u-boot.lists.denx.de archive mirror
 help / color / mirror / Atom feed
From: "Marek Behún" <marek.behun@nic.cz>
To: Tom Rini <trini@konsulko.com>
Cc: "Patrick DELAUNAY" <patrick.delaunay@foss.st.com>,
	"Marek Vasut" <marex@denx.de>,
	u-boot@lists.denx.de, "Pali Rohár" <pali@kernel.org>,
	"Jagan Teki" <jagan@amarulasolutions.com>,
	"Christophe KERELLO" <christophe.kerello@foss.st.com>,
	"Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Priyanka Jain" <priyanka.jain@nxp.com>,
	"Patrice Chotard" <patrice.chotard@foss.st.com>,
	"Heiko Schocher" <hs@denx.de>, "Simon Glass" <sjg@chromium.org>,
	"Vignesh R" <vigneshr@ti.com>,
	"U-Boot STM32" <uboot-stm32@st-md-mailman.stormreply.com>
Subject: Re: [PATCH v4 0/2] mtd: spi: nor: force mtd name to "nor%d"
Date: Fri, 24 Sep 2021 21:25:59 +0200	[thread overview]
Message-ID: <20210924212559.22006a61@thinkpad> (raw)
In-Reply-To: <20210924182257.GG31748@bill-the-cat>

On Fri, 24 Sep 2021 14:22:57 -0400
Tom Rini <trini@konsulko.com> wrote:

> On Thu, Sep 23, 2021 at 11:04:28AM +0200, Patrick DELAUNAY wrote:
> > Hi,
> > 
> > On 9/23/21 3:32 AM, Marek Vasut wrote:  
> > > On 9/22/21 10:00 PM, Tom Rini wrote:  
> > > > On Wed, Sep 22, 2021 at 09:56:26PM +0200, Marek Vasut wrote:  
> > > > > On 9/22/21 9:46 PM, Tom Rini wrote:  
> > > > > > On Wed, Sep 22, 2021 at 09:24:24PM +0200, Marek Vasut wrote:
> > > > > >   
> > > > > > > I am talking about using nor%d in MTDIDS in U-Boot UBI
> > > > > > > code to look up from
> > > > > > > which device to attach UBI in U-Boot.  
> > > > > > 
> > > > > > OK, so are we not able to pass in the correct name now?  Or
> > > > > > just worried
> > > > > > about old environment and new U-Boot?  
> > > > > 
> > > > > Say you have the following in board config:
> > > > > 
> > > > > CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
> > > > > CONFIG_MTDPARTS_DEFAULT="mtdparts=ff705000.spi.0:-(fs);"
> > > > > 
> > > > > Then run "=> ubi part fs", which will fail to find nor0, because
> > > > > now that
> > > > > nor0 is called something else. That is what this series tries to fix.  
> > > > 
> > > > Yes, and what is nor0 now, and what happens if you use it?  
> > > 
> > > Now it is "mt25ql02g", for all mt25ql02g on the board, so ... I cannot
> > > even select the one SPI NOR I want to use, since they are not even
> > > enumerated in any way, they are all the same. You might want to look at
> > > get_mtd_device_nm() in drivers/mtd/mtdcore.c .  
> > 
> > 
> > To comple me use case, on EV1 board can boot from NOR / NAND / SPI-NAND
> > 
> > so mtdparts and mtdids are buidl dynamically with
> > CONFIG_SYS_MTDPARTS_RUNTIME in
> > 
> > afraided board/st/common/stm32mp_mtdparts.c::board_mtdparts_default()
> > 
> > 
> > I don't use MTDIDS_DEFAULT / MTDPARTS_DEFAULT.
> > 
> > 
> > For example, when I force NOR / NAND presence, I create the MTD variables:
> > 
> > mtdids=nand0=nand0,nor0=nor0
> > 
> > mtdparts=mtdparts=nand0:2m(fsbl),2m(ssbl1),2m(ssbl2),-(UBI);nor0:256k(fsbl1),256k(fsbl2),2m(ssbl),512k(u-boot-env),-(nor_user)
> > 
> > 
> > The command "mtdparts" is working in previous U-Boot releaseafraided
> > 
> > and it is not more working as the name of MTD device change
> > 
> > 
> > Today, without my patch I have
> >   
> > STM32MP> mtd list  
> > SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, total
> > 64 MiB
> > Could not find a valid device for nor0
> > List of MTD devices:
> > * nand0
> >   - type: NAND flash
> >   - block size: 0x40000 bytes
> >   - min I/O: 0x1000 bytes
> >   - OOB size: 224 bytes
> >   - OOB available: 118 bytes
> >   - ECC strength: 8 bits
> >   - ECC step size: 512 bytes
> >   - bitflip threshold: 6 bits
> >   - 0x000000000000-0x000040000000 : "nand0"
> >       - 0x000000000000-0x000000200000 : "fsbl"
> >       - 0x000000200000-0x000000400000 : "ssbl1"
> >       - 0x000000400000-0x000000600000 : "ssbl2"
> >       - 0x000000600000-0x000040000000 : "UBI"
> > * mx66l51235l
> >   - device: mx66l51235l@0
> >   - parent: spi@58003000
> >   - driver: jedec_spi_nor
> >   - path: /soc/spi@58003000/mx66l51235l@0
> >   - type: NOR flash
> >   - block size: 0x10000 bytes
> >   - min I/O: 0x1 bytes
> >   - 0x000000000000-0x000004000000 : "mx66l51235l"
> > * mx66l51235l
> >   - device: mx66l51235l@1
> >   - parent: spi@58003000
> >   - driver: jedec_spi_nor
> >   - path: /soc/spi@58003000/mx66l51235l@1
> >   - type: NOR flash
> >   - block size: 0x10000 bytes
> >   - min I/O: 0x1 bytes
> >   - 0x000000000000-0x000004000000 : "mx66l51235l"
> > 
> > 
> > 
> > before my patch, Ihave always the error "Device nor0 not found!" on mtdparts
> > command
> >   
> > => get_mtd_info  
> >   
> > ==> get_mtd_device_nm("nor0")   build with MTD_DEV_TYPE(type)  
> >   
> > ===> mtd_device_matches_name()  
> > 
> >             and here "nor0" must be  mtd->name acoring the code
> > 
> > 
> > or I miss something...
> > 
> > 
> > I don't found any way to solve my issue only with "mtdids" variable.
> > 
> > so I restore the previous behavior as I expect the mtd name
> > 
> > modification can impact many other boards.
> > 
> > 
> > A other solution can be change get_mtd_info(),
> > 
> > but I was also afraid of side effect.  
> 
> Thanks for explaining more.  Marek, any ideas on how to resolve this
> best, other than logic to restore some form of nor%d being created here?

