I have compiled and updated u-boot in AI7688 module.
u-boot version: U-Boot 1.1.3
Before updation reset command was working.
I have taken fresh U-boot code from the git link mentioned below
Git Link: https://github.com/AcSiP/linkit-smart-7688-uboot.git
But, now reset command is not working. When i gone through the code in depth then I got the below mentioned code.
#define SOFTRES_REG (RALINK_SYSCTL_BASE + 0x0034)
#define GORESET (0x01)
int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *argv)
*(volatile unsigned int*)(SOFTRES_REG) = GORESET;
I have checked the rigester address its also correct. But, then also reset command is not working.
Can someone please let me knwo how can I make the command work.
Thanks in advance,
Lad Dhawal Umesh
as already stated in your other thread, this isn't openwrt related.
I agreed that it is not OpenWRT issue but we have posted here if someone had faced this type of issues at his or her end.
We have checked that default boot loader is working fine with reset command but when we updated boot loader with compiled boot loader at that time reset is failed to work.
Same issue we have faced after updating sysupgrade image as well like reboot command is not working
Let us know if anyone has faced and resolved that type of issue into current boot loader build.
Doubtfully, because of the reason previously given.
OpenWrt = hardware + bootloader + openwrt firmware.
Although the bootloader not maintained by openwrt team, but it's a very important part of openwrt system also.
Just as important as electricity...
I woud advise restoring the old bootloader. Few OpenWrt devices have instructions that advise a need to manipulate the bootloader.
Also, this thread is a duplicate:
I have OpenWRT based, AI7688 board. I am trying to update firmware(sysupgrade image) into the board using loadb command. But when using cp command in u-boot then its not working.
Also, bootm command is not booting the firmware from the location. Its booting the firmware from the address where the firmware is loaded.
Below are the logs shown the issue occured
U-Boot 1.1.3 for AI7688H-64MB (Feb 16 2017 - 08:19:34)
MT7628 # loadb 0x80a00000 57600
## Ready for binary (kermit) download to…
I'm lost on how this is related to OpenWrt; or better yet, how a duplicate thread helps.
You have the same thing on both sides of an equation.
You are absolutely correct. We assumed that Boot Loader is not part of OpenWRT fully but partially it is part of OpenWRT as without boot loader we can't move further.
Let me know if you have any clue for the same.
Thanks for your prompt response.
I understood your concern. But practially i have posted thread over here to help us if anyone has faced this type of issue while using compiled version of boot loader into AI7688H based modules or chips.
Also I would let you know that AI7688 Update Issue has been resolved from our end and we are able to update boot loader and sysupgrade image successfully from boot loader using loadb command.And that is totally different compare to issue which we have right now posted to get help if anyone has faced it.
Hope you can understand it our concern and query for the same
Let me know if anyone has any clue or any feedback for the boot loader related issue which we are facing.
They're working on commercially sourced hardware and should be talking to their seller.
The OpenWrt community is not a stopgap for crappy or inexistent aftersales of someone's supplier.
... esp for a piece of sw we don't really deal with, the boot loader.
Compiling uboot isn't really all that difficult for the MT7688, even if one just grabbed mainline uboot instead of the preconfigured setup these guys are using, so I am just dying to know what did they mess up to break reset? The curiosity is killing me.
Don't feed the u-boot troll ,)
Always denying me all the fun! Next you tell me chopping people up in the silence of the night is also on the ban-list!
Suggest OP be banned, they posted the same post, word for word, on the Vendor's git page - and got a reply.
I think it's a tad harsh to ask for them to be banned, just because they're looking for help in multiple places.
OpenWrt-forums ain't exactly the most correct one, sure, but trying here is somewhat logical, considering how many of us here do have some programming-experience and may even have dealt with uboot as well.
That’s certainly fair enough, the multiple postings of exactly the same content rubs me up the wrong way, as well as not acknowledging that the vendor had already responded through the correct channel.
But we do support the power supply also in this forum😄
Not to mention what high voltage symbol to use for the wiki warning a while back.
I don’t see the point of banning a question that actually is inside the physical hardcover of the devices we support. If we do that it will come back and hit us.
Firmware dev isn’t that black and white.
We have the support treads of BanIP and AdBlock in this forum also, why do we allow them? They are not OpenWrt.
But they're packages offered by the OpenWrt community.