FoodGenius

as a quick and dirty workaround... without rebuilding the bootloader images.... i fiddle with uboot "switch" command switch phy_write 1 0 0 0xffff to disable the ports at boot, just by prepending to bootcmd variable. so even if there is no microsd card available or filesystem or kernel image is corrupt, the ports gets deactivated and no traffic ist forwarded. so you can use setenv bootcmd 'switch phy_write 1 0 0 0xffff;for target in ${boot_targets}; do run bootcmd_${target}; done' but the "2 seconds timeout prompt" is still there, so you have a small window of 2-3 seconds at boot time, where lan/wan still gets forwarded/bridged.... and if uboot itself hangs (memory timing or instability of powersource ).. there is still the problem of forwarding traffic until manually triggered hard reset or shutdown. also if you enter the uboot console, switch forwarding is still active. so your first command in console should be. switch phy_write 1 0 0 0xffff if you dont won't to set wan port down, use 2 or 3 for the lan0 and lan1. switch phy_write 1 0 0 0xffff -> WAN switch phy_write 2 0 0 0xffff -> LAN0 switch phy_write 3 0 0 0xffff -> LAN1 Update: @Igor perhaps you want to mention this alternative bootcmd var at the current armbian infopage? https://www.armbian.com/espressobin/

can somebody confirm this problem? in the year 2017 someone mentioned in http://espressobin.net/forums/topic/boot-behavior-of-the-switch-and-security/ some security concerns with older uboot bootloaders and port-mask setting in armada-3720-espressobin.dts(i) this seems still to be the case in the current released armbian bootloaders found in https://dl.armbian.com/espressobin/u-boot/ WTMI-devel-18.12.1-e6bb176 U-Boot 2018.03-devel-18.12.3-gc9aa92c-armbian (Feb 20 2019 - 09:45:04 +0100) since they also seem to use port-mask = <0xf> instead of the suggested port-mask = <0x3> ?! https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2018.03-armada-18.12/arch/arm/dts/armada-3720-espressobin.dts#L55 this means... as soon as ESPRESSOBin board (revision v5 and v7) gets powered up, you will see that u-boot is still initialising the switch chipset to forward traffic. u-boot sets the topaz switch chipsatz portmask in a way that the board is in "full switch mode" and all ports are bridged. security concers: * at every "normal" reboot you have bridged the ports for some seconds, until armbian final loads the linux kernel, newer dtb and module mv88e6xxx. * but furthermore... if you stop autoboot manually, or if your boot fails for any reason (boot-medium has a corrupt filesystem).. you will run into the serious problem, that you're stuck in the Marvell Uboot Console, which is default forwarding all traffic... and so you LAN and WAN ports are bridged all the time. the switch chipset seems to have bootstrap pins which allows at least 3 different configurations: 1. start with forwarding enabled 2. start with forwarding disabled 3. fetch configuration from EEPROM as mentioned in espressobin forum, the RGE_RXD3 has a pull down and tis should prevent traffic flow at reset/power up by default.. .... but u-boot is (re)enabling the forward again. So it seems, that all uboot images for espressobin should have the setting with disabled lan ports and just use wan port per default. how to fix?

fine. thanks. would be nice to publish these images in https://dl.armbian.com/espressobin/u-boot/ in a subfolder "rescue".

