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@d0000000/spi@10600/flash@0/partition@0 > > (/soc/internal-regs@d0000000/spi@10600/flash@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
