On Wed, Sep 22, 2021 at 09:05:36PM +0200, Marek Behún wrote: > On Wed, 22 Sep 2021 20:24:18 +0200 > Marek Vasut <ma...@denx.de> wrote: > > > On 9/22/21 7:29 PM, Marek Behún wrote: > > > (Adding also Tom.) > > > > > > Hi Patrick, Marek, > > > > > > I find this either not complete or not needed: > > > > > > - either you need mtd names to be of this format so that old MTDPARTS > > > config definitions do not need to be changed, i.e. something like > > > CONFIG_MTDPARTS_DEFAULT="nor0:1M(u-boot),0x1000@0xfff000(env)" > > > does not work currently, and you want to make it work. > > > > > > I find your solution here incomplete because MTDPARTS can also be > > > used to be passed to Linux as mtdparts parameter, but there is no > > > guarantee that the "norN" numbering you are creating in U-Boot will > > > be the same as the one in kernel. > > > > > > - or it is not needed, because you can remove MTDPARTS definition from > > > the board config entirely and move the information into device tree. > > > In fact this was the main idea behind making the series > > > Support SPI NORs and OF partitions in `mtd list` > > > The SPI-NOR MTDs after this series can have conflicting names, > > > because you can still choose between them via OF path with the `mtd` > > > command. > > > > > > Tom and I were of the opinion that MTDPARTS should be deprecated and > > > removed in favor of OF. Marek Vasut says that this is not possible > > > for every board, and so needs to stay. > > > > > > BTW, I find it a little weird for Marek to defend old API which should > > > be converted to DT, when in discussion about DM USB / Nokia N900 > > > USB TTY console [1] he was defending the opinion that we should be > > > heading to DT in U-Boot. > > > > > > [1] > > > https://patchwork.ozlabs.org/project/uboot/patch/20210618145724.2558-1-p...@kernel.org/ > > > > > > > That USB discussion is completely unrelated to the problem here, the USB > > discussion is about internal (i.e. not user facing) conversion to DM/DT. > > The user-facing ABI does not change there. Also, that discussion was > > about patching USB stack to permit new non-DM/DT operation, not fixing > > existing one. > > This is not only about the user ABI (altough now I agree that you are > correct there, see below). What I meant is this: > Should we push for converting to device-tree even if for some boards > it is not possible, and would mean removing them? > > Because you are saying that MTDPARTS cannot be converted to DT for > some boards. > > But N900 also cannot be reasonably converted because of space > issues, as far as I understood. Yes, it has gigabytes of eMMC storage, > and it was proposed to put SPL in MTD and U-Boot proper into eMMC on > VFAT/ext4, but this simply cannot be done reasonably, because: > - it would break Linux userspace (existing OS upgrade system would > have to be rewritten and backwords compatibility would be broken) > - it would make bootstrapping (booting newer version of U-Boot) while > developing U-Boot a pain in the ass or maybe even impossible > - I beleive there was some other reason Pali mentioned, but I cannot > remember anymore > > > This problem here is user facing ABI, the mtdparts/mtdids. That user > > facing ABI got broken. Boards which do depend on it, even those > > currently in tree, are broken. Not all boards can update their > > environment, so some backward compatibility of the user facing ABI > > should be in place, even though it might not be to the degree Linux > > kernel does so. So far, it seems most of the U-Boot command line > > interface has managed to retain backward compatibility, I don't see why > > this here should be handled any differently. > > OK, I get that the if `mtd nor0` was working before, it should work also > now. But the conversion from MTDPARTS to device tree could be probably > done for lots of these, see below. > > > Note that there are not just a few boards that are broken, but hundreds. > > I believe that itself justifies a fix, instead of just throwing all > > those hundreds of boards overboard. > > > > u-boot$ git grep -l CONFIG_MTDIDS configs | wc -l > > 203 > > Only 96 of those also grep the substring "nor". But okay, that is still > a lot. The question is how many of them could be rewritten to DT: > > for cfg in $(git grep -l 'CONFIG_MTDIDS.*nor[0-9]' configs); do > fgrep CONFIG_DEFAULT_DEVICE_TREE "$cfg" > done | wc -l > > 92 of those 96 have CONFIG_DEFAULT_DEVICE_TREE defined. > > Of these, 65 contain CONFIG_DM_SPI_FLASH=y, so at least these 65 could > be converted. Of the rest 27, how many could also be converted to DM? > How may use non-DM drivers?
I was thinking maybe we have problems with the platforms that "mtdparts default", of which we have a handful and most of that handful also do it to then make use of the partition table within U-Boot (dfu, or update the on-flash U-Boot). Of those, it might make most sense to poke the maintainer directly on how to proceed. -- Tom
signature.asc
Description: PGP signature
