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.
FWIW, I have been testing these on my spare board when I have the time. The legacy versions work great here. The next-kernel versions still do not output video to the HDMI port, at least not with a VGA adapter attached. Next, I will test it out on a non-VGA monitor when I can. But in any case, I have my main mini-server locked on the 5.6.19 kernel, I have no issues with that kernel on this board, video out through HDMI-to-VGA works fine on the older kernels.
Regardless, thanks again for supporting this board.
Okay, sorry for the late reply on this one. I was trying to investigate some inconsistent behavior with these images when I got slammed with work. I spent some time today figuring out exactly what was going on.
The 4.4.254-base and -xfce images do not boot at all without an eMMC card attached to the board. If I attach one (that has a bootable image w/ 5.6.19 kernel in this case), the board boots off of the SD card and ignores the eMMC. Without an eMMC, the red and white lights come on solid, but the red light never starts blinking. No logs are generated, no swap is created, etc. Strange, I do not remember seeing this behavior with other images. But now even my 5.6.19 image will not boot from SD card without the eMMC on this board. I wonder if it is dying? I definitely recall this board working without an eMMC attached at one point. Hmmmm... Anyway, once I had that figured out, this image boots to the HDMI-to-VGA monitor with no problems.
The 5.10.10 images also requires an eMMC to be connected in order to boot, same as above. Neither HDMI-to-VGA nor HDMI-to-DVI gives any signal. I have tried plugging in the video after booting once the red light is blinking, that does not help. I also tried adding that line you suggested to uEnv.txt, and the same symptoms result, I see no difference in the video output at all.
I have not tried any newer builds since these. But if I am having hardware issues with this board, any testing I do might be suspect, I am not sure.
If anyone else has this same board, I would be interested to see if you can get any of these images to boot from the SD card without an eMMC connected, regardless of the monitor output. If so, then my board might be on its way out.
No, everything is fine with the board, I tested it and it turned out that u-boot with native TPL (memory initialization) caused the board to hang. At first I lowered the memory frequency from 800 to 650 and this stabilized the work (stopped freezing), but there was an unpleasant twitching of the image when working with the mouse. After which I stopped using TPL and switched to DDR blob, after that the work stabilized and the board is now constantly compiling without any problems.
Therefore, it is advisable to use both the eMMC and the sdcard (since when the eMMC is connected, the bootloader is always booting from it) the bootloader from 2021.01.30 or newer. Concerning. yes so far there is a problem with the legacy kernel when booting without eMMC.
[...] Therefore, it is advisable to use both the eMMC and the sdcard (since when the eMMC is connected, the bootloader is always booting from it) the bootloader from 2021.01.30 or newer. Concerning. yes so far there is a problem with the legacy kernel when booting without eMMC.
Ah, okay, good to know it is not just me. Thanks sndwvs.
While trying a fresh next-kernel build for Rock64, I ran into this early in the kernel build:
Code:
CC kernel/softirq.o
AS arch/arm64/crypto/aes-ce.o
CC arch/arm64/crypto/crc32-arm64.o
CC arch/arm64/kvm/../../../virt/kvm/arm/vgic-v2-emul.o
CC kernel/resource.o
CC arch/arm64/kernel/smp.o
kernel/exit.c: In function `do_exit':
kernel/exit.c:702:3: error: implicit declaration of function `futext_exit_recursive'; did you mean `futex_exit_recursive'? [-Werror=implicit-function-declaration]
702 | futext_exit_recursive(tsk);
| ^~~~~~~~~~~~~~~~~~~~~
| futex_exit_recursive
LD arch/arm64/crypto/sha1-ce.o
LD arch/arm64/crypto/sha2-ce.o
LD arch/arm64/crypto/ghash-ce.o
CC arch/arm64/kvm/../../../virt/kvm/arm/vgic-v3.o
LD arch/arm64/crypto/aes-ce-ccm.o
LD arch/arm64/crypto/aes-ce-blk.o
LD arch/arm64/crypto/built-in.o
CC arch/arm64/kernel/smp_spin_table.o
CC arch/arm64/kernel/topology.o
CC kernel/sysctl.o
AS arch/arm64/kernel/smccc-call.o
CC kernel/sysctl_binary.o
CC kernel/capability.o
CC arch/arm64/kvm/../../../virt/kvm/arm/vgic-v3-emul.o
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:280: kernel/exit.o] Error 1
make[1]: *** Waiting for unfinished jobs....
CC arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.o
CC arch/arm64/kernel/sys32.o
AS arch/arm64/kernel/kuser32.o
CC arch/arm64/kvm/hyp/vgic-v2-sr.o
CC arch/arm64/kvm/hyp/vgic-v3-sr.o
CC arch/arm64/kernel/signal32.o
CC arch/arm64/kvm/hyp/timer-sr.o
LD arch/arm64/kvm/kvm.o
CC arch/arm64/kvm/hyp/sysreg-sr.o
CC arch/arm64/kernel/sys_compat.o
AS arch/arm64/kernel/entry32.o
make: *** [Makefile:1044: kernel] Error 2
make: *** Waiting for unfinished jobs....
CC arch/arm64/kvm/hyp/debug-sr.o
CC arch/arm64/kernel/ftrace.o
AS arch/arm64/kernel/entry-ftrace.o
CC arch/arm64/kernel/arm64ksyms.o
AS arch/arm64/kvm/hyp/entry.o
CC arch/arm64/kvm/hyp/switch.o
CC arch/arm64/kernel/module.o
CC arch/arm64/kernel/perf_regs.o
AS arch/arm64/kvm/hyp/fpsimd.o
CC arch/arm64/kernel/perf_callchain.o
AS arch/arm64/kvm/hyp/hyp-entry.o
CC arch/arm64/kvm/hyp/tlb.o
CC arch/arm64/kernel/perf_event.o
CC arch/arm64/kernel/hw_breakpoint.o
AS arch/arm64/kernel/sleep.o
CC arch/arm64/kernel/suspend.o
LD arch/arm64/kvm/hyp/built-in.o
LD arch/arm64/kvm/built-in.o
CC arch/arm64/kernel/cpuidle.o
CC arch/arm64/kernel/pci.o
CC arch/arm64/kernel/armv8_deprecated.o
arch/arm64/kernel/hw_breakpoint.c: In function `arch_bp_generic_fields':
arch/arm64/kernel/hw_breakpoint.c:364:5: note: parameter passing for argument of type `struct arch_hw_breakpoint_ctrl' changed in GCC 9.1
364 | int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
| ^~~~~~~~~~~~~~~~~~~~~~
LD arch/arm64/kernel/probes/built-in.o
OBJCOPY arch/arm64/kernel/vdso/vdso.so
AS arch/arm64/kernel/head.o
AS arch/arm64/kernel/vdso/vdso.o
LDS arch/arm64/kernel/vmlinux.lds
LD arch/arm64/kernel/vdso/built-in.o
LD arch/arm64/kernel/built-in.o
I have not tried legacy yet, will try that next. I just wanted to report it before I lost the place in the build.log.
UPDATE: Legacy gives the same errors and then stops at a later point:
Code:
CC kernel/fork.o
AS arch/arm64/crypto/sha1-ce-core.o
CC arch/arm64/crypto/sha2-ce-glue.o
AS arch/arm64/kernel/hyp-stub.o
CC arch/arm64/kernel/psci.o
CC arch/arm64/kernel/cpu_ops.o
CC arch/arm64/kernel/insn.o
CC arch/arm64/kvm/../../../arch/arm/kvm/mmio.o
CC arch/arm64/kernel/return_address.o
AS arch/arm64/crypto/sha2-ce-core.o
CC arch/arm64/kvm/../../../arch/arm/kvm/psci.o
CC arch/arm64/crypto/ghash-ce-glue.o
CC arch/arm64/kvm/../../../arch/arm/kvm/perf.o
CC arch/arm64/kernel/cpuinfo.o
CC arch/arm64/kvm/emulate.o
AS arch/arm64/crypto/ghash-ce-core.o
CC arch/arm64/kernel/cpu_errata.o
CC arch/arm64/crypto/aes-ce-cipher.o
CC arch/arm64/crypto/aes-ce-ccm-glue.o
CC arch/arm64/kvm/inject_fault.o
CC arch/arm64/kvm/regmap.o
CC arch/arm64/kernel/cpufeature.o
CC kernel/exec_domain.o
CC kernel/panic.o
CC arch/arm64/kernel/alternative.o
AS arch/arm64/kvm/hyp.o
AS arch/arm64/crypto/aes-ce-ccm-core.o
AS arch/arm64/kvm/hyp-init.o
CC arch/arm64/crypto/aes-glue-ce.o
CC arch/arm64/kernel/cacheinfo.o
CC arch/arm64/kvm/handle_exit.o
CC arch/arm64/kvm/guest.o
CC kernel/cpu.o
CC kernel/exit.o
CC arch/arm64/kernel/smp.o
AS arch/arm64/crypto/aes-ce.o
CC arch/arm64/crypto/crc32-arm64.o
CC arch/arm64/kernel/smp_spin_table.o
CC arch/arm64/kvm/debug.o
kernel/exit.c: In function `do_exit':
kernel/exit.c:702:3: error: implicit declaration of function `futext_exit_recursive'; did you mean `futex_exit_recursive'? [-Werror=implicit-function-declaration]
702 | futext_exit_recursive(tsk);
| ^~~~~~~~~~~~~~~~~~~~~
| futex_exit_recursive
CC arch/arm64/kvm/reset.o
CC arch/arm64/kernel/topology.o
CC kernel/softirq.o
LD arch/arm64/crypto/sha1-ce.o
LD arch/arm64/crypto/sha2-ce.o
LD arch/arm64/crypto/ghash-ce.o
LD arch/arm64/crypto/aes-ce-ccm.o
LD arch/arm64/crypto/aes-ce-blk.o
LD arch/arm64/crypto/built-in.o
AS arch/arm64/kernel/smccc-call.o
CC kernel/resource.o
CC arch/arm64/kernel/sys32.o
CC arch/arm64/kvm/sys_regs.o
LD certs/built-in.o
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:280: kernel/exit.o] Error 1
make[1]: *** Waiting for unfinished jobs....
CC arch/arm64/kvm/sys_regs_generic_v8.o
CC mm/filemap.o
AS arch/arm64/kernel/kuser32.o
CC arch/arm64/kernel/signal32.o
CC arch/arm64/kernel/sys_compat.o
AS arch/arm64/kernel/entry32.o
CC fs/open.o
make: *** [Makefile:1044: kernel] Error 2
make: *** Waiting for unfinished jobs....
CC arch/arm64/kvm/../../../virt/kvm/arm/vgic.o
CC arch/arm64/kvm/../../../virt/kvm/arm/vgic-v2.o
CC arch/arm64/kernel/ftrace.o
AS arch/arm64/kernel/entry-ftrace.o
CC arch/arm64/kvm/../../../virt/kvm/arm/vgic-v2-emul.o
CC arch/arm64/kernel/arm64ksyms.o
CC arch/arm64/kvm/../../../virt/kvm/arm/vgic-v3.o
CC mm/mempool.o
CC arch/arm64/kernel/module.o
CC arch/arm64/kernel/perf_regs.o
CC arch/arm64/kvm/../../../virt/kvm/arm/vgic-v3-emul.o
CC fs/read_write.o
CC mm/oom_kill.o
CC mm/maccess.o
CC arch/arm64/kernel/perf_callchain.o
CC arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.o
CC arch/arm64/kernel/perf_event.o
CC arch/arm64/kernel/hw_breakpoint.o
CC mm/page_alloc.o
CC mm/page-writeback.o
CC arch/arm64/kvm/hyp/vgic-v2-sr.o
CC arch/arm64/kvm/hyp/vgic-v3-sr.o
CC arch/arm64/kvm/hyp/timer-sr.o
arch/arm64/kernel/hw_breakpoint.c: In function `arch_bp_generic_fields':
arch/arm64/kernel/hw_breakpoint.c:364:5: note: parameter passing for argument of type `struct arch_hw_breakpoint_ctrl' changed in GCC 9.1
364 | int arch_bp_generic_fields(struct arch_hw_breakpoint_ctrl ctrl,
| ^~~~~~~~~~~~~~~~~~~~~~
CC fs/file_table.o
AS arch/arm64/kernel/sleep.o
CC arch/arm64/kernel/suspend.o
CC mm/readahead.o
CC arch/arm64/kvm/hyp/sysreg-sr.o
CC fs/super.o
CC arch/arm64/kernel/cpuidle.o
CC arch/arm64/kvm/hyp/debug-sr.o
CC arch/arm64/kernel/pci.o
AS arch/arm64/kvm/hyp/entry.o
CC mm/swap.o
CC arch/arm64/kvm/hyp/switch.o
CC arch/arm64/kernel/armv8_deprecated.o
AS arch/arm64/kvm/hyp/fpsimd.o
CC mm/truncate.o
CC arch/arm64/kvm/hyp/tlb.o
CC fs/char_dev.o
AS arch/arm64/kvm/hyp/hyp-entry.o
LD arch/arm64/kvm/hyp/built-in.o
LD arch/arm64/kvm/kvm.o
LD arch/arm64/kvm/built-in.o
CC mm/vmscan.o
CC fs/stat.o
LD arch/arm64/kernel/probes/built-in.o
AS arch/arm64/kernel/head.o
CC mm/shmem.o
OBJCOPY arch/arm64/kernel/vdso/vdso.so
AS arch/arm64/kernel/vdso/vdso.o
CC mm/util.o
LD arch/arm64/kernel/vdso/built-in.o
LDS arch/arm64/kernel/vmlinux.lds
LD arch/arm64/kernel/built-in.o
CC mm/mmzone.o
CC mm/vmstat.o
CC fs/exec.o
CC fs/pipe.o
CC mm/backing-dev.o
[...]
CC fs/xfs/xfs_qm.o
CC fs/xfs/xfs_quotaops.o
CC fs/xfs/xfs_rtalloc.o
CC fs/xfs/xfs_acl.o
CC fs/xfs/xfs_sysctl.o
CC fs/xfs/xfs_ioctl32.o
CC fs/xfs/xfs_pnfs.o
LD fs/xfs/xfs.o
LD fs/xfs/built-in.o
LD fs/built-in.o
No rush of course. I was just playing around trying to update my other boards now that the Pinebook seems to be stabilizing. I thought I would check in on the external video issue I was having with the Rock64. Right now it is humming along on a 5.6.19 kernel with no issues, but the video issue on the newer kernels has me somewhat intrigued.
thanks as always....
Last edited by shelldweller; 03-23-2021 at 06:33 PM.
Reason: added legacy info
I just wanted to report that the latest images solve all of the problems I have been having on this board. I get video output (at least through HDMI-to-DVI adapter, maybe not HDMI-to-VGA, but that might just be this adapter, not quite sure yet...), and for the first time ever one of my boards has working Ethernet. I have even upgraded my 5.6.19 box to the 5.10.25 kernel, and so far it is fully stable on Rock64. The legacy kernel seems to work well too.
I have a question about uploading the kernel packages. Should I update the bootloader files at the same time? It seems like this is necessary when switching kernel branches. However, if I am upgrading from 4.4.268 to 4.4.269, should I also update the files that get put into the boot-***.txz archive?
If so, what would the exact commands be? I am able to do this on the Pinebook with these instructions, just for reference:
What would be the equivalent commands for the three files that get created for the Rock64? (idbloader.img, rkspi_loader.img, u-boot.itb) Specifically, what would the seek values be?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
