| Message ID | 20190124201820.7676-1-xypron.glpk@gmx.de |
|---|---|
| State | Superseded, archived |
| Delegated to: | Bin Meng |
| Headers | show |
| Series | [U-Boot,1/1] x86: #define CONFIG_LOADADDR 0x1100000 | expand |
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
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"
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(-)