[LinuxBIOS] GSoC status report: lbmenu
Joseph Smith
joe at smittys.pointclark.net
Sun Aug 5 19:43:44 CEST 2007
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
More information about the coreboot
mailing list