So in board/st/common/stm32mp_mtdparts.c the mtd partitions are defined
in a options configurable in the Kconfig file in that directory:
  config MTDPARTS_NAND0_BOOT
    default "2m(fsbl),2m(ssbl1),2m(ssbl2)" if STM32MP15x_STM32IMAGE ||
                                              !TFABOOT
    default "2m(fsbl),4m(fip1),4m(fip2)"

  config MTDPARTS_NAND0_TEE
    default "512k(teeh),512k(teed),512k(teex)"
and so on.

This should be moved to device tree, and if needed, fixed up via
board_fix_fdt() if some needed fixes can only be discovered in runtime.

When mtd partitions are defined this way, the mtd command will be able
to work with them all.

The other thing is that the boot device is chosen according to the
result of get_bootmode() function, and can be UART, USB, NAND, SPINAND,
NOR.

This could be implemented via distro boot by setting some env variables
to needed values. include/configs/stm32mp1.h already does define
bootcmd_stm32mp, for example.

Anyway, this whole thing can be converted to not use mtdparts. I can
elaborate more to Patrick if he has some questions. He can also look
at how board/CZ.NIC/turris_omnia.c changes distro boot in
handle_reset_button() function.



I think all the other code using mtdparts can be converted in a similar
way. The question is how hard would it be to convert things such as UBI.

Marek

  reply	other threads:[~2021-09-24 19:26 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-22 16:29 [PATCH v4 0/2] mtd: spi: nor: force mtd name to "nor%d" Patrick Delaunay
2021-09-22 16:29 ` [PATCH v4 1/2] mtd: cfi_flash: use cfi_flash_num_flash_banks only when supported Patrick Delaunay
2021-09-28 18:45   ` Tom Rini
2021-09-22 16:29 ` [PATCH v4 2/2] mtd: spi: nor: force mtd name to "nor%d" Patrick Delaunay
2021-09-28 18:45   ` Tom Rini
2021-09-22 17:29 ` [PATCH v4 0/2] " Marek Behún
2021-09-22 18:24   ` Marek Vasut
2021-09-22 18:42     ` Tom Rini
2021-09-22 19:08       ` Marek Behún
2021-09-22 19:12       ` Marek Vasut
2021-09-22 19:05     ` Marek Behún
2021-09-22 19:23       ` Tom Rini
2021-09-22 19:39         ` Marek Vasut
2021-09-22 19:24       ` Marek Vasut
2021-09-22 19:41         ` Tom Rini
2021-09-22 19:42         ` Tom Rini
2021-09-22 19:46         ` Tom Rini
2021-09-22 19:56           ` Marek Vasut
2021-09-22 20:00             ` Tom Rini
2021-09-23  1:32               ` Marek Vasut
2021-09-23  9:04                 ` Patrick DELAUNAY
2021-09-24 18:22                   ` Tom Rini
2021-09-24 19:25                     ` Marek Behún [this message]
2021-09-24 20:09                       ` Marek Vasut
2021-09-25  0:12                         ` Marek Behún
2021-09-25  3:06                           ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210924212559.22006a61@thinkpad \
    --to=marek.behun@nic.cz \
    --cc=christophe.kerello@foss.st.com \
    --cc=hs@denx.de \
    --cc=jagan@amarulasolutions.com \
    --cc=marex@denx.de \
    --cc=miquel.raynal@bootlin.com \
    --cc=pali@kernel.org \
    --cc=patrice.chotard@foss.st.com \
    --cc=patrick.delaunay@foss.st.com \
    --cc=priyanka.jain@nxp.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=uboot-stm32@st-md-mailman.stormreply.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).