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

[Pali Rohár]

On Thursday 20 August 2020 10:51:28 Pali Rohár wrote:
> On Thursday 20 August 2020 10:17:55 Stefan Roese wrote:
> > On 20.08.20 09:40, Pali Rohár wrote:
> > > 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?
> 
> In case U-Boot would see MTD SPI partitions, then fdt_fixup_mtdparts()
> should work.

It looks like that fdt_fixup_mtdparts() is broken.

I added following config lines

CONFIG_MTDIDS_DEFAULT="nor0=nor0"
CONFIG_MTDPARTS_DEFAULT="nor0:4032k(firmware),64k(u-boot-env)"
CONFIG_FDT_FIXUP_PARTITIONS=y

Then in uboot console I called 'sf probe' and 'boot'.

And Linux kernel thrown following MTD error:

[    1.038352] spi-nor spi0.0: w25q32dw (4096 Kbytes)
[    1.043403] spi0.0: error parsing ofpart partition /soc/internal-regs at d0000000/spi at 10600/flash at 0/partition at 0 (/soc/internal-regs at d0000000/spi at 10600/flash at 0)

So I do not know if it makes sense to continue debugging SF <--> MTD
layer in Uboot when passing uboot MTD partitions via
fdt_fixup_mtdparts() to Linux kernel does not work...

Original patch which in this thread is working fine and kernel correctly
see both defined partitions in ft_board_setup() function.