This is what you would need to do to have your board officially supported by OpenWrt:
I hope this helps and your device gets added - the official way!
@psherman - if @gioreva is indeed the [willing] developer of this model of board - I'd ask that you consider re-opening the User's original thread and merging.
Con quale nome vuoi che venga chiamato il tuo dispositivo?
By what name do you wish your device to be called?
To add:
In the most basic scene, the OP should be able to post the DST file into codeboxes. Anyone should then be able to build the image from the development tools located at the target's directory in downloads.openwrt.org
A lot of community members would debate - that definitely means his board is supported here.
I don't disagree with the basic premise of this post, but I'll play devil's advocate. I was under the impression that thread was closed because @gioreva was asking how to debug hardware problems on their custom board. I understand that intermittent hardware problems are notoriously difficult to track down and fix. Especially at gigabit speeds, the PCB layout and assembly process really matters.
But at that regime, @gioreva should be talking to an electrical engineer before a software developer and get the Ethernet hardware working first. I'm sure once that is straightened out we can discuss the device tree and whatnot.
I highly value your opinion and welcome the opposing view with intelligible reasoning advocating it - you bring forth good points if this is still on the issue of base issues at the circuitry level. I merely suggest that the device itself could be supported from inception - and eliminate software as issue (as far as the troubling 30% anomaly with the design allows in this case, of course).
It's also true these devices are generally backed by corporate $$ and profits from previous router sales.
While I would argue that a good few well known models are RMA'ed regularly each year - I don't believe that amounts to 3 out of 10 (30%). I believe that the former funding reduces that ratio to more like 20 or 25% . Go talk to any "Geek Unit" or other kinda stores/companies/service-providers, they have headaches with models, or ones that don't do what the user needs, etc.
Lastly, I think the OP needs OpenWrt official support for the purposes of:
I do not believe we should then go on to the various chip matters ( e.g. the OP mentioned he may have received a bad batch of chips). It's obvious he is higher in the manufacturing stream in order to provide us a supported model from available release date to the general public - but no, he would not get a pass on us fixing his hardware issue...if one exists.
Yet, we advocate for another OpenWrt-OEM'ed device in another Category of the forums.
I realize this chat may just be philosophical now...what is an acceptable [known] failure rate here to be accepted here, even after a promise of a revision 2 of the model (at the OEM's expense - meaning we're not any more inconvenienced in any case)?
EDIT:
I had to indulge good friend to ask - philosophically:
If The OP is [indeed] running OpenWrt compiled from GitHub (claiming only the DST file) - I must ask:
How so is it a black box - and different from a router we use in our homes and businesses running OpenWrt today - or its orginal OEM's fork?
I do agree that it would be great to support a device that is designed from the ground up to run official OpenWrt.
The situation here, as many have noted, appears to be one of hardware related issues which cannot be diagnosed from afar if others don't have devices in hand. Based on the available information (which may admittedly be incomplete on the part of the OP), these statements are true:
I would be happy to allow the OP of the earlier thread to create a new topic in which they could request hardware + firmware assistance. In the thread, they could coordinate with one or more developers who express interest in helping diagnose/debug/fix the issues with the device. In that thread, the OP would need to disclose the status of the device -- i.e. a commercially available product, reference board, prototype, commercial product in active development, etc.).
Assuming that it is not currently commercially available, the expectation would be that the OP would use the new thread (and/or PMs) to arrange for delivery of at least 2 samples of the device -- one working reliably and one that is manifesting the unreliable gigabit link -- to each of the volunteers free of charge (ideally the OP would also pay shipping and any applicable export/import duties if the recipients are located outside the OP's country, but this could be discussed on an individual level with the volunteers). It would be important for the OP to also be aware of any international trade restrictions and/or local regulations that could preclude sending/operating the device in specific regions/countries as to ensure that all the development efforts are compliant with local and international laws.
Additionally, the OP would need to be willing to share (privately with the relevant volunteers) the full codebase in use, schematics, and gerber (PCB layout) files to ensure that the design can be properly understood and debugged.
To be clear, I fully agree that it would be amazing to have more ground-up hardware designs that are built to be supported by OpenWrt. But I firmly believe that, unless the project is actually fully open source, the development efforts should primarily be the responsibility of the entities creating the devices. That's why I said that the devices should be provided free of cost to the volunteer developers willing to assist -- nobody should have to pay for the 'privilege' of providing free assistance to an entity that will be profiting from their work.
The product is on the market.
In fact, I have 4 products on the market.
They are based on two versions.
MT7621D+MT7615 and MT7620A
I'm on my own, I own the company, I design hardware, software, firmware, production, repair.
The quantities are small and the earnings low.
I have no resources to pay external consultants,
Although 30 per cent of the MT7621D boards have problems, the remaining 70 per cent are fine.
By redoing the PCB layout, I will definitely solve the problem in the next batch.
I have already solved the problems on the PCI bus of the previous model.
I only asked for advice on how I could go about tuning the Ethernet.
What commands and what procedure to use.
To save the 30% of boards that don't work.
I would be pleased if my configuration was included among the existing ones. I can share my two .DST and .mk There is no custom firmware, just some .sh to control the leds.
Can you ask a MediaTek engineer for help with the Ethernet portion here? You are their customer, after all. And besides, OpenWrt (or really any Linux distro) is not going to have built-in commands or tuning knobs for that kind of low-level control of the Ethernet PHY.
If that's the case, then feel free to send a patch or a pull request with your device tree files and the Makefile.
Are the LEDs controlled via GPIO on the SoC itself or is there some extra stuff that requires a separate shell script? If it's the former, all you really need is some entries in the device tree and you'd be able to control the LEDs via LuCI.
I wrote dozens of times to Mediatek, they never replied.
I had to get the datasheets and schematics on the black market.
They are horrible people.
I wrote on many forums, but I couldn't find anyone capable of routing a PCI bus, or a DDR or an ethernet.
I did it all myself by trying and failing.
Studying how to make a pull takes time that I don't have right now. I will try to share the files here.
They are normal GPIOs, but none of the functions in OpenWRT meet my needs.
I have three RGB leds.
The WiFi led, I want it to be green if connected to 2.5G and blue if connected to 5G The ETH led, I want it to be green if the lan is 100M and blue if gigalan.
The power led, blynk default, can be changed from script on special case.
. Go talk to any "Geek Unit" or other kinda stores/companies/service-providers, they have headaches with models, or ones that don't do what the user needs, etc.