LinuxTag presentation highlights

[Carl-Daniel Hailfinger]

Hi,

if you know of any cool features in coreboot, flashrom, buildrom,
libpayload, coreinfo etc., please list them in response to this mail.
Since I'm working almost exclusively on v3 and flashrom, I'm bound to
miss the exciting news/features in other areas, so please help me out.

Exciting coreboot features are:
1. Almost every (free) operating system can be used as a payload in ROM
2. Having an OS in ROM means it works even if HDD/UDB/NIC are broken
3. Logging in with SSH is possible regardless of the brokenness of local
storage if the payload has a SSH server or can load one via network
4. Security against viruses/malware: If write protection for the ROM is
active (and can't be circumvented), the OS in ROM can't be compromised
5. Improved diagnostics: We don't rely on the usual cryptic and
uninformative beep codes, but output meaningful english error and debug
messages via the serial port
6. Error and status messages are saved in RAM (v3 only) and can be read
by the OS during or after boot with a dmesg-like mechanism
7. Extemely high speed: We have a record of ~600 ms from poweron to
bootloader, which is in stark contrast to the 10-30 seconds for
proprietary BIOS
8. Anything supported by the hardware can be supported by coreboot: Some
universities use the second processor socket of a dual processor board
for a FPGA instead f a processor
9. The code is written almost completely in C with ~100 lines assembly
remaining per architecture, compared to pure assembly for proprietary BIOS
10. Recompilation of the whole firmware with arbitrary features takes
10-30 seconds (v3 only)
11. You decide which features (EFI/OpenFirmware/BIOS/etc) you want, the
vendor can't limit you

Exciting flashrom features are:
1. No reboot needed for BIOS update
2. No DOS/Windows needed for BIOS update
3. Cross-flashing is possible
4. Hot-flashing is possible

Regards,
Carl-Daniel

[ron minnich]

for flashrom, you can mention that we regularly re-flashed a 1024 node
cluster in 30 seconds -- yep, averages out to 30 milliseconds per node
:-). I just talked to a Nameless Vendor two weeks ago who told me that
reflash would probably take "5 minutes per node, and was interactive
with DOS" -- this on BRAND NEW HARDWARE!

Do you want to spend 1024 * 5 or 5120 minutes or 85 hours or do you
want to spend 30 seconds? the choice is yours.

ron

[Stefan Reinauer]

On 22.05.2008, at 18:23, Carl-Daniel Hailfinger <[e-mail]
> wrote:
> Recompilation of the whole firmware with arbitrary features takes
>
> 10-30 seconds

I tweaked abuild a bit to compile in parallel. Compilation on my quad  
core machine takes 3 seconds for a full featured v2 port. A test cycle  
with the Artec LPC dongle takes 28s including compilation and flashing  
of a 8MBit image... Beat that during development with any other  
firmware :-)

Stefan

[David Hendricks]

Looks good so far. A couple more points to bring up:

12. Coreboot is highly configurable (via menu-driven Linux Kconfig) and can
be easily tailored for both server *and* embedded applications -- A single
firmware core for platforms both big and small.

13. Development and compilation are done using free/open source tools -- No
costly proprietary development tools are needed (in addition to a costly
proprietary firmware core).

On Thu, May 22, 2008 at 9:23 AM, Carl-Daniel Hailfinger <
[e-mail]> wrote:
> Hi,
>
> if you know of any cool features in coreboot, flashrom, buildrom,
> libpayload, coreinfo etc., please list them in response to this mail.
> Since I'm working almost exclusively on v3 and flashrom, I'm bound to
> miss the exciting news/features in other areas, so please help me out.
>
> Exciting coreboot features are:
> Almost every (free) operating system can be used as a payload in ROM
> Having an OS in ROM means it works even if HDD/UDB/NIC are broken
> Logging in with SSH is possible regardless of the brokenness of local
>
> storage if the payload has a SSH server or can load one via network
> 4. Security against viruses/malware: If write protection for the ROM is
> active (and can't be circumvented), the OS in ROM can't be compromised
> 5. Improved diagnostics: We don't rely on the usual cryptic and
> uninformative beep codes, but output meaningful english error and debug
> messages via the serial port
> 6. Error and status messages are saved in RAM (v3 only) and can be read
> by the OS during or after boot with a dmesg-like mechanism
> 7. Extemely high speed: We have a record of ~600 ms from poweron to
> bootloader, which is in stark contrast to the 10-30 seconds for
> proprietary BIOS
> 8. Anything supported by the hardware can be supported by coreboot: Some
> universities use the second processor socket of a dual processor board
> for a FPGA instead f a processor
> 9. The code is written almost completely in C with ~100 lines assembly
> remaining per architecture, compared to pure assembly for proprietary BIOS
> 10. Recompilation of the whole firmware with arbitrary features takes
> 10-30 seconds (v3 only)
> 11. You decide which features (EFI/OpenFirmware/BIOS/etc) you want, the
> vendor can't limit you
>
> Exciting flashrom features are:
> No reboot needed for BIOS update
> No DOS/Windows needed for BIOS update
> Cross-flashing is possible
> Hot-flashing is possible
>
> Regards,
> Carl-Daniel

[ron minnich]

Are you going to have a demo of Jordan's payload chooser?

I think it would be a real eye-opener.

ron

[Carl-Daniel Hailfinger]

On 26.05.2008 17:56, ron minnich wrote:
> Are you going to have a demo of Jordan's payload chooser?

Sure thing. I'd appreciate instructions (or a pointer to them) to
generate an image containing the chooser and maybe tint, coreinfo and
something else. I have a dongle handy, so 4MByte is the limit (but the
early init code has to enable 4MByte mode in the dongle). Due to
problems with my dongle, I was unable to debug RAM init on the dbe61, so
the demo will most likely be done with an Alix.1C. Precreated Alix.1C
images are appreciated as well, preferably accompanied by a source
tarball/svn tree/git tree.
> I think it would be a real eye-opener.

Indeed. Bayou really is one of the features in the coreboot universe
which are absolutely impressive to the end user and need to be presented
at technology showcase events like LinuxTag.

By the way, I plan to hand out CDs with precreated Alix.1C images ready
for flashing (512 kByte limit) and a snapshot of the associated source
trees. Do I have to print out the GPL on some extra paper if I supply
all sources on the same CD as the binaries? I have no ideological
problems doing so, but being able to avoid printing the GPL would allow
me to concentrate on useful stuff instead of spending time on logistics.

Regards,
Carl-Daniel

[ron minnich]

On Mon, May 26, 2008 at 9:56 AM, Carl-Daniel Hailfinger
> By the way, I plan to hand out CDs with precreated Alix.1C images ready
> for flashing (512 kByte limit) and a snapshot of the associated source
> trees. Do I have to print out the GPL on some extra paper if I supply
> all sources on the same CD as the binaries?

I can't imagine why. I've handed out GPL stuff on CD for ten years now
and never had this extra paper required of me.

thanks

ron

[Ward Vandewege]

On Mon, May 26, 2008 at 06:56:34PM +0200, Carl-Daniel Hailfinger wrote:
> By the way, I plan to hand out CDs with precreated Alix.1C images ready
> for flashing (512 kByte limit) and a snapshot of the associated source
> trees. Do I have to print out the GPL on some extra paper if I supply
> all sources on the same CD as the binaries?

Uhm, no? Why would that be necessary? Save the trees.

Thanks,
Ward.