FoodGenius Posted August 29, 2018 Posted 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 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: 0SF: 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 Posted August 30, 2018 Author Posted 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 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: 1SF: 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 Posted August 30, 2018 Posted 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 Posted August 31, 2018 Posted 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 Posted August 31, 2018 Posted 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 Posted September 3, 2018 Author Posted 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 Posted September 3, 2018 Author Posted 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 Posted September 3, 2018 Posted 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 Posted September 3, 2018 Author Posted 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 athttps://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 Posted September 3, 2018 Posted September 3, 2018 (edited) @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 Posted September 3, 2018 Posted September 3, 2018 And, yes, I used the toolchain from here, as suggested by the build instructions, on Ubuntu 18.04.
Igor Posted September 4, 2018 Posted September 4, 2018 15 hours ago, FoodGenius said: there should be a hint athttps://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 Posted September 4, 2018 Author Posted 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 Posted September 4, 2018 Posted 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 Posted September 4, 2018 Author Posted 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 Posted September 4, 2018 Posted 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 Posted September 4, 2018 Author Posted 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 Posted September 4, 2018 Posted 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 Posted September 4, 2018 Author Posted 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 Posted September 4, 2018 Posted 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 Posted September 4, 2018 Posted 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 Posted September 4, 2018 Author Posted 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 Posted September 4, 2018 Posted 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 Posted September 5, 2018 Posted 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 Posted September 5, 2018 Author Posted 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 Posted September 5, 2018 Posted September 5, 2018 (edited) 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 Posted September 5, 2018 Posted 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 Posted September 5, 2018 Author Posted 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 Posted September 5, 2018 Author Posted 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 Posted September 5, 2018 Posted 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.
Recommended Posts