Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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/
  2. 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?
  3. fine. thanks. would be nice to publish these images in https://dl.armbian.com/espressobin/u-boot/ in a subfolder "rescue".
  4. 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 ... 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 '' setenv stderr 'serial@12000' setenv stdin 'serial@12000' setenv stdout 'serial@12000' setenv serverip '' setenv gatewayip '' setenv ipaddr '' 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
  5. 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) 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) 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.
  6. 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.
  7. 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
  8. 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+++
  9. 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
  10. there is still missing flash-image-1g-2cs-800_800_boot_sd_and_usb.bin ?
  11. 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.
  12. @ebin-dev could you please check if your new binary has references to Macronix mx25u3235f ? strings image-file.bin | grep mx25u3235f
  13. 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.
  14. @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.
  15. 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.
  • Create New...