Espressobin: rescue instruction for macronix SPI chip

FoodGenius · August 29, 2018

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 192.168.5.5; our IP address is 192.168.5.10
Filename 'espresso/flash-image-1g-2cs-800_800_boot_sd_and_usb.bin'.
Load address: 0x5000000
Loading: ########################################################
2.1 MiB/s
done
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 +++

TIM-1.0
WTMI-armada-17.10.5-34ce216
WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 1.038V

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!!

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

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

DLL TUNING
==============
   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
NOTICE: BL31:

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) 2.28.2.20170706

+++ 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)

FoodGenius · August 30, 2018

A fresh delivered espressobin v5 with uboot from globalscale
boots up with

TIM-1.0
WTMI-armada-17.10.5-bb8f823
WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 1.143V

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!!

QS GATING
=============
Calibration done: cycle = 0x00 tap =0x60
CH0_PHY_RL_Control_CS0_B0[0xC0001180]: 0x00000060
CH0_PHY_RL_Control_CS0_B1[0xC0001184]: 0x00000060

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

DLL TUNING
==============
   DLL 0xc0001050[21:16]: [0,31,18]
   DLL 0xc0001050[29:24]: [4,34,1c]
   DLL 0xc0001054[21:16]: [1,2f,18]
   DLL 0xc0001054[29:24]: [9,34,1e]
   DLL 0xc0001074[21:16]: [0,3f,1f]
   DLL 0xc

NOTICE: BL1: v1.3(release):armada-17.10.3:39a62a1
NOTICE: BL1: Built : 15:39:52, Jun 1 2NOTICE: BL2: v1.3(release):armada-17.10.3:39a62a1
NOTICE: BL2: Built : 15:39:54, Jun 1 2018NOTICE: BL31: v1.3(release):armada-17.10.3:39a62a1
NOTICE: BL31:

U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - 15:39:10 +0800)

Model: Marvell Armada 3720 Community Board ESPRESSOBin
       CPU    @ 1000 [MHz]
       L2     @ 800 [MHz]
       TClock @ 200 [MHz]
       DDR    @ 800 [MHz]
DRAM: 1 GiB
U-Boot DT blob at : 000000003f7161b8
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, sdhci@d8000: 1
SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB
Net:   eth0: neta@30000 [PRIME]
Hit any key to stop autoboot: 0

....

Marvell>> sspi
SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB

so it seems to be an issue in current armbian uboot ?
https://dl.armbian.com/espressobin/u-boot/

not supporting the macronix mx25u3235f ?

ebin-dev · August 30, 2018

I have recompiled the u-boot flash images two days ago (u-boot 17.10.3, atf1.3-17.10.8, A3700utils-17.10.5).

You can download them here. Does this solve the issue ?

Edit: If the recompiled u-boot flash images still do not support the macronix chip on your EspressoBin we will have to wait for Marvell to release the code in their publicly available branch on github.

skandalfo · August 31, 2018

So I got a new espressobin on the mail and flashed the 1200-750 2GB 2cs bootloader following the instructions here. Right, I knew uboot was reporting 1000-800 as the speed, it didn't boot. When I tried to go back via UART recovery, the image from espressobin.net had the issue here and did not recognize the SPI flash.

I had to recompile all following the wiki instructions, but after adding this entry to u-boot/drivers/mtd/spi/spi_flash_ids.c (in the Macronix section):

    {"mx25u3235f",     INFO(0xc22536, 0x0, 64 * 1024,    64, RD_FULL | WR_QPP | SECT_4K) },

Which I copied from the entry for "fw25q32dw" after checking that the datasheets more or less matched.

So it's booting again. I'll see if I can make it work with 1200-750 with the "fix".

skandalfo · August 31, 2018

Update: I had to go back to 1000-800; otherwise I'd get the same as in this report, which is what I got the first time.

BTW what I get during boot is slightly different

SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB

from what was reported here in the stock bootloader

SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB

I think that's because I added the SECT_4K keyword. The datasheet for mx25u3235f says that 4K sector erases are supported anyway, and everything seems to be working fine.

FoodGenius · September 3, 2018

