Hi Tom,

Thanks for getting back to me

...

I'm developing on an ubuntu x86 machine, trying to run the u-boot hello_world standalone application which resides on an image |sd.img| which contains a partition

I've compiled u-boot (|v2022.10|) with |qemu-x86_64_defconfig|

I run qemu with "|qemu-system-x86_64 -m 1024 -nographic -bios u-boot.rom -drive format=raw,file=sd.img"|

u-boot starts up, doesn't find a script, doesn't detect tftp, and awaits a command. If I type |"ext4ls ide 0:1|", I can clearly see hello_world.bin (|3932704 hello_world.bin|).

When I do a |ext4load ide 0:1 0x40000 hello_world.bin| (in preparation for |go 40000 This is another test|), qemu/u-boot restarts.

0x40000 is the |CONFIG_STANDALONE_LOAD_ADDR| for x86.

I have also tried making an image of hello_world |"mkimage -n "Hello stand alone" -A x86_64 -O u-boot -T standalone -C none -a 0x40000 -d hello_world.bin -v hello_world.img|" and tried to load the image into 0x40000 with the intention of using |bootm| in case of cache issues - qemu/u-boot still resets.

Could anyone possibly point out the basic mistake I'm making?

Using the standalone API on platforms where we support UEFI applications is strongly discouraged. If some part of the UEFI support in U-Boot is lacking for your use case we strongly encourage patches adding support for that (as we're doing right now for enhancing SPI support).

All I'm trying to do at the moment is develop a standalone program usingqemu (with -kvm) on my x86 ubuntu machine  and then target a platform (riscv or arm) at a later date.

The instructions in Readme.standalone, loading at a load address of 0x40000, cause a restart of the boot process - mind you saying that, loading to a higher address (say 0x1000000) works but I'm unable to perform a 'go' as the non-relocatable standalone needs to be at 0x40000 (CONFIG_STANDALONE_LOAD_ADDR)

If you can suggest a way forward for developing a u-boot standalone on an x86 machine, I would be hugely grateful! Thanks again

Nick

Hi Simon,

Thanks for getting back to me

...

I'm developing on an ubuntu x86 machine, trying to run the u-boot hello_world standalone application which resides on an image |sd.img| which contains a partition

I've compiled u-boot (|v2022.10|) with |qemu-x86_64_defconfig|

I run qemu with "|qemu-system-x86_64 -m 1024 -nographic -bios u-boot.rom -drive format=raw,file=sd.img"|

u-boot starts up, doesn't find a script, doesn't detect tftp, and awaits a command. If I type |"ext4ls ide 0:1|", I can clearly see hello_world.bin (|3932704 hello_world.bin|).

When I do a |ext4load ide 0:1 0x40000 hello_world.bin| (in preparation for |go 40000 This is another test|), qemu/u-boot restarts.

0x40000 is the |CONFIG_STANDALONE_LOAD_ADDR| for x86.

I have also tried making an image of hello_world |"mkimage -n "Hello stand alone" -A x86_64 -O u-boot -T standalone -C none -a 0x40000 -d hello_world.bin -v hello_world.img|" and tried to load the image into 0x40000 with the intention of using |bootm| in case of cache issues - qemu/u-boot still resets.

Could anyone possibly point out the basic mistake I'm making?

Is the app linked to start at that address. Could you try 'dcache off' before the 'go'? Do you have a debugger?

The standalone Makefile sets up the start address at 0x40000 (CONFIG_STANDALONE_LOAD_ADDR), so I'm assuming that hello_world.bin is correctly linked to that address.

I'm unable to even try 'dcache off' before 'go' as the 'ext4load' at CONFIG_STANDALONE_LOAD_ADDR causes a restart.

As I mentioned to Tom Rini, all I'm trying to do at the moment is develop a standalone program using u-boot and qemu on my x86 ubuntu machine and then target a platform (riscv or arm) at a later date.

Thanks again for your reply

Nick

Hi Simon,

Thanks for the reply

Does qemu have RAM at 0x40000? Can you use 'md' to check that region? I am not sure why it is restarting when you load something there, but that might be unrelated to U-Boot and more to do with QEMU?

You're right, this could easily be a qemu issue - there certainly seems to be memory at 0x40000 - I'll pursue this angle

Thanks again

Cheers Nick