[U-Boot] [PATCH 1/1] x86: #define CONFIG_LOADADDR 0x1100000
arch/x86/dts/qemu-x86_i440fx.dts reserves memory for PCI at 0x1000000. Loading via the `dhcp` command to this address leads to a crash on qemu-x86_64_defconfig. So let's define CONFIG_LOADADDR as 0x1100000.
Reported-by: Alexander Graf agraf@suse.de Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de --- compatible='pci-x86' is a U-Boot specific device tree binding. Unfortunately it is not documented. Simon, it would be helpful if you could provide some README. --- include/configs/x86-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h index 4180b25f97..e936230157 100644 --- a/include/configs/x86-common.h +++ b/include/configs/x86-common.h @@ -99,7 +99,7 @@ #define CONFIG_ROOTPATH "/opt/nfsroot" #define CONFIG_HOSTNAME "x86" #define CONFIG_BOOTFILE "bzImage" -#define CONFIG_LOADADDR 0x1000000 +#define CONFIG_LOADADDR 0x1100000 #define CONFIG_RAMDISK_ADDR 0x4000000 #if defined(CONFIG_GENERATE_ACPI_TABLE) || defined(CONFIG_EFI_STUB) #define CONFIG_OTHBOOTARGS "othbootargs=\0"
On 1/24/19 9:18 PM, Heinrich Schuchardt wrote:
arch/x86/dts/qemu-x86_i440fx.dts reserves memory for PCI at 0x1000000. Loading via the `dhcp` command to this address leads to a crash on qemu-x86_64_defconfig. So let's define CONFIG_LOADADDR as 0x1100000.
Reported-by: Alexander Graf agraf@suse.de Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
compatible='pci-x86' is a U-Boot specific device tree binding. Unfortunately it is not documented. Simon, it would be helpful if you could provide some README.
include/configs/x86-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h index 4180b25f97..e936230157 100644 --- a/include/configs/x86-common.h +++ b/include/configs/x86-common.h @@ -99,7 +99,7 @@ #define CONFIG_ROOTPATH "/opt/nfsroot" #define CONFIG_HOSTNAME "x86" #define CONFIG_BOOTFILE "bzImage" -#define CONFIG_LOADADDR 0x1000000 +#define CONFIG_LOADADDR 0x1100000 #define CONFIG_RAMDISK_ADDR 0x4000000 #if defined(CONFIG_GENERATE_ACPI_TABLE) || defined(CONFIG_EFI_STUB) #define CONFIG_OTHBOOTARGS "othbootargs=\0"
Hello Bin, hello Simon,
this is one of the three patches missing in U-Boot master that are putting the EFI patch queue on hold. What is your opinion on the patch?
Best regards
Heinrich
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.
Loading via the `dhcp` command to this address leads to a crash on qemu-x86_64_defconfig. So let's define CONFIG_LOADADDR as 0x1100000.
Reported-by: Alexander Graf agraf@suse.de Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
compatible='pci-x86' is a U-Boot specific device tree binding. Unfortunately it is not documented. Simon, it would be helpful if you could provide some README.
include/configs/x86-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Regards, Bin
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? :)
Alex
Loading via the `dhcp` command to this address leads to a crash on qemu-x86_64_defconfig. So let's define CONFIG_LOADADDR as 0x1100000.
Reported-by: Alexander Graf agraf@suse.de Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
compatible='pci-x86' is a U-Boot specific device tree binding. Unfortunately it is not documented. Simon, it would be helpful if you could provide some README.
include/configs/x86-common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Regards, Bin
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 =>
Regards, Bin
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".
Alex
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
participants (3)
-
Alexander Graf -
Bin Meng -
Heinrich Schuchardt