Hello!
On Mon, Mar 25, 2024 at 10:46 PM Alexey Romanov
<avroma...@salutedevices.com> wrote:
>
> UBI block is virtual block device, which is an abstraction
> over MTD layer. Therefore it is logical to use it in combination
> with MTD drivers.
>
> Signed-off-by: Alexey Romanov <avroma...@salutedevices.com>
> ---
> drivers/mtd/nand/spi/core.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
> index dd880adf31..c47f6c1b46 100644
> --- a/drivers/mtd/nand/spi/core.c
> +++ b/drivers/mtd/nand/spi/core.c
> @@ -27,6 +27,7 @@
> #include <watchdog.h>
> #include <spi.h>
> #include <spi-mem.h>
> +#include <ubi_uboot.h>
> #include <dm/device_compat.h>
> #include <dm/devres.h>
> #include <dm/uclass.h>
> @@ -1182,8 +1183,13 @@ static int spinand_bind(struct udevice *dev)
> {
> if (blk_enabled()) {
> struct spinand_plat *plat = dev_get_plat(dev);
> + int ret;
> +
> + ret = mtd_bind(dev, &plat->mtd);
> + if (ret)
> + return ret;
>
> - return mtd_bind(dev, &plat->mtd);
> + return ubi_bind(dev);
Is this expecting the entire SPI-NAND covered by a single UBI partition?
It's almost never this case on real hardware. For SPI-NAND booted
SoCs, the first few blocks always store the first stage bootloader
raw, because bootrom knows nothing about UBI.
> }
>
> return 0;
> --
> 2.34.1
>
--
Regards,
Chuanhong Guo
