[U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions

[Roy Spliet <r.spliet@ultimaker.com>]

Hello Hans,

Op 08-06-15 om 15:16 schreef Hans de Goede:
> Hi Roy,
>
> On 08-06-15 10:38, Roy Spliet wrote:
>> Hello Michal,
>>
>> Op 07-06-15 om 18:48 schreef Michal Suchanek:
>>> Hello,
>>>
>>> On 5 June 2015 at 13:52, Roy Spliet <r.spliet@ultimaker.com> wrote:
>>>> Based on the default layout of the android image used at least on 
>>>> Olimex Lime
>>>>
>>>> Signed-off-by: Roy Spliet <r.spliet@ultimaker.com>
>>>> ---
>>>>   include/configs/sunxi-common.h | 9 +++++++++
>>>>   1 file changed, 9 insertions(+)
>>>>
>>>> diff --git a/include/configs/sunxi-common.h 
>>>> b/include/configs/sunxi-common.h
>>>> index ec28c40..b38f2f5 100644
>>>> --- a/include/configs/sunxi-common.h
>>>> +++ b/include/configs/sunxi-common.h
>>>> @@ -404,8 +404,15 @@ extern int soft_i2c_gpio_scl;
>>>>   #define BOOT_TARGET_DEVICES_USB(func)
>>>>   #endif
>>>>
>>>> +#ifdef CONFIG_NAND
>>>> +#define BOOT_TARGET_DEVICES_NAND(func) func(NAND, nand , 0)
>>>> +#else
>>>> +#define BOOT_TARGET_DEVICES_NAND(func)
>>>> +#endif
>>>> +
>>>>   #define BOOT_TARGET_DEVICES(func) \
>>>>          BOOT_TARGET_DEVICES_MMC(func) \
>>>> +       BOOT_TARGET_DEVICES_NAND(func) \
>>>>          BOOT_TARGET_DEVICES_SCSI(func) \
>>>>          BOOT_TARGET_DEVICES_USB(func) \
>>>>          func(PXE, pxe, na) \
>>>> @@ -441,6 +448,8 @@ extern int soft_i2c_gpio_scl;
>>>>          MEM_LAYOUT_ENV_SETTINGS \
>>>>          "fdtfile=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
>>>>          "console=ttyS0,115200\0" \
>>>> +       "mtdids=nand0=mtd2\0" \
>>>> + "mtdparts=mtdparts=mtd2:0xffc00000 at 0x400000(nand0_main)\0" \
>>>>          BOOTENV
>>>  From what I heard the nand boot partition size should be specified in
>>> nand pages rather than bytes because the boot rom loads a fixed number
>>> of pages and just uses the start of each page regardless of page size.
>> Although I believe you have the facts mostly right, they do not apply 
>> in this situation.
>> What you are looking for is the partition definition for U-boot. At 
>> this point the boot
>> rom (BROM) is no longer active and thus it's inner workings are 
>> mostly irrelevant.
>> The NAND partition lay-out for the boards I have seen (various Olimex 
>> + Cubietruck..)
>> are as follows:
>> 0-2MB U-Boot-SPL + U-Boot
>> 2-4MB U-Boot SPL + U-Boot (for recovery)
>> 4MB+ Main file system
>>
>> The mtdparts env variable defines only the main file system because 
>> that's the only
>> place with relevant files for U-Boot.
>> This said: I have replaced the default file system with a "custom" 
>> UBI FS containing
>> just a boot and a rootfs partition. I am unsure whether these 
>> defaults apply for the
>> Android image that ships with the Olimex boards. But then again: that 
>> image also
>> ships with a boot-loader, so do we care?
>>> I did not find any document regarding the nand boot partition layout
>>> so I would like to see some input from somebody familiar with the
>>> driver.
>>>
>>> While it is fine for testing to hand-edit the environment the final
>>> nand support should have
>>>
>>> 1) way to express the boot partition size in nand pages
>>> 2) way to make the main partition start at the end of boot partition
>>> and extend to the end of the flash
>>>
>>> This should probably also go to Linux.
>> Linux can define partitions in the device tree. I'd prefer to carry 
>> this approach to U-boot,
>> but current U-Boot has the partitioning part of the MTD code hacked 
>> away and replaced by
>> custom mtdparts code without OF support. Doing this proper requires 
>> getting rid of the
>> latter, which will likely break a lot of legacy. So as far as I 
>> agree, I have to warn that is
>> a longer-term project, extended further by the ongoing (justified) 
>> discussion we are having
>> regarding the MTD partitioning code in upstream Linux that may or may 
>> not lead to parts
>> of the framework being re-architected.
>
> Last time I discussed this with some kernel people, they pointed me to 
> the fact that
> the kernel actually parses partition info provided by u-boot through 
> the u-boot mtdparts
> command, and that that is the preferred way to pass partition info to 
> the kernel, so rather
> then adding dts partition info to u-boot we would need to teach the 
> existing kernel mtdpart
> code to deal with separate ecc / random setting and maybe use a list 
> of hardcoded
> partitition names for which to use the brom compatible settings. These 
> are all things
> which we need to figure out on the kernel side, it would be good to 
> get a discussion
> started on this with the kernel mtd people.
I am unaware of the kernel developers' preferences, but [1] shows that 
the kernel
gained OF (DTS) partition parsing in 2008. We do need to teach the 
kernel (and U-Boot)
the trick of parsing mtd partitions, but with ARM/Linaro pushing DTS as 
the preferred way
to describe hardware we might have to consider this a separate 
discussion point.
>
> Note that we will also need to have a u-boot env partition somewhare 
> either at the
> nandpart level, or as a ubi volume, assuming the u-boot env code can 
> deal with
> ubi volumes (we are in the full u-boot environment when reading the env.)
Thanks, this is a relevant addition and something that needs investigation.
Unfortunately I can probably not pull this wagon too much further, given
I am about to continue my career in academics starting next month. I'd 
be happy to
think along and start the discussion, but I might not be around long 
enough to work
much on the implementation.
Yours,

Roy
>
> Regards,
>
> Hans
>
>
>
>>
>> Roy
>>> Thanks
>>>
>>> Michal
>>
>>


-- 


IMAGINE IT >> MAKE IT

Meet us online at Twitter <http://twitter.com/ultimaker>, Facebook 
<http://facebook.com/ultimaker>, Google+ <http://google.com/+Ultimaker>

www.ultimaker.com