lsartory Posted April 9, 2020 Posted April 9, 2020 Hi everyone, I updated the Linux kernel on my Espressobin to the latest version (5.6.2) and had some issues booting from SATA as my SSD was not detected properly after boot. Using the device tree from an older kernel version did help, but I also read somewhere that updating to the latest Armbian U-Boot would solve the issue. So I downloaded the version that matches my hardware (flash-image-ddr3-2g-2cs-1000_800.bin) and flashed it. It indeed fixed the boot issues, but now only 1 GB of RAM is detected instead of 2 GB. This happens as soon as the board is powered on, in U-Boot: DRAM: 1 GiB Before that, I was using the U-Boot version from espressobin.net, and the 2 GB were detected and usable. I'm sure of it, because before downloading the Armbian U-Boot I checked the output to make sure that I indeed had the 2 GB version. I cannot do a downgrade to verify this right now, because the espressobin.net website is broken; most pages report a 404 error, including the one where the U-Boot files were located. I tried different versions, like the slower flash-image-ddr3-2g-2cs-800_800.bin or the version in the https://dl.armbian.com/espressobin/u-boot/archive/10/ folder, with similar results. I also tried the 1200 MHz version out of curiosity, and had to recover the SPI flash using the SATA rescue image. In any case, I would prefer to continue using the Armbian U-Boot version, since it is more up to date and works with the current mainline kernel and device tree. I did not find any answer for this in the forums or using Google. I actually find it very odd that it works at all. What is then used? Only one RAM chip? Or 512 MB from each? Did I install the wrong image, or did I miss a step when migrating U-Boot?
ebin-dev Posted April 11, 2020 Posted April 11, 2020 On 4/9/2020 at 9:42 PM, lsartory said: Did I install the wrong image, or did I miss a step when migrating U-Boot? Unfortunately there are no details about your board. Do you own a V5_0_1 EspressoBin with 2GB RAM (2 x 8Gbit DDR3, one on each side of the board) ?
lsartory Posted April 11, 2020 Author Posted April 11, 2020 Yes, sorry, I forgot to mention it. I'm actually not entirely sure which hardware revision it is. I bought it in December of 2017, so it's clearly not a v7. Could it be a v4? It has indeed one DDR3 chip on each side.
shadow Posted April 17, 2020 Posted April 17, 2020 Hello, i have the same problem wit my V5_0_1 Board after an u-boot update there was only find 1Gb of DRAM Here the Log from the Update: TIM-1.0 WTMI-devel-18.07.0-6050fd5 WTMI: system early-init SVC REV: 3, CPU VDD voltage: 1.155V NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.5(release):711ecd3 (Marvell-armada-18.09.4) NOTICE: BL1: Built : 15:13:47, Sep 7 2018 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.5(release):711ecd3 (Marvell-armada-18.09.4) NOTICE: BL2: Built : 15:13:50, Sep 7 2018 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.5(release):711ecd3 (Marvell-armada-18.09.4) NOTICE: BL31: Built : 15:1 U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian (Sep 05 2018 - 21:49:34 +0200) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU 1000 [MHz] L2 1000 [MHz] NB AXI 250 [MHz] SB AXI 250 [MHz] DDR 800 [MHz] DRAM: 2 GiB U-Boot DT blob at : 000000007f7142d8 Comphy chip #0: 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: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB Net: eth0: neta@30000 [PRIME] Hit any key to stop autoboot: 0 Marvell>> Marvell>> bubt flash-image-ddr3-2g-2cs-1000_800.bin spi usb Burning U-BOOT image "flash-image-ddr3-2g-2cs-1000_800.bin" from "usb" to "spi" USB0: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1: USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found scanning bus 1 for devices... 1 USB Device(s) found reading flash-image-ddr3-2g-2cs-1000_800.bin Image checksum...OK! SF: Detected w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB 684228 bytes written, 204800 bytes skipped in 12.723s, speed 71552 B/s Done! Marvell>> reset resetting ... TIM-1.0 WTMI-devel-18.12.1-e6bb176 WTMI: system early-init SVC REV: 3, CPU VDD voltage: 1.155V NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.5(release):1f8ca7e (Marvell-devel-18.12.2) NOTICE: BL1: Built : 16:24:14, May 21 2019 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.5(release):1f8ca7e (Marvell-devel-18.12.2) NOTICE: BL2: Built : 16:24:16, May 21 2019 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.5(release):1f8ca7e (Marvell-devel-18.12.2) NOTICE: BL31: Built : 16:2 U-Boot 2018.03-devel-18.12.3-gc9aa92c-armbian (Feb 20 2019 - 09:45:04 +0100) Model: Marvell Armada 3720 Community Board ESPRESSOBin CPU 1000 [MHz] L2 800 [MHz] TClock 200 [MHz] DDR 800 [MHz] DRAM: 1 GiB Comphy chip #0: Comphy-0: USB3 5 Gbps Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 6 Gbps SATA link 0 timeout. could it be that the 2g bin is compiled with 1g? Regards shadow
lsartory Posted April 19, 2020 Author Posted April 19, 2020 Thanks for the log, shadow. I couldn't copy / paste it myself as I did not expect the issue. Which version were you using before ? Did you roll back ? Also, are the Espressobin U-Boot sources / configuration available somewhere so that we can build it ourselves ? I did not find anything in the Armbian GitHub, and the stuff on the Marvell GitHub is very obsolete.
Heisath Posted April 19, 2020 Posted April 19, 2020 Build configuration for Espressobin with Armbian Tools can be found here: https://github.com/armbian/build/blob/master/config/sources/families/mvebu64.conf After a quick look I'd say it is using the Marvell Version, Branch u-boot-2018.03-armada-18.12. BOOTSOURCE='https://github.com/MarvellEmbeddedProcessors/u-boot-marvell.git' BOOTBRANCH='branch:u-boot-2018.03-armada-18.12' But have a look at the config yourself.
lsartory Posted April 20, 2020 Author Posted April 20, 2020 Indeed, the configuration in the mvebu64.conf script is wrong. The 2 CS 2 GB image is compiled with the same DDR topology parameter as the 2 CS 1 GB image (DDR_TOPOLOGY=2). It appears that the configuration for the 2 CS 512 MB version is also wrong, as it points to the same topology file as the 1 CS version. I guess this is not really a problem, because I'm not even sure that this variant actually exists. So to answer my previous question: On 4/9/2020 at 9:42 PM, lsartory said: What is then used? Only one RAM chip? Or 512 MB from each? What is used is only 512 MB from each chip. If anyone needs it, here is the bootloader (U-Boot 2018.03-18.12) compiled with the correct topology (DDR_TOPOLOGY=7): flash-image-ddr3-2g-2cs-1000_800.bin Note that only changing the DDR_TOPOLOGY from 2 to 7 was not enough, because this configuration is also missing from the Marvell sources, even though that's the parameter used in the build examples. The correct topology exists in the Armbian tree, but with the wrong name: https://github.com/armbian/build/blob/master/packages/blobs/espressobin/DDR_TOPOLOGY_2-2g.txt The A3700-utils-marvell/script/buildtim.sh script must also be adapted to accept a DDR_TOPOLOGY value higher than 6. 3
Heisath Posted April 20, 2020 Posted April 20, 2020 If this works consider to contribute (https://docs.armbian.com/Process_Contribute/) and maybe add a PR with your changes to the Github https://github.com/armbian/build We are always looking for helping hands, especially espressobin since this has currently no real maintainer (that I'm aware of). 1
shadow Posted April 26, 2020 Posted April 26, 2020 On 4/20/2020 at 7:13 PM, lsartory said: Indeed, the configuration in the mvebu64.conf script is wrong. The 2 CS 2 GB image is compiled with the same DDR topology parameter as the 2 CS 1 GB image (DDR_TOPOLOGY=2). It appears that the configuration for the 2 CS 512 MB version is also wrong, as it points to the same topology file as the 1 CS version. I guess this is not really a problem, because I'm not even sure that this variant actually exists. So to answer my previous question: What is used is only 512 MB from each chip. If anyone needs it, here is the bootloader (U-Boot 2018.03-18.12) compiled with the correct topology (DDR_TOPOLOGY=7): flash-image-ddr3-2g-2cs-1000_800.bin Note that only changing the DDR_TOPOLOGY from 2 to 7 was not enough, because this configuration is also missing from the Marvell sources, even though that's the parameter used in the build examples. The correct topology exists in the Armbian tree, but with the wrong name: https://github.com/armbian/build/blob/master/packages/blobs/espressobin/DDR_TOPOLOGY_2-2g.txt The A3700-utils-marvell/script/buildtim.sh script must also be adapted to accept a DDR_TOPOLOGY value higher than 6. Thank you for the new bootloader it is working now i get back my 2 GiB DRAM
lsartory Posted April 29, 2020 Author Posted April 29, 2020 On 4/20/2020 at 10:19 PM, Heisath said: If this works consider to contribute (https://docs.armbian.com/Process_Contribute/) and maybe add a PR with your changes to the Github https://github.com/armbian/build We are always looking for helping hands, especially espressobin since this has currently no real maintainer (that I'm aware of). The change was merged. Hopefully it will help. It's a pity that no one maintains this, because the Espressobin has really nice hardware (when it works)!
umiddelb Posted August 23, 2020 Posted August 23, 2020 The download directory doesn't seem to contain the recent firmware with the correct RAM layout. The last modification date is from 2019 and I run into the some issue when I've 'refurbished' my espressobin today with Ubuntu 20.04.
ebin-dev Posted August 24, 2020 Posted August 24, 2020 @umiddelb You can try my latest u-boot flash images (see below) - they were compiled on March 7th 2020. I have just used newer versions of the Linaro tools. @lsartory Historical remarks: There are two issues to be solved in the build system: a) A3700-Utils 18.12 in Marvell Repository does not provide a DDR_Topology for the DDR3 2GB EspressoBin and b) there is an error in DDR_Topology_6.txt related to the V7 2G Espressobin: it shoud specify ddr_mem_size_index=4 (1024MB) for the single chip size instead of 5. The second issue is corrected by using an amended DDR_Topology_6.txt in the Armbian Build system which is copied into place before building the flash files. The first issue was solved in a similar way using two different versions of DDR_Topology_2 - one for the DDR3 1G EspressoBin (DDR_Topology_2-1g) and the other one for the DDR3 2G EspressoBin (DDR_Topology_2-2g) copied into place as DDR_Topology_2 just before compiling the corresponding flash images. The A3700-utils-marvell/script/buildtim.sh did not need any adaptation. Edit: The u-boot flash images should be available by now on the EspressoBin download page.
lsartory Posted August 24, 2020 Author Posted August 24, 2020 @ebin-dev, thanks for the clarification. That explains how the previous images were built, and where the error was made. I hope my changes will help prevent it from happening again in future builds.
umiddelb Posted August 25, 2020 Posted August 25, 2020 17 hours ago, ebin-dev said: You can try my latest u-boot flash images (see below) - they were compiled on March 7th 2020. I have just used newer versions of the Linaro tools. They are working fine, thank you.
tekrantz Posted September 15, 2020 Posted September 15, 2020 First of all thank you so much for the link to a working 2gb uboot. I just grabbed it and got my 2gb back. Second, I had noticed earlier in the day that on the espressobin download page aht all the uboots had been updated as of 8/24/2020. I tried ALL of the ones listed as 2gb and ALL of them still came up as 1gb, so whatever fix was put in did not take. But as I say, the link above to a working 2gb uboot got me going again.
Recommended Posts