@ebin-dev
I flashed your current armbian uboot

https://dl.armbian.com/espressobin/u-boot/flash-image-1g-2cs-800_800_boot_sd_and_usb.bin

NOTICE: BL1: v1.3(release):armada-17.10.8:34247e0
NOTICE: BL1: Built : 19:00:27, Aug 26 2NOTICE: BL2: v1.3(release):armada-17.10.8:34247e0
NOTICE: BL2: Built : 19:00:27, Aug 26 2018
NNOTICE: BL31: v1.3(release):armada-17.10.8:34247e0

Unfortunately there's still the same error, after resetting the board

Saving Environment to SPI Flash...
SF: unrecognized JEDEC id bytes: c2, 25, 36
*** Warning - spi_flash_probe_bus_cs() failed, using default environment

@skandalfo

so you don't use the armbian uboot binary?
you've compiled your own version and changed
u-boot/drivers/mtd/spi/spi_flash_ids.c ?
an this works? setting SECT_16K instead of SECT_4K ? Like this

 {"mx25u3235f",     INFO(0xc22536, 0x0, 64 * 1024,    64, RD_FULL | WR_QPP | SECT_16K) },

or just ommit the SECT flag like this...

 {"mx25u3235f",     INFO(0xc22536, 0x0, 64 * 1024,    64, RD_FULL | WR_QPP) },

FoodGenius · September 3, 2018

# recovery bootloader espressobin - downloaded from http://espressobin.net/tech-spec/

U-Boot 2017.03-armada-17.10.3-g06ad760 (Jul 18 2018 - 06:31:08 +0000)
aarch64-linux-gnu-gcc (Linaro GCC 5.3-2016.05) 5.3.1 20160412
GNU ld (Linaro_Binutils-2016.05) 2.25.0 Linaro 2016_02
-> SF: unrecognized JEDEC id bytes: c2, 25, 36

# current armbian bootloader

U-Boot 2017.03-armada-17.10.3-g06ad760 (Aug 26 2018 - 19:00:03 +0200)
aarch64-linux-gnu-gcc (Linaro GCC 7.3-2018.05) 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701]
GNU ld (Linaro_Binutils-2018.05) 2.28.2.20170706
-> SF: unrecognized JEDEC id bytes: c2, 25, 36

# current bootloader (preloaded on espressobin boards)

U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - 15:39:10 +0800)
aarch64-linux-gnu-gcc (Linaro GCC 5.2-2015.11-2) 5.2.1 20151005
GNU ld (GNU Binutils) 2.25.0 Linaro 2015_10

-> SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB

ebin-dev · September 3, 2018

2 hours ago, FoodGenius said:

GNU ld (GNU Binutils) 2.25.0 Linaro 2015_10

So using old Linaro 2015_10 for compiling atf may solve the issue. Noted.

Unfortunately compiling atf1.3-17.10 is currently broken - probably due to a recent update of Ubuntu 16.04 default compilers - at least on my system. I will therefore wait for the next series of updates in Marvells public repository on Github.

FoodGenius · September 3, 2018

@ebin-dev

not sure, if this this really solve the issue, since its also a different uboot subversion.
U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - 15:39:10 +0800)
U-Boot 2017.03-armada-17.10.3-g06ad760 (Aug 26 2018 - 19:00:03 +0200)

and... because the current bootloader won't work with recent boards,
there should be a hint at
https://www.armbian.com/espressobin/
so other users won't download the bootloader from there and "brick" their SPI.

