[LinuxBIOS] GSoC status report: lbmenu

[Joseph Smith]

Quoting Darmawan Salihun <darmawan.salihun at gmail.com>:

> Uwe Hermann wrote:
>> Hi all,
>>
>> here's my (first) status report for the lbmenu project I'm working on as
>> part of the Google Summer of Code. I should have done this a lot
>> earlier, sorry for the delay.
>>
>>
>> What is lbmenu?
>> ---------------
>>
>> lbmenu is a simple payload which provides a LinuxBIOS config menu,
>> which allows you to change some config options at "runtime", i.e.
>> after LinuxBIOS did the hardware init, but before any bootloader or
>> OS is started.
>>
>>
>> Planned features, design goals (mostly copied from my GSoC proposal)
>> --------------------------------------------------------------------
>>
>>  - Text-mode (Kconfig-like) console UI for changing LinuxBIOS settings.
>>
>>  - Bootsplash screen (text mode only for now) where the user can press a
>>    certain (configurable) key to enter the configuration tool.
>>
>>  - The tool should also be accessible over serial console (for headless
>>    clients, servers or debugging scenarios), as well as (if feasible) over
>>    telnet or ssh (given a big enough ROM chip and Linux + busybox in ROM).
>>
>>  - The tool should work both in ROM (as part of LinuxBIOS), and as a
>>    standalone application on a Linux system. The GUI should be the same
>>    (or similar) in both cases. The standalone version might enable some
>>    options which cannot be used in the embedded version because of
>>    size constraints.
>>
>>    To investigate: Implement the standalone tool as a frontend of lxbios?
>>    Or include the lxbios code in the standalone tool?
>>
>>  - The tool needs to fit into flash ROM (together with LinuxBIOS and at
>>    least one LinuxBIOS payload), so size is important. Typical sizes of
>>    flash ROM chips today range from 256 KB to 2 MB.
>>
>>  - It should be reasonably easy to extend the tool. For example, it should
>>    be possible to (later) add a graphical user-interface on top of the
>>    generic, UI-independent code of this tool.
>>
>>    A graphical user-interface is _not_ part of this GSoC project, though!
>>
>>  - "BIOS password" feature for setting a LinuxBIOS password.
>>    Without the correct password, no payload should be executed/booted.
>>
>>
>> Random possible ideas for after GSoC
>> ------------------------------------
>>
>>  - Internationalization support (using gettext or something similar).
>>    The strings in the UI should be fully translatable into other languages.
>>    Changing the language at run-time would require the strings of all
>>    supported languages to be placed into ROM (size constraints), so this
>>    will probably be a compile-time option only.
>>
>>  - Configurable UI-Themes (colors, layouts, key mappings,
>>    text-based or (later) graphical splash screens etc.)
>>
>>  - Payload selection mechanism to choose at runtime which
>>    payload to boot (if multiple payloads are included in the ROM chip).
>>    This would make it theoretically possible to choose between GRUB2, EFI,
>>    Open Firmware and other payloads upon each system boot.
>>
>>    It's not yet clear if this should be done in lbmenu, or as a
>>    mechanism in LinuxBIOS itself, or maybe as part of lbgrub2.
>>
>>  - LinuxBIOS Device Tree browser which shows the device tree
>>    for this mainboard (maybe even allows changes?).
>>
>>
>> Implementation plan/notes
>> -------------------------
>>
>>  - Written in C code (minimal assembly code, if required).
>>
>>  - The code will be documented using Doxygen-style code comments.
>>
>>  - A manpage will explain the usage and parameters of the tool.
>>    Optionally, there will be some help texts in the tool (configurable, as
>>    that increases the size of the tool).
>>
>>  - Ideally, the building of the tool will be integrated in the normal
>>    LinuxBIOSv3 build process, with hooks for adapting some defaults or
>>    settings of the tool at compile-time.
>>
>>  - QEMU will be used for testing the implementation.
>>
>>  - License: GPL, version 2 or later.
>>
>>
>> Status
>> ------
>>
>>  - I have written a minimalist ncurses-implementation called tinycurses,
>>    which allows some basic primitives such as printing characters on
>>    screen, moving the cursor, reading keys from keyboard, beeping etc.
>>
>>    It (sort of) supports both, VGA text console, and serial; more work
>>    is needed, though.
>>
>>    This is designed as a general purpose payload library, which can also
>>    be used by other payloads which need console text support, serial
>>    output, keyboard services, beep() etc.
>>
>>  - The alternative would be to use the stock ncurses, but there are
>>    various problems:
>>
>>     - Too big; tinycurses is stripped down to just provide the most
>>       important functions and features (e.g. no wide character support).
>>
>>     - Requires syscalls, term library, and generally an OS. I _do_ have
>>       a first test version which is compiled/linked against newlib
>>       (http://sourceware.org/newlib/), a small libc implementation which
>>       has stubs for OS-less builds (which we need in LinuxBIOS + payloads).
>>
>>       However, making this really fully work will require a lot more
>>       work. Also, the smallest lbmenu payload size when using newlib
>>       I've been able to get so far, is 130 KB or so (which is quite a lot).
>>
>>       My plan is to be able to use lbmenu with 256K ROM chips, and you
>>       need to put LinuxBIOS (30-70 KB) in there, as well as at least one
>>       payload (say FILO, ~60-80 KB), and lbmenu. So size is very important.
>>
>>       On the long term the lbmenu implementation should probably rely on
>>       the tinycurses implementation for that reason (which is currently
>>       smaller than 10 KB or so, and doesn't require newlib).
>>
>>  - The final goal of all of this would be to use plain Kconfig _within_
>>    lbmenu (at runtime) to display lbmenu's options and let the user
>>    change them. Thus ncurses or tinycurses needs to be complete enough
>>    to be able to compile kconfig.
>>
>>    If this is absolutely not feasible, well, I'll have to implement a
>>    small menu system from scratch, but I hope that won't be necessary.
>>
>>  - The compile-time options of lbmenu are configured via kconfig, just
>>    like the options of LinuxBIOSv3 itself.
>>
>>  - So far my draft implementation of lbmenu can be booted, prints a text
>>    banner (VGA and/or serial), can react on a (configurable) keypress,
>>    e.g. ESC, then enter a "menu" (which is a stub right now), and
>>    reboot upon another ESC keypress.
>>
>>
>> TODO
>> ----
>>
>>  - Finish tinycurses and/or ncurses+newlib so they're usable with kconfig.
>>
>>  - Figure out a mechanism to select between various payloads included in
>>    the ROM (_if_ this will be done in lbmenu, discussions welcome).
>>
>>  - Implement read/write of CMOS values.
>>
>>  - The configuration menu within lbmenu will be "dynamically" generated
>>    (or that's my plan at least) from Kconfig.lbmenu files in the
>>    LinuxBIOSv3 tree. The same parser which is used in Kconfig should
>>    parse all *.lbmenu files and construct the lbmenu main menu from that.
>>
>>    So you can have southbridge/amd/cs5536/Kconfig.lbmenu which provides
>>    lbmenu menu items which are CS5536-specific (e.g. enable/disable IDE).
>>    Another mainboard/amd/norwich/Kconfig.lbmenu would provide mainboard-
>>    specific menu items etc. etc.
>>
>>  - Probably a few other things I cannot think of right now.
>>
>>
>> No code yet, sorry, but I'll try to put together a small demo soon which
>> I can post here.
>>
>> I intend to put tinycurses into the global util/ directory, as it's
>> independant of LinuxBIOS and generally usable for other payloads.
>>
>> Same for lbmenu, it should be in util/ and gets its tinycurses   
>> implementation
>> via svn:externals (as should all other payloads which use it)...
>>
>>
>> Any comments and suggestions welcome!
>>
>>
>> Uwe.
>>
>
> This is really interesting. I think I will have a use for it in the
> future. Even if it's only for experiments but it should speed up the task.
>
> --Darmawan Salihun
>

Yes, I am very intrigued by this also :-)

Thanks - Joe