jdonoghue Posted September 19, 2019 Share Posted September 19, 2019 Previously running a different Linux, I followed the instructions to update the boot loader so I could try Armbian on my Espressobin. The update completed ok, but could no longer read from the SD card. After several hours of frustration, I attempted to revert back to the original boot loader and found I could no longer tftp or update from USB. After several days of frustration, I am near the point of giving up. Here's what happens when I attempt to use the UART rescue found at the Espressobin web site: Marvell>> usb start starting USB... USB0: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1: USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Marvell>> bubt bootloader.bin spi usb Burning U-BOOT image "bootloader.bin" from "usb" to "spi" USB0: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1: USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found Image checksum...OK! SF: unrecognized JEDEC id bytes: c2, 25, 36 Failed to probe SPI Flash exit not allowed from main input shell. Marvell>> I then tried various newer UART rescue images, which all seem to recognize the SPI flash chip but cannot update from USB (yes, I tried various working USB memory sticks...): Marvell>> usb start starting USB... USB0: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1: USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Marvell>> bubt bootloader.bin spi usb Burning U-BOOT image "bootloader.bin" from "usb" to "spi" USB0: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1: USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found BUG: failure at drivers/usb/host/xhci-ring.c:489/abort_td()! BUG! resetting ... > I also tried updating via TFTP. All the UART rescue images I tried give the same result: tftp hangs, like this: Marvell>> setenv serverip 192.168.1.15 Marvell>> setenv ipaddr 192.168.1.12 Marvell>> ping $serverip Using neta@30000 device host 192.168.1.15 is alive Marvell>> bubt bootloader.bin spi tftp Burning U-BOOT image "bootloader.bin" from "tftp" to "spi" Using neta@30000 device TFTP from server 192.168.1.15; our IP address is 192.168.1.12 Filename 'bootloader.bin'. Load address: 0x80000000 Loading: # Has anyone else experienced this problem? I find it hard to believe the board is broken, since it was working fine prior to the first boot loader update. Link to comment Share on other sites More sharing options...
ebin-dev Posted September 20, 2019 Share Posted September 20, 2019 15 hours ago, jdonoghue said: I find it hard to believe the board is broken, since it was working fine prior to the first boot loader update. The UART rescue images to be used are those here (18.12-v2). To be on the safe side, please use the 600_600 or 800_800 images for your board. Did you follow the uart recovery instructions (use miniterm - not minicom etc.) ? Do you use a V7 or a V5_0_1 EspressoBin ? Link to comment Share on other sites More sharing options...
jdonoghue Posted September 20, 2019 Author Share Posted September 20, 2019 This is a V5_0_1 EspressoBin. It's working now with the 600_600 image. It appears the problem was created during pasting the environment into the terminal - after restoring the environment to default, I was able to TFTP without problems. Careful examination showed that when I pasted the environment into the terminal, a few characters are being dropped. After carefully typing it in manually, I was able to get it to boot. Thanks for your help. Link to comment Share on other sites More sharing options...
Recommended Posts