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

Yassin
2015-06-08T10:48:41Z

Hi Roy
Thank you for working on this, I would like to suggest if you could implement separate control commands to switch ECC and Randomisation modes per partitions. I know this is not the best approach but it will provide more controls.

> On 8 Jun 2015, at 7:11 pm, Roy Spliet <r.spliet@ultimaker.com> wrote:
>
> Dear Michal,
>
> Op 08-06-15 om 10:54 schreef Michal Suchanek:
>> On 8 June 2015 at 10:38, Roy Spliet <r.spliet@ultimaker.com> 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
>> OK, so 0-2 MB has to be read (at least in part) by brom to load the
>> SPL so it must be in the format brom understands. The part containing
>> the SPL which is read by brom has certain number of pages. The u-boot
>> part can contain whatever we define.
>>
>>> 2-4MB U-Boot SPL + U-Boot (for recovery)
>>> 4MB+ Main file system
>> The main filesystem has to be in format suitable for UBIFS. It has to
>> follow u-boot part possibly with some space in between.
>>
>> If support for non-uniform flash format is not available then there
>> are basically two options:
>>
>> 1) SPL supports brom format and u-boot binary is part of boot
>> partition. SPL can read/write itself and u-boot and u-boot can
>> read/write the main partition
>>
>> 2) SPL and u-boot support the main partition format. While u-boot is
>> written to the boot partition its pages are written in the format
>> suitable for ubifs. This will get hairy when you want to actually
>> write u-boot and SPL.
>>
>> The problem with counting the partition sizes in bytes is obvious -
>> whatever you do the brom reads predefined number of pages from the
>> start of the nand to load the SPL and unless you know maximum page
>> size of every nand ever made that is compatible with Allwinner brom
>> you cannot tell what is even the maximum size of this part in bytes.]
> The solution already implemented now and carried to Hans' tree is 1)
> with the size of SPL aligned to 8KB blocks (the largest of the page sizes
> attempted). The modes tried by BROM are listed in [1]. SPL currently
> tries only a single mode whose params are defined in sunxi-common.h,
> but this is likely to change to a "brute-force" approach to resemble
> BROM in the near future.
> Yours,
>
> Roy
>>
>> Thanks
>>
>> Michal
>
> [1] https://linux-sunxi.org/NAND
>
> --
>
>
> 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
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.