Mainline kernel bad magic for Pine64-A64-LTS

(Also posted in pine64 forum https://forum.pine64.org/showthread.php?tid=19460)
In an attempt to troubleshoot failing to get generic alpine linux to run on PA64-2G-LTS, I've tried to reduce the problem to the smallest steps that are legible to me.
When booting the kernel, I get "Bad ARM64 Image Magic" I can't figure out what this means, and why it is happening. Sources I have searched seem to be board specific, and found nothing on this board. I've arrived at a point where I cannot find a way to reason further about it, so thus I am reaching out.
I am currently loading the kernel and dtb manually at the uboot prompt:
setenv bootargs loglevel=7 earlyprintk fatload mmc 0:1 0x42000000 boot/vmlinux fatload mmc 0:1 0x4a000000 boot/u-boot.dtb booti 0x42000000 - 0x4a000000
My current configuration is:
- linux 5.14 from mainline (git:7d2a07b769330c34b4deabeed939325c77a7ec2f) - u-boot v2024.10 from https://source.denx.de/u-boot/u-boot (git:f919c3a889f0ec7d63a48b5d0ed064386b0980bd) - dtb from the u-boot build - bl31.bin from PLAT=sun50i_a64 https://git.trustedfirmware.org/TF-A/tru...ware-a.git lts-v2.10.6 (git:f2aebf361050d69176d60016170291efa9e08a68) - scp.bin from https://github.com/crust-firmware/crust 0.6 (git:ffe9f1ac9c675e6e67db9084bd19fbdeffd8e162) - u-boot-sunxi-with-spl.bin written to offset 8k - tried sd and emmc vfat single partition (whole disk) with * boot/vmlinux * boot/u-boot.dtb
Files:
- uboot defconfig: https://g33k.holbrook.no/c36cab0e6a15127...7b25f71bdd - uboot environment (saved from soc): https://g33k.holbrook.no/1c4d93e6510eb49...2329468b73 - linux defconfig: https://g33k.holbrook.no/5bde4487e333f5a...19beb3382f

Hi Louis,
On 10/13/24 9:34 PM, Louis Holbrook wrote:
[You don't often get email from accounts-uboot@holbrook.no. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
(Also posted in pine64 forum https://forum.pine64.org/showthread.php?tid=19460)
In an attempt to troubleshoot failing to get generic alpine linux to run on PA64-2G-LTS, I've tried to reduce the problem to the smallest steps that are legible to me.
When booting the kernel, I get "Bad ARM64 Image Magic" I can't figure out what this means, and why it is happening. Sources I have searched seem to be board specific, and found nothing on this board. I've arrived at a point where I cannot find a way to reason further about it, so thus I am reaching out.
I am currently loading the kernel and dtb manually at the uboot prompt:
setenv bootargs loglevel=7 earlyprintk fatload mmc 0:1 0x42000000 boot/vmlinux fatload mmc 0:1 0x4a000000 boot/u-boot.dtb booti 0x42000000 - 0x4a000000
Make sure that those are absolutely NOT overlapping, i.e. you may be writing u-boot.dtb over vmlinux and thus corrupting it. I've not made the maths if this is reasonable with the addresses provided there but it's good general advice anyway. What I usually like to do is have the DTB right before the vmlinux, like 1MB before. No way a DTB is going to be bigger than that :)
I have never used vmlinux so cannot tell if you're supposed to use booti with it. I usually just get the Image or Image.gz from arch/arm64/boot and `booti` it and that should just work.
I also do not exactly know if you're supposed to be able to use u-boot's DTB for Linux kernel. Eventually we want to go towards this, but I don't know if that's necessarily possible today (but that wouldn't have anything to do with the bad image).
Cheers, Quentin

Hi,
On Mon, 14 Oct 2024 at 11:00, Quentin Schulz quentin.schulz@cherry.de wrote:
Hi Louis,
On 10/13/24 9:34 PM, Louis Holbrook wrote:
[You don't often get email from accounts-uboot@holbrook.no. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
(Also posted in pine64 forum https://forum.pine64.org/showthread.php?tid=19460)
In an attempt to troubleshoot failing to get generic alpine linux to run on PA64-2G-LTS, I've tried to reduce the problem to the smallest steps that are legible to me.
When booting the kernel, I get "Bad ARM64 Image Magic" I can't figure out what this means, and why it is happening. Sources I have searched seem to be board specific, and found nothing on this board. I've arrived at a point where I cannot find a way to reason further about it, so thus I am reaching out.
I am currently loading the kernel and dtb manually at the uboot prompt:
setenv bootargs loglevel=7 earlyprintk fatload mmc 0:1 0x42000000 boot/vmlinux fatload mmc 0:1 0x4a000000 boot/u-boot.dtb booti 0x42000000 - 0x4a000000
Make sure that those are absolutely NOT overlapping, i.e. you may be writing u-boot.dtb over vmlinux and thus corrupting it. I've not made the maths if this is reasonable with the addresses provided there but it's good general advice anyway. What I usually like to do is have the DTB right before the vmlinux, like 1MB before. No way a DTB is going to be bigger than that :)
I have never used vmlinux so cannot tell if you're supposed to use booti with it. I usually just get the Image or Image.gz from arch/arm64/boot and `booti` it and that should just work.
Right, that isn't actually an 'Image', so far as I am aware. However on x86 machines it seems that it sort-of is? I'm a bit unsure about why.
You can use arch/arm64/boot/Image (offhand)
I also do not exactly know if you're supposed to be able to use u-boot's DTB for Linux kernel. Eventually we want to go towards this, but I don't know if that's necessarily possible today (but that wouldn't have anything to do with the bad image).
Cheers, Quentin
Regards, Simon
participants (3)
-
Louis Holbrook
-
Quentin Schulz
-
Simon Glass