[U-Boot] U-Boot-x86 / coreboot Integration

[U-Boot] U-Boot-x86 / coreboot Integration

[Graeme Russ]

Hi All,

I figured it might be best to start a new, clean thread dealing with the
technical design aspects of bootstrapping U-Boot from coreboot.

I am extremely excited about this as the x86 U-Boot maintainer, but even
more so by the idea of two very mature and respected FLOSS projects
potentially becoming greater than the sum of their parts :)

OK, enough with the warm and fuzzies. Lets look first at a few facts (as I
understand them - please feel free to correct me):
 - U-Boot is a bootloader for embedded systems - A market segment
   dominated by ARM, PPC et al - i.e. NOT x86
 - coreboot is a 'BIOS' replacement for mainstream PC's - A market segment
   dominated by x86
 - Both are principally designed as 'primary bootloaders' - i.e. intended
   to be executed at CPU reset and responsible for low level hardware
   initialisation
 - U-Boot has no support for modern x86 PC hardware (North and South
   bridges, Dual-Core x86 CPUs, microcode, ACPI, APM etc)
 - coreboot is 'dumb' (No command line, scripting etc) As I understand it
   you build a 'payload' into the coreboot image which coreboot simply runs
   after it has performed necessary low-level hardware initialisation
 - U-Boot is 'smart' (command line, scripting, network support, environment
   variables etc) but currently lacks the ability to perform low level
   hardware initialisation of x86 PC hardware
 - coreboot launches a 'payload' which is (typically) an ELF executable
   linked to 'libpayload'. libpayload provides access to some primitive
   libc functionality, I/O and coreboot generated data structures
 - Our primary target OS is GNU/Linux (of course!)
 - The majority of U-Boot and coreboot is licensed under the 'GPLv2 or (at
   your option) any later version'

So coreboot and U-Boot are a good complement to each other so bringing
U-Boot to x86 PC mainboards via coreboot looks like a good idea - Now the
politics ;)
 - The U-Boot source 'must' be self contained - No external libraries.
   Incorporating license compatible source is OK
 - coreboot payloads should be in ELF (linked to libpayload)
 - There should be minimal intrusion into the core U-Boot build scripts
   (Makefiles, mk.configs etc) - I would assume the same applies to
   coreboot build files as well. Hacking the U-Boot x86 specific build
   files should be fine
 - Everything should 'just work' with a recent GNU toolchain (gcc,
   binutils etc)
 - U-Boot relocates to 'Top of RAM' - This is a fundamental architectural
   design and not x86 specific. This feature should be retained for
   consistency with other U-Boot arches
 - Do we care about legacy BIOS support (SeaBIOS) for now (I think not)?

So, a few questions
 - How much of libpayload would we need to bring into U-Boot to provide
   bare minimal payload delivery? U-Boot already contains it's own minimal
   libc routines.
 - How do we get VGA and USB keyboard support working? Do other U-Boot
   boards implement console on anything other than serial?
 - Can we add relocation support to the coreboot ELF loader?
 - Does coreboot relocate into RAM? If so, what is the target address? What
   guarantee is there that the target address is valid?
 - Could coreboot benefit from U-Boot's 'load to top of RAM' philosophy?
 - Is it worth playing around with segment registers to 'relocate' U-Boot
 - What hardware should be initialised in coreboot and what should be
   initialised in U-Boot? (political question ;)
 - What about Chipset Microcode (CMC)
 - What about System Management Mode (SMM)

I think a good start would be to create a new U-Boot target which includes
a stripped down libpayload in the U-Boot source. This target can exclude
most of the assembler startup code (resetvec.S, start16.S, start.S). I
assume the coreboot ELF loader (or libpayload) takes care of setting up the
C environment (stack etc).

We can start with U-Boot linked to a fixed location in RAM and skip
relocations then work on either extending coreboot to perform relocation
fixups or have U-Boot perform the fixups based on RAM information read from
cbtable

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Peter Stuge]

Graeme Russ wrote:
> I am extremely excited about this as the x86 U-Boot maintainer, but
> even more so by the idea of two very mature and respected FLOSS
> projects potentially becoming greater than the sum of their parts :)

Yes good fun!


> OK, enough with the warm and fuzzies. Lets look first at a few facts
> (as I understand them - please feel free to correct me):
>  - U-Boot is a bootloader for embedded systems - A market segment
>    dominated by ARM, PPC et al - i.e. NOT x86
>  - coreboot is a 'BIOS' replacement for mainstream PC's - A market segment
>    dominated by x86
>  - Both are principally designed as 'primary bootloaders' - i.e. intended
>    to be executed at CPU reset and responsible for low level hardware
>    initialisation
>  - U-Boot has no support for modern x86 PC hardware (North and South
>    bridges, Dual-Core x86 CPUs, microcode, ACPI, APM etc)
>  - coreboot is 'dumb' (No command line, scripting etc) As I understand it
>    you build a 'payload' into the coreboot image which coreboot simply runs
>    after it has performed necessary low-level hardware initialisation
>  - U-Boot is 'smart' (command line, scripting, network support, environment
>    variables etc) but currently lacks the ability to perform low level
>    hardware initialisation of x86 PC hardware
>  - coreboot launches a 'payload' which is (typically) an ELF executable
>    linked to 'libpayload'. libpayload provides access to some primitive
>    libc functionality, I/O and coreboot generated data structures
>  - Our primary target OS is GNU/Linux (of course!)
>  - The majority of U-Boot and coreboot is licensed under the 'GPLv2 or (at
>    your option) any later version'

