cancel
Showing results for 
Search instead for 
Did you mean: 

u-boot switch from NAND DFU backend to MTD breaks some use cases

Grodriguez
Senior

In previous releases of OpenSTLinux, u-boot used the NAND DFU backend to write to the NAND flash in the EV1 dev board. For UBI images, this required that the image was generated using the --space-fixup flag.

To avoid this requirement, I submitted a patch to add a new DFU_NAND_TRIMFFS option to u-boot (link). When this option was used, the DFU NAND backend would correctly write UBI images to flash regardless of whether --space-fixup was used.

With the latest release of OpenSTLinux, u-boot no longer uses the NAND DFU backend; it uses the MTD backend instead.

Is there a way to tell the MTD backend to do the same (drop trailing all-0xff pages), so that UBI images generated without --space-fixup can be used?

Thank you,

Guillermo

1 ACCEPTED SOLUTION

Accepted Solutions
PatrickD
ST Employee

Hi,

In V1.X, ST don't use TRIMFFS in U-Boot (CMD_NAND_TRIMFFS [=n])

And I agree with you, today this TRIMFFS feature is not supported on MTD

backend DFU introduced by ST in U-Boot (and also upstreamed):

it is a simple RAW, without full UBI support (same level than DFU NAND before

your patch).

For V2.0, we move to this DFU MTD interface to support all MTD devices with

only one DFU backend, including SPI-NAND.

Today I see a solution for your issue: implement the TRIM FSS directly in

the file drivers/dfu/dfu_mtd.c as it was done drivers/mtd/nand/raw/nand_util.c

= skip the LAST 0xFF in each write page with a new function drop_ffs

This dev is not planned today by ST as it is not mandatory:

"--space-fixup" flag is used in OpenSTLinux v2.0 yocto recipes

in meta-st/meta-st-stm32mp/conf/machine/include/st-machine-common-stm32mp.inc:

MKUBIFS_ARGS_nand_4_256 = "--min-io-size 4096 --leb-size 253952 --max-leb-cnt 4096 --space-fixup"

Why it is blocking for you to use "--space-fixup" flag as us ?

It is for time optimization on first boot ?

References:

http://www.linux-mtd.infradead.org/faq/ubifs.html#L_free_space_fixup

https://linux-mtd.infradead.narkive.com/MuWWGTRF/patch-ubifs-make-space-fixup-work-in-the-remount-case

if you want to come back to NAND DFU instead of MTD DFU.....

it should be possible with some adaptation but for me it just a temporarily solution,

I prefer the TRIMFFS addition in DFU_MTD (it is more generic solution)

I see something at least the next modification not tested:

1/ activate CONFIG_DFU_NAND (add imply arch/arm/mach-stm32mp/Kconfig in config CMD_STM32PROG)

2/ update configuration in arch/arm/mach-stm32mp$ ne cmd_stm32prog/stm32prog.c

in stm32prog_alt_add()

...

  " mmcpart %d;", -(part->part_id));

} else {

if (part->part_type == PART_SYSTEM &&

  (part->target == STM32PROG_NAND ||

   part->target == STM32PROG_NOR ||

   part->target == STM32PROG_SPI_NAND))

offset += snprintf(buf + offset,

  ALT_BUF_LEN - offset,

  "partubi");

else

offset += snprintf(buf + offset,

  ALT_BUF_LEN - offset,

  "part");

- /* dev_id requested by DFU MMC */

- if (part->target == STM32PROG_MMC)

+ /* dev_id requested by DFU MMC and FDU_NAND */

+ if (part->target == STM32PROG_MMC || part->target == STM32PROG_NAND)

offset += snprintf(buf + offset, ALT_BUF_LEN - offset,

  " %d", part->dev_id);

offset += snprintf(buf + offset, ALT_BUF_LEN - offset,

  " %d;", part->part_id);

}

