jlaitine commented on pull request #3834: URL: https://github.com/apache/incubator-nuttx/pull/3834#issuecomment-854937825
> @jlaitine As I mentioned, the H7 was the only platform that interpreted getpage as the index of writable units instead of erasable units. Can you explain why this was necessary? It stands out to me that no one needed this information before and makes me wonder what the use-case is for this info is. I don't think the above is true; you need to look into other devices which use the progmem interface on NAND flash (with ECC correction). I am not saying that everything in stm32h7 flash driver is good :) But it is extremely important that we maintain clear distinction between the eraseblocks and write/read unit. Otherwise it is impossible to use the interface with NAND flash devices, where the smallest read/write unit actually matters. On NOR flash devices it pretty much makes no difference. On some NAND flash devices the smallest erasable unit is so small that you can actually mix these up by also reading/writing the same size. On stm32h7 there is no room for compromise, since it has got a 128KB (!) smallest erase size and 32 byte read/write size. However, I have seen it mapped to both PX4 flashparams and also nuttx littlefs (latter turned out to make no sense, but worked in principle). So the it can't be all broken... It is also that this distinction is there on purpose in progmem.h; see the topmost commit touching it: " commit 0f18e8cc328f1a420135531eb2afe57b27d3332f Author: EunBong Song <[email protected]> Date: Fri Sep 21 03:18:38 2018 +0000 " Also check out the commit history of "drivers/mtd/mtd_progmem.c" I don't object naming changes as such, if there is a common view that it is important. I just 1) see the need of distinction between the "eraseblock" and "write/read unit" for NAND flash support and 2) personally liked the nuttx-way of naming these "block" and "page". -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
