5 ms·

It's possible to write 256 bit of user data to the Pis internal OTP memory. You can store a non-changeable key there. Of course that's then easily readable if y

It's possible to write 256 bit of user data to the Pis internal OTP memory. You can store a non-changeable key there. Of course that's then easily readable if you can run execute commands on the Pi. LittleFS (recently posted here) is indeed interesting, although from the documentation I couldn't figure out 1) if it works for larger devices as it seems it seems mostly intended for sizes of a few MB. I might be totally wrong with that. 2) if/how it handles corruption of complete blocks(?) of SD memory. As far as I understand, an SD card doesn't necessarily use 4K block sizes and corruption might hit multiple blocks at once. If LittleFS stores both previous and next version next to each other, I don't think that'll help in that case.

skl_ 8y ago
Oh, there's an OTP in the MPU? I didn't know that. Yes with 1) I'm not sure either but there's some sporadic discussion in the Github issues with various attempts. From what I remember certain scenarios currently cause all blocks to be re-scanned which will obviously get slower with capacity. With regards 2), I was under the impression each block is allocated according to the wear-levelling algo[0] so I don't think they're contiguous if that's what you mean. Also block size is configurable. I tried implementing LittleFS on a 32MB SFDP flash with Mbed but couldn't get any decent performance out of it. It kept spewing out "bad block" errors an re-allocating everything. I hope it's a more viable option in future though as I do like the design. [0] https://github.com/ARMmbed/littlefs/blob/master/DESIGN.md https://github.com/ARMmbed/littlefs/blob/master/DESIGN.md
opless 8y ago
I posted it (though I'll freely admit hackaday was the source that I discovered it through) Personally I want to use it as an internal filesystem for various projects (like games - instead of zip/pak files, which are really read only) even littlefs over https might be an interesting naval gazing project :D

skl_ 8y ago

Oh, there's an OTP in the MPU? I didn't know that. Yes with 1) I'm not sure either but there's some sporadic discussion in the Github issues with various attempts. From what I remember certain scenarios currently cause all blocks to be re-scanned which will obviously get slower with capacity. With regards 2), I was under the impression each block is allocated according to the wear-levelling algo[0] so I don't think they're contiguous if that's what you mean. Also block size is configurable. I tried implementing LittleFS on a 32MB SFDP flash with Mbed but couldn't get any decent performance out of it. It kept spewing out "bad block" errors an re-allocating everything. I hope it's a more viable option in future though as I do like the design. [0] https://github.com/ARMmbed/littlefs/blob/master/DESIGN.md https://github.com/ARMmbed/littlefs/blob/master/DESIGN.md

opless 8y ago

I posted it (though I'll freely admit hackaday was the source that I discovered it through) Personally I want to use it as an internal filesystem for various projects (like games - instead of zip/pak files, which are really read only) even littlefs over https might be an interesting naval gazing project :D