1 |
Roy Bamford wrote: |
2 |
> > > I take it the above statement is based on the kernel being |
3 |
> > > directly placed within the BIOS/firmware/nvram on the board, |
4 |
|
5 |
This is sometimes called Linux-as-bootloader (LAB/lab for short) in |
6 |
the coreboot project. |
7 |
|
8 |
|
9 |
> > > such that you couldn't boot anything else but that kernel? |
10 |
|
11 |
Yes and no. A kernel can kexec() another program. |
12 |
|
13 |
|
14 |
> So when you build a dud kernel and flash your BIOS with it, and we |
15 |
> all build the odd dud, your motherboard is bricked. |
16 |
|
17 |
Any firmware modification has potential to brick, and shouldn't be |
18 |
done unless you are comfortable with the modification, or with |
19 |
solving a brick problem. :) |
20 |
|
21 |
Keep backup flash chips, if your boot flash is socketed. |
22 |
|
23 |
There are also several software techniques to eliminate and/or |
24 |
reduce the brick risk. |
25 |
|
26 |
Again, if you flash nothing but a kernel into the boot flash then |
27 |
the machine will just laugh at you in your face and not start. |
28 |
|
29 |
coreboot has infrastructure for separating normal boot from fallback |
30 |
boot, for when the normal boot fails. |
31 |
|
32 |
Writing to the flash chip is not an all-or-nothing operation. |
33 |
coreboot uses a super simple filesystem for the boot flash, which can |
34 |
be aligned to eraseblocks in the flash chip, such that only ever the |
35 |
normal boot "files" are erased and rewritten, while leaving fallback |
36 |
contents untouched. Even a power outage during flashing will not |
37 |
brick your machine. |
38 |
|
39 |
|
40 |
> Get out your JTAG adaptor and another PC I suppose. |
41 |
|
42 |
PCs don't usually have JTAG as convenient as embedded systems, but |
43 |
the boot flash can always be written with other suitable dedicated |
44 |
hardware, from "the outside", as you write. |
45 |
|
46 |
|
47 |
//Peter |