Questions on LinuxBIOS and OpenFirmware
Deal list, When reading about works on web page I was a little bit confused about OLPC's BIOS solution. Seems at the very first stage OLPC are using Insyde BIOS, then move to LinuxBIOS, then move to OFW. My questions is: does OFW is the only thing that act as BIOS? Or OLPC is using LinuxBIOS as BIOS and use OFW as BIOS payload to do extra things? Thanks a lot, Kein ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Questions on LinuxBIOS and OpenFirmware
On Aug 24, 2007, at 5:28 AM, Kein Yuan wrote: Seems at the very first stage OLPC are using Insyde BIOS, then move to LinuxBIOS, then move to OFW. My questions is: does OFW is the only thing that act as BIOS? Or OLPC is using LinuxBIOS as BIOS and use OFW as BIOS payload to do extra things? Insyde was a development BIOS and bootloader used for a very short time until we were able to bootstrap our own. At that point, we moved to LinuxBIOS for both low-level hw init and bootloader, which was less than ideal and somewhat unwieldy. In a surprise move, SUNW then opened up their parts of the OFW/OBP code under a BSD license, which allowed Mitch Bradley (at that point working for us) to open up his own parts -- that of his company, FirmWorks -- and let us have an acceptably-licensed OpenFirmware we can use as a fancy and compact bootloader. LinuxBIOS still does low-level hardware initialization, and there aren't plans to change that in the near future. (Mitch will correct me if I got any of the history wrong.) -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Questions on LinuxBIOS and OpenFirmware
So in short words, OLPC is using LinuxBIOS to do low level HW init, then transfer control to OFW, which also acting as boot loader to load Linux OS, right? Thanks a lot, Kein On 8/24/07, Ivan Krstić [EMAIL PROTECTED] wrote: On Aug 24, 2007, at 5:28 AM, Kein Yuan wrote: Seems at the very first stage OLPC are using Insyde BIOS, then move to LinuxBIOS, then move to OFW. My questions is: does OFW is the only thing that act as BIOS? Or OLPC is using LinuxBIOS as BIOS and use OFW as BIOS payload to do extra things? Insyde was a development BIOS and bootloader used for a very short time until we were able to bootstrap our own. At that point, we moved to LinuxBIOS for both low-level hw init and bootloader, which was less than ideal and somewhat unwieldy. In a surprise move, SUNW then opened up their parts of the OFW/OBP code under a BSD license, which allowed Mitch Bradley (at that point working for us) to open up his own parts -- that of his company, FirmWorks -- and let us have an acceptably-licensed OpenFirmware we can use as a fancy and compact bootloader. LinuxBIOS still does low-level hardware initialization, and there aren't plans to change that in the near future. (Mitch will correct me if I got any of the history wrong.) -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Questions on LinuxBIOS and OpenFirmware
On Aug 24, 2007, at 7:25 AM, Kein Yuan wrote: So in short words, OLPC is using LinuxBIOS to do low level HW init, then transfer control to OFW, which also acting as boot loader to load Linux OS, right? Correct. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: accessibilities first tests - many questions
Hello On 8/20/07, Jordan Crouse [EMAIL PROTECTED] wrote: It'd be great if this could be included. Better yet would be to allow specifying the raw register value, of course with an -EINVAL if bits unrelated to swizzle and backlight are set. Again - can I ask why? The sysfs/ interface exists to provide the right interface to the applications and the user to accomplish what they want to do. If you have a good reason for exposing this functionality, then I'm all ears, but I think that just for giggles doesn't quite cut it. What about because it has not been tested? In the end, I guess it depends on how you design your software. Personally, I write quick and dirty test code where I do my best to keep every possibility open. Then I work around some specific parts. Sometimes, I even avoid includes to have some nearly identical version and play with tiny parts of the code (which way is faster, how does it react to tests with real data, etc). If I can't get any measurable difference, I consider running benchmarks ten thousands of loops, etc. But unless some feature has been *tested* (not considered) to be useless, I keep it at that step. When I remove something, that's for a serious, documented reason. Then comes optimisation time, and I decide what makes it in, and what doesnt, based on the data gained on the previous tests. Lot of stuff get removed then, and some parts are even fully rewritten and fully tested again. Removing a feature that people want to test, doing someway instead of the other way, just because you are guessing it won't be helpful, is just wrong to me. That's Premature optimisation, design by commitee - name it how you want. I only trust tests, data and conclusions. Likewise, I have a friend who is a damn good coder - far better than I am. However, he has this tendancy to ignore tests and error checks, write evrything in one shot, and then spend some serious time wondering why it isn't working as it should. Same mistake IMHO. If you want to write directly on the device for testing purposes, then the i2c-tools work great - you can bang on the registers all day. But you are making that unreasonably complex. What about other features? Will everyone will have to do i2c? What about switching GPIOs? (I haven't checked that yet) An echo 0/echo 1 in /sys really saves testing time. A real life example with the XO - did you try the script I posted with black and white + backlight mode? Some people I showed it to actually enjoyed it, not for the high contrast mode as I initially supposed (bw with full backlight), but for reading ebooks at night (!!!) - they said it was easier on the eyes, at least according to them, than the color mode. The pale backlight made it suitable to be used with the lights off. Do you want to actually prevent creative uses? Something even more funny - someone turned the screen to pda mode, but did not close the keyboard all the way, so that it made the screen stand at a strange angle suited for standing on a desktop, like a picture holder. How clever users are - they think in ways we don't. So we shouldn't be arrogant and try to dictate them what's best for them, but see what they do with the possibilites we provide. Therefore, I think we should not currently be removing possibilites but adding them instead, test them, and remove what has been *proved* to be useless. Wild guessing is not a good strategy. And anyway, what's the cost ? That's won't make your kernel bigger. That won't make it run slower or eat more power. Guylhem ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DejaVu fonts (Was: Ethiopean)
Sergey Udaltsov wrote: Would you try the Ethiopian XIM in en_US locale (replacing Compose file)? I'm afraid I'm totally ignorant of the subject. How is the Xlib compose handling supposed to work in applications? Would it also work in Write.activity? By the way, the am_ET.UTF-8 locale appears to work with glibc 2.90 from Fedora Development. We'll need to backport a fix or upgrade glibc if we want Ethiopian support in the OLPC. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Questions on LinuxBIOS and OpenFirmware
Hi, On Aug 24, 2007, at 7:25 AM, Kein Yuan wrote: So in short words, OLPC is using LinuxBIOS to do low level HW init, then transfer control to OFW, which also acting as boot loader to load Linux OS, right? Correct. Actually, I think Mitch replaced the LinuxBIOS init code with his own OFW init about six months ago -- Ivan described the situation before that. So, we're using pure OFW. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Questions on LinuxBIOS and OpenFirmware
On 24/08/07 10:38 -0400, Chris Ball wrote: Hi, On Aug 24, 2007, at 7:25 AM, Kein Yuan wrote: So in short words, OLPC is using LinuxBIOS to do low level HW init, then transfer control to OFW, which also acting as boot loader to load Linux OS, right? Correct. Actually, I think Mitch replaced the LinuxBIOS init code with his own OFW init about six months ago -- Ivan described the situation before that. So, we're using pure OFW. Yep. B3 and newer is using OFW from top to bottom [1]. Jordan [1] Well, actually, the low level stuff is in assembly, which I think the OFW purists will claim isn't actually OFW, but it all comes together in the same package, and Mitch owns it all, so to us, its OFW. -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: accessibilities first tests - many questions
On 24/08/07 15:47 +0200, Guylhem Aznar wrote: Hello On 8/20/07, Jordan Crouse [EMAIL PROTECTED] wrote: It'd be great if this could be included. Better yet would be to allow specifying the raw register value, of course with an -EINVAL if bits unrelated to swizzle and backlight are set. Again - can I ask why? The sysfs/ interface exists to provide the right interface to the applications and the user to accomplish what they want to do. If you have a good reason for exposing this functionality, then I'm all ears, but I think that just for giggles doesn't quite cut it. What about because it has not been tested? Don't make the assumption that this hasn't been tested. This hardware goes through extensive testing before we even get to see it. From Linux even. Removing a feature that people want to test, doing someway instead of the other way, just because you are guessing it won't be helpful, is just wrong to me. I told you how you could test it easily, and I stick by that. Adding the sysfs entry costs time, code size, and further confuses the interface (which is already pretty darn confusing). If the only viable usage is I want to see how it works then i2dump is two doors down and to the right. It comes for free with the bus. If you want to write directly on the device for testing purposes, then the i2c-tools work great - you can bang on the registers all day. But you are making that unreasonably complex. What about other features? Will everyone will have to do i2c? What about switching GPIOs? (I haven't checked that yet) An echo 0/echo 1 in /sys really saves testing time. Not really, when you have the i2c tools, then its just a single command as well - and the interface comes for free. Its not always easy being a low end developer. But here's an alternative - use OFW to change the values instead - that absolutely comes for free - the functionality is already built in. Ask Mitch, and he'll give you a recipe. How clever users are - they think in ways we don't. So we shouldn't be arrogant and try to dictate them what's best for them, but see what they do with the possibilities we provide. Its not about dictating whats best for them, its about providing the knobs that make sense to turn. There are hundreds of interesting looking registers in the chips on this platform, and I'm sure that we could go through and toss them all into syfs or some other interface, but the odds are that every single one of them will go untouched, except for the occasional guy who reads the datasheet and thinks he has found something creative that the rest of us missed. So we don't provide the interfaces that aren't useful in production. Thats not to say that you still can't twiddle the registers - there are several great ways to play with the internals of the chipsets from the privacy of your own userspace. We're not in the business of making it impossible for people to tinker, but we are in the business of optimizing the experience for the end user. Therefore, I think we should not currently be removing possibilities but adding them instead, test them, and remove what has been *proved* to be useless. Wild guessing is not a good strategy. And anyway, what's the cost ? That's won't make your kernel bigger. That won't make it run slower or eat more power. Actually, it will. It will make the kernel larger, and it will eat more memory due to the additional infrastructure. We know exactly the cost - my question is, whats the benefit? Nobody really knows (or I suspect, cares), they just read the spec and say wow, I want to try that because its a knob I can twiddle. But hey, this is open source. I'm sure Andres will take a patch against olpc-dcon if you really care that much. -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Questions on LinuxBIOS and OpenFirmware
Ivan Krstić wrote: On Aug 24, 2007, at 7:25 AM, Kein Yuan wrote: So in short words, OLPC is using LinuxBIOS to do low level HW init, then transfer control to OFW, which also acting as boot loader to load Linux OS, right? Correct. Sorry, not correct. LinuxBIOS is not present at all. The low-level init is now done with a few lines of assembly language code and a big table of register values. Removing LinuxBIOS was what made it possible for me to get the startup time down to a couple of seconds, and to do the firmware part of resume in a few milliseconds. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DejaVu fonts (Was: Ethiopean)
Also note that we need Pango 1.18 (just released) for Ethiopian to work; J5 says this is now in our builds. On Fri, 2007-08-24 at 10:01 -0400, Bernardo Innocenti wrote: Sergey Udaltsov wrote: Would you try the Ethiopian XIM in en_US locale (replacing Compose file)? I'm afraid I'm totally ignorant of the subject. How is the Xlib compose handling supposed to work in applications? Would it also work in Write.activity? By the way, the am_ET.UTF-8 locale appears to work with glibc 2.90 from Fedora Development. We'll need to backport a fix or upgrade glibc if we want Ethiopian support in the OLPC. -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Board Revision
The change list from Quanta: 1. Reserved ESD Protected IC for Speaker Left/Right (U67,U68) Channel and PS/2 interface (U66). – EC 3B00,3B01 (Page 12,13) 2. Connect U39 charger IC pin 124 to REF5V for supplier recommend for unused pin. – EC 3B02 (Page 18) 3. Change R345/360Ohm , R346/360Ohm , R347/549Ohm , R349/536Ohm , R350/432Ohm , R351/27Ohm , R357/10Ohm for New LCD Gamma value. –EC 3B03 (Page 21) [ No visible change, just lower power] 4. Pop back J1 console port connect . –EC 3B04 (Page 8) I added moving an inconveniently placed test pad. Terry already responded with their intention to bump the board rev., so I think this discussion is moot. wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DejaVu fonts (Was: Ethiopean)
On Fri, 2007-08-24 at 22:26 +0100, Sergey Udaltsov wrote: Is it in the latest _stable_ build? Should I wait for the new one? Or should I rather risk installing today's devel build? No, current builds.. Eg. 556, which I installed on 3 systems (B3, B4, and CTest) this afternoon. - Jim Sergey On 8/24/07, Jim Gettys [EMAIL PROTECTED] wrote: Also note that we need Pango 1.18 (just released) for Ethiopian to work; J5 says this is now in our builds. On Fri, 2007-08-24 at 10:01 -0400, Bernardo Innocenti wrote: Sergey Udaltsov wrote: Would you try the Ethiopian XIM in en_US locale (replacing Compose file)? I'm afraid I'm totally ignorant of the subject. How is the Xlib compose handling supposed to work in applications? Would it also work in Write.activity? By the way, the am_ET.UTF-8 locale appears to work with glibc 2.90 from Fedora Development. We'll need to backport a fix or upgrade glibc if we want Ethiopian support in the OLPC. -- Jim Gettys One Laptop Per Child -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