coreboot is GPLv2 only, otherwise the facts are accurate.


> Now the politics ;)
>  - The U-Boot source 'must' be self contained - No external libraries.
>    Incorporating license compatible source is OK

Well ok.. (why though?)


>  - coreboot payloads should be in ELF (linked to libpayload)

They do not neccessarily have to link to libpayload, but if they
don't they have to replicate some of what libpayload does. That code
duplication is pretty silly, so most payloads do use libpayload.


>  - There should be minimal intrusion into the core U-Boot build scripts
>    (Makefiles, mk.configs etc) - I would assume the same applies to
>    coreboot build files as well. Hacking the U-Boot x86 specific build
>    files should be fine

coreboot uses Kconfig for build time configuration and I think it
would be no problem (maybe even desirable) to add a few special
commands in order to grab a U-Boot from git, build it, and include it
as payload in the output coreboot.rom. This is done for SeaBIOS
already.


>  - Everything should 'just work' with a recent GNU toolchain (gcc,
>    binutils etc)

coreboot has significant experiences from distribution toolchains
being patched to the point where they are unable to correctly build
coreboot itself and/or payloads. If the distribution toolchain works
for you that's good, but most of the big name distributions have
messed up their toolchains. The coreboot source includes a script to
build known good versions of the toolchain, and the coreboot build
system will automatically pick up such a toolchain if it is found
during build.


>  - U-Boot relocates to 'Top of RAM' - This is a fundamental architectural
>    design and not x86 specific. This feature should be retained for
>    consistency with other U-Boot arches

IMO this might be a little misguided. Retaining behavior, especially
across architecture, shouldn't be an end in itself. If U-Boot was the
primary bootloader in this situation it would matter less. In the
context of coreboot however U-Boot would be much easier to integrate
with if this policy was not enforced. Maybe U-Boot wants to stay
resident however, then there's not much choice except top of memory.


>  - Do we care about legacy BIOS support (SeaBIOS) for now (I think
>    not)?

IMO it is not relevant to the integration of coreboot and U-Boot. If
a BIOS is needed by U-Boot itself or whatever it loads, then SeaBIOS
must be used as payload for coreboot, and SeaBIOS will then start
U-Boot after setting up the BIOS environment.


> So, a few questions
>  - How much of libpayload would we need to bring into U-Boot to provide
>    bare minimal payload delivery? U-Boot already contains it's own
>    minimal libc routines.

Not much at all. You basically just have to look up the coreboot
table.


>  - How do we get VGA and USB keyboard support working?

Write VGA and USB drivers. Or use the ones that are available in
libpayload. Estimate 5-6 months of development effort to write from
scratch. But you could also copy it all from libpayload of course.

One thing to keep in mind here is that VGA will only be available if
coreboot or SeaBIOS has set it up. coreboot only knows how to do this
for two or three graphics chipsets. SeaBIOS can initialize any VGA
option ROM, but then you need SeaBIOS in the loop.

Option ROMs are ageold technology and stupid, but they are still
firmly entrenched in PC hardware. A BIOS was always there so everyone
assumes it will always stay there, not very many question if
something better could be done.


>    Do other U-Boot boards implement console on anything other than
>    serial?

U-Boot? Can't say.


>  - Can we add relocation support to the coreboot ELF loader?

ELF payloads are parsed at build time, simplified into a
coreboot-internal format. Run time relocation is not so attractive.


>  - Does coreboot relocate into RAM? If so, what is the target address?

Determined at build time.

>    What guarantee is there that the target address is valid?

It's low enough in RAM.


>  - Could coreboot benefit from U-Boot's 'load to top of RAM' philosophy?

I doubt it, but maybe?


>  - Is it worth playing around with segment registers to 'relocate' U-Boot

Maybe?


>  - What hardware should be initialised in coreboot and what should be
>    initialised in U-Boot? (political question ;)

Actually this is well defined. coreboot in general does not touch
peripherals with VGA being the exception.


>  - What about Chipset Microcode (CMC)
>  - What about System Management Mode (SMM)

coreboot does provide the bare minimum for chipsets which need it,
but preference is to not go beyond the busses.


> We can start with U-Boot linked to a fixed location in RAM and skip
> relocations then work on either extending coreboot to perform
> relocation fixups or have U-Boot perform the fixups based on RAM
> information read from cbtable

The latter sounds better to me. :)


> From there, we can start to add device support (USB, video, PCI,
> IDE/SATA etc)

libpayload covers most of these. :) Take a look at a couple different
libpayload users. FILO would probably be the closest to what U-Boot
does.


//Peter

[U-Boot] U-Boot-x86 / coreboot Integration

[Wolfgang Denk]

Dear Graeme Russ,

In message <4DC94CD4.2050904@gmail.com> you wrote:
> 
> So coreboot and U-Boot are a good complement to each other so bringing
> U-Boot to x86 PC mainboards via coreboot looks like a good idea - Now the
> politics ;)
>  - The U-Boot source 'must' be self contained - No external libraries.
>    Incorporating license compatible source is OK

The same is probably true for coreboot.

>  - coreboot payloads should be in ELF (linked to libpayload)

