Re: [PATCH u-boot-dm + u-boot-spi v2 0/7] Support SPI NORs and OF partitions in `mtd list`
On Wed, 10 Feb 2021 15:31:56 +0100 Patrice CHOTARD wrote: > and what about @ as shown in my previous email > ? And there is a second problem with this: this can be bad for automatic U-Boot scripts. For example on Turris Omnia there are boards which were manufactured with a Macronix SPI-NOR, and boards which were manufactured with Winbond SPI-NOR (or Spansion or something different from Macronix). So I think that there should be some mechanism available via the mtd command to select the SPI-NOR by its chip select somehow, without knowing the SPI ID.
Re: [PATCH u-boot-dm + u-boot-spi v2 0/7] Support SPI NORs and OF partitions in `mtd list`
On Wed, 10 Feb 2021 15:31:56 +0100 Patrice CHOTARD wrote: > > So one solution is to use device-tree name to select the NOR, but still > > print the name determined from SPI ID somewhere. > > > > Second solution is to allow selecting the SPI by number, i.e. (the n-th > > enumerated SPI). > > and what about @ as shown in my previous email > ? That could be one solution, but there would still be a collision if there were multiple SPI controllers. It is possible to have two identical SPI-NORs connected to 2 different SPI controllers on the same chip select. But maybe this situation is rare enough that we can ignore it.
Re: [PATCH u-boot-dm + u-boot-spi v2 0/7] Support SPI NORs and OF partitions in `mtd list`
Hi Marek
On 2/10/21 3:14 PM, Marek Behun wrote:
> On Wed, 10 Feb 2021 14:48:23 +0100
> Patrice CHOTARD wrote:
>
>> +Patrick
>>
>> Hi All
>>
>> I have tested this series on stm32mp1-ev1 board which embeds 1 nand and 2
>> identical spi-nor.
>> spi-nor DT node is the following:
>>
>> {
>> pinctrl-names = "default", "sleep";
>> pinctrl-0 = <_clk_pins_a _bk1_pins_a _bk2_pins_a>;
>> pinctrl-1 = <_clk_sleep_pins_a _bk1_sleep_pins_a
>> _bk2_sleep_pins_a>;
>> reg = <0x58003000 0x1000>, <0x7000 0x400>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>> status = "okay";
>>
>> flash0: mx66l51235l@0 {
>> compatible = "jedec,spi-nor";
>> reg = <0>;
>> spi-rx-bus-width = <4>;
>> spi-max-frequency = <10800>;
>> #address-cells = <1>;
>> #size-cells = <1>;
>> };
>>
>> flash1: mx66l51235l@1 {
>> compatible = "jedec,spi-nor";
>> reg = <1>;
>> spi-rx-bus-width = <4>;
>> spi-max-frequency = <10800>;
>> #address-cells = <1>;
>> #size-cells = <1>;
>> };
>> };
>>
>> As is, this series is not able to differentiate the both identical spi-nor
>> using the MTD framework.
>> Both spi-nor have the same name "mx66l51235l" as shown below, and usage of
>> mtd command is not possible to reach
>> both spi-nor:
>>
>> STM32MP> mtd list
>> List of MTD devices:
>> * nand0
>> - type: NAND flash
>> - block size: 0x4 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
>> - 0x-0x4000 : "nand0"
>> * mx66l51235l
>> - device: mx66l51235l@0
>> - parent: spi@58003000
>> - driver: jedec_spi_nor
>> - type: NOR flash
>> - block size: 0x1 bytes
>> - min I/O: 0x1 bytes
>> - 0x-0x0400 : "mx66l51235l"
>> * mx66l51235l
>> - device: mx66l51235l@1
>> - parent: spi@58003000
>> - driver: jedec_spi_nor
>> - type: NOR flash
>> - block size: 0x1 bytes
>> - min I/O: 0x1 bytes
>> - 0x-0x0400 : "mx66l51235l"
>>
>> The following patch fix it :
>>
>> @@ -2528,11 +2528,11 @@ int spi_nor_scan(struct spi_nor *nor)
>> ret = spi_nor_init_params(nor, info, );
>> if (ret)
>> return ret;
>>
>> if (!mtd->name)
>> -mtd->name = info->name;
>> +mtd->name = (char *)nor->dev->name;
>> mtd->dev = nor->dev;
>> mtd->priv = nor;
>> mtd->type = MTD_NORFLASH;
>> mtd->writesize = 1;
>> mtd->flags = MTD_CAP_NORFLASH;
>>
>>
>>
>> Now it looks like :
>>
>> STM32MP> mtd list
>> List of MTD devices:
>> * nand0
>> - type: NAND flash
>> - block size: 0x4 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
>> - 0x-0x4000 : "nand0"
>> * mx66l51235l@0
>> - device: mx66l51235l@0
>> - parent: spi@58003000
>> - driver: jedec_spi_nor
>> - type: NOR flash
>> - block size: 0x1 bytes
>> - min I/O: 0x1 bytes
>> - 0x-0x0400 : "mx66l51235l@0"
>> * mx66l51235l@1
>> - device: mx66l51235l@1
>> - parent: spi@58003000
>> - driver: jedec_spi_nor
>> - type: NOR flash
>> - block size: 0x1 bytes
>> - min I/O: 0x1 bytes
>> - 0x-0x0400 : "mx66l51235l@1"
>> STM32MP>
>>
>> Everything goes fine, i observed one side effect regarding "sf probe"
>> command:
>>
>> STM32MP> sf probe
>> SF: Detected mx66l51235l@0 with page size 256 Bytes, erase size 64 KiB,
>> total 64 MiB
>> STM32MP> sf probe 1
>> SF: Detected mx66l51235l@1 with page size 256 Bytes, erase size 64 KiB,
>> total 64 MiB
>>
>> Here the flash name is mx66l51235l@0 or mx66l51235l@1 and no more
>> mx66l51235l.
>
> I too tried that change (using (char *)nor->dev->name as mtd name).
>
> The thing is that the name "mx66l51235l" is determined from the SPI NOR
> ID (not the device-tree), so if you solder a different NOR, the name
> will be different. Meanwhile dts name is always the same.
Ok got it, i didn't pay attention to the fact nor->dev->name doesn't come from
spi-nor-ids but from DT :-(
>
> I think the mtd command should at least inform the user what kind of SPI
> NOR is soldered on the board.
Fully agree
>
> So one solution is to use device-tree name to select the NOR, but still
> print the name determined from SPI ID somewhere.
>
> Second solution is to allow selecting the SPI by number, i.e. (the n-th
> enumerated SPI).
and what about @ as shown in my previous email ?
>
> (BTW regarding your dts node names, the node names should be spi-nor@0
> and spi-nor@1. Yes, I know that spi-nor is not documented in
> device-tree bindings yet, but this would be
Re: [PATCH u-boot-dm + u-boot-spi v2 0/7] Support SPI NORs and OF partitions in `mtd list`
On Wed, 10 Feb 2021 14:48:23 +0100
Patrice CHOTARD wrote:
> +Patrick
>
> Hi All
>
> I have tested this series on stm32mp1-ev1 board which embeds 1 nand and 2
> identical spi-nor.
> spi-nor DT node is the following:
>
> {
> pinctrl-names = "default", "sleep";
> pinctrl-0 = <_clk_pins_a _bk1_pins_a _bk2_pins_a>;
> pinctrl-1 = <_clk_sleep_pins_a _bk1_sleep_pins_a
> _bk2_sleep_pins_a>;
> reg = <0x58003000 0x1000>, <0x7000 0x400>;
> #address-cells = <1>;
> #size-cells = <0>;
> status = "okay";
>
> flash0: mx66l51235l@0 {
> compatible = "jedec,spi-nor";
> reg = <0>;
> spi-rx-bus-width = <4>;
> spi-max-frequency = <10800>;
> #address-cells = <1>;
> #size-cells = <1>;
> };
>
> flash1: mx66l51235l@1 {
> compatible = "jedec,spi-nor";
> reg = <1>;
> spi-rx-bus-width = <4>;
> spi-max-frequency = <10800>;
> #address-cells = <1>;
> #size-cells = <1>;
> };
> };
>
> As is, this series is not able to differentiate the both identical spi-nor
> using the MTD framework.
> Both spi-nor have the same name "mx66l51235l" as shown below, and usage of
> mtd command is not possible to reach
> both spi-nor:
>
> STM32MP> mtd list
> List of MTD devices:
> * nand0
> - type: NAND flash
> - block size: 0x4 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
> - 0x-0x4000 : "nand0"
> * mx66l51235l
> - device: mx66l51235l@0
> - parent: spi@58003000
> - driver: jedec_spi_nor
> - type: NOR flash
> - block size: 0x1 bytes
> - min I/O: 0x1 bytes
> - 0x-0x0400 : "mx66l51235l"
> * mx66l51235l
> - device: mx66l51235l@1
> - parent: spi@58003000
> - driver: jedec_spi_nor
> - type: NOR flash
> - block size: 0x1 bytes
> - min I/O: 0x1 bytes
> - 0x-0x0400 : "mx66l51235l"
>
> The following patch fix it :
>
> @@ -2528,11 +2528,11 @@ int spi_nor_scan(struct spi_nor *nor)
> ret = spi_nor_init_params(nor, info, );
> if (ret)
> return ret;
>
> if (!mtd->name)
> - mtd->name = info->name;
> + mtd->name = (char *)nor->dev->name;
> mtd->dev = nor->dev;
> mtd->priv = nor;
> mtd->type = MTD_NORFLASH;
> mtd->writesize = 1;
> mtd->flags = MTD_CAP_NORFLASH;
>
>
>
> Now it looks like :
>
> STM32MP> mtd list
> List of MTD devices:
> * nand0
> - type: NAND flash
> - block size: 0x4 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
> - 0x-0x4000 : "nand0"
> * mx66l51235l@0
> - device: mx66l51235l@0
> - parent: spi@58003000
> - driver: jedec_spi_nor
> - type: NOR flash
> - block size: 0x1 bytes
> - min I/O: 0x1 bytes
> - 0x-0x0400 : "mx66l51235l@0"
> * mx66l51235l@1
> - device: mx66l51235l@1
> - parent: spi@58003000
> - driver: jedec_spi_nor
> - type: NOR flash
> - block size: 0x1 bytes
> - min I/O: 0x1 bytes
> - 0x-0x0400 : "mx66l51235l@1"
> STM32MP>
>
> Everything goes fine, i observed one side effect regarding "sf probe" command:
>
> STM32MP> sf probe
> SF: Detected mx66l51235l@0 with page size 256 Bytes, erase size 64 KiB, total
> 64 MiB
> STM32MP> sf probe 1
> SF: Detected mx66l51235l@1 with page size 256 Bytes, erase size 64 KiB, total
> 64 MiB
>
> Here the flash name is mx66l51235l@0 or mx66l51235l@1 and no more mx66l51235l.
I too tried that change (using (char *)nor->dev->name as mtd name).
The thing is that the name "mx66l51235l" is determined from the SPI NOR
ID (not the device-tree), so if you solder a different NOR, the name
will be different. Meanwhile dts name is always the same.
I think the mtd command should at least inform the user what kind of SPI
NOR is soldered on the board.
So one solution is to use device-tree name to select the NOR, but still
print the name determined from SPI ID somewhere.
Second solution is to allow selecting the SPI by number, i.e. (the n-th
enumerated SPI).
(BTW regarding your dts node names, the node names should be spi-nor@0
and spi-nor@1. Yes, I know that spi-nor is not documented in
device-tree bindings yet, but this would be consistent with other
device-tree bindings in Linux.)
Marek
Re: [PATCH u-boot-dm + u-boot-spi v2 0/7] Support SPI NORs and OF partitions in `mtd list`
+Patrick
Hi All
I have tested this series on stm32mp1-ev1 board which embeds 1 nand and 2
identical spi-nor.
spi-nor DT node is the following:
{
pinctrl-names = "default", "sleep";
pinctrl-0 = <_clk_pins_a _bk1_pins_a _bk2_pins_a>;
pinctrl-1 = <_clk_sleep_pins_a _bk1_sleep_pins_a
_bk2_sleep_pins_a>;
reg = <0x58003000 0x1000>, <0x7000 0x400>;
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
flash0: mx66l51235l@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-rx-bus-width = <4>;
spi-max-frequency = <10800>;
#address-cells = <1>;
#size-cells = <1>;
};
flash1: mx66l51235l@1 {
compatible = "jedec,spi-nor";
reg = <1>;
spi-rx-bus-width = <4>;
spi-max-frequency = <10800>;
#address-cells = <1>;
#size-cells = <1>;
};
};
As is, this series is not able to differentiate the both identical spi-nor
using the MTD framework.
Both spi-nor have the same name "mx66l51235l" as shown below, and usage of mtd
command is not possible to reach
both spi-nor:
STM32MP> mtd list
List of MTD devices:
* nand0
- type: NAND flash
- block size: 0x4 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
- 0x-0x4000 : "nand0"
* mx66l51235l
- device: mx66l51235l@0
- parent: spi@58003000
- driver: jedec_spi_nor
- type: NOR flash
- block size: 0x1 bytes
- min I/O: 0x1 bytes
- 0x-0x0400 : "mx66l51235l"
* mx66l51235l
- device: mx66l51235l@1
- parent: spi@58003000
- driver: jedec_spi_nor
- type: NOR flash
- block size: 0x1 bytes
- min I/O: 0x1 bytes
- 0x-0x0400 : "mx66l51235l"
The following patch fix it :
@@ -2528,11 +2528,11 @@ int spi_nor_scan(struct spi_nor *nor)
ret = spi_nor_init_params(nor, info, );
if (ret)
return ret;
if (!mtd->name)
- mtd->name = info->name;
+ mtd->name = (char *)nor->dev->name;
mtd->dev = nor->dev;
mtd->priv = nor;
mtd->type = MTD_NORFLASH;
mtd->writesize = 1;
mtd->flags = MTD_CAP_NORFLASH;
Now it looks like :
STM32MP> mtd list
List of MTD devices:
* nand0
- type: NAND flash
- block size: 0x4 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
- 0x-0x4000 : "nand0"
* mx66l51235l@0
- device: mx66l51235l@0
- parent: spi@58003000
- driver: jedec_spi_nor
- type: NOR flash
- block size: 0x1 bytes
- min I/O: 0x1 bytes
- 0x-0x0400 : "mx66l51235l@0"
* mx66l51235l@1
- device: mx66l51235l@1
- parent: spi@58003000
- driver: jedec_spi_nor
- type: NOR flash
- block size: 0x1 bytes
- min I/O: 0x1 bytes
- 0x-0x0400 : "mx66l51235l@1"
STM32MP>
Everything goes fine, i observed one side effect regarding "sf probe" command:
STM32MP> sf probe
SF: Detected mx66l51235l@0 with page size 256 Bytes, erase size 64 KiB, total
64 MiB
STM32MP> sf probe 1
SF: Detected mx66l51235l@1 with page size 256 Bytes, erase size 64 KiB, total
64 MiB
Here the flash name is mx66l51235l@0 or mx66l51235l@1 and no more mx66l51235l.
Thanks
Patrice
On 2/9/21 3:44 PM, Marek Behún wrote:
> Hello,
>
> this is v2 of patchset that adds support for U-Boot to parse MTD
> partitions from device-tree, and also improves support for SPI NOR
> access via the `mtd` command.
>
> Since mtd subsystem is unmaintained, who shall apply the mtd patches?
> I put an u-boot-spi tag into the subject prefix, but am not sure if
> this is correct.
>
> Changes since v1:
> - added tests of ofnode_get_addr_size_index() and
> ofnode_get_addr_size_index_notrans() as requested by Simon
> - the last patch now probes SPI NORs in both versions of
> mtd_probe_devices(), that is when MTDPARTS is enabled or disabled
>
> Marek
>
> Marek Behún (7):
> dm: core: add test for ofnode_get_addr_size_index()
> dm: core: add non-translating version of ofnode_get_addr_size_index()
> mtd: add support for parsing partitions defined in OF
> mtd: spi-nor: allow registering multiple MTDs when DM is enabled
> mtd: spi-nor: fill-in mtd->dev member
> mtd: remove mtd_probe function
> mtd: probe SPI NOR devices in mtd_probe_devices()
>
> drivers/core/ofnode.c | 19 -
> drivers/mtd/mtd-uclass.c | 15
> drivers/mtd/mtd_uboot.c| 129 -
> drivers/mtd/mtdpart.c | 60 +++
> drivers/mtd/spi/sf_internal.h | 4 +-
> drivers/mtd/spi/sf_mtd.c |
[PATCH u-boot-dm + u-boot-spi v2 0/7] Support SPI NORs and OF partitions in `mtd list`
Hello, this is v2 of patchset that adds support for U-Boot to parse MTD partitions from device-tree, and also improves support for SPI NOR access via the `mtd` command. Since mtd subsystem is unmaintained, who shall apply the mtd patches? I put an u-boot-spi tag into the subject prefix, but am not sure if this is correct. Changes since v1: - added tests of ofnode_get_addr_size_index() and ofnode_get_addr_size_index_notrans() as requested by Simon - the last patch now probes SPI NORs in both versions of mtd_probe_devices(), that is when MTDPARTS is enabled or disabled Marek Marek Behún (7): dm: core: add test for ofnode_get_addr_size_index() dm: core: add non-translating version of ofnode_get_addr_size_index() mtd: add support for parsing partitions defined in OF mtd: spi-nor: allow registering multiple MTDs when DM is enabled mtd: spi-nor: fill-in mtd->dev member mtd: remove mtd_probe function mtd: probe SPI NOR devices in mtd_probe_devices() drivers/core/ofnode.c | 19 - drivers/mtd/mtd-uclass.c | 15 drivers/mtd/mtd_uboot.c| 129 - drivers/mtd/mtdpart.c | 60 +++ drivers/mtd/spi/sf_internal.h | 4 +- drivers/mtd/spi/sf_mtd.c | 19 - drivers/mtd/spi/sf_probe.c | 6 +- drivers/mtd/spi/spi-nor-core.c | 1 + drivers/mtd/spi/spi-nor-tiny.c | 1 + include/dm/ofnode.h| 17 + include/linux/mtd/mtd.h| 9 +++ include/mtd.h | 1 - test/dm/ofnode.c | 29 13 files changed, 236 insertions(+), 74 deletions(-) -- 2.26.2
