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.
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.
Good work, can't wait to see the end result!
-Corey
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
Quoting Darmawan Salihun darmawan.salihun@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
-
Corey Osgood -
Darmawan Salihun -
Joseph Smith -
Uwe Hermann