2020-09-01 03:33 AM
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
Solved! Go to Solution.
2020-09-02 09:41 AM
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
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
2020-09-01 07:59 AM
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
2020-09-01 08:29 AM
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
2020-09-02 09:41 AM
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
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
2020-09-03 10:06 AM
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
2020-09-04 01:52 AM
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).
2020-10-06 12:59 AM
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
2022-01-18 01:30 AM
Hi,
Just for information, the requested patch is pushed in U-Boot mailing list:
It will be integrated in V4.0.0
Patrick