Roy Bamford wrote:
> > > I take it the above statement is based on the kernel being
> > > directly placed within the BIOS/firmware/nvram on the board,

This is sometimes called Linux-as-bootloader (LAB/lab for short) in
the coreboot project.


> > > such that you couldn't boot anything else but that kernel?

Yes and no. A kernel can kexec() another program.


> So when you build a dud kernel and flash your BIOS with it, and we
> all build the odd dud, your motherboard is bricked.

Any firmware modification has potential to brick, and shouldn't be
done unless you are comfortable with the modification, or with
solving a brick problem.

Keep backup flash chips, if your boot flash is socketed.

There are also several software techniques to eliminate and/or
reduce the brick risk.

Again, if you flash nothing but a kernel into the boot flash then
the machine will just laugh at you in your face and not start.

coreboot has infrastructure for separating normal boot from fallback
boot, for when the normal boot fails.

Writing to the flash chip is not an all-or-nothing operation.
coreboot uses a super simple filesystem for the boot flash, which can
be aligned to eraseblocks in the flash chip, such that only ever the
normal boot "files" are erased and rewritten, while leaving fallback
contents untouched. Even a power outage during flashing will not
brick your machine.


> Get out your JTAG adaptor and another PC I suppose.

PCs don't usually have JTAG as convenient as embedded systems, but
the boot flash can always be written with other suitable dedicated
hardware, from "the outside", as you write.


//Peter

On Thu, Jun 21, 2012 at 3:10 PM, Peter Stuge <peter@stuge.se> wrote:
> Roy Bamford wrote:
>
>> So when you build a dud kernel and flash your BIOS with it, and we
>> all build the odd dud, your motherboard is bricked.
>
> Any firmware modification has potential to brick, and shouldn't be
> done unless you are comfortable with the modification, or with
> solving a brick problem.

So, why are we still going back and forth about this? If people want
to work on coreboot they can do so (I'm sure they have a list). If
people want to fork coreboot or redo it from scrach they can do so and
start their own list.

When it is shiny and perfect and has a following of hundreds of linux
users we can always discuss whether we recommend using it in the
handbook on -dev then. Otherwise it seems about as on-topic as
debating whether grub or systemd or openrc should have feature A/B/C -
we're a DISTRO - we integrate and ship what upstream gives us...

Rich

On 06/21/2012 06:51 PM, Rich Freeman wrote:
> On Thu, Jun 21, 2012 at 3:10 PM, Peter Stuge <peter@stuge.se> wrote:
>> Roy Bamford wrote:
>>
>>> So when you build a dud kernel and flash your BIOS with it, and we
>>> all build the odd dud, your motherboard is bricked.
>>
>> Any firmware modification has potential to brick, and shouldn't be
>> done unless you are comfortable with the modification, or with
>> solving a brick problem.
>
> So, why are we still going back and forth about this?

This idea has technical merit and it has sparked a very insightful
discussion in which I learned many things that I did not know. My
original intention in emailing the list was to learn such things, so my
email has fulfilled its purpose.

My email has also led to an interesting off list conversation between
myself and Peter about this. I believe that the exchange of ideas that
this prompted has been mutually beneficial. My hope is that our
discussion catalyzes improvements in both Gentoo and coreboot.

On 06/21/2012 06:51 PM, Rich Freeman wrote:
> we're a DISTRO - we integrate and ship what upstream gives us...

RHEL is a distribution, but I understand that RedHat does a great deal
of upstream programming and is also upstream for some things. Do you
consider it to be inappropriate for us to play a larger role in both
upstream development and as upstream ourselves?

Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted:

> A firmware replacement for the BIOS does not need to worry about floppy
> drives, hard drives, optical drives, usb devices, isa devices, pci
> devices and pci express drives, etcetera, because those live on buses,
> which the kernel can detect.

But you have to be able to load the kernel first, before it can do all
that detection. And to load it, you need to be able to read the device
it's located on, which in a modern x86 system (as contrasted with mips/
arm) generally means detection of what's there, some mechanism to choose
which available devices to check for a kernel or boot loader or whatever,
and some way to dynamically configure it, since many devices are simply
(device info probable) bricks until configured, these days.

Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian
S suggested), but then you're back to hard-configuring it in ordered to
do so, thus losing all that extra flexibility that's part of what makes
x86 different. Which was the question that I was addressing.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On 06/22/2012 01:02 AM, Duncan wrote:
> Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted:
>
>> A firmware replacement for the BIOS does not need to worry about floppy
>> drives, hard drives, optical drives, usb devices, isa devices, pci
>> devices and pci express drives, etcetera, because those live on buses,
>> which the kernel can detect.
>
> But you have to be able to load the kernel first, before it can do all
> that detection. And to load it, you need to be able to read the device
> it's located on, which in a modern x86 system (as contrasted with mips/
> arm) generally means detection of what's there, some mechanism to choose
> which available devices to check for a kernel or boot loader or whatever,
> and some way to dynamically configure it, since many devices are simply
> (device info probable) bricks until configured, these days.
>
> Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian
> S suggested), but then you're back to hard-configuring it in ordered to
> do so, thus losing all that extra flexibility that's part of what makes
> x86 different. Which was the question that I was addressing.
>

