trabucayre changed the topic of #openFPGALoader to: Universal utility for programming FPGA / Github: https://github.com/trabucayre/openFPGALoader/ Logs: https://libera.irclog.whitequark.org/openFPGALoader
m_w has joined #openFPGALoader
<m_w> greetings all
<m_w> I was wondering if there is a porting guide for this loader
<m_w> trying to get standard support for the ICE-V wireless so that it can easily be provided by upstream for oss-cad-suite > apio > icestudio
<trabucayre> m_w: I have to do to documentation about how to port openFPGALoader to a new device/probe/family
<trabucayre> m_w: the ESP32 is required to program the flash no?
<m_w> yeah it handle the protocol
<m_w> handles
<m_w> there is no flash connected directly to the FPGA on ICE-V
<m_w> we use the ESP32's flash to store the bitstream and initial content of the PSRAM that is connected to the FPGA
<trabucayre> Ok! So the communication isn't a classic protocol but something specific host<->ESP32?
<m_w> yup
<m_w> the ESP32 is the protocol master
<m_w> we just send it data using WiFi or USB
<m_w> seeing as openFPGAloader assumes you want to drive the protocol from the host it might not be the best fit
<trabucayre> ok! I see. So you have to follow DFU, XVC server or SPI model.
<m_w> it is a simple protocol developed by emeb
<trabucayre> nt, in openFPGALoader, at the same level as protocols previouly cited.
<trabucayre> I mean it's a protocol to implement, in openFPGALoader, at the same level as protocols previouly cited.
<m_w> ICE-V is all pretty much self contained when it comes to FPGA protocol
<m_w> we just may to provide it at a level which can be easily consumed by the other open tools specifically icestudio
<trabucayre> in fact, for openFPGALoader, it's a new protocol, totally independent
<trabucayre> You are more or less free to implement has you want in fact.
<trabucayre> it's how I have added the xvc server protocol
<m_w> okay
<trabucayre> your question is relevant: draft I'm write about contribution is mainly on how to extend cable list or device list. For cable list it's in the context of an already implemented protocol (jtag, xvc_server, dfu, spi) but not how to add a new protocol!
<m_w> yeah I think that protocols lead to neverending support
<m_w> so providing the stubs and having people maintain their own protocol is the best option
<m_w> esp32-c3 is special in that the USB port is fixed to UART only
<m_w> but we got the wifi "cable" :)
<trabucayre> seeing a protocol == a plugin may be a good idea
<m_w> yes; I think that we need to go up one level in abstraction
<trabucayre> yup. if it doesn't have a big impact on performance
<m_w> should we add a ticket for new protocol support?
<trabucayre> it's a solution yep or you can create a PR too (or both)
<trabucayre> unfortunately I haven't this board and consequently it will more difficult to me to implement this protocol without being able to test
<m_w> yeah they are prerelease now
<m_w> trying to keep it upstream
<m_w> upstream first
<m_w> so that people can more easily command of the device when they receive it
<m_w> just made 6 prototypes by hand and I have two left
<m_w> I rather not ship
<trabucayre> ok
<m_w> though there will be a first batch coming this week and I can try to get some allocation for community developers
<trabucayre> backer first no?
<m_w> well backers will get them but we produced extra units
<m_w> so backers could add this support but I rather give the units to people that are going to provide support
<m_w> free as in beer
<trabucayre> make sense :)
<m_w> so I will see if I can get you and benitoss a module
<m_w> from the first batch
<trabucayre> If it's possible (without penalizing anyone because I have lot of thing to do (DAYJOB, improving/adding intel max10 support and another task) and I'm not sure to be enough reactive)
<trabucayre> thanks!
<trabucayre> But I think this protocol may be faster to implement compared to the difficulty to find required informations for intel device.
<m_w> well we will gauge the interest when the modules are available
<m_w> sounds like a handful for you and wouldn't want to make it hold up more pressing things
<m_w> look are looking more direct apio support for now
<m_w> *looking at