High demand for CLI payload: Use GRUB 2?

[Paul Menzel]

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?

Thanks,

Paul

[mrnuke]

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

[Scott Duplichan]

mrnuke [mailto:[e-mail]] wrote:

]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

UEFI shell of course.
Thanks,
Scott

]I can't speak for older versions of GRUB2, but 2.02 beta fails to fulfill any 
]and all of the above requirements.
]
]Alex

[David Hendricks]

On Thu, Jan 23, 2014 at 1:59 PM, Paul Menzel <
[e-mail]> 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 :-)