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. +++