From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roy Spliet Date: Mon, 08 Jun 2015 15:56:45 +0200 Subject: [U-Boot] [linux-sunxi] [RFC 11/11] mtd/nand: Sunxi NAND boot partition definitions In-Reply-To: <557595AC.7030403@redhat.com> References: <1433505164-24112-1-git-send-email-r.spliet@ultimaker.com> <1433505164-24112-12-git-send-email-r.spliet@ultimaker.com> <55755472.5080008@ultimaker.com> <557595AC.7030403@redhat.com> Message-ID: <55759F1D.108@ultimaker.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 wrote: >>>> Based on the default layout of the android image used at least on >>>> Olimex Lime >>>> >>>> Signed-off-by: Roy Spliet >>>> --- >>>> 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 , Facebook , Google+ www.ultimaker.com