Talk:LinuxBIOS

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)

• The concerns you raise seem to valid for the bootloader interface, that comes out of the NOR flash.

 I suspect the solution is some minimal predictable interface in the NOR flash that does the right
 thing and the nice UI section later.  Either that or we need to do the hard work to get the kernel
 in flash very small and get a very dense user space to use with it.

 I think you are forgetting basics. Ncurses is doing 10'000 things - and most of them are TOTALLY
 useless for LinuxBIOS. For example it tries to reduce number of characters sent to terminal when
 it needs to show menu or whatever. Why ? IBM PC XT (yup, the one with uber-fast 4.7MHz CPU) was
 able to redhaw the whole screen few times per second without any such tricks. Also ncurses have
 extensive code to select correct line-drawing characters for terminal. And this code is also
 totally useless when you have just one terminal type to consider. But why do we need terminal
 abstraction at all ? We can just write directly to video memory instead. Come on: 20 years ago the
 whole games with a lot of menus, texts and so on existed on computers with 8Kb of RAM (yes, that's 
 right - not 8Mb but 8KB!) -- are we really so much dumber now that we can not do it today ? Khim

• For reflashing the BIOS we can do that from a fully booted linux and as such are not limited to the

 bootstrapping size limitations.  Currently there is a command line interface for that and that may
 be ok for such a dangerous operation.  If not possibly something better can be arranged.

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

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

Confusion: putting DSDT in the BIOS image DOES NOT require AML support in the FLASH ROM image. So the issue is not really that space taken up -- I don't think the DSDT is large. It's more about how we control this platform -- do we want ACPI in there? Bear in mind that, while there have not yet been ACPI viruses in the wild, they are a great opportunity for bad guys everywhere. ACPI viruses are a promised capability in the future.

• • The discussion has migrated away from the DSDT to ACPI support in general. We do need AML if we want to read the EC and return battery status, etc, through ACPI. Granted, the DSDT is small and innocent, and the full interpeter will be in the kernel, not in the FLASH ROM, but the general thinking is that the DSDT is a "gateway" drug^H^H^H^H interface - once it is in place, people will try to push for full ACPI support. As for using the DSDT in a Linux kernel without distributing it in the BIOS image, see ACPI howto for examples on how one would do that. --JordanCrouse 20:47, 10 July 2006 (EDT)