this is for everyone, who "bricked" a board by flashing old or testing bootloader, that can't reflash from uboot, because macronix SPI is not detected or uboot won't answer at all. I revived the board this way: * use the old UART recovery images from globalscale (even if they don't detect macronix SPI NOR Flash) so download them from http://espressobin.net/wp-content/uploads/2018/07/ebin-17.10-uart.zip unfortunately globalscale still won't provide newer image. following these instructions http://wiki.espressobin.net/tiki-index.php?page=Bootloader+recovery+via+UART in short... * 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 wtp 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 * do not reset the board now. just start the terminal again to connect to espressobin by usb * you should see the prompt "Marvell>>" now and can use the command "version" to show uboot version. * now we are able to boot a linux kernel I build a small kernel, with patches from skandalfo. so this kernel can access macronix SPI and you can reflash the SPI from userspace, instead from uboot. this is my kernel build process mkdir espresso_rescue_kernel_build cd espresso_rescue_kernel_build # get kernelsource wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.18.7.tar.xz tar xvf linux-4.18.7.tar.xz # patch kernel wget https://download.foodgenius.de/data/patches/espressobin/201809/armada-3720-espressobin.dts.patch wget https://download.foodgenius.de/data/patches/espressobin/201809/spi-nor.c.patch patch linux-4.18.7/arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts < armada-3720-espressobin.dts.patch patch linux-4.18.7/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c < spi-nor.c.patch # you can you espressobin kernel default config wget https://raw.githubusercontent.com/MarvellEmbeddedProcessors/linux-marvell/linux-4.14.22-armada-18.09/arch/arm64/configs/mvebu_v8_lsp_defconfig cp mvebu_v8_lsp_defconfig linux-4.18.7/arch/arm64/configs/ # .... but we need a rootfs, and i build it as initramfs in the kernel # download my modified config with initramfs (path ../initramfs in config and user_id mapping = 1000 to 0. change this!) wget https://download.foodgenius.de/data/patches/espressobin/201809/kernel_config # since user_id mapping for initramfs is 1000 to 0, you have to change this to your current userid (user for build process) in the kernel_config file. so do this... sed -i "s/CONFIG_INITRAMFS_ROOT_UID=1000/CONFIG_INITRAMFS_ROOT_UID=`id -u`/g" kernel_config sed -i "s/CONFIG_INITRAMFS_ROOT_UID=1000/CONFIG_INITRAMFS_ROOT_GID=`id -g`/g" kernel_config # use the kernel_config for your kernel def config cp kernel_config linux-4.18.7/arch/arm64/configs/mvebu_v8_lsp_defconfig # you can download my initramfs, but also can build your own (with buildroot) wget https://download.foodgenius.de/data/patches/espressobin/201809/initramfs.tar.gz tar xvfz initramfs.tar.gz # build_kernel now cd linux-4.18.7/ export ARCH=arm64 export CROSS_COMPILE=aarch64-linux-gnu- make mvebu_v8_lsp_defconfig make -j4 # you have to run a tftp-hpa on your machine for tftp boot # you will find more information in https://help.ubuntu.com/community/TFTP # so i am assuming you have tftpd-hpa up and running. base path /srv/tftp/ mkdir /srv/tftp/espresso_recovery # copy new kernel and dts to tftp path on my machine cp arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtb /srv/tftp/espresso_recovery/ cp arch/arm64/boot/Image /srv/tftp/espresso_recovery/ (+++ additionally ++++ # if you want to download and extract buildroot source wget https://buildroot.org/downloads/buildroot-2018.08.tar.gz tar xvfz buildroot-2018.08.tar.gz # buildroot default config https://raw.githubusercontent.com/MarvellEmbeddedProcessors/buildroot-marvell/buildroot-2015.11-16.08/configs/mvebu_armv8_le_defconfig cp mvebu_armv8_le_defconfig buildroot-2018.08/configs/ # build buildroot cd buildroot-2018.08 make mvebu_armv8_le_defconfig make menuconfig #you have to rebuild your kernel then) but i didn't use full buildroot. just uses busybox and a handmade minimal init script in the initramfs of the kernel #!/bin/busybox sh /bin/busybox --install /bin/ mount -t proc none /proc mount -t sysfs none /sys mknod /dev/sda b 8 0 mknod /dev/sda1 b 8 1 mknod /dev/mtd0 c 90 0 /bin/busybox/sh then i boot my new kernel via tftp and this environment. my tftpd machine had 192.168.5.5 ... you have to change this in your setting setenv default -a setenv baudrate '115200' setenv bootdelay 2 setenv ethact 'neta@30000' setenv ethaddr '00:51:82:11:22:00' setenv ethprime 'eth0' setenv fdt_addr '0x4f00000' setenv fdt_high '0xffffffffffffffff' setenv get_images 'tftpboot $kernel_addr $image_name; tftpboot $fdt_addr $fdt_name; run get_ramfs' setenv get_ramfs 'if test "${ramfs_name}" != "-"; then setenv ramfs_addr 0x8000000; tftpboot $ramfs_addr $ramfs_name; else setenv ramfs_addr -;fi' setenv set_bootargs 'setenv bootargs $console $root ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:none' setenv bootcmd 'run get_images; run set_bootargs; booti $kernel_addr $ramfs_addr $fdt_addr' setenv hostname 'marvell' setenv initrd_addr '0xa00000' setenv initrd_size '0x2000000' setenv kernel_addr '0x8000000' setenv fdt_addr '0x7000000' setenv loadaddr '0x8000000' setenv ramfs_addr '0x9000000' setenv ramfs_name - setenv netdev 'eth0' setenv netmask '255.255.255.0' setenv stderr 'serial@12000' setenv stdin 'serial@12000' setenv stdout 'serial@12000' setenv serverip '192.168.5.5' setenv gatewayip '192.168.5.250' setenv ipaddr '192.168.5.10' setenv image_name 'espresso_recovery/Image' setenv fdt_name 'espresso_recovery/armada-3720-espressobin.dtb' setenv root '' setenv console 'console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000' dhcp boot so now you should boot into the kernel download https://download.foodgenius.de/data/patches/espressobin/201809/mtd0.img.gz this file is a compressed dump of the uboot, supporting macronix spi. unpack it and copy the uncompressed(!) img to a usb stick (assuming partitioned usb stick, partition 1) connect the usb-stick with to your espresso board. run the following commands in the rescue kernel linux, to flash SPI from userspace # connect usb stick mkdir -p /mnt/a mount /dev/sda1 /mnt/a cd /mnt/a # dd image from usb stick to nor flash dd if=mtd0.img of=/dev/mtd0 cd / umount /mnt/a now you can reset the board. the current uboot should support macronix spi. test in "Marvell>> " prompt with version sspi so you can use https://www.armbian.com/espressobin/ bubt flash-image-MEM-RAM_CHIPS-CPU_DDR_boot_sd_and_usb.bin spi usb or any other image and environment

I'm currently using this Image kostap-flash-image-espressobin-1g-2cs-1000_800_v2017.bin a predecessor of flash-images-18.09/flash-image-1g-2cs-1000_800_boot_sd_and_usb.bin out of https://www.dropbox.com/s/sn8bafe250s8r2c/flash-images-18.09.tar.gz?dl=1 which was also provided by kostap. Marvell>> version U-Boot 2017.03-devel-18.09.0-00814-g09e03ea-dirty (Sep 05 2018 - 16:45:31 +0300) 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 and modified env to boot armbian from mmc. still not sure about the address ranges, but until now it runs stable. will do some further testing. setenv default -a setenv verbosity "2" setenv boot_interface mmc setenv image_name boot/Image setenv initrd_image "boot/uInitrd" setenv fdt_name boot/dtb/marvell/armada-3720-community.dtb setenv fdt_high "0xffffffffffffffff" setenv rootdev "/dev/mmcblk0p1" setenv rootfstype "ext4" setenv initrd_addr "0x1100000" setenv usbstoragequirks "0x2537:0x1066:u,0x2537:0x1068:u" setenv fdt_addr "0x6000000" setenv kernel_addr "0x7000000" setenv loadaddr "0x8000000" setenv initrd_size "0x2000000" setenv bootcmd 'mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $initrd_addr $initrd_image; ext4load mmc 0:1 $fdt_addr $fdt_name; setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr' setenv ethaddr F0:AD:4E:..... setenv eth1addr F0:AD:4E:..... setenv eth2addr F0:AD:4E:..... setenv eth3addr F0:AD:4E:..... env save and this works an boots into armbian on actual espresso bin board with macronix chip. I will also test the current releases from kostap. Edit: OK. fine. flash-images-18.09/flash-image-1g-2cs-800_800_boot_sd_and_usb.bin Marvell>> version U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian (Sep 05 2018 - 21:49:34 +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 Marvell>> sspi SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB works for me and booting into armbian with my posted environment. Many Thanks @kostap , @skandalfo and @ebin-dev Thank you. still have to do some stability test and recover the stack of all "burned" testboards.

that is right. i known this. thank you for you work. but it means, that any new user who's buying an actual espresso bin board and using armbian with the current provided armbian bootloader... will "brick" the board, can't use bubt oder or save env, and so.. can't use armbian. armbian espressobin release only works with old espresso bin boards (those with winbond SPI). This hint should be clearly visible at https://www.armbian.com/espressobin/ since support ist now "broken", until we have a bootloader that supports mx25u3235f. I have no response from espressobin yet. I referenced this thread.

all these confirmation-tests (you mentioned in https://pastebin.com/mfrDk4AQ, ) shows boards with SPI w25q32dw - thats the old winbond SPI. we have only those problems with the new one... macronix SPI mx25u3235f it seems, your build only supports these macronix SPI mx25u1635e and mx25u6435f http://www.macronix.com/Lists/Datasheet/Attachments/7412/MX25U1635E, 1.8V, 16Mb, v2.1.pdf http://www.macronix.com/Lists/Datasheet/Attachments/7411/MX25U6435F, 1.8V, 64Mb, v1.5.pdf but mx25u3235f is needed http://www.macronix.com/Lists/Datasheet/Attachments/7438/MX25U3235F, 1.8V, 32Mb, v1.6.pdf since the new espresso board use a Macronix MXIC MX 25V3 2311 -> SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB (shown by vendor/manufacturer shipped bootloader) 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

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

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

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

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 could you please check if your new binary has references to Macronix mx25u3235f ? strings image-file.bin | grep mx25u3235f

it won't boot. no output at uart. 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.

@skandalfo thank you for you work. I already build a patched bootloader, but it doesn't work. Will try your mentioned toolchain. 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.

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.

@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.

# 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 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) },

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

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

sorry. my fault. setenv ethaddr 0F:AD:4E:xx:xx:xx setenv eth1addr 0F:AD:4E:xx:xx:xx setenv eth2addr 0F:AD:4E:xx:xx:xx setenv eth3addr 0F:AD:4E:xx:xx:xx was a dumb typo, since the mac vendor id of globalscale inc. is F0:AD:4E... so this would be the correct setting... setenv ethaddr F0:AD:4E:xx:xx:xx and with this environment setting the mac address ist also recognized correctly without any further changes in the system. this mac-address is set for all devices: lan0,lan01,wan,eth0,br0 unfortunately the dumb typo 0F instead of F0 also set the unicast/multicast bit... so I intiallty thought the env setting would'nt work. rubbish. I found this out, while doing a ugly hack as a workaround Nevertheless... I'll share this obsolet workaround with you 1. changing environment in uboot once again... for passing a custom kernel parameter "hackmac=F0:AD:4E:xx:xx:xx" defined for the current board: setenv bootcmd 'mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $initrd_addr $initrd_image; ext4load mmc 0:1 $fdt_addr $fdt_name; setenv bootargs $console root=$rootdev hackmac=F0:AD:4e:XX:XX:XX rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr' 2. this is my changed /etc/network/interfaces in rootfs auto lo iface lo inet loopback auto wan iface wan inet dhcp auto eth0 iface eth0 inet manual auto lan0 iface lan0 inet manual auto lan1 iface lan1 inet manual auto br0 iface br0 inet static pre-up /usr/bin/hackmac br0 address 192.168.xxx.xxx netmask 255.255.255.0 gateway 192.168.xxx.xxx bridge_ports lan0 lan1 bridge_fd 0 bridge_stp off dns-domain xxxxxxxxxxx post-up ifconfig lan0 up post-up ifconfig lan1 up 3. and this script /usr/bin/hackmac for getting und setting mac-adress out of the custom kernel cmdline #!/bin/bash hackmac="$(tr " " "\n" < /proc/cmdline | \ grep -m1 "^hackmac=" | cut -d"=" -f2 | \ tr -dc "0-9a-fA-F:" | tr "A-F" "a-f" | head -c 17)" [ "$#" -gt 0 ] && [ "$hackmac" != "" ] && \ ip link set dev $1 address $hackmac exit 0

@ebin-dev thank you. I know that. At least for me it is a problem if I only can set macs address after boot process in the OS. if you use the same image for different boards, you can't simply change those files in rootfs or in flashed image. e.g. if you deliver the same rootfs by nfs or nbd. etc. running script for autogenerate keys and setting ip after well-know mac address as id. your mac is not well-known then. that is the problem. I'm using the vendor given unique mac address for internal autoprovisioning. So... at first run, I won't have these settings in /etc/network or /etc/system/network.. any other config-file in my delivered rootfs can't know the mac of the board. normally your nic gets this from bootenv/board vendor defined, before ip setting. later you're writing those network config files and change settings. if mac-address is changing at every reboot, I won't get such a auto configure. even for ipv6 or other stuff it is relevant to get all well defined mac address when initializing the nic... even at boot-time it is to late... you have to do this before parsing or setting any config-files in rootfs. so I have to fix autoprovisioning and get a board serial number.. send this to an autoprov server to get a mac.. and then reset those mac address at boot-time. but even this is a problem in some configurations its also a severe problem, if you allow only a bunch of mac adresses... e.g. your switch is configured to block unknown mac-adresses and setting whole port down if a foreign mac address is detected... as an intrusion detection. so with changing mac adresses at every reboot (even if you change them later in system config) would mean, those board gets disconnected from net, because it reports nonsense mac adresses first.. an the switch denies any further access - or at least is sending false-positive intrusion detection messages. so here - it is a no-go (at least for me), if I have only can define the mac-adresses in config-files in the rootfs and if there ist no way to set a fix mac address already before booting the kernel to get a clean initialization.

Sorry. Doesn't work. I'm using these environment vars. (mac address is only masked in this post, not in real setting). mmc rescan env print setenv verbosity 2 setenv boot_interface mmc setenv image_name boot/Image setenv fdt_name boot/dtb/marvell/armada-3720-community.dtb setenv fdt_high "0xffffffffffffffff" setenv rootdev "/dev/mmcblk0p1" setenv rootfstype "ext4" setenv verbosity "1" setenv initrd_addr "0x1100000" setenv initrd_image "boot/uInitrd" setenv bootcmd 'mmc dev 0; ext4load mmc 0:1 $kernel_addr $image_name;ext4load mmc 0:1 $initrd_addr $initrd_image; ext4load mmc 0:1 $fdt_addr $fdt_name;setenv bootargs $console root=$rootdev rw rootwait; booti $kernel_addr $initrd_addr $fdt_addr' setenv ethaddr 0F:AD:4e:xx:xx:xx setenv eth1addr 0F:AD:4e:xx:xx:xx setenv eth2addr 0F:AD:4e:xx:xx:xx setenv eth3addr 0F:AD:4e:xx:xx:xx env save boot the driver/kernel wont use those macs after reset and reboot. I always get some randomized mac adresses for all other interfaces every reboot. If I force the mac-adress in /etc/network/interfaces manually like this auto eth0 iface eth0 inet manual hwaddress ether f0:ad:4e:xx:xx:xx then, the interface is working with this mac. but this is a no-go. the default mac address should not to be set by the OS, and the mac address of the nic should not change every reboot. is it possible to set the mac in the kernel cmdline at least?

Is there a special reason for change of mac-address after upgrading the bootloader/firmware? its now 00:51:82:xx:xx:xx instead of the old one f0:ad:4e:xx:xx:xx also its the same mac address for all interfaces lan0/lan1/wan how to fix this? the board really should have the mac address that is printed on the barcode-label on top of the rj45 ports.