[PATCH 2/2] arm: mvebu: Espressobin: Setup MTD partitions when booting kernel

[Stefan Roese]

On 20.08.20 09:40, Pali Rohár wrote:
> On Thursday 20 August 2020 07:02:18 Stefan Roese wrote:
>> Can't you just use "mtdparts=" kernel cmdline parameter instead to pass
>> the MTD layout to the kernel?
> 
> Maybe it is possible too, I have not tried it.
> 
> I thought that more common is to update DTS file by uboot when loading
> kernel as it is already done e.g. for ethernet MAC address on
> Espressobin.

Updating the MAC address is very common, yes. But passing the
MTD partition layout via the mtdparts= cmdline is also very
common and used very frequently. From my experience, its the
defacto recommended method to pass this info and also easier than
generating these DTS lines via some code.

Please take a look at the mtdparts U-Boot command and its usage
in other targets.

> Also I see that uboot has function fdt_fixup_mtdparts() via
> CONFIG_FDT_FIXUP_PARTITIONS option which do this, but uses uboot MTD
> code which IIRC cannot initialize SPI NOR.

Why not? SPI NOR is also integrated into the U-Boot MTD world as
well. Please see this GARDENA MT7688 target, which uses SPI NOR &
SPI NAND:

=> mtd list
List of MTD devices:
* nor0
   - type: NOR flash
   - block size: 0x1000 bytes
   - min I/O: 0x1 bytes
   - 0x000000000000-0x000000800000 : "nor0"
           - 0x000000000000-0x0000000a0000 : "uboot"
           - 0x0000000a0000-0x0000000b0000 : "uboot_env0"
           - 0x0000000b0000-0x0000000c0000 : "uboot_env1"
           - 0x0000000c0000-0x0000000d0000 : "factory"
           - 0x0000000d0000-0x000000800000 : "unused"
* spi-nand0
   - device: spi-nand at 1
   - parent: spi at b00
   - driver: spi_nand
   - type: NAND flash
   - block size: 0x20000 bytes
   - min I/O: 0x800 bytes
   - OOB size: 128 bytes
   - OOB available: 63 bytes
   - 0x000000000000-0x000008000000 : "spi-nand0"
           - 0x000000000000-0x000008000000 : "nand"
=> mtdparts

device nor0 <spi0.0>, # parts = 5
  #: name                size            offset          mask_flags
  0: uboot               0x000a0000      0x00000000      0
  1: uboot_env0          0x00010000      0x000a0000      0
  2: uboot_env1          0x00010000      0x000b0000      0
  3: factory             0x00010000      0x000c0000      0
  4: unused              0x00730000      0x000d0000      0

device spi-nand0 <spi0.1>, # parts = 1
  #: name                size            offset          mask_flags
  0: nand                0x08000000      0x00000000      0

active partition: nor0,0 - (uboot) 0x000a0000 @ 0x00000000

defaults:
mtdids  : spi-nand0=spi0.1,nor0=spi0.0
mtdparts: 
spi0.0:640k(uboot),64k(uboot_env0),64k(uboot_env1),64k(factory),-(unused);spi0.1:-(nand)

> Anyway, updating DTS has advantage that it is not needed to update
> existing boot scripts for OS. There are more distributions for
> Espressobin which have own boot scripts stored on SD card for loading
> kernel. And therefore to use command line parameters it would be needed
> to update all of them.

I see. This is an argument I understand. But can't you use the common
fdt_fixup_mtdparts() then?

> And I see there another problem. For specifying size of mtd partitions
> in command line, it is required to know offsets of those partitions. And
> e.g. uboot env partition depends on CONFIG_ENV_OFFSET option which is
> not available for uboot boot script code.
> 
> But if you have other idea, I'm open to also other solutions.

I have not investigated a multi-distribution solution here. Perhaps
the common fdt_fixup_mtdparts() is able to handle this?

If not, then I won't stop this current patch. I just wanted to point
out the more common and more elegant solutions to you.

Thanks,
Stefan