[U-Boot] Booting linux zImage on vexpress-a15
Hi @all,
I'm trying to build a linux kernel as zImage and boot it with u-boot on a qemu vexpress-a15 machine. The host machine is a Ubuntu 18.04.
What I tried until now:
1. Get Linux from git, export ARCH=arm and CROSS_COMPILE=arm-linux-gnueabihf-
2. Make Defconfig: make vexpress_defconfig
3. Enable 'Early Printk' with make menuconfig
4. Make Kernel: make
5. Get U-Boot from git, export ARCH=arm and CROSS_COMPILE=arm-linux-gnueabihf-
6. Make Defconfig: make vexpress_ca15_tc2_defconfig
7. Make U-Boot: make
8. Generate empty image file and mount it: truncate -s 100M image; mkfs.ext4 image; mount -o loop image /mnt
9. Copy zImage and DTB to image: cp arch/arm/boot/zImage /mnt ; cp arch/arm/boot/dts/vexpress-v2p-ca15_a7.dtb /mnt
10. Unmount Image: umount /mnt
11. Start u-boot in qemu: qemu-system-arm -m 1024M -M vexpress-a15 -cpu cortex-a15 -kernel u-boot -serial stdio -sd image => U-Boot comes up and I can hit a key to stop automount, ok so far
12. In u-boot, checking filesystem on image: ext4ls mmc 0:0 => I can see my zImage and my DTB file, ok so far
13. In u-boot, loading kernel: ext4load mmc 0:0 82008000 zImage => XXXX bytes read is shown, ok so far
14. In u-boot, loading DTB: ext4load mmc 0:0 85000000 vexpress-v2p-ca15_a7.dtb => YYYY bytes read, ok so far
15. In u-boot, boot: bootz 82008000 - 85000000 => 'Starting kernel ....' and 'Uncompressing kernel done' is shown and then nothing at all...
Cross-checks I have done right now:
- Booting kernel and DTB directly from qemu with 'qemu-system-arm -m 1024M -M vexpress-a15 -cpu cortex-a15 -kernel arch/arm/boot/zImage -dtb arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb -serial stdio' works, normal boot output is shown. Also the standard console device ttyAMA0 is available after mounting devtmpfs.
- Same setup with vexpress-a9 (uboot with vexpress_ca9x4_defconfig, linux with vexpress_defconfig and DTB vexpress-v2p-ca9.dtb. The kernel was loaded to 62008000 and the DTB to 65000000) worked, Normal boot output was shown.
What I don't understand right now is:
- Am I using the corrected DTB? vexpress-v2p-ca15-tc1.dtb or vexpress-v2p-ca15_a7.dtb ? Which is the right one?
- What are the addresses I need to load kernel and the DTB? In the working vexpress-a9 sample the kernel was loaded with a offset of 2008000h and the DTB with a offset of 5000000h to start of RAM at 60000000h. So I decided use the same offsets with the alternate start of RAM address of 8000000h of vexpress-a15, i.e. kernel at 82008000 and DTB at 85000000. Is this assumption correct?
- 'Starting kernel...' is a last message from u-boot and 'Uncompressing kernel done' the first from the kernels self extractor?
- Where in RAM is the zImage decompressed by u-boot bootz? Between start of RAM at 80000000h and kernels loadaddr at 82008000h?
- What are the differences between loading kernel and DTB by qemu directly and loading kernel and DTB indirectly via u-boot?
Thank you very very much for your replies in advance.
Greetings,
André
+++ Richard Wolf GmbH, Pforzheimer Strasse 32, 75438 Knittlingen Managing Directors: Juergen Pfab, Juergen Steinbeck. Trade Register: Mannheim HRB 510031 +++ Richard Wolf GmbH routinely monitors the content of e-mail sent and received via its network for the purposes of ensuring compliance with its policies and procedures. Richard Wolf GmbH is not responsible for any changes made to the message after it has been sent. Where opinions are expressed, they are not necessarily those of Richard Wolf GmbH. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended addressee, or the person responsible for delivering it to them, you may not copy, forward, disclose, or otherwise use it or any part of it in any way. To do so may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately. +++
On Tue, Feb 05, 2019 at 07:05:55PM +0100, Andre Wagner wrote:
Hi @all,
Hi Andre,
I'm trying to build a linux kernel as zImage and boot it with u-boot on a qemu vexpress-a15 machine. The host machine is a Ubuntu 18.04.
What I tried until now:
- Get Linux from git, export ARCH=arm and
CROSS_COMPILE=arm-linux-gnueabihf-
Make Defconfig: make vexpress_defconfig
Enable 'Early Printk' with make menuconfig
Make Kernel: make
Get U-Boot from git, export ARCH=arm and
CROSS_COMPILE=arm-linux-gnueabihf-
Make Defconfig: make vexpress_ca15_tc2_defconfig
Make U-Boot: make
Generate empty image file and mount it: truncate -s 100M image; mkfs.ext4
image; mount -o loop image /mnt
- Copy zImage and DTB to image: cp arch/arm/boot/zImage /mnt ; cp
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dtb /mnt
Unmount Image: umount /mnt
Start u-boot in qemu: qemu-system-arm -m 1024M -M vexpress-a15 -cpu
cortex-a15 -kernel u-boot -serial stdio -sd image => U-Boot comes up and I can hit a key to stop automount, ok so far
- In u-boot, checking filesystem on image: ext4ls mmc 0:0 => I can see my
zImage and my DTB file, ok so far
- In u-boot, loading kernel: ext4load mmc 0:0 82008000 zImage => XXXX
bytes read is shown, ok so far
- In u-boot, loading DTB: ext4load mmc 0:0 85000000
vexpress-v2p-ca15_a7.dtb => YYYY bytes read, ok so far
- In u-boot, boot: bootz 82008000 - 85000000 => 'Starting kernel ....' and
'Uncompressing kernel done' is shown and then nothing at all...
I think your problem is that you're putting the device tree too close to the kernel, so it might be trampled on by the kernel decompression.
Steps I suggest you try that worked in my environment:
1. set the bootargs variable in U-Boot to 'console=ttyAMA0 earlyprintk debug verbose' 2. Load the kernel at 0x80008000
Cross-checks I have done right now:
- Booting kernel and DTB directly from qemu with 'qemu-system-arm -m 1024M
-M vexpress-a15 -cpu cortex-a15 -kernel arch/arm/boot/zImage -dtb arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb -serial stdio' works, normal boot output is shown. Also the standard console device ttyAMA0 is available after mounting devtmpfs.
- Same setup with vexpress-a9 (uboot with vexpress_ca9x4_defconfig, linux
with vexpress_defconfig and DTB vexpress-v2p-ca9.dtb. The kernel was loaded to 62008000 and the DTB to 65000000) worked, Normal boot output was shown.
What I don't understand right now is:
- Am I using the corrected DTB? vexpress-v2p-ca15-tc1.dtb or
vexpress-v2p-ca15_a7.dtb ? Which is the right one?
None is the right one, as they are DTBs for actual hardware that QEMU doesn't emulate correctly with your parameters. However, the emulation should be close enough to allow you to boot the kernel.
- What are the addresses I need to load kernel and the DTB? In the working
vexpress-a9 sample the kernel was loaded with a offset of 2008000h and the DTB with a offset of 5000000h to start of RAM at 60000000h. So I decided use the same offsets with the alternate start of RAM address of 8000000h of vexpress-a15, i.e. kernel at 82008000 and DTB at 85000000. Is this assumption correct?
No, the offset should be 0x8000 from the start of your memory, because the kernel for arm arch expects to be loaded at the beginning of the RAM. For DTB it doesn't matter (other than probably faster if it is 32bit aligned).
- 'Starting kernel...' is a last message from u-boot and 'Uncompressing
kernel done' the first from the kernels self extractor?
Correct.
- Where in RAM is the zImage decompressed by u-boot bootz? Between start of
RAM at 80000000h and kernels loadaddr at 82008000h?
I might be wrong but I believe it decompresses in memory *after* the kernel image, not before (otherwise the decompression might generate an image that overwrites the start of the kernel, which is where the decompressor lives).
- What are the differences between loading kernel and DTB by qemu directly
and loading kernel and DTB indirectly via u-boot?
Placement in memory of the kernel image :)
Best regards, Liviu
Thank you very very much for your replies in advance.
Greetings,
André
+++ Richard Wolf GmbH, Pforzheimer Strasse 32, 75438 Knittlingen Managing Directors: Juergen Pfab, Juergen Steinbeck. Trade Register: Mannheim HRB 510031 +++ Richard Wolf GmbH routinely monitors the content of e-mail sent and received via its network for the purposes of ensuring compliance with its policies and procedures. Richard Wolf GmbH is not responsible for any changes made to the message after it has been sent. Where opinions are expressed, they are not necessarily those of Richard Wolf GmbH. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended addressee, or the person responsible for delivering it to them, you may not copy, forward, disclose, or otherwise use it or any part of it in any way. To do so may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately. +++ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Hi Liviu,
thank you very much for your reply. A very good hint was that I need to set the extra kernel parameter earlyprintk for showing further debug output. I expected that setting the 'Early Printk' option in Kconfig is enough. After adding this kernel parameter i can see the kernel boot messages, but the kernel stucks now at 'smp: Bringing up secondary CPUs ...'. As a cross-check I booted the kernel directly on the qemu vexpress machine and there are also error messages at the SMP step shown, but the boot process continues. In the running system I can only see one CPU, so SMP does not work at all. So I disabled all CPUs expect the first one in the device tree, so my boot procedure in u-boot is as following:
1. Set boot args: setenv bootargs console=ttyAMA0 earlyprintk debug verbose
2. Load the zImage at start of RAM + 8000h offset: ext4load mmc 0:1 80008000 zImage
3. Load Device Tree: ext4load mmc 0:1 8a000000 vexpress-v2p-ca15-tc1.dtb
4. Init fdt subsystem: fdt addr 8a000000
5. Deactivate second CPU: fdt rm /cpus/cpu@1
6. Boot with bootz command: bootz 80008000 - 8a000000
7. In the SMP boot step only one CPU it recognized, the boot process continues
8. Now the boot process stucks at 'DMA: preallocated 256 KiB pool for atomic coherent allocations'
Further I found that:
1. The space between kernel loadaddr and DTB load address of 2ff8000h Bytes (about 50MB) was big enough, since there is no difference if I use the old (85000000h) or the new DTB loadaddr (8a000000h). Just for being on the sure site I continue using 8a000000 for DTB load address
2. All vexpress DTBs contain a ARM HBI number with seems to be a identificator for the ARM board. The ARM HBI of vexpress-v2p-ca15-tc1.dtb fits the expected ARM HBI of the qemu vexpress-a15, the vexpress-v2p-ca15_a7.dtb fits not. So I keep using the vexpress-v2p-ca15-tc1.dtb device tree
3. I recompiled the vexpress-v2p-ca15-tc1.dtb device tree without the /cpus/cpu@1 and let it run directly by qemu. The boot process succeeds. The next message after 'DMA: preallocated 256 KiB pool for atomic coherent allocations' is in this case 'cpuidle: using governor ladder'
4. I didn't mentioned the versions I'm using: It's qemu version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.8), Linux version 5.0.0-rc5 and U-Boot version 2019.01-00523-ge5fd39c886. I'm aware that these are development versions.
At this point I assume that kernel and DTB are loaded correctly, but I haven't any idea what influence u-boot can have initializing DMA and/or cpuidle. Any suggestions?
P.S. I will continue testing other stable vanilla kernels.
P.S. I attached the boot logs: The file boot_qemu_only is the successful boot with qemu only via kernel and dtb option, the file boot_qemu_uboot is the boot with qemu + u-boot.
Thanks for your help.
Greetings,
André
On 06.02.19 17:58, Liviu Dudau wrote:
On Tue, Feb 05, 2019 at 07:05:55PM +0100, Andre Wagner wrote:
Hi @all,
Hi Andre,
I'm trying to build a linux kernel as zImage and boot it with u-boot on a qemu vexpress-a15 machine. The host machine is a Ubuntu 18.04.
What I tried until now:
- Get Linux from git, export ARCH=arm and
CROSS_COMPILE=arm-linux-gnueabihf-
Make Defconfig: make vexpress_defconfig
Enable 'Early Printk' with make menuconfig
Make Kernel: make
Get U-Boot from git, export ARCH=arm and
CROSS_COMPILE=arm-linux-gnueabihf-
Make Defconfig: make vexpress_ca15_tc2_defconfig
Make U-Boot: make
Generate empty image file and mount it: truncate -s 100M image; mkfs.ext4
image; mount -o loop image /mnt
- Copy zImage and DTB to image: cp arch/arm/boot/zImage /mnt ; cp
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dtb /mnt
Unmount Image: umount /mnt
Start u-boot in qemu: qemu-system-arm -m 1024M -M vexpress-a15 -cpu
cortex-a15 -kernel u-boot -serial stdio -sd image => U-Boot comes up and I can hit a key to stop automount, ok so far
- In u-boot, checking filesystem on image: ext4ls mmc 0:0 => I can see my
zImage and my DTB file, ok so far
- In u-boot, loading kernel: ext4load mmc 0:0 82008000 zImage => XXXX
bytes read is shown, ok so far
- In u-boot, loading DTB: ext4load mmc 0:0 85000000
vexpress-v2p-ca15_a7.dtb => YYYY bytes read, ok so far
- In u-boot, boot: bootz 82008000 - 85000000 => 'Starting kernel ....' and
'Uncompressing kernel done' is shown and then nothing at all...
I think your problem is that you're putting the device tree too close to the kernel, so it might be trampled on by the kernel decompression.
Steps I suggest you try that worked in my environment:
- set the bootargs variable in U-Boot to 'console=ttyAMA0 earlyprintk debug verbose'
- Load the kernel at 0x80008000
Cross-checks I have done right now:
- Booting kernel and DTB directly from qemu with 'qemu-system-arm -m 1024M
-M vexpress-a15 -cpu cortex-a15 -kernel arch/arm/boot/zImage -dtb arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb -serial stdio' works, normal boot output is shown. Also the standard console device ttyAMA0 is available after mounting devtmpfs.
- Same setup with vexpress-a9 (uboot with vexpress_ca9x4_defconfig, linux
with vexpress_defconfig and DTB vexpress-v2p-ca9.dtb. The kernel was loaded to 62008000 and the DTB to 65000000) worked, Normal boot output was shown.
What I don't understand right now is:
- Am I using the corrected DTB? vexpress-v2p-ca15-tc1.dtb or
vexpress-v2p-ca15_a7.dtb ? Which is the right one?
None is the right one, as they are DTBs for actual hardware that QEMU doesn't emulate correctly with your parameters. However, the emulation should be close enough to allow you to boot the kernel.
- What are the addresses I need to load kernel and the DTB? In the working
vexpress-a9 sample the kernel was loaded with a offset of 2008000h and the DTB with a offset of 5000000h to start of RAM at 60000000h. So I decided use the same offsets with the alternate start of RAM address of 8000000h of vexpress-a15, i.e. kernel at 82008000 and DTB at 85000000. Is this assumption correct?
No, the offset should be 0x8000 from the start of your memory, because the kernel for arm arch expects to be loaded at the beginning of the RAM. For DTB it doesn't matter (other than probably faster if it is 32bit aligned).
- 'Starting kernel...' is a last message from u-boot and 'Uncompressing
kernel done' the first from the kernels self extractor?
Correct.
- Where in RAM is the zImage decompressed by u-boot bootz? Between start of
RAM at 80000000h and kernels loadaddr at 82008000h?
I might be wrong but I believe it decompresses in memory *after* the kernel image, not before (otherwise the decompression might generate an image that overwrites the start of the kernel, which is where the decompressor lives).
- What are the differences between loading kernel and DTB by qemu directly
and loading kernel and DTB indirectly via u-boot?
Placement in memory of the kernel image :)
Best regards, Liviu
Thank you very very much for your replies in advance.
Greetings,
André
+++ Richard Wolf GmbH, Pforzheimer Strasse 32, 75438 Knittlingen Managing Directors: Juergen Pfab, Juergen Steinbeck. Trade Register: Mannheim HRB 510031 +++ Richard Wolf GmbH routinely monitors the content of e-mail sent and received via its network for the purposes of ensuring compliance with its policies and procedures. Richard Wolf GmbH is not responsible for any changes made to the message after it has been sent. Where opinions are expressed, they are not necessarily those of Richard Wolf GmbH. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended addressee, or the person responsible for delivering it to them, you may not copy, forward, disclose, or otherwise use it or any part of it in any way. To do so may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately. +++ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
+++ Richard Wolf GmbH, Pforzheimer Strasse 32, 75438 Knittlingen Managing Directors: Juergen Pfab, Juergen Steinbeck. Trade Register: Mannheim HRB 510031 +++ Richard Wolf GmbH routinely monitors the content of e-mail sent and received via its network for the purposes of ensuring compliance with its policies and procedures. Richard Wolf GmbH is not responsible for any changes made to the message after it has been sent. Where opinions are expressed, they are not necessarily those of Richard Wolf GmbH. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended addressee, or the person responsible for delivering it to them, you may not copy, forward, disclose, or otherwise use it or any part of it in any way. To do so may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately. +++
On Thu, Feb 07, 2019 at 01:55:00PM +0100, Andre Wagner wrote:
Hi Liviu,
thank you very much for your reply. A very good hint was that I need to set the extra kernel parameter earlyprintk for showing further debug output. I expected that setting the 'Early Printk' option in Kconfig is enough. After adding this kernel parameter i can see the kernel boot messages, but the kernel stucks now at 'smp: Bringing up secondary CPUs ...'. As a cross-check I booted the kernel directly on the qemu vexpress machine and there are also error messages at the SMP step shown, but the boot process continues. In the running system I can only see one CPU, so SMP does not work at all. So I disabled all CPUs expect the first one in the device tree, so my boot procedure in u-boot is as following:
- Set boot args: setenv bootargs console=ttyAMA0 earlyprintk debug verbose
May I suggest you use
$ setenv bootargs 'console=ttyAMA0 earlyprintk debug verbose'
i.e. put single quotes around the value of the variable.
- Load the zImage at start of RAM + 8000h offset: ext4load mmc 0:1 80008000
zImage
Load Device Tree: ext4load mmc 0:1 8a000000 vexpress-v2p-ca15-tc1.dtb
Init fdt subsystem: fdt addr 8a000000
In my test with mainline kernel and U-Boot from yesterday I didn't had to do this, because ....
- Deactivate second CPU: fdt rm /cpus/cpu@1
I didn't have to disable the other CPUs either.
Boot with bootz command: bootz 80008000 - 8a000000
In the SMP boot step only one CPU it recognized, the boot process
continues
- Now the boot process stucks at 'DMA: preallocated 256 KiB pool for atomic
coherent allocations'
Further I found that:
- The space between kernel loadaddr and DTB load address of 2ff8000h Bytes
(about 50MB) was big enough, since there is no difference if I use the old (85000000h) or the new DTB loadaddr (8a000000h). Just for being on the sure site I continue using 8a000000 for DTB load address
- All vexpress DTBs contain a ARM HBI number with seems to be a
identificator for the ARM board. The ARM HBI of vexpress-v2p-ca15-tc1.dtb fits the expected ARM HBI of the qemu vexpress-a15, the vexpress-v2p-ca15_a7.dtb fits not. So I keep using the vexpress-v2p-ca15-tc1.dtb device tree
Like I've said, those dtbs are for real hardware CoreTiles placed inside the Versatile Express motherboard. I don't know (or remember exactly) if qemu emulates all the aspects, but it should not matter much.
- I recompiled the vexpress-v2p-ca15-tc1.dtb device tree without the
/cpus/cpu@1 and let it run directly by qemu. The boot process succeeds. The next message after 'DMA: preallocated 256 KiB pool for atomic coherent allocations' is in this case 'cpuidle: using governor ladder'
- I didn't mentioned the versions I'm using: It's qemu version
2.11.1(Debian 1:2.11+dfsg-1ubuntu7.8), Linux version 5.0.0-rc5 and U-Boot version 2019.01-00523-ge5fd39c886. I'm aware that these are development versions.
My versions are qemu 3.1.0, U-Boot 2019.01-00058-g23b00a07fc-dirty, Linux version 5.0.0-rc5+. Attached is a log of my session.
Best regards, Liviu
At this point I assume that kernel and DTB are loaded correctly, but I haven't any idea what influence u-boot can have initializing DMA and/or cpuidle. Any suggestions?
P.S. I will continue testing other stable vanilla kernels.
P.S. I attached the boot logs: The file boot_qemu_only is the successful boot with qemu only via kernel and dtb option, the file boot_qemu_uboot is the boot with qemu + u-boot.
Thanks for your help.
Greetings,
André
On 06.02.19 17:58, Liviu Dudau wrote:
On Tue, Feb 05, 2019 at 07:05:55PM +0100, Andre Wagner wrote:
Hi @all,
Hi Andre,
I'm trying to build a linux kernel as zImage and boot it with u-boot on a qemu vexpress-a15 machine. The host machine is a Ubuntu 18.04.
What I tried until now:
- Get Linux from git, export ARCH=arm and
CROSS_COMPILE=arm-linux-gnueabihf-
Make Defconfig: make vexpress_defconfig
Enable 'Early Printk' with make menuconfig
Make Kernel: make
Get U-Boot from git, export ARCH=arm and
CROSS_COMPILE=arm-linux-gnueabihf-
Make Defconfig: make vexpress_ca15_tc2_defconfig
Make U-Boot: make
Generate empty image file and mount it: truncate -s 100M image; mkfs.ext4
image; mount -o loop image /mnt
- Copy zImage and DTB to image: cp arch/arm/boot/zImage /mnt ; cp
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dtb /mnt
Unmount Image: umount /mnt
Start u-boot in qemu: qemu-system-arm -m 1024M -M vexpress-a15 -cpu
cortex-a15 -kernel u-boot -serial stdio -sd image => U-Boot comes up and I can hit a key to stop automount, ok so far
- In u-boot, checking filesystem on image: ext4ls mmc 0:0 => I can see my
zImage and my DTB file, ok so far
- In u-boot, loading kernel: ext4load mmc 0:0 82008000 zImage => XXXX
bytes read is shown, ok so far
- In u-boot, loading DTB: ext4load mmc 0:0 85000000
vexpress-v2p-ca15_a7.dtb => YYYY bytes read, ok so far
- In u-boot, boot: bootz 82008000 - 85000000 => 'Starting kernel ....' and
'Uncompressing kernel done' is shown and then nothing at all...
I think your problem is that you're putting the device tree too close to the kernel, so it might be trampled on by the kernel decompression.
Steps I suggest you try that worked in my environment:
- set the bootargs variable in U-Boot to 'console=ttyAMA0 earlyprintk debug verbose'
- Load the kernel at 0x80008000
Cross-checks I have done right now:
- Booting kernel and DTB directly from qemu with 'qemu-system-arm -m 1024M
-M vexpress-a15 -cpu cortex-a15 -kernel arch/arm/boot/zImage -dtb arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb -serial stdio' works, normal boot output is shown. Also the standard console device ttyAMA0 is available after mounting devtmpfs.
- Same setup with vexpress-a9 (uboot with vexpress_ca9x4_defconfig, linux
with vexpress_defconfig and DTB vexpress-v2p-ca9.dtb. The kernel was loaded to 62008000 and the DTB to 65000000) worked, Normal boot output was shown.
What I don't understand right now is:
- Am I using the corrected DTB? vexpress-v2p-ca15-tc1.dtb or
vexpress-v2p-ca15_a7.dtb ? Which is the right one?
None is the right one, as they are DTBs for actual hardware that QEMU doesn't emulate correctly with your parameters. However, the emulation should be close enough to allow you to boot the kernel.
- What are the addresses I need to load kernel and the DTB? In the working
vexpress-a9 sample the kernel was loaded with a offset of 2008000h and the DTB with a offset of 5000000h to start of RAM at 60000000h. So I decided use the same offsets with the alternate start of RAM address of 8000000h of vexpress-a15, i.e. kernel at 82008000 and DTB at 85000000. Is this assumption correct?
No, the offset should be 0x8000 from the start of your memory, because the kernel for arm arch expects to be loaded at the beginning of the RAM. For DTB it doesn't matter (other than probably faster if it is 32bit aligned).
- 'Starting kernel...' is a last message from u-boot and 'Uncompressing
kernel done' the first from the kernels self extractor?
Correct.
- Where in RAM is the zImage decompressed by u-boot bootz? Between start of
RAM at 80000000h and kernels loadaddr at 82008000h?
I might be wrong but I believe it decompresses in memory *after* the kernel image, not before (otherwise the decompression might generate an image that overwrites the start of the kernel, which is where the decompressor lives).
- What are the differences between loading kernel and DTB by qemu directly
and loading kernel and DTB indirectly via u-boot?
Placement in memory of the kernel image :)
Best regards, Liviu
Thank you very very much for your replies in advance.
Greetings,
André
+++ Richard Wolf GmbH, Pforzheimer Strasse 32, 75438 Knittlingen Managing Directors: Juergen Pfab, Juergen Steinbeck. Trade Register: Mannheim HRB 510031 +++ Richard Wolf GmbH routinely monitors the content of e-mail sent and received via its network for the purposes of ensuring compliance with its policies and procedures. Richard Wolf GmbH is not responsible for any changes made to the message after it has been sent. Where opinions are expressed, they are not necessarily those of Richard Wolf GmbH. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended addressee, or the person responsible for delivering it to them, you may not copy, forward, disclose, or otherwise use it or any part of it in any way. To do so may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately. +++ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
+++ Richard Wolf GmbH, Pforzheimer Strasse 32, 75438 Knittlingen Managing Directors: Juergen Pfab, Juergen Steinbeck. Trade Register: Mannheim HRB 510031 +++ Richard Wolf GmbH routinely monitors the content of e-mail sent and received via its network for the purposes of ensuring compliance with its policies and procedures. Richard Wolf GmbH is not responsible for any changes made to the message after it has been sent. Where opinions are expressed, they are not necessarily those of Richard Wolf GmbH. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended addressee, or the person responsible for delivering it to them, you may not copy, forward, disclose, or otherwise use it or any part of it in any way. To do so may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately. +++
Booting Linux on physical CPU 0x0 Linux version 5.0.0-rc5 (wagner@wagner-Precision-3510) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04)) #1 SMP Tue Feb 5 17:09:25 CET 2019 CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d CPU: div instructions available: patching division code CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache OF: fdt: Machine model: V2P-CA15 Memory policy: Data cache writealloc Reserved memory: created DMA memory pool at 0x18000000, size 8 MiB OF: reserved mem: initialized node vram@18000000, compatible id shared-dma-pool cma: Reserved 16 MiB at 0xbf000000 random: get_random_bytes called from start_kernel+0x9c/0x458 with crng_init=0 percpu: Embedded 17 pages/cpu @(ptrval) s37196 r8192 d24244 u69632 Built 1 zonelists, mobility grouping on. Total pages: 260096 Kernel command line: root=/dev/mmcblk0p1 console=ttyAMA0,9600 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1012188K/1048576K available (7168K kernel code, 420K rwdata, 1572K rodata, 1024K init, 158K bss, 20004K reserved, 16384K cma-reserved) Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xffc00000 - 0xfff00000 (3072 kB) vmalloc : 0xc0800000 - 0xff800000 (1008 MB) lowmem : 0x80000000 - 0xc0000000 (1024 MB) modules : 0x7f000000 - 0x80000000 ( 16 MB) .text : 0x(ptrval) - 0x(ptrval) (8160 kB) .init : 0x(ptrval) - 0x(ptrval) (1024 kB) .data : 0x(ptrval) - 0x(ptrval) ( 421 kB) .bss : 0x(ptrval) - 0x(ptrval) ( 159 kB) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 rcu: Hierarchical RCU implementation. rcu: RCU event tracing is enabled. rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1. rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns Failed to initialize '/smb@8000000/motherboard/iofpga@3,00000000/timer@120000': -22 arch_timer: cp15 timer(s) running at 62.50MHz (virt). clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns Switching to timer-based delay loop, resolution 16ns Console: colour dummy device 80x30 Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=625000) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) CPU: Testing write buffer coherency: ok CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable /cpus/cpu@0 missing clock-frequency property CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 Setting up static identity map for 0x80100000 - 0x80100060 rcu: Hierarchical SRCU implementation. smp: Bringing up secondary CPUs ... smp: Brought up 1 node, 1 CPU SMP: Total of 1 processors activated (125.00 BogoMIPS). CPU: All CPU(s) started in SVC mode. devtmpfs: initialized VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0 clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns futex hash table entries: 256 (order: 2, 16384 bytes) NET: Registered protocol family 16 DMA: preallocated 256 KiB pool for atomic coherent allocations cpuidle: using governor ladder hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers. hw-breakpoint: maximum watchpoint size is 8 bytes. Serial: AMBA PL011 UART driver 1c090000.uart: ttyAMA0 at MMIO 0x1c090000 (irq = 33, base_baud = 0) is a PL011 rev1 printk: console [ttyAMA0] enabled 1c0a0000.uart: ttyAMA1 at MMIO 0x1c0a0000 (irq = 34, base_baud = 0) is a PL011 rev1 1c0b0000.uart: ttyAMA2 at MMIO 0x1c0b0000 (irq = 35, base_baud = 0) is a PL011 rev1 1c0c0000.uart: ttyAMA3 at MMIO 0x1c0c0000 (irq = 36, base_baud = 0) is a PL011 rev1 OF: amba_device_add() failed (-19) for /smb@8000000/motherboard/iofpga@3,00000000/wdt@f0000 OF: amba_device_add() failed (-19) for /memory-controller@2b0a0000 OF: amba_device_add() failed (-19) for /memory-controller@7ffd0000 OF: amba_device_add() failed (-19) for /dma@7ffb0000 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Advanced Linux Sound Architecture Driver Initialized. clocksource: Switched to clocksource arch_sys_counter NET: Registered protocol family 2 tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes) TCP established hash table entries: 8192 (order: 3, 32768 bytes) TCP bind hash table entries: 8192 (order: 4, 65536 bytes) TCP: Hash tables configured (established 8192 bind 8192) UDP hash table entries: 512 (order: 2, 16384 bytes) UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. hw perfevents: enabled with armv7_cortex_a15 PMU driver, 1 counters available workingset: timestamp_bits=30 max_order=18 bucket_order=0 squashfs: version 4.0 (2009/01/31) Phillip Lougher jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc. 9p: Installing v9fs 9p2000 file system support io scheduler mq-deadline registered io scheduler kyber registered drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram@18000000 drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111 drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD physmap-flash 8000000.flash: physmap platform flash device: [mem 0x08000000-0x0bffffff] 8000000.flash: Found 2 x16 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000000 Chip ID 0x000000 Intel/Sharp Extended Query Table at 0x0031 Using buffer write method physmap-flash 8000000.flash: physmap platform flash device: [mem 0x0c000000-0x0fffffff] 8000000.flash: Found 2 x16 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000000 Chip ID 0x000000 Intel/Sharp Extended Query Table at 0x0031 Using buffer write method Concatenating MTD devices: (0): "8000000.flash" (1): "8000000.flash" into device "8000000.flash" physmap-flash 14000000.psram: physmap platform flash device: [mem 0x14000000-0x15ffffff] libphy: Fixed MDIO Bus: probed smsc911x 1a000000.ethernet: Linked as a consumer to regulator.1 libphy: smsc911x-mdio: probed smsc911x 1a000000.ethernet eth0: MAC Address: 52:54:00:12:34:56 isp1760 1b000000.usb: bus width: 32, oc: digital isp1760 1b000000.usb: NXP ISP1760 USB Host Controller isp1760 1b000000.usb: new USB bus registered, assigned bus number 1 isp1760 1b000000.usb: Scratch test failed. isp1760 1b000000.usb: can't setup: -19 isp1760 1b000000.usb: USB bus 1 deregistered usbcore: registered new interface driver usb-storage rtc-pl031 1c170000.rtc: registered as rtc0 mmci-pl18x 1c050000.mmci: Got CD GPIO mmci-pl18x 1c050000.mmci: Got WP GPIO mmci-pl18x 1c050000.mmci: Linked as a consumer to regulator.1 mmci-pl18x 1c050000.mmci: mmc0: PL181 manf 41 rev0 at 0x1c050000 irq 29,30 (pio) ledtrig-cpu: registered to indicate activity on CPUs usbcore: registered new interface driver usbhid usbhid: USB HID core driver aaci-pl041 1c040000.aaci: ARM AC'97 Interface PL041 rev0 at 0x1c040000, irq 28 aaci-pl041 1c040000.aaci: FIFO 512 entries oprofile: using timer interrupt. NET: Registered protocol family 17 9pnet: Installing 9P2000 support Registering SWP/SWPB emulation handler input: AT Raw Set 2 keyboard as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:iofpga@3,00000000/1c060000.kmi/serio0/input/input0 mmc0: new SD card at address 4567 mmcblk0: mmc0:4567 QEMU! 1.00 GiB drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram@18000000 drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory Error: Driver 'vexpress-muxfpga' is already registered, aborting... drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111 drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD mmcblk0: p1 drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram@18000000 drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory Error: Driver 'vexpress-muxfpga' is already registered, aborting... drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111 drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram@18000000 drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory Error: Driver 'vexpress-muxfpga' is already registered, aborting... drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111 drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD rtc-pl031 1c170000.rtc: setting system clock to 2019-02-07T12:12:07 UTC (1549541527) ALSA device list: #0: ARM AC'97 Interface PL041 rev0 at 0x1c040000, irq 28 input: ImExPS/2 Generic Explorer Mouse as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:iofpga@3,00000000/1c070000.kmi/serio1/input/input2 drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram@18000000 drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory Error: Driver 'vexpress-muxfpga' is already registered, aborting... drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111 drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD
Booting Linux on physical CPU 0x0 Linux version 5.0.0-rc5 (wagner@wagner-Precision-3510) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04)) #1 SMP Tue Feb 5 17:09:25 CET 2019 CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d CPU: div instructions available: patching division code CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache OF: fdt: Machine model: V2P-CA15 printk: bootconsole [earlycon0] enabled Memory policy: Data cache writealloc Reserved memory: created DMA memory pool at 0x18000000, size 8 MiB OF: reserved mem: initialized node vram@18000000, compatible id shared-dma-pool cma: Reserved 16 MiB at 0xbf000000 On node 0 totalpages: 262144 Normal zone: 2048 pages used for memmap Normal zone: 0 pages reserved Normal zone: 262144 pages, LIFO batch:63 random: get_random_bytes called from start_kernel+0x9c/0x458 with crng_init=0 percpu: Embedded 17 pages/cpu @(ptrval) s37196 r8192 d24244 u69632 pcpu-alloc: s37196 r8192 d24244 u69632 alloc=17*4096 pcpu-alloc: [0] 0 Built 1 zonelists, mobility grouping on. Total pages: 260096 Kernel command line: console=ttyAMA0 earlyprintk debug verbose Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1012216K/1048576K available (7168K kernel code, 420K rwdata, 1572K rodata, 1024K init, 158K bss, 19976K reserved, 16384K cma-reserved) Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xffc00000 - 0xfff00000 (3072 kB) vmalloc : 0xc0800000 - 0xff800000 (1008 MB) lowmem : 0x80000000 - 0xc0000000 (1024 MB) modules : 0x7f000000 - 0x80000000 ( 16 MB) .text : 0x(ptrval) - 0x(ptrval) (8160 kB) .init : 0x(ptrval) - 0x(ptrval) (1024 kB) .data : 0x(ptrval) - 0x(ptrval) ( 421 kB) .bss : 0x(ptrval) - 0x(ptrval) ( 159 kB) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 rcu: Hierarchical RCU implementation. rcu: RCU event tracing is enabled. rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1. rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns Failed to initialize '/smb@8000000/motherboard/iofpga@3,00000000/timer@120000': -22 arch_timer: cp15 timer(s) running at 62.50MHz (virt). clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns Switching to timer-based delay loop, resolution 16ns Console: colour dummy device 80x30 Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=625000) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) CPU: Testing write buffer coherency: ok CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable /cpus/cpu@0 missing clock-frequency property CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 Setting up static identity map for 0x80100000 - 0x80100060 rcu: Hierarchical SRCU implementation. smp: Bringing up secondary CPUs ... smp: Brought up 1 node, 1 CPU SMP: Total of 1 processors activated (125.00 BogoMIPS). CPU: All CPU(s) started in SVC mode. devtmpfs: initialized VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0 clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns futex hash table entries: 256 (order: 2, 16384 bytes) NET: Registered protocol family 16 DMA: preallocated 256 KiB pool for atomic coherent allocations
Hi Liviu,
I got the qemu + uboot + zImage running now! The solution was to use qemu version 3.1 like you and not the ancient 2.11 version of Ubuntu 18.04. Thank you very much for your support. I was completely lost in the debugging of linux, qemu and u-boot...
Greetings,
André
On 07.02.19 15:40, Liviu Dudau wrote:
On Thu, Feb 07, 2019 at 01:55:00PM +0100, Andre Wagner wrote:
Hi Liviu,
thank you very much for your reply. A very good hint was that I need to set the extra kernel parameter earlyprintk for showing further debug output. I expected that setting the 'Early Printk' option in Kconfig is enough. After adding this kernel parameter i can see the kernel boot messages, but the kernel stucks now at 'smp: Bringing up secondary CPUs ...'. As a cross-check I booted the kernel directly on the qemu vexpress machine and there are also error messages at the SMP step shown, but the boot process continues. In the running system I can only see one CPU, so SMP does not work at all. So I disabled all CPUs expect the first one in the device tree, so my boot procedure in u-boot is as following:
- Set boot args: setenv bootargs console=ttyAMA0 earlyprintk debug verbose
May I suggest you use
$ setenv bootargs 'console=ttyAMA0 earlyprintk debug verbose'i.e. put single quotes around the value of the variable.
- Load the zImage at start of RAM + 8000h offset: ext4load mmc 0:1 80008000
zImage
Load Device Tree: ext4load mmc 0:1 8a000000 vexpress-v2p-ca15-tc1.dtb
Init fdt subsystem: fdt addr 8a000000
In my test with mainline kernel and U-Boot from yesterday I didn't had to do this, because ....
- Deactivate second CPU: fdt rm /cpus/cpu@1
I didn't have to disable the other CPUs either.
Boot with bootz command: bootz 80008000 - 8a000000
In the SMP boot step only one CPU it recognized, the boot process
continues
- Now the boot process stucks at 'DMA: preallocated 256 KiB pool for atomic
coherent allocations'
Further I found that:
- The space between kernel loadaddr and DTB load address of 2ff8000h Bytes
(about 50MB) was big enough, since there is no difference if I use the old (85000000h) or the new DTB loadaddr (8a000000h). Just for being on the sure site I continue using 8a000000 for DTB load address
- All vexpress DTBs contain a ARM HBI number with seems to be a
identificator for the ARM board. The ARM HBI of vexpress-v2p-ca15-tc1.dtb fits the expected ARM HBI of the qemu vexpress-a15, the vexpress-v2p-ca15_a7.dtb fits not. So I keep using the vexpress-v2p-ca15-tc1.dtb device tree
Like I've said, those dtbs are for real hardware CoreTiles placed inside the Versatile Express motherboard. I don't know (or remember exactly) if qemu emulates all the aspects, but it should not matter much.
- I recompiled the vexpress-v2p-ca15-tc1.dtb device tree without the
/cpus/cpu@1 and let it run directly by qemu. The boot process succeeds. The next message after 'DMA: preallocated 256 KiB pool for atomic coherent allocations' is in this case 'cpuidle: using governor ladder'
- I didn't mentioned the versions I'm using: It's qemu version
2.11.1(Debian 1:2.11+dfsg-1ubuntu7.8), Linux version 5.0.0-rc5 and U-Boot version 2019.01-00523-ge5fd39c886. I'm aware that these are development versions.
My versions are qemu 3.1.0, U-Boot 2019.01-00058-g23b00a07fc-dirty, Linux version 5.0.0-rc5+. Attached is a log of my session.
Best regards, Liviu
At this point I assume that kernel and DTB are loaded correctly, but I haven't any idea what influence u-boot can have initializing DMA and/or cpuidle. Any suggestions?
P.S. I will continue testing other stable vanilla kernels.
P.S. I attached the boot logs: The file boot_qemu_only is the successful boot with qemu only via kernel and dtb option, the file boot_qemu_uboot is the boot with qemu + u-boot.
Thanks for your help.
Greetings,
André
On 06.02.19 17:58, Liviu Dudau wrote:
On Tue, Feb 05, 2019 at 07:05:55PM +0100, Andre Wagner wrote:
Hi @all,
Hi Andre,
I'm trying to build a linux kernel as zImage and boot it with u-boot on a qemu vexpress-a15 machine. The host machine is a Ubuntu 18.04.
What I tried until now:
- Get Linux from git, export ARCH=arm and
CROSS_COMPILE=arm-linux-gnueabihf-
Make Defconfig: make vexpress_defconfig
Enable 'Early Printk' with make menuconfig
Make Kernel: make
Get U-Boot from git, export ARCH=arm and
CROSS_COMPILE=arm-linux-gnueabihf-
Make Defconfig: make vexpress_ca15_tc2_defconfig
Make U-Boot: make
Generate empty image file and mount it: truncate -s 100M image; mkfs.ext4
image; mount -o loop image /mnt
- Copy zImage and DTB to image: cp arch/arm/boot/zImage /mnt ; cp
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dtb /mnt
Unmount Image: umount /mnt
Start u-boot in qemu: qemu-system-arm -m 1024M -M vexpress-a15 -cpu
cortex-a15 -kernel u-boot -serial stdio -sd image => U-Boot comes up and I can hit a key to stop automount, ok so far
- In u-boot, checking filesystem on image: ext4ls mmc 0:0 => I can see my
zImage and my DTB file, ok so far
- In u-boot, loading kernel: ext4load mmc 0:0 82008000 zImage => XXXX
bytes read is shown, ok so far
- In u-boot, loading DTB: ext4load mmc 0:0 85000000
vexpress-v2p-ca15_a7.dtb => YYYY bytes read, ok so far
- In u-boot, boot: bootz 82008000 - 85000000 => 'Starting kernel ....' and
'Uncompressing kernel done' is shown and then nothing at all...
I think your problem is that you're putting the device tree too close to the kernel, so it might be trampled on by the kernel decompression.
Steps I suggest you try that worked in my environment:
1. set the bootargs variable in U-Boot to 'console=ttyAMA0 earlyprintk debug verbose' 2. Load the kernel at 0x80008000Cross-checks I have done right now:
- Booting kernel and DTB directly from qemu with 'qemu-system-arm -m 1024M
-M vexpress-a15 -cpu cortex-a15 -kernel arch/arm/boot/zImage -dtb arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb -serial stdio' works, normal boot output is shown. Also the standard console device ttyAMA0 is available after mounting devtmpfs.
- Same setup with vexpress-a9 (uboot with vexpress_ca9x4_defconfig, linux
with vexpress_defconfig and DTB vexpress-v2p-ca9.dtb. The kernel was loaded to 62008000 and the DTB to 65000000) worked, Normal boot output was shown.
What I don't understand right now is:
- Am I using the corrected DTB? vexpress-v2p-ca15-tc1.dtb or
vexpress-v2p-ca15_a7.dtb ? Which is the right one?
None is the right one, as they are DTBs for actual hardware that QEMU doesn't emulate correctly with your parameters. However, the emulation should be close enough to allow you to boot the kernel.
- What are the addresses I need to load kernel and the DTB? In the working
vexpress-a9 sample the kernel was loaded with a offset of 2008000h and the DTB with a offset of 5000000h to start of RAM at 60000000h. So I decided use the same offsets with the alternate start of RAM address of 8000000h of vexpress-a15, i.e. kernel at 82008000 and DTB at 85000000. Is this assumption correct?
No, the offset should be 0x8000 from the start of your memory, because the kernel for arm arch expects to be loaded at the beginning of the RAM. For DTB it doesn't matter (other than probably faster if it is 32bit aligned).
- 'Starting kernel...' is a last message from u-boot and 'Uncompressing
kernel done' the first from the kernels self extractor?
Correct.
- Where in RAM is the zImage decompressed by u-boot bootz? Between start of
RAM at 80000000h and kernels loadaddr at 82008000h?
I might be wrong but I believe it decompresses in memory *after* the kernel image, not before (otherwise the decompression might generate an image that overwrites the start of the kernel, which is where the decompressor lives).
- What are the differences between loading kernel and DTB by qemu directly
and loading kernel and DTB indirectly via u-boot?
Placement in memory of the kernel image :)
Best regards, Liviu
Thank you very very much for your replies in advance.
Greetings,
André
+++ Richard Wolf GmbH, Pforzheimer Strasse 32, 75438 Knittlingen Managing Directors: Juergen Pfab, Juergen Steinbeck. Trade Register: Mannheim HRB 510031 +++ Richard Wolf GmbH routinely monitors the content of e-mail sent and received via its network for the purposes of ensuring compliance with its policies and procedures. Richard Wolf GmbH is not responsible for any changes made to the message after it has been sent. Where opinions are expressed, they are not necessarily those of Richard Wolf GmbH. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended addressee, or the person responsible for delivering it to them, you may not copy, forward, disclose, or otherwise use it or any part of it in any way. To do so may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately. +++ _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
+++ Richard Wolf GmbH, Pforzheimer Strasse 32, 75438 Knittlingen Managing Directors: Juergen Pfab, Juergen Steinbeck. Trade Register: Mannheim HRB 510031 +++ Richard Wolf GmbH routinely monitors the content of e-mail sent and received via its network for the purposes of ensuring compliance with its policies and procedures. Richard Wolf GmbH is not responsible for any changes made to the message after it has been sent. Where opinions are expressed, they are not necessarily those of Richard Wolf GmbH. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended addressee, or the person responsible for delivering it to them, you may not copy, forward, disclose, or otherwise use it or any part of it in any way. To do so may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately. +++ Booting Linux on physical CPU 0x0 Linux version 5.0.0-rc5 (wagner@wagner-Precision-3510) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04)) #1 SMP Tue Feb 5 17:09:25 CET 2019 CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d CPU: div instructions available: patching division code CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache OF: fdt: Machine model: V2P-CA15 Memory policy: Data cache writealloc Reserved memory: created DMA memory pool at 0x18000000, size 8 MiB OF: reserved mem: initialized node vram@18000000, compatible id shared-dma-pool cma: Reserved 16 MiB at 0xbf000000 random: get_random_bytes called from start_kernel+0x9c/0x458 with crng_init=0 percpu: Embedded 17 pages/cpu @(ptrval) s37196 r8192 d24244 u69632 Built 1 zonelists, mobility grouping on. Total pages: 260096 Kernel command line: root=/dev/mmcblk0p1 console=ttyAMA0,9600 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1012188K/1048576K available (7168K kernel code, 420K rwdata, 1572K rodata, 1024K init, 158K bss, 20004K reserved, 16384K cma-reserved) Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xffc00000 - 0xfff00000 (3072 kB) vmalloc : 0xc0800000 - 0xff800000 (1008 MB) lowmem : 0x80000000 - 0xc0000000 (1024 MB) modules : 0x7f000000 - 0x80000000 ( 16 MB) .text : 0x(ptrval) - 0x(ptrval) (8160 kB) .init : 0x(ptrval) - 0x(ptrval) (1024 kB) .data : 0x(ptrval) - 0x(ptrval) ( 421 kB) .bss : 0x(ptrval) - 0x(ptrval) ( 159 kB) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 rcu: Hierarchical RCU implementation. rcu: RCU event tracing is enabled. rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1. rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns Failed to initialize '/smb@8000000/motherboard/iofpga@3,00000000/timer@120000': -22 arch_timer: cp15 timer(s) running at 62.50MHz (virt). clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns Switching to timer-based delay loop, resolution 16ns Console: colour dummy device 80x30 Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=625000) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) CPU: Testing write buffer coherency: ok CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable /cpus/cpu@0 missing clock-frequency property CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 Setting up static identity map for 0x80100000 - 0x80100060 rcu: Hierarchical SRCU implementation. smp: Bringing up secondary CPUs ... smp: Brought up 1 node, 1 CPU SMP: Total of 1 processors activated (125.00 BogoMIPS). CPU: All CPU(s) started in SVC mode. devtmpfs: initialized VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0 clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns futex hash table entries: 256 (order: 2, 16384 bytes) NET: Registered protocol family 16 DMA: preallocated 256 KiB pool for atomic coherent allocations cpuidle: using governor ladder hw-breakpoint: found 5 (+1 reserved) breakpoint and 4 watchpoint registers. hw-breakpoint: maximum watchpoint size is 8 bytes. Serial: AMBA PL011 UART driver 1c090000.uart: ttyAMA0 at MMIO 0x1c090000 (irq = 33, base_baud = 0) is a PL011 rev1 printk: console [ttyAMA0] enabled 1c0a0000.uart: ttyAMA1 at MMIO 0x1c0a0000 (irq = 34, base_baud = 0) is a PL011 rev1 1c0b0000.uart: ttyAMA2 at MMIO 0x1c0b0000 (irq = 35, base_baud = 0) is a PL011 rev1 1c0c0000.uart: ttyAMA3 at MMIO 0x1c0c0000 (irq = 36, base_baud = 0) is a PL011 rev1 OF: amba_device_add() failed (-19) for /smb@8000000/motherboard/iofpga@3,00000000/wdt@f0000 OF: amba_device_add() failed (-19) for /memory-controller@2b0a0000 OF: amba_device_add() failed (-19) for /memory-controller@7ffd0000 OF: amba_device_add() failed (-19) for /dma@7ffb0000 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Advanced Linux Sound Architecture Driver Initialized. clocksource: Switched to clocksource arch_sys_counter NET: Registered protocol family 2 tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes) TCP established hash table entries: 8192 (order: 3, 32768 bytes) TCP bind hash table entries: 8192 (order: 4, 65536 bytes) TCP: Hash tables configured (established 8192 bind 8192) UDP hash table entries: 512 (order: 2, 16384 bytes) UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. hw perfevents: enabled with armv7_cortex_a15 PMU driver, 1 counters available workingset: timestamp_bits=30 max_order=18 bucket_order=0 squashfs: version 4.0 (2009/01/31) Phillip Lougher jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc. 9p: Installing v9fs 9p2000 file system support io scheduler mq-deadline registered io scheduler kyber registered drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram@18000000 drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111 drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD physmap-flash 8000000.flash: physmap platform flash device: [mem 0x08000000-0x0bffffff] 8000000.flash: Found 2 x16 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000000 Chip ID 0x000000 Intel/Sharp Extended Query Table at 0x0031 Using buffer write method physmap-flash 8000000.flash: physmap platform flash device: [mem 0x0c000000-0x0fffffff] 8000000.flash: Found 2 x16 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000000 Chip ID 0x000000 Intel/Sharp Extended Query Table at 0x0031 Using buffer write method Concatenating MTD devices: (0): "8000000.flash" (1): "8000000.flash" into device "8000000.flash" physmap-flash 14000000.psram: physmap platform flash device: [mem 0x14000000-0x15ffffff] libphy: Fixed MDIO Bus: probed smsc911x 1a000000.ethernet: Linked as a consumer to regulator.1 libphy: smsc911x-mdio: probed smsc911x 1a000000.ethernet eth0: MAC Address: 52:54:00:12:34:56 isp1760 1b000000.usb: bus width: 32, oc: digital isp1760 1b000000.usb: NXP ISP1760 USB Host Controller isp1760 1b000000.usb: new USB bus registered, assigned bus number 1 isp1760 1b000000.usb: Scratch test failed. isp1760 1b000000.usb: can't setup: -19 isp1760 1b000000.usb: USB bus 1 deregistered usbcore: registered new interface driver usb-storage rtc-pl031 1c170000.rtc: registered as rtc0 mmci-pl18x 1c050000.mmci: Got CD GPIO mmci-pl18x 1c050000.mmci: Got WP GPIO mmci-pl18x 1c050000.mmci: Linked as a consumer to regulator.1 mmci-pl18x 1c050000.mmci: mmc0: PL181 manf 41 rev0 at 0x1c050000 irq 29,30 (pio) ledtrig-cpu: registered to indicate activity on CPUs usbcore: registered new interface driver usbhid usbhid: USB HID core driver aaci-pl041 1c040000.aaci: ARM AC'97 Interface PL041 rev0 at 0x1c040000, irq 28 aaci-pl041 1c040000.aaci: FIFO 512 entries oprofile: using timer interrupt. NET: Registered protocol family 17 9pnet: Installing 9P2000 support Registering SWP/SWPB emulation handler input: AT Raw Set 2 keyboard as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:iofpga@3,00000000/1c060000.kmi/serio0/input/input0 mmc0: new SD card at address 4567 mmcblk0: mmc0:4567 QEMU! 1.00 GiB drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram@18000000 drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory Error: Driver 'vexpress-muxfpga' is already registered, aborting... drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111 drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD mmcblk0: p1 drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram@18000000 drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory Error: Driver 'vexpress-muxfpga' is already registered, aborting... drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111 drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram@18000000 drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory Error: Driver 'vexpress-muxfpga' is already registered, aborting... drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111 drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD rtc-pl031 1c170000.rtc: setting system clock to 2019-02-07T12:12:07 UTC (1549541527) ALSA device list: #0: ARM AC'97 Interface PL041 rev0 at 0x1c040000, irq 28 input: ImExPS/2 Generic Explorer Mouse as /devices/platform/smb@8000000/smb@8000000:motherboard/smb@8000000:motherboard:iofpga@3,00000000/1c070000.kmi/serio1/input/input2 drm-clcd-pl111 1c1f0000.clcd: assigned reserved memory node vram@18000000 drm-clcd-pl111 1c1f0000.clcd: using device-specific reserved memory Error: Driver 'vexpress-muxfpga' is already registered, aborting... drm-clcd-pl111 1c1f0000.clcd: initializing Versatile Express PL111 drm-clcd-pl111 1c1f0000.clcd: DVI muxed to motherboard CLCD
Booting Linux on physical CPU 0x0 Linux version 5.0.0-rc5 (wagner@wagner-Precision-3510) (gcc version 7.3.0 (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04)) #1 SMP Tue Feb 5 17:09:25 CET 2019 CPU: ARMv7 Processor [412fc0f1] revision 1 (ARMv7), cr=10c5387d CPU: div instructions available: patching division code CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache OF: fdt: Machine model: V2P-CA15 printk: bootconsole [earlycon0] enabled Memory policy: Data cache writealloc Reserved memory: created DMA memory pool at 0x18000000, size 8 MiB OF: reserved mem: initialized node vram@18000000, compatible id shared-dma-pool cma: Reserved 16 MiB at 0xbf000000 On node 0 totalpages: 262144 Normal zone: 2048 pages used for memmap Normal zone: 0 pages reserved Normal zone: 262144 pages, LIFO batch:63 random: get_random_bytes called from start_kernel+0x9c/0x458 with crng_init=0 percpu: Embedded 17 pages/cpu @(ptrval) s37196 r8192 d24244 u69632 pcpu-alloc: s37196 r8192 d24244 u69632 alloc=17*4096 pcpu-alloc: [0] 0 Built 1 zonelists, mobility grouping on. Total pages: 260096 Kernel command line: console=ttyAMA0 earlyprintk debug verbose Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1012216K/1048576K available (7168K kernel code, 420K rwdata, 1572K rodata, 1024K init, 158K bss, 19976K reserved, 16384K cma-reserved) Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xffc00000 - 0xfff00000 (3072 kB) vmalloc : 0xc0800000 - 0xff800000 (1008 MB) lowmem : 0x80000000 - 0xc0000000 (1024 MB) modules : 0x7f000000 - 0x80000000 ( 16 MB) .text : 0x(ptrval) - 0x(ptrval) (8160 kB) .init : 0x(ptrval) - 0x(ptrval) (1024 kB) .data : 0x(ptrval) - 0x(ptrval) ( 421 kB) .bss : 0x(ptrval) - 0x(ptrval) ( 159 kB) SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 rcu: Hierarchical RCU implementation. rcu: RCU event tracing is enabled. rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1. rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns Failed to initialize '/smb@8000000/motherboard/iofpga@3,00000000/timer@120000': -22 arch_timer: cp15 timer(s) running at 62.50MHz (virt). clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns Switching to timer-based delay loop, resolution 16ns Console: colour dummy device 80x30 Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=625000) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) CPU: Testing write buffer coherency: ok CPU0: Spectre v2: firmware did not set auxiliary control register IBE bit, system vulnerable /cpus/cpu@0 missing clock-frequency property CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 Setting up static identity map for 0x80100000 - 0x80100060 rcu: Hierarchical SRCU implementation. smp: Bringing up secondary CPUs ... smp: Brought up 1 node, 1 CPU SMP: Total of 1 processors activated (125.00 BogoMIPS). CPU: All CPU(s) started in SVC mode. devtmpfs: initialized VFP support v0.3: implementor 41 architecture 4 part 30 variant f rev 0 clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns futex hash table entries: 256 (order: 2, 16384 bytes) NET: Registered protocol family 16 DMA: preallocated 256 KiB pool for atomic coherent allocations
+++ Richard Wolf GmbH, Pforzheimer Strasse 32, 75438 Knittlingen Managing Directors: Juergen Pfab, Juergen Steinbeck. Trade Register: Mannheim HRB 510031 +++ Richard Wolf GmbH routinely monitors the content of e-mail sent and received via its network for the purposes of ensuring compliance with its policies and procedures. Richard Wolf GmbH is not responsible for any changes made to the message after it has been sent. Where opinions are expressed, they are not necessarily those of Richard Wolf GmbH. This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended addressee, or the person responsible for delivering it to them, you may not copy, forward, disclose, or otherwise use it or any part of it in any way. To do so may be unlawful. If you receive this e-mail by mistake, please advise the sender immediately. +++
participants (2)
-
Andre Wagner -
Liviu Dudau