On 05/23/2018 08:25 AM, Geert Uytterhoeven wrote:

Hi Marek,

On Wed, May 23, 2018 at 12:01 AM, Marek Vasut [off-list ref] wrote:

quoted

On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:

quoted

On Tue, May 22, 2018 at 2:02 PM, Marek Vasut [off-list ref] wrote:

quoted

Drop the MTD partitioning from DT, since it does not describe HW
and to give way to a more flexible kernel command line partition
passing.

To retain the original partitioning, assure you have enabled
CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
following to your kernel command line:

  mtdparts=spi0.0:256k at 0(loader),4096k(user),-(flash)

I think the "@0" can be dropped, as it's optional?
4m?

My take on this is that the loader is actually at offset 0x0 of the MTD
device and we explicitly state that in the mtdparts to anchor the first
partition within the MTD device and all the other partitions are at
offset +(sum of the sizes of all partitions listed before the current
one) relative to that first partition.

Where is this explicitly states for the first partition?

quoted

Removing the @0 feels fragile at best and it seems to depend on the
current behavior of the code.

Better, it also depends on the documented behavior:

Documentation/admin-guide/kernel-parameters.txt refers to
drivers/mtd/cmdlinepart.c, which states:

 * <offset>  := standard linux memsize
 *              if omitted the part will immediately follow the previous part
 *              or 0 if the first part

None of the examples listed there or under the MTD_CMDLINE_PARTS Kconfig
help text, or in a defconfig bundled with the kernel, use @0 for the first
partition.

I think this is exceptionally fragile and dangerous to depend on this,
but so be it.

-- 
Best regards,
Marek Vasut