Hello Boris,
On Wed, Dec 12, 2018 at 10:32:51AM +0100, Boris Brezillon wrote:
Hi Ladislav,
On Tue, 11 Dec 2018 23:55:26 +0100 Ladislav Michl ladis@linux-mips.org wrote:
Hi Boris,
On Mon, Dec 10, 2018 at 04:38:50PM +0100, Boris Brezillon wrote:
The only implementer of this function has been patched to use CONFIG_MTD{IDS,PARTS}_DEFAULT instead. Let's get rid of this function and the associated CONFIG_SYS_MTDPARTS_RUNTIME option.
the only implementer of this fuction did so for a good reason. What is a motivation to remove it?
Simplifying the code (see this discussion [1] which led me to send this patchset).
Thank you, makes sense.
The requirement is to be able to use single u-boot binary on all igep2 boards ever produced. These comes with various NAND and OneNAND chips and I was not able to come with single static partition configuration to support them all.
That's actually the question I asked Enric in [1]. Can you list all the memory organization you have (for NAND and OneNAND chips)? I mean, the SPL part size depends on the NAND/OneNAND erase block size, and board vendors try to use similar flashes when they source different parts (same page size, same block size, ...). Assuming this is the case, you should always have the same layout for OneNAND/NAND devices, hence my proposal to define those parts statically.
First, thanks to Enric for pinging me, otherwise I would probably miss this completely.
Now problem is that IGEPv2 comes with quite many configurations, some of them are even customized, so static configuration is a show stopper mainly as I do not know what devices are in field. Another issue is how ubispl code works: It expects struct ubispl_info filled with (among others) peb_offset of ubi partition. ubispl code counts in terms of eraseblocks regardless of their size. So we would need to touch this number when using static mtdparts.
Hence runtime detection. That code could be used on all OMAP3 boards as BootROM reads up to first four sectors searching for SPL (MLO).
Note that, for the nand side of things, you can also automate that using a u-boot script:
nand info; setexpr splsize ${nand_erasesize} * 4; setenv mtdparts mtdparts=omap2-nand:0x${splsize}(SPL),-(UBI)
That seems as a way to go!
Shouldn't be hard to patch the onenand cmd to also expose writesize, erasesize and oobsize.
Side note: I never fully understand why is OneNAND using separate set of commands.
Could you hold merging your paches until I implement above idea and test it on a few boards? I know u-boot is now using two months merge window, which is unfortunate, so I'll try to do it as soon as possible, but I do not think I'll finish it till end of week.
Regards,
Boris
[1]https://www.mail-archive.com/u-boot@lists.denx.de/msg304933.html