Using dhara for nor and nand flash - some questions

[Laczen]

Hi @dlbeer, thank you for providing dhara.

I am looking at using dhara for both nor and nand flashes as a "virtual block manager" with wear levelling. Dhara already provides excellent support for nand flashes but for nor flashes I am running into some issues:

1. Nor flashes are a lot smaller then nand flashes so it is wanted to keep the dhara_meta_size small, there are two possibilities to do that: reduce the radix depth and reduce the meta entry.

I have been succesfull at reducing the radix depth (is it correct that this can be seen as a measure of the amount of logical pages ?).

Reducing the size of the meta entry (is it correct that this can be seen as a measure of the amount of physical pages ?) seems to be more difficult, what would be the best way to reduce this to e.g. a uint16_t ?

2. Nor flashes have the ability to continue writing to a page, would it make sense to introduce a dhara_nand_rewrite() routine that tries to rewrite a page and if it fails to continue the present behaviour. For nand flashes this routine could just return an error.

[Laczen]

I have been able to also reduce the size of the meta entry to a uint16_t. Would you accept a PR that enables smaller radix depth and meta size entry ?

Something I am missing is a way to validate the checkpoint metadata page, a addition of a crc32 at the end of that page could resolve this, what is your opinion ?

[dlbeer]

On Tue, Nov 23, 2021 at 02:29:01AM -0800, Jehudi Maes wrote: Hi @dlbeer, thank you for providing dhara. I am looking at using dhara for both nor and nand flashes as a "virtual block manager" with wear levelling. Dhara already provides excellent support for nand flashes but for nor flashes I am running into some issues: 1. Nor flashes are a lot smaller then nand flashes so it is wanted to keep the dhara_meta_size small, there are two possibilities to do that: reduce the radix depth and reduce the meta entry. I have been succesfull at reducing the radix depth (is it correct that this can be seen as a measure of the amount of logical pages ?). Reducing the size of the meta entry (is it correct that this can be seen as a measure of the amount of physical pages ?) seems to be more difficult, what would be the best way to reduce this to e.g. a uint16_t ?

You would need to do both. Reducing the radix depth won't do anything by itself, but it will enable you to reduce the metadata size to (radix_depth*4 + 4) bytes.

2. Nor flashes have the ability to continue writing to a page, would it make sense to introduce a `dhara_nand_rewrite()` routine that tries to rewrite a page and if it fails to continue the present behaviour. For nand flashes this routine could just return an error.

I'm not sure what you mean here. Do you mean rewriting 1 bits to 0s? Or just treating a page as multiple sub-pages and writing individual chunks on separate occasions?

…

-- Daniel Beer ***@***.***> http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B

[dlbeer]

On Tue, Nov 23, 2021 at 08:17:58AM -0800, Jehudi Maes wrote: I have been able to also reduce the size of the meta entry to a uint16_t. Would you accept a PR that enables smaller radix depth and meta size entry ?

I would prefer not to have to support something like this in the master branch, as it adds complexity for testing if it's a compile-time option. However, if you wanted to post your local changes here I'd be happy to check it over for issues and review it if that's helpful to you.

…

-- Daniel Beer ***@***.***> http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B

[Laczen]

On Tue, Nov 23, 2021 at 08:17:58AM -0800, Jehudi Maes wrote: I have been able to also reduce the size of the meta entry to a uint16_t. Would you accept a PR that enables smaller radix depth and meta size entry ?
I would prefer not to have to support something like this in the master branch, as it adds complexity for testing if it's a compile-time option. However, if you wanted to post your local changes here I'd be happy to check it over for issues and review it if that's helpful to you.

Thank you for your quick reply. I will keep my changes local for the moment. I was thinking about adding support for dhara into zephyr, but for that dhara would need to be a little bit more configurable and also support nor flashes.

Regarding the rewrite, most nor flashes allow you to rewrite a certain flash location as long as you only change 1's to 0.

[dlbeer]

On Tue, Nov 23, 2021 at 08:43:16PM -0800, Jehudi Maes wrote: Regarding the rewrite, most nor flashes allow you to rewrite a certain flash location as long as you only change 1's to 0.

Yes, that's true. If you thought that was useful, you could perhaps make use of it already by using dhara_map_find to locate the physical page that needs modification. I wouldn't recommend doing this in general though, as it means that your write operation becomes non-atomic -- the power might fail after the reprogram attempt has failed, but before you've had a chance to fall back on a normal sector write.

…

-- Daniel Beer ***@***.***> http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B