Is this really necessary, assuming we have a self-contained payload
that does not request any services from the tool that was used to
start it?

>  - How much of libpayload would we need to bring into U-Boot to provide
>    bare minimal payload delivery? U-Boot already contains it's own minimal
>    libc routines.

Right.  See above - eventually such linking is not really necessary if
the U-Boot ELF image is really self-contained.

>  - How do we get VGA and USB keyboard support working? Do other U-Boot
>    boards implement console on anything other than serial?

Yes, we do support output on LCD and other video adapters, and we
support input from USB keyboard (not to mentione netconsole, or
netconsole over ethernet  over USB and similar fancy stuff).

>  - Can we add relocation support to the coreboot ELF loader?

Do we have to?

>  - Does coreboot relocate into RAM? If so, what is the target address? What
>    guarantee is there that the target address is valid?

Do we have to care?  I would expect that we consider both coreboot and
U-Boot as isolated entities, each performing it's own task. Coreboot
will initialize the RAM and load and start U-Boot, similar to what a
first stage loader does on systems that boot from NAND.  Once U-Bootis
running, it does so completely on its own.

>  - Could coreboot benefit from U-Boot's 'load to top of RAM' philosophy?

Is there any need for this?  Don't make things more complex than
needed.

>  - Is it worth playing around with segment registers to 'relocate' U-Boot

That's a U-Boot question, right?  Let's solve this independently.

>  - What hardware should be initialised in coreboot and what should be
>    initialised in U-Boot? (political question ;)

No, that's a very practical; question. Coreboot should do as many of
the x86 specific stuff as it can, and as it already does to load and
start other payloads.  And probably not more, at least not for now.

I think the best way to make this undertaking a success is to make it
as unintrusive to both involved projects as possible.

> I think a good start would be to create a new U-Boot target which includes
> a stripped down libpayload in the U-Boot source. This target can exclude

Why would we need that?  I can understand that this may make initial
porting and debugging easier ("early console output" etc.), but we
should try to do without this.

> We can start with U-Boot linked to a fixed location in RAM and skip
> relocations then work on either extending coreboot to perform relocation
> fixups or have U-Boot perform the fixups based on RAM information read from
> cbtable

I strongly recommend not to request changes to coreboot, and not to
deviate from standard U-Boot methods.

We are not re-inventing the wheel here.  We have many similar
situations where some ROM boot loader or xload or nand_spl code or
onenand_ipl code is loading an U-Boot image into a halfway initialized
system, and U-Boot starts there.  I see no need to make coreboot use a
different method.

> P.S. Please keep both U-Boot and coreboot mailing lists Cc'd - Note: If you
> are not on the coreboot ml, you emails will get bounced to a moderator :(

I hope he is tolerant enough...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"...all the  good  computer  designs  are  bootlegged;  the  formally
planned  products,  if  they  are built at all, are dogs!" - David E.
Lundstrom, "A Few Good Men From Univac", MIT Press, 1987

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Wolfgang Denk]

Dear Peter Stuge,

In message <20110510160850.2499.qmail@stuge.se> you wrote:
>
> >  - U-Boot relocates to 'Top of RAM' - This is a fundamental architectural
> >    design and not x86 specific. This feature should be retained for
> >    consistency with other U-Boot arches
> 
> IMO this might be a little misguided. Retaining behavior, especially
> across architecture, shouldn't be an end in itself. If U-Boot was the
> primary bootloader in this situation it would matter less. In the
> context of coreboot however U-Boot would be much easier to integrate
> with if this policy was not enforced. Maybe U-Boot wants to stay
> resident however, then there's not much choice except top of memory.

It's not about staying resident, but for a number of other features
that are considered valuable, like:
- auto-adapting to the available RAM size so a maximum amount of
  contiguous RAM is available to load OS and/or file system images,
  etc.
- providing "persistent RAM" which keeps it's content even through a
  reset/crash/warmboot; frequently used for in-memory file systems
  (pramfs for example)
- sharing a log buffewr between U-Boot and Linux, so Linux can pick up
  U-Boot's POST codes using standard syslog tools, or U-Boot can read
  the Linux log buffer after a system crash - or Linux can pick up the
  last entries of the previous Linux kernel's messages after a
  crash/reboot
- sharing video RAM, so we can load a splash screen in U-Boot which
  can be assedon without any flicker to Linux, until application code
  starts drawing it's own graphics.
etc.

All these are based on the idea to reserve memory chunks from the top
of physical RAM.  And U-Boot is sitting just below all these reserved
chunks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
God is real, unless declared integer.

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Graeme Russ]

On Wed, May 11, 2011 at 2:08 AM, Peter Stuge <peter@stuge.se> wrote:
> Graeme Russ wrote:
>> I am extremely excited about this as the x86 U-Boot maintainer, but
>> even more so by the idea of two very mature and respected FLOSS
>> projects potentially becoming greater than the sum of their parts :)
>
> Yes good fun!
>
>

[snip]

>> ?- The majority of U-Boot and coreboot is licensed under the 'GPLv2 or (at
>> ? ?your option) any later version'
>
> coreboot is GPLv2 only, otherwise the facts are accurate.

[U-Boot] U-Boot-x86 / coreboot Integration

[Graeme Russ]

Hi Wolfgang

