Re: Bootloader question
The kernel init improvements will certainly bring 15 other seconds. Maybe some parallelisation of the sysvinit will save some time, say 5 seconds (low end estimation) Parallelization will not help at all if you are using JFFS2. The low level NAND driver that JFFS2 uses busy waits for I/O, and then JFFS2 is CPU-bound on the decompression step, preventing any useful concurrency. The busy-wait could be changed to an interrupt - if only someone had time to do the work and test it extensively. The decompression is going to be CPU bound no matter what you do, so the only option is to arrange for the important files not to be compressed (thus increasing the NAND footprint). Hi Guylhem! What I have been told: The busy waiting happens because there is no scatter-gather support in the NAND driver so the interrupt rate is high and it is faster to busy wait than to context switch. Probably it would help to interrupt for large IO and busy wait for small IO but it needs testing. I promise you that if you happen to make the required efforts to speed up booting then I will finish my fixed LZO decompressor code. It would make reading compressed files actually faster, just I am not a Linux kernel developer so integrating that with Linux would be your job. BTW why the doctors cannot just close the lid and open when needed? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
On Thu, Jun 4, 2009 at 3:41 AM, Guylhem Aznar o...@guylhem.net wrote: Of course I do, but IMHO there are also some things that could have been done differently. Ah, hindsight is so easy ;-) As Mitch's reply shows, we have been looking at the boot times and studying any low-hanging-fruit there. Your stated goal allows for a couple of options... see below. on a SQL database (which needs ~600 Mb of flash total). I'm more of a debian guy, so I took what I knew to have a working base which can be improved. Maybe try deb-xo on an SD card? As Mitch mentions, booting from SD skips various steps that are slow on our platform. Pretests results show a usage pattern where doctors prefer to power on the laptop when some specific information is needed. This behaviour is How about suspend or hibernate? So I see a boot delay that could be easily cut by half, You see lots of things we'd like to have! Have a read of Mitch's reply, there are several spots where you could help us. martin -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
I will try fedora 11, if only to have a good refence point. But since you said many of the speedups where dependant on kernel fixes, how is 2.6.29 doing on the XO? Could anyone using f11/2.6.29 on the XO give some feedback ? Off the top of my head from the last time I tested it sound and camera don't work, and there are needed patches for the display DCON, some i2c bus stuff and power saving. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
Martin Langhoff wrote: Easily? Yeah, right. Well, he can show us how it's done. I'll definitely be impressed :-) My point is that, while each individual step is rather straightforward, requiring no new technology, putting together all the pieces to accomplish the goal requires a lot of work and testing. It's a build/packaging/release engineering job that touches many aspects of the system - basically a mini-distro. In my experience, creating a coherent release containing changes to lots of disparate system components is anything but easy. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
On Thu, Jun 4, 2009 at 10:36 AM, Mitch Bradley w...@laptop.org wrote: My point is that, while each individual step is rather straightforward, A ton of careful detail work. As you point out, kernel, firmware and distro hackers have been looking at this for a while, and there are no obvious easy wins left. If Guylhem is prepared to help with a few of those steps, things do get better for everyone. Every little step helps... cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
I'm thinking about ext4, but I must confess that my experience with ext2 has been pretty frustrating. The ext2/3 on-disk format has sprouted many new features over time. Supporting people who plug in disks that are formatted with the latest fancy feature, then complain that an old firmware release fails to work with it, is difficult. Would the patch that was done to add support to grub for ext4 be of any use to you for reference for adding support? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
I'm not using sugar. The OLPC will be used [by doctors] to access drug information, so I made some different choices. At the moment, I am using a bootstrapped lenny where I removed everything I could. No udev, no hotplug but a custom made script to provide the firmware and do automounts, (etc). Going straight into X to run an old opera version (easier on ram use) Um, you're not using OLPC hardware to teach kids, but because someone gave it to you for free? It's not appropriate -- an ordinary netbook would be much better -- but you're bashing it to fit. By the time you're done, there will be nobody who understands how it works except you. (0) How does your work help OLPC reach its goals? Or do you just want us to help you, while you provide no help to us? (1) Wouldn't the doctors be better off getting a thick printed book? If you're really set on doing this with a computer, how about a US$300 Dell Mini 10v, with a 120GB hard drive, 1GB RAM, and modern processor? Or a US$330 Acer Aspire One 10.1 with 160GB and similar specs? It should be able to resume from disk-based hibernation in seconds, and easily be programmed to hibernate when the lid is closed. On my Acer, stock Ubuntu 9.04 resumes from hibernation in about 35 seconds, including 2 sec of grub menu delay, and there's lots of upstream interest if you find ways to speed it up. Or if you suspend to RAM, it wakes up in 4 seconds, but takes more power while it's closed. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
On Thu, Jun 4, 2009 at 5:55 AM, Mitch Bradley w...@laptop.org wrote: 18 seconds to initrd load dominated by decompression time. Eliminate the initrd ... I'm working on the initrd a but so tested a few things today. Once under linux, a cold-cache read of the initrd takes ~300ms, and the decompression about 1s. Changing the compression to '-1' (fastest) shaves maybe 200ms. OFW doesn't like non-gzipped initrds ;-) I'm tempted to say that reading/uncompressing the initrd is to blame only for about 1.3s -- probably 2s if we count cpio's work. This work is being carried out by OFW, which doesn't seem to be any slower -- following the messages on screen, the 'reading ramdisk' step doesn't take more than 2s. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
As for speedups, I see 2 different ways : a) using a SD with a fat partition + ext2 filesystem b) using the nand with a fat partition + ubifs - this requires 2.6.29 which is not ready yet. A FAT partition will not work well on the raw NAND of XO-1, because of blocksize, erase block size, and wear leveling issues. It would be better to use a smallish boot partition of say 10 MB, formatted in JFFS2. JFFS2 is fine for small partition sizes. It only starts to be troublesome with large partitions. It's hard to chose at the moment. I guess I'll stick to b) and hope 2.6.29 makes it better, and if it doesn't go for a) Mitch says there's very little time to gain and provides an excellent analysis. I just have a final question there : regarding the 2 seconds SPI flash slowdown, is there a way to boot from the NAND (without reading the full SPI) if there's a special partition at the beginning, or if there isn't or if a special key is pressed at boottime, go back to SPI OFW? That won't work. The only way that the CPU can start is by fetching from SPI FLASH. If you wanted to get into the firmware business, you could write a smallish NAND reader that loads from SPI FLASH then reads the rest from NAND. Doing so would require a substantial amount of detailed knowledge about the hardware, would be difficult to debug and maintain, would require great care to prevent bricking the machine if the NAND contents were overwritten, and might reduce the startup time by 1 second. To sum up what I've read in this thread, what should be done in any case : a) discarding jffs2 b) discarding initrd c) storing the kernel uncompressed in an uncompressed small partition Actually, there is an alternative to discarding the initrd. The trick would be to ensure that most of the stuff in the initrd is reused during runtime, thus avoiding the need to reload the same stuff later. I've done that with embedded systems, in which the entire filesystem is included in initrd, copied to a ram FS, and used forever. Loading initrd from a small JFFS2 partition is just as fast as loading the same amount of code/libraries/files from any other filesystem, and perhaps even faster, since the reads are likely to be sequential and can be done in large chunks. The case in which initrd is wasteful is when a large amount of stuff from initrd is discarded and then reloaded again from a different FS. And yes, this seems trivial to do - the low hanging fruit. Please, can we stop using the word trivial? Although you might not mean it that way, the subtext of saying things are trivial or easy is that the people who didn't do these obvious things in the past are stupid or lazy. It is true that many of the speedup techniques that have been discussed are individually easy to understand and think about, but putting together all the pieces and making them work together flawlessly requires a substantial amount of effort. I would be pleased to see someone make that effort, but asserting that the whole deal is easy is disrespectful to the people who have spent countless hours packaging the various OLPC distributions and sorting out many hundreds of little problems. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
Don't believe everything you read on a wiki. OFW has included support for partitioned NAND since the first production shipments, dating back to January 2008. The idea is to have a small boot partition that can be in any format that OFW supports - JFFS2, ext2, FAT, or even a .zip archive. JFFS2 is just fine on a small partition; the scan time for a few MB is negligeable. I have been lobbying for such a structure for about 2 years now, but never managed to get enough traction among the OS people to actually implement it in the XO software distribution. The OFW support for this is known to work, as debxo uses it. I'm sorry, I didn't know that and I didn't want to imply OFW was not the right tool for the job. I'm just very concerned by the current time it takes for a vanilla olpc to be ready, especially when compared to any netbook running moblin, so I'm exploring various ways to fix the problem (actually rereading every documentation that was send to me explaining various aspect of the OFW before starting the UBIFS tests, but I have limited time and I'd like to spend in on the UI rather than on the boot process) A lot of the changes that you see in moblin are already in newer kernels and even added to the boot process in Fedora which will be part of the next XO software release. You also have to realise that a atom cpu with a gig of ram and a relatively fast SSD are hardware wise an order of magnitude faster than the current Gen 1 XO hardware. The current stable release of the XO software is based on Fedora 9 and even on my relatively fast Dell laptop running Fedora 11 the time to boot from F-9 to F-11 has dropped by well over 2 minutes with all the various improvements that have been made to kernel device scanning, X startup and various other improvements. What would you suggest to have the kernel loaded in ram as quickly as possible? (I'd guess execute in place, but I think that's not possible) A fat partition with the zimage ? The time it takes for a kernel to be loaded into RAM is hardware dependant on things like the speed/bandwidth of the storage/bus/ram etc I'd also like to remove the initrd to try to shave some seconds. I don't need any antitheft protection, I just want to protect the nand against a reflash with a non approved software image, which IMHO is the most interesting feature of OFW. But if that's too complicated/requires the initrd or some weird other stuff, I'll scrap that too. I'm not sure you'll save that much by removing it. If you really want to play with boot speed I suggest you flash on a copy of Fedora 11 and then use some of their boot profiling tools to test and see where you can save time. BTW, could you point me to some documentation explaining how to have OFW immediately boot a kernel, without fancy sound/screen/counter? (only prioritising USB or MMC, so that it boots first if a media is inserted or if a struck esc key is detected it gives a command prompt) At a guess you'd need to recompile the OFW to remove them. I doubt it will save much time. I'm open to any additional suggestions. (I'll consider the sysvinit optimisations later) What version of XO software are you running? Have you tried SOAS or one of the F11/rawhide test images to see if that improves speed at all over 8.2.1? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
On Wed, Jun 3, 2009 at 11:34 AM, Peter Robinson pbrobin...@gmail.com wrote: What version of XO software are you running? Have you tried SOAS or one of the F11/rawhide test images to see if that improves speed at all over 8.2.1? SoaS boot on XO-1 hw is fairly slow, but as you say it has more potential than the F9 stack had. In other words, and area ripe for hacking if Guylhem is interested in faster boot times. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question (ext2/3 filesystem format evolution)
I'm thinking about ext4, but I must confess that my experience with ext2 has been pretty frustrating. The ext2/3 on-disk format has sprouted many new features over time. Supporting people who plug in disks that are formatted with the latest fancy feature, then complain that an old firmware release fails to work with it, is difficult. I just experienced this yesterday, plugging a new PATA 750GB disk drive into an Ubuntu 9.04 system, doing parted and mke2fs -j on it, then moving it to a Red Hat 7.3 system. Not only did RH7.3 parted complain about the alignment of the partition table, but the kernel would not mount the ext3 filesystem AT ALL, because Ubuntu had silently created it with 256-byte inodes rather than 128-byte ones, and the old kernel didn't support 256-byte inodes. The disk was empty, so I took the lesson and reformatted it *from the old system* rather than from the new system. Now it works with both. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
Guylhem Aznar wrote: Approx timings from pressing on the power button on my test machine using an old 2.6.22 on a jffs2 partition 2 seconds with the screen turned off There is very little that can be done to reduce that 2 seconds, which is dominated by the time it takes to read the firmware from the SPI FLASH. SPI FLASH access is very slow because it is done a byte at a time over the LPC bus, mediated by the embedded controller which is between the LPC bus and the SPI FLASH. That is the lowest-cost hardware solution. 8 seconds to the end the jingle Okay, right here you may be making an invalid assumption about what is happening. It is tempting to think that the jingle is taking all this time. But really what is happening is that the jingle sound is loaded from SPI FLASH into memory (takes 0.3 sec) and then played autonomously by the AC97 DMA hardware while other startup operations are being performed. The end of the jingle is not a useful milestone. 11 seconds to the first OFW mesages and boot delay The 11 second milestone reflects the following operations, which begin at the 2-second point, i.e. when the jingle starts playing: a) Init'ing the keyboard - takes about 1 second due to the startup characteristics of PS/2 keyboards. Can be reduced only at the risk of unreliable keyboard operation. b) Probing the USB bus. Takes from 0 to several seconds depending on what is plugged in. Some USB devices take up to 5 seconds before you can access them without hangs. c) Checking for a key to interrupt the boot sequence to get to the ok prompt. Takes 2 seconds, can be shortened only at the expense of making it harder to interrupt auto-boot. d) Checking for developer keys and bootable images on SD and USB. Usually very fast. e) Mounting JFFS2 from NAND and searching it for /boot/olpc.fth. This is the step that takes most of the time. On a minimal installation with no activities loaded - about 300 MB of NAND occupied- the JFFS2 mount takes 6 seconds. That time can increase quite a lot as more stuff is added to NAND and especially if the NAND gets badly fragmented. The interval from 2 to 11seconds is accounted for by the times mentioned above. If an SD card with Windows is installed, the time from power-on to the first Windows loader screen is 5 seconds, consist with progress through step (d) above. At the expense of some utility/reliablity, steps (a) and (c) above could be reduced, bringing the total time from power-on to transfer of control from OFW to the OS down to perhaps 3 seconds. But that last 2 seconds (from 5 down to 3) is not the low-hanging fruit ... If you want to boot from NAND, the clear win is to make a separate small boot partition and store the kernel on it in uncompressed form. Mounting a JFFS2 partition containing 3 MB of data is 100 times faster than mounting one with 300 MB, so 6 seconds reduces to 60 milliseconds. Gzip decompression goes at 3 MB/sec on a Geode, which is slower than NAND access time, so it's a win if the kernel isn't compressed (but with the standard kernel bzImage build procedures, you don't get an easy option to do that). 18 seconds to initrd load dominated by decompression time. Eliminate the initrd ... 25 to leds blinking The kernel remounts JFFS2 to get its root FS. Another 6 or so seconds. UBIFS in the system partition might help... 37 seconds to the kernel black screen JFFS2 is slowed down by the decompression time. Storing the stuff that is touched during startup in uncompressed form would help 45 seconds to mesh initialisation 52 seconds it init 2 starting its daemons 58 seconds to startx 1:04 seconds to having X loaded 1:10 seconds to having opera loaded and displaying the page Pretests results show a usage pattern where doctors prefer to power on the laptop when some specific information is needed. This behaviour is based on multiple factors, but in the end having a minute of delay is considered too long and could discourage users. IMHO jffs2 is only responsible for ~20 seconds (between initrd load and kernel black screen). I see ~10 other seconds before that which could be cut, if the boot status was saved and reused (something that old eeepcs do, saving HW status to the a special partition. Maybe ofw can also do that too?)Then there's 5 seconds of boot delay that a ofw recompilation can fix. As detailed above, the conjecture that you can shave 5 seconds by recompiling OFW is incorrect. The kernel init improvements will certainly bring 15 other seconds. Maybe some parallelisation of the sysvinit will save some time, say 5 seconds (low end estimation) Parallelization will not help at all if you are using JFFS2. The low level NAND driver that JFFS2 uses busy waits for I/O, and then JFFS2 is CPU-bound on the decompression step, preventing any useful concurrency. The busy-wait could be changed to an interrupt - if only someone had
Re: Bootloader question
Hi, I'm still preparing my custom images for the Haïti project, and I am quite disturbed by the JFFS2 boottime. From what I've read on the wiki, JFFS2 is here only because OFW doesn't know how to use UBIFS. I think its actually there because ubifs wasn't around when OLPC needed to make a decision on filesystems. UBIFS hasn't been around that long. This brings a question - is it possible to replace OFW with something that could use UBIFS? Say coreboot , or even a bios with grub, anything will do! No idea, but you can use a small /boot partition with jffs2 (or ext2) which is enough to boot the kernel and then have a ubifs root file system. If there's no security, if there's little functionality, not field upgrades etc, it will just be fine as long as it can boot any quicker. I just can't keep the boot delays currently experienced with jffs2 Well there's details of what experimentation was done with ubifs on the wiki here http://wiki.laptop.org/go/UBIFS_on_XO http://wiki.laptop.org/go/UBIFS_initial_experiments Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
On Tue, Jun 2, 2009 at 9:46 AM, Peter Robinson pbrobin...@gmail.com wrote: I think its actually there because ubifs wasn't around when OLPC needed to make a decision on filesystems. UBIFS hasn't been around that long. Exactly. We're very keen on hearing of people experimenting with it, reporting on performance and stability. It will be interesting to hear whether it's ready for production use. JFFS2, for all its faults, has been fairly resilient against powerloss-related corruption. This brings a question - is it possible to replace OFW with something that could use UBIFS? Say coreboot , or even a bios with grub, anything will do! That'd probably be a huge endeavour. Getting a BIOS to work on a particular piece of hardware is significant work... No idea, but you can use a small /boot partition with jffs2 (or ext2) which is enough to boot the kernel and then have a ubifs root file system. +1 on Peter's recommendation :-) m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
I think its actually there because ubifs wasn't around when OLPC needed to make a decision on filesystems. UBIFS hasn't been around that long. Exactly. We're very keen on hearing of people experimenting with it, reporting on performance and stability. It will be interesting to hear whether it's ready for production use. JFFS2, for all its faults, has been fairly resilient against powerloss-related corruption. I'd also be interested to know what is required to add support for new filesystems to OFW. ext4 now has the option to run without a journal which gives it the advantage that ext2 had over ext3 with a lot of the other improvements that come with ext4. I wonder what would be required to add support for it and the likes of ubifs? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
On Tue, Jun 2, 2009 at 3:33 PM, Peter Robinson pbrobin...@gmail.com wrote: I'd also be interested to know what is required to add support for new filesystems to OFW. ext4 now has the option to run without a journal which gives it the advantage that ext2 had over ext3 with a lot of the other improvements that come with ext4. I wonder what would be required to add support for it and the likes of ubifs? Well, Mitch might chime in, or there's the ofw mailing list :-). I'm sure OFW will get some ext2/3/4 support for the XO-1.5 hardware, which will have an FTL. For XO-1.0 users -- there's over a million of them -- FTLs are not an option, so it'll be interesting to see if ubifs works better. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
If you seriously are thinking of replacing OFW in your local OLPC trials in order to shave five or ten seconds off the boot time, then you have tons of talent but not much judgment -- and WAY too much time on your hands. Don't waste your time on trivia; put your talent into fixing some of the real major OLPC issues. (Like the lack of a high quality book reader on the laptop; or the few bugs preventing automatic suspend/resume support that would double the battery life; or the tiny kernel regression that makes it hang dead when it runs out of memory rather than killing a process; or the huge CPU load caused by thrashing executable pages in from a compressed flash filesystem.) Put your root filesystem on an SD card (and fix the bugs relating to SD cards not properly remounting after suspend) if you want to avoid JFFS2. John Gilmore ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
From what I've read on the wiki, JFFS2 is here only because OFW doesn't know how to use UBIFS. Don't believe everything you read on a wiki. As Peter Robinson says, JFFS is used because it was the only viable alternative at the time we were doing the initial development. UBIFS did not become viable from a technical standpoint until the middle of last year, and OLPC's software team hasn't had the resources to fully test UBIFS and do the very substantial amount of work necessary to change over to it. OFW would not have to change, because ... No idea, but you can use a small /boot partition with jffs2 (or ext2) which is enough to boot the kernel and then have a ubifs root file system. OFW has included support for partitioned NAND since the first production shipments, dating back to January 2008. The idea is to have a small boot partition that can be in any format that OFW supports - JFFS2, ext2, FAT, or even a .zip archive. JFFS2 is just fine on a small partition; the scan time for a few MB is negligeable. I have been lobbying for such a structure for about 2 years now, but never managed to get enough traction among the OS people to actually implement it in the XO software distribution. The OFW support for this is known to work, as debxo uses it. I'd also be interested to know what is required to add support for new filesystems to OFW. ext4 now has the option to run without a journal which gives it the advantage that ext2 had over ext3 with a lot of the other improvements that come with ext4. I wonder what would be required to add support for it and the likes of ubifs? I'm thinking about ext4, but I must confess that my experience with ext2 has been pretty frustrating. The ext2/3 on-disk format has sprouted many new features over time. Supporting people who plug in disks that are formatted with the latest fancy feature, then complain that an old firmware release fails to work with it, is difficult. I am more inclined to insist that the boot partition must be formatted with a stable format - stable in the sense that the spec rarely changes. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Bootloader question
Hello, On Tue, Jun 2, 2009 at 22:12, Mitch Bradley w...@laptop.org wrote: Don't believe everything you read on a wiki. OFW has included support for partitioned NAND since the first production shipments, dating back to January 2008. The idea is to have a small boot partition that can be in any format that OFW supports - JFFS2, ext2, FAT, or even a .zip archive. JFFS2 is just fine on a small partition; the scan time for a few MB is negligeable. I have been lobbying for such a structure for about 2 years now, but never managed to get enough traction among the OS people to actually implement it in the XO software distribution. The OFW support for this is known to work, as debxo uses it. I'm sorry, I didn't know that and I didn't want to imply OFW was not the right tool for the job. I'm just very concerned by the current time it takes for a vanilla olpc to be ready, especially when compared to any netbook running moblin, so I'm exploring various ways to fix the problem (actually rereading every documentation that was send to me explaining various aspect of the OFW before starting the UBIFS tests, but I have limited time and I'd like to spend in on the UI rather than on the boot process) What would you suggest to have the kernel loaded in ram as quickly as possible? (I'd guess execute in place, but I think that's not possible) A fat partition with the zimage ? I'd also like to remove the initrd to try to shave some seconds. I don't need any antitheft protection, I just want to protect the nand against a reflash with a non approved software image, which IMHO is the most interesting feature of OFW. But if that's too complicated/requires the initrd or some weird other stuff, I'll scrap that too. BTW, could you point me to some documentation explaining how to have OFW immediately boot a kernel, without fancy sound/screen/counter? (only prioritising USB or MMC, so that it boots first if a media is inserted or if a struck esc key is detected it gives a command prompt) I'm open to any additional suggestions. (I'll consider the sysvinit optimisations later) Thanks -- Dr. Guylhem Aznar, MD PhD Unité d'Analyse Médico-Économique Service de Santé Publique et d'Économie de la Santé Pôle SPSSR CHU de Fort de France BP 632 97261 Fort De France Cedex Martinique, France Tel : 05 96 55 23 47 Fax : 05 96 75 84 57 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Bootloader question
Hello I'm still preparing my custom images for the Haïti project, and I am quite disturbed by the JFFS2 boottime. From what I've read on the wiki, JFFS2 is here only because OFW doesn't know how to use UBIFS. This brings a question - is it possible to replace OFW with something that could use UBIFS? Say coreboot , or even a bios with grub, anything will do! If there's no security, if there's little functionality, not field upgrades etc, it will just be fine as long as it can boot any quicker. I just can't keep the boot delays currently experienced with jffs2 -- Dr. Guylhem Aznar, MD PhD Unité d'Analyse Médico-Économique Service de Santé Publique et d'Économie de la Santé Pôle SPSSR CHU de Fort de France BP 632 97261 Fort De France Cedex Martinique, France Tel : 05 96 55 23 47 Fax : 05 96 75 84 57 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
