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

[Pali Rohár]

On Thursday 20 August 2020 14:09:50 Stefan Roese wrote:
> On 20.08.20 14:03, Pali Rohár wrote:
> > 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)
> 
> I know that passing mtdparts= is working in general. You need the
> correct device names though. Perhaps something is wrong here. Hard
> to say, without looking deeper. Could you please post the complete
> Linux bootlog of this failing boot attempt?

I sent it to you in private email as log is large.

> > 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...
> 
> I understand. You have a working version and it makes not much sense
> for you to work on an alternative solution. But the fdt_fixup_mtdparts()
> way provides a common way for all (most?) boards and your's needs
> to be rewritten for each board. So from this prospective, it definitely
> makes sense to continue debugging / testing.

Well, currently I do not have time to debug other components to figure
out what is broken in uboot.

For me it looks like a overkill to enable & configure MTD layer, then
attach SF layer to it and all this would be needed only for usage of
fdt_fixup_mtdparts() function. And once these layers would be fixed and
fully working it would same thing as in this my patch.

> > Original patch which in this thread is working fine and kernel correctly
> > see both defined partitions in ft_board_setup() function.
> 
> I understand. Thanks for at looking into this anyways.
> 
> Thanks,
> Stefan