While the Linkit Smart has an MX25 series flash chip, the AI7688H appears to use a W25Q256FV.
The AI7688H straps the MT7688 to operate in the new 4-byte addressing mode needed for large chips, and U-Boot talks to it in that mode as well.
But whoever wrote the U-Boot code for the W25Q256FV was excessively polite - after each access in 4-byte mode, it considerately sets it back to legacy 3-byte mode.
What happens then is that if you do either a hardware or software reset after U-Boot has been talking to the flash, then the MT7688 will reset and start trying to read the flash contents using 4-byte addressing, but the flash chip is still in a mode to want 3-byte addresses. Hence it starts providing data during the last byte of the address, the image therefore ends up in RAM is shifted by a byte and unusable, and it goes into a persistent loop. There's no visible output (to a user or serial terminal it just seems dead), but a scope will reveal the endless SPI traffic and a logic analyzer the addressing size mismatch issue.
I was ably to crudely hack up U-Boot to make it decline to exit 4-byte mode when it is talking to something that might be a WQ256FV - now both hardware and software resets work from within U-Boot.
uboot-ai7688h-resetfix.patch (518 Bytes)
I want to stress that the attached is a crude temporary fix; probably the right thing to do is to first determine with confidence that the flash chip is a W25Q256FV, then read its persistent register that sets power-on addressing width, and base the decision to set the mode back on that, so that other chips (or potentially even other ways of configuring a system with the W25Q256FV) are not adversely impacted.
Interestingly, it seemed that if you let the board boot all the way to Linux, reset would start working again - I guess the Linux build is configured to use the chip in 4-byte mode and leave it there.
While ai7688h's had been shipping with what appeard to be a linkit smart u-boot, acsip now has their own u-boot repository at https://github.com/AcSiP/linkit-smart-7688-uboot which seems to include an attempt to deal with this issue
There has also been some related work on the Linux MTD driver, apparently in some configurations it can put a large flash chip into a boot-incompatible mode, but that generally appears to be an issue with systems strapped to expect 3-byte mode at boot; the AI7688H appears to expect 4-byte mode.