Since after flashing to this version, you can't use "bubt" anylonger and have to
recover via sata... which is also still buggy... since the "official sata-recovery image",
mentioned at http://wiki.espressobin.net/tiki-download_file.php?fileId=146
( http://wiki.espressobin.net/tiki-index.php?page=Boot+ESPRESSObin+from+SATA+drive link "here")

is the old one

U-Boot 2015.01-armada-17.02.0-01546-g184fa4e (Apr 20 2017 - 16:21:34)
aarch64-linux-gnu-gcc (Linaro GCC 5.2-2015.11-2) 5.2.1 20151005
GNU ld (GNU Binutils) 2.25.0 Linaro 2015_10

which also won't support Macronix mx25u3235f SPI.
I could not find any usable flash-sata-img recovery file, for using
bubt again. so only recovery via uart and marvell WtpDownload tool seams to
be possible.

skandalfo · September 3, 2018

@FoodGenius

I was trying to explain that I ended up in the same situation as you (couldn't get anything flashed because everything I loaded didn't support the Macronix mx25u3235f flash chip).

I bricked my board by flashing the "wrong speed one" from Armbian. I could not boot to uboot because it wouldn't pass calibration (wrong CPU/DRAM speed). So I tried to recover via UART using these instructions, and the binary bootloader images here.

I managed to upload the binary bootloader to RAM, but it would not be able to flash SPI from USB with anything else because, as you realized, only the version that came pre-flashed knew about the new flash chip.

So I got to these other instructions to compile the bootloader from source. Notice the section that explains that the build also includes the UART recovery images. I managed to build them and upload via UART, and I got the flashable image in USB, but the newly compiled uboot wouldn't know about the flash chip yet.

So I added the entry from my first post to the list of flash chips IDs and recompiled everything (both UART and flashable images). Then the in-RAM uboot received via UART was able to flash the flashable image in USB (both with support for the new flash chip compiled in), and my board came back to life.

It's a pity the manufacturer didn't bother to update their relatively good instructions in the wiki before replacing hardware with a basically incompatible part with no notice.

BTW. You can leave the SECT_4K flag out; it'll just mean that block erases will be at least 64kiB in size rather than 4kiB when possible. The thing is the new chip does support 4kIB erases; I saw just 8k had to be cleared when switching between bootloaders.

Also I saw the armada uboot repo has a version newer than boot-2017.03-armada-17.10. There's a u-boot-2013.01-armada-18.06 branch. I didn't try anything with it as the build instructions that worked required a pair of patches that I didn't want to look into. Also, it looks like that branch is different (w.r.t. flash drivers at least) and it still doesn't support the mx25u3235f anyway.

Hope this helps.

Edited September 3, 2018 by skandalfo
Close parens :-)

skandalfo · September 3, 2018

And, yes, I used the toolchain from here, as suggested by the build instructions, on Ubuntu 18.04.

Igor · September 4, 2018

15 hours ago, FoodGenius said:

there should be a hint at
https://www.armbian.com/espressobin/
so other users won't download the bootloader from there and "brick" their SPI.

