Jim,
I see from the OLPC Wiki
http://wiki.laptop.org/wiki/Hardware_specification
that the ENE KB3920
is to be used for keyboard scan and system management.
Are there plans to keep the code for this open as well?
Many types of these controllers share memory space with the flash that stores the BIOS. The KB3920 data sheet is not available from the ENE website. Do you know if this device has enough flash, OTP or mask ROM to hold all of it's own code or will it share with the system BIOS?
-Bari
On Tue, 2006-03-14 at 08:13 -0600, Bari Ari wrote:
Jim,
I see from the OLPC Wiki
http://wiki.laptop.org/wiki/Hardware_specification
that the ENE KB3920
is to be used for keyboard scan and system management.
Are there plans to keep the code for this open as well?
Many types of these controllers share memory space with the flash that stores the BIOS. The KB3920 data sheet is not available from the ENE website. Do you know if this device has enough flash, OTP or mask ROM to hold all of it's own code or will it share with the system BIOS?
I think the part may not have been released yet; so you get the part number for now; or maybe it is just some variant of an existing part. I don't know the exact situation and will have to ask Quanta.
It isn't clear to me if we should release the code (at least without some thought) to this part.
IIRC, the flash in which LinuxBIOS is getting stored is interfaced via this controller and is a serial flash part; possible sizes are 4 megabits and 8 megabits. We save something like $.3 to $.5 if we can use the 4 megabit part. Right now, we are carrying the 8 megabit version on the BOM.
Here's what I'm paranoid about: that the serial flash rom in which LinuxBIOS and bootloader is stored gets overwritten, and the laptop is no longer a laptop, but an expensive brick. I particularly worry about someone writing a worm that manages to do this, and that thousands/millions of machines all over the world are unrecoverable. The logistics of repair are impossible. I will ask Mark Foster about how that flash gets write enabled; if we can absolutely in hardware inhibit write to the boot flash, then I get much less worried. I've sent him mail asking.
I do want the bootloader sequence in this flash to be able to load a second copy of itself out of the regular main flash so that later versions can be installed safely (with appropriate checksum checking). I don't want the situation we had on the iPAQ where you could possibly "brick" the unit when updating the bootloader. The iPAQ valhalla we had (you could send us a bricked iPAQ and we'd eventually reflash it via jtag and return it) was a PITA, and not feasible for OLPC. We have to ensure boot and restore is absolutely bulletproof. - Jim
Jim Gettys wrote:
It isn't clear to me if we should release the code (at least without some thought) to this part.
If it would help with "The Free Software Foundation's Campaign for Free BIOS" for laptops
http://www.fsf.org/campaigns/free-bios.html
OLPC would also gain support from this community and the whole open source community for laptops and tablets.
The keyboard/system controller in laptops is often used to control writes to the flash (and several other system areas) and has made it very difficult to support laptops with a Free BIOS.
Here's what I'm paranoid about: that the serial flash rom in which LinuxBIOS and bootloader is stored gets overwritten, and the laptop is no longer a laptop, but an expensive brick. I particularly worry about someone writing a worm that manages to do this, and that thousands/millions of machines all over the world are unrecoverable. The logistics of repair are impossible. I will ask Mark Foster about how that flash gets write enabled; if we can absolutely in hardware inhibit write to the boot flash, then I get much less worried. I've sent him mail asking.
Several vendors have relied on "security through obscurity" to prevent worms or a virus from modifying the system BIOS. It's always been defeated. A very difficult AES + SHA-1 or SHA-256 hash based security scheme could be used, but it still would not be 100% secure.
I do want the bootloader sequence in this flash to be able to load a second copy of itself out of the regular main flash so that later versions can be installed safely (with appropriate checksum checking). I don't want the situation we had on the iPAQ where you could possibly "brick" the unit when updating the bootloader. The iPAQ valhalla we had (you could send us a bricked iPAQ and we'd eventually reflash it via jtag and return it) was a PITA, and not feasible for OLPC. We have to ensure boot and restore is absolutely bulletproof. - Jim
Fallback BIOS in ROM plus a hardware switch/jumper to control writes to flash is one 100% solution. Having a fallback BIOS image in flash would only be safe if writes to the memory area in flash that stores the fallback BIOS image is completely inaccessible to writes unless a hardware switch/jumper is enabled.
-Bari
On Tue, 2006-03-14 at 21:58 -0600, Bari Ari wrote:
Jim Gettys wrote:
It isn't clear to me if we should release the code (at least without some thought) to this part.
If it would help with "The Free Software Foundation's Campaign for Free BIOS" for laptops
I'm aware of the campaign. I guess I'm more on the pragmatic Linus side of the camp: my interest in LinuxBIOS is what it can do that we forsee difficult or impossible using a conventional BIOS. LinuxBIOS looks to us like *the best tool for our job*. I personally believe open source and Free software should meet all comers on its own merits; the ideology is secondary or tertiary in my view. I'm not saying I don't share much of what the FSF advocates; I'm saying that by free software being the obviously right technical solution to a problem is an even stronger, cogent, compelling argument than ideology.
We have a secondary motivation that is educational: we'd like kids to be able to take the software apart down to the bare silicon as a potential learning experience: you can't do that on closed source BIOS's.
But if the commercial BIOS did all of what we need (and you aren't yet aware how interestingly nuts we've all become, yet), I'd use it. But they don't, and LinuxBIOS means we can get in there and make whatever changes are needed, and we know we need changes that go beyond the usual. When you fully understand what the DCON chip means, you'll have an interesting revelation. I'll guess we'll open up on that in a week or two; definitely by the Linux Power management summit in April.
OLPC would also gain support from this community and the whole open source community for laptops and tablets.
The keyboard/system controller in laptops is often used to control writes to the flash (and several other system areas) and has made it very difficult to support laptops with a Free BIOS.
Actually, I suspect we may end up with a separate keyboard controller to save on wires. The spec current calls for the keyboard to be electrically PS/2. That implies a separate keyboard scanner, or many wires have to go through the hinge.
Here's what I'm paranoid about: that the serial flash rom in which LinuxBIOS and bootloader is stored gets overwritten, and the laptop is no longer a laptop, but an expensive brick. I particularly worry about someone writing a worm that manages to do this, and that thousands/millions of machines all over the world are unrecoverable. The logistics of repair are impossible. I will ask Mark Foster about how that flash gets write enabled; if we can absolutely in hardware inhibit write to the boot flash, then I get much less worried. I've sent him mail asking.
Several vendors have relied on "security through obscurity" to prevent worms or a virus from modifying the system BIOS. It's always been defeated. A very difficult AES + SHA-1 or SHA-256 hash based security scheme could be used, but it still would not be 100% secure.
I don't believe in security by obscurity.
I have asked Mark Foster to see if he can determine a way to write protect the flash; he said he'd see what he can do.
Bullet proof solution is what we have to have. "Takes a licking and keeps on ticking" as the old Timex commercials said (boy, I'm showing my age, aren't I?
I do want the bootloader sequence in this flash to be able to load a second copy of itself out of the regular main flash so that later versions can be installed safely (with appropriate checksum checking). I don't want the situation we had on the iPAQ where you could possibly "brick" the unit when updating the bootloader. The iPAQ valhalla we had (you could send us a bricked iPAQ and we'd eventually reflash it via jtag and return it) was a PITA, and not feasible for OLPC. We have to ensure boot and restore is absolutely bulletproof. - Jim
Fallback BIOS in ROM plus a hardware switch/jumper to control writes to flash is one 100% solution. Having a fallback BIOS image in flash would only be safe if writes to the memory area in flash that stores the fallback BIOS image is completely inaccessible to writes unless a hardware switch/jumper is enabled.
External switches cost money and are difficult to seal. Internal jumpers we may be able to afford.
As I said, I am hopeful we'll make the flash unwritable. Then I can sleep at night... - Jim
Jim Gettys wrote:
Actually, I suspect we may end up with a separate keyboard controller to save on wires. The spec current calls for the keyboard to be electrically PS/2. That implies a separate keyboard scanner, or many wires have to go through the hinge.
If the code to whatever system controller ends up being used for the OLPC is free and open it will help that device get into and enable more fully open laptops, tablets and handhelds to be produced.
There is usually is not much to the code, a few of KB's of routines to handle the indicator LED's, power & lid switches, temperature management, and battery charging.
-Bari
Jim, the write protect is pretty easy. It's a pullup on all the parts I'm familiar with, unless I'm missing something -- Ollie?
ron
I expect it is easy.
I just put it on Mark Foster's list, so that a jumper might appear in the right place... It is easy to overlook such details (though this one is small enough it might have been simple to get added later); but the closer to production the first board is, the better. - Jim
On Wed, 2006-03-15 at 19:51 -0700, ron minnich wrote:
Jim, the write protect is pretty easy. It's a pullup on all the parts I'm familiar with, unless I'm missing something -- Ollie?
ron
On Wed, 2006-03-15 at 22:03 -0500, Jim Gettys wrote:
I expect it is easy.
I just put it on Mark Foster's list, so that a jumper might appear in the right place... It is easy to overlook such details (though this one is small enough it might have been simple to get added later); but the closer to production the first board is, the better. - Jim
The SPI flash rom they are going to use has a W# signal. When it is driven low and some register bit is set, certain part (programmable) of the flash can't be programmed.
In the schematics, they pull the W# hi (software write protect).
-
Bari Ari -
Jim Gettys -
Li-Ta Lo -
ron minnich