On Thursday, January 23, 2014 10:59:21 PM Paul Menzel wrote:

Do you also know if GRUB 2 does not fulfill one of these requirements?

GRUB2 doesn't meet several requirements that vendors usually have: * must be crappily coded (ignoring the GNU coding standard here) * code must be unreadable to the casual trained observer * must be full of redundancy * must contain many superfluous functions * must be hard to get working (vendors want to add value, right?) * requires Visual Studio to compile I can't speak for older versions of GRUB2, but 2.02 beta fails to fulfill any and all of the above requirements. Alex

On Thu, Jan 23, 2014 at 1:59 PM, Paul Menzel < paulepanter@users.sourceforge.net> wrote:

Dear coreboot folks,

in the coreboot IRC channel it was mentioned that a lot of vendors want to have a CLI (command line interface) payload. To get that they even used U-Boot as a payload. Though nobody understand the reason for this demand, the common opinion was to just give in and provide a solution for their problem.

As getting a CLI payload with for example auto-completion, help texts and so on is tiresome and probably takes some work, I wonder why GRUB 2 is not a suitable solution? It’s very modular and thanks to Vladimir works very well as a payload for some time now.

Though normally a menu is shown, you can drop into the command line and have a lot of commands depending on the modules you built.

Could people in contact with the vendors please tell us, what the requirements from the vendors are?

Do you also know if GRUB 2 does not fulfill one of these requirements?

I missed the discussion on IRC. But FWIW, I have been working on making a small initramfs image consisting of busybox and a few handy tools (flashrom, iotools, pciutils, usbutils, networking support, etc). I hope to polish it up in the not-too-distant future and make it easy to build in the ChromiumOS SDK (Portage-based). If you're interested to try out a snapshot I have put one up here (built for i386): http://goo.gl/a2kwE0 . Everything is dynamically linked against uClibc and once integrated with our build system can be easily targeted at different architectures. One could also write test programs and compile them using the same toolchain, then add it to the initramfs image or wget it from a live machine. The idea is to give developers a familiar, standards-compliant shell environment using a real kernel to provide drivers. Loading the kernel and initramfs off the firmware ROM reduces dependencies on many drivers. So as long as coreboot can init DRAM and run the payload, kernel and firmware development can be done in parallel even with a lot of stuff broken. It also means the bootloader doesn't need to be bloated with unnecessary drivers and tools, and development is focused where it should be. Perhaps we can call this LinuxBIOS :-) -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.