Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please revive the tools-system repo #459

Closed
zapta opened this issue Nov 14, 2024 · 8 comments
Closed

Please revive the tools-system repo #459

zapta opened this issue Nov 14, 2024 · 8 comments

Comments

@zapta
Copy link
Collaborator

zapta commented Nov 14, 2024

@Obijuan, @cavearr, The tools-system is marked as 'archived' and 'read/only'. Please revive it to a normal repo status. I am sending PRs now that will load that package to provide the ftdi_eeprom binary without having to modify the stock oss-cad-suite package.

https://github.com/FPGAwars/tools-system

@cavearr
Copy link
Member

cavearr commented Nov 14, 2024

Thanks @zapta , i will add new tools for new boards to this package, very good idea reopen it.

I made for some guys a cutom tinyfpga programmer , for wrong firmware batch in 2024 (i don't know if you know about it) i put in standby this but could be a good idea put our patched version in this package, what do you think?

@cavearr
Copy link
Member

cavearr commented Nov 14, 2024

tools-system is alive! @zapta

@zapta
Copy link
Collaborator Author

zapta commented Nov 14, 2024

Thanks @cavearr.

Regarding the patched tinyfpga, some thoughts:

  1. From the package perspective, if the binary name does conflict with existing binary names it should be ok. This package is curated by the APIO team as opposed to other packages such as oss-cad-tools.

  2. You mentioned 'wrong firmware', is there a way to fix the firmware? May be easier to provide a fixing tool.

  3. How will the users use it, will they use different programmer and board definitions? Are you going to add it to boards.json?

@cavearr
Copy link
Member

cavearr commented Nov 14, 2024

Hi @zapta, I tell you, it is a long and complex story. On the one hand, the big problem is that the tinyfpga project seems somewhat abandoned or, if not, neglected, the software has not been released for a long time and the main developers do not respond in the forum or in the issues.

In parallel to this support situation, Mouser released a batch this year with an error in the flash metadata. The Tiny uses a quite interesting bootloader but it plays with read-only pages in the flash. A lot of threads have been opened both in the github issues and in different forums (redit for example). But there is no official solution neither response.

Some users asked for help on Fpgawars and I managed to unify a solution by putting together several possible partial solutions from different forums, here is the thread in which an affected user confirms that it works:

FPGAwars/icestudio#753

The problem is that I don't have a 2024 tiny (mine has always worked well). But as that affected user told you, he confirmed that the solution works.

The solution is a patch on the official programmer, we could either create an alternative programmer and create our own package, but to avoid generating noise and confusion with the official one, I would put it into the system tools as another programmer, or create a package in fpgawars but always indicating that it is not official. In principle this tinyprogrammer should work with all tiny boards, the bad ones and the good ones, but we could always keep both . One possible solution could be duplicate tinyfpga boards with the suffix '2024fix' or something like this.

As I said, there have been very few users who have complained about this, but I think it would be nice to have a solid solution.

@zapta
Copy link
Collaborator Author

zapta commented Nov 14, 2024

@cavearr, with the new apio release, users can add custom boards.json, fpga.json and programmers.json in their project directory. This means that they can use it without changes to apio or its packages. The programmer binary can come either from their path or you can add it to the system tool package. You can also provide them with an example project, either as a zip file or in the examples package.

In other words, you have a good mechanism to provide them a solution, you just need to decide for yourself how much you want to make it official and commit to its maintenance. The is no right answer here, all the options are reasonable, whatever makes sense to you.

BOARDS_JSON, allow_custom=project_scope

@cavearr
Copy link
Member

cavearr commented Nov 15, 2024

@zapta this is very interesting, i'm working on something similar into icestudio, i'm exploring your soluition in deep to merge forces.

I can't finish the tests in windows os, problems for a new Dana today, It has been impossible to move. Tomorrow, in principle, it won't rain and if nothing happens I'll be able to do the tests without a problem, I'll keep you informed.

@zapta
Copy link
Collaborator Author

zapta commented Nov 15, 2024

Thanks @cavearr, whenver it works for you. The goal is to know what driver settings out-of-the-box windows users will need to do, if at all.

@zapta
Copy link
Collaborator Author

zapta commented Nov 26, 2024

Done. Closing.

@zapta zapta closed this as completed Nov 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants