LinuxQuestions.org - Quartz64 RK3566 (aarch64)

- slarm64 (https://www.linuxquestions.org/questions/slarm64-132/)

- - Quartz64 RK3566 (aarch64) (https://www.linuxquestions.org/questions/slarm64-132/quartz64-rk3566-aarch64-4175707556/)

Quartz64 RK3566 (aarch64)

previous discussion Quartz64

I spent the past few days pulling my hair out over a silly bug (or something, you tell me...)

Trying to get this booting off of eMMC: I dd the image file over to /dev/mmcblk1. Then I mount /dev/mmcblk1p1 to ~/boot and /dev/mmcblk1p2 to ~/root, so that I can edit ~/boot/extlinux/extlinux.conf and set the rootdev to /dev/mmcblk1p2. I also edit ~/root/etc/fstab and set the boot and root partitions to /dev/mmcblk1p1 and /dev/mmcblk1p2, respectively.

I have done this on many other boards many times, and I generally wind up with a booting eMMC. I once did it on the Quartz64, a few months ago, and then I tried to update the bootloader files unsuccessfully. I might not have the right commands for this board. Anyway... this time it does not boot. I have tried your images, my images, old images, new images, nothing seems to work. I tried rolling back the ATF version, the u-boot version, tried disabling a few patches (all changes since I last got this booting off the eMMC successfully). Nothing seemed to work.

Then, just on a whim, I changed the files mentioned above to reflect a boot device of /dev/mmcblk2p1 and a root device of /dev/mmcblk2p2, and look at that, it boots!

So, I am not sure why or how this happens, but when you boot from the SD card, it sees the eMMC as /dev/mmcblk1. However, when/if you can boot from the eMMC, it sees itself as /dev/mmcblk2 instead. I recall something like this happening on other boards, and that is what gave me the idea in the first place.

Anyway, I just wanted to post this here in case anyone else runs into trouble trying to get the Quartz64 booting off of the eMMC.

Quote:

Originally Posted by shelldweller (Post 6330043)

Thanks!

Quote:

Originally Posted by sndwvs (Post 6340980)

installation README.TXT

kernel 5.17.0

slarm64-current-aarch64-server-quartz64-5.17.0-build-20220323.img.zst
slarm64-current-aarch64-server-quartz64-5.17.0-build-20220323.img.zst.sha256
slarm64-current-aarch64-xfce-quartz64-5.17.0-build-20220323.img.zst
slarm64-current-aarch64-xfce-quartz64-5.17.0-build-20220323.img.zst.sha256

This one is not booting for me, unfortunately. I built the same image myself, and it does not boot either. Any luck getting this to boot off of SD Card? Just curious, thanks.

...also, I am running into an interesting assembly code error while trying to build a legacy image. I have never seen this before, and various related internet search results are not clarifying things for me much.

Code:

  AS      arch/arm64/kernel/entry.o

  CC      arch/arm64/kernel/irq.o

arch/arm64/kernel/entry.S: Assembler messages:

arch/arm64/kernel/entry.S:582: Error: unknown mnemonic `clear_address_tag' -- `clear_address_tag x0,x3'

arch/arm64/kernel/entry.S:745: Error: unknown mnemonic `clear_address_tag' -- `clear_address_tag x0,x26'

make[1]: *** [scripts/Makefile.build:433: arch/arm64/kernel/entry.o] Error 1

make[1]: *** Waiting for unfinished jobs....

Just thought I would report this here. Thanks again.

Hi shelldweller,

Thank you, after the last patch, I did not check the compilation of the nucleus. Additional changes have been added to the patch for more compliance with Kernel.org nucleus.
Made additional fixes for assembling kernel 4.19.236.

Quote:

Originally Posted by shelldweller (Post 6341065)

This one is not booting for me, unfortunately. I built the same image myself, and it does not boot either. Any luck getting this to boot off of SD Card? Just curious, thanks.

Confirmed, I think there is something wrong with u-boot. I created a fresh legacy image, and it would not boot either. I then took an older image with a 5.16.7 kernel on it, replaced that kernel with the fresh legacy kernel I just built, and it booted fine. I then upgraded to the 5.17.0 kernel, and it seemed to boot fine, but I had no HDMI output at all, which is typical for the next-kernel and my monitor for some reason.

When I try to boot the latest images, I do not even get a red blinking light. I tried changing /dev/mmcblk0p* to /dev/mmcblk1p* and /dev/mmcblk2p* in the relevant boot files, and nothing seemed to do the trick. I could not get the red lights blinking nor any screen activity to happen. So, I am pretty sure something is off with u-boot (or maybe atf) on this board at the moment. Unless I am the only one experiencing this and it is specific to my board.

Just a heads up. Thanks for the legacy kernel fix in any case, I was able to update my eMMC with that.

Hi shelldweller,

Thanks, one of the patches broke the booting.

Hi sndwvs,

I noticed that my Quartz64 has been running slower on some benchmarks than what I recall a few months ago. I went to check if it was running at full speed, and it doesn't seem like any frequency governor is even loaded:

Code:

root@quartz:~# cpufreq-info

cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009

Report errors and bugs to cpufreq@vger.kernel.org, please.

analyzing CPU 0:

  no or unknown cpufreq driver is active on this CPU

  maximum transition latency: 4294.55 ms.

analyzing CPU 1:

  no or unknown cpufreq driver is active on this CPU

  maximum transition latency: 4294.55 ms.

analyzing CPU 2:

  no or unknown cpufreq driver is active on this CPU

  maximum transition latency: 4294.55 ms.

analyzing CPU 3:

  no or unknown cpufreq driver is active on this CPU

  maximum transition latency: 4294.55 ms.

I checked my latest image as well as yours, both legacy and next. I get the same thing on all. Is there any way to adjust the frequency on these? It may have nothing to do with my benchmarking results (now it is the slowest of all my slarm64 machines for some reason, a title previously held by the Pinebook :scratch:). But I figured it would be a good place to start investigating.

FWIW, I tried compiling a fresh legacy kernel just to see if there were any changes. I noticed an extra module loaded between 4.19.236 and 4.19.237, so maybe it is still in the works. I got this far on the legacy compilation, however:

Code:

  CC      fs/xfs/libxfs/xfs_trans_resv.o

  CC      fs/xfs/libxfs/xfs_types.o

  CC      fs/xfs/xfs_aops.o

  CC      fs/xfs/xfs_attr_inactive.o

  CC      fs/xfs/xfs_attr_list.o

  CC      fs/xfs/xfs_bmap_util.o

  CC      fs/xfs/xfs_buf.o

  CC      fs/xfs/xfs_dir2_readdir.o

  CC      fs/xfs/xfs_discard.o

  CC      fs/xfs/xfs_error.o

  CC      fs/xfs/xfs_export.o

  CC      fs/xfs/xfs_extent_busy.o

  CC      fs/xfs/xfs_file.o

  CC      fs/xfs/xfs_filestream.o

  CC      fs/xfs/xfs_fsmap.o

  CC      fs/xfs/xfs_fsops.o

  CC      fs/xfs/xfs_globals.o

  CC      fs/xfs/xfs_icache.o

  CC      fs/xfs/xfs_ioctl.o

  CC      fs/xfs/xfs_iomap.o

  CC      fs/xfs/xfs_iops.o

  CC      fs/xfs/xfs_inode.o

  CC      fs/xfs/xfs_itable.o

  CC      fs/xfs/xfs_message.o

  CC      fs/xfs/xfs_mount.o

  CC      fs/xfs/xfs_mru_cache.o

  CC      fs/xfs/xfs_reflink.o

  CC      fs/xfs/xfs_stats.o

  CC      fs/xfs/xfs_super.o

  CC      fs/xfs/xfs_symlink.o

  CC      fs/xfs/xfs_sysfs.o

  CC      fs/xfs/xfs_trans.o

  CC      fs/xfs/xfs_xattr.o

  CC      fs/xfs/kmem.o

  CC      fs/xfs/xfs_log.o

  CC      fs/xfs/xfs_log_cil.o

  CC      fs/xfs/xfs_bmap_item.o

  CC      fs/xfs/xfs_buf_item.o

  CC      fs/xfs/xfs_extfree_item.o

  CC      fs/xfs/xfs_icreate_item.o

  CC      fs/xfs/xfs_inode_item.o

  CC      fs/xfs/xfs_refcount_item.o

  CC      fs/xfs/xfs_rmap_item.o

  CC      fs/xfs/xfs_log_recover.o

  CC      fs/xfs/xfs_trans_ail.o

  CC      fs/xfs/xfs_trans_bmap.o

  CC      fs/xfs/xfs_trans_buf.o

  CC      fs/xfs/xfs_trans_extfree.o

  CC      fs/xfs/xfs_trans_inode.o

  CC      fs/xfs/xfs_trans_refcount.o

  CC      fs/xfs/xfs_trans_rmap.o

  CC      fs/xfs/xfs_sysctl.o

  CC      fs/xfs/xfs_ioctl32.o

  AR      fs/xfs/built-in.a

  AR      fs/built-in.a

|err | details      /hdd/slarm64/images_build_kit/build/source/build.log

root@quartz:/hdd/slarm64/images_build_kit#

Just curious. Thank you.

thanks, added fixes for kernel compilation.

More legacy compilation errors...

Code:

  CC [M]  drivers/net/wireless/rockchip_wlan/rkwifi/bcmdhd/dhd_pno.o

  CC [M]  drivers/net/wireless/rockchip_wlan/rkwifi/bcmdhd/dhd_common.o

  CC      drivers/video/fbdev/core/fbcon_ud.o

  CC      drivers/usb/dwc3/gadget.o

  CC      drivers/video/fbdev/core/fbcon_ccw.o

drivers/usb/dwc3/gadget.c: In function 'dwc3_gadget_ep_cleanup_completed_request':

drivers/usb/dwc3/gadget.c:2910:25: error: 'request_status' undeclared (first use in this function)

 2910 |                        request_status = -EXDEV;

      |                        ^~~~~~~~~~~~~~

drivers/usb/dwc3/gadget.c:2910:25: note: each undeclared identifier is reported only once for each function it appears in

drivers/usb/dwc3/gadget.c: In function 'dwc3_gadget_init':

drivers/usb/dwc3/gadget.c:3780:13: warning: unused variable 'request_status' [-Wunused-variable]

error, forbidden warning:gadget.c:3780

 3780 |        int request_status;

      |            ^~~~~~~~~~~~~~

make[3]: *** [scripts/Makefile.build:333: drivers/usb/dwc3/gadget.o] Error 1

make[2]: *** [scripts/Makefile.build:637: drivers/usb/dwc3] Error 2

make[1]: *** [scripts/Makefile.build:637: drivers/usb] Error 2

make[1]: *** Waiting for unfinished jobs....

  CC      drivers/video/fbdev/core/cfbfillrect.o



.........



  CC [M]  drivers/net/wireless/rockchip_wlan/rtl8822ce/hal/btc/halbtccommon.o

  CC [M]  drivers/net/wireless/rockchip_wlan/rtl8822ce/hal/btc/halbtc8822c.o

  CC [M]  drivers/net/wireless/rockchip_wlan/rtl8822ce/platform/platform_ops.o

  CC [M]  drivers/net/wireless/rockchip_wlan/rtl8822ce/core/rtw_mp.o

  LD [M]  drivers/net/wireless/rockchip_wlan/rtl8822ce/rtl88x2ce.o

  AR      drivers/net/wireless/rockchip_wlan/built-in.a

  AR      drivers/net/wireless/built-in.a

  AR      drivers/net/built-in.a

make: *** [Makefile:1194: drivers] Error 2

This was with EXTERNAL_WIFI=no, but I think it was stopping in the same place without that flag, too.

This kernel looks promising though, there are some new config settings for CPUFREQ, maybe that will finally work with the next build.

Just FYI. Thank you!