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