[U-Boot-Users] ubi and u-boot
[apologies for the cross post]
Is anyone working on ubi/ubifs support in u-boot?
Kind regards, Bernard.
Josh Boyer wrote:
On Fri, 2008-04-18 at 22:21 +0800, Bernard Blackham wrote:
[apologies for the cross post] Is anyone working on ubi/ubifs support in u-boot?
I am not aware of anyone actively working on porting UBI to upstream U-Boot at this exact moment.
Is it even a good idea? The UBI (version 1 :-) initial scan is not fast for large flash, and if the bootloader does it too, that's twice as much time to boot.
However, if there was a protocol for bootloader to pass the scan results to the booted kernel, that would be very nice.
-- Jamie
Jamie Lokier wrote:
Josh Boyer wrote:
Is anyone working on ubi/ubifs support in u-boot?
I am not aware of anyone actively working on porting UBI to upstream U-Boot at this exact moment.
Is it even a good idea?
From what I've seen, UBI is the first solution with the potential for reliably booting from NAND flash - specifically, dealing with read-disturbance from adjacent blocks causing bit errors in critical boot blocks. This could save useful things like your kernel image (where it's rarely written, but it and blocks around it are read often enough to cause an annoying bitflip or two). The rewriting can be done once userspace boots, but having it in UBI to begin with makes this easier.
(Unless there's a much easier way to deal with read-disturbance that I've missed, in which case please lart me).
Wolfgang showed some interest briefly too.[1]
The UBI (version 1 :-) initial scan is not fast for large flash, and if the bootloader does it too, that's twice as much time to boot.
However, if there was a protocol for bootloader to pass the scan results to the booted kernel, that would be very nice.
If there's no compelling reasons not to, I'll try and find some time to work on ubi in uboot. I'm not expecting it to be easy though :)
Cheers, Bernard.
[1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/32602
In message 4808DF3B.2080702@largestprime.net you wrote:
Wolfgang showed some interest briefly too.[1]
I am definitely interested.
The UBI (version 1 :-) initial scan is not fast for large flash, and if the bootloader does it too, that's twice as much time to boot.
We have the same (at at least similar) problems when using JFFS2 file systems in U-Boot. Yet, being able to do this is quite useful in many situations.
However, if there was a protocol for bootloader to pass the scan results to the booted kernel, that would be very nice.
That would be of course a good thing to have :-)
If there's no compelling reasons not to, I'll try and find some time to work on ubi in uboot. I'm not expecting it to be easy though :)
Thanks in advance, and good luck!
Best regards,
Wolfgang Denk
On Fri, 2008-04-18 at 17:59 +0100, Jamie Lokier wrote:
Josh Boyer wrote:
On Fri, 2008-04-18 at 22:21 +0800, Bernard Blackham wrote:
[apologies for the cross post] Is anyone working on ubi/ubifs support in u-boot?
I am not aware of anyone actively working on porting UBI to upstream U-Boot at this exact moment.
Is it even a good idea? The UBI (version 1 :-) initial scan is not fast for large flash, and if the bootloader does it too, that's twice as much time to boot.
It's a good idea, yes. Particularly if you want to boot from NAND flash.
Can you define "large device"? It only scans the first 1 or 2 pages for each eraseblock to build up the volume tables. That really isn't that slow...
However, if there was a protocol for bootloader to pass the scan results to the booted kernel, that would be very nice.
Maybe. I was never fully convinced of that.
josh
Josh Boyer wrote:
Is it even a good idea? The UBI (version 1 :-) initial scan is not fast for large flash, and if the bootloader does it too, that's twice as much time to boot.
It's a good idea, yes. Particularly if you want to boot from NAND flash.
Can you define "large device"? It only scans the first 1 or 2 pages for each eraseblock to build up the volume tables. That really isn't that slow...
I was thinking this:
Hamish Moffatt wrote (Message-ID: 20080407073227.GA6317@cloud.net.au):
Sorry I should've said 512MiB perhaps: 512 megabytes. UBI attach time appears to be about 6 seconds.
If 6 seconds is as fast as it can be done, annoying but fair enough.
Adding _another_ 6 seconds to the boot time seems a lot to me.
The only ways I see to improve the speed in general are:
1. Partition the NAND into multiple independent UBIs, so the boot loader doesn't have the scan the whole chip, but that is obviously not so good for wear levelling. (It's probably alright, though, if it's like the /boot partition on a standard Linux distro - not updated very often.)
2. Change UBI's data structure so that the number of pages it needs to read is a sub-linear function of the number of erase blocks. I think this is what's meant by 'UBI 2'.
To remove the double scan:
However, if there was a protocol for bootloader to pass the scan results to the booted kernel, that would be very nice.
Maybe. I was never fully convinced of that.
I can understand the hesitation, but I think 6 seconds just to find the kernel - especially when doing a 'disk resume' - is quite a lot.
Note that I haven't tried UBI myself yet. I'm going on what has been written to the list so far, as quoted above.
-- Jamie
On Sun, 2008-04-20 at 17:04 +0100, Jamie Lokier wrote:
Josh Boyer wrote:
Is it even a good idea? The UBI (version 1 :-) initial scan is not fast for large flash, and if the bootloader does it too, that's twice as much time to boot.
It's a good idea, yes. Particularly if you want to boot from NAND flash.
Can you define "large device"? It only scans the first 1 or 2 pages for each eraseblock to build up the volume tables. That really isn't that slow...
I was thinking this:
Hamish Moffatt wrote (Message-ID: 20080407073227.GA6317@cloud.net.au):
Sorry I should've said 512MiB perhaps: 512 megabytes. UBI attach time appears to be about 6 seconds.
If 6 seconds is as fast as it can be done, annoying but fair enough.
You should read that thread a bit more carefully. The scan time is highly dependent upon the NAND driver beneath UBI. For example, a UBI scan/attach on a 1GiB device on OLPC was 2 seconds.
Adding _another_ 6 seconds to the boot time seems a lot to me.
You mean adding another "X amount of time depending on factors outside of UBI's control."
The only ways I see to improve the speed in general are:
Partition the NAND into multiple independent UBIs, so the boot loader doesn't have the scan the whole chip, but that is obviously not so good for wear levelling. (It's probably alright, though, if it's like the /boot partition on a standard Linux distro - not updated very often.)
Change UBI's data structure so that the number of pages it needs to read is a sub-linear function of the number of erase blocks. I think this is what's meant by 'UBI 2'.
To remove the double scan:
However, if there was a protocol for bootloader to pass the scan results to the booted kernel, that would be very nice.
Maybe. I was never fully convinced of that.
I can understand the hesitation, but I think 6 seconds just to find the kernel - especially when doing a 'disk resume' - is quite a lot.
You should really stop quoting this 6 second number.
Anyway, passing the scan results from a bootloader becomes very involved. You have to store it somewhere, probably preserving a section of DRAM, which isn't always easy.
Note that I haven't tried UBI myself yet. I'm going on what has been written to the list so far, as quoted above.
Maybe you should try it :).
josh
Josh Boyer wrote:
Hamish Moffatt wrote (Message-ID: 20080407073227.GA6317@cloud.net.au):
Sorry I should've said 512MiB perhaps: 512 megabytes. UBI attach time appears to be about 6 seconds.
If 6 seconds is as fast as it can be done, annoying but fair enough.
You should read that thread a bit more carefully. The scan time is highly dependent upon the NAND driver beneath UBI. For example, a UBI scan/attach on a 1GiB device on OLPC was 2 seconds.
Ah, I intended to quote the 2 seconds too but forgot, sorry. I think 2 seconds per gigabyte is a significant time, too, but not so much.
The followup suggested it was due to the speed of the chip, not so much the driver.
Adding _another_ 6 seconds to the boot time seems a lot to me.
You mean adding another "X amount of time depending on factors outside of UBI's control."
Well, yes, that would be a reason to consider whether doing it is a good idea :-)
I can understand the hesitation, but I think 6 seconds just to find the kernel - especially when doing a 'disk resume' - is quite a lot.
You should really stop quoting this 6 second number.
Let's call it 2 seconds per gigabyte, then.
Note that I haven't tried UBI myself yet. I'm going on what has been written to the list so far, as quoted above.
Maybe you should try it :).
I will when good looking figures are being quoted on the list ;-)
-- Jamie
On Sun, Apr 20, 2008 at 05:04:14PM +0100, Jamie Lokier wrote:
I was thinking this:
Hamish Moffatt wrote (Message-ID: 20080407073227.GA6317@cloud.net.au):
Sorry I should've said 512MiB perhaps: 512 megabytes. UBI attach time appears to be about 6 seconds.
If 6 seconds is as fast as it can be done, annoying but fair enough.
Adding _another_ 6 seconds to the boot time seems a lot to me.
Yes. I have a prototype system here booting a minimal system from NOR flash then booting the full system from NAND via kexec. I'm suffering my 6 seconds of UBI attach time twice each boot.
Six seconds does seem to be abnormal though - I don't have a hardware NAND controller so it's all software ECC, GPIO for chip selects etc. The performance is said to be much better with a hardware controller.
To remove the double scan:
However, if there was a protocol for bootloader to pass the scan results to the booted kernel, that would be very nice.
That would certainly help my case. Fortunately my device is usually always-on and therefore boot time is not critical, and we don't suspend/resume.
Hamish
participants (5)
-
Bernard Blackham -
Hamish Moffatt -
Jamie Lokier -
Josh Boyer -
Wolfgang Denk