I got a brief UEFI introduction. It seems that it is pretty close to coreboot.
They have same goal and face same problem. Any idea?
Zheng _________________________________________________________________ Windows Live™: Keep your life in sync. Check it out! http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009
On 23.09.2009 15:29, Zheng Bao wrote:
I got a brief UEFI introduction. It seems that it is pretty close to coreboot.
They have same goal and face same problem. Any idea?
I think there are quite some differences which make coreboot the better solution: - The lowlevel parts of UEFI are closed source. - UEFI is bigger/bloated. - UEFI stays resident in memory. - UEFI has to provide network/disk/video drivers which can/should be used by the OS.
And if someone really wants EFI functionality, it is possible to run UEFI as a coreboot payload. Besides that, if you want a completely opensource firmware with UEFI, you have to use coreboot+UEFI because the chipset/CPU init in UEFI is not open source.
Regards, Carl-Daniel
The killer for uefi for me are the security concerns.
For many outfits, nowadays, the closed nature, and the limited control, of UEFI is worrisome.
Here's a simple rule: open source almost always wins. I've seen almost no exceptions save maybe in compilers, and that only in special cases. Open source is the water that wears down the rock.
There's more and more interest in the last two years in coreboot. Customers really want it.
It's just that PC vendors are worried about providing it for some reason.
PC vendors need to be careful, they're building closed ecosystems now around the PC platform. It's quite amazing how much more closed the PC platform is than it was in 1994 or even 1999.
Closed ecosystems die.
Here at linuxcon and other recent conferences, all the real innovation and cool stuff is ARM-based. PCs are those big, expensive, hot, closed things that you're not allowed to hack. Really wonderful stuff being done on OMAP 35.
ron
Hello Ron,
ron minnich wrote (ao):
There's more and more interest in the last two years in coreboot. Customers really want it.
It's just that PC vendors are worried about providing it for some reason.
PC vendors need to be careful, they're building closed ecosystems now around the PC platform. It's quite amazing how much more closed the PC platform is than it was in 1994 or even 1999.
Closed ecosystems die.
Here at linuxcon and other recent conferences, all the real innovation and cool stuff is ARM-based. PCs are those big, expensive, hot, closed things that you're not allowed to hack. Really wonderful stuff being done on OMAP 35.
Pardon my ignorance, but there is no Coreboot for ARM based hardware AFAICS?
On the OpenMoko Freerunner one boots with 'u-boot'. U-boot is a bootloader, and as such not comparable with Coreboot I think. Does ARM have BIOS firmware at all? I've googled but failed to find the answer.
Please feel free to ignore me is this is too off topic.
Sander
Sander wrote:
On the OpenMoko Freerunner one boots with 'u-boot'.
Or Qi: http://wiki.openmoko.org/wiki/Qi
Does ARM have BIOS firmware at all?
No. BIOS is strictly a PC thing. ARM does have firmware to boot the system, but it can not be called BIOS.
But please note that coreboot is not a BIOS. coreboot does only hardware initialization. After coreboot follows another component which takes over, and can do whatever it wants. This component is called the payload.
There are bootloader payloads with drivers for hard drives, CD-ROMs and network cards. The Linux kernel can be used as payload, and a few other operating system kernels as well. There is also a BIOS payload, which is called SeaBIOS. Please see http://www.coreboot.org/Payloads for more information. Combining coreboot with SeaBIOS gets you an open source version of a legacy BIOS. Combining coreboot with something else gets you a whole new way of booting PCs.
Kind regards
//Peter
On 29.09.2009 13:55, Peter Stuge wrote:
Sander wrote:
On the OpenMoko Freerunner one boots with 'u-boot'.
Or Qi: http://wiki.openmoko.org/wiki/Qi
[...]coreboot does only hardware initialization. After coreboot follows another component which takes over, and can do whatever it wants. This component is called the payload.
I'd say Qi is similar to coreboot+FILO without all the extra features something like U-Boot would provide. The Qi goal was to be fast, simple and lightweight and load Linux. Given that coreboot is pretty PCI centric (and has no ARM port), coreboot was not the best possible patch for OpenMoko.
Regards, Carl-Daniel
ron minnich wrote (ao):
There's more and more interest in the last two years in coreboot. Customers really want it.
It's just that PC vendors are worried about providing it for some reason.
PC vendors need to be careful, they're building closed ecosystems now around the PC platform. It's quite amazing how much more closed the PC platform is than it was in 1994 or even 1999.
Closed ecosystems die.
Here at linuxcon and other recent conferences, all the real innovation and cool stuff is ARM-based. PCs are those big, expensive, hot, closed things that you're not allowed to hack. Really wonderful stuff being done on OMAP 35.
Sander wrote:
Pardon my ignorance, but there is no Coreboot for ARM based hardware AFAICS?
On the OpenMoko Freerunner one boots with 'u-boot'. U-boot is a bootloader, and as such not comparable with Coreboot I think. Does ARM have BIOS firmware at all? I've googled but failed to find the answer.
Das U-Boot is directly comparable to coreboot. U-Boot is almost always used on non-x86 architectures, but it does a similar sort of hardware initialization on those architectures that coreboot does on x86 architectures. U-Boot does not have a payload structure like coreboot, but U-Boot can load executables (usually an operating system) and U-Boot scripts. U-Boot has a TCP/IP stack and USB stack, a system of drivers, maintains a non-volatile set of environment variables, etc. It is a reasonably well designed system that is more often than not used as a bootloader with full boot device initialization for non-x86 architectures.
I suggest that coreboot designers look at how U-Boot is designed, and conversely U-Boot designers look at how coreboot is designed. I know that some have already done this. Perhaps both projects have done some things better than the other and can share ideas and even higher level architecture independent code.
http://en.wikipedia.org/wiki/Das_U-Boot
Sincerely,
Ken Fuchs
Ken.Fuchs@bench.com wrote:
I suggest that coreboot designers look at how U-Boot is designed,
I understand that at least previous versions of U-Boot were not so nice to look at.
I did discuss with Denx about running the non-hardware-specific part of U-Boot as a payload. They were not uninterested.
//Peter
Peter Stuge wrote:
Ken.Fuchs@bench.com wrote:
I suggest that coreboot designers look at how U-Boot is designed,
I understand that at least previous versions of U-Boot were not so nice to look at.
I did discuss with Denx about running the non-hardware-specific part of U-Boot as a payload. They were not uninterested.
There is a new, Denx-independent branch of u-boot from Pengutronix which we've been using on custom ARM based hardware: u-boot v2.
It has a few less features, but a considerably nicer design. And, the Pengutronix folks seemed very interested to see it happen as a coreboot payload. I think this would be a real improvement for both projects, coreboot (nice and slim, standardized user interface, could replace FILO) as well as u-boot (access to the x86 world without re-implementing the wheel).
I had this on my TODO, but there's been too much other stuff so far. Yet I would love to see this happen. Maybe we get the momentum together?
All the best, Stefan
Stefan Reinauer wrote:
I suggest that coreboot designers look at how U-Boot is designed,
I understand that at least previous versions of U-Boot were not so nice to look at.
I did discuss with Denx about running the non-hardware-specific part of U-Boot as a payload. They were not uninterested.
There is a new, Denx-independent branch of u-boot from Pengutronix which we've been using on custom ARM based hardware: u-boot v2.
It has a few less features, but a considerably nicer design. And, the Pengutronix folks seemed very interested to see it happen as a coreboot payload.
Yes, I've talked a lot with Wolfgang about coreboot, at several events. Maybe it was even Pengutronix people rather than Denx people I had a chat with at embeddedworld? Hmm. :)
I think this would be a real improvement for both projects, coreboot (nice and slim, standardized user interface, could replace FILO) as well as u-boot (access to the x86 world without re-implementing the wheel).
Agree.
I had this on my TODO, but there's been too much other stuff so far. Yet I would love to see this happen. Maybe we get the momentum together?
So many things TODO.. :\
What does u-boot v2 need from coreboot?
//Peter
Peter Stuge wrote:
So many things TODO.. :\
Yes, I thought about emigrating to Venus, days have ~5832.5 hours there.
What does u-boot v2 need from coreboot?
Basically one thing is crucial: u-boot-v2 has no x86 support as we speak. The architecture support would require some libgcc functions, probably memcpy etc, a linker script and some Kconfig changes. There could be a generic coreboot "board" with (almost) no hardware init.
The next thing is to get the amount of available RAM from the coreboot table, a serial driver, etc. It might be worthwhile to consider linking against libpayload for that, as it'll provide an UHCI stack, too.
After that, it would be interesting to look into flash drivers, to be able to use ubootenv for variables, etc. Maybe CBFS support etc.
Stefan
Hi Peter, Hi Stefan,
[adding Sascha Hauer to the Cc: list, as he is the maintainer of u-boot-v2]
On Tue, Sep 29, 2009 at 11:49:32PM +0200, Peter Stuge wrote:
I did discuss with Denx about running the non-hardware-specific part of U-Boot as a payload. They were not uninterested.
U-Boot-v2 can be run as a completely hardware-init less payload; in fact, there are already two scenarios where we actually do that:
- sandbox: you can compile u-boot-v2 to run in POSIX userspace; this is mainly used for testing the command part
- 2nd stage booting: We sometimes use u-boot-v2 as a second stage ontop of for example u-boot-v1, in order to get the scripting environment running on systems where we don't have the time/need to develop the lowlevel initialization (i.e. development boards where v1 is already there and the adaption will be finally done on the custom hw).
It has a few less features, but a considerably nicer design. And, the Pengutronix folks seemed very interested to see it happen as a coreboot payload.
Yes, that would really be interesting.
Yes, I've talked a lot with Wolfgang about coreboot, at several events. Maybe it was even Pengutronix people rather than Denx people I had a chat with at embeddedworld? Hmm. :)
Maybe :)
I think this would be a real improvement for both projects, coreboot (nice and slim, standardized user interface, could replace FILO) as well as u-boot (access to the x86 world without re-implementing the wheel).
Agree.
We are definitely interested.
I had this on my TODO, but there's been too much other stuff so far. Yet I would love to see this happen. Maybe we get the momentum together?
So many things TODO.. :\
What does u-boot v2 need from coreboot?
Hardware initialization, plus maybe some interface which can be used to find out about the hardware parts you want to use in the boot process.
Can you elaborate about your use case?
Robert
-
Carl-Daniel Hailfinger -
Ken.Fuchs＠bench.com -
Peter Stuge -
Robert Schwebel -
ron minnich -
Sander -
Stefan Reinauer -
Zheng Bao