Just a note to say that I'm having the precise same problem described here:
http://lists.fedoraproject.org/pipermail/arm/2010-December/thread.html#786
'Mojibake' after the kernel is uncompressed. No tty settings seem to fix it[*].
The wiki links to the uImage-2.6.30-sheevaplug image all over, but it is definitely broken either inherently or just with the latest SheevaPlug hardware.
Rich.
[*] How on earth did someone decide it was a good idea for USB serial to suffer from all the same configuration problems as RS-232? The 1980s called ...
My guruplug shipped with 2.6.32, I don't think there is a lot of hardware differences between that and the sheeva.
You might try: http://www.plugcomputer.org/plugwiki/index.php/Re-building_the_kernel_and_U-...
I just rolled the kernel last night as I need CONFIG_KEYS=y to run/build AFS and they just did a pre-release of 1.6 and I wanted to test the build.
I don't recall exactly if it is in uboot, the kernel or a combination of the two.
Quoting "Richard W.M. Jones" rjones@redhat.com:
Just a note to say that I'm having the precise same problem described here:
http://lists.fedoraproject.org/pipermail/arm/2010-December/thread.html#786
'Mojibake' after the kernel is uncompressed. No tty settings seem to fix it[*].
The wiki links to the uImage-2.6.30-sheevaplug image all over, but it is definitely broken either inherently or just with the latest SheevaPlug hardware.
Rich.
[*] How on earth did someone decide it was a good idea for USB serial to suffer from all the same configuration problems as RS-232? The 1980s called ...
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On Sat, 2011-01-08 at 12:28 +0000, Richard W.M. Jones wrote:
Just a note to say that I'm having the precise same problem described here:
http://lists.fedoraproject.org/pipermail/arm/2010-December/thread.html#786
'Mojibake' after the kernel is uncompressed. No tty settings seem to fix it[*].
The wiki links to the uImage-2.6.30-sheevaplug image all over, but it is definitely broken either inherently or just with the latest SheevaPlug hardware.
We should probably update these wiki links to point to a common 'ARM Kernel' page, which we can then use as a trampoline to a currently-recommended kernel or a collection of kernels, and later change to point to an RPM-based kernel solution. Any takers for this bit of wiki gardening?
(Speaking of kernels, I'm going to get a couple students looking at doing RPM-based kernels for ARM this semester. Some things from primary archs won't apply, e.g., updating grub boot menus -- I think ARM with uBoot will probably need some ugly pieces like a hard link to the "current" kernel, at least to start. We also need to do an inventory to figure out the smallest number of kernels necessary to support common hardware).
-Chris
Chris Tyler píše v So 08. 01. 2011 v 12:20 -0500:
On Sat, 2011-01-08 at 12:28 +0000, Richard W.M. Jones wrote:
Just a note to say that I'm having the precise same problem described here:
http://lists.fedoraproject.org/pipermail/arm/2010-December/thread.html#786
'Mojibake' after the kernel is uncompressed. No tty settings seem to fix it[*].
The wiki links to the uImage-2.6.30-sheevaplug image all over, but it is definitely broken either inherently or just with the latest SheevaPlug hardware.
We should probably update these wiki links to point to a common 'ARM Kernel' page, which we can then use as a trampoline to a currently-recommended kernel or a collection of kernels, and later change to point to an RPM-based kernel solution. Any takers for this bit of wiki gardening?
(Speaking of kernels, I'm going to get a couple students looking at doing RPM-based kernels for ARM this semester. Some things from primary archs won't apply, e.g., updating grub boot menus -- I think ARM with uBoot will probably need some ugly pieces like a hard link to the "current" kernel, at least to start. We also need to do an inventory to figure out the smallest number of kernels necessary to support common hardware).
We have a student in Red Hat Brno who will work on RPM-based kernels as his bachelor thesis and it should include an improvement in grubby to use the flash-kernel utility (https://bugzilla.redhat.com/show_bug.cgi?id=548422) Debian is developing and using to actually flash the kernel to a supported range of devices. We think the kernel installation workflow could be very similar to the one used on x86.
Dan
On Sat, 2011-01-08 at 18:36 +0100, Dan Horák wrote:
Chris Tyler píše v So 08. 01. 2011 v 12:20 -0500:
On Sat, 2011-01-08 at 12:28 +0000, Richard W.M. Jones wrote:
Just a note to say that I'm having the precise same problem described here:
http://lists.fedoraproject.org/pipermail/arm/2010-December/thread.html#786
'Mojibake' after the kernel is uncompressed. No tty settings seem to fix it[*].
The wiki links to the uImage-2.6.30-sheevaplug image all over, but it is definitely broken either inherently or just with the latest SheevaPlug hardware.
We should probably update these wiki links to point to a common 'ARM Kernel' page, which we can then use as a trampoline to a currently-recommended kernel or a collection of kernels, and later change to point to an RPM-based kernel solution. Any takers for this bit of wiki gardening?
(Speaking of kernels, I'm going to get a couple students looking at doing RPM-based kernels for ARM this semester. Some things from primary archs won't apply, e.g., updating grub boot menus -- I think ARM with uBoot will probably need some ugly pieces like a hard link to the "current" kernel, at least to start. We also need to do an inventory to figure out the smallest number of kernels necessary to support common hardware).
We have a student in Red Hat Brno who will work on RPM-based kernels as his bachelor thesis and it should include an improvement in grubby to use the flash-kernel utility (https://bugzilla.redhat.com/show_bug.cgi?id=548422) Debian is developing and using to actually flash the kernel to a supported range of devices. We think the kernel installation workflow could be very similar to the one used on x86.
Cool! Any forward movement on that one? The review is a year old.
We need to be sure that we can ultimately boot either from NAND or a filesystem.
-Chris
Chris Tyler píše v So 08. 01. 2011 v 12:48 -0500:
On Sat, 2011-01-08 at 18:36 +0100, Dan Horák wrote:
Chris Tyler píše v So 08. 01. 2011 v 12:20 -0500:
On Sat, 2011-01-08 at 12:28 +0000, Richard W.M. Jones wrote:
Just a note to say that I'm having the precise same problem described here:
http://lists.fedoraproject.org/pipermail/arm/2010-December/thread.html#786
'Mojibake' after the kernel is uncompressed. No tty settings seem to fix it[*].
The wiki links to the uImage-2.6.30-sheevaplug image all over, but it is definitely broken either inherently or just with the latest SheevaPlug hardware.
We should probably update these wiki links to point to a common 'ARM Kernel' page, which we can then use as a trampoline to a currently-recommended kernel or a collection of kernels, and later change to point to an RPM-based kernel solution. Any takers for this bit of wiki gardening?
(Speaking of kernels, I'm going to get a couple students looking at doing RPM-based kernels for ARM this semester. Some things from primary archs won't apply, e.g., updating grub boot menus -- I think ARM with uBoot will probably need some ugly pieces like a hard link to the "current" kernel, at least to start. We also need to do an inventory to figure out the smallest number of kernels necessary to support common hardware).
We have a student in Red Hat Brno who will work on RPM-based kernels as his bachelor thesis and it should include an improvement in grubby to use the flash-kernel utility (https://bugzilla.redhat.com/show_bug.cgi?id=548422) Debian is developing and using to actually flash the kernel to a supported range of devices. We think the kernel installation workflow could be very similar to the one used on x86.
Cool! Any forward movement on that one? The review is a year old.
Peter told me he still has some duties in school for the next 1 or 2 weeks and then he will join us here again.
Dan
On 01/08/2011 05:36 PM, Dan Horák wrote:
Chris Tyler píše v So 08. 01. 2011 v 12:20 -0500:
On Sat, 2011-01-08 at 12:28 +0000, Richard W.M. Jones wrote:
Just a note to say that I'm having the precise same problem described here:
http://lists.fedoraproject.org/pipermail/arm/2010-December/thread.html#786
'Mojibake' after the kernel is uncompressed. No tty settings seem to fix it[*].
The wiki links to the uImage-2.6.30-sheevaplug image all over, but it is definitely broken either inherently or just with the latest SheevaPlug hardware.
We should probably update these wiki links to point to a common 'ARM Kernel' page, which we can then use as a trampoline to a currently-recommended kernel or a collection of kernels, and later change to point to an RPM-based kernel solution. Any takers for this bit of wiki gardening?
(Speaking of kernels, I'm going to get a couple students looking at doing RPM-based kernels for ARM this semester. Some things from primary archs won't apply, e.g., updating grub boot menus -- I think ARM with uBoot will probably need some ugly pieces like a hard link to the "current" kernel, at least to start. We also need to do an inventory to figure out the smallest number of kernels necessary to support common hardware).
We have a student in Red Hat Brno who will work on RPM-based kernels as his bachelor thesis and it should include an improvement in grubby to use the flash-kernel utility (https://bugzilla.redhat.com/show_bug.cgi?id=548422) Debian is developing and using to actually flash the kernel to a supported range of devices. We think the kernel installation workflow could be very similar to the one used on x86.
So what exactly do you do when the flashed kernel turns out to be broken and doesn't boot?
It also sounds ill advised to be burning things that are supposed to get updated relatively frequently (kernels DO get updated) to non-replaceable flash. Keeping the kernel with the rest of the distro on the easily removable/replaceable flash media is probably a more reasonable long-term solution. Using built in flash is fine for embedded appliances that only see 1-2 updates/year, but not necessarily for bleeding edge desktop distributions like Fedora.
Gordan
On Sat, 2011-01-08 at 19:05 +0000, Gordan Bobic wrote:
It also sounds ill advised to be burning things that are supposed to get updated relatively frequently (kernels DO get updated) to non-replaceable flash. Keeping the kernel with the rest of the distro on the easily removable/replaceable flash media is probably a more reasonable long-term solution. Using built in flash is fine for embedded appliances that only see 1-2 updates/year, but not necessarily for bleeding edge desktop distributions like Fedora.
Well, there's a huge difference between putting / on NAND and the kernel on NAND. Assuming just a 10,000-write-cycle durability, updating the kernel every 3-4 days (100x/year) gives you 100 years of life.
-Chris
On 01/08/2011 07:33 PM, Chris Tyler wrote:
On Sat, 2011-01-08 at 19:05 +0000, Gordan Bobic wrote:
It also sounds ill advised to be burning things that are supposed to get updated relatively frequently (kernels DO get updated) to non-replaceable flash. Keeping the kernel with the rest of the distro on the easily removable/replaceable flash media is probably a more reasonable long-term solution. Using built in flash is fine for embedded appliances that only see 1-2 updates/year, but not necessarily for bleeding edge desktop distributions like Fedora.
Well, there's a huge difference between putting / on NAND and the kernel on NAND. Assuming just a 10,000-write-cycle durability, updating the kernel every 3-4 days (100x/year) gives you 100 years of life.
Assuming you actually get your 10,000 erase cycles out of it - and that is a big assumotion. I have seen a lot of consumer grade MLC flash fail after a few dozen erases (USB sticks, CF cards). In general, if it survives the first 20 or so I find it does last fine, but assuming that you will get 10,000 erase cycles out of it seems like an unnecessary risk when you will actually end up bricking the device permanently. An SD card, OTOH, is easy to replace.
Advantages of keeping it on the same media as the rest of the distro include but are not limited to:
1) It makes the kernel image easily available and accessible without any additional magic.
2) It is what anybody who has used Fedora on a different distro will intuitively expect.
3) It makes sense to keep the kernel in the same place as /lib/modules, as the chances are that you won't get very far if they don't match, especially on a distro like Fedora where just about everything is a module.
What are the percieved advantages of having the kernel image on built in nand? The only advantage is for devices that for some reason aren't supported by u-boot or another similar boot loader. AC100 is one such device, but u-boot support is being worked on.
Gordan
On 01/08/11 19:48, Somebody in the thread at some point said:
On 01/08/2011 07:33 PM, Chris Tyler wrote:
On Sat, 2011-01-08 at 19:05 +0000, Gordan Bobic wrote:
It also sounds ill advised to be burning things that are supposed to get updated relatively frequently (kernels DO get updated) to non-replaceable flash. Keeping the kernel with the rest of the distro on the easily removable/replaceable flash media is probably a more reasonable long-term solution. Using built in flash is fine for embedded appliances that only see 1-2 updates/year, but not necessarily for bleeding edge desktop distributions like Fedora.
Well, there's a huge difference between putting / on NAND and the kernel on NAND. Assuming just a 10,000-write-cycle durability, updating the kernel every 3-4 days (100x/year) gives you 100 years of life.
Assuming you actually get your 10,000 erase cycles out of it - and that is a big assumotion. I have seen a lot of consumer grade MLC flash fail after a few dozen erases (USB sticks, CF cards). In general, if it
Actually with USB Sticks and CF cards you have no idea what you saw "fail", since you are not talking to the flash directly, but through a controller handling ECC and wear levelling.
If in fact an erase sector going bad is the problem it should be swapped out by the controller with a spare sector logically mapped in place of it.
In the typical emebedded Linux case with raw NAND people are using jffs2 or yaffs to take care of that, hiding individual sectors on the raw nand from the filesystem.
Raw NAND is very ugly to work with, but with ECC and bad block lists and remapping by the time Linux gets to see it as a block device it is fine for updating the kernel how you like... otherwise just running the rootfs would be so fragile it would all turn to crap in minutes and my android phone with its many updates would be impractical ^^
There is a variety of ways of storing the kernel in embedded systems though, not always in /boot on the same filesystem as /.
For example, I have done it myself with at least
- stick it in RAW NAND at a magic offset after the bootloader - stick it in Serial NOR flash at a magic offset after the bootloader - stick it on its own VFAT partition on sd card - stick it on the rootfs partition on sd card
Also, it may not make sense to use an initrd in many cases, and if you do use it you also have the problem of what to do with it to store it accessibly to the bootloader.
Maybe a plan is just have the kernel package stick it in /boot as usual, and as part of its %post look for and if it exists run a script like "local-kernel-update.sh" or whatever. It can copy the newly installed kernel file down /boot using whatever means are appropriate for that particular board.
One big thing working in our favour is that Linux usually has standardized access to all the storage assets by mtd, usually partitioned up nicely if the kernel is just stuck in somewhere raw.
-Andy
On 01/09/2011 11:18 AM, Andy Green wrote:
On 01/08/11 19:48, Somebody in the thread at some point said:
On 01/08/2011 07:33 PM, Chris Tyler wrote:
On Sat, 2011-01-08 at 19:05 +0000, Gordan Bobic wrote:
It also sounds ill advised to be burning things that are supposed to get updated relatively frequently (kernels DO get updated) to non-replaceable flash. Keeping the kernel with the rest of the distro on the easily removable/replaceable flash media is probably a more reasonable long-term solution. Using built in flash is fine for embedded appliances that only see 1-2 updates/year, but not necessarily for bleeding edge desktop distributions like Fedora.
Well, there's a huge difference between putting / on NAND and the kernel on NAND. Assuming just a 10,000-write-cycle durability, updating the kernel every 3-4 days (100x/year) gives you 100 years of life.
Assuming you actually get your 10,000 erase cycles out of it - and that is a big assumotion. I have seen a lot of consumer grade MLC flash fail after a few dozen erases (USB sticks, CF cards). In general, if it
Actually with USB Sticks and CF cards you have no idea what you saw "fail", since you are not talking to the flash directly, but through a controller handling ECC and wear levelling.
Sure, so the bad sector might actually move around, which makes it harder to detect. I have, however, seen an issue where some sectors simply will not accept further writes - the data always remains the same.
If in fact an erase sector going bad is the problem it should be swapped out by the controller with a spare sector logically mapped in place of it.
Most cheap CF/SD cards and USB sticks don't actually come with any spare sectors.
In the typical emebedded Linux case with raw NAND people are using jffs2 or yaffs to take care of that, hiding individual sectors on the raw nand from the filesystem.
Except that flashing a kernel image to raw NAND won't be on top of yaffs.
Raw NAND is very ugly to work with, but with ECC and bad block lists and remapping by the time Linux gets to see it as a block device it is fine for updating the kernel how you like... otherwise just running the rootfs would be so fragile it would all turn to crap in minutes and my android phone with its many updates would be impractical ^^
Sure, but in that intensive an environment it'd be picked up well within the warranty period. :)
And as I said, I don't think the discussion here was about having a kernel on a file system but on the raw NAND.
There is a variety of ways of storing the kernel in embedded systems though, not always in /boot on the same filesystem as /.
For example, I have done it myself with at least
- stick it in RAW NAND at a magic offset after the bootloader
- stick it in Serial NOR flash at a magic offset after the bootloader
- stick it on its own VFAT partition on sd card
- stick it on the rootfs partition on sd card
Sure - I always use a seaprate /boot partition, especially on flash media, because of the block alignment issues and bootloader issues.
1) The first partition loses 16KB, so everything after that is misaligned if you are trying to make thing optimal for erase block sizes
16KB (and no consumer grade device I've heard of uses erase block
sizes that small). Typically I align things to 512KB (mkfs.ext[234] -b 4096 -E stripe-width=128), except where the erase block size is known (IIRC Intel disks use 128KB erase blocks).
Also, it may not make sense to use an initrd in many cases, and if you do use it you also have the problem of what to do with it to store it accessibly to the bootloader.
I don't that's more of a problem than with the kernel itself. Is it?
Maybe a plan is just have the kernel package stick it in /boot as usual, and as part of its %post look for and if it exists run a script like "local-kernel-update.sh" or whatever. It can copy the newly installed kernel file down /boot using whatever means are appropriate for that particular board.
Personally I think just putting the kernel, initrd and boot.scr (for uboot) in /boot and having /boot on a separate partition is the way forward. The majority of ARM devices in use today seem to either be already well supported by uboot (Sheeva/Guru Plugs, Egika Genesi MX), or at least have rudimentary support that is being further worked on (Toshiba AC100). Can anyone think of any ARMv5 or later devices that have no uboot support and are unlikely to have uboot support in the future that would be plausible candidates for running Fedora on?
Gordan
On 01/09/11 12:23, Somebody in the thread at some point said:
Assuming you actually get your 10,000 erase cycles out of it - and that is a big assumotion. I have seen a lot of consumer grade MLC flash fail after a few dozen erases (USB sticks, CF cards). In general, if it
Actually with USB Sticks and CF cards you have no idea what you saw "fail", since you are not talking to the flash directly, but through a controller handling ECC and wear levelling.
Sure, so the bad sector might actually move around, which makes it harder to detect. I have, however, seen an issue where some sectors simply will not accept further writes - the data always remains the same.
No, if the bad sector is found (by erase failure, or uncorrectable ecc) then these schemes put it out of circulation permanently, google "nand BBT" to learn more.
If in fact an erase sector going bad is the problem it should be swapped out by the controller with a spare sector logically mapped in place of it.
Most cheap CF/SD cards and USB sticks don't actually come with any spare sectors.
And you know that to state it as a fact because...?
In the typical emebedded Linux case with raw NAND people are using jffs2 or yaffs to take care of that, hiding individual sectors on the raw nand from the filesystem.
Except that flashing a kernel image to raw NAND won't be on top of yaffs.
It can perfectly well be on top of VFAT, ext2, or jffs2 in the U-Boot case though, which is much more common than yaffs outside of Android, in which case it is not relevant for Fedora.
And in any event, as was done at Openmoko where I was kernel maintainer for over a year, nothing stops the bootloader particpating in the same EEC and BBT schemes are the mtd layer in Linux when pulling from raw NAND.
Raw NAND is very ugly to work with, but with ECC and bad block lists and remapping by the time Linux gets to see it as a block device it is fine for updating the kernel how you like... otherwise just running the rootfs would be so fragile it would all turn to crap in minutes and my android phone with its many updates would be impractical ^^
Sure, but in that intensive an environment it'd be picked up well within the warranty period. :)
In case it wasn't clear, I am saying we can indeed bank on 10,000 writes to a sector where that is what the datasheet promises.
And as I said, I don't think the discussion here was about having a kernel on a file system but on the raw NAND.
The bit of the discussion is about how to have fedora arm kernels deal with the wide variety of boards out there. Kernels in raw NAND is just one scheme that is used there are plenty of others -->
There is a variety of ways of storing the kernel in embedded systems though, not always in /boot on the same filesystem as /.
For example, I have done it myself with at least
- stick it in RAW NAND at a magic offset after the bootloader
- stick it in Serial NOR flash at a magic offset after the bootloader
- stick it on its own VFAT partition on sd card
- stick it on the rootfs partition on sd card
Sure - I always use a seaprate /boot partition, especially on flash media, because of the block alignment issues and bootloader issues.
Other people don't; sometimes choices are forced by the hardware.
Also, it may not make sense to use an initrd in many cases, and if you do use it you also have the problem of what to do with it to store it accessibly to the bootloader.
I don't that's more of a problem than with the kernel itself. Is it?
Sorry your question can't be understood.
The initrd is brought in by the bootloader and handed to the kernel already in-memory. It means that in addition to needing to be flexible with where and how to copy the kernel image itself it assumes that everything has the storage and wants to use an initrd. It'd be better if the initrd was not mandatory like it is in normal Fedora.
There's a good reason to not use Fedora initrd + init on slower devices, bootup time can be cut to a few seconds with a custom boot script instead. So it'd be good if the initrd was optional in the sense it's not required if you're not going to boot via the Fedora path.
Maybe a plan is just have the kernel package stick it in /boot as usual, and as part of its %post look for and if it exists run a script like "local-kernel-update.sh" or whatever. It can copy the newly installed kernel file down /boot using whatever means are appropriate for that particular board.
Personally I think just putting the kernel, initrd and boot.scr (for uboot) in /boot and having /boot on a separate partition is the way
How does that even fit the case where the kernel is written to raw NAND that you were preoccupied about at the start of this mail?
Most of the stuff I use does not use U-Boot.
What'd solve this really nicely is a /etc/kernel-update.d/ which has a bunch of scripts that try to match based on /proc/cpuinfo. For example on the board I am working on right now, it says in there
[root@ivmon ~]# cat /proc/cpuinfo Processor : ARM926EJ-S rev 4 (v5l) BogoMIPS : 103.42 Features : swp half thumb fastmult vfp edsp java CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part : 0x926 CPU revision : 4
Hardware : Embedded Artists LPC3250 OEM board with the LPC3250 Microcontroller Revision : 0001 Serial : 0000000000000000
Based on the board ID and its revision, that script can take care of "doing the right thing" to update the kernel from the one in /boot. The arm kernel packages can take care of packaging most of these scripts but local ones can be kept or vendors can package others.
-Andy
On Sun, Jan 9, 2011 at 2:30 PM, Andy Green andy@warmcat.com wrote:
On 01/09/11 12:23, Somebody in the thread at some point said:
Assuming you actually get your 10,000 erase cycles out of it - and that is a big assumotion. I have seen a lot of consumer grade MLC flash fail after a few dozen erases (USB sticks, CF cards). In general, if it
Actually with USB Sticks and CF cards you have no idea what you saw "fail", since you are not talking to the flash directly, but through a controller handling ECC and wear levelling.
Sure, so the bad sector might actually move around, which makes it harder to detect. I have, however, seen an issue where some sectors simply will not accept further writes - the data always remains the same.
No, if the bad sector is found (by erase failure, or uncorrectable ecc) then these schemes put it out of circulation permanently, google "nand BBT" to learn more.
If in fact an erase sector going bad is the problem it should be swapped out by the controller with a spare sector logically mapped in place of it.
Most cheap CF/SD cards and USB sticks don't actually come with any spare sectors.
And you know that to state it as a fact because...?
In the typical emebedded Linux case with raw NAND people are using jffs2 or yaffs to take care of that, hiding individual sectors on the raw nand from the filesystem.
Except that flashing a kernel image to raw NAND won't be on top of yaffs.
It can perfectly well be on top of VFAT, ext2, or jffs2 in the U-Boot case though, which is much more common than yaffs outside of Android, in which case it is not relevant for Fedora.
And in any event, as was done at Openmoko where I was kernel maintainer for over a year, nothing stops the bootloader particpating in the same EEC and BBT schemes are the mtd layer in Linux when pulling from raw NAND.
Raw NAND is very ugly to work with, but with ECC and bad block lists and remapping by the time Linux gets to see it as a block device it is fine for updating the kernel how you like... otherwise just running the rootfs would be so fragile it would all turn to crap in minutes and my android phone with its many updates would be impractical ^^
Sure, but in that intensive an environment it'd be picked up well within the warranty period. :)
In case it wasn't clear, I am saying we can indeed bank on 10,000 writes to a sector where that is what the datasheet promises.
And as I said, I don't think the discussion here was about having a kernel on a file system but on the raw NAND.
The bit of the discussion is about how to have fedora arm kernels deal with the wide variety of boards out there. Kernels in raw NAND is just one scheme that is used there are plenty of others -->
There is a variety of ways of storing the kernel in embedded systems though, not always in /boot on the same filesystem as /.
For example, I have done it myself with at least
- stick it in RAW NAND at a magic offset after the bootloader
- stick it in Serial NOR flash at a magic offset after the bootloader
- stick it on its own VFAT partition on sd card
- stick it on the rootfs partition on sd card
Sure - I always use a seaprate /boot partition, especially on flash media, because of the block alignment issues and bootloader issues.
Other people don't; sometimes choices are forced by the hardware.
Also, it may not make sense to use an initrd in many cases, and if you do use it you also have the problem of what to do with it to store it accessibly to the bootloader.
I don't that's more of a problem than with the kernel itself. Is it?
Sorry your question can't be understood.
The initrd is brought in by the bootloader and handed to the kernel already in-memory. It means that in addition to needing to be flexible with where and how to copy the kernel image itself it assumes that everything has the storage and wants to use an initrd. It'd be better if the initrd was not mandatory like it is in normal Fedora.
There's a good reason to not use Fedora initrd + init on slower devices, bootup time can be cut to a few seconds with a custom boot script instead. So it'd be good if the initrd was optional in the sense it's not required if you're not going to boot via the Fedora path.
Maybe a plan is just have the kernel package stick it in /boot as usual, and as part of its %post look for and if it exists run a script like "local-kernel-update.sh" or whatever. It can copy the newly installed kernel file down /boot using whatever means are appropriate for that particular board.
Personally I think just putting the kernel, initrd and boot.scr (for uboot) in /boot and having /boot on a separate partition is the way
How does that even fit the case where the kernel is written to raw NAND that you were preoccupied about at the start of this mail?
Most of the stuff I use does not use U-Boot.
What'd solve this really nicely is a /etc/kernel-update.d/ which has a bunch of scripts that try to match based on /proc/cpuinfo. For example on the board I am working on right now, it says in there
I believe the utils that the x86 kernels use already have the ability to do something like that so it shouldn't be too hard to extend those utils to be able to update particular files based on arch/machine like OFW (XO-1.75 will be arm but with openfirmware for eg), uboot, uEFI etc.
Peter
On 01/09/11 16:07, Somebody in the thread at some point said:
What'd solve this really nicely is a /etc/kernel-update.d/ which has a bunch of scripts that try to match based on /proc/cpuinfo. For example on the board I am working on right now, it says in there
I believe the utils that the x86 kernels use already have the ability to do something like that so it shouldn't be too hard to extend those utils to be able to update particular files based on arch/machine like OFW (XO-1.75 will be arm but with openfirmware for eg), uboot, uEFI etc.
Sounds cool. Hopefully one way or another whatever storage or filesystem is used for the kernel by the bootloader can always be made reachable by a Linux mtd or other block device and it'll work out cleanly scriptable without losing flexibility or filling up the kernel spec file with specifics.
-Andy
"Gordan Bobic" gordan@bobich.net wrote:
On 01/09/2011 11:18 AM, Andy Green wrote:
On 01/08/11 19:48, Somebody in the thread at some point said:
On 01/08/2011 07:33 PM, Chris Tyler wrote:
On Sat, 2011-01-08 at 19:05 +0000, Gordan Bobic wrote:
It also sounds ill advised to be burning things that are supposed
to
get updated relatively frequently (kernels DO get updated) to non-replaceable flash. Keeping the kernel with the rest of the distro on the easily removable/replaceable flash media is probably a more reasonable long-term solution. Using built in flash is fine for embedded appliances that only see 1-2 updates/year, but not necessarily for bleeding edge desktop distributions like Fedora.
Well, there's a huge difference between putting / on NAND and the
kernel
on NAND. Assuming just a 10,000-write-cycle durability, updating
the
kernel every 3-4 days (100x/year) gives you 100 years of life.
Assuming you actually get your 10,000 erase cycles out of it - and
that
is a big assumotion. I have seen a lot of consumer grade MLC flash
fail
after a few dozen erases (USB sticks, CF cards). In general, if it
Actually with USB Sticks and CF cards you have no idea what you saw "fail", since you are not talking to the flash directly, but through
a
controller handling ECC and wear levelling.
Sure, so the bad sector might actually move around, which makes it harder to detect. I have, however, seen an issue where some sectors simply will not accept further writes - the data always remains the same.
If in fact an erase sector going bad is the problem it should be
swapped
out by the controller with a spare sector logically mapped in place
of it.
Most cheap CF/SD cards and USB sticks don't actually come with any spare sectors.
In the typical emebedded Linux case with raw NAND people are using
jffs2
or yaffs to take care of that, hiding individual sectors on the raw
nand
from the filesystem.
Except that flashing a kernel image to raw NAND won't be on top of yaffs.
Raw NAND is very ugly to work with, but with ECC and bad block lists
and
remapping by the time Linux gets to see it as a block device it is
fine
for updating the kernel how you like... otherwise just running the rootfs would be so fragile it would all turn to crap in minutes and
my
android phone with its many updates would be impractical ^^
Sure, but in that intensive an environment it'd be picked up well within the warranty period. :)
And as I said, I don't think the discussion here was about having a kernel on a file system but on the raw NAND.
There is a variety of ways of storing the kernel in embedded systems though, not always in /boot on the same filesystem as /.
For example, I have done it myself with at least
- stick it in RAW NAND at a magic offset after the bootloader
- stick it in Serial NOR flash at a magic offset after the bootloader
- stick it on its own VFAT partition on sd card
- stick it on the rootfs partition on sd card
Sure - I always use a seaprate /boot partition, especially on flash media, because of the block alignment issues and bootloader issues.
- The first partition loses 16KB, so everything after that is
misaligned if you are trying to make thing optimal for erase block sizes
16KB (and no consumer grade device I've heard of uses erase block
sizes that small). Typically I align things to 512KB (mkfs.ext[234] -b 4096 -E stripe-width=128), except where the erase block size is known (IIRC Intel disks use 128KB erase blocks).
Also, it may not make sense to use an initrd in many cases, and if
you
do use it you also have the problem of what to do with it to store it accessibly to the bootloader.
I don't that's more of a problem than with the kernel itself. Is it?
Maybe a plan is just have the kernel package stick it in /boot as
usual,
and as part of its %post look for and if it exists run a script like "local-kernel-update.sh" or whatever. It can copy the newly installed kernel file down /boot using whatever means are appropriate for that particular board.
Personally I think just putting the kernel, initrd and boot.scr (for uboot) in /boot and having /boot on a separate partition is the way forward. The majority of ARM devices in use today seem to either be already well supported by uboot (Sheeva/Guru Plugs, Egika Genesi MX), or at least have rudimentary support that is being further worked on (Toshiba AC100). Can anyone think of any ARMv5 or later devices that have no uboot support and are unlikely to have uboot support in the future that would be plausible candidates for running Fedora on?
Yes the olpc xo it will be using openfirmware not uboot and will probably ship more units than those you mentioned
Gordan Bobic píše v So 08. 01. 2011 v 19:05 +0000:
On 01/08/2011 05:36 PM, Dan Horák wrote:
Chris Tyler píše v So 08. 01. 2011 v 12:20 -0500:
On Sat, 2011-01-08 at 12:28 +0000, Richard W.M. Jones wrote:
Just a note to say that I'm having the precise same problem described here:
http://lists.fedoraproject.org/pipermail/arm/2010-December/thread.html#786
'Mojibake' after the kernel is uncompressed. No tty settings seem to fix it[*].
The wiki links to the uImage-2.6.30-sheevaplug image all over, but it is definitely broken either inherently or just with the latest SheevaPlug hardware.
We should probably update these wiki links to point to a common 'ARM Kernel' page, which we can then use as a trampoline to a currently-recommended kernel or a collection of kernels, and later change to point to an RPM-based kernel solution. Any takers for this bit of wiki gardening?
(Speaking of kernels, I'm going to get a couple students looking at doing RPM-based kernels for ARM this semester. Some things from primary archs won't apply, e.g., updating grub boot menus -- I think ARM with uBoot will probably need some ugly pieces like a hard link to the "current" kernel, at least to start. We also need to do an inventory to figure out the smallest number of kernels necessary to support common hardware).
We have a student in Red Hat Brno who will work on RPM-based kernels as his bachelor thesis and it should include an improvement in grubby to use the flash-kernel utility (https://bugzilla.redhat.com/show_bug.cgi?id=548422) Debian is developing and using to actually flash the kernel to a supported range of devices. We think the kernel installation workflow could be very similar to the one used on x86.
So what exactly do you do when the flashed kernel turns out to be broken and doesn't boot?
The commercial devices that are our target (like NAS made by QNAP) have a documented recovery process without the need for a serial console. And when someone wants to replace the original image with Fedora (or Debian), then he should be aware what is he doing.
Dan
On 01/08/2011 05:20 PM, Chris Tyler wrote:
On Sat, 2011-01-08 at 12:28 +0000, Richard W.M. Jones wrote:
Just a note to say that I'm having the precise same problem described here:
http://lists.fedoraproject.org/pipermail/arm/2010-December/thread.html#786
'Mojibake' after the kernel is uncompressed. No tty settings seem to fix it[*].
The wiki links to the uImage-2.6.30-sheevaplug image all over, but it is definitely broken either inherently or just with the latest SheevaPlug hardware.
We should probably update these wiki links to point to a common 'ARM Kernel' page, which we can then use as a trampoline to a currently-recommended kernel or a collection of kernels, and later change to point to an RPM-based kernel solution. Any takers for this bit of wiki gardening?
I do seem to remember running into this issue of the 2.6.30 kernel linked on the wiki.
(Speaking of kernels, I'm going to get a couple students looking at doing RPM-based kernels for ARM this semester. Some things from primary archs won't apply, e.g., updating grub boot menus -- I think ARM with uBoot will probably need some ugly pieces like a hard link to the "current" kernel, at least to start.
I'd be careful with that. U-boot has a very tentative understanding of the ext2 file system. For example, I know for a fact that if you use block alignment mkfs parameters (-E stride=[blocks],stripe-width=[blocks]) it ceases to be able to handle it.
I'm not sure if that includes any weirdness around hard-links. A straight copy might be safer.
We also need to do an inventory to figure out the smallest number of kernels necessary to support common hardware).
If you're interested, I can provide you with a 2.6.36.2 .config I use that is designed to be used with minimal changes on the Sheeva Plug and the Toshiba AC100. I'm hoping I can get away with the only build change being the target hardware (Tegra 2 vs. Feroceon).
Another thing worth mentioning that I've found is that the latest u-boot is a bit broken when handling high-speed MMC cards. With a normal no-name card it was fine, but with a high-speed SanDisk Class 10, it fails to initialize properly the first time, and the kernel load fails. The bodge solution I've applied is to run mmc_init twice - that makes it work, but it is probably something that needs fixing in uboot sooner rather than later.
Gordan
Chris Tyler chris@tylers.info writes:
On Sat, 2011-01-08 at 12:28 +0000, Richard W.M. Jones wrote:
Just a note to say that I'm having the precise same problem described here:
http://lists.fedoraproject.org/pipermail/arm/2010-December/thread.html#786
'Mojibake' after the kernel is uncompressed. No tty settings seem to fix it[*].
The wiki links to the uImage-2.6.30-sheevaplug image all over, but it is definitely broken either inherently or just with the latest SheevaPlug hardware.
We should probably update these wiki links to point to a common 'ARM Kernel' page, which we can then use as a trampoline to a currently-recommended kernel or a collection of kernels, and later change to point to an RPM-based kernel solution. Any takers for this bit of wiki gardening?
FWIW, I've been using http://sheeva.with-linux.com/sheeva/ for my Sheeva kernels.
(Speaking of kernels, I'm going to get a couple students looking at doing RPM-based kernels for ARM this semester. Some things from primary archs won't apply, e.g., updating grub boot menus -- I think ARM with uBoot will probably need some ugly pieces like a hard link to the "current" kernel, at least to start. We also need to do an inventory to figure out the smallest number of kernels necessary to support common hardware).
-Chris
-derek
On Mon, Jan 10, 2011 at 09:36:47AM -0500, Derek Atkins wrote:
FWIW, I've been using http://sheeva.with-linux.com/sheeva/ for my Sheeva kernels.
I used these as well. They appear to work perfectly.
Rich.
-
Andy Green -
Chris Tyler -
Dan Horák -
Dennis Gilmore -
Derek Atkins -
Gordan Bobic -
omalleys＠msu.edu -
Peter Robinson -
Richard W.M. Jones