[U-Boot] [PATCH 1/1] x86: #define CONFIG_LOADADDR 0x1100000

[Bin Meng]

On Thu, Jan 31, 2019 at 4:04 PM Alexander Graf <agraf at 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 at suse.de> wrote:
> >>
> >>
> >>
> >>> Am 31.01.2019 um 08:50 schrieb Bin Meng <bmeng.cn at gmail.com>:
> >>>
> >>> Hi Heinrich,
> >>>
> >>>> On Fri, Jan 25, 2019 at 4:18 AM Heinrich Schuchardt <xypron.glpk at 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