[U-Boot] u-boot on x86 reloaded

[Rudolf Marek]

Hello all,

> Excellent - U-Boot on a new x86 board

Yes and in general any supported coreboot board.

> This is one of the ways I was thinking of getting U-Boot running on
> mainstream PC boards. The other is to create U-Boot as a GRUB payload.
> Either way, it's all about getting the SDRAM initialised

Not only, also HyperTransport, complex PCI stuff, power mngmt etc, lots of lots 
of stuff.

> Well, that's why I started too - kudos for the effort

Thanks.

>> Anyone with more free time could work on this?
>
> Well I did have someone else contact me about doing exactly as you have
> done (I have Bcc'd him in case he is interested)
>
> As the U-Boot x86 maintainer, I am extremely interested in going further
> with this and am keen to help get your work mainlined

Ok

> OK, a few little points which may help answer some questions you didn't
> realise you even had ;)
>
>   - The build warnings and errors you incurred are probably fixed in
> mainline (x86 is a bit of a forgotten cousin which gets broken when global
> patches are made to Makefile, linker scripts etc). If you still have
> problems compiling the latest U-Boot git head, please post them to the
> mailing list and I'll sort them out ASAP

The links to the coreboot mailing list contain some patches.

>   - The x86 port of U-Boot was the first to implement the (now pretty much
> standard) relocation scheme. Understanding it is a Very Good Idea(tm)
>   - SYS_TEXT_BASE=0×19000000 is very specific to the eNET - It is the start
> of non-volatile (battery backed) SRAM. We can run from SRAM prior to
> initialising SDRAM, so I use it as an alternative to Flash for testing new
> builds (reset ->  TFTP new image to 0x19000000 ->  go 19000000)

Yes I move that to 16MB boundary to load it just into RAM. u-boot ELF can be 
loaded from coreboot, where it is stored compressed.

>   - When launching U-Boot as a payload from Coreboot, you really don't need
> to worry about what is at the end of the image (reset vector and jump to
> protected mode). All the fun begins at the first byte of u-boot.bin which
> is the first line of code in start.S

I think it jumps to _start which is 32 bit entry point. The coreboot is in flat 
mode 32bit.

>   - CONFIG_SYS_INIT_SP_ADDR is a temporary stack pointer which is used
> during the relocation of U-Boot from ROM (Flash) into SDRAM. Typically the
> CPU's Cache-As-RAM (CAR) capability is used. However, if SDRAM is already
> initialised, you can set CONFIG_SYS_INIT_SP_ADDR to anywhere in SDRAM that
> will not get clobbered by the relocation

Yes I set it to 256KB boundary.

>   - I'm in the middle of re-writing the entire real-mode switch code and
> real-mode support in U-Boot. The new code allows you to write real-mode
> code in C - I even have the Linux real-mode printf ported :) This will make
> writing your own 'BIOS' code for your board a lot easier

Well I liked here that there is no BIOS at all. The SeaBIOS is the layer used by 
coreboot to have full legacy BIOS stuff. This is used by KVM/Qenu too.

The coreboot can do VGA init (it has kind of BIOS emulation stuff for this) so 
at the end VGA + keyboard could be possible.

I guess if u-boot is for linux loading, then we need to add e820 stuff to have 
support for over 4GB of memory.

>   - Ultimately, I would like to bypass Linux's real-mode stub (like GRUB)
> and ditch the real-mode code (for the purpose of booting Linux)

This is done in FILO. Check http://www.coreboot.org/FILO I guess it can be just 
ported. The coreboot will provide the memory map and this is how the FILO is 
doing that, just  transforming it and passing it directly to kernel.

> I would really like to see some U-Boot patches on the mailing list -
> Technically U-Boot is meant to be a stand-alone and self-sufficient, but I
> think for x86 there is merit in creating board configuration that gets
> boot-strapped by Coreboot (we just need to make sure the documentation is
> up-to-scratch)

The patches are just now on coreboot mailing list. It is just a hack, because 
there are places which needs to be fixed, the computation of place for the 
realmode and bios sections needs to be fixed.  I added the coreboot as a board 
and subarchitecture.

What is specific is that we will need to copy "MPtable" "PIR" and "RSDP" pointer 
to F-segment just after the bios section. The memory map can be read out of 
coreboot tables stored in high mem. Also a PCI mem stuff should be fixed in u-boot.

Also if we get rid of the .bios and .realmode section then the problem that 
those two sections are not relocated to end of memory disappears.

> Looking forward to moving this forward

Good. Please check the patches on coreboot ml and feel free to join #coreboot 
channel. I'm in both now as "ruik".

Thanks,
Rudolf