On Wed, May 11, 2011 at 4:03 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Graeme Russ,
>
> In message <4DC94CD4.2050904@gmail.com> you wrote:
>>
>> So coreboot and U-Boot are a good complement to each other so bringing
>> U-Boot to x86 PC mainboards via coreboot looks like a good idea - Now the
>> politics ;)
>> ?- The U-Boot source 'must' be self contained - No external libraries.
>> ? ?Incorporating license compatible source is OK
>
> The same is probably true for coreboot.
>
>> ?- coreboot payloads should be in ELF (linked to libpayload)
>
> Is this really necessary, assuming we have a self-contained payload
> that does not request any services from the tool that was used to
> start it?

Question for the coreboot guys. I think the linkage to libpayload can be
omitted, but include enough of libpayload to get to the coreboot data
structures which can tell U-Boot vital information regarding the hardware.

Also see below - If it's loading an ELF image, can't it just pass a
parameter which points to the tables?

>> ?- How much of libpayload would we need to bring into U-Boot to provide
>> ? ?bare minimal payload delivery? U-Boot already contains it's own minimal
>> ? ?libc routines.
>
> Right. ?See above - eventually such linking is not really necessary if
> the U-Boot ELF image is really self-contained.

Yes

>> ?- How do we get VGA and USB keyboard support working? Do other U-Boot
>> ? ?boards implement console on anything other than serial?
>
> Yes, we do support output on LCD and other video adapters, and we
> support input from USB keyboard (not to mentione netconsole, or
> netconsole over ethernet ?over USB and similar fancy stuff).

Nice :)

>> ?- Can we add relocation support to the coreboot ELF loader?
>
> Do we have to?

If we want U-Boot at top-of RAM and avoid a second memcpy then yes,
but as we know, it is not as simple as that. U-Boot relocates after it
has determined how much upper memory to reserve which isn't known until
U-Boot has enumerated it's hardware environment. Hence the reason U-Boot
will always have to suffer the penalty of the extra memcpy (the bootstrap
loader does not have enough information to reserve this memory for U-Boot)

>> ?- Does coreboot relocate into RAM? If so, what is the target address? What
>> ? ?guarantee is there that the target address is valid?
>
> Do we have to care? ?I would expect that we consider both coreboot and
> U-Boot as isolated entities, each performing it's own task. Coreboot
> will initialize the RAM and load and start U-Boot, similar to what a
> first stage loader does on systems that boot from NAND. ?Once U-Bootis
> running, it does so completely on its own.
>
>> ?- Could coreboot benefit from U-Boot's 'load to top of RAM' philosophy?
>
> Is there any need for this? ?Don't make things more complex than
> needed.

No, I don't think there is

>> ?- Is it worth playing around with segment registers to 'relocate' U-Boot
>
> That's a U-Boot question, right? ?Let's solve this independently.

Not really - If we want coreboot to place U-Boot at top-of-RAM then
coreboot would have to figure this out. But I think this is now a moot
point (see my other email)

>> ?- What hardware should be initialised in coreboot and what should be
>> ? ?initialised in U-Boot? (political question ;)
>
> No, that's a very practical; question. Coreboot should do as many of
> the x86 specific stuff as it can, and as it already does to load and
> start other payloads. ?And probably not more, at least not for now.

Yes - As I mentioned in my other post, coreboot should do as much as it
needs to (and not more) to load (arbitrary) payloads. The rest should
be up to U-Boot using the U-Boot principle of initialising only what
needs to be initialised.

> I think the best way to make this undertaking a success is to make it
> as unintrusive to both involved projects as possible.

Agree

>> I think a good start would be to create a new U-Boot target which includes
>> a stripped down libpayload in the U-Boot source. This target can exclude
>
> Why would we need that? ?I can understand that this may make initial
> porting and debugging easier ("early console output" etc.), but we
> should try to do without this.

Even more stripped than that - Just enough to get access to the coreboot
tables. Actually, if coreboot is launching an ELF payload, surely it
could pass a pointer to the tables as a argument to main()

>> We can start with U-Boot linked to a fixed location in RAM and skip
>> relocations then work on either extending coreboot to perform relocation
>> fixups or have U-Boot perform the fixups based on RAM information read from
>> cbtable
>
> I strongly recommend not to request changes to coreboot, and not to
> deviate from standard U-Boot methods.

Agree and Agree

> We are not re-inventing the wheel here. ?We have many similar
> situations where some ROM boot loader or xload or nand_spl code or
> onenand_ipl code is loading an U-Boot image into a halfway initialized
> system, and U-Boot starts there. ?I see no need to make coreboot use a
> different method.

Except the coreboot can load ELF images and if we can avoid a memcpy by
having coreboot do the relocation, we eek out that little bit more boot
speed ;)

