[U-Boot] U-Boot and UBI
Kyungmin Park
kmpark at infradead.org
Wed Aug 13 01:34:12 CEST 2008
Hi,
On Tue, Aug 12, 2008 at 8:11 PM, Stefan Roese <sr at denx.de> wrote:
> On Tuesday 12 August 2008, Kyungmin Park wrote:
>> > On Monday 11 August 2008, Kyungmin Park wrote:
>> >> Actually the Samsung implemented the UBI support on U-boot already and
>> >> has used it internally. The big difference is the code base. It's
>> >> based on kernel UBI code. Yes it's not fit well to u-boot ecosystem so
>> >> it created the ubi wrapper for u-boot.
>> >
>> > And how does NAND/OneNAND booting with UBI support fit into this? I
>> > assume that you have some size restrictions for the IPL/SPL on your
>> > platforms as well.
>>
>> It's not yet covered. it's TODO
>
> I see.
>
Yes, we should make a u-boot within one block size since flash only
guarantees the first one block as bad block free. e.g., exactly
(128KiB - 2KiB) size if OneNAND case.
For this, we need to code or size optimization.
If this is solved, we can use flash as bad block free device with UBI.
Also there are some issues related with ubi partitioning.
It's just rough ideas. For make a system as reasonable it creates two
UBI devices, one for boot-loader and another for kernel. If we make
only one UBI device, we should read whole flash blocks to read kernel.
but it's not reasonable.
1. UBI image for bootloader.
boot params (rw), kernel(ro), [Optional] initrd (ro)
Even though it has r/w area, we regards it as static volume for
performance since boot params almost read only. I think If UBI has
only static volumes we can optimize it more. we don't need to mirror
layout volume. no wear leveling and so on. For this, of course, we
need special handling for boot params.
2. UBI image for kernel.
rootfs(ro/rw), datafs(rw), and others(??)
Feel free, you make it for your purposes.
Thank you,
Kyungmin Park
More information about the U-Boot
mailing list