Re: Openmoko to shift to 2.6.27 kernel ?
On Wed, 15 Oct 2008 15:14:28 +0200, Christ van Willegen [EMAIL PROTECTED] wrote: Andy, On Sat, Oct 11, 2008 at 2:29 PM, Andy Green [EMAIL PROTECTED] wrote: If you're interested to visit the edge and know how to DFU stuff around with NOR to get yourself in and out of trouble, you can get a moredrivers kernel here http://people.openmoko.org/andy/uImage-moredrivers-andy-tracking_2ffb4cc483642df1.bin I dfu-util'led this into my 'kernel' partition, and also the qi image into by u-boot. After that, the red led started flashing. IIRC that means that there is no kernel to boot. I then panicked and replaced the u-boot with the one from OM20080917. That didn't help, so I also DFU'd the kernel from OM20080917. That fixed my phone (I could boot again!), but I'm left wondering what I did wrong... AFAIK I can just do 'sudo dfu-util -D uImage-moredrivers-andy-tracking_2ffb4cc483642df1.bin -a kernel -R' to flash your kernel, but that may not be the case... Christ van Willegen (who sometimes likes to be on the edge, and will re-flash with QI again tonight...) No, as I found out and Andy confirmed several messages back in this thread. His 2.6.27 kernel image has issues running from NAND, has to be on uSD. Qi will boot from any kernel named 'uImage.bin' in the /boot folder in the root of an ext2/ext3 partition - first partition - on the uSD. failing to find that, it will boot from the kernel in NAND, but that an't be the current 2.6.27 uImage. Also, I wanted to revisit this thread to post some stopwatch results on Qi (error is approx ±1/2 second): Booting SHR image with uBoot: 0:00 power button held down 0:07 splash screen appears 0:15 drops to console showing kernel messages scrolling by for ~1 minute 1:18 Openmoko 'please wait' splash 1:31 desktop animated splash 2:38 finished booting Booting identical setup with Qi flashed over uBoot: 0:00 power button held down 0:06 backlit black 0:13 please wait booting... (only this text on console for next 38 seconds) 0:51 Angstrom console message (at the end of kernel output with uBoot, but ONLY text display to appear throughout this stage with Qi) 0:54 Openmoko 'please wait' splash 1:05 desktop animated splash 1:54 finished booting So for this particular configuration, it reduced time-to-desktop by about 28%, about 44 seconds. I was pleasantly surprised to see that the later segments of booting (desktop) were also noticeably faster than with uBoot - I'd expected just the fist stages up until init (kernel finished establishing itself) to be faster. My previously-posted estimate of boot time improvement was based on the appearance of the post-kernel splash - 'please wait' in the case of SHR - not then noticing improvements later in the boot process. I'll be thrilled if we can get it under one minute, preferably with GSM powered up at the earliest possible point, and maybe putting up a dialer instead of a splash screen. (something like 25 seconds to dial, 60 seconds for full system finished loading) (Note that I still have the problem where Qi won't boot the 'first try' after power restored - I didn't count that first 10 seconds for Qi to be fair to its booting speed, not penalize it for what appears to be a bug that bears no relation to actual boot speed) j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
Joel Newkirk wrote: On Wed, 15 Oct 2008 07:05:59 +0200, Marco Trevisan (Treviño) Isn't there a way to update/configure the NOR u-Boot too? http://wiki.openmoko.org/wiki/Flashing_NOR The NOR image sample there is a broken link now. I'm presuming that it's NOT just the same u-boot bin as is flashed to NAND either, so it looks like doing this is possible but not simple, and most of us wouldn't be equipped to do it. (lacking debug board to enable write mode) Mh, ok... So the debug board is absolutely needed... :/ I figure I'll continue with my NAND... :) -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
Andy, On Sat, Oct 11, 2008 at 2:29 PM, Andy Green [EMAIL PROTECTED] wrote: If you're interested to visit the edge and know how to DFU stuff around with NOR to get yourself in and out of trouble, you can get a moredrivers kernel here http://people.openmoko.org/andy/uImage-moredrivers-andy-tracking_2ffb4cc483642df1.bin I dfu-util'led this into my 'kernel' partition, and also the qi image into by u-boot. After that, the red led started flashing. IIRC that means that there is no kernel to boot. I then panicked and replaced the u-boot with the one from OM20080917. That didn't help, so I also DFU'd the kernel from OM20080917. That fixed my phone (I could boot again!), but I'm left wondering what I did wrong... AFAIK I can just do 'sudo dfu-util -D uImage-moredrivers-andy-tracking_2ffb4cc483642df1.bin -a kernel -R' to flash your kernel, but that may not be the case... Christ van Willegen (who sometimes likes to be on the edge, and will re-flash with QI again tonight...) -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
On Tuesday 14 October 2008 02:58:13 Joel Newkirk wrote: On Mon, 13 Oct 2008 17:48:50 +0200, David Samblas [EMAIL PROTECTED] wrote: El lun, 13-10-2008 a las 00:42 -0400, Joel Newkirk escribió: Which one way or another goes to highlight that Qi - as it stands now and from what I understand of the intention for it - will not be usable for a dual-boot setup. Not a problem actually, as NOR uBoot will let us achieve that, and I realize that the common target case will be a user who wants a smartphone, not a multiboot development platform. I just realized that the default behavior of Qi being uSD and the default behavior of uBoot being NAND means you could place 'primary' on uSD and 'secondary' in NAND, and booting to secondary is just two-step - NOR boot with aux+power, then power again to boot. Don't you love that feeling when things start to click? :) Now I have Base/Empty firing up by default, Raster+FSO if I use aux to invoke NOR Uboot. j I'm not a kernel hacker only a user, but as I undertand It would be better to invert that behaviour, better to primary boot from NAND and then secondary boot on uSD, a normal user must boot his phone even without any uSD. Normal boot to nand, and if you want to boot from anything else do something else. It's a pitty than NOR uboot doesn't allow to boot from uSD by default, but this fault does't have to change the logical behaviour NAND is attached to the phone and is less likely blow up the hole S.O. sa mistake by a normal user putting some music in his uSD card trough a 2.0 Card reader :) seekeng for some free space If there's NO uSD, or the uSD doesn't contain a folder named 'boot' on the first partition, with a file named 'uImage.bin', then Qi will boot from NAND. It's just if you WANT a dual-boot environment that currently Qi doesn't let you do that simply. As Andy noted in his response to that post, however, he plans for Qi to support user selection of boot, it just doesn't do it at this time. Until it offers the ability to select, then the present behavior (check for kernel on uSD, else use NAND) makes more sense that always going to NAND and only NAND. I'm guessing with the current scenario, invoking a generic boot from nor means you lose any benefits of an updated u-boot/qi in nand? As in you may see power management regressions and the like? Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
On Wed, 15 Oct 2008 12:03:53 +1100, Sarton O'Brien [EMAIL PROTECTED] wrote: On Tuesday 14 October 2008 02:58:13 Joel Newkirk wrote: If there's NO uSD, or the uSD doesn't contain a folder named 'boot' on the first partition, with a file named 'uImage.bin', then Qi will boot from NAND. It's just if you WANT a dual-boot environment that currently Qi doesn't let you do that simply. As Andy noted in his response to that post, however, he plans for Qi to support user selection of boot, it just doesn't do it at this time. Until it offers the ability to select, then the present behavior (check for kernel on uSD, else use NAND) makes more sense that always going to NAND and only NAND. I'm guessing with the current scenario, invoking a generic boot from nor means you lose any benefits of an updated u-boot/qi in nand? As in you may see power management regressions and the like? Sarton Correct. NOR U-Boot only supports SD booting off FAT+EXT3, for example - if the kernel isn't in a FAT/VFAT partition it barfs. (though interestingly it should be possible to boot the same distro off SD with either of two kernels - Qi looking for /boot/uImage.bin and NOR UBoot looking for a uImage file in the root of a FAT partition) j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
Joel Newkirk wrote: On Wed, 15 Oct 2008 12:03:53 +1100, Sarton O'Brien [EMAIL PROTECTED] wrote: I'm guessing with the current scenario, invoking a generic boot from nor means you lose any benefits of an updated u-boot/qi in nand? As in you may see power management regressions and the like? Sarton Correct. NOR U-Boot only supports SD booting off FAT+EXT3, for example - if the kernel isn't in a FAT/VFAT partition it barfs. (though interestingly it should be possible to boot the same distro off SD with either of two kernels - Qi looking for /boot/uImage.bin and NOR UBoot looking for a uImage file in the root of a FAT partition) Isn't there a way to update/configure the NOR u-Boot too? -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
On Wed, 15 Oct 2008 07:05:59 +0200, Marco Trevisan (Treviño) [EMAIL PROTECTED] wrote: Joel Newkirk wrote: On Wed, 15 Oct 2008 12:03:53 +1100, Sarton O'Brien [EMAIL PROTECTED] wrote: I'm guessing with the current scenario, invoking a generic boot from nor means you lose any benefits of an updated u-boot/qi in nand? As in you may see power management regressions and the like? Sarton Correct. NOR U-Boot only supports SD booting off FAT+EXT3, for example - if the kernel isn't in a FAT/VFAT partition it barfs. (though interestingly it should be possible to boot the same distro off SD with either of two kernels - Qi looking for /boot/uImage.bin and NOR UBoot looking for a uImage file in the root of a FAT partition) Isn't there a way to update/configure the NOR u-Boot too? http://wiki.openmoko.org/wiki/Flashing_NOR The NOR image sample there is a broken link now. I'm presuming that it's NOT just the same u-boot bin as is flashed to NAND either, so it looks like doing this is possible but not simple, and most of us wouldn't be equipped to do it. (lacking debug board to enable write mode) j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
On Mon, 13 Oct 2008 00:42:13 -0400, Joel Newkirk [EMAIL PROTECTED] wrote: On Sun, 12 Oct 2008 18:29:53 +0100, Andy Green [EMAIL PROTECTED] wrote: Thanks a lot for trying it and reporting it, you'll get further with uSD boot right now. Now I've successfully booted from uSD with Base Image and 2.6.27. Linux om-gta02 2.6.27-andy-tracking_2ffb4cc483642df1-mokodev #12 PREEMPT Sat Oct 11 13:06:05 BST 2008 armv4tl unknown. (although every other attempt or I've got more on this now. After complete absence of power, when power is restored Qi does NOT start up the first time the power button is held down for 10+ secs. I have to do it a second time. And (not yet sure if it's Qi or not, but I've seen it with a couple images and 2.6.24 and 2.6.27 kernels off SD) when the system goes to suspend it will at best only come back without LCD, but usually is gone, and no mashing of power button helps, I need to pull the battery. j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joel Newkirk wrote: Now I've successfully booted from uSD with Base Image and 2.6.27. Linux om-gta02 2.6.27-andy-tracking_2ffb4cc483642df1-mokodev #12 PREEMPT Sat Oct 11 13:06:05 BST 2008 armv4tl unknown. (although every other attempt or so it seems to hang at a blank console with a blinking cursor, not really mapped that behavior out yet) Depending on your rootfs (ie, Debian) it can be doing fsck on your ext3 filesystem during initscripts there and seem pretty hung -- you'd be able to see it with debug board. Which one way or another goes to highlight that Qi - as it stands now and from what I understand of the intention for it - will not be usable for a dual-boot setup. Not a problem actually, as NOR uBoot will let us achieve What's planned for partition selection is you will in future be able to press AUX while Qi is pulling in the kernel it selected to abort the load and move to next usable partition, so I think multiboot will work out fine if you can remember which n'th rootfs it is you want... hopefully only a problem for people with 2. that, and I realize that the common target case will be a user who wants a smartphone, not a multiboot development platform. I just realized that the default behavior of Qi being uSD and the default behavior of uBoot being NAND means you could place 'primary' on uSD and 'secondary' in NAND, and booting to secondary is just two-step - NOR boot with aux+power, then power again to boot. Don't you love that feeling when things start to click? :) Now I have Base/Empty firing up by default, Raster+FSO if I use aux to invoke NOR Uboot. It's a nice idea to leverage NOR but I think Qi will take care of it soon and allow more that one alternative rootfs. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjy+hIACgkQOjLpvpq7dMr5TgCglEzStrw+GUdzuGSgH8cIgT97 gEoAn0RzSvpWC7BQsaJDlbYrXj482XZ5 =V6W/ -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
On Mon, Oct 13, 2008 at 09:34, Andy Green [EMAIL PROTECTED] wrote: What's planned for partition selection is you will in future be able to press AUX while Qi is pulling in the kernel it selected to abort the load and move to next usable partition, so I think multiboot will work out fine if you can remember which n'th rootfs it is you want... hopefully only a problem for people with 2. But in this case will you have visual feedback on this partition switch ? For more complex multi-boots, could the solution be a partition booting a simple kernel and show a multi-boot screen, from were you can ask Qi to re-boot on a given other partition ? (or even simply continue with already loaded kernel if wanted) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cédric Berger wrote: On Mon, Oct 13, 2008 at 09:34, Andy Green [EMAIL PROTECTED] wrote: What's planned for partition selection is you will in future be able to press AUX while Qi is pulling in the kernel it selected to abort the load and move to next usable partition, so I think multiboot will work out fine if you can remember which n'th rootfs it is you want... hopefully only a problem for people with 2. But in this case will you have visual feedback on this partition switch ? We can flash an LED to acknowledge we skipped that partition, so you can see what's happening. For more complex multi-boots, could the solution be a partition booting a simple kernel and show a multi-boot screen, from were you can ask Qi to re-boot on a given other partition ? (or even simply continue with already loaded kernel if wanted) Yes... it's also discussed, a recovery / backup kernel and rootfs that can execute other kernels. There are big advantages for us in a normal Linux implementation that is actually maintainable from single source tree for kernel and common packageset for the rootfs associated with it. Networking can be up so you can ssh in to rescue or update partitions, etc, all the normal Linux goodness comes pretty much for free then. But in general it will be slower than clicking AUX if all you want is to select another partition. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjzEZEACgkQOjLpvpq7dMoh7gCeIZJz1/UtUVHQvRs1oh+NQYRt OqAAniXqMQlj6s40yKgvClFYQG7GGo7u =Q+nx -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
El lun, 13-10-2008 a las 00:42 -0400, Joel Newkirk escribió: On Sun, 12 Oct 2008 18:29:53 +0100, Andy Green [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joel Newkirk wrote: Qi boots like a dream - no kernel messages scrolling by, just turns on backlight on a black screen for about 5 seconds (heartstopper of sorts the first time) then the graphical boot progress screen appears. I'd guesstimate that overall boot time was improved perhaps 15%. Great. NOTE for other 'daredevils': Qi does NOT provide a boot menu. (at least not that I could find, not at this point) The usual NOR uBoot menu you use Right Qi's concept is it leaves everything possible to Linux, that includes even the video init. You can use NOR U-Boot on Freerunner to do DFU or other U-Boot specific stuff. Qi has a list of bootable devices and currently will try uSD partition 1 for /boot/uImage.bin, if that is not working out then it will try the NAND kernel partition. Currently 2.6.27 doesn't do mtd properly and blows chunks with these CRC errors, didn't find why yet. But it does work with uSD boot on ext3 OK. The red LED thing is what we do on kernel panic... it's panicking because it can't mount the jffs2 part because of the CRC errors, then it has no rootfs. Thanks a lot for trying it and reporting it, you'll get further with uSD boot right now. I finally realized that you meant boot from uSD-based system, rather than just pull the kernel from uSD - I tried 2.6.27 and 2008.8-update uImage in /media/card/boot and just got blinking red kernel panic LED. Now I've successfully booted from uSD with Base Image and 2.6.27. Linux om-gta02 2.6.27-andy-tracking_2ffb4cc483642df1-mokodev #12 PREEMPT Sat Oct 11 13:06:05 BST 2008 armv4tl unknown. (although every other attempt or so it seems to hang at a blank console with a blinking cursor, not really mapped that behavior out yet) Which one way or another goes to highlight that Qi - as it stands now and from what I understand of the intention for it - will not be usable for a dual-boot setup. Not a problem actually, as NOR uBoot will let us achieve that, and I realize that the common target case will be a user who wants a smartphone, not a multiboot development platform. I just realized that the default behavior of Qi being uSD and the default behavior of uBoot being NAND means you could place 'primary' on uSD and 'secondary' in NAND, and booting to secondary is just two-step - NOR boot with aux+power, then power again to boot. Don't you love that feeling when things start to click? :) Now I have Base/Empty firing up by default, Raster+FSO if I use aux to invoke NOR Uboot. j I'm not a kernel hacker only a user, but as I undertand It would be better to invert that behaviour, better to primary boot from NAND and then secondary boot on uSD, a normal user must boot his phone even without any uSD. Normal boot to nand, and if you want to boot from anything else do something else. It's a pitty than NOR uboot doesn't allow to boot from uSD by default, but this fault does't have to change the logical behaviour NAND is attached to the phone and is less likely blow up the hole S.O. sa mistake by a normal user putting some music in his uSD card trough a 2.0 Card reader :) seekeng for some free space ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
On Mon, 13 Oct 2008 17:48:50 +0200, David Samblas [EMAIL PROTECTED] wrote: El lun, 13-10-2008 a las 00:42 -0400, Joel Newkirk escribió: Which one way or another goes to highlight that Qi - as it stands now and from what I understand of the intention for it - will not be usable for a dual-boot setup. Not a problem actually, as NOR uBoot will let us achieve that, and I realize that the common target case will be a user who wants a smartphone, not a multiboot development platform. I just realized that the default behavior of Qi being uSD and the default behavior of uBoot being NAND means you could place 'primary' on uSD and 'secondary' in NAND, and booting to secondary is just two-step - NOR boot with aux+power, then power again to boot. Don't you love that feeling when things start to click? :) Now I have Base/Empty firing up by default, Raster+FSO if I use aux to invoke NOR Uboot. j I'm not a kernel hacker only a user, but as I undertand It would be better to invert that behaviour, better to primary boot from NAND and then secondary boot on uSD, a normal user must boot his phone even without any uSD. Normal boot to nand, and if you want to boot from anything else do something else. It's a pitty than NOR uboot doesn't allow to boot from uSD by default, but this fault does't have to change the logical behaviour NAND is attached to the phone and is less likely blow up the hole S.O. sa mistake by a normal user putting some music in his uSD card trough a 2.0 Card reader :) seekeng for some free space If there's NO uSD, or the uSD doesn't contain a folder named 'boot' on the first partition, with a file named 'uImage.bin', then Qi will boot from NAND. It's just if you WANT a dual-boot environment that currently Qi doesn't let you do that simply. As Andy noted in his response to that post, however, he plans for Qi to support user selection of boot, it just doesn't do it at this time. Until it offers the ability to select, then the present behavior (check for kernel on uSD, else use NAND) makes more sense that always going to NAND and only NAND. j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
[Sorry, this may be slightly off topic] May I draw the attention of those whom it might concern to the following article on LWN, where some guys got linux to boot on an eee pc in 5 seconds: http://lwn.net/Articles/299483/ Am I the only one whose eyes are dreamy and glazed over after reading this? Can we learn anything from this? 2008/10/13 Joel Newkirk [EMAIL PROTECTED]: On Mon, 13 Oct 2008 17:48:50 +0200, David Samblas [EMAIL PROTECTED] wrote: El lun, 13-10-2008 a las 00:42 -0400, Joel Newkirk escribió: Which one way or another goes to highlight that Qi - as it stands now and from what I understand of the intention for it - will not be usable for a dual-boot setup. Not a problem actually, as NOR uBoot will let us achieve that, and I realize that the common target case will be a user who wants a smartphone, not a multiboot development platform. I just realized that the default behavior of Qi being uSD and the default behavior of uBoot being NAND means you could place 'primary' on uSD and 'secondary' in NAND, and booting to secondary is just two-step - NOR boot with aux+power, then power again to boot. Don't you love that feeling when things start to click? :) Now I have Base/Empty firing up by default, Raster+FSO if I use aux to invoke NOR Uboot. j I'm not a kernel hacker only a user, but as I undertand It would be better to invert that behaviour, better to primary boot from NAND and then secondary boot on uSD, a normal user must boot his phone even without any uSD. Normal boot to nand, and if you want to boot from anything else do something else. It's a pitty than NOR uboot doesn't allow to boot from uSD by default, but this fault does't have to change the logical behaviour NAND is attached to the phone and is less likely blow up the hole S.O. sa mistake by a normal user putting some music in his uSD card trough a 2.0 Card reader :) seekeng for some free space If there's NO uSD, or the uSD doesn't contain a folder named 'boot' on the first partition, with a file named 'uImage.bin', then Qi will boot from NAND. It's just if you WANT a dual-boot environment that currently Qi doesn't let you do that simply. As Andy noted in his response to that post, however, he plans for Qi to support user selection of boot, it just doesn't do it at this time. Until it offers the ability to select, then the present behavior (check for kernel on uSD, else use NAND) makes more sense that always going to NAND and only NAND. j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
El lun, 13-10-2008 a las 11:58 -0400, Joel Newkirk escribió: On Mon, 13 Oct 2008 17:48:50 +0200, David Samblas [EMAIL PROTECTED] wrote: El lun, 13-10-2008 a las 00:42 -0400, Joel Newkirk escribió: Which one way or another goes to highlight that Qi - as it stands now and from what I understand of the intention for it - will not be usable for a dual-boot setup. Not a problem actually, as NOR uBoot will let us achieve that, and I realize that the common target case will be a user who wants a smartphone, not a multiboot development platform. I just realized that the default behavior of Qi being uSD and the default behavior of uBoot being NAND means you could place 'primary' on uSD and 'secondary' in NAND, and booting to secondary is just two-step - NOR boot with aux+power, then power again to boot. Don't you love that feeling when things start to click? :) Now I have Base/Empty firing up by default, Raster+FSO if I use aux to invoke NOR Uboot. j I'm not a kernel hacker only a user, but as I undertand It would be better to invert that behaviour, better to primary boot from NAND and then secondary boot on uSD, a normal user must boot his phone even without any uSD. Normal boot to nand, and if you want to boot from anything else do something else. It's a pitty than NOR uboot doesn't allow to boot from uSD by default, but this fault does't have to change the logical behaviour NAND is attached to the phone and is less likely blow up the hole S.O. sa mistake by a normal user putting some music in his uSD card trough a 2.0 Card reader :) seekeng for some free space If there's NO uSD, or the uSD doesn't contain a folder named 'boot' on the first partition, with a file named 'uImage.bin', then Qi will boot from NAND. It's just if you WANT a dual-boot environment that currently Qi doesn't let you do that simply. As Andy noted in his response to that post, however, he plans for Qi to support user selection of boot, it just doesn't do it at this time. Until it offers the ability to select, then the present behavior (check for kernel on uSD, else use NAND) makes more sense that always going to NAND and only NAND. j OK that make sense , I have not fully understood Qi boot mechanism thaks for your explanation Joel :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
Andy Green ha scritto: Cédric Berger wrote: On Mon, Oct 13, 2008 at 09:34, Andy Green [EMAIL PROTECTED] wrote: What's planned for partition selection is you will in future be able to press AUX while Qi is pulling in the kernel it selected to abort the load and move to next usable partition, so I think multiboot will work out fine if you can remember which n'th rootfs it is you want... hopefully only a problem for people with 2. But in this case will you have visual feedback on this partition switch ? We can flash an LED to acknowledge we skipped that partition, so you can see what's happening. For more complex multi-boots, could the solution be a partition booting a simple kernel and show a multi-boot screen, from were you can ask Qi to re-boot on a given other partition ? (or even simply continue with already loaded kernel if wanted) Yes... it's also discussed, a recovery / backup kernel and rootfs that can execute other kernels. There are big advantages for us in a normal Linux implementation that is actually maintainable from single source tree for kernel and common packageset for the rootfs associated with it. Networking can be up so you can ssh in to rescue or update partitions, etc, all the normal Linux goodness comes pretty much for free then. But in general it will be slower than clicking AUX if all you want is to select another partition. I know but I'd agree on adding a menu for switching partions... Actually I'm using the u-boot with a multi-boot and I'm very happy with it (pratically I've made 6 partitions in my µSD, in the first one I keep the kernels named with uImage-name-of-the-distro.bin and in the others I've put the needed rootfs; so I can run easily lots of distros), but if Qi could improve the performances I'd like to get the same also without u-Boot. Is all this possible/planned? -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
On Sat, 11 Oct 2008 17:21:35 +0200 Marco Trevisan (Treviño) [EMAIL PROTECTED] wrote: Yes it is usable... I've tried it weeks ago and it basically said me that gpsd was using really so much cycles also if the GPS was off, that's why I generally kill it if I've no GPS need. But it was saying also many other things that kernel devs should understand better than me. Will it be considered for optimizing the power usage? Well , i guess major problem with FR power saving is about suspend/resume issue and i believe om developers have pretty good idea on which process consuming how much battery , anyway , powertop will help users / community distribution makers a bit :) -- Armin ranjbar , System Administrator ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joel Newkirk wrote: Qi boots like a dream - no kernel messages scrolling by, just turns on backlight on a black screen for about 5 seconds (heartstopper of sorts the first time) then the graphical boot progress screen appears. I'd guesstimate that overall boot time was improved perhaps 15%. Great. NOTE for other 'daredevils': Qi does NOT provide a boot menu. (at least not that I could find, not at this point) The usual NOR uBoot menu you use Right Qi's concept is it leaves everything possible to Linux, that includes even the video init. You can use NOR U-Boot on Freerunner to do DFU or other U-Boot specific stuff. Qi has a list of bootable devices and currently will try uSD partition 1 for /boot/uImage.bin, if that is not working out then it will try the NAND kernel partition. The kernel wasn't so dreamy... On first flash a few trillion CRC errors seemed to scroll by, then it hung. Subsequent attempts: with Qi I get Currently 2.6.27 doesn't do mtd properly and blows chunks with these CRC errors, didn't find why yet. But it does work with uSD boot on ext3 OK. white screen for a half second, then backlighted black screen for a couple seconds, then off, with AUX red LED blinking about 4/sec. If I boot into NOR uBoot and select 'boot', I can see the screen as it load the kernel and starts it up. Then I get 17 lines on the screen, with AUX red LED again blinking ~4/sec: The red LED thing is what we do on kernel panic... it's panicking because it can't mount the jffs2 part because of the CRC errors, then it has no rootfs. lis302dl lis302dl.1: unknown who_am_i signature 0x00 lis302dl lis302dl.2: unknown who_am_i signature 0x00 kernel panic: not syncing: Attempted to kill init! (lis302dl are the accelerometers) Yes accel code is undergoing renovation and is broken right now, all the others are actually just informational. space. In this broken state, the instant I restored power (remove/replace battery) the blue Power LED came on, blinked off for a fraction of a second every 10 secs or so. I've never seen this before - is it coming from Qi?? It was really instantaneous upon battery reinsertion, I didn't press power or anything. (I thought it sat in powered-down state at that point, guess I was mistaken) Yes Qi has tried all its boot devices looking for valid kernel and reacted with the blue light when it sees it has nothing valid to boot. Thanks a lot for trying it and reporting it, you'll get further with uSD boot right now. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjyNBAACgkQOjLpvpq7dMpA9QCfQFHzU+qRnca4MUFyZeWJvmsP 4EYAn0o/RyaMxo6BOToxviccQn8TTLQx =dxjG -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
On Sun, 12 Oct 2008 18:29:53 +0100, Andy Green [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joel Newkirk wrote: Qi boots like a dream - no kernel messages scrolling by, just turns on backlight on a black screen for about 5 seconds (heartstopper of sorts the first time) then the graphical boot progress screen appears. I'd guesstimate that overall boot time was improved perhaps 15%. Great. NOTE for other 'daredevils': Qi does NOT provide a boot menu. (at least not that I could find, not at this point) The usual NOR uBoot menu you use Right Qi's concept is it leaves everything possible to Linux, that includes even the video init. You can use NOR U-Boot on Freerunner to do DFU or other U-Boot specific stuff. Qi has a list of bootable devices and currently will try uSD partition 1 for /boot/uImage.bin, if that is not working out then it will try the NAND kernel partition. Currently 2.6.27 doesn't do mtd properly and blows chunks with these CRC errors, didn't find why yet. But it does work with uSD boot on ext3 OK. The red LED thing is what we do on kernel panic... it's panicking because it can't mount the jffs2 part because of the CRC errors, then it has no rootfs. Thanks a lot for trying it and reporting it, you'll get further with uSD boot right now. I finally realized that you meant boot from uSD-based system, rather than just pull the kernel from uSD - I tried 2.6.27 and 2008.8-update uImage in /media/card/boot and just got blinking red kernel panic LED. Now I've successfully booted from uSD with Base Image and 2.6.27. Linux om-gta02 2.6.27-andy-tracking_2ffb4cc483642df1-mokodev #12 PREEMPT Sat Oct 11 13:06:05 BST 2008 armv4tl unknown. (although every other attempt or so it seems to hang at a blank console with a blinking cursor, not really mapped that behavior out yet) Which one way or another goes to highlight that Qi - as it stands now and from what I understand of the intention for it - will not be usable for a dual-boot setup. Not a problem actually, as NOR uBoot will let us achieve that, and I realize that the common target case will be a user who wants a smartphone, not a multiboot development platform. I just realized that the default behavior of Qi being uSD and the default behavior of uBoot being NAND means you could place 'primary' on uSD and 'secondary' in NAND, and booting to secondary is just two-step - NOR boot with aux+power, then power again to boot. Don't you love that feeling when things start to click? :) Now I have Base/Empty firing up by default, Raster+FSO if I use aux to invoke NOR Uboot. j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Openmoko to shift to 2.6.27 kernel ?
Well , 2.6.27 released , i have noticed few Great feature that can help Openmoko device , * Kexec hibernation * Voltage and Current Regulator -- Armin ranjbar , System Administrator ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
On Sat, 11 Oct 2008 10:35:37 +0330, Armin ranjbar [EMAIL PROTECTED] wrote: Well , 2.6.27 released , i have noticed few Great feature that can help Openmoko device , * Kexec hibernation * Voltage and Current Regulator Another very handy new 'feature': UVC and GSPCA webcam drivers are both now in the kernel tree. Between them they support the majority of webcams. http://linux-uvc.berlios.de/#devices http://mxhaard.free.fr/spca5xx.html j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
On Sat, 11 Oct 2008 13:29:39 +0100 Andy Green [EMAIL PROTECTED] wrote: Good , is there any milestone , todo on this ? how we can help ? By the way , why don't you include 'powertop' ? Hi - I spent a lot of time tracking upstream HEAD for several months, we do have development 2.6.27 kernel based on upstream release 2.6.27. Not everything works yet but it's basically there. If you're interested to visit the edge and know how to DFU stuff around with NOR to get yourself in and out of trouble, you can get a moredrivers kernel here -- Armin ranjbar , System Administrator ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
Armin ranjbar wrote: Well , 2.6.27 released , i have noticed few Great feature that can help Openmoko device , * Voltage and Current Regulator really? they included phc? fantastic one thing which would be good for openmoko too and which was included is that they included ubifs which is way better than jffs ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Armin ranjbar wrote: Well , 2.6.27 released , i have noticed few Great feature that can help Openmoko device , * Kexec hibernation * Voltage and Current Regulator Hi - I spent a lot of time tracking upstream HEAD for several months, we do have development 2.6.27 kernel based on upstream release 2.6.27. Not everything works yet but it's basically there. If you're interested to visit the edge and know how to DFU stuff around with NOR to get yourself in and out of trouble, you can get a moredrivers kernel here http://people.openmoko.org/andy/uImage-moredrivers-andy-tracking_2ffb4cc483642df1.bin sources: http://git.openmoko.org/?p=kernel.git;a=shortlog;h=andy-tracking for daredevils this works with the U-Boot replacement Qi (image is ready for DFU into NAND bootloader) http://people.openmoko.org/andy/qi-andy_ab8665e9ac10a054.udfu sources: http://git.openmoko.org/?p=qi.git;a=summary Qi will boot from /boot/uImage.bin on ext2 first partition of SD Card if present, else fallback to NAND kernel. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjwnDIACgkQOjLpvpq7dMpUowCdEhjwd8zr4QrG88fTZpkeazRk LbgAnivd3tooU/dpJdw/Kalj+DWfbHIz =H0bO -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
Armin ranjbar wrote: On Sat, 11 Oct 2008 13:29:39 +0100 Andy Green [EMAIL PROTECTED] wrote: Good , is there any milestone , todo on this ? how we can help ? By the way , why don't you include 'powertop' ? Hi - I spent a lot of time tracking upstream HEAD for several months, we do have development 2.6.27 kernel based on upstream release 2.6.27. Not everything works yet but it's basically there. If you're interested to visit the edge and know how to DFU stuff around with NOR to get yourself in and out of trouble, you can get a moredrivers kernel here Maybe because afaik powertop is by intel and for x86 cpus only? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
On Sat, 11 Oct 2008 15:22:54 +0200 Bumbl [EMAIL PROTECTED] wrote: Maybe because afaik powertop is by intel and for x86 cpus only? humm ... is it ? since debian has Arm package for that , i thought its usable on arm -- Armin ranjbar , System Administrator ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
On Saturday 11 October 2008, Andy Green wrote: for daredevils this works with the U-Boot replacement Qi (image is ready for DFU into NAND bootloader) http://people.openmoko.org/andy/qi-andy_ab8665e9ac10a054.udfu sources: http://git.openmoko.org/?p=qi.git;a=summary Qi will boot from /boot/uImage.bin on ext2 first partition of SD Card if present, else fallback to NAND kernel. Hi Andy! I'm just curious: What are the goals of Qi? I had a look at git and noticed that you basically wrote it from scratch. Is it just a proof of concept or is it going to replace u-boot? Cheers, Florian -- DI Florian Hackenberger [EMAIL PROTECTED] www.hackenberger.at ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
Armin ranjbar wrote: On Sat, 11 Oct 2008 15:22:54 +0200 Bumbl [EMAIL PROTECTED] wrote: Maybe because afaik powertop is by intel and for x86 cpus only? humm ... is it ? since debian has Arm package for that , i thought its usable on arm Yes it is usable... I've tried it weeks ago and it basically said me that gpsd was using really so much cycles also if the GPS was off, that's why I generally kill it if I've no GPS need. But it was saying also many other things that kernel devs should understand better than me. Will it be considered for optimizing the power usage? -- Treviño's World - Life and Linux http://www.3v1n0.net/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florian Hackenberger wrote: On Saturday 11 October 2008, Andy Green wrote: for daredevils this works with the U-Boot replacement Qi (image is ready for DFU into NAND bootloader) http://people.openmoko.org/andy/qi-andy_ab8665e9ac10a054.udfu sources: http://git.openmoko.org/?p=qi.git;a=summary Qi will boot from /boot/uImage.bin on ext2 first partition of SD Card if present, else fallback to NAND kernel. Hi Andy! I'm just curious: What are the goals of Qi? I had a look at git and noticed that you basically wrote it from scratch. Is it just a proof of concept or is it going to replace u-boot? Actually Xiangfu did the work to chop down U-Boot and get it started. After that I gave it more attention. U-Boot is basically on a mission to duplicate Linux, it's quite obvious when you look at the flow of drivers from Linux to U-Boot, getting dumber and they transfer. Qi's concept is to do the minimum to pull in the Linux kernel and start it, and to have no configuration. Everything that would otherwise bloat the bootloader is the domain of Linux that the bootloader starts. Bootloader == load then boot, everything else in the bootloader not necessary for those two is evil. If you try Qi you'll find it is considerably faster than our U-Boot. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjwy+UACgkQOjLpvpq7dMqjmwCgj+HX+lDw14F+EHjv1FJ4k+o/ 58QAnR4rzp7W64KzWP4WJ7oJj8wb7alr =kSc3 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko to shift to 2.6.27 kernel ?
On Sat, 11 Oct 2008 13:29:39 +0100, Andy Green [EMAIL PROTECTED] wrote: Hi - I spent a lot of time tracking upstream HEAD for several months, we do have development 2.6.27 kernel based on upstream release 2.6.27. Not everything works yet but it's basically there. If you're interested to visit the edge and know how to DFU stuff around with NOR to get yourself in and out of trouble, you can get a moredrivers kernel here http://people.openmoko.org/andy/uImage-moredrivers-andy-tracking_2ffb4cc483642df1.bin sources: http://git.openmoko.org/?p=kernel.git;a=shortlog;h=andy-tracking for daredevils this works with the U-Boot replacement Qi (image is ready for DFU into NAND bootloader) http://people.openmoko.org/andy/qi-andy_ab8665e9ac10a054.udfu sources: http://git.openmoko.org/?p=qi.git;a=summary Qi will boot from /boot/uImage.bin on ext2 first partition of SD Card if present, else fallback to NAND kernel. - -Andy Sign me up, baby! I live on the edge! :) Qi boots like a dream - no kernel messages scrolling by, just turns on backlight on a black screen for about 5 seconds (heartstopper of sorts the first time) then the graphical boot progress screen appears. I'd guesstimate that overall boot time was improved perhaps 15%. NOTE for other 'daredevils': Qi does NOT provide a boot menu. (at least not that I could find, not at this point) The usual NOR uBoot menu you use to flash your Neo (Aux first, power second, wait for menu) of course works fine, but if you try the usual procedure to fire up NAND uBoot (Power first, aux second, wait for menu) you get no response. (not even the 'backlighted black screen') The kernel wasn't so dreamy... On first flash a few trillion CRC errors seemed to scroll by, then it hung. Subsequent attempts: with Qi I get white screen for a half second, then backlighted black screen for a couple seconds, then off, with AUX red LED blinking about 4/sec. If I boot into NOR uBoot and select 'boot', I can see the screen as it load the kernel and starts it up. Then I get 17 lines on the screen, with AUX red LED again blinking ~4/sec: # init_resume_dependancy_list(head=c040e9fc) # init_resume_dependancy_list(head=c040eac8) # init_resume_dependancy_list(head=c040eb94) glamofb_update_lcd_controller spin_lock_irqsave glamofb_update_lcd_controller spin_unlock_irqrestore fbcon_event_notify action=5, data=c781faa8 glamofb_update_lcd_controller spin_lock_irqsave glamofb_update_lcd_controller spin_unlock_irqrestore glamo_mci glamo_mci.0: ** glamo_mci_reset glamo_mci glamo_mci.0: error after cmd: 0x8120 glamo_mci glamo_mci.0: error after cmd: 0x120 glamo_mci glamo_mci.0: error after cmd: 0x8120 glamo_mci glamo_mci.0: error after cmd: 0x120 lis302dl lis302dl.1: unknown who_am_i signature 0x00 lis302dl lis302dl.2: unknown who_am_i signature 0x00 kernel panic: not syncing: Attempted to kill init! (lis302dl are the accelerometers) One other interesting thing happened while I was flashing about: I committed the unutterably stupid error of flashing uBoot into the kernel space. In this broken state, the instant I restored power (remove/replace battery) the blue Power LED came on, blinked off for a fraction of a second every 10 secs or so. I've never seen this before - is it coming from Qi?? It was really instantaneous upon battery reinsertion, I didn't press power or anything. (I thought it sat in powered-down state at that point, guess I was mistaken) j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
