LinuxBoot Continues Maturing - Now Able To Boot Windows

[phoronix]

Phoronix: LinuxBoot Continues Maturing - Now Able To Boot Windows

LinuxBoot is approaching two years of age as the effort led by Facebook and others for replacing some elements of the system firmware with the Linux kernel...

http://www.phoronix.com/scan.php?page=news_item&px=LinuxBoot-Can-Boot-Windows

[starshipeleven]

That's very good. But I'm still not seeing a whole lot of adoption, or even modding community that ports boards to LinuxBoot, so there is that.

[shmerl]

A bit surprising they are using Go for systems programming, instead of a lot more appropriate Rust for it. No heavy runtime should be an important factor for tiny firwmare.

[starshipeleven]

A bit surprising they are using Go for systems programming, instead of a lot more appropriate Rust for it. No heavy runtime should be an important factor for tiny firwmare.

everything apart from kernel and go compiler binaries is in source form and compiled only when you need to use them.

https://www.usenix.org/system/files/conference/atc15/atc15-paper-minnich.pdf

The challenge to using Go in a storage-constrained environment such as firmware is that advanced language features lead to big binaries.
Even a date program is about 2 MiB. One Go binary, implementing one function, is twice as large as a BusyBox binary implementing many functions.
As of this writing, a typical BIOS FLASH part is 16 MiB.
Fitting many Go binaries into a single BIOS flash part is not practical.
The Go compiler is very fast and its sheer speed points to a solution: to compile programs only when they are used.
We can build a root file system which has almost no binaries except the Go compiler itself.
The compiled programs and packages can be saved to a RAM-based file system.
U-root is our proof of concept of this idea.
U-root contains only 5 binaries, 4 of them from the Go toolchain ,and the 5th an init binary.
The rest of the programs are contained in BIOS FLASH in source form, including packages.

The general idea is ease of use and probably ease of downstream modification to fix issues, as you are shipping mostly source files and not binaries. Remember that this thing is still supposed to give freedoms to the end user.

[MrMorden]

A bit surprising they are using Go for systems programming, instead of a lot more appropriate Rust for it. No heavy runtime should be an important factor for tiny firwmare.

TinyGo can compile Go code to AVR8. It's amazing what you can do these days.

[onicsis]

Step number ZERO: dumping unsafe C to learn Golang

[pal666]

A bit surprising they are using Go for systems programming, instead of a lot more appropriate Rust for it.

it's scripting, not systems programming. remember, they were using shell for it since beginning. and of course there are more appropriate languages for systems programming

[ihatemichael]

How is this different from something like coreboot?

[anarki2]

How is this different from something like coreboot?

It has a chance for adoption.

[starshipeleven]

How is this different from something like coreboot?

Coreboot is low-level board initialization. When it has done the job it will load and execute a payload, SeaBIOS, Tianocore (UEFI), or hardcoded GRUB load or whatever.
Currently, coreboot is mostly an empty shell as the board initialization is done by vendor blobs, Intel FSP or AMD's equivalent.

linuxboot is a payload. It can be loaded by coreboot or by proprietary board init blobs and is much simpler, safer and infinitely more powerful than commercial UEFI firmware.

the "it has a chance for adoption" said by the other user means that this can be relatively easily retrofitted to a board without knowing secret OEM information, it's just a matter of opening the stock UEFI firmware image with UEFI developer tools, removing all unnecessary components so only low-level board initialization parts remain, and then hook Linuxboot to them, then flash that back to the board firmware chip.