On Monday 04 September 2006 01:11, Bari Ari wrote: > Look for laptops that have the firmware Flash write enable lines > controlled only by the chipset and not also by the keyboard/system > management controller. This will allow a developer to rewrite the Flash > with LinuxBIOS. Most efforts to port LinuxBIOS on laptops in the past > could not get past this hurdle. > > Designing and manufacturing for a laptop for mass market using LinuxBIOS > is simple. The bill of material and hardware design are the same as a > laptop using a closed source BIOS. Laptop mainboards are typically > manufactured in high volumes in single runs (much the same as > desktop/platform mainboards). The LinuxBIOS would be developed for the > mainboard during the design stage of the project and then programmed > into the flash before manufacture or after the flash devices are > installed on the boards. > > There hasn't been much demand for laptops to have LinuxBIOS yet. The > first major project to demand LinuxBIOS on a laptop has probably been > the OLPC project. I doubt if Quanta had much experience with or > knowledge of LinuxBIOS before OLPC.
I was thinking more along the way, how hardware could be simplified on one side and at the same time enhanced by nice-to-have features. Just some ideas: +Large enough (partitioned) Flash(s) already on the board +as low as possible number of parts +get rid of stone-age hardware and replace with modern parts +new concepts to replace error prone complex initialisation sequences +combine just the best of the best (with options to scale on purpose) +open, fully documented standards +KISS =a more advanced PC/Laptop/Node...whatever (IMHO) --- As my original post got accidently PM, here what i wrote before that mail: > The chipset docs may all be available but not docs to the power > management/keyboard scan controller firmware. The docs for the micros > describe the general purpose micro itself, but that won't tell you how > they are using all of its gpio pins and ports. Isn't that a pity? Those parts are not the complex parts, it are the most simple parts and some of them are just to control hardware that is available for eons as a standard. In the age of USB i wonder if we still need a keyboard/mouse controller for other than that. (i mean: why not just USB without PS2? Why COM,LPT? ) How would a (linux) mainboard look like? Is there a parts list, e.g. one for desktop, one for laptop that would be great? Maybe, just maybe, one of the manufacturers takes a deep breath... Or just maybe they notice, that the selection of parts is so carefully optimized, that it would be great to do it that way for a decent windows PC as well. - (As for the price of energy i would say, both should only use mobile-hardware) I'am reading at that least for a while and i got the feeling, that most hardware is not support, only a few work fully - i liked to have it for my Centrino-Mini-itx but the memory controller is a problem, howe does it look now for turion based mini-itx-systems? (I use those as a desktop pc because they use so little energy to run and are fast anyway - beside such a tiny little box is not so intrusive in the living room ;-) Part of the problem is certainly the very difficult installation and the risk of failure - i once fried a mainboard while updating the standard flash with an update from the manufacturer - it just stopped half way through. I got a replacement part, let it flash somewhere else but it didn't help. Though i work in embedded control area, flashing ECU's without trouble hundred times a day. Those ECU's are designed in a way, that they can even be reflashed when the flash-process interrupted __anywhere__ - despite the propability that this feature is actually required out there in the field is very low, maybe once in the lifetime of a car. The (missing) content of the flash can be delivered via certain serial line protocols during the flashing process from an external hardware/software (K-Line, CAN, ...) - wouldn't that be a nice thing to have for Linux as well? -- linuxbios mailing list [email protected] http://www.openbios.org/mailman/listinfo/linuxbios