>> P.S. Please keep both U-Boot and coreboot mailing lists Cc'd - Note: If you
>> are not on the coreboot ml, you emails will get bounced to a moderator :(
>
> I hope he is tolerant enough...

Regards,

Graeme

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Kevin O'Connor]

On Wed, May 11, 2011 at 09:44:00AM +1000, Graeme Russ wrote:
> On Wed, May 11, 2011 at 2:08 AM, Peter Stuge <peter@stuge.se> wrote:
> > Graeme Russ wrote:
> >> ?- Do we care about legacy BIOS support (SeaBIOS) for now (I think
> >> ? ?not)?
> >
> > IMO it is not relevant to the integration of coreboot and U-Boot. If
> > a BIOS is needed by U-Boot itself or whatever it loads, then SeaBIOS
> > must be used as payload for coreboot, and SeaBIOS will then start
> > U-Boot after setting up the BIOS environment.
> 
> Or U-Boot could load a SeaBIOS image and initialise it if needed. So
> in a U-Boot script:
>   - If the target OS is GNU/Linux the load the Linux kernel image and go
>   - If the target OS is Windows (or any other OS which needs a BIOS) then
>     U-Boot first loads a SeaBIOS image and then loads the image for the
>     target OS (this may even be a 'GRUB' image for example)

That's possible to do, but would likely require some changes to SeaBIOS.

> > for two or three graphics chipsets. SeaBIOS can initialize any VGA
> > option ROM, but then you need SeaBIOS in the loop.
> > Option ROMs are ageold technology and stupid, but they are still
> > firmly entrenched in PC hardware. A BIOS was always there so everyone
> > assumes it will always stay there, not very many question if
> > something better could be done.
> 
> Would be interesting to investigate implementing a stub in U-Boot to
> initialise and use VGA option ROMs

VGA option ROMs call BIOS functions.  So, one needs a BIOS
implementation (eg, SeaBIOS) or an emulator for them (eg, in
coreboot).

-Kevin

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Kevin O'Connor]

On Wed, May 11, 2011 at 10:11:41AM +1000, Graeme Russ wrote:
> On Wed, May 11, 2011 at 4:03 AM, Wolfgang Denk <wd@denx.de> wrote:
> > In message <4DC94CD4.2050904@gmail.com> you wrote:
> >> ?- coreboot payloads should be in ELF (linked to libpayload)
> >
> > Is this really necessary, assuming we have a self-contained payload
> > that does not request any services from the tool that was used to
> > start it?
> 
> Question for the coreboot guys. I think the linkage to libpayload can be
> omitted, but include enough of libpayload to get to the coreboot data
> structures which can tell U-Boot vital information regarding the hardware.
> 
> Also see below - If it's loading an ELF image, can't it just pass a
> parameter which points to the tables?

Finding and parsing the coreboot tables is trivial - SeaBIOS does it
in ~170 lines of code.  See coreboot_fill_map():

http://code.coreboot.org/p/seabios/source/tree/master/src/coreboot.c#L126

Note, SeaBIOS is deployed as a coreboot payload, but it does not use
libpayload.

[...]
> >> ?- Can we add relocation support to the coreboot ELF loader?
> >
> > Do we have to?
> 
> If we want U-Boot at top-of RAM and avoid a second memcpy then yes,
> but as we know, it is not as simple as that. U-Boot relocates after it
> has determined how much upper memory to reserve which isn't known until
> U-Boot has enumerated it's hardware environment. Hence the reason U-Boot
> will always have to suffer the penalty of the extra memcpy (the bootstrap
> loader does not have enough information to reserve this memory for U-Boot)

If U-Boot can already relocate itself to top-of-ram, then I'd reuse
that - it can always be optimized later.

Note, SeaBIOS can also relocate part of itself to high memory.
(Though, SeaBIOS is pretty small, so the memcpy costs are trivial.)

-Kevin

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Graeme Russ]

Hi Kevin

On Wed, May 11, 2011 at 10:23 AM, Kevin O'Connor <kevin@koconnor.net> wrote:
> On Wed, May 11, 2011 at 09:44:00AM +1000, Graeme Russ wrote:
>> On Wed, May 11, 2011 at 2:08 AM, Peter Stuge <peter@stuge.se> wrote:
>> > Graeme Russ wrote:
>> >> ?- Do we care about legacy BIOS support (SeaBIOS) for now (I think
>> >> ? ?not)?
>> >
>> > IMO it is not relevant to the integration of coreboot and U-Boot. If
>> > a BIOS is needed by U-Boot itself or whatever it loads, then SeaBIOS
>> > must be used as payload for coreboot, and SeaBIOS will then start
>> > U-Boot after setting up the BIOS environment.
>>
>> Or U-Boot could load a SeaBIOS image and initialise it if needed. So
>> in a U-Boot script:
>> ? - If the target OS is GNU/Linux the load the Linux kernel image and go
>> ? - If the target OS is Windows (or any other OS which needs a BIOS) then
>> ? ? U-Boot first loads a SeaBIOS image and then loads the image for the
>> ? ? target OS (this may even be a 'GRUB' image for example)
>
> That's possible to do, but would likely require some changes to SeaBIOS.

I don't see why - I'm sure U-Boot could launch it in exactly the same way
coreboot does... Oh, I see - It will then start trying to boot the system
oops ;)

>
>> > for two or three graphics chipsets. SeaBIOS can initialize any VGA
>> > option ROM, but then you need SeaBIOS in the loop.
>> > Option ROMs are ageold technology and stupid, but they are still
>> > firmly entrenched in PC hardware. A BIOS was always there so everyone
>> > assumes it will always stay there, not very many question if
>> > something better could be done.
>>
>> Would be interesting to investigate implementing a stub in U-Boot to
>> initialise and use VGA option ROMs
>
> VGA option ROMs call BIOS functions. ?So, one needs a BIOS
> implementation (eg, SeaBIOS) or an emulator for them (eg, in
> coreboot).

How many functions are needed? (surely not all the IDE and keyboard stuff
for example) - Could the bare minimum be implemented in a stripped-down
modified SeaBIOS?

