summaryrefslogtreecommitdiff
path: root/board/ti/am57xx/Makefile
diff options
context:
space:
mode:
authorAlex G <mr.nuke.me@gmail.com>2016-11-08 20:48:44 -0800
committerTom Rini <trini@konsulko.com>2016-11-13 15:54:35 -0500
commitc19a28bc65aa27fe143e3c784d4f2e19e08810bf (patch)
tree100605dfa471550826b38abdaeae7d69da18ac3b /board/ti/am57xx/Makefile
parent4fa72bd3fc7755777be0850a99b91d2efad6740b (diff)
downloadu-boot-imx-c19a28bc65aa27fe143e3c784d4f2e19e08810bf.zip
u-boot-imx-c19a28bc65aa27fe143e3c784d4f2e19e08810bf.tar.gz
u-boot-imx-c19a28bc65aa27fe143e3c784d4f2e19e08810bf.tar.bz2
board: am335x/mux: Do not hang when encountering a bad EEPROM
In most cases, the SPL and u-boot.img will be on the same boot media. Since the SPL was loaded by the boot rom, the pinmux will already have been configured for this media. This, the board will still be able to boot successfully, or at least reach the u-boot console, where more recovery options are available. I've encountered this on a beaglebone black with a corrupted EEPROM. Removing this check allowed the board to boot successfully. I've also seen this on EVM-based boards with an unprogrammed EEPROM. On those boards, for some reason there were no UART messages. This made it look as if the SOC was dead. Remove the hang(), as it is not a fatal error. Also reformat the error message to be clearer as to the cause. The original message made it appear as if the wrong binary was being loaded. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Diffstat (limited to 'board/ti/am57xx/Makefile')
0 files changed, 0 insertions, 0 deletions