[coreboot] [U-Boot] u-boot on x86 reloaded

[Graeme Russ]

On 04/05/11 18:54, Rudolf Marek wrote:
> Hello,
> 
> I was asked to post it here too.
> 
> I would like to announce that I was able to boot Linux using u-boot on AMD64 
> motherboard Asrock 939A785G. The development was done on QEMU.

Excellent - U-Boot on a new x86 board

> 
> How does it work?
> 
> Coreboot does the complete HW init including memory setup PCI etc. When finishes 
> it loads u-boot.

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

[Snip]

> How the porting was done is described here:
> 
> http://blogs.coreboot.org/blog/2011/04/30/u-boot-as-coreboot-payload/

Excellent write-up - Thanks!

> 
> http://www.coreboot.org/pipermail/coreboot/2011-April/064877.html
> http://www.coreboot.org/pipermail/coreboot/2011-May/064914.html
> http://www.coreboot.org/pipermail/coreboot/2011-May/064915.html
> 
> And boot log http://assembler.cz/minicom42.txt
> 
> This project started "just for fun" or "because I can". Maybe there are some 
> real uses. If you can think of some, please let me know.

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

> 
> 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

> 
> I'm not subscribed, please cc me. I'm ccing coreboot mailing list too.
> 

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 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)
 - 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
 - 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
 - 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
 - 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)

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)

Looking forward to moving this forward

Regards,

Graeme