FoodGenius

  • Content Count

    24
  • Joined

  • Last visited

About FoodGenius

  • Rank
    Member

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 s
  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> in
  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.
  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) 2.28.2.20170706 a
  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 espressobi
  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/MX
  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-1
  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
  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 deli