Jump to content
  • 0

Espressobin: rescue instruction for macronix SPI chip



Hi. I've ordererd a new bunch of espresso bins from globalscale.
they have the same board revision as my old ones (V5_0_1 and 1G 2CS) - but now I get an error while trying to flash armbian uboot (mentioned in https://www.armbian.com/espressobin/)


Marvell>> bubt espresso/flash-image-1g-2cs-800_800_boot_sd_and_usb.bin spi tftp                                          
Burning U-BOOT image "espresso/flash-image-1g-2cs-800_800_boot_sd_and_usb.bin" from "tftp" to "spi"
Using neta@30000 device
TFTP from server; our IP address is
Filename 'espresso/flash-image-1g-2cs-800_800_boot_sd_and_usb.bin'.
Load address: 0x5000000
Loading: ########################################################
         2.1 MiB/s
Bytes transferred = 819136 (c7fc0 hex)
Image checksum...OK!
SF: unrecognized JEDEC id bytes: c2, 25, 36
Failed to probe SPI Flash


some months ago I've ordered a bunch of espresso bins and I could flash uboot without any problems.

I tried to flash two different boards out of the new order... both failed with this message.

same thing, if I try to flash from usb stick instead of tftp.

Has anyone else encountered this issue? Any idea how to fix it?

Thanks in advance.



+++ bootup of the currently shipped espresso bins after trying to flash the armbian uboot +++


WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 1.038V

Fill memory before self refresh...done

Fill memory before self refresh...done

Now in Self-refresh Mode
Restore termination values to original values
Exited self-refresh ...

Self refresh Pass.
DDR self test mode test done!!

Self refresh Pass.
DDR self test mode test done!!

Calibration done: cycle = 0x00 tap =0x5B
CH0_PHY_RL_Control_CS0_B0[0xC0001180]: 0x0000005B
CH0_PHY_RL_Control_CS0_B1[0xC0001184]: 0x0000005B

Calibration done: cycle = 0x00 tap =0x5C
CH0_PHY_RL_Control_CS1_B0[0xC00011A4]: 0x0000005C
CH0_PHY_RL_Control_CS1_B1[0xC00011A8]: 0x0000005C

   DLL 0xc0001050[21:16]: [0,2b,15]
   DLL 0xc0001050[29:24]: [8,33,1d]
   DLL 0xc0001054[21:16]: [0,23,11]
   DLL 0xc0001054[29:24]: [8,2d,1a]
   DLL 0xc0001074[21:16]: [0,3f,1f]
   DLL 0xc0001074NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.3(release):armada-17.10.8:34247e0
NOTICE:  BL1: Built : 16:46:13, May 10 2NOTICE:  BL2: v1.3(release):armada-17.10.8:34247e0
NOTICE:  BL2: Built : 16:46:13, May 10 2018
NNOTICE:  BL31: v1.3(release):armada-17.10.8:34247e0

U-Boot 2017.03-armada-17.10.3-g06ad760-armbian (May 10 2018 - 16:45:48 +0200)

Model: Marvell Armada 3720 Community Board ESPRESSOBin
       CPU    @ 800 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 800 [MHz]
DRAM:  1 GiB
U-Boot DT blob at : 000000003f7182d8
Comphy-0: USB3          5 Gbps    
Comphy-1: PEX0          2.5 Gbps  
Comphy-2: SATA0         6 Gbps    
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs
PCIE-0: Link down
MMC:   sdhci@d0000: 0
SF: unrecognized JEDEC id bytes: c2, 25, 36
*** Warning - spi_flash_probe() failed, using default environment

Net:   eth0: neta@30000 [PRIME]
Hit any key to stop autoboot:  0

Marvell>>  bdinfo
arch_number = 0x00000000
boot_params = 0x00000100
DRAM bank   = 0x00000000
-> start    = 0x00000000
-> size     = 0x40000000
baudrate    = 115200 bps
TLB addr    = 0x3FFF0000
relocaddr   = 0x3FF2B000
reloc off   = 0x3FF2B000
irq_sp      = 0x3F7182C0
sp start    = 0x3F7182C0
Early malloc usage: 220 / 2000

Marvell>> sspi
SF: unrecognized JEDEC id bytes: c2, 25, 36


Marvell>> version

U-Boot 2017.03-armada-17.10.3-g06ad760-armbian (May 10 2018 - 16:45:48 +0200)
aarch64-linux-gnu-gcc (Linaro GCC 7.2-2017.11) 7.2.1 20171011
GNU ld (Linaro_Binutils-2017.11)


+++ Furthermore... +++


According to JEP106AW Jul 2018  (https://www.jedec.org/standards-documents/docs/jep-106ab#)
the JEDEC id byte c2... means  Macronix


An indeed...

The old boards use a Winbond 25Q32 FWS10 152  -> SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
The new ones use a Macronix MXIC MX 25V3 2311 ->  SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB

(images attached)



Link to comment
Share on other sites

Recommended Posts

  • 0
6 hours ago, Igor said:

BTW. I received a new board today but it still has Winbond flash. It was also mentioned that it will be probably a 4G model, but it's 1G. Basically, it is the same model that I already have with some changes to PCB which need to be inspected.


So it is a system still with two ddr ram chips - and it comes with a huge heat sink :-)) .


