Hi all,
I think it is time to make a reservation for the Hotel/Hostel. Is there anyone else besides Peter, Sven and Florentin? Just reminding that it take place in Prague on last weekend in May.
The Hackaton topics I have in mind:
* make netconsole work on secondary PCI buses * implement a gdb stub for coreboot * fix the u-boot patches/submit them * ... (need to get info from the attending guys)
Thanks, Rudolf
On 5/8/11 10:37 PM, Rudolf Marek wrote:
- implement a gdb stub for coreboot
Why not use the one that is there?
* Rudolf Marek r.marek@assembler.cz [110509 08:34]:
- implement a gdb stub for coreboot
Why not use the one that is there?
Yep, but it seems it does not use HW debugging features like HW watchpoints. Anyway this was just an idea.
Ah this sounds great. Just wanted to make sure you didn't miss that there already is something around that could potentially be useful. Extending the debugging functionality would be awesome.
Rudolf Marek r.marek@assembler.cz writes:
I think it is time to make a reservation for the Hotel/Hostel. Is there anyone else besides Peter, Sven and Florentin? Just reminding that it take place in Prague on last weekend in May.
Cool! Thanks for organizing this Event!
The Hackaton topics I have in mind:
- make netconsole work on secondary PCI buses
- implement a gdb stub for coreboot
- fix the u-boot patches/submit them
- ... (need to get info from the attending guys)
What i'm working on right now (i will bring the Hardware with me, if there's any interest)
- Thinkpad T4x support, which means getting the i855PM chipset supported (which is a bit different from the i855GM we have in coreboot)
- Thinkpad X61 support, i should receive a X61 motherboard this week. Uses the i965 (crestline) northbridge, which isn't supported. Not sure if i will succeed in adding support for it.
As i'm going by car to prague, i could also bring some soldering/measuring equipment with me. Not sure what we have there, and what's needed. The Logic Analyzer is rather heavy (around 90 pounds) so i'll only bring it if there's something to hack on where it would be an adavantage to have that thing :)
See you in Prague,
Sven.
Sven Schnelle wrote:
Logic Analyzer is rather heavy (around 90 pounds) so i'll only bring it if there's something to hack on where it would be an adavantage to have that thing :)
I'll bring the OLS which is very easy to pack. Not much in the way of protocol decoders, but still something.
//Peter
Hi Rudolf,
On 09/05/11 15:37, Rudolf Marek wrote:
Hi all,
I think it is time to make a reservation for the Hotel/Hostel. Is there anyone else besides Peter, Sven and Florentin? Just reminding that it take place in Prague on last weekend in May.
The Hackaton topics I have in mind:
- make netconsole work on secondary PCI buses
- implement a gdb stub for coreboot
- fix the u-boot patches/submit them
If you like, I can create a coreboot 'test and development' branch in the u-boot-x86 repository. I think I can relax the rules a little and expedite patches from your hackathon into a central u-boot git repository as a 'testing' branch isolated from mainline
After the hackathon, the coreboot patches can be cleaned up and cherry-picked into u-boot-x86 master (after posting on the u-boot mailing list of course)
Given that the license for u-boot is the same as coreboot (GPLv2 - preferably later) there should be no problem with any overlap code
Any chance we could get a bit of a design for coreboot/u-boot integration sorted before the hackathon? For example: - Formalising the u-boot payload API. For example ELF/binary, compressed/raw, passing memory size, temporary stack location, relocation, transition from u-boot back to coreboot - Can u-boot piggy-back on SeaBIOS loaded by coreboot? - Can we move more hardware init and drivers from coreboot into u-boot and provide more commands in u-boot for coreboot supported boards - VGA & Keyboard support - U-Boot splash screen support - Flash updates from u-boot
- ... (need to get info from the attending guys)
Thanks, Rudolf
I'm really looking forward to the u-boot integration :)
Regards
Graeme Russ (U-Boot x86 custodian)
Am 09.05.2011 14:18, schrieb Graeme Russ:
- Formalising the u-boot payload API. For example ELF/binary,
compressed/raw, passing memory size, temporary stack location, relocation, transition from u-boot back to coreboot
compressed/raw is nothing the payload needs to concern itself with with coreboot.
Transitioning back to coreboot doesn't happen (what for?), though we have bayou which allows handling multiple payloads with proper exit semantics.
memory size is in cbtable, payloads are ELF by convention (worst case would be to objcopy a binary uboot image into ELF to use that), stack location and relocation are payload matters (ie. nothing coreboot cares about), though optional relocation support might be provided by libpayload in the not too far future.
- Can u-boot piggy-back on SeaBIOS loaded by coreboot?
In the context of coreboot: why?
- Can we move more hardware init and drivers from coreboot into u-boot and
provide more commands in u-boot for coreboot supported boards
Code duplication? *shudder*
- VGA & Keyboard support
- U-Boot splash screen support
libpayload
- Flash updates from u-boot
libflashrom (work in progress)
Patrick
Hi Patrick
On Tue, May 10, 2011 at 3:14 AM, Patrick Georgi patrick@georgi-clan.de wrote:
Am 09.05.2011 14:18, schrieb Graeme Russ:
- Formalising the u-boot payload API. For example ELF/binary, compressed/raw, passing memory size, temporary stack location, relocation, transition from u-boot back to coreboot
compressed/raw is nothing the payload needs to concern itself with with coreboot.
Transitioning back to coreboot doesn't happen (what for?), though we have bayou which allows handling multiple payloads with proper exit semantics.
Well, I do not know the semantic architecture of coreboot :) In addition to 'boot OS and die', U-Boot has a 'standalone application' API which allows a 'payload' to be run with control returning to U-Boot. If coreboot does not have any such concept then you are right, no need to worry about returning back to coreboot
memory size is in cbtable, payloads are ELF by convention (worst case would be to objcopy a binary uboot image into ELF to use that), stack location and relocation are payload matters (ie. nothing coreboot cares about), though optional relocation support might be provided by libpayload in the not too far future.
My point being that U-Boot needs to know about the arrangement of memory of the target board. As the primary bootloader, U-Boot figures this out during SDRAM initialisation (in addition to some hard-coded board level defines in some cases). If coreboot is doing all the memory init, we need a way of telling U-Boot about the memory on the board.
The idea of adding support for relocatable ELF images to libpayload is interesting. If coreboot can load U-Boot at an appropriate target address than we can skip a memcpy and relocation fixup loop in U-Boot. Need to have a closer look at the impact of some post-relocation code such as reloading of the GDT (although off the top of my head, I don't think this will be a problem at all)
- Can u-boot piggy-back on SeaBIOS loaded by coreboot?
In the context of coreboot: why?
Again, probably a missunderstanding of coreboot on my behalf - U-Boot has a REALLY primative BIOS implementation (just enough to trick Linux into booting in an embedded environment). It is basically just some empty VGA stubs and simple e820 support. If coreboot can load SeaBIOS, U-Boot could transition to it and I could ditch all of the real-mode support from U-Boot. This could allow U-Boot to support booting of OSs that require a BIOS. For Linux, I can implement a protected mode transition from U-Boot for which we would not need to load SeaBIOS at all.
- Can we move more hardware init and drivers from coreboot into u-boot and provide more commands in u-boot for coreboot supported boards
Code duplication? *shudder*
The point being that U-Boot provides a shell and command line with diagnostic features. These require hooks into the hardware drivers.
- VGA & Keyboard support - U-Boot splash screen support
libpayload
- Flash updates from u-boot
libflashrom (work in progress)
How will these work in practice? Where are they initiated from?
Regards,
Graeme
Graeme Russ wrote:
Well, I do not know the semantic architecture of coreboot :)
Welcome to the list.
In addition to 'boot OS and die', U-Boot has a 'standalone application' API which allows a 'payload' to be run with control returning to U-Boot. If coreboot does not have any such concept then you are right, no need to worry about returning back to coreboot
coreboot does not.
memory size is in cbtable, payloads are ELF by convention
..
My point being that U-Boot needs to know about the arrangement of memory of the target board.
Yes. The information is published by coreboot in the "coreboot table" AKA cbtable. libpayload already has code to find it.
The idea of adding support for relocatable ELF images to libpayload is interesting. If coreboot can load U-Boot at an appropriate target address than we can skip a memcpy and relocation fixup loop in U-Boot.
I think the coreboot loader does this already. If U-Boot is built as an ELF located at the appropriate target address then that's where coreboot will run it from.
- Can u-boot piggy-back on SeaBIOS loaded by coreboot?
In the context of coreboot: why?
Again, probably a missunderstanding of coreboot on my behalf - U-Boot has a REALLY primative BIOS implementation (just enough to trick Linux into booting in an embedded environment). It is basically just some empty VGA stubs and simple e820 support. If coreboot can load SeaBIOS, U-Boot could transition to it and I could ditch all of the real-mode support from U-Boot.
coreboot starts one payload and one payload only. SeaBIOS when built as payload for coreboot can actually start other files in the boot flash that are identical to the coreboot payload.
The sequence would then be coreboot->SeaBIOS->U-Boot. Note that coreboot is not a BIOS and does not want to be a BIOS.
This could allow U-Boot to support booting of OSs that require a BIOS.
That should work fine if SeaBIOS is inserted before U-Boot and can set up the complete BIOS environment.
For Linux, I can implement a protected mode transition from U-Boot for which we would not need to load SeaBIOS at all.
This would be something similar to what FILO, GRUB 2 and gPXE do I guess. Even mkelfImage.
- Can we move more hardware init and drivers from coreboot into u-boot and provide more commands in u-boot for coreboot supported boards
Code duplication? *shudder*
The point being that U-Boot provides a shell and command line with diagnostic features. These require hooks into the hardware drivers.
coreboot does not generally have drivers. coreboot knows how to do the init, but the payload is responsible for driving any hardware that needs to be driven.
One could argue that coreboot is only a collection of CPU and chipset drivers, which so far have very few if any knobs.
- VGA & Keyboard support - U-Boot splash screen support
libpayload
- Flash updates from u-boot
libflashrom (work in progress)
How will these work in practice? Where are they initiated from?
coreboot starts one payload.
The payload can be very easily created with libpayload, a C library that we have created in order to make it easy to create payloads. Run lpgcc instead of gcc to link against libpayload. Some coreboot-specific functions like accessing the coreboot tables are available, and a good deal of libc compatibility.
Besides using libpayload, U-Boot would also use libflashrom, to take advantage of the rich boot flash writing code that is flashrom also at boot time.
//Peter
On Tue, May 10, 2011 at 10:30 AM, Peter Stuge peter@stuge.se wrote:
Graeme Russ wrote:
Well, I do not know the semantic architecture of coreboot :)
Welcome to the list.
Thanks
In addition to 'boot OS and die', U-Boot has a 'standalone application' API which allows a 'payload' to be run with control returning to U-Boot. If coreboot does not have any such concept then you are right, no need to worry about returning back to coreboot
coreboot does not.
OK - No need to worry about re-entering coreboot then :)
memory size is in cbtable, payloads are ELF by convention
..
My point being that U-Boot needs to know about the arrangement of memory of the target board.
Yes. The information is published by coreboot in the "coreboot table" AKA cbtable. libpayload already has code to find it.
Hmm - I don't think linking U-Boot against libpayload is the right solution. U-Boot is designed to be the primary bootloader much like coreboot is - It is not a 'payload'. There is a rather special case with NAND booting where a bootstrap loader loads U-Boot into RAM, but even in this case U-Boot is treated like a binary blob exectuted in RAM with no real concept of how it got there (i.e. no link-backs to the 'loader')
The idea of adding support for relocatable ELF images to libpayload is interesting. If coreboot can load U-Boot at an appropriate target address than we can skip a memcpy and relocation fixup loop in U-Boot.
I think the coreboot loader does this already. If U-Boot is built as an ELF located at the appropriate target address then that's where coreboot will run it from.
U-Boot is build with the target address in Flash. It initialises memory and copies itself into RAM at an address calculated by the RAM init code. It then processes the ELF symbol table (embedded in the raw binary image) to adjust memory addresses in the in-RAM copy before jumping out of flash and into RAM
So what would be really neat is if coreboot calculated where the final in-RAM location of U-Boot needs to be, copy U-Boot there, do the relocation fixups and jumps into the in-RAM copy of U-Boot. U-Boot would then skip all it's own relocation code. The other option is to not use coreboot's ELF loader and simply have coreboot jump to the U-Boot binary image in Flash. This is a far simpler method, and all the code already exists in U-Boot anyway - all we need to do is tell U-Boot the highest available memory address.
- Can u-boot piggy-back on SeaBIOS loaded by coreboot?
In the context of coreboot: why?
Again, probably a missunderstanding of coreboot on my behalf - U-Boot has a REALLY primative BIOS implementation (just enough to trick Linux into booting in an embedded environment). It is basically just some empty VGA stubs and simple e820 support. If coreboot can load SeaBIOS, U-Boot could transition to it and I could ditch all of the real-mode support from U-Boot.
coreboot starts one payload and one payload only. SeaBIOS when built as payload for coreboot can actually start other files in the boot flash that are identical to the coreboot payload.
The sequence would then be coreboot->SeaBIOS->U-Boot. Note that coreboot is not a BIOS and does not want to be a BIOS.
Neither is (or does) U-Boot. But in order to load many OSs, there needs (unfortunately) to be some BIOS functionality.
This could allow U-Boot to support booting of OSs that require a BIOS.
That should work fine if SeaBIOS is inserted before U-Boot and can set up the complete BIOS environment.
Sounds good
For Linux, I can implement a protected mode transition from U-Boot for which we would not need to load SeaBIOS at all.
This would be something similar to what FILO, GRUB 2 and gPXE do I guess. Even mkelfImage.
- Can we move more hardware init and drivers from coreboot into u-boot and provide more commands in u-boot for coreboot supported boards
Code duplication? *shudder*
The point being that U-Boot provides a shell and command line with diagnostic features. These require hooks into the hardware drivers.
coreboot does not generally have drivers. coreboot knows how to do the init, but the payload is responsible for driving any hardware that needs to be driven.
One could argue that coreboot is only a collection of CPU and chipset drivers, which so far have very few if any knobs.
U-Boot is similar, but having a command line and shell which can run scripts means that it can do a bit more with the hardware (set Ethernet MAC addresses, intialise devices on I2C busses, display a bitmap splash screen, toggle LEDs etc)
- VGA & Keyboard support - U-Boot splash screen support
libpayload
- Flash updates from u-boot
libflashrom (work in progress)
How will these work in practice? Where are they initiated from?
coreboot starts one payload.
The payload can be very easily created with libpayload, a C library that we have created in order to make it easy to create payloads. Run lpgcc instead of gcc to link against libpayload. Some coreboot-specific functions like accessing the coreboot tables are available, and a good deal of libc compatibility.
Besides using libpayload, U-Boot would also use libflashrom, to take advantage of the rich boot flash writing code that is flashrom also at boot time.
As I said earlier, I don't want to tie U-Boot to libpayload. With regard to VGA and keyboard support, how can we make them usable in U-Boot (i.e. so the command prompt is displayed on a monitor and the user can use the keyboard to enter commands?)
Regards,
Graeme
Graeme Russ wrote:
My point being that U-Boot needs to know about the arrangement of memory of the target board.
Yes. The information is published by coreboot in the "coreboot table" AKA cbtable. libpayload already has code to find it.
Hmm - I don't think linking U-Boot against libpayload is the right solution.
Why not?
U-Boot is designed to be the primary bootloader much like coreboot is - It is not a 'payload'.
If coreboot is participating then yes, U-Boot is the (coreboot) payload. The idea is to leverage the shell and bootloading features of U-Boot, after the platform initialization in coreboot has run.
There is a rather special case with NAND booting where a bootstrap loader loads U-Boot into RAM, but even in this case U-Boot is treated like a binary blob exectuted in RAM with no real concept of how it got there (i.e. no link-backs to the 'loader')
Make no mistake, coreboot payloads have no link-back to the 'loader'.
I guess this is getting a little confusing because both projects use the term payload to mean different things.
U-Boot is build with the target address in Flash. It initialises memory and copies itself into RAM at an address calculated by the RAM init code.
Here there should probably be a second possible entry point, for when U-Boot is a coreboot payload.
It then processes the ELF symbol table (embedded in the raw binary image) to adjust memory addresses in the in-RAM copy before jumping out of flash and into RAM
I guess this processing would remain, but the bytes it operates on would already be in RAM.
So what would be really neat is if coreboot calculated where the final in-RAM location of U-Boot needs to be,
This is decided at (coreboot payload) build time.
copy U-Boot there,
Sure thing.
do the relocation fixups
But possibly not this one.
and jumps into the in-RAM copy of U-Boot.
Yep.
U-Boot would then skip all it's own relocation code.
ELF is the way to happiness in coreboot land. coreboot would like a U-Boot ELF binary and will copy it to given address in RAM and run it.
The other option is to not use coreboot's ELF loader and simply have coreboot jump to the U-Boot binary image in Flash.
Does not fit the coreboot model so well. Something could be hacked of course, but that's not so nice..
This is a far simpler method, and all the code already exists in U-Boot anyway - all we need to do is tell U-Boot the highest available memory address.
That can be read from the cbtable.
coreboot does not generally have drivers. coreboot knows how to do the init, but the payload is responsible for driving any hardware that needs to be driven.
One could argue that coreboot is only a collection of CPU and chipset drivers, which so far have very few if any knobs.
U-Boot is similar, but having a command line and shell which can run scripts means that it can do a bit more with the hardware (set Ethernet MAC addresses, intialise devices on I2C busses, display a bitmap splash screen, toggle LEDs etc)
My point was that coreboot has no drivers of that sort. :)
Besides using libpayload, U-Boot would also use libflashrom, to take advantage of the rich boot flash writing code that is flashrom also at boot time.
As I said earlier, I don't want to tie U-Boot to libpayload.
Again, why not? For the particular U-Boot build that runs as coreboot payload it should save a lot of development time.
With regard to VGA and keyboard support, how can we make them usable in U-Boot (i.e. so the command prompt is displayed on a monitor and the user can use the keyboard to enter commands?)
If U-Boot will require SeaBIOS then some VGA option ROM will likely have been executed and all the standard BIOS services for console are there.
When U-Boot is the coreboot payload there are no BIOS services, and U-Boot needs to implement everything on it's own. Or it can use libpayload, which already has console support for a few hardware types.
//Peter
On Tue, May 10, 2011 at 11:15 AM, Peter Stuge peter@stuge.se wrote:
Graeme Russ wrote:
My point being that U-Boot needs to know about the arrangement of memory of the target board.
Yes. The information is published by coreboot in the "coreboot table" AKA cbtable. libpayload already has code to find it.
Hmm - I don't think linking U-Boot against libpayload is the right solution.
Why not?
a) High probablility of impacting on the U-Boot build process (you mention using lpgcc rather than gcc) b) Breaks the ethos of U-Boot being a self-contained binary image intended to be written directly to a boot Flash c) The U-Boot maintainer (Wolfgang Denk) won't allow patches that result in U-Boot relying on code external to the U-Boot git tree. All that should ever be required to build U-Boot is a pull from the U-Boot git tree and standard set of build tools (compiler and linker)
U-Boot is designed to be the primary bootloader much like coreboot is - It is not a 'payload'.
If coreboot is participating then yes, U-Boot is the (coreboot) payload. The idea is to leverage the shell and bootloading features of U-Boot, after the platform initialization in coreboot has run.
There is a rather special case with NAND booting where a bootstrap loader loads U-Boot into RAM, but even in this case U-Boot is treated like a binary blob exectuted in RAM with no real concept of how it got there (i.e. no link-backs to the 'loader')
Make no mistake, coreboot payloads have no link-back to the 'loader'.
I guess I need to understand what, exactly, libpayload is all about. I get the impression that, while not a link-back to coreboot, it does provide a set of low-level APIs (some of which provide access to data structures created by coreboot and some to access hardware features)
I guess this is getting a little confusing because both projects use the term payload to mean different things.
U-Boot does not have a 'payload' - It has a 'standalone application' which can be invoked with control returning back to U-Boot and an OS 'image' which, when invoked, typically results in U-Boot being 'blown away'
U-Boot is build with the target address in Flash. It initialises memory and copies itself into RAM at an address calculated by the RAM init code.
Here there should probably be a second possible entry point, for when U-Boot is a coreboot payload.
Already exists - It is the very first byte of u-boot.bin (which is a dozen or so bytes before the entry point used by the x86 cold-reset vector code
I mentioned in an unrelated email that the U-Boot linker script needs to be adjusted to fix the ELF entry point
It then processes the ELF symbol table (embedded in the raw binary image) to adjust memory addresses in the in-RAM copy before jumping out of flash and into RAM
I guess this processing would remain, but the bytes it operates on would already be in RAM.
So what would be really neat is if coreboot calculated where the final in-RAM location of U-Boot needs to be,
This is decided at (coreboot payload) build time.
The in-RAM location of U-Boot is dynamically determined after RAM is initialised so as to place U-Boot as high in memory as possible to allow for the maximum amount of contiuous RAM below U-Boot
copy U-Boot there,
Sure thing.
do the relocation fixups
But possibly not this one.
and jumps into the in-RAM copy of U-Boot.
Yep.
U-Boot would then skip all it's own relocation code.
ELF is the way to happiness in coreboot land. coreboot would like a U-Boot ELF binary and will copy it to given address in RAM and run it.
This is only viable if coreboot can: - Load U-Boot to an arbitrary memory address based on total available system RAM - Perform the relocation fixups (which are fairly trival to imeplement - Look in u-boot's arch/x86/lib/board.c for details) - Does not require U-Boot to be linked against libpayload (which is possibly negotiable ;)
The other option is to not use coreboot's ELF loader and simply have coreboot jump to the U-Boot binary image in Flash.
Does not fit the coreboot model so well. Something could be hacked of course, but that's not so nice..
Hmm, can we wrap u-boot.bin in a 'payload' - In U-Boot, you create an 'image' using the mkimage tool. U-Boot images support a range of formats including compressed/uncompress, raw/ELF etc. I suppose it is as close to a coreboot 'payload' as you can get, but does not carry any API for the contents of the image to use. The image content is always stand-alone with U-Boot providing the API. Correct me if I am wrong, but it would seem with coreboot that once the 'payload' is launched, coreboot is gone and the only API available is what is in libpayload
This is a far simpler method, and all the code already exists in U-Boot anyway - all we need to do is tell U-Boot the highest available memory address.
That can be read from the cbtable.
Which is only available via libpayload? - Can a link to cbtable be provided via a reserved register (perhaps a reseved segment even)
coreboot does not generally have drivers. coreboot knows how to do the init, but the payload is responsible for driving any hardware that needs to be driven.
One could argue that coreboot is only a collection of CPU and chipset drivers, which so far have very few if any knobs.
U-Boot is similar, but having a command line and shell which can run scripts means that it can do a bit more with the hardware (set Ethernet MAC addresses, intialise devices on I2C busses, display a bitmap splash screen, toggle LEDs etc)
My point was that coreboot has no drivers of that sort. :)
But it does have more code for hardware that U-Boot :) Typically U-Boot drivers are derived from Linux, so maybe coreboot's codebase is not going to be as helpful as I might have thought. The question is, does coreboot knows about any hardware that Linux does not?
Besides using libpayload, U-Boot would also use libflashrom, to take advantage of the rich boot flash writing code that is flashrom also at boot time.
As I said earlier, I don't want to tie U-Boot to libpayload.
Again, why not? For the particular U-Boot build that runs as coreboot payload it should save a lot of development time.
With regard to VGA and keyboard support, how can we make them usable in U-Boot (i.e. so the command prompt is displayed on a monitor and the user can use the keyboard to enter commands?)
If U-Boot will require SeaBIOS then some VGA option ROM will likely have been executed and all the standard BIOS services for console are there.
When U-Boot is the coreboot payload there are no BIOS services, and U-Boot needs to implement everything on it's own. Or it can use libpayload, which already has console support for a few hardware types.
OK, so I think there are three things to really look into: - Giving coreboot to ability to load a relocatable ELF image to an arbitrary RAM location and performing the necessary relocation fixups - libpayload - Console I/O in U-Boot (porting support available in libpayload into U-Boot?)
Regards,
Graeme
On 5/9/11 7:18 PM, Graeme Russ wrote:
On Tue, May 10, 2011 at 11:15 AM, Peter Stugepeter@stuge.se wrote:
Graeme Russ wrote:
My point being that U-Boot needs to know about the arrangement of memory of the target board.
Yes. The information is published by coreboot in the "coreboot table" AKA cbtable. libpayload already has code to find it.
Hmm - I don't think linking U-Boot against libpayload is the right solution.
Why not?
a) High probablility of impacting on the U-Boot build process (you mention using lpgcc rather than gcc)
FILO uses libpayload without lpgcc (and in fact I think we should obsolete lpgcc)
b) Breaks the ethos of U-Boot being a self-contained binary image intended to be written directly to a boot Flash
No. It's just a static library. Unlike uboot, it does not do any run time relocation and linking ;-)
c) The U-Boot maintainer (Wolfgang Denk) won't allow patches that result in U-Boot relying on code external to the U-Boot git tree. All that should ever be required to build U-Boot is a pull from the U-Boot git tree and standard set of build tools (compiler and linker)
Ok, I am sure politics will get in the way at some point, but that is something that should not limit our initial design.
If you build uboot for coreboot, you will have libpayload checked out anyways. So that would not be too ugly.
However, unless we start using large portions (e.g. more than 3-4 files from libpayload) we should just copy them over and not worry. Worst case we have another target we have to fix if something in libpayload changes.
This is decided at (coreboot payload) build time.
The in-RAM location of U-Boot is dynamically determined after RAM is initialised so as to place U-Boot as high in memory as possible to allow for the maximum amount of contiuous RAM below U-Boot
What's the practical use case of this? While I see a point in having stand alone applications return, a (Linux) kernel will most likely not. At least not on x86.
This is only viable if coreboot can:
- Load U-Boot to an arbitrary memory address based on total available system RAM
- Perform the relocation fixups (which are fairly trival to imeplement - Look in u-boot's arch/x86/lib/board.c for details)
- Does not require U-Boot to be linked against libpayload (which is possibly negotiable ;)
I would rather want to renegotiate adding a linker to coreboot and do that at compile time rather than runtime. The x86 CPU provides excellent features that make such a relinking unnecessary.
Hmm, can we wrap u-boot.bin in a 'payload'
Preferably I would not add additional layers/wrappers around uboot. Boot time is precious.
My point was that coreboot has no drivers of that sort. :)
But it does have more code for hardware that U-Boot :) Typically U-Boot drivers are derived from Linux, so maybe coreboot's codebase is not going to be as helpful as I might have thought. The question is, does coreboot knows about any hardware that Linux does not?
Yes, lots of it. But Linux does not need that knowledge (and neither should uboot)
I think the code in uboot might be fine except for the lack of support for PC specific components (IDE, VGA output, PS2 input, XHCI/USB3 boot, ...)
That stuff traditionally lives in libpayload (or the payload) for us, not in coreboot. Coreboot takes care of RAM controllers, HT links, PCIe links, DMI links, etc. By the time uboot runs it can assume that all necessary devices already live on what looks like a PCI bus.
OK, so I think there are three things to really look into:
- Giving coreboot to ability to load a relocatable ELF image to an arbitrary RAM location and performing the necessary relocation fixups
Can I bribe?
- libpayload
I'd be fine with just ripping what we need for now, like this:
- Console I/O in U-Boot (porting support available in libpayload into U-Boot?)
On 5/9/11 6:15 PM, Peter Stuge wrote:
Graeme Russ wrote:
U-Boot is build with the target address in Flash. It initialises memory and copies itself into RAM at an address calculated by the RAM init code.
Here there should probably be a second possible entry point, for when U-Boot is a coreboot payload.
Let's just add a compile time option and select that for a coreboot build. I don't think we need additional entry points.
KISS has always served us well.
It then processes the ELF symbol table (embedded in the raw binary image) to adjust memory addresses in the in-RAM copy before jumping out of flash and into RAM
I guess this processing would remain, but the bytes it operates on would already be in RAM.
Please, no! Why would you do something at run time on every boot when you can do it at compile/build time?
It's firmware, not an OS. (Even if popular belief claims there is no difference)
As I said earlier, I don't want to tie U-Boot to libpayload.
Again, why not? For the particular U-Boot build that runs as coreboot payload it should save a lot of development time.
I think copying over those one or two files from libpayload would allow to keep uboot without any build time dependencies, which sounds like a good thing and possibly worth the code duplication. Note that Rudolfs port already copies a small portion of libpayload code because he felt that the libpayload integration would make the code more complex than the code duplication. And I agree in this case.
If U-Boot will require SeaBIOS then some VGA option ROM will likely have been executed and all the standard BIOS services for console are there.
When U-Boot is the coreboot payload there are no BIOS services, and U-Boot needs to implement everything on it's own.
Not everything. It can rely on coreboot initializing video (and a framebuffer for example)
I think both above scenarios would make an excellent configuration choice in uboot, providing support for whatever the user wants.
On systems with SeaBIOS you probably don't care for uboot anyways as the additional benefit is rather small. On other systems where SeaBIOS is not the payload of choice uboot is much more interesting (for now)
Stefan
Stefan,
On Tue, May 10, 2011 at 2:32 PM, Stefan Reinauer stefan.reinauer@coreboot.org wrote:
On 5/9/11 6:15 PM, Peter Stuge wrote:
Graeme Russ wrote:
U-Boot is build with the target address in Flash. It initialises memory and copies itself into RAM at an address calculated by the RAM init code.
Here there should probably be a second possible entry point, for when U-Boot is a coreboot payload.
Let's just add a compile time option and select that for a coreboot build. I don't think we need additional entry points.
KISS has always served us well.
The second entry point already exists - It is an extremely small overhead in the U-Boot source and I have been using it extensively to load new images for testing into RAM and bypassing the cold-reset vector and initial setup of a temporary GDT - It's value far outweighs the expense
It then processes the ELF symbol table (embedded in the raw binary image) to adjust memory addresses in the in-RAM copy before jumping out of flash and into RAM
I guess this processing would remain, but the bytes it operates on would already be in RAM.
Please, no! Why would you do something at run time on every boot when you can do it at compile/build time?
Because U-Boot is designed to load itself into the highest possible memory address to provide a maximum RAM footprint to whatever image it loads. Also, there is no guarantee of a particular amount of RAM existing. This is not an x86 specific feature - This is a core U-Boot design principle
It's firmware, not an OS. (Even if popular belief claims there is no difference)
As I said earlier, I don't want to tie U-Boot to libpayload.
Again, why not? For the particular U-Boot build that runs as coreboot payload it should save a lot of development time.
I think copying over those one or two files from libpayload would allow to keep uboot without any build time dependencies, which sounds like a good thing and possibly worth the code duplication. Note that Rudolfs port already copies a small portion of libpayload code because he felt that the libpayload integration would make the code more complex than the code duplication. And I agree in this case.
Yes, I think small bits of libpayload could be easily integrated
If U-Boot will require SeaBIOS then some VGA option ROM will likely have been executed and all the standard BIOS services for console are there.
When U-Boot is the coreboot payload there are no BIOS services, and U-Boot needs to implement everything on it's own.
Not everything. It can rely on coreboot initializing video (and a framebuffer for example)
I think both above scenarios would make an excellent configuration choice in uboot, providing support for whatever the user wants.
On systems with SeaBIOS you probably don't care for uboot anyways as the additional benefit is rather small. On other systems where SeaBIOS is not the payload of choice uboot is much more interesting (for now)
Well I think the examination of use cases could get very interesting. For the time being, I think there are two options:
1) Load SeaBIOS and then launch U-Boot and have U-Boot use the BIOS routines provided by SeaBIOS for I/O 2) Incorporate parts of libpayload (and potentially bits of SeaBIOS implemented in 32-bit protected mode) into U-Boot and launch U-Boot directly
I think we could start with 1) and then transition to 2) over time. Note that for 2), U-Boot could also provide a very thin 'BIOS wrapper' which would translate 16-bit BIOS calls into the U-Boot core via for (optional) support of legacy applications
Regards,
Graeme
On 5/9/11 5:53 PM, Graeme Russ wrote:
Yes. The information is published by coreboot in the "coreboot table" AKA cbtable. libpayload already has code to find it.
Hmm - I don't think linking U-Boot against libpayload is the right solution. U-Boot is designed to be the primary bootloader much like coreboot is - It is not a 'payload'. There is a rather special case with NAND booting where a bootstrap loader loads U-Boot into RAM, but even in this case U-Boot is treated like a binary blob exectuted in RAM with no real concept of how it got there (i.e. no link-backs to the 'loader')
That's not the case for all platforms. On Nvidia Tegra2 there is a boot rom loading uboot. I remember on the Dbox uboot was piggybacked on the original firmware, too. At the least, uboot should play nice in such scenarios (which I think it does)
U-Boot is build with the target address in Flash. It initialises memory and copies itself into RAM at an address calculated by the RAM init code. It then processes the ELF symbol table (embedded in the raw binary image) to adjust memory addresses in the in-RAM copy before jumping out of flash and into RAM
We should add a configuration option to avoid this copying with respect to boot time.
So what would be really neat is if coreboot calculated where the final in-RAM location of U-Boot needs to be, copy U-Boot there, do the relocation fixups and jumps into the in-RAM copy of U-Boot.
Another option would be to have uboot do a virtual/physical mapping that allows us to skip the run time linking. As the copying, it's a (small but measurable) waste of time, and it makes the code unnecessarily complex. I'm not suggesting to remove this feature, but I think it should be configurable (and disabled for coreboot and anyone else who aims at booting quickly)
U-Boot would then skip all it's own relocation code. The other option is to not use coreboot's ELF loader and simply have coreboot jump to the U-Boot binary image in Flash. This is a far simpler method, and all the code already exists in U-Boot anyway - all we need to do is tell U-Boot the highest available memory address.
coreboot does its ELF parsing at build time, not at runtime. This way we save yet another copy while preserving the option of compressing the payload (e.g. uboot) in flash.
The sequence would then be coreboot->SeaBIOS->U-Boot. Note that coreboot is not a BIOS and does not want to be a BIOS.
Neither is (or does) U-Boot. But in order to load many OSs, there needs (unfortunately) to be some BIOS functionality.
Piggybacking coreboot->seabios->uboot should not be a big deal, but the most common use case for uboot is booting Linux, not Windows or other bios prone OSes. Let's do one step after another.
- Can we move more hardware init and drivers from coreboot into
u-boot and provide more commands in u-boot for coreboot supported boards
Code duplication? *shudder*
The point being that U-Boot provides a shell and command line with diagnostic features. These require hooks into the hardware drivers.
coreboot does not generally have drivers. coreboot knows how to do the init, but the payload is responsible for driving any hardware that needs to be driven.
One could argue that coreboot is only a collection of CPU and chipset drivers, which so far have very few if any knobs.
U-Boot is similar, but having a command line and shell which can run scripts means that it can do a bit more with the hardware (set Ethernet MAC addresses, intialise devices on I2C busses, display a bitmap splash screen, toggle LEDs etc)
Those things are often not available or required on the systems coreboot runs on.
- VGA& Keyboard support
- U-Boot splash screen support
libpayload
- Flash updates from u-boot
libflashrom (work in progress)
I don't think we want to plug flashrom into uboot (not in the beginning anyways) nor libpayload. Let's keep this minimal and then see what's actually missing. A clean design is more important right now than overplugging uboot with foreign libraries.
As I said earlier, I don't want to tie U-Boot to libpayload. With regard to VGA and keyboard support, how can we make them usable in U-Boot (i.e. so the command prompt is displayed on a monitor and the user can use the keyboard to enter commands?)
Does uboot provide a USB stack on PCs (e.g. UHCI/OHCI/EHCI/XHCI)... those might be interesting parts of libpayload in the longer run. For now, just adding a simple keyboard and vga driver should be fairly simple. It would be nice to also have an option for running on a linear framebuffer (with the framebuffer specs read from the coreboot table)
Stefan
On Tue, May 10, 2011 at 2:22 PM, Stefan Reinauer stefan.reinauer@coreboot.org wrote:
On 5/9/11 5:53 PM, Graeme Russ wrote:
Yes. The information is published by coreboot in the "coreboot table" AKA cbtable. libpayload already has code to find it.
Hmm - I don't think linking U-Boot against libpayload is the right solution. U-Boot is designed to be the primary bootloader much like coreboot is - It is not a 'payload'. There is a rather special case with NAND booting where a bootstrap loader loads U-Boot into RAM, but even in this case U-Boot is treated like a binary blob exectuted in RAM with no real concept of how it got there (i.e. no link-backs to the 'loader')
That's not the case for all platforms. On Nvidia Tegra2 there is a boot rom loading uboot. I remember on the Dbox uboot was piggybacked on the original firmware, too. At the least, uboot should play nice in such scenarios (which I think it does)
Yes, there are other bootstrap loaders, but U-Boot is still a raw binary image without any kind of payload wrapper as far as I am aware
U-Boot is build with the target address in Flash. It initialises memory and copies itself into RAM at an address calculated by the RAM init code. It then processes the ELF symbol table (embedded in the raw binary image) to adjust memory addresses in the in-RAM copy before jumping out of flash and into RAM
We should add a configuration option to avoid this copying with respect to boot time.
Nope - U-Boot is specifically designed to move itself into RAM - A primary reason for moving into RAM is so the ROM can be re-flashed. This is particularly neccessary when the U-Boot environment variables are embedded in the U-Boot image
So what would be really neat is if coreboot calculated where the final in-RAM location of U-Boot needs to be, copy U-Boot there, do the relocation fixups and jumps into the in-RAM copy of U-Boot.
Another option would be to have uboot do a virtual/physical mapping that allows us to skip the run time linking. As the copying, it's a (small but measurable) waste of time, and it makes the code unnecessarily complex. I'm not suggesting to remove this feature, but I think it should be configurable (and disabled for coreboot and anyone else who aims at booting quickly)
U-Boot would then skip all it's own relocation code. The other option is to not use coreboot's ELF loader and simply have coreboot jump to the U-Boot binary image in Flash. This is a far simpler method, and all the code already exists in U-Boot anyway - all we need to do is tell U-Boot the highest available memory address.
coreboot does its ELF parsing at build time, not at runtime. This way we save yet another copy while preserving the option of compressing the payload (e.g. uboot) in flash.
The sequence would then be coreboot->SeaBIOS->U-Boot. Note that coreboot is not a BIOS and does not want to be a BIOS.
Neither is (or does) U-Boot. But in order to load many OSs, there needs (unfortunately) to be some BIOS functionality.
Piggybacking coreboot->seabios->uboot should not be a big deal, but the most common use case for uboot is booting Linux, not Windows or other bios prone OSes. Let's do one step after another.
- Can we move more hardware init and drivers from coreboot into u-boot and provide more commands in u-boot for coreboot supported boards
Code duplication? *shudder*
The point being that U-Boot provides a shell and command line with diagnostic features. These require hooks into the hardware drivers.
coreboot does not generally have drivers. coreboot knows how to do the init, but the payload is responsible for driving any hardware that needs to be driven.
One could argue that coreboot is only a collection of CPU and chipset drivers, which so far have very few if any knobs.
U-Boot is similar, but having a command line and shell which can run scripts means that it can do a bit more with the hardware (set Ethernet MAC addresses, intialise devices on I2C busses, display a bitmap splash screen, toggle LEDs etc)
Those things are often not available or required on the systems coreboot runs on.
au contraire - PC's have lots of little bits and pieces (like thermal monitoring, fan speed monitoring/setting etc) - It may be very useful to have access to these from the U-Boot command line / script.
- VGA& Keyboard support - U-Boot splash screen support
libpayload
- Flash updates from u-boot
libflashrom (work in progress)
I don't think we want to plug flashrom into uboot (not in the beginning anyways) nor libpayload. Let's keep this minimal and then see what's actually missing. A clean design is more important right now than overplugging uboot with foreign libraries.
We can always run flashrom as a standalone app from U-Boot
As I said earlier, I don't want to tie U-Boot to libpayload. With regard to VGA and keyboard support, how can we make them usable in U-Boot (i.e. so the command prompt is displayed on a monitor and the user can use the keyboard to enter commands?)
Does uboot provide a USB stack on PCs (e.g. UHCI/OHCI/EHCI/XHCI)... those might be interesting parts of libpayload in the longer run.
There are USB drivers in U-Boot - It's all a question of hardware support
For now, just adding a simple keyboard and vga driver should be fairly simple. It would be nice to also have an option for running on a linear framebuffer (with the framebuffer specs read from the coreboot table)
Regards,
Graeme
On 5/9/11 4:20 PM, Graeme Russ wrote:
Again, probably a missunderstanding of coreboot on my behalf - U-Boot has a REALLY primative BIOS implementation (just enough to trick Linux into booting in an embedded environment). It is basically just some empty VGA stubs and simple e820 support.
Why don't you use the 32bit entry point of the Linux kernel? Grub2 does this (at least on coreboot), FILO and mkelfImage too.
Would be nice to (at least be able to) boot Linux without real mode code being involved.
Stefan
On Monday 09 May 2011 07:37:32 Rudolf Marek wrote:
Hi all,
I think it is time to make a reservation for the Hotel/Hostel. Is there anyone else besides Peter, Sven and Florentin? Just reminding that it take place in Prague on last weekend in May.
Hey, that's a good date as I'd be anyways in Prague. I wouldn't take the time to join the hackaton, but maybe just have a visit there.
Is there any detailed information about that event available?
Regards, Harald
The Hackaton topics I have in mind:
- make netconsole work on secondary PCI buses
- implement a gdb stub for coreboot
- fix the u-boot patches/submit them
- ... (need to get info from the attending guys)
Thanks, Rudolf
Am Montag, den 09.05.2011, 07:37 +0200 schrieb Rudolf Marek:
[…]
The Hackaton topics I have in mind:
- make netconsole work on secondary PCI buses
- implement a gdb stub for coreboot
- fix the u-boot patches/submit them
- ... (need to get info from the attending guys)
This event seems to be over. I hope you had fun.
I am very interested in what you have done and achieved. Could some of the attendees write something up? That would be awesome.
Thanks,
Paul
Hi,
I am very interested in what you have done and achieved. Could some of the attendees write something up? That would be awesome.
Oh well I thought that someone ELSE will write what we were doing. I had to wrote by myself about FOSDEM too. :)
If not then I will write about that soonish. Thanks for a ping.
Thanks Rudolf
Hello,
I wanted to reply but Rudolph was more swift than me (I'm so lazy these days! .. ;-)), but I can give you my travel impressions.. The hackathon in Prague proceeded very well, the organisation was excellent and we have been well received by Rudolph.
I arrived by car from France Friday evening. My journey was approximatively 14 hours from Paris to Prague. Unfortunately for me, it wasn't possible for me to stay 2 full days (so many personal projects pending!!..), so I had to quit early Sunday.
The accomodation was in the Masarykova dormitory of the CVUT University of Prague (the University of Rudolph), and it was OK (even if it was "student style" ;-))
On the technical side, Rudolph succeded to reserve a classroom in his University, so we installed our stuff early Saturday and began to work: - Rudolph on the integration of U-Boot with coreboot; - Christi focused mostly on the cleaning and reorganisation of some coreboot code, but I don't remember very well what (Christi can you give more details?) - Sven and Bjärne worken with the T60 laptop coreboot port (again I'm not sure: can you give more details?); - for Peter I don't remember what was his topic of interest but he helped me very heavily for my board: - my objective was to install coreboot on my new board MA785GMT-UDH2. I had bring with me a Phenom II 1055T CPU with 6 cores. Unfortunately I met big problems because: * the factory BIOS version (F4) wasn't fit for this kind of CPU, so I was unable to boot the board even with the factory BIOS, so no flashrom solution for installing coreboot; * Peter helped me to "socketise" the BIOS chip and Sven helped me with his external programmer, but unfortunately the curent release of coreboot didn' work => it crashed at some stage in early initialisation (romstage.c?) before microcode update if I remember well..
To conclude, globally this hackaton was great for me even if I didn't get great results on the technical side, but the oportunity to meet and work with other coreboot people greatly offsets those technical drawbacks..
Thank you again friends and especially you Rudolph for this great event! Hope I see you soon at the next coreboot hackaton! Florentin
PS : a friend of mine gave me a Phenom II with 4 cores so I was able to update the factory BIOS (I installed the F6 revision), and the board boots flawlessly with the factory bios even with my 6 core Phenom II cpu! So it is NOT a power supply problem Rudolph and Peter.. ;-). I didn't had the time to reinstall coreboot and give it a run, but I will do that ASAP! Also I will investigate the problem of the 6 core Phenom II on this board..
Quoting Rudolf Marek r.marek@assembler.cz:
Hi,
I am very interested in what you have done and achieved. Could some of the attendees write something up? That would be awesome.
Oh well I thought that someone ELSE will write what we were doing. I had to wrote by myself about FOSDEM too. :)
If not then I will write about that soonish. Thanks for a ping.
Thanks Rudolf
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Sat, Jul 09, 2011 at 05:04:43PM +0200, Florentin Demetrescu wrote:
- my objective was to install coreboot on my new board MA785GMT-UDH2. I had
bring with me a Phenom II 1055T CPU with 6 cores. Unfortunately I met big problems because:
[...]
coreboot and give it a run, but I will do that ASAP! Also I will investigate the problem of the 6 core Phenom II on this board..
Isn't it a fam 10 revision E CPU ?
Coreboot did not have any code specific for Fam 10 rev E last time I checked (mid feb 2011) (no errata workarounds, no specific initialization, just a small untested part in fidvid.c). There wasn't even a constant defined for rev E.
Back in August 2010 I asked how to extend the revision bitfield that's used as a trigger for rule based initializations and workarounds, and in a small thread it was suggested to get rid of it and use a struct, but I never did. http://www.coreboot.org/pipermail/coreboot/2010-August/059701.html
On Tue, Jul 12, 2011 at 10:18 AM, xdrudis xdrudis@tinet.cat wrote:
On Sat, Jul 09, 2011 at 05:04:43PM +0200, Florentin Demetrescu wrote:
- my objective was to install coreboot on my new board MA785GMT-UDH2. I had bring with me a Phenom II 1055T CPU with 6 cores. Unfortunately I met big problems because:
[...]
coreboot and give it a run, but I will do that ASAP! Also I will investigate the problem of the 6 core Phenom II on this board..
Isn't it a fam 10 revision E CPU ?
Coreboot did not have any code specific for Fam 10 rev E last time I checked (mid feb 2011) (no errata workarounds, no specific initialization, just a small untested part in fidvid.c). There wasn't even a constant defined for rev E.
Back in August 2010 I asked how to extend the revision bitfield that's used as a trigger for rule based initializations and workarounds, and in a small thread it was suggested to get rid of it and use a struct, but I never did. http://www.coreboot.org/pipermail/coreboot/2010-August/059701.html
The C32 support might handle rev E. I don't know if there is much different from rev D (bigger differences between revC and revD). If more support is required, there may be some updates from AMD in the future.
Marc
-----Original Message----- From: coreboot-bounces@coreboot.org
[mailto:coreboot-bounces@coreboot.org]
On Behalf Of xdrudis Sent: Wednesday, July 13, 2011 12:18 AM To: Florentin Demetrescu Cc: coreboot@coreboot.org Subject: [coreboot] AMD Phenom II 1055T was : Hackaton in Prague 2011
On Sat, Jul 09, 2011 at 05:04:43PM +0200, Florentin Demetrescu wrote:
- my objective was to install coreboot on my new board
MA785GMT-UDH2. I
had
bring with me a Phenom II 1055T CPU with 6 cores. Unfortunately I
met big
problems because:
[...]
coreboot and give it a run, but I will do that ASAP! Also I will
investigate the
problem of the 6 core Phenom II on this board..
Isn't it a fam 10 revision E CPU ?
Coreboot did not have any code specific for Fam 10 rev E last time I checked (mid feb 2011) (no errata workarounds, no specific initialization, just a small untested part in fidvid.c). There wasn't even a constant defined for rev E.
Back in August 2010 I asked how to extend the revision bitfield that's used as a trigger for rule based initializations and workarounds, and in a small thread it was suggested to get rid of it and use a struct, but I never did. http://www.coreboot.org/pipermail/coreboot/2010-August/059701.html
AMD Family10 RevE support code was just added into Coreboot a few weeks ago, Please check http://review.coreboot.org/40 in detail, The RevD support code are ready, and will release soon. I think it's not hard to implement RevE, by using the RevD as an reference. thanks -- Kerry
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Xavi, Kerry and Marc, Tahnk you very much for these advices! This will facilitate greatly my work.. Concerning my coreboot tests on MA785GMT-UDH2 with Phenom II 1055T, I hope to be able to give you a feedback next week. Thank you again! Florentin Demetrescu
Quoting "She, Kerry" Kerry.She@amd.com:
-----Original Message----- From: coreboot-bounces@coreboot.org
[mailto:coreboot-bounces@coreboot.org]
On Behalf Of xdrudis Sent: Wednesday, July 13, 2011 12:18 AM To: Florentin Demetrescu Cc: coreboot@coreboot.org Subject: [coreboot] AMD Phenom II 1055T was : Hackaton in Prague 2011
On Sat, Jul 09, 2011 at 05:04:43PM +0200, Florentin Demetrescu wrote:
- my objective was to install coreboot on my new board
MA785GMT-UDH2. I
had
bring with me a Phenom II 1055T CPU with 6 cores. Unfortunately I
met big
problems because:
[...]
coreboot and give it a run, but I will do that ASAP! Also I will
investigate the
problem of the 6 core Phenom II on this board..
Isn't it a fam 10 revision E CPU ?
Coreboot did not have any code specific for Fam 10 rev E last time I checked (mid feb 2011) (no errata workarounds, no specific initialization, just a small untested part in fidvid.c). There wasn't even a constant defined for rev E.
Back in August 2010 I asked how to extend the revision bitfield that's used as a trigger for rule based initializations and workarounds, and in a small thread it was suggested to get rid of it and use a struct, but I never did. http://www.coreboot.org/pipermail/coreboot/2010-August/059701.html
AMD Family10 RevE support code was just added into Coreboot a few weeks ago, Please check http://review.coreboot.org/40 in detail, The RevD support code are ready, and will release soon. I think it's not hard to implement RevE, by using the RevD as an reference. thanks -- Kerry
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-
Florentin Demetrescu -
Graeme Russ -
Harald Gutmann -
Marc Jones -
Patrick Georgi -
Paul Menzel -
Peter Stuge -
Rudolf Marek -
She, Kerry -
Stefan Reinauer -
Sven Schnelle -
xdrudis