Placing it in the firmware is what I suggested. I also later stated that
it is possible for the firmware to contain an initramfs that would
enable it to start a kernel located on a device.

It seems to me that this would work if device trees for motherboards
were readily available and the EEPROM chips have sufficient capacity. I
am under the impression that UEFI firmware is large enough that capacity
on UEFI motherboards should not be an issue. The main issue would be
obtaining device trees.

On 06/22/2012 01:10 AM, Richard Yao wrote:
> On 06/22/2012 01:02 AM, Duncan wrote:
>> Richard Yao posted on Thu, 21 Jun 2012 05:33:22 -0400 as excerpted:
>>
>>> A firmware replacement for the BIOS does not need to worry about floppy
>>> drives, hard drives, optical drives, usb devices, isa devices, pci
>>> devices and pci express drives, etcetera, because those live on buses,
>>> which the kernel can detect.
>> But you have to be able to load the kernel first, before it can do all
>> that detection. And to load it, you need to be able to read the device
>> it's located on, which in a modern x86 system (as contrasted with mips/
>> arm) generally means detection of what's there, some mechanism to choose
>> which available devices to check for a kernel or boot loader or whatever,
>> and some way to dynamically configure it, since many devices are simply
>> (device info probable) bricks until configured, these days.
>>
>> Sure, you can boot directly to a Linux kernel /as/ your firmware (as Ian
>> S suggested), but then you're back to hard-configuring it in ordered to
>> do so, thus losing all that extra flexibility that's part of what makes
>> x86 different. Which was the question that I was addressing.
>>
> Placing it in the firmware is what I suggested. I also later stated that
> it is possible for the firmware to contain an initramfs that would
> enable it to start a kernel located on a device.
>
> It seems to me that this would work if device trees for motherboards
> were readily available and the EEPROM chips have sufficient capacity. I
> am under the impression that UEFI firmware is large enough that capacity
> on UEFI motherboards should not be an issue. The main issue would be
> obtaining device trees.
>
Before anyone says it, information on how to initialize the memory
controller and possibly a few other bits prior to loading the kernel is
also necessary. I omitted that by mistake.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 21/06/12 08:24 PM, Richard Yao wrote:
> On 06/21/2012 06:51 PM, Rich Freeman wrote:
>> we're a DISTRO - we integrate and ship what upstream gives us...
>
> RHEL is a distribution, but I understand that RedHat does a great
> deal of upstream programming and is also upstream for some things.
> Do you consider it to be inappropriate for us to play a larger role
> in both upstream development and as upstream ourselves?
>

As a gentoo developer in general? Absolutely not. Through discussion
on this list specifically? possibly.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/kbQEACgkQ2ugaI38ACPDCrAEAquDX0hrTUufGqXhSG2Cv+yLU
bmw3WpMa17OHSmbZ+3QA/Am2K80tHFGDA7uklTUm6Lxe8wynVRTNrmpD93qTlJ4R
=gO47
-----END PGP SIGNATURE-----