switch (part->target) {

.....

- case STM32PROG_NAND:

case STM32PROG_NOR:

case STM32PROG_SPI_NAND:

sprintf(dfustr, "mtd");

get_mtd_by_target(devstr, part->target, part->dev_id);

break;

+ case STM32PROG_NAND:

+ sprintf(dfustr, "nand");

+ sprintf(devstr, "%d", part->dev_id);

+ break;

......

BR

Patrick

View solution in original post

7 REPLIES 7
Olivier GALLIEN
ST Employee

Hi @Grodriguez​ 

Thanks to raise this point.

Request has been escalated to assess integration in a next release.

A short term solution would be to stick on V1.2 ecosystem to benefit of your patch.

Do you have strong need to move to V2.0 ?

BR,

Olivier

Olivier GALLIEN
In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Grodriguez
Senior

Well, if I use the tf-a / u-boot from 1.2.0 now, I will not be able to upgrade the kernel of devices in the field later, since release 2.0.0 breaks backwards compatibility in this regard...

If there is no way to tell the MTD DFU backend to drop trailing all-0xff pages, is there any way to force stm32prog to use the NAND DFU backend instead of the MTD DFU backend ?

Guillermo

PatrickD
ST Employee

Hi,

In V1.X, ST don't use TRIMFFS in U-Boot (CMD_NAND_TRIMFFS [=n])

And I agree with you, today this TRIMFFS feature is not supported on MTD

backend DFU introduced by ST in U-Boot (and also upstreamed):

it is a simple RAW, without full UBI support (same level than DFU NAND before

your patch).

For V2.0, we move to this DFU MTD interface to support all MTD devices with

only one DFU backend, including SPI-NAND.

Today I see a solution for your issue: implement the TRIM FSS directly in

the file drivers/dfu/dfu_mtd.c as it was done drivers/mtd/nand/raw/nand_util.c

= skip the LAST 0xFF in each write page with a new function drop_ffs

This dev is not planned today by ST as it is not mandatory:

"--space-fixup" flag is used in OpenSTLinux v2.0 yocto recipes

in meta-st/meta-st-stm32mp/conf/machine/include/st-machine-common-stm32mp.inc:

MKUBIFS_ARGS_nand_4_256 = "--min-io-size 4096 --leb-size 253952 --max-leb-cnt 4096 --space-fixup"

Why it is blocking for you to use "--space-fixup" flag as us ?

It is for time optimization on first boot ?

References:

http://www.linux-mtd.infradead.org/faq/ubifs.html#L_free_space_fixup

https://linux-mtd.infradead.narkive.com/MuWWGTRF/patch-ubifs-make-space-fixup-work-in-the-remount-case

if you want to come back to NAND DFU instead of MTD DFU.....

it should be possible with some adaptation but for me it just a temporarily solution,

I prefer the TRIMFFS addition in DFU_MTD (it is more generic solution)

I see something at least the next modification not tested:

1/ activate CONFIG_DFU_NAND (add imply arch/arm/mach-stm32mp/Kconfig in config CMD_STM32PROG)

2/ update configuration in arch/arm/mach-stm32mp$ ne cmd_stm32prog/stm32prog.c

in stm32prog_alt_add()

...

  " mmcpart %d;", -(part->part_id));

} else {

if (part->part_type == PART_SYSTEM &&

  (part->target == STM32PROG_NAND ||

   part->target == STM32PROG_NOR ||

   part->target == STM32PROG_SPI_NAND))

offset += snprintf(buf + offset,

  ALT_BUF_LEN - offset,

  "partubi");

else

offset += snprintf(buf + offset,

  ALT_BUF_LEN - offset,

  "part");

- /* dev_id requested by DFU MMC */

- if (part->target == STM32PROG_MMC)

+ /* dev_id requested by DFU MMC and FDU_NAND */

+ if (part->target == STM32PROG_MMC || part->target == STM32PROG_NAND)

offset += snprintf(buf + offset, ALT_BUF_LEN - offset,

  " %d", part->dev_id);

offset += snprintf(buf + offset, ALT_BUF_LEN - offset,

  " %d;", part->part_id);

}

switch (part->target) {

.....

- case STM32PROG_NAND:

case STM32PROG_NOR:

case STM32PROG_SPI_NAND:

sprintf(dfustr, "mtd");

get_mtd_by_target(devstr, part->target, part->dev_id);

break;

+ case STM32PROG_NAND:

+ sprintf(dfustr, "nand");

+ sprintf(devstr, "%d", part->dev_id);

+ break;

......

BR

Patrick

Grodriguez
Senior

Hello @Community member​ 

Thank you for your answer, and also for the hints re. stm32prog.

Yes I'd rather avoid --space-fixup if possible for optimization of first boot and also to avoid unneeded writes.

I may look into adding drop_ffs support to the mtd dfu backend.

BTW I just submitted a fix for an issue in that code: https://patchwork.ozlabs.org/project/uboot/patch/20200902110606.15764-1-guille.rodriguez@gmail.com/

I am also reviewing other changes that have happened in the 1.2.0 -> 2.0.0 transition.

BR,

Guillermo

Bernard PUEL
ST Employee

Hello Guillermo,

after ST internal review, ST has entered a ticket for this development but it is for long term delivery (ecosystem based on next kernel LTS).

For short term, ST can give support or review to your patch if needed (as we started to do in this thread).

Hi @Community member​ 

Just as a quick feedback -- I can confirm that your suggested patch to switch back to DFU_NAND works.

(I agree that this is a short term solution only and that the right thing to do would be to add support for TRIMFFS to DFU_MTD)

Thanks,

Guillermo

PatrickD
ST Employee

Hi,

Just for information, the requested patch is pushed in U-Boot mailing list:

http://patchwork.ozlabs.org/project/uboot/patch/20220118102619.1.I161a621b6f151ada380bedac41d2a2bd67d47933@changeid/

It will be integrated in V4.0.0

Patrick