On Thu, Jan 31, 2019 at 4:04 PM Alexander Graf agraf@suse.de wrote:
On 31.01.19 08:59, Bin Meng wrote:
Hi Alex,
On Thu, Jan 31, 2019 at 3:57 PM Alexander Graf agraf@suse.de wrote:
Am 31.01.2019 um 08:50 schrieb Bin Meng bmeng.cn@gmail.com:
Hi Heinrich,
On Fri, Jan 25, 2019 at 4:18 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
arch/x86/dts/qemu-x86_i440fx.dts reserves memory for PCI at 0x1000000.
I think you misread the codes. 0x1000000 means PCI I/O space, not the actual address here. See FDT_PCI_SPACE_IO in fdtdec.h.
It still crashes. Can you explain why? :)
I did a 'dhcp' just now, no crashes. What test cases are you using?
logs:
U-Boot SPL 2019.01-00430-g6b4b811 (Jan 31 2019 - 15:55:57 +0800) CPU: x86_64, vendor AMD, device 663h Trying to boot from SPI Jumping to 64-bit U-Boot: Note many features are missing
U-Boot 2019.01-00430-g6b4b811 (Jan 31 2019 - 15:55:57 +0800)
CPU: QEMU Virtual CPU version 2.5+ DRAM: 128 MiB Incorrect expansion ROM header signature 4baa Model: QEMU x86 (I440FX) Net: e1000: 52:54:00:12:34:56
Warning: e1000#0 using MAC address from ROM eth0: e1000#0 Hit any key to stop autoboot: 0 => dhcp BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 BOOTP broadcast 8 BOOTP broadcast 9 BOOTP broadcast 10 BOOTP broadcast 11 BOOTP broadcast 12 BOOTP broadcast 13 BOOTP broadcast 14 BOOTP broadcast 15 BOOTP broadcast 16 BOOTP broadcast 17
Retry time exceeded; starting again =>
Well, it doesn't actually load any file.
Try:
$ qemu-system-x86_64 -bios u-boot.rom -nographic -net nic -net user,tftp=.,bootfile=u-boot
That should crash once you run "dhcp".
OK, I've reproduced this. It turns out 0x1000000 is where the page table locates in the 64-bit mode, so we can't overwrite its contents. I will send a patch to change that address.
Regards, Bin