From: Marek Vasut <marex@denx.de>
To: "Marek Behún" <marek.behun@nic.cz>, "Tom Rini" <trini@konsulko.com>
Cc: "Patrick DELAUNAY" <patrick.delaunay@foss.st.com>,
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 22:09:15 +0200 [thread overview]
Message-ID: <f3c1e30e-a7d7-a492-2ca1-789edf1f9290@denx.de> (raw)
In-Reply-To: <20210924212559.22006a61@thinkpad>
On 9/24/21 9:25 PM, Marek Behún wrote:
> 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.
I have a feeling the discussion is again banking toward "mtdparts" and
"DT", which really is a solved problem, or at least we agreed upon the
solution.
The patch is trying to fix MTDIDS and their look up in
get_mtd_device_nm(). This is all U-Boot stuff, it has nothing to do with
passing mtd partitions to Linux at all.
next prev parent reply other threads:[~2021-09-24 20:09 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
2021-09-24 20:09 ` Marek Vasut [this message]
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=f3c1e30e-a7d7-a492-2ca1-789edf1f9290@denx.de \
--to=marex@denx.de \
--cc=christophe.kerello@foss.st.com \
--cc=hs@denx.de \
--cc=jagan@amarulasolutions.com \
--cc=marek.behun@nic.cz \
--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).