All this because stupid hardware manufacturers refuse to release details
of how to do even the most basic of functions with their hardware :(

Regards,

Graeme

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Peter Stuge]

Graeme Russ wrote:
> >> Would be interesting to investigate implementing a stub in U-Boot to
> >> initialise and use VGA option ROMs
> >
> > VGA option ROMs call BIOS functions. ?So, one needs a BIOS
> > implementation (eg, SeaBIOS) or an emulator for them (eg, in
> > coreboot).
> 
> How many functions are needed?

That depends completely on the particular VGA option ROM.

Having as complete a BIOS environment as can possibly be accomplished
is the only hope to making arbitrary option ROMs work.

Option ROMs are heavily tied into the BIOS concept.


> (surely not all the IDE and keyboard stuff for example)

I think I've seen some VGA option ROM get stuck waiting for
non-working keyboard BIOS services.


> - Could the bare minimum be implemented in a stripped-down modified
> SeaBIOS?

Not really.


> All this because stupid hardware manufacturers refuse to release details
> of how to do even the most basic of functions with their hardware :(

Welcome to coreboot.


//Peter

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Kevin O'Connor]

On Wed, May 11, 2011 at 10:40:23AM +1000, Graeme Russ wrote:
> On Wed, May 11, 2011 at 10:23 AM, Kevin O'Connor <kevin@koconnor.net> wrote:
> > VGA option ROMs call BIOS functions. ?So, one needs a BIOS
> > implementation (eg, SeaBIOS) or an emulator for them (eg, in
> > coreboot).
> 
> How many functions are needed? (surely not all the IDE and keyboard stuff
> for example) - Could the bare minimum be implemented in a stripped-down
> modified SeaBIOS?

The disk and keyboard drivers aren't needed to init VGA.

SeaBIOS has a Kconfig interface, and almost all features can be
disabled via that interface.

-Kevin

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Graeme Russ]

On Wed, May 11, 2011 at 10:46 AM, Peter Stuge <peter@stuge.se> wrote:
> Graeme Russ wrote:
>> >> Would be interesting to investigate implementing a stub in U-Boot to
>> >> initialise and use VGA option ROMs
>> >
>> > VGA option ROMs call BIOS functions. ?So, one needs a BIOS
>> > implementation (eg, SeaBIOS) or an emulator for them (eg, in
>> > coreboot).
>>
>> How many functions are needed?
>
> That depends completely on the particular VGA option ROM.
>
> Having as complete a BIOS environment as can possibly be accomplished
> is the only hope to making arbitrary option ROMs work.
>
> Option ROMs are heavily tied into the BIOS concept.
>
>
>> (surely not all the IDE and keyboard stuff for example)
>
> I think I've seen some VGA option ROM get stuck waiting for
> non-working keyboard BIOS services.
>
>
>> - Could the bare minimum be implemented in a stripped-down modified
>> SeaBIOS?
>
> Not really.
>
>
>> All this because stupid hardware manufacturers refuse to release details
>> of how to do even the most basic of functions with their hardware :(
>
> Welcome to coreboot.

OK, well maybe the coreboot/u-boot scenarion goes like this:

1) coreboot initialises SDRAM and other 'critical' hardware
2) coreboot launches a U-Boot payload
3) If U-Boot does not care about console output then move on and boot
   the OS
4) If U-Boot has a driver for the video hardware then use it for console
   output
5) If U-Boot does not have a driver then load SeaBIOS (modified a bit) and
   the VGA option ROM and use BIOS calls for console output

horrid, horrid, horrid

Regards,

Graeme

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Kevin O'Connor]

On Wed, May 11, 2011 at 02:46:53AM +0200, Peter Stuge wrote:
> Graeme Russ wrote:
> > >> Would be interesting to investigate implementing a stub in U-Boot to
> > >> initialise and use VGA option ROMs
> > >
> > > VGA option ROMs call BIOS functions. ?So, one needs a BIOS
> > > implementation (eg, SeaBIOS) or an emulator for them (eg, in
> > > coreboot).
> > 
> > How many functions are needed?
> 
> That depends completely on the particular VGA option ROM.
> 
> Having as complete a BIOS environment as can possibly be accomplished
> is the only hope to making arbitrary option ROMs work.
> 
> Option ROMs are heavily tied into the BIOS concept.
> 
> > (surely not all the IDE and keyboard stuff for example)
> 
> I think I've seen some VGA option ROM get stuck waiting for
> non-working keyboard BIOS services.

One will require all the BIOS interfaces, but the hardware drivers
shouldn't be needed.  So, in SeaBIOS' Kconfig menu, disabling stuff in
"BIOS interfaces" is risky, but one can pretty much disable all the
features under "General Features" and "Hardware support".

> > - Could the bare minimum be implemented in a stripped-down modified
> > SeaBIOS?
> 
> Not really.

Removing the hardware drivers and other niceties can be done.

Note that SeaBIOS is already pretty small (~96K uncompressed / 45K
compressed), so I doubt cutting out features would matter much for
size.  (In a quick test, pulling out everything but interfaces brought
the size to ~45K/24K.)  However, it could be done if one doesn't want
to bother initializing hardware (eg, USB) twice.

-Kevin

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Graeme Russ]

