From: Jamie Lokier <jamie@shareable.org>
To: Josh Boyer <jwboyer@gmail.com>
Cc: u-boot-users@lists.sourceforge.net,
Bernard Blackham <bernard@largestprime.net>,
linux-mtd@lists.infradead.org
Subject: Re: [U-Boot-Users] ubi and u-boot
Date: Sun, 20 Apr 2008 17:04:14 +0100 [thread overview]
Message-ID: <20080420160413.GC14268@shareable.org> (raw)
In-Reply-To: <1208546341.6654.8.camel@vader.jdub.homelinux.org>
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
next prev parent reply other threads:[~2008-04-20 16:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-18 14:21 ubi and u-boot Bernard Blackham
2008-04-18 16:40 ` [U-Boot-Users] " Josh Boyer
2008-04-18 16:59 ` Jamie Lokier
2008-04-18 17:49 ` Bernard Blackham
2008-04-20 22:22 ` Wolfgang Denk
2008-04-21 12:05 ` Artem Bityutskiy
2008-04-21 13:36 ` Ricard Wanderlof
2008-04-21 13:44 ` Josh Boyer
2008-04-21 13:50 ` Artem Bityutskiy
2008-04-21 14:01 ` Artem Bityutskiy
2008-04-22 11:44 ` Ricard Wanderlof
2008-04-22 12:30 ` Jamie Lokier
2008-04-18 19:19 ` Josh Boyer
2008-04-20 16:04 ` Jamie Lokier [this message]
2008-04-20 16:44 ` Josh Boyer
2008-04-20 17:29 ` Jamie Lokier
2008-04-21 1:05 ` Hamish Moffatt
2008-04-19 9:25 ` Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080420160413.GC14268@shareable.org \
--to=jamie@shareable.org \
--cc=bernard@largestprime.net \
--cc=jwboyer@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=u-boot-users@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox