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
From there, we can start to add device support (USB, video, PCI, IDE/SATA etc)
It's getting late, so I'll stop now. Hopefully this gives a good design platform to start from
Regards,
Graeme
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 :(
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
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
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.
From http://www.coreboot.org/Development_Guidelines#License_Issues
Contributed code must be GPL'd (preferably 'GPLv2 or any later version', but 'GPLv2' is fine, too). At the very minimum the code must have a GPL-compatible license.
But yes, I image a lot of the code predates this preference, much like a lot of U-Boot code does
Now the politics ;) - The U-Boot source 'must' be self contained - No external libraries. Incorporating license compatible source is OK
Well ok.. (why though?)
Because that's the way Wolfgang likes it ;)
- 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.
I think what will end up happening is porting enough of libpayload across to U-Boot in order to get access to coreboot data structures. Everything else either already exists in U-Boot (libc functionality) or can be added using existing U-Boot architectural principals (USB keyboard, VGA support etc)
- 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.
That's an issue for the coreboot team - sounds sensible enough
- 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.
I tend to use a pure breed toolchain (I build GCC and binutils from scratch and don't use the disto's toolchain)
- 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.
As Wolfgang has commented on in another post in this thread, there are some pretty solid reasons behind this rationale. These reasons may be more applicable to ARM/PPC embedded environments and possibly irrelevant in the x86/PC world. Although this 'feature' is currently implemented on a per-CPU architecture basis, this may change in the future - It's worth keeping in mind so nobody gets blindsided
- 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)
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.
Thought so - So we just port this bit
- 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.
U-Boot already has USB support framework - just a matter of writing device drivers for the chipset hardware
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
Or if U-Boot does
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
Do other U-Boot boards implement console on anything other than serial?
U-Boot? Can't say.
From Wolfgang : Yes
- 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?
On further though, probably not. The Linux protected mode entry point requires a very specific segment setup - Using segments to 'relocate' U-Boot is only going to make things very ugly, very quickly
- 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.
Agree - Have coreboot do the bare minimum to launch an arbitrary payload and leave the rest up to U-Boot
- 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.
Yes, I think CMC and SMM should be loaded by U-Boot. It may be necessary for some boards to have CMC loaded by coreboot in order to bring SDRAM controllers up
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. :)
But involves a double memcpy - A decision for later
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.
Hmm, I'm thinking these should be implemented in U-Boot. I'm keeping embedded x86 solutions in mind - I want to maintain the idea of U-Boot being a primary bootloader for these systems and not rely on coreboot / libpayload / SeaBIOS etc
Regards,
Graeme
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-
Graeme Russ -
Kevin O'Connor -
Peter Stuge -
Rudolf Marek -
Wolfgang Denk