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

[Stefan Roese]

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?

> 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.

> 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