Shell I revert last change and leave the previous version (https://dl.armbian.com/espressobin/u-boot/archive/4/) as default until this is resolved?

FoodGenius · September 4, 2018

51 minutes ago, Igor said:

Shell I revert last change and leave the previous version (https://dl.armbian.com/espressobin/u-boot/archive/4/) as default until this is resolved?

this won't solve the problem, since older releases still wont detect macronix SPI - afaik.
As long as the current armbian uboot bootloader can't support the macronix SPI... every user "bricks" his SPI when
flashing it. You have to go a very roundabout way for recovery then to regain access to SPI.

"bricking spi".. i mean... you cant't you bubt anylonger other bootloaders and .. much more important...
you can't save env.... so the mentioned steps at https://www.armbian.com/espressobin/

are not working anymore. You would need a recovery bootloader... and (sadly) espressobin
delivers no out-of-the-box recovery-image currently.

Igor · September 4, 2018

1 minute ago, FoodGenius said:

You would need a recovery bootloader... and (sadly) espressobin delivers no out-of-the-box recovery-image currently.

Got it. I added a link to this thread in the download section.

FoodGenius · September 4, 2018

@skandalfo

thank you for you work. I already build a patched bootloader, but it doesn't work. Will try your mentioned toolchain.

Quote

It's a pity the manufacturer didn't bother to update their relatively good instructions in the wiki before replacing hardware with a basically incompatible part with no notice.

thats right. I also tried to contact the manufacturer. so hopefully they publish a working recovery bootloader... at least...
for those users, that can't quickly build uboot on their own.

skandalfo · September 4, 2018

23 minutes ago, FoodGenius said:

I already build a patched bootloader, but it doesn't work. Will try your mentioned toolchain.

What do you mean with "doesn't work"?

Ihad issues with the upload via minicom (it seemed to do something with the serial port that would make the serial transfer) and had to switch to miniterm.py and set line breaks to just LF before I got wtp activation and serial download to be stable.

Is that what's failing for you?

FoodGenius · September 4, 2018

4 hours ago, skandalfo said:

What do you mean with "doesn't work"?

it won't boot. no output at uart.

Quote

Ihad issues with the upload via minicom (it seemed to do something with the serial port that would make the serial transfer) and had to switch to miniterm.py and set line breaks to just LF before I got wtp activation and serial download to be stable.

Is that what's failing for you?

i use ~~minicom~~ kermit for uart and only setting to wtp. >wtp
then I used the marvell tool for uploading my TIM_ATF.bin and wtmi_h.bin and boot-image_h.bin

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

This is my uboot build-script

#!/bin/bash

# apt-get install device-tree-compiler 

mkdir build_bootloader
cd build_bootloader

# build uboot
mkdir u-boot
cd u-boot/
git clone https://github.com/MarvellEmbeddedProcessors/u-boot-marvell .
git checkout u-boot-2017.03-armada-17.10

patch -l drivers/mtd/spi/spi_flash_ids.c << +++EOF+++ || echo "PATCH FAILED. ABORT"
--- drivers/mtd/spi/spi_flash_ids.c
+++ /dev/stdin
@@ -78,6 +78,7 @@
        {"mx25l1605d",     INFO(0xc22015, 0x0, 64 * 1024,    32, 0) },
        {"mx25l3205d",     INFO(0xc22016, 0x0, 64 * 1024,    64, 0) },
        {"mx25l6405d",     INFO(0xc22017, 0x0, 64 * 1024,   128, 0) },
+       {"mx25u3235f",     INFO(0xc22536, 0x0, 64 * 1024,    64, RD_FULL | WR_QPP) },
        {"mx25l12805",     INFO(0xc22018, 0x0, 64 * 1024,   256, RD_FULL | WR_QPP) },
        {"mx25l25635f",    INFO(0xc22019, 0x0, 64 * 1024,   512, RD_FULL | WR_QPP) },
        {"mx25l51235f",    INFO(0xc2201a, 0x0, 64 * 1024,  1024, RD_FULL | WR_QPP) },
+++EOF+++

export CROSS_COMPILE=aarch64-linux-gnu-
make clean
make mvebu_espressobin-88f3720_defconfig
make DEVICE_TREE=armada-3720-espressobin
export BL33=`pwd`/u-boot.bin
cd ..

# build atf
mkdir atf
cd atf
git clone https://github.com/MarvellEmbeddedProcessors/atf-marvell.git .
git checkout atf-v1.3-armada-17.10
cd ..
mkdir a3700-utils
cd a3700-utils
git clone -b A3700_utils-armada-17.10 https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell.git .
cd ..

# build images
mkdir images

for boot_type in SPINOR SATA
do
cd atf
make clean
make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 CLOCKSPRESET=CPU_800_DDR_800 \
DDR_TOPOLOGY=2 BOOTDEV=${boot_type} PARTNUM=0 WTP=../a3700-utils/ PLAT=a3700 all fip
source_image="build/a3700/debug/flash-image.bin"
target_image="../images/flash-image-${boot_type}.bin"
echo
echo "${source_image} is bootloader for ${boot_type} -> copy to ${target_image}"
cp "${source_image}" "${target_image}"
cd ..
done

echo "uart-images: build/a3700/debug/uart-images/"
echo "uboot: u-boot/u-boot.bin"

cp u-boot/u-boot.bin images/u-boot.bin
cp -r atf/build/a3700/debug/uart-images images/

ls -l images/

then dd the images/flash-image-SATA.bin to an ssd

dd if=build_bootloader/images/flash-image-SATA.bin of=/dev/sdb

and use SATA-Boot-Mode Jumper at espressobin board
But boot hangs at TIM.

Connecting to /dev/ttyUSB0, speed 115200
 Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------
TIM-1.0

after a while, it drops to fallback

Connecting to /dev/ttyUSB0, speed 115200
 Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------
TIM-1.0
>
E
>

perhaps there's something wrong in my build-process.
could you provide your build process steps?

since tftp still works in spi-broken uboot, it could also be possible to boot a initramfs kernel via tftp an recover spi
with tools like spidev_flash from userspace... https://www.kernel.org/doc/Documentation/spi/spidev

I'll give a try.

ebin-dev · September 4, 2018

I am currently testing new 18.09 flash images (thanks to Kosta):

TIM-1.0
WTMI-devel-18.07.0-6050fd5
WTMI: system early-init
CPU VDD voltage default value: 1.155V
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v1.5(release):711ecd3 (Marvell-armada-18.09.4)
NOTICE: BL1: Built : 14:00:41, Sep 4 2018
NOTICE: BL1: Booting BL2
NOTICE: BL2: v1.5(release):711ecd3 (Marvell-armada-18.09.4)
NOTICE: BL2: Built : 14:00:41, Sep 4 2018
NOTICE: BL1: Booting BL31
NOTICE: BL31: v1.5(release):711ecd3 (Marvell-armada-18.09.4)
NOTICE: BL31: Built : 14:0

U-Boot 2018.03-armada-18.09.1-g8fe4031-armbian (Sep 04 2018 - 14:00:03 +0200)

Model: Marvell Armada 3720 Community Board ESPRESSOBin
CPU @ 1000 [MHz]
L2 @ 800 [MHz]
TClock @ 200 [MHz]
DDR @ 800 [MHz]
DRAM: 512 MiB
Comphy chip #0:
Comphy-0: USB3 5 Gbps
Comphy-1: PEX0 2.5 Gbps
Comphy-2: SATA0 6 Gbps
Target spinup took 0 ms.
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:
Loading Environment from SPI Flash... SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Marvell Armada 3720 Community Board ESPRESSOBin
Net: eth0: neta@30000 [PRIME]
Hit any key to stop autoboot: 0

FoodGenius · September 4, 2018

@ebin-dev
could you please check if your new binary has references to Macronix mx25u3235f ?

strings image-file.bin | grep mx25u3235f

ebin-dev · September 4, 2018

@FoodGenius I still have to get it running (erase the old environment etc.). Will be available here if everything is fine.

ebin-dev · September 4, 2018

46 minutes ago, FoodGenius said:

could you please check if your new binary has references to Macronix mx25u3235f ?

$ strings flash-image-1g-2cs-1000_800_boot_sd_and_usb.bin | grep mx25u3235f
-> no references found.

FoodGenius · September 4, 2018

2 minutes ago, ebin-dev said:

$ strings flash-image-1g-2cs-1000_800_boot_sd_and_usb.bin | grep mx25u3235f
-> no references found.

so it won't work i think.

give a try to

strings flash-image-1g-2cs-1000_800_boot_sd_and_usb.bin | grep mx25

other macronix SPI should get listet

mx25l25635f, mx25l51235f ...

but since the current boards uses a mx25u3235f , the current bootloader would not solve the problem.

ebin-dev · September 4, 2018

1 hour ago, FoodGenius said:

other macronix SPI should get listet

$ strings flash-image-1g-2cs-1000_800_boot_sd_and_usb.bin | grep mx25
mx25l2006e
mx25l4005
mx25l8005
mx25l1605d
mx25l3205d
mx25l6405d
mx25l12805
mx25l25635f
mx25l51235f
mx25u6435f
mx25l12855e
mx25u1635e

ebin-dev · September 5, 2018

The new 18.09 u-boot flash-images are available for download now.

The environment must be reset to default values:

Marvell>> env default -a

Marvell>> saveenv

and the environment settings as shown on the EspressoBin Download page should be used.

FoodGenius · September 5, 2018

1 hour ago, ebin-dev said:

The new 18.09 u-boot flash-images are available for download now.

The environment must be reset to default values:

Marvell>> env default -a

Marvell>> saveenv

and the environment settings as shown on the EspressoBin Download page should be used.

there is still missing flash-image-1g-2cs-800_800_boot_sd_and_usb.bin ?

kostap · September 5, 2018

Quote

then dd the images/flash-image-SATA.bin to an ssd

dd if=build_bootloader/images/flash-image-SATA.bin of=/dev/sdb

and use SATA-Boot-Mode Jumper at espressobin board
But boot hangs at TIM.

Do not copy your boot image to offset 0 of SATA device. The BootROM will look for the boot image on LBA1 and then on LBA34. This is done for keeping the MBR and/or GPT intact, so besides booting from disk you can use it as a root FS.

Edited September 5, 2018 by kostap

ebin-dev · September 5, 2018

On 9/5/2018 at 9:07 AM, FoodGenius said:

there is still missing flash-image-1g-2cs-800_800_boot_sd_and_usb.bin ?

A file got overwritten accidentally.

I have therefore just recompiled the images for the 1g-2cs EspressoBin.

You can download all of them here.

The firmware is working - remember the environment needs a reset.

There may be further changes necessary in Armbian to boot the OS.

FoodGenius · September 5, 2018

12 minutes ago, ebin-dev said:

A file got overwritten accidentally.

I have therefore just recompiled the images for the 1g-2cs EspressoBin.

You can download all of them here.

The firmware is working - remember the environment needs a reset.

There may be further changes necessary in Armbian to boot the OS.

thank you.

is there a reason for the difference between filesizes?

860K Sep 4 14:00 flash-image-1g-1cs-1000_800_boot_sd_and_usb.bin
860K Sep 4 14:00 flash-image-1g-1cs-1200_750_boot_sd_and_usb.bin
860K Sep 4 14:00 flash-image-1g-1cs-600_600_boot_sd_and_usb.bin
860K Sep 4 14:00 flash-image-1g-1cs-800_800_boot_sd_and_usb.bin
860K Sep 5 09:36 flash-image-1g-2cs-1000_800_boot_sd_and_usb.bin
860K Sep 5 09:36 flash-image-1g-2cs-1200_750_boot_sd_and_usb.bin
860K Sep 5 09:36 flash-image-1g-2cs-600_600_boot_sd_and_usb.bin
860K Sep 4 14:01 flash-image-2g-2cs-1000_800_boot_sd_and_usb.bin
860K Sep 4 14:01 flash-image-2g-2cs-1200_750_boot_sd_and_usb.bin
860K Sep 4 14:01 flash-image-2g-2cs-600_600_boot_sd_and_usb.bin
860K Sep 4 14:00 flash-image-512m-2cs-1000_800_boot_sd_and_usb.bin
860K Sep 4 14:00 flash-image-512m-2cs-1200_750_boot_sd_and_usb.bin
860K Sep 4 14:00 flash-image-512m-2cs-600_600_boot_sd_and_usb.bin
860K Sep 4 14:00 flash-image-512m-2cs-800_800_boot_sd_and_usb.bin
732K Sep 5 09:36 flash-image-1g-2cs-800_800_boot_sd_and_usb.bin
732K Sep 4 14:01 flash-image-2g-2cs-800_800_boot_sd_and_usb.bin

FoodGenius · September 5, 2018

your new image flash-image-1g-2cs-800_800_boot_sd_and_usb.bin
is unfortunately not working after flashing to current board. Getting no Marvell prompt.


Connecting to /dev/ttyUSB0, speed 115200
 Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.
----------------------------------------------------
TIM-1.0
WTMI-devel-18.07.0-6050fd5
WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 1.062V
+++hangs here+++

ebin-dev · September 5, 2018

On 9/5/2018 at 10:09 AM, FoodGenius said:

is there a reason for the difference between filesizes?

If I am compiling all of the images in one go and in parallel - indeed this time the file size of one or two images differ - I haven't noticed that.

This would appear to be an effect of the compilers and/or OS used and could simply be avoided by compiling the images in sets of 4 - without any other changes.

You can find the current images here. The 1g-2cs images are confirmed to be working.

I have changed by build scripts so that this does not happen anymore. Sorry for the inconvenience.

Sign In

Espressobin: rescue instruction for macronix SPI chip

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Similar Content

Important Information