>> > for two or three graphics chipsets. SeaBIOS can initialize any VGA
>> > option ROM, but then you need SeaBIOS in the loop.
>> > Option ROMs are ageold technology and stupid, but they are still
>> > firmly entrenched in PC hardware. A BIOS was always there so everyone
>> > assumes it will always stay there, not very many question if
>> > something better could be done.
>>
>> Would be interesting to investigate implementing a stub in U-Boot to
>> initialise and use VGA option ROMs
>
> VGA option ROMs call BIOS functions. ?So, one needs a BIOS
> implementation (eg, SeaBIOS) or an emulator for them (eg, in
> coreboot).

What does Linux do? i.e. if you boot Linux from coreboot, how does it
output to the VGA console? I know it uses BIOS early on (before switching
to protected mode) but what does it do after entering protected mode?

Regards,

Graeme

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Kevin O'Connor]

On Wed, May 11, 2011 at 01:12:16PM +1000, Graeme Russ wrote:
> >> > for two or three graphics chipsets. SeaBIOS can initialize any VGA
> >> > option ROM, but then you need SeaBIOS in the loop.
> >> > Option ROMs are ageold technology and stupid, but they are still
> >> > firmly entrenched in PC hardware. A BIOS was always there so everyone
> >> > assumes it will always stay there, not very many question if
> >> > something better could be done.
> >>
> >> Would be interesting to investigate implementing a stub in U-Boot to
> >> initialise and use VGA option ROMs
> >
> > VGA option ROMs call BIOS functions. ?So, one needs a BIOS
> > implementation (eg, SeaBIOS) or an emulator for them (eg, in
> > coreboot).
> 
> What does Linux do? i.e. if you boot Linux from coreboot, how does it
> output to the VGA console? I know it uses BIOS early on (before switching
> to protected mode) but what does it do after entering protected mode?

In general, one enables the coreboot VGA option ROM emulation when
booting Linux directly from coreboot.

-Kevin

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Graeme Russ]

On Wed, May 11, 2011 at 1:20 PM, Kevin O'Connor <kevin@koconnor.net> wrote:
> On Wed, May 11, 2011 at 01:12:16PM +1000, Graeme Russ wrote:
>> >> > for two or three graphics chipsets. SeaBIOS can initialize any VGA
>> >> > option ROM, but then you need SeaBIOS in the loop.
>> >> > Option ROMs are ageold technology and stupid, but they are still
>> >> > firmly entrenched in PC hardware. A BIOS was always there so everyone
>> >> > assumes it will always stay there, not very many question if
>> >> > something better could be done.
>> >>
>> >> Would be interesting to investigate implementing a stub in U-Boot to
>> >> initialise and use VGA option ROMs
>> >
>> > VGA option ROMs call BIOS functions. ?So, one needs a BIOS
>> > implementation (eg, SeaBIOS) or an emulator for them (eg, in
>> > coreboot).
>>
>> What does Linux do? i.e. if you boot Linux from coreboot, how does it
>> output to the VGA console? I know it uses BIOS early on (before switching
>> to protected mode) but what does it do after entering protected mode?
>
> In general, one enables the coreboot VGA option ROM emulation when
> booting Linux directly from coreboot.
>

Yes, I understand that - But how does Linux output to the VGA console
after switching to Protected Mode? Does it still do BIOS calls?

And what about all those Linux drivers in drivers/video - Would porting
them (to U-Boot) elliminate the need for BIOS/Option ROMs

Note: Please pardon my ignorance if these appear to be dumb questions - I
really don't know how the guts of VGA console works

Regards,

Graeme

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Kevin O'Connor]

On Wed, May 11, 2011 at 01:27:30PM +1000, Graeme Russ wrote:
> On Wed, May 11, 2011 at 1:20 PM, Kevin O'Connor <kevin@koconnor.net> wrote:
> > On Wed, May 11, 2011 at 01:12:16PM +1000, Graeme Russ wrote:
> >> What does Linux do? i.e. if you boot Linux from coreboot, how does it
> >> output to the VGA console? I know it uses BIOS early on (before switching
> >> to protected mode) but what does it do after entering protected mode?
> >
> > In general, one enables the coreboot VGA option ROM emulation when
> > booting Linux directly from coreboot.
> 
> Yes, I understand that - But how does Linux output to the VGA console
> after switching to Protected Mode? Does it still do BIOS calls?
> 
> And what about all those Linux drivers in drivers/video - Would porting
> them (to U-Boot) elliminate the need for BIOS/Option ROMs

I'm not really sure - I'd guess it will vary significantly from card
to card and driver to driver.

I'm pretty sure you need to run the VGA option ROM if you want the
legacy text console mode.  However, some of the Linux/X11 drivers will
likely be able to get the card into graphics mode without running the
option ROM.

-Kevin

[U-Boot] U-Boot-x86 / coreboot Integration

[Wolfgang Denk]

Dear Graeme Russ,

In message <BANLkTi=P=H+3u+03+zyVfoUkzNFC2EPY2g@mail.gmail.com> you wrote:
>
> >>  - Is it worth playing around with segment registers to 'relocate' U-Boot
> >
> > That's a U-Boot question, right?  Let's solve this independently.
>
> Not really - If we want coreboot to place U-Boot at top-of-RAM then
> coreboot would have to figure this out. But I think this is now a moot
> point (see my other email)

I think we should start simple, like we do for example with NAND
booting systems.  Here we agree on a fixed load address for U-Boot,
too, so we can certainly do the same for Coreboot.

