is it possible to reveal history of this patch?:
nand-base.c patch disabling all NAND modes >1
That patch should be banned at least for no single word of comment in the code for what they did, why and what the heck is that magic number 1. Unpatched code was taking supported NAND modes mask from ONFI data of attached chip, then iterated calculating the best transfer mode.
Some Colibries have MX30LF4G28AB populated, some MX30LF4G28AC. With mode 1 I get less than 7MB/s from both chips with
dd if=/dev/mtd4 of=/dev/null bs=1M status=progress. Unapplying that patch the same speed rises >3 times to 22MB/s. Everything seems being stable, but it would be nice to know why did they apply that patch. Chip errata doesn’t seem having any problems with NAND.
Looking at upstream kernel source code, it seems this patch is not applied.
Hi @Edward ,
Thank you for using the community.
What BSP version did you use with your Colibri iMX7? And what version of the Colibri do you use?
Linux BSP 5.3.0, but that patch is dated 2019 and applies to older BSPs as well. Verified to apply to Colibri iMX6ULL 512MB, Colibri iMX6ULL512MB WB, and Colibri iMX7D 512MB. These are just the Colibries I’m using. All show the same result, >20MB/s /dev/mtd read speed using upstream kernel and <8MB/s /dev/mtd read speed using downstream kernel.
And what about my question about the reason and history of this weird patch?
Hi @Edward ,
this patch was not written by Toradex. It was signed-off by Han Xu email@example.com. I would suggest you contact nxp directly if you want to know more about the reason and history of this patch.
Thank for your reply. Looks like latest NXP BSPs use newer kernel, which doesn’t have this problem. I expected all that data stored in git logs could be useful to track such issues. Indeed it isn’t.