[U-Boot] u-boot x86 on qemu

Hi all, I am using u-boot from git://git.denx.de/u-boot-x86.git I build u-boot by: make coreboot-x86_config make
u-boot is then set as a payload for coreboot.
I then run coreboot as a bios for qemu: qemu-system-i386 -bios ./build/coreboot.rom -m 1g -nographic -s -S
the system hangs when calling the function u64 get_ticks()
because gd->arch.tsc_base is false and hence panic("No tick base available"); is executed.
panic will itself call udelay(100000 ) which in turn calls __udelay (kv) which finally calls get_ticks() again.
There is then a recursive behavior here which will go on executing until the stack is "depleted".
Has anyone come across this behavior? what could be the reason for the tick base not to be set properly?
regards

Hi Jose,
On 28 January 2014 12:17, José Marinho zemanel@gmail.com wrote:
Hi all, I am using u-boot from git://git.denx.de/u-boot-x86.git I build u-boot by: make coreboot-x86_config make
u-boot is then set as a payload for coreboot.
I then run coreboot as a bios for qemu: qemu-system-i386 -bios ./build/coreboot.rom -m 1g -nographic -s -S
the system hangs when calling the function u64 get_ticks()
because gd->arch.tsc_base is false and hence panic("No tick base available"); is executed.
panic will itself call udelay(100000 ) which in turn calls __udelay (kv) which finally calls get_ticks() again.
There is then a recursive behavior here which will go on executing until the stack is "depleted".
Has anyone come across this behavior? what could be the reason for the tick base not to be set properly?
I believe you might need to build Coreboot in a certain way (with the timestamp feature enabled perhaps?) But the code is supposed to deal with that, so this is a bug.
/* We assume that 0 means the base hasn't been set yet */ if (!gd->arch.tsc_base) panic("No tick base available");
My suggestion would be to either remove this code, or add a warning instead. From memory there was some suggestion in a code review that we produce an error when Coreboot does the wrong thing, but I don't personally think this is that important.
Regards, Simon
participants (2)
-
José Marinho
-
Simon Glass