Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Well, that solution suggests that 'CONFIG_LEGACY_PTYS' should be enabled in the kernel. For some reason, at least on the sarpi64 5.9.12 kernel it is not enabled. I will try to update to the latest 5.10 in slarm64 and check.
almost everywhere off by default:
Code:
grep CONFIG_LEGACY_PTYS -r
linux-bcm2711-legacy.config:# CONFIG_LEGACY_PTYS is not set
linux-meson-sm1-legacy.config:# CONFIG_LEGACY_PTYS is not set
linux-rk3288-legacy.config:# CONFIG_LEGACY_PTYS is not set
linux-bcm2711-next.config:# CONFIG_LEGACY_PTYS is not set
linux-meson-sm1-next.config:CONFIG_LEGACY_PTYS=y
linux-rk3288-next.config:# CONFIG_LEGACY_PTYS is not set
linux-rk3308-legacy.config:# CONFIG_LEGACY_PTYS is not set
linux-rk3399-legacy.config:# CONFIG_LEGACY_PTYS is not set
linux-rk3399-next.config:CONFIG_LEGACY_PTYS=y
linux-sun50iw1-legacy.config:# CONFIG_LEGACY_PTYS is not set
linux-sun8i-legacy.config:CONFIG_LEGACY_PTYS=y
linux-sun50iw1-next.config:# CONFIG_LEGACY_PTYS is not set
linux-sun8i-next.config:# CONFIG_LEGACY_PTYS is not set
I think I followed the instructions to the letter, but it will not boot:
On my linux box:
wget http://dl.fail.pp.ua/slackware/image...201029.img.zst
zstd -d slarm64-current-aarch64-base-rootfs-20201023-4.19.153-rock64-build-20201029.img.zst
dd if=slarm64-current-aarch64-base-rootfs-20201023-4.19.153-rock64-build-20201029.img of=/dev/sdd bs=1M
.. where /dev/sdd was the SD card plugged in with a USD adapter. Then I inserted the SD card into my Rock64 v2 and tried to boot. I waited more than 30 minutes, and nothing happened.
What I am doing wrong?
I did check the content of the SD card before I removed it from my linux box, and it looked OK.
Somebody posted that an eMMC module has to exist for the boot to happen. I don't have one (ordered, on its way). Is that true? Will it not boot without one?
Another source of confusion for me is the different image versions. I understand that there are at least two versions, one with XFCE, and one without graphical UI, the 'base' version, but what about all the others there?
Would someone explain how do the above differ from each-other?
Which is the best for Rock64? I will not need a GUI, because I want to use this for a server, so which of the 3 'base' versions should I use?
And what are boot-*.tar.xz files? What are those for?
Sorry for the dumb questions. I looked around a bit but I did not find any info about these.
Thanks a lot,
Karl
PS: My Rock64 boots with Armbian, but I really want to use Slackware.
is optional for eMMC to work. boot - *.tar.xz is a separately packaged bootloader (in case you need/want to update on the installed system). images are divided into basic and desktop, the difference is only in the set of packages, then they are subdivided according to the type of kernel legacy 4.4.y, mainline 5.11.y and experimental (from rockchip).
you need base images: slarm64-current-aarch64-base-rock64-5.11.11-build-20210402.img.zst or slarm64-current-aarch64-base-rock64-4.4.254-build-20210130.img.zst
then follow the instructions README.TXT
Your build box must be much faster than mine, you always beat me to the punch. ;-) In any case, here is a second version of LibreOffice; this one has no third party dependencies at all, and also no JDK support, just in case anyone wants to try an alternate version.
is optional for eMMC to work. boot - *.tar.xz is a separately packaged bootloader (in case you need/want to update on the installed system). images are divided into basic and desktop, the difference is only in the set of packages, then they are subdivided according to the type of kernel legacy 4.4.y, mainline 5.11.y and experimental (from rockchip).
you need base images: slarm64-current-aarch64-base-rock64-5.11.11-build-20210402.img.zst or slarm64-current-aarch64-base-rock64-4.4.254-build-20210130.img.zst
then follow the instructions README.TXT
I appreciate your answer very much. I tried both those images - my rock64 v2.0 did not boot. Then, for sanity check, I flashed a new Armbian (because it worked previously), and it did NOT boot either. There is something wrong with the hardware. I read a bit on the internet and learned that rock64 has many hardware issues.
I think I am going to move on to another system. Can you please recommend another ARM device that supports Slackware? I was going to use rock64 as a router/server/openvpn. It has filled that role nicely before with Armbian, but I want to stick with Slackware. And now it seems my rock64 is broken.
I did erase the SPI. Didn't help.
Strange, because just before I started with Slackware, I inserted the old SD with Armbian on it, and it did start to boot. Then it ran into a problem, but I though it was a file system error. Anyway something has broken.
I did erase the SPI. Didn't help.
Strange, because just before I started with Slackware, I inserted the old SD with Armbian on it, and it did start to boot. Then it ran into a problem, but I though it was a file system error. Anyway something has broken.
If you had a u-boot prompt, it is actually better to just run:
Code:
env default -a -f
..snip..
saveenv
reset
This will get rid of your settings in SPI Flash, while still retaining the soc distributiors default u-boot that is know to work with that hardware. I made the mistake of removing the u-boot image in SPI flash and replacing it. Had a ton of problems recently due to this mistake, including USB and Serial connections. Once I restored the defaults with an upstream u-boot build, problems disappeared.
If you had a u-boot prompt, it is actually better to just run:
Code:
env default -a -f
..snip..
saveenv
reset
This will get rid of your settings in SPI Flash, while still retaining the soc distributiors default u-boot that is know to work with that hardware. I made the mistake of removing the u-boot image in SPI flash and replacing it. Had a ton of problems recently due to this mistake, including USB and Serial connections. Once I restored the defaults with an upstream u-boot build, problems disappeared.
Thank you, but you lost me there. Are you recommending to restore the u-boot image? I don't even know how to start. What should I do?
My original problem was that my rock64 did not boot at all. Shorting the SPI Clock pin allowed me to boot into ayufan's image, and I just followed his instructions.
Once you get your sustem running again, copy over the latest u-boot from ayufan ( i think that is the spelling). Put it on the SPI flash mtd0, I think. It is basically the same thing as erasing the flash, except you are flashing it instead with a new image. From what you posted it looks like Right now your sd card has u-boot on it and that is why the sbc still boots. Just be careful not to put the wrong image, file or /dev/random onto SPI flash. You will have to jump the SPI flash again and erase it, rinse, repeat the SPI flash write.
I am not sure if anyone here is interested in this, but I uploaded my slightly old Rock64 base image, with a 5.6.19 kernel. I am pretty sure this one boots without needing the eMMC attached, and is one of the most stable images I ever produced for the Rock64 board. The kernel is a bit outdated, but otherwise it might be worth playing around with if you are still having trouble booting the other images:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.