I am a firmware developer worked on Microcontorllers. This is the start of my journey in to developing device drivers for Microprocessors, in this case the Mediatek MT7621AT. I have been provided with a VoIP based router which needs few tweaks. In my initial approach I was under the impression that I would get all the information from the Manufacturer's site, with this I mean the development toolchain information but I couldn't even get he datasheet for the Microprocessor mentioned above from their site. Upon digging furhter I stumbled upon various git repos and scribd data where I could stitch up a decent collection of technical information.
Current hardware Configuratons:
MT7621AT
WINBOND DDR3L SDRAM W632GU6NB - 128 MB
WINBOND SPI FLASH W632GU6NB - 16MB
Skyworks ProSLIC Si3217x-C (Used for VoIP ???)
There is a serial UART header which is clocked at 115200 baudrate. I could sniff the logs through this. I could enter the bootloader section as well by entering the command line interface.
Apart from this I could telnet using 192.168.1.1 but I couldn't make any changes to the files found in the rootfs.
From the binaries I could extract some filesystem related data using binwalk. I tried to repackage the firmware "as is" without making any changes but failed to load it up onto the hardware. It would either prompt bad checksum or bad magic number. I have checked the binaries for inconsistencies and noticed issues with padding bytes which was fixed later but inspite of that it failed.
The compression formats being used were lzma and squashfs.
Please advice an approach if I were to build this from ground up, what would be a good path.
Would I need a programmer/debugger? If yes which one?
How should I get started? (Any blinky LEDs)
Any well documented SDKs which could help me access the latest toolchain?
If I had to maintain the same version and make edits to the existing firmware, how should I go about the same?
We can't and won't provide support for Mediatek's proprietary SDK, that's up to you and your company contacts.
In terms of OpenWrt support, this should be relatively easy to port, as all mt7621 targets are relatively similar. 16 MB flash is rather limited, with an expectation to do VoIP (asterisk and friends are large) and 128 RAM is not plenty. With the FXS/ ATA functionality you'd be starting development from zero (some lantiq vr9 targets have FXS support via asterisk and chan_lantiq), there is no support for Mediatek's VoIP hardware, yet.
It appears you are using firmware that is not from the official OpenWrt project.
When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.
Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).
If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.
What if I plan to flash my device with OpenWRT what are the steps I need to follow?
I am using Flying Voice G504/8 device.
Do I need a schematics for the pin interfaced between the CPU, RAM and SPI_Flash?
Based on what I read from the datasheets, I am under the impression that the pin outs would be default for these lines. I am not sure how to fetch the GPIO lines which are connected to the LEDs though, was wondering if these would be default as well.
As requested I have attached the firmware extracted files here.
Do you have serial access to the boot-loader shell interface?
Then you can easily RAM-TFTP-load images from other supported MT7621 devices, taking note, which one fails where.
Then you can make a DTS file for your board based on your findings from the previous steps, edit the Makefile to include an entry for your board alongside the other MT7621 boards.
Forget about the VOIP part. Unless your supplier can cough up the source for a mainline linux kernel driver for that VOIP peripheral, that you could then backport to the 6.6.xy kernel Openwrt currently uses.
@stragies for the moment I can ignore the VoIP part.
I do have access to load the image to the RAM using TFTP, I have done this before but failed. Il give it a shot once again.
My only concern is the pin mapping. Do I need to know the pinouts for the RAM and SPI_Flash? I noticed the chip select pins were fixed in this case. The Ram interfacing seemed parallel.
I wouldn't mind ignoring the LEDs for now. I have already bricked one device as of now, can't afford to brick another one.
In my firmware where could I locate the pin mappings for my hardware?
In the bootloader menu, select '4', then type 'help' or '?' to hopefully get a list of possible commands built-in. None of the other options are the desired "TFTP-to-RAM-Then-Boot-From-Ram-without-touching-flash option we are looking for.
try to find a version command or something like that. u-boot also has a bunch of 'information' style commands available.
Post a complete serial bootup log in text form, not as a picture.
Up to and including you navigating into the menu #4, and issueing 'help' and '?'.
Whats the serial output of the bricked one? Do you know what JTAG is? Does your board have pins for that? Are there pictures available of the insides of the device?
Read through the links posted in the last message by @slh, Google/Wikipedia/stackexchange common terminology. DTS is a device description file, so "what chip is connected where with what settings/interface"
Look at/compare the DTS files in the openwrt source for the mt7621 subtarget.
The VOIP part will most likely never working during the expected remaining livetime of the device, if you run Openwrt on it, unless there is already a preexisting mainline linux kernel driver+user-space for that part.
