Talk:LinuxBIOS: Difference between revisions

From OLPC
Jump to navigation Jump to search
Line 40: Line 40:


* Custom powersave will be done for powerdown rather than involving ACPI.
* Custom powersave will be done for powerdown rather than involving ACPI.

* It sounds like the primary concern right now is maintenance. (Will we wind up having to maintain
something outside of the normal kernel interfaces). So it sounds like for the short term
the goal should be ACPI in user space (while we do development) and using ACPI (or at least AML) only for those
things which we cannot find a suitable interface for. This should restrict acpi to motherboard specific
details because if the hardware setup is not motherboard specific the should already be a linux
driver interface to handle it. -- Eric


--[[User:Drew|Drew]] 13:32, 10 July 2006 (EDT)
--[[User:Drew|Drew]] 13:32, 10 July 2006 (EDT)

Revision as of 17:44, 10 July 2006

LinuxBIOS discussion....

UI

I'm assuming that we're going to need some sort of interactive UI. With all due respect to the uber hackers, I don't think its going to fly if we force the kids to drop to a shell. Obviously, some sort of simple menu system is going to be required. I tried to build dialog into the ROM image, but ncurses is just too big for it to fit.

So these are questions that I think need to be answered. For lack of a better word, I'm going to call this the 'reflash menu'.

  • Do we want a splashscreen in the BIOS? Do we have the room and desire to stick bootsplash in the minimal kernel?
  • Will we use the LCD to display the reflash menu, or will it only be available via serial? Obviously, serial simplifies things greatly, since we'll just need a simple UI, with nothing fancy. Also, it will avoid confusing the kids - they'll learn they need to do something special to re-flash the image. On the other hand, serial means another machine, and cables which might not always be available.
  • If we have a splashscreen and we want to use the LCD to show the reflash menu, then we'll need a keystroke to jump into the menu. Actually, now that I think about it, we're going to need a keystroke regardless of how we display the menu.
  • Would LCD menu be a simple command line based tool (possibly readline based?) or will it be more menu based (like with dialog style screens?)
  • How much do we have to worry about network setup? Do we need to provide options for setting IP address, netmask, gateway etc, or can we assume that DHCP is always available?
  • Is there anyplace we can get a light weight curses library, and can we hack dialog to use it? Do we need something as heavy as dialog, or can we design our own interactive menus? (disclaimer: I know absoutely nothing about how curses works)
  • Am I worrying too much? Will all this work itself out? --JordanCrouse 11:59, 10 July 2006 (EDT)

ACPI

  • Do we need ACPI DSDT tables in the BIOS?

Pros:

  • Standard interface
  • Usable by other OS e.g. BSD, WinCE, Win95

Cons:

  • Space - takes 64K or more in kernel for AML interpreter

Commentary:

  • I'm not familiar enough with this to say (IOW, I am explicitly admitting ignorance of the details here), but will ACPI etc. do everything OLPC needs to do? We're a bit more agressive about power saving than is typical. --Drew 12:28, 10 July 2006 (EDT)
  • ACPI is strongly preferred for e.g. lid switch, battery state monitoring so that there will be no commitment to maintain userspace apps.
  • Custom powersave will be done for powerdown rather than involving ACPI.
  • It sounds like the primary concern right now is maintenance. (Will we wind up having to maintain

something outside of the normal kernel interfaces). So it sounds like for the short term the goal should be ACPI in user space (while we do development) and using ACPI (or at least AML) only for those things which we cannot find a suitable interface for. This should restrict acpi to motherboard specific details because if the hardware setup is not motherboard specific the should already be a linux driver interface to handle it. -- Eric

--Drew 13:32, 10 July 2006 (EDT)