Some boards have a header that provides access to the BIOS chip for external flashing hardware. On some others the BIOS chip is socketed so you can just swap in another chip to flash coreboot to. Some do have it just soldered down with no header, though.
Originally Posted by mendieta
So then every time you do a OS upgrade you are going to be essentially reflashing a cmos device that was never meant to have many write cycles and hope that nothing goes wrong during that more frequent flash? Not really a great idea.
Originally Posted by Ex-Cyber
No, I'm talking about using kboot as a customizable flash-resident bootloader (similar in principle to how it and petitboot were used on PS3). A typical distro kernel+initrd wouldn't fit anyway.
Originally Posted by deanjo
I get what you are saying however bootloaders usually have to be rewritten every time a OS is installed (or kernel change). If you were to have an additional nand storage device on the board then perhaps I could see it (such as the nand devices used on some Asus boards with their Expressgate SSD). It seems to me then however that if motherboard manufactures were to start accommodating such setups it would be just as easy to standardize and document their "special" board features so that it could be properly put into Coreboot to begin with.
Originally Posted by Ex-Cyber
Usually only the bootloader configuration really needs to change, and the OS-specific config can be stored on whatever disk the OS is installed to, sort of like GRUB (actually, GRUB itself can already be used as a coreboot payload). If the disk is inaccessible you can't boot the OS anyway.
Originally Posted by deanjo
Besides, even supposing that you did need to rewrite the whole thing every time you do a kernel upgrade, modern SLC flash chips are usually rated to at least 100,000 write/erase cycles. If you're going to burn through that before the board is retired, you're probably savvy enough to handle buying a board with a socketed flash chip and swapping it out.
what the hell are you talking about ?
isn't that payload should be an analogue of proprietary BIOS'es "boot menu" and such ?
like (core BIOS stuff)->(payload with minimal bootloader with boot order written on CMOS to boot system's main, external bootloader)->(system bootloader from external device)->(OS or chainbooted other bootloader like Windows crap) ?
grub or kernel on BIOS's shitty flash (i know you can do it with coreboot now, and other then for very specific situations - _this is not a good idea_)... what can go wrong, right ?
personally, i think that main OS and its /boot partition should be located at some flash drive like SSD in PCI slot, SD card in SD<->IDE/SATA adapter or something like that and not on HDDs/SSDs where you store your data and/or /home. but BIOS's flash is stretching this idea into nonsense unless, again, it's for something specific and non-desktop related.
BIOSes are extremely shitty.
I cannot stress this enough.
You know how you have to go through a bluescreen dialog and go up and down and press little configuration changes to configure your hardware.
You know how Linux has a hard time with ACPI configurations and getting hardware to suspend properly.
You know it takes something like a minute and a half for your system to boot up?
I've had to work with vendors and bios makers before, professionally. Their software sucks. It's really horrible and it's a afflicted on everybody that uses a PC. I cannot stress it enough just how bad BIOSes are designed and programed.
Coreboot can do everything a BIOS does if it is properly setup... but it does it very very quick. Probably quicker then it takes for your LCD display to boot up. Essentially by the time the display activates you should already be half-way done booting your system up.
On modern hardware it should take about 30 seconds, at most, from you hitting the power button to desktop login. Distro makers have really cut the fat out and made Linux boot fast. Now we just have to make the rest of the system as fast.
I noticed that I'm not the only one checking motherboard pictures to try to verify if the bios chip is soldered or not.
That explains why my 1 year old PC takes as much time to get through the BIOS initialization screens (or whatever they're called) as my first 486 PC back in 1995.
Originally Posted by drag
One other thing I as a customer would love when it comes to vendors using coreboot would be support.
I currently have an old desktop from DELL. Its motherboard supports many CPUs wrt chipset, socket and so on. But since DELL only sold it with one two kinds of CPU (first they only supported one kind of CPU, then they sold later models with the other CPU and a BIOS update, then they EOL that model). Now I got an old CPU from a friend. This CPU is supported by the chipset, it is supported by the sockets, the family is partly supported by the motherboard, but since DELL have not released a BIOS update the motherboard does not start with it.
There are a a reference card from intel (who made the motherboard to begin with) with some minor changes, and also another computer model from DELL which are nearly identical, both supporting the CPU in question. But I do not dare to cross-flash since I do not want to brick that computer, and that BIOS-version of DELL is stripped on any information that would make it possible to easy to mod.
Now if the vendor had used coreboot for this machine, the source code for a BIOS would already exist, and I would feel a bit less risky by flashing it since I could essentially just grab the revision the vendor based their "bios" on, update just those parts I think was needed (in this case replace some of the supported CPUs by others that never ever is going to be placed in that computer anyway), compile and reflash. And it would not feel as hacky and dangerous as the current way of modding those stripped versions of Phoenix-BIOS: hex-edit.
Tags for this Thread