[U-Boot] Unable to boot evb-ast2500
Hello,
I am attempting to boot evb-ast2500 in Qemu before flashing it to a system. It doesn't get past the DRAM step, due to getting stuck endlessly looping in some libfdt code.
With some debugging turned on, I get this:
OF: translating address: 0040781e OF: parent translation for: 00000000 OF: one level translation: 0040781e OF: parent translation for: 00000000 OF: one level translation: 0040781e OF: translating address: 00206e1e
U-Boot 2018.09-rc1-00096-gbb694d4e898b-dirty (Aug 06 2018 - 12:27:22 +0930)
Model: Aspeed BMC DRAM: OF: translating address: 00006e1e OF: translating address: 00026e1e OF: translating address: 0050781e OF: parent translation for: 00000000 OF: one level translation: 0050781e OF: parent translation for: 00000000 OF: one level translation: 0050781e Watchdog timer expired.
And then the watchdog causes the system to reboot. The build is master as of gbb694d4e898b, with the addition of some #define DEBUG.
I don't think this is a qemu issue. If it is, I can work on fixing qemu, but I need some help on understanding what u-boot is doing.
There's a big pause before the U-Boot banner, and again after showing 'DRAM: 'before getting any of the OF messages. If I get gdb to show me a backtrace at this point:
#0 0x0001e858 in __fswab32 (x=<optimised out>) at include/linux/byteorder/swab.h:114 #1 fdt_offset_ptr (fdt=fdt@entry=0x39370, offset=offset@entry=6444, len=len@entry=4) at lib/libfdt/../../scripts/dtc/libfdt/fdt.c:86 #2 0x0001e9b4 in fdt_next_tag (fdt=fdt@entry=0x39370, startoffset=startoffset@entry=6440, nextoffset=0x1e726d44, nextoffset@entry=0x1e726d3c) at lib/libfdt/../../scripts/dtc/libfdt/fdt.c:120 #3 0x0001eae4 in fdt_next_node (fdt=fdt@entry=0x39370, offset=6440, depth=0x1e726d5c, depth@entry=0x1e726d54) at lib/libfdt/../../scripts/dtc/libfdt/fdt.c:176 #4 0x000205cc in fdt_supernode_atdepth_offset (fdt=0x39370, nodeoffset=14748, supernodedepth=0, nodedepth=0x0 <_start>) at lib/libfdt/fdt_ro.c:443 #5 0x00011608 in ofnode_get_parent (node=..., node@entry=...) at include/dm/ofnode.h:94 #6 0x000113dc in regmap_init_mem (node=..., mapp=0x0 <_start>, mapp@entry=0x1e726dbc) at drivers/core/regmap.c:63 #7 0x000014e0 in ast2500_sdrammc_ofdata_to_platdata (dev=0x1e7273c4) at include/dm/read.h:38 #8 0x0000fc88 in device_probe (dev=dev@entry=0x1e7273c4) at drivers/core/device.c:399 #9 0x000108c0 in uclass_get_device_tail (dev=0x1e7273c4, ret=<optimised out>, devp=0x1e726e0c) at drivers/core/uclass.c:397 #10 0x00010900 in uclass_get_device (id=id@entry=UCLASS_RAM, index=index@entry=0, devp=0x1e726e0c, devp@entry=0x1e726e04) at drivers/core/uclass.c:413 #11 0x00001ab0 in dram_init () at arch/arm/mach-aspeed/ast2500-board.c:69 #12 0x0001b834 in initcall_run_list (init_sequence=init_sequence@entry=0x29344 <init_sequence_f>) at lib/initcall.c:30 #13 0x0000854c in board_init_f (boot_flags=<optimised out>) at common/board_f.c:900 #14 0x00000664 in _main () at arch/arm/lib/crt0.S:86
Cheers,
Joel
--
To reproduce in qemu, build qemu master for ARM:
git://git.qemu-project.org/qemu && cd qemu ./configure --target-list=arm-softmmu make
build a 32MB image from u-boot.bin:
dd if=/dev/zero of=test.img bs=1M count=32 dd if=u-boot.bin of=test.img conv=notrunc
boot it:
arm-softmmu/qemu-system-arm -M ast2500-evb -m 512 -nographic -drive file=test.img,format=raw,if=mtd -serial stdio -monitor pty
On 08/06/2018 05:25 AM, Joel Stanley wrote:
Hello,
I am attempting to boot evb-ast2500 in Qemu before flashing it to a system. It doesn't get past the DRAM step, due to getting stuck endlessly looping in some libfdt code.
With some debugging turned on, I get this:
OF: translating address: 0040781e OF: parent translation for: 00000000 OF: one level translation: 0040781e OF: parent translation for: 00000000 OF: one level translation: 0040781e OF: translating address: 00206e1e
U-Boot 2018.09-rc1-00096-gbb694d4e898b-dirty (Aug 06 2018 - 12:27:22 +0930)
Model: Aspeed BMC DRAM: OF: translating address: 00006e1e OF: translating address: 00026e1e OF: translating address: 0050781e OF: parent translation for: 00000000 OF: one level translation: 0050781e OF: parent translation for: 00000000 OF: one level translation: 0050781e Watchdog timer expired.
And then the watchdog causes the system to reboot. The build is master as of gbb694d4e898b, with the addition of some #define DEBUG.
I don't think this is a qemu issue. If it is, I can work on fixing qemu, but I need some help on understanding what u-boot is doing.
The sdram driver in U-Boot uses the watchdog1 and the SCU power reset register to reset the SDRAM controller. Our QEMU emulation is not precise enough I think.
C.
There's a big pause before the U-Boot banner, and again after showing 'DRAM: 'before getting any of the OF messages. If I get gdb to show me a backtrace at this point:
#0 0x0001e858 in __fswab32 (x=<optimised out>) at include/linux/byteorder/swab.h:114 #1 fdt_offset_ptr (fdt=fdt@entry=0x39370, offset=offset@entry=6444, len=len@entry=4) at lib/libfdt/../../scripts/dtc/libfdt/fdt.c:86 #2 0x0001e9b4 in fdt_next_tag (fdt=fdt@entry=0x39370, startoffset=startoffset@entry=6440, nextoffset=0x1e726d44, nextoffset@entry=0x1e726d3c) at lib/libfdt/../../scripts/dtc/libfdt/fdt.c:120 #3 0x0001eae4 in fdt_next_node (fdt=fdt@entry=0x39370, offset=6440, depth=0x1e726d5c, depth@entry=0x1e726d54) at lib/libfdt/../../scripts/dtc/libfdt/fdt.c:176 #4 0x000205cc in fdt_supernode_atdepth_offset (fdt=0x39370, nodeoffset=14748, supernodedepth=0, nodedepth=0x0 <_start>) at lib/libfdt/fdt_ro.c:443 #5 0x00011608 in ofnode_get_parent (node=..., node@entry=...) at include/dm/ofnode.h:94 #6 0x000113dc in regmap_init_mem (node=..., mapp=0x0 <_start>, mapp@entry=0x1e726dbc) at drivers/core/regmap.c:63 #7 0x000014e0 in ast2500_sdrammc_ofdata_to_platdata (dev=0x1e7273c4) at include/dm/read.h:38 #8 0x0000fc88 in device_probe (dev=dev@entry=0x1e7273c4) at drivers/core/device.c:399 #9 0x000108c0 in uclass_get_device_tail (dev=0x1e7273c4, ret=<optimised out>, devp=0x1e726e0c) at drivers/core/uclass.c:397 #10 0x00010900 in uclass_get_device (id=id@entry=UCLASS_RAM, index=index@entry=0, devp=0x1e726e0c, devp@entry=0x1e726e04) at drivers/core/uclass.c:413 #11 0x00001ab0 in dram_init () at arch/arm/mach-aspeed/ast2500-board.c:69 #12 0x0001b834 in initcall_run_list (init_sequence=init_sequence@entry=0x29344 <init_sequence_f>) at lib/initcall.c:30 #13 0x0000854c in board_init_f (boot_flags=<optimised out>) at common/board_f.c:900 #14 0x00000664 in _main () at arch/arm/lib/crt0.S:86
Cheers,
Joel
--
To reproduce in qemu, build qemu master for ARM:
git://git.qemu-project.org/qemu && cd qemu ./configure --target-list=arm-softmmu make
build a 32MB image from u-boot.bin:
dd if=/dev/zero of=test.img bs=1M count=32 dd if=u-boot.bin of=test.img conv=notrunc
boot it:
arm-softmmu/qemu-system-arm -M ast2500-evb -m 512 -nographic -drive file=test.img,format=raw,if=mtd -serial stdio -monitor pty
On Mon, 6 Aug 2018 at 19:39, Cédric Le Goater clg@kaod.org wrote:
On 08/06/2018 05:25 AM, Joel Stanley wrote:
Hello,
I am attempting to boot evb-ast2500 in Qemu before flashing it to a system. It doesn't get past the DRAM step, due to getting stuck endlessly looping in some libfdt code.
With some debugging turned on, I get this:
OF: translating address: 0040781e OF: parent translation for: 00000000 OF: one level translation: 0040781e OF: parent translation for: 00000000 OF: one level translation: 0040781e OF: translating address: 00206e1e
U-Boot 2018.09-rc1-00096-gbb694d4e898b-dirty (Aug 06 2018 - 12:27:22 +0930)
Model: Aspeed BMC DRAM: OF: translating address: 00006e1e OF: translating address: 00026e1e OF: translating address: 0050781e OF: parent translation for: 00000000 OF: one level translation: 0050781e OF: parent translation for: 00000000 OF: one level translation: 0050781e Watchdog timer expired.
And then the watchdog causes the system to reboot. The build is master as of gbb694d4e898b, with the addition of some #define DEBUG.
I don't think this is a qemu issue. If it is, I can work on fixing qemu, but I need some help on understanding what u-boot is doing.
The sdram driver in U-Boot uses the watchdog1 and the SCU power reset register to reset the SDRAM controller. Our QEMU emulation is not precise enough I think.
Thanks for the pointer.
I was able to get u-boot to load to the prompt after some hacks to get rid of the watchdog requirement. It was a surprise to find out that the watchdog is used to reset the SDRAM controller!
I have some patches to send to the qemu list that will allow it to run.
Cheers,
Joel
On 08/06/2018 12:11 PM, Joel Stanley wrote:
On Mon, 6 Aug 2018 at 19:39, Cédric Le Goater clg@kaod.org wrote:
On 08/06/2018 05:25 AM, Joel Stanley wrote:
Hello,
I am attempting to boot evb-ast2500 in Qemu before flashing it to a system. It doesn't get past the DRAM step, due to getting stuck endlessly looping in some libfdt code.
With some debugging turned on, I get this:
OF: translating address: 0040781e OF: parent translation for: 00000000 OF: one level translation: 0040781e OF: parent translation for: 00000000 OF: one level translation: 0040781e OF: translating address: 00206e1e
U-Boot 2018.09-rc1-00096-gbb694d4e898b-dirty (Aug 06 2018 - 12:27:22 +0930)
Model: Aspeed BMC DRAM: OF: translating address: 00006e1e OF: translating address: 00026e1e OF: translating address: 0050781e OF: parent translation for: 00000000 OF: one level translation: 0050781e OF: parent translation for: 00000000 OF: one level translation: 0050781e Watchdog timer expired.
And then the watchdog causes the system to reboot. The build is master as of gbb694d4e898b, with the addition of some #define DEBUG.
I don't think this is a qemu issue. If it is, I can work on fixing qemu, but I need some help on understanding what u-boot is doing.
The sdram driver in U-Boot uses the watchdog1 and the SCU power reset register to reset the SDRAM controller. Our QEMU emulation is not precise enough I think.
Thanks for the pointer.
I was able to get u-boot to load to the prompt after some hacks to get rid of the watchdog requirement. It was a surprise to find out that the watchdog is used to reset the SDRAM controller!
The SDK also does but it uses wdt3 and only sets the enable reset SDRAM bit in the reset register mask. May be u-boot needs some improvements on that part.
I have some patches to send to the qemu list that will allow it to run.
OK. we can add them to our QEMU branch
Thanks,
C.
participants (2)
-
Cédric Le Goater -
Joel Stanley