Link to comment
Share on other sites

Search Before Posting!

  • 0
On 9/25/2018 at 1:51 PM, Igor said:

Do we have some quick sum of how to use them?


Along the lines of the summary provided by FoodGenius, recovery with these UART images should work like this:


* jumper your board to "UART-Bootmode"
* use a terminal and connect to espressobin by usb
* you now see the recovery prompt ">" instead of "Marvell>>"

  so type the command


followed by enter. board is now in a mode to receive the temporary bootloader.. so close the terminal.

*  use the marvell tool to flash the UART recovery images to RAM
./WtpDownload_linux -P UART -C 0 -R 115200 -B TIM_ATF.bin -I wtmi_h.bin -I boot-image_h.bin -E

* reset the board.

Link to comment
Share on other sites

  • 0
14 hours ago, ebin-dev said:

./WtpDownload_linux -P UART -C 0 -R 115200 -B TIM_ATF.bin -I wtmi_h.bin -I boot-image_h.bin -E

* reset the board.


Not enough. The recovery image is loaded to RAM only, so when you reset it goes away and you boot again from a borked image once jumpers are back to normal.


What you need to do is use the image in RAM you just booted from to flash a good one to SPI.


After WtpDownload finishes, going back to the serial terminal and pressing enter a couple of times should give you a working uboot prompt (with your UART image that now can write to your flash). From there you should be able to use the bubt command like explained here, or some other of the commands in that page to make your changes permanent.

Link to comment
Share on other sites

  • 0

So, I just checked that I could use the images in this folder to flash the current ones in its grand-parent one, and that I still was able to boot from the Armbian already installed in my SD card with a Macronix chip. Thanks a lot for these fixed images! 



  1. Had to use miniterm:
    miniterm --eol CR /dev/ttyUSB0 115200
    rather than minicom. Minicom would interfere with the transfer from WtpDownload by trying to reopen the serial port once it had lost it; and then WtpDownload_linux would get interrupted.
  2. Set the jumpers for UART recovery and powered the board.
  3. In miniterm I hit enter until I got the E prompt, then entered "wtp".
  4. Then I ran the upload: 
    <path>/<to>/WtpDownload_linux -P UART -C 0 -R 115200 -B TIM_ATF.bin -I wtmi_h.bin -I boot-image_h.bin -E


  5. As my bootable SD card was in, the just-downloaded bootloader in RAM would quickly go and start Linux from the SD card. If your EspressoBIN is borked, you probably should just remove any boot device. In my case I didn't bother; I just restarted miniterm quickly after WtpDownload had finished and pressed enter a number of times to interrupt the boot sequence.

  6. I plugged in a USB stick with flash-image-2g-2cs-1000_800.bin in it.

  7. I flashed it to SPI:

    Marvell>> bubt flash-image-2g-2cs-1000_800.bin spi usb
    Burning U-BOOT image "flash-image-2g-2cs-1000_800.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... 1 USB Device(s) found
    scanning bus 1 for devices... 2 USB Device(s) found
    reading flash-image-2g-2cs-1000_800.bin
    Image checksum...OK!
    SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB
    Updating, 8% 126859 B/s   
    Updating, 16% 127704 B/s   
    Updating, 31% 167458 B/s   
    Updating, 39% 155994 B/s
    262144 bytes written, 593344 bytes skipped in 2.249s, speed 389342 B/s
  8. I then powered the board off, switched the boot jumpers back to their default position, and powered it on again. The board booted Armbian from SD card as usual.


Link to comment
Share on other sites

This topic is now closed to further replies.

  • Create New...