search

trabucayre / openFPGALoader

Universal utility for programming FPGA
https://trabucayre.github.io/openFPGALoader/
Apache License 2.0
1.2k stars 257 forks source link

flashrom interoperability #125

Open emard opened 3 years ago

emard commented 3 years ago

There's utility "flashrom" which already supports a lot of flash chips and I'm thinking how it could be used for FPGA https://www.flashrom.org/Supported_hardware#USB_Devices

I'm thinking about idea if openFPGALoader could expose a dll library or network compatible protocol like "serprog" so "flashrom" utility could use openFPGALoader as some virtual programmer bridge to access flash chip.

trabucayre commented 3 years ago

The idea to split openFPGALoader between a library and a frontend is in my TODO list. The big question is about run time impact. Using FPGA lowlevel code to access flash is a solution to take profit to both code. Anyway, I've planned ASAP to add features requested by #124 and to improve a bit (lot ?) spiFlash class. Thanks

emard commented 3 years ago

HI

Thanx, it can stay on TODO list and I think it should not be too urgent. Of course it will work slower than integrated tool.

I have just tested "flashrom" and for my chips of interest, ISSI IS25LP128, IS25LP032 and Winbond W25Q128JV "flashorm" tool provides only basic RW support and no block write protection control which I hoped for.

Here's small core that exposes FLASH SPI lines to 2.54 mm board pins at ULX3S to connect external programmer FT2232, which is supported by "flashom".

https://github.com/emard/ulx3s-misc/tree/master/examples/flash_passthru/proj

On 10/6/21, Gwenhael Goavec-Merou @.***> wrote:

The idea to split openFPGALoader between a library and a frontend is in my TODO list. The big question is about run time impact. Using FPGA lowlevel code to access flash is a solution to take profit to both code. Anyway, I've planned ASAP to add features requested by #124 and to improve a bit (lot ?) spiFlash class. Thanks

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/trabucayre/openFPGALoader/issues/125#issuecomment-936840491

trabucayre commented 3 years ago

For library it's something I consider interesting/necessary. In fact, to do tests or addition usually I create a small app out-of-tree and It's a bit boring to have to write a long Makefile with all required direct or indirect classes. I have started to work to (un)protect sectors but it's required to have knowledge about flash chip so I need to integrate list of known devices. Bottom to top sectors protection requires to change one bit, on most flash it's just non-volatile bit to set but for anothers chips it's an OneTimeProgramming bit -> In this situation I'm not happy to be (or openFPGALoader) responsable to a unrevertible modification.

I Will check/add flash you point.

WIP

emard commented 3 years ago

Yes, OTP bit is very annoying, I have already set lock bit to 1 in winbond register and now I can't reset it to 0.

For handling write protection for flash chips found on my boards, I have made a small esp32 micropython utility - it reports protection status and sets default protection for first 2MB that's what I need for bootloader.

https://github.com/emard/esp32ecp5/blob/master/ecp5wp.py

from my user point of view for universal tool, I'd like to enter wanted protection range like 0 - 0x1FFFFF and let the tool autodetect chip, if OTP change is needed, report to user what consequences will be from setting OTP bits (no more programming or just no more changing top/bottom) ask for additional confirmation option and set wanted protection range.

On 10/7/21, Gwenhael Goavec-Merou @.***> wrote:

For library it's something I consider interesting/necessary. In fact, to do tests or addition usually I create a small app out-of-tree and It's a bit boring to have to write a long Makefile with all required direct or indirect classes. I have started to work to (un)protect sectors but it's required to have knowledge about flash chip so I need to integrate list of known devices. Bottom to top sectors protection requires to change one bit, on most flash it's just non-volatile bit to set but for anothers chips it's an OneTimeProgramming bit -> In this situation I'm not happy to be (or openFPGALoader) responsable to a unrevertible modification.

I Will check/add flash you point.

WIP

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/trabucayre/openFPGALoader/issues/125#issuecomment-937504103

trabucayre commented 3 years ago

My answer in #124