litex_boards bump is blocked. Local LiteX scripts probably need update.

[tcal-x]

See https://github.com/im-tomu/fomu-workshop/pull/410/checks?check_run_id=1616270863#step:10:5267. add_dfu_suffix has been removed from the latest litex_boards.

[mithro]

@umarcor - Can you take a look?

[tcal-x]

I had told @umarcor that I would take a look since I had just been playing with up-to-date Litex + Fomu.

[tcal-x]

Quick comments about the current litex_boards targets/fomu.py that we're not bumping to:

• It is now much more standardized with other LiteX targets
• It seems it now only supports PVT (production) Fomu
• It doesn't immediately support the no-CPU build used in the workshop, but this is probably an easy fix.
• Calling add_dfu_suffix is now integral to the LiteX utility for flashing Fomu (before it was part of building). So, we could either use LiteX --flash directly, or have the user manually run add_dfu_suffix before dfu-util -D.

[umarcor]

@tcal-x, what is the status of this issue? It seems that the fomu.py mentioned in enjoy-digital/litex#773 does not exist anymore?

[tcal-x]

Thanks for the ping, @umarcor. The new fomu.py has been renamed kosagi_fomu.py. It would probably be confusing if we copied the old fomu.py into that directory, if that's what you were thinking. Although it occurred to me, we could possibly copy the old targets/fomu.py into fomu-workshop. We'd need to check if it worked with the current platforms/kosagi_fomu_pvt.py.

There's another issue I forgot to mention above -- now that the default LteX build for Fomu (target/kosagi_fomu.py) includes LEDchaser, the workshop exercise of adding the RGB module (https://workshop.fomu.im/en/latest/migen.html#wishbone-bus-extension) might not work unless we suppress the LEDchaser first.

I'll make time later this week to look at it.