[PATCH 2/2] arm: mvebu: Espressobin: Setup MTD partitions when booting kernel
Stefan Roese
sr at denx.de
Thu Aug 20 13:19:34 CEST 2020
On 20.08.20 13:12, 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:
>>>> On Thursday 20 August 2020 07:02:18 Stefan Roese wrote:
>>>>> Can't you just use "mtdparts=" kernel cmdline parameter instead to pass
>>>>> the MTD layout to the kernel?
>>>>
>>>> Maybe it is possible too, I have not tried it.
>>>>
>>>> I thought that more common is to update DTS file by uboot when loading
>>>> kernel as it is already done e.g. for ethernet MAC address on
>>>> Espressobin.
>>>
>>> Updating the MAC address is very common, yes. But passing the
>>> MTD partition layout via the mtdparts= cmdline is also very
>>> common and used very frequently. From my experience, its the
>>> defacto recommended method to pass this info and also easier than
>>> generating these DTS lines via some code.
>>>
>>> Please take a look at the mtdparts U-Boot command and its usage
>>> in other targets.
>>>
>>>> Also I see that uboot has function fdt_fixup_mtdparts() via
>>>> CONFIG_FDT_FIXUP_PARTITIONS option which do this, but uses uboot MTD
>>>> code which IIRC cannot initialize SPI NOR.
>>>
>>> Why not?
>>
>> I had an impression that U-Boot does not support.
>>
>>> SPI NOR is also integrated into the U-Boot MTD world as
>>> well. Please see this GARDENA MT7688 target, which uses SPI NOR &
>>> SPI NAND:
>>
>> Ok, I'm going to look at it.
>
> With following config
>
> CONFIG_MTD=y
> CONFIG_CMD_MTD=y
> CONFIG_CMD_MTDPARTS=y
> CONFIG_SPI_FLASH_MTD=y
> CONFIG_MTDIDS_DEFAULT="nor0=nor0"
>
> I get following result:
>
> => mtd list
> List of MTD devices:
> No MTD device found
> => mtdparts
> Device nor0 not found!
> => sf probe
> SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
> => mtdparts
> => mtd list
> List of MTD devices:
> * nor0
> - type: NOR flash
> - block size: 0x1000 bytes
> - min I/O: 0x1 bytes
> - 0x000000000000-0x000000400000 : "nor0"
>
> So main problem is that MTD does not work until I call 'sf probe' in
> uboot command line.
Then a dependency seems to be missing here. On my MT7688 board I get
this:
U-Boot 2020.07-rc5-00075-g0b7d95531c-dirty (Jun 30 2020 - 09:51:39 +0200)
CPU: MediaTek MT7688A ver:1 eco:2
Boot: DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
Model: GARDENA smart Gateway (MT7688)
DRAM: 128 MiB
WDT: Started with servicing (60s timeout)
Loading Environment from SPI Flash... SF: Detected XM25QH64A with page
size 256 Bytes, erase size 4 KiB, total 8 MiB
OK
F-Data:factory-data version 1 detected
Net: eth0: eth at 10110000
Hit any key to stop autoboot: 0
=> dm tree
Class Index Probed Driver Name
-----------------------------------------------------------
root 0 [ + ] root_driver root_driver
...
spi 0 [ + ] mt7621_spi | |-- spi at b00
spi_flash 0 [ + ] spi_flash_std | | |-- spi-flash at 0
mtd 0 [ ] spi_nand | | `-- spi-nand at 1
...
=> mtd list
List of MTD devices:
* nor0
- type: NOR flash
- block size: 0x1000 bytes
- min I/O: 0x1 bytes
- 0x000000000000-0x000000800000 : "nor0"
- 0x000000000000-0x0000000a0000 : "uboot"
- 0x0000000a0000-0x0000000b0000 : "uboot_env0"
- 0x0000000b0000-0x0000000c0000 : "uboot_env1"
- 0x0000000c0000-0x0000000d0000 : "factory"
- 0x0000000d0000-0x000000800000 : "unused"
* spi-nand0
- device: spi-nand at 1
- parent: spi at b00
- driver: spi_nand
- type: NAND flash
- block size: 0x20000 bytes
- min I/O: 0x800 bytes
- OOB size: 128 bytes
- OOB available: 63 bytes
- 0x000000000000-0x000008000000 : "spi-nand0"
- 0x000000000000-0x000008000000 : "nand"
=> dm tree
Class Index Probed Driver Name
-----------------------------------------------------------
root 0 [ + ] root_driver root_driver
...
spi 0 [ + ] mt7621_spi | |-- spi at b00
spi_flash 0 [ + ] spi_flash_std | | |-- spi-flash at 0
mtd 0 [ + ] spi_nand | | `-- spi-nand at 1
...
As you see, spi_nand is automatically probed by "mtd list". SPI NOR
is most likely already probed since its used for ENV storage.
It would be great, if you could check, if and where such a dependency
is missing in your case.
Thanks,
Stefan
More information about the U-Boot
mailing list