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@1
- parent: spi@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