At least initially.  If somebody finds time and ressources this could
be added as an optimization later.

> >>  - What hardware should be initialised in coreboot and what should be
> >>    initialised in U-Boot? (political question ;)
> >
> > No, that's a very practical; question. Coreboot should do as many of
> > the x86 specific stuff as it can, and as it already does to load and
> > start other payloads.  And probably not more, at least not for now.
>
> Yes - As I mentioned in my other post, coreboot should do as much as it
> needs to (and not more) to load (arbitrary) payloads. The rest should
> be up to U-Boot using the U-Boot principle of initialising only what
> needs to be initialised.

Yes, but we also should try to avoid duplication of code - if coreboot
already includes code to initialize things that need to be
initialized, we should use this, and not duplicate the function in
U-Boot without need.

> > We are not re-inventing the wheel here.  We have many similar
> > situations where some ROM boot loader or xload or nand_spl code or
> > onenand_ipl code is loading an U-Boot image into a halfway initialized
> > system, and U-Boot starts there.  I see no need to make coreboot use a
> > different method.
>
> Except the coreboot can load ELF images and if we can avoid a memcpy by
> having coreboot do the relocation, we eek out that little bit more boot
> speed ;)

Keep things simple first, and add optimization later, when we have
everything running.  Early optimization is...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
God runs electromagnetics by wave theory on  Monday,  Wednesday,  and
Friday,  and the Devil runs them by quantum theory on Tuesday, Thurs-
day, and Saturday.                                   -- William Bragg

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Wolfgang Denk]

Dear Kevin O'Connor,

In message <20110511035148.GA14339@morn.localdomain> you wrote:
>
> > And what about all those Linux drivers in drivers/video - Would porting
> > them (to U-Boot) elliminate the need for BIOS/Option ROMs
> 
> I'm not really sure - I'd guess it will vary significantly from card
> to card and driver to driver.

Indeed.

> I'm pretty sure you need to run the VGA option ROM if you want the
> legacy text console mode.  However, some of the Linux/X11 drivers will
> likely be able to get the card into graphics mode without running the
> option ROM.

Usually you have to run the ROM init code; on many cards this is
needed for example to initialize the video RAM (well known problem,
isn't it?). Guess why the code in drivers/bios_emulator is needed in
U-Boot ?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The human mind ordinarily operates at only ten percent of its capaci-
ty - the rest is overhead for the operating system.

[U-Boot] [coreboot] U-Boot-x86 / coreboot Integration

[Rudolf Marek]

Hi all,

Sorry for the delay. I'm adding some of mine ideas for the discussion. What I 
like on u-boot is interactive command line ;) this is why I started to tickle this.

The coreboot + u-boot is a win for u-boot because it can run on then on any 
coreboot supported board (including QEMU).

 From the "target" application of use I would like to see the u-boot as kind of 
alternative bootloader/monitor, where the BIOS compatibility is NOT needed. This 
limit us most likely to just linux kernel or coreboot payloads for now. We can 
have a u-boot and SeaBIOS payload in same image.

Therefore its booting job should be just loading the image (from supported 
interfaces plus CBFS ROM image) and letting this execute.

I would go with the native drivers approach, there is a plenty of them already 
for IDE, AHCI, USB if they are usable. I discuss the libpayload stuff later. The 
BIOS emulation should be restricted as much as possible because it is not the 
goal. The VGA init can be done in coreboot, as there is similar x86 emulator for 
VGA option ROM.

Do we need interrupt system up and running? I guess there are no peripherals 
using IRQ besides PPC405?

To make u-boot and coreboot work and boot on legacy IDE, following extra code is 
needed:

x86/coreboot/sdram.c -> it just reads the coreboot tables in coreboto ROM/RAM 
stage and gets memsize for u-boot. The code can be taken from libpayload (2 
files, BSD lic) or from SeaBIOS (if relicensed to GPL v2 or later). Or written 
from scratch. This file should also move ACPI RSDP table, PIR table and MP-table 
to F0000 segment.

board/coreboot.c -> the PIC should be init before CPU irq or we get div 0
x86/coreboot/pci.c -> we tell the PCI subsystem that first usable PCI address is 
right after RAM (which is not true, but the PCI is setup already from coreboot, 
should be enough to make it work).

u-boot relocation fix:

So far my patches just put into 32MB RAM, I let it relocate to the end of memory 
which I read from coreboot tables. There is a small issue with the LMA/VMA 
problem for .bios and .realmode switch section.

This is OK so far, but both sections are loaded low and its content may be 
overwritten because they tend to be used just in the booting phase.

Maybe Graeme can fix this later.

So far not much else is needed, however for the future it would be nice to for 
example write u-boot env to flash (on x86 through upcoming libflashrom). Or 
setup coreboot CMOS variables (this can be done via libpayload).

Also not sure how advanced is the PCI SATA/IDE stuff or the USB keyboard in 
u-boot. Problem is that all this is already done in libpayload and it looks like 
a waste of time to duplicate it again.

Maybe for a start I will prepare the patches to have at least the minimal 
functionality ready, so other people might jump in. Current plan is to prepare 
patches during Coreboot hackaton in prague in two weeks.

I re-read the thread regarding the libpayload/libflashrom but could not find the 
decision how to solve this.

Thanks,
Rudolf