Anders 4 Posted February 23 Author Share Posted February 23 8 hours ago, Pali said: Just to note, we have sent a new version (v3) of Armada 37xx cpufreq patches, now with fixes for 1.2 GHz boards: https://lore.kernel.org/linux-arm-kernel/20210222194158.12342-1-pali@kernel.org/ Nice work. I'm unable to test it on my V7 1gb board though. Every time I fash it with a 1200mhz image, it bricks, and I can't even get to the uboot prompt. Are there anyone who's been able to boot the Espressobin V7 at 1.2 Ghz? By the way, who's sponsoring your work on this chip? 0 Quote Link to post Share on other sites
Pali 12 Posted February 25 Share Posted February 25 On 2/23/2021 at 5:46 AM, Anders said: Nice work. I'm unable to test it on my V7 1gb board though. Every time I fash it with a 1200mhz image, it bricks, and I can't even get to the uboot prompt. Could you please provide following information? full UART output with 1200 MHz image if there is at least something full UART output with some image which is working, up to the U-Boot booting output of U-Boot command (from working image): md d0012604 1; md d0012604 1; md d0012604 1 lables / indentifiers printed on SoC chip package (that one identified by 88F3720) On 2/23/2021 at 5:46 AM, Anders said: Are there anyone who's been able to boot the Espressobin V7 at 1.2 Ghz? In email thread with mentioned kernel patches on linux-arm-kernel mailing list there is one tester and final version of patches are working stable also on 1.2 GHz mode. On 2/23/2021 at 5:46 AM, Anders said: By the way, who's sponsoring your work on this chip? It is for Turris MOX, modular router: https://www.turris.com/en/mox/overview/ 0 Quote Link to post Share on other sites
Anders 4 Posted March 2 Author Share Posted March 2 @Pali Normal boot: TIM-1.0 WTMI-devel-18.12.1-0967979 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.155V NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.5(release):1f8ca7e0 (Marvell-devel-18.12.2) NOTICE: BL1: Built : 10:12:00, Sep 18 2020 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.5(release):1f8ca7e0 (Marvell-devel-18.12.2) NOTICE: BL2: Built : 10:12:01, Sep 18 2020 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.5(release):1f8ca7e0 (Marvell-devel-18.12.2) NOTICE: BL31: Built : 10:1 U-Boot 2018.03-devel-18.12.3-gc9aa92ce70-armbian (Sep 18 2020 - 10:07:21 +0200) 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. 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 Loading Environment from SPI Flash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiBB OK Model: Marvell Armada 3720 Community Board ESPRESSOBin Net: eth0: neta@30000 [PRIME] Hit any key to stop autoboot: 0 Marvell>> md d0012604 1; md d0012604 1; md d0012604 1 d0012604: 00000000 .... d0012604: 27236501 .e#' d0012604: 0000f580 .... With flash-image-ddr4-1g-1cs-1200_750.bin (md5sum 1c25222cd3cb9162547afa80eb280a26) from https://minio.k-space.ee/minio/armbian/dl/espressobin/u-boot/ I managed to get this output once: TIM-1.0 WTMI-devel-18.12.1-0967979 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 0.898V That voltage seems low, right? Do you still need me to pull the heat sink to get the lables / indentifiers printed on SoC chip? 0 Quote Link to post Share on other sites
Pali 12 Posted March 2 Share Posted March 2 14 minutes ago, Anders said: Marvell>> md d0012604 1; md d0012604 1; md d0012604 1 d0012604: 00000000 .... d0012604: 27236501 .e#' d0012604: 0000f580 .... Content of known bits in OTP: SVC revision is 5 600 MHz mode is not supported 800 MHz mode uses 1.073V 1000 MHz mode uses 1.155V 1200 MHz mode is not supported 14 minutes ago, Anders said: TIM-1.0 WTMI-devel-18.12.1-0967979 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 0.898V That voltage seems low, right? Do you still need me to pull the heat sink to get the lables / indentifiers printed on SoC chip? I guess it is not needed. In OTP is burned that 1.2GHz mode is not supported, so some lowest default value was chosen by WTMI. So the result is that your SoC most probably does not contain 1.2 GHz CPU, but only 1 GHz CPU. If you want to know definite answer then it is needed to check if package has printed C120 (1.2 GHz variant) or C100/I100 (1 GHz variant). But even if you have SoC with 1.2 GHz CPU and you want to use 1.2 GHz mode you would have to calibrate / figure out voltage level and then patch WTMI firmware to use that calibrated / measured voltage value. 0 Quote Link to post Share on other sites
Anders 4 Posted March 2 Author Share Posted March 2 @Paul Interesting. All marketing on espressobin.net and from Globalscale claims that this chip is 1.2Ghz capable. I'm going to need some help interpreting the labels on the chip: https://drive.google.com/file/d/1dqvT6HzcH9VCEb4dPryXie61xP3WwY0B/view?usp=sharing https://drive.google.com/file/d/1rldOzYHm3nWbHMIr08oCoLps1hM9dq_R/view?usp=sharing 0 Quote Link to post Share on other sites
Pali 12 Posted March 3 Share Posted March 3 See public HW documentation https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-37xx-hardware-specifications-2019-09.pdf page 154 and 153. There is described what all numbers on label means. Public documentation is older and 1.2 GHz variant is missing here. But you can deduce that its Speed Code is 120. From your photos I cannot read all numbers on that chip. I see that first line is 88F3-BVB2, but I cannot read other lines. 0 Quote Link to post Share on other sites
Anders 4 Posted March 3 Author Share Posted March 3 On 2/25/2021 at 1:35 AM, Pali said: In email thread with mentioned kernel patches on linux-arm-kernel mailing list there is one tester and final version of patches are working stable also on 1.2 GHz mode. With a Espressobin board? @all Are there anyone who's been able to boot using flash-image-ddr4-1g-1cs-1200_750.bin or flash-image-ddr4-2g-2cs-1200_750.bin, or should they be warned against on https://www.armbian.com/espressobin/ since they just soft brick your board? It would also be nice if someone with a chip with readable labels could take a picture and share. You'll need to wriggle the heat-sink quite a bit (maybe easier if the board is warm). I'm my case, I could just put it back on the chip with the glue still working. 0 Quote Link to post Share on other sites
Pali 12 Posted March 3 Share Posted March 3 4 minutes ago, Anders said: With a Espressobin board? Yes, ESPRESSObin_V7_1-0 with 88F3720-A0-C120 SoC. See whole discussion https://lore.kernel.org/linux-arm-kernel/20210209225630.mdwnzkvnaz3r4blt@pali/ 0 Quote Link to post Share on other sites
Igor 2201 Posted March 4 Share Posted March 4 On 3/3/2021 at 11:22 AM, Anders said: or should they be warned against on https://www.armbian.com/espressobin/ since they just soft brick your board? We don't have maintainer for this board anymore - he moved to another hardware. We also never received a cent from anyone for trying to keep this HW usable. We only got one free sample from vendor and one (sadly the same revision) from their lead developer. Since this product was never more then 1/4 baken we wasted insane a lot of time for little gain. But our OS was probably the only usable ... Changing board status to EOS is all I can do. If someone has a desire to take over and keep information on that page relevant (Community supported status), send me a private message. 1 Quote Link to post Share on other sites
Pali 12 Posted March 17 Share Posted March 17 On 3/4/2021 at 11:32 AM, Igor said: we wasted insane a lot of time for little gain Excuse me, but what have you done? Can show e.g. your changes which have you done in upstream kernel, u-boot or any other project, including links to git commit to those projects? Or issues which you have fixed? On 3/4/2021 at 11:32 AM, Igor said: We also never received a cent from anyone for trying to keep this HW usable. Because the only thing which I saw, was removal of MAC addresses and claiming that this is the best for everybody. Sorry but nobody is going to pay to project which is just complaining about wasted insane of time or project which is erasing MAC addresses or project which is wasting time without any result. We have made 1GHz variant of A3720 SoC stable. 0 Quote Link to post Share on other sites
lanefu 306 Posted March 17 Share Posted March 17 27 minutes ago, Pali said: Excuse me, but what have you done? Can show e.g. your changes which have you done in upstream kernel, u-boot or any other project, including links to git commit to those projects? Or issues which you have fixed? Primarily our project integrates patches and wrangles configurations to create repeatable image builds for SBCs. Some maintainers are able to go a bit deeper and send device tree patches etc upstream. 30 minutes ago, Pali said: Because the only thing which I saw, was removal of MAC addresses and claiming that this is the best for everybody. Not familiar with the best for everybody statement.. I think the primary misconfiguration of the MAC was done by me..and in the early stages... and never got improved. I acknowledged that on a prior thread. 32 minutes ago, Pali said: We have made 1GHz variant of A3720 SoC stable. Are you interested in taking a more formal maintainer role for the ebin with Armbian? I'd be glad to introduce you to the build tool, and the ways we add patches etc if you like. 0 Quote Link to post Share on other sites
Pali 12 Posted March 17 Share Posted March 17 3 minutes ago, lanefu said: Are you interested in taking a more formal maintainer role for the ebin with Armbian? No, never. 0 Quote Link to post Share on other sites
lanefu 306 Posted March 17 Share Posted March 17 1 minute ago, Pali said: No, never. Okay.. There's another open role that you may be interested in: We're looking for someone who's interested in the hardware, likes to post on the forum to discuss and share technical improvements, but also get angry about low participation, and take any opportunity available to insult the Armbian project and yell at developers and contributors who generally have good intentions. Is that something you'd be interested in taking on? 0 Quote Link to post Share on other sites
Pali 12 Posted March 17 Share Posted March 17 Sorry, no. I'm not going to take any role in any community. 0 Quote Link to post Share on other sites
Igor 2201 Posted March 17 Share Posted March 17 1 hour ago, Pali said: Because the only thing which I saw, was removal of MAC addresses and claiming that this is the best for everybody. Core of Armbian involvement into this hardware goes 3-4 years before you showed up. When almost nothing worked well! When you start complaining about things you don't or don't want to understand, we already cease all activities in semy broken stage - we lost interest. I understand some other company or even more of them took this design and are trying make something out of it. It seems you are a part of one and you are certainly not wasting your private time for it. 1 hour ago, Pali said: which is erasing MAC addresses or project which is wasting time without any result. I explained you, why dirty hack existed. I guess you have a lot to learn. 1 hour ago, Pali said: We have made 1GHz variant of A3720 SoC stable. 10 (?) more to go. 0 Quote Link to post Share on other sites
Pali 12 Posted March 25 Share Posted March 25 (edited) @Anders Here is patch for A3700-utils-marvell repository which adds fallback for CPU VDD voltage to default value when there is no value burned value in OTP. Could you try to test it for 1.2 GHz mode? diff --git a/wtmi/sys_init/avs.c b/wtmi/sys_init/avs.c index c25fae087483..b993a80d9c5d 100644 --- a/wtmi/sys_init/avs.c +++ b/wtmi/sys_init/avs.c @@ -196,12 +196,21 @@ int init_avs(u32 speed) } if (svc_rev >= SVC_REVISION_2) { - vdd_otp = ((otp_data[OTP_DATA_SVC_SPEED_ID] >> shift) + - AVS_VDD_BASE) & AVS_VDD_MASK; - regval |= (vdd_otp << HIGH_VDD_LIMIT_OFF); - regval |= (vdd_otp << LOW_VDD_LIMIT_OFF); - printf("SVC REV: %d, CPU VDD voltage: %s\n", svc_rev, - avis_dump[vdd_otp].desc); + vdd_otp = (otp_data[OTP_DATA_SVC_SPEED_ID] >> shift) & + AVS_VDD_MASK; + if (!vdd_otp || vdd_otp + AVS_VDD_BASE > AVS_VDD_MASK) { + regval |= (vdd_default << HIGH_VDD_LIMIT_OFF); + regval |= (vdd_default << LOW_VDD_LIMIT_OFF); + printf("SVC REV: %d, CPU VDD voltage is invalid," + " using default value: %s\n", svc_rev, + avis_dump[vdd_default].desc); + } else { + vdd_otp += AVS_VDD_BASE; + regval |= (vdd_otp << HIGH_VDD_LIMIT_OFF); + regval |= (vdd_otp << LOW_VDD_LIMIT_OFF); + printf("SVC REV: %d, CPU VDD voltage: %s\n", + svc_rev, avis_dump[vdd_otp].desc); + } } else { regval |= (vdd_default << HIGH_VDD_LIMIT_OFF); regval |= (vdd_default << LOW_VDD_LIMIT_OFF); Edited April 10 by Pali printf bug 0 Quote Link to post Share on other sites
Anders 4 Posted April 8 Author Share Posted April 8 @Pali This is how I attempted to build an image (inspired by http://wiki.espressobin.net/tiki-index.php?page=Build+From+Source+-+Bootloader): $ mkdir espressobin-bootloader && cd espressobin-bootloader $ git clone https://github.com/MarvellEmbeddedProcessors/u-boot-marvell.git -b u-boot-2017.03-armada-17.10 $ git clone https://github.com/MarvellEmbeddedProcessors/atf-marvell.git -b atf-v1.3-armada-17.10 $ git clone https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell.git -b master $ git clone https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git -b master $ cd u-boot-marvell $ export CROSS_COMPILE=aarch64-linux-gnu- $ make mvebu_espressobin-88f3720_defconfig $ sed -i 's/-Werror //' Makefile $ make DEVICE_TREE=armada-3720-espressobin $ cd .. $ mkdir -p A3700-utils-marvell/ddr/tim_ddr $ ln -sr A3700-utils-marvell/script/ A3700-utils-marvell/ddr/tim_ddr/script $ ln -sr A3700-utils-marvell/wtmi/ A3700-utils-marvell/ddr/tim_ddr/wtmi $ ln -sr A3700-utils-marvell/tim/ A3700-utils-marvell/ddr/tim_ddr/tim $ ln -sr A3700-utils-marvell/wtptp/linux/tbb_linux A3700-utils-marvell/wtptp/linux/TBB_linux $ cd atf-marvell $ export BL33=../u-boot-marvell/u-boot.bin $ make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=5 BOOTDEV=SPINOR PARTNUM=0 WTP=../A3700-utils-marvell/ MV_DDR_PATH=../mv-ddr-marvell/ PLAT=a3700 all fip // Now copy build/a3700/debug/flash-image.bin to a FAT32 USB, and flash it on the device: Marvell>> bubt flash-image.bin spi usb This is what I got trying to boot this 1000Mhz image: TIM-1.0 mv_ddr-devel-g7c35173 DDR4 16b 1GB 1CS WTMI-devel-18.12.1-c444aeb WTMI: system early-init DDR topology parameters: ======================== ddr type DDR4 ddr speedbin 11 bus width 16-bits cs num 1 cs[0] - group num 0 cs[0] - bank num 8 cs[0] - capacity 1024MiB SVC REV: 5, CPU VDD voltage: 1.155V DRAM windows: ============= WIN[0] - base addr 0x60000000 WIN[0] - size 0x40000000 memory test region: =================== CS[0] 0x60000000 - 0x9fffffff SELF-REFRESH TEST PASSSetting clocks: CPU 1000 MHz, DDR 800 MHz VREF READ TRAINING PASSED VREF WRITE TRAINING PASSED DLL TUNING PASSED ASSERT: mmap_add_region <96> : IS_PAGE_ALIGNED(base_va) And with the new patch applied, and configured to 1200mhz: $ cd ../A3700-utils-marvell/ $ make clean $ git apply cpu_vdd_fallback.patch $ cd ../atf-marvell $ make distclean $ make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 CLOCKSPRESET=CPU_1200_DDR_750 DDR_TOPOLOGY=5 BOOTDEV=SPINOR PARTNUM=0 WTP=../A3700-utils-marvell/ MV_DDR_PATH=../mv-ddr-marvell/ PLAT=a3700 all fip This results in: TIM-1.0 mv_ddr-devel-g7c35173 DDR4 16b 1GB 1CS WTMI-devel-18.12.1-c444aeb-dirty WTMI: system early-init DDR topology parameters: ======================== ddr type DDR4 ddr speedbin 11 bus width 16-bits cs num 1 cs[0] - group num 0 cs[0] - bank num 8 cs[0] - capacity 1024MiB SVC REV: 536817928, CPU VDD voltage is invalid, using default value: DRAM windows: ============= WIN[0] - base addr 0x60000000 WIN[0] - size 0x40000000 memory test region: =================== CS[0] 0x60000000 - 0x9fffffff SELF-REFRESH TEST PASSSetting clocks: CPU 1200 MHz, DDR 750 MHz VREF READ TRAINING PASSED VREF WRITE TRAINING PASSED DLL TUNING PASSED ASSERT: mmap_add_region <96> : IS_PAGE_ALIGNED(base_va) I think this is what is causing me problems: "No input file for TIMN is supplied". I'll continue working on it tomorrow night! [...] TBB Version : 3.3.12.1 TBB Date : 2017-03-17 Start time: 04/08/21 23:49:06 CommandLineOptions: -r ../A3700-utils-marvell//atf-ntim.txt -v -D Verifying Descriptor Integrity... Parsing non trusted TIM... Parsing Instruction Labels.... Finished Parsing Instruction Labels.... Parsing Instruction Labels.... Finished Parsing Instruction Labels.... Parsing Instruction Labels.... Finished Parsing Instruction Labels.... Success: Non-trusted Tim Descriptor file parsing has completed successfully! Processing non trusted TIM... Prepending ImageTag <0x57544d49> to image file: <../A3700-utils-marvell//wtmi/build/wtmi_h.bin>. Prepending ImageTag <0x4F424d49> to image file: <./build/a3700/debug/boot-image_h.bin>. 'TIM_ATF.bin' size in bytes: 3064 Tim size to hash read from file: 3064 TIM Hash size (in bits) 256 0xEED27F4D 0xC1E7B5BF 0x93AC3F05 0x4440324F 0x10AB1D38 0x4536F14F 0x42199E01 0x2F67F28B Success: NTIM Processing has completed successfully! Finish time: 04/08/21 23:49:06 TBB Exiting...! Building flash image ../A3700-utils-marvell//script/buildtim.sh 0 SPINOR ../A3700-utils-marvell//tim/untrusted ../A3700-utils-marvell//ddr/tim_ddr CPU_1000_DDR_800 5 0 1 ../A3700-utils-marvell//atf-ntim.txt 1 sed -i 's|WTMI_IMG|../A3700-utils-marvell//wtmi/build/wtmi.bin|1' ../A3700-utils-marvell//atf-ntim.txt sed -i 's|BOOT_IMAGE|./build/a3700/debug/boot-image.bin|1' ../A3700-utils-marvell//atf-ntim.txt ../A3700-utils-marvell//wtptp/linux/TBB_linux -r ../A3700-utils-marvell//atf-ntim.txt -v -D TBB Version : 3.3.12.1 TBB Date : 2017-03-17 Start time: 04/08/21 23:49:06 CommandLineOptions: -r ../A3700-utils-marvell//atf-ntim.txt -v -D Verifying Descriptor Integrity... Parsing non trusted TIM... Parsing Instruction Labels.... Finished Parsing Instruction Labels.... Parsing Instruction Labels.... Finished Parsing Instruction Labels.... Parsing Instruction Labels.... Finished Parsing Instruction Labels.... Success: Non-trusted Tim Descriptor file parsing has completed successfully! Processing non trusted TIM... Prepending ImageTag <0x57544d49> to image file: <../A3700-utils-marvell//wtmi/build/wtmi_h.bin>. Prepending ImageTag <0x4F424d49> to image file: <./build/a3700/debug/boot-image_h.bin>. 'TIM_ATF.bin' size in bytes: 3780 Tim size to hash read from file: 3780 TIM Hash size (in bits) 256 0xD38D2762 0xBA346897 0x6BB1D740 0xD44AB2CF 0x2C52F87B 0x92A99738 0x515873A2 0xD6648666 Success: NTIM Processing has completed successfully! Finish time: 04/08/21 23:49:06 TBB Exiting...! ../A3700-utils-marvell//script/tim2img.pl -i ../A3700-utils-marvell//atf-ntim.txt -o ./build/a3700/debug/flash-image.bin No input file for TIMN is supplied Total number of images to process in file[0] - 3 0 Image at offset 00000000 is TIM_ATF.bin 1 Image at offset 00004000 is ../A3700-utils-marvell//wtmi/build/wtmi.bin 2 Image at offset 00015000 is ./build/a3700/debug/boot-image.bin Total number of images 3 0 Quote Link to post Share on other sites
Pali 12 Posted April 8 Share Posted April 8 2 hours ago, Anders said: $ git clone https://github.com/MarvellEmbeddedProcessors/u-boot-marvell.git -b u-boot-2017.03-armada-17.10 $ git clone https://github.com/MarvellEmbeddedProcessors/atf-marvell.git -b atf-v1.3-armada-17.10 These are old repositories. You should use upstream u-boot (https://source.denx.de/u-boot/u-boot.git) and upstream TF-A (https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git). Also ensure that you have set correct DDR_TOPOLOGY= parameter. Whole build parameters are described in TF-A documentation at: https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html Search for full example how to build on that page for inspiration. But basically your steps are correct. You do not need to set DEVICE_TREE variable. 0 Quote Link to post Share on other sites
Anders 4 Posted April 10 Author Share Posted April 10 @Pali That actually seems to work: TIM-1.0 mv_ddr-devel-g7c35173 DDR4 16b 1GB 1CS WTMI-devel-18.12.1-c444aeb-dirty WTMI: system early-init DDR topology parameters: ======================== ddr type DDR4 ddr speedbin 11 bus width 16-bits cs num 1 cs[0] - group num 0 cs[0] - bank num 8 cs[0] - capacity 1024MiB SVC REV: 536817928, CPU VDD voltage is invalid, using default value: DRAM windows: ============= WIN[0] - base addr 0x60000000 WIN[0] - size 0x40000000 memory test region: =================== CS[0] 0x60000000 - 0x9fffffff SELF-REFRESH TEST PASSSetting clocks: CPU 1200 MHz, DDR 750 MHz VREF READ TRAINING PASSED VREF WRITE TRAINING PASSED DLL TUNING PASSED SELF-REFRESH TEST PASSNOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2) NOTICE: BL1: Built : 15:37:24, Apr 10 2021 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2) NOTICE: BL2: Built : 15:37:24, Apr 10 2021 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2) NOTICE: BL31: Built : 15:37:24, Apr 10 2021 U-Boot 2021.04-00640-g3f2e3c7845 (Apr 10 2021 - 15:27:13 +0200) DRAM: 1 GiB WDT: Not starting Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 5 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 Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Card did not respond to voltage select! : -110 Net: eth0: neta@30000 [PRIME] Hit any key to stop autoboot: 0 anders@espressobin:~$ uname -a Linux espressobin 5.11.0+ #1 SMP PREEMPT Wed Mar 3 11:51:48 CET 2021 aarch64 aarch64 aarch64 GNU/Linux anders@espressobin:~$ cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1.20 GHz available frequency steps: 200 MHz, 300 MHz, 600 MHz, 1.20 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 200 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:79.25%, 300 MHz:5.20%, 600 MHz:1.47%, 1.20 GHz:14.08% (1095) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 0.97 ms. hardware limits: 200 MHz - 1.20 GHz available frequency steps: 200 MHz, 300 MHz, 600 MHz, 1.20 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 200 MHz and 1.20 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:79.25%, 300 MHz:5.20%, 600 MHz:1.47%, 1.20 GHz:14.08% (1095) anders@espressobin:~$ 7za b 7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21 p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE) LE CPU Freq: 1195 1197 1197 1197 1197 1197 1197 1197 1196 RAM size: 983 MB, # CPU hardware threads: 2 RAM usage: 441 MB, # Benchmark threads: 2 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 1013 159 621 986 | 26035 199 1115 2223 23: 994 158 640 1013 | 25584 199 1110 2215 24: 989 159 667 1064 | 24925 198 1103 2188 25: 982 160 703 1122 | 24618 199 1099 2191 ---------------------------------- | ------------------------------ Avr: 159 658 1046 | 199 1107 2204 Tot: 179 882 1625 For reference, this is how I built the bootloader (cpu_vdd_fallback.patch contains the patch you posted for wtmi/sys_init/avs.c): $ git clone https://source.denx.de/u-boot/u-boot.git $ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git $ git clone https://github.com/weidai11/cryptopp.git $ git clone https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell.git $ git clone https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git $ cd u-boot $ export CROSS_COMPILE=aarch64-linux-gnu- $ make mvebu_espressobin-88f3720_defconfig $ make DEVICE_TREE=armada-3720-espressobin -j$(nproc) $ cd ../A3700-utils-marvell/ $ git apply cpu_vdd_fallback.patch $ cd ../trusted-firmware-a/ $ export BL33=../u-boot/u-boot.bin $ make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 CLOCKSPRESET=CPU_1200_DDR_750 DDR_TOPOLOGY=5 WTP="$(realpath ../A3700-utils-marvell/)" MV_DDR_PATH=../mv-ddr-marvell/ CRYPTOPP_PATH="$(realpath ../cryptopp/)" PLAT=a3700 mrvl_flash -j$(nproc) I'll let you know if I get a crash. Should I be concerned about temperatures? How can I read the CPU temperature? 0 Quote Link to post Share on other sites
Anders 4 Posted April 10 Author Share Posted April 10 Another nice-to-have is proper powerdown handling: anders@espressobin:~$ sudo shutdown -hP now [...] [ 921.950348] reboot: Power down ERROR: a3700_system_off needs to be implemented BACKTRACE: START: a3700_system_off 0: EL3: 0x4024d34 1: EL3: 0x4023834 2: EL3: 0x4029c2c 3: EL3: 0x4029b34 4: EL3: 0x402a43c 5: EL3: 0x4024ba0 BACKTRACE: END: a3700_system_off Unhandled Exception from EL1 x0 = 0x0000000084000008 [...] 0 Quote Link to post Share on other sites
Pali 12 Posted April 10 Share Posted April 10 4 minutes ago, Anders said: @Pali That actually seems to work: Perfect! Thank you for testing. I will send this patch to Marvell. 4 minutes ago, Anders said: SVC REV: 536817928, CPU VDD voltage is invalid, using default value: Ouch, this is a bug :-( I did mistake in that patch, in printf is missing svc_rev parameter. I updated post with my patch. 4 minutes ago, Anders said: I'll let you know if I get a crash. Should I be concerned about temperatures? How can I read the CPU temperature? Yes, if you board do not have voltage value for 1.2 GHz mode in OTP then it means that your board does not (officially) support 1.2 GHz mode and it could be for various reason... One can be temperature. But unfortunately A3720 SoC does not have temperature sensor from which can be read temperature. So just check if your espressobin is not too hot. I was told that SoC should have some sensor for HW overheat detection, but not sure how it works. 0 Quote Link to post Share on other sites
Pali 12 Posted April 10 Share Posted April 10 5 minutes ago, Anders said: Another nice-to-have is proper powerdown handling: anders@espressobin:~$ sudo shutdown -hP now [...] [ 921.950348] reboot: Power down ERROR: a3700_system_off needs to be implemented BACKTRACE: START: a3700_system_off 0: EL3: 0x4024d34 1: EL3: 0x4023834 2: EL3: 0x4029c2c 3: EL3: 0x4029b34 4: EL3: 0x402a43c 5: EL3: 0x4024ba0 BACKTRACE: END: a3700_system_off Unhandled Exception from EL1 x0 = 0x0000000084000008 [...] This backtrace is from debug version of Trusted Firmware. If you compile it without DEBUG=1 then backtrace is omitted. A3720 SoC does not have full power management like ATX on PC, which can turn power off from all components. This is why function a3700_system_off() in Trusted Firmware is not implemented. Basically I just do not know what this a3700_system_off() should do (if I decide to implement it). It can just call reset or maybe call suspend procedure. A3720 has support for some kind of low power suspend/sleep mode, so maybe this is the best approximation of whole power off. 1 Quote Link to post Share on other sites
Anders 4 Posted April 10 Author Share Posted April 10 (edited) 8 hours ago, Pali said: A3720 SoC does not have full power management like ATX on PC, which can turn power off from all components. This is why function a3700_system_off() in Trusted Firmware is not implemented. Basically I just do not know what this a3700_system_off() should do (if I decide to implement it). It can just call reset or maybe call suspend procedure. A3720 has support for some kind of low power suspend/sleep mode, so maybe this is the best approximation of whole power off. Entering a low power state would be nice. I just got a crash on 1200Mhz. It may be due to temperature. I'm trying to reproduce it now to get a crashlog. Got something: TIM-1.0 mv_ddr-devel-g7c35173 DDR4 16b 1GB 1CS WTMI-devel-18.12.1-c444aeb-dirty WTMI: system early-init DDR topology parameters: ======================== ddr type DDR4 ddr speedbin 11 bus width 16-bits cs num 1 cs[0] - group num 0 cs[0] - bank num 8 cs[0] - capacity 1024MiB SVC REV: 536817928, CPU VDD voltage is invalid, using default value: DRAM windows: ============= WIN[0] - base addr 0x60000000 WIN[0] - size 0x40000000 memory test region: =================== CS[0] 0x60000000 - 0x9fffffff SELF-REFRESH TEST PASSSetting clocks: CPU 1200 MHz, DDR 750 MHz VREF READ TRAINING PASSED VREF WRITE TRAINING PASSED DLL TUNING PASSED SELF-REFRESH TEST PASSNOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2) NOTICE: BL1: Built : 15:37:24, Apr 10 2021 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2) NOTICE: BL2: Built : 15:37:24, Apr 10 2021 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2) NOTICE: BL31: Built : 15:37:24, Apr 10 2021 U-Boot 2021.04-00640-g3f2e3c7845 (Apr 10 2021 - 15:27:13 +0200) DRAM: 1 GiB WDT: Not starting Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 5 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 Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Card did not respond to voltage select! : -110 Net: eth0: neta@30000 [PRIME] Hit any key to stop autoboot: 0 starting USB... Bus usb@58000: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 Bus usb@5e000: USB EHCI 1.00 scanning bus usb@58000 for devices... 1 USB Device(s) found scanning bus usb@5e000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found / Can't set block device ## Executing script at 06d00000 Wrong image format for "source" command /boot/ Can't set block device ## Executing script at 06d00000 Wrong image format for "source" command scanning bus for devices... Device 0: unknown device / Can't set block device ## Executing script at 06d00000 Wrong image format for "source" command /boot/ Can't set block device ## Executing script at 06d00000 Wrong image format for "source" command / Can't set block device ## Executing script at 06d00000 Wrong image format for "source" command /boot/ Can't set block device ## Executing script at 06d00000 Wrong image format for "source" command / Failed to load '/boot.scr' ## Executing script at 06d00000 Wrong image format for "source" command /boot/ 1119 bytes read in 17 ms (63.5 KiB/s) ## Executing script at 06d00000 237 bytes read in 14 ms (15.6 KiB/s) 21432832 bytes read in 910 ms (22.5 MiB/s) 12287307 bytes read in 533 ms (22 MiB/s) Failed to load '/boot/dtb/marvell/armada-3720-community.dtb' 11459 bytes read in 35 ms (319.3 KiB/s) ## Loading init Ramdisk from Legacy Image at 01100000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 12287243 Bytes = 11.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 06000000 Booting using the fdt blob at 0x6000000 Loading Ramdisk to 3ef51000, end 3fb08d0b ... OK Using Device Tree in place at 0000000006000000, end 0000000006005cc2 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 5.11.0+ (anders@ubuntu-desktop) (aarch64-linux-gnu-gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1 SMP PREEMPT Wed Mar 3 11:51:48 CET 2021 [ 0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board [ 0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '') [ 0.000000] printk: bootconsole [ar3700_uart0] enabled Loading, please wait... starting version 237 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... done. Begin: Will now check root file system ... fsck from util-linux 2.31.1 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 /dev/mmcblk0p1 was not cleanly unmounted, check forced. ERROR: Unhandled External Abort received on 0x80000000 at EL3! / 7.0% ERROR: exception reason=0 syndrome=0xbf000001 BACKTRACE: START: plat_ea_handler 0: EL3: 0x4024d34 1: EL3: 0x4028438 2: EL3: 0x402416c BACKTRACE: END: plat_ea_handler Unhandled Exception from EL0 x0 = 0x00000055a51c5f60 x1 = 0x00000055a51add20 x2 = 0x00000000000008b0 x3 = 0x00000055a51c6620 x4 = 0x00000055a51ae620 x5 = 0x00000055a51c6f60 x6 = 0x432e6d6574737953 x7 = 0x746e656e6f706d6f x8 = 0x6f432e6c65646f4d x9 = 0x6f697469736f706d x10 = 0x70642e6c6c642e6e x11 = 0x000077656e2d676b x12 = 0x0132003c000580ea x13 = 0x432e6d6574737953 x14 = 0x0000000000000000 x15 = 0x0000000000000000 x16 = 0x0000007faf405bd8 x17 = 0x0000007faf241f90 x18 = 0x0000007faf312a70 x19 = 0x00000055a51a8098 x20 = 0x0000000000000000 x21 = 0x00000055a51c5f60 x22 = 0x00000055a51a7f60 x23 = 0x00000055a51a8030 x24 = 0x0000000000000001 x25 = 0x0000000000181e01 x26 = 0x0000007fdba04d08 x27 = 0x0000000000000040 x28 = 0x00000055a51c5f60 x29 = 0x0000007fdba04ca0 x30 = 0x0000007faf3eaf28 scr_el3 = 0x0000000000000739 sctlr_el3 = 0x0000000030cd183f cptr_el3 = 0x0000000000000000 tcr_el3 = 0x0000000080803520 daif = 0x00000000000002c0 mair_el3 = 0x00000000004404ff spsr_el3 = 0x0000000020000000 elr_el3 = 0x0000007faf2420c4 ttbr0_el3 = 0x0000000004031c80 esr_el3 = 0x00000000bf000001 far_el3 = 0x0000000000000000 spsr_el1 = 0x0000000020001000 elr_el1 = 0x0000007faf27ff9c spsr_abt = 0x0000000000000000 spsr_und = 0x0000000000000000 spsr_irq = 0x0000000000000000 spsr_fiq = 0x0000000000000000 sctlr_el1 = 0x0000000034d4d91d actlr_el1 = 0x0000000000000000 cpacr_el1 = 0x0000000000300000 csselr_el1 = 0x0000000000000000 sp_el1 = 0xffffffc011704000 esr_el1 = 0x0000000056000000 ttbr0_el1 = 0x000000003f1e0000 ttbr1_el1 = 0x01040000080ec000 mair_el1 = 0x000c0400bb44ffff amair_el1 = 0x0000000000000000 tcr_el1 = 0x00000032b5593519 tpidr_el1 = 0xffffffc02ec2f000 tpidr_el0 = 0x0000007faf42a700 tpidrro_el0 = 0x0000000000000000 par_el1 = 0xff00000004024980 mpidr_el1 = 0x0000000080000000 afsr0_el1 = 0x0000000000000000 afsr1_el1 = 0x0000000000000000 contextidr_el1 = 0x00000000000000f1 vbar_el1 = 0xffffffc010010800 cntp_ctl_el0 = 0x0000000000000005 cntp_cval_el0 = 0x000000000e45c556 cntv_ctl_el0 = 0x0000000000000000 cntv_cval_el0 = 0x0080000000000030 cntkctl_el1 = 0x0000000000000096 sp_el0 = 0x0000000004030e50 isr_el1 = 0x0000000000000040 dacr32_el2 = 0x0000000000000000 ifsr32_el2 = 0x0000000000000000 cpuectlr_el1 = 0x0000000000000040 cpumerrsr_el1 = 0x00000000001c00f2 l2merrsr_el1 = 0x80000100911820b0 cpuactlr_el1 = 0x00000000090ca000 icc_hppir0_el1 = 0x00000000000003fd icc_hppir1_el1 = 0x000000000000001e icc_ctlr_el3 = 0x0000000000000410 gicd_ispendr regs (Offsets 0x200 - 0x278) 0000000000000200: 0x0000000000000002 0000000000000208: 0x0000000000000000 0000000000000210: 0x0000000000000000 0000000000000218: 0x0000000000000000 0000000000000220: 0x0000000f00000024 0000000000000228: 0x0000000000000000 0000000000000230: 0x0000000000000000 0000000000000238: 0x0000002400000000 0000000000000240: 0x00000000000000c0 0000000000000248: 0x0000000000000000 0000000000000250: 0x0000000000000000 0000000000000258: 0x0000000000000000 0000000000000260: 0x0000000000000000 0000000000000268: 0x0000000000000000 0000000000000270: 0x0000000000000000 0000000000000278: 0x0000000000000000 Unhandled Exception in EL3. [...] It may just need something better than the standard heat sink. Even if it is not stable, the patch is still nice to have since it lets you flash a new bootloader without moving jumpers around and doing recovery using UART. Edited April 10 by Anders crashlog 0 Quote Link to post Share on other sites
Pali 12 Posted April 10 Share Posted April 10 There is just information that External Abort happened. Not sure what is the issue. Check that you have kernel with v3 version of a3720 cpufreq patches as in v3 was updated VDD value for load L1 when base freq is 1.2 GHz. Also can apply updated cpu_vdd_fallback.patch patch? It does not change behavior, only fixes printf for SVC REV: line. But it can can be useful to verify which CPU VDD value is used. 1 Quote Link to post Share on other sites
Anders 4 Posted April 11 Author Share Posted April 11 15 hours ago, Pali said: There is just information that External Abort happened. Not sure what is the issue. Check that you have kernel with v3 version of a3720 cpufreq patches as in v3 was updated VDD value for load L1 when base freq is 1.2 GHz. Also can apply updated cpu_vdd_fallback.patch patch? It does not change behavior, only fixes printf for SVC REV: line. But it can can be useful to verify which CPU VDD value is used. Can an External Abort trigger because of temps? I should already be on v3 of the a3720 cpufreq patches. Here's the output after fixing printf: TIM-1.0 mv_ddr-devel-g7c35173 DDR4 16b 1GB 1CS WTMI-devel-18.12.1-c444aeb-dirty WTMI: system early-init DDR topology parameters: ======================== ddr type DDR4 ddr speedbin 11 bus width 16-bits cs num 1 cs[0] - group num 0 cs[0] - bank num 8 cs[0] - capacity 1024MiB SVC REV: 5, CPU VDD voltage is invalid, using default value: 1.202V DRAM windows: ============= WIN[0] - base addr 0x60000000 WIN[0] - size 0x40000000 memory test region: =================== CS[0] 0x60000000 - 0x9fffffff SELF-REFRESH TEST PASSSetting clocks: CPU 1200 MHz, DDR 750 MHz VREF READ TRAINING PASSED VREF WRITE TRAINING PASSED DLL TUNING PASSED SELF-REFRESH TEST PASSNOTICE: Booting Trusted Firmware NOTICE: BL1: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2) NOTICE: BL1: Built : 15:18:32, Apr 11 2021 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2) NOTICE: BL2: Built : 15:18:32, Apr 11 2021 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2) NOTICE: BL31: Built : 15:18:32, Apr 11 2021 U-Boot 2021.04-00640-g3f2e3c7845 (Apr 10 2021 - 15:27:13 +0200) DRAM: 1 GiB WDT: Not starting Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 5 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 Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Card did not respond to voltage select! : -110 Net: eth0: neta@30000 [PRIME] Hit any key to stop autoboot: 0 I added a fan to my Espressobin, and I'm currently testing to see if that keeps it from crashing (running `stress --cpu 2` on the device. I've had it running for about 30 min so far). 1 Quote Link to post Share on other sites
Pali 12 Posted April 11 Share Posted April 11 Well, External Abort means that CPU tried to access memory on the bus (not internal CPU memory) and for some reason access (read or write) cannot be completed and it raised exception. Overheating may cause different issues and if some block on SoC stops working then abort may happen. From your log can be seen that base VDD voltage for 1.2 GHz CPU frequency is set to 1.202 V. Typical voltage for 1.2 GHz freq is documented by Marvell as 1.155 V. Higher voltage value makes CPU more stable, but also increase power usage and temperature. And of course higher temperature make CPU less stable. During testing 1 GHz mode when CPU voltage was too low I saw lot of times either this External Abort or segfault of random processes. So External Abort can be definitely caused by instability of CPU. But in your case it may be because of either high temperature or low voltage or something else... Also it may be because your SoC/CPU tested during manufactoring and checked that is not really stable for 1.2 GHz freq (and so written this information into OTP -- not defined VDD value for 1.2 GHz). 1 Quote Link to post Share on other sites
Pali 12 Posted April 11 Share Posted April 11 I have sent that fallback vdd voltage patch to Marvell: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/pull/18 3 Quote Link to post Share on other sites
Anders 4 Posted April 11 Author Share Posted April 11 @Pali Awesome. Adding a fan has kept my device from crashing: $ uptime -p up 7 hours, 42 minutes $ cpufreq-info [...] analyzing CPU 0: current CPU frequency is 1.20 GHz (asserted by call to hardware). cpufreq stats: 200 MHz:0.72%, 300 MHz:0.05%, 600 MHz:0.06%, 1.20 GHz:99.16% (2626) [...] analyzing CPU 1: current CPU frequency is 1.20 GHz (asserted by call to hardware). cpufreq stats: 200 MHz:0.72%, 300 MHz:0.05%, 600 MHz:0.06%, 1.20 GHz:99.16% (2628) [...] AFAIK that means that everything now works on my Espressobin v7 1GB board. The bootloader is stable, the CPU frequency is correctly reported and you can even clock the CPU at the advertised 1.2Ghz. Thanks @Pali! Where should direct my frustrations on why this has taken so long? Is it the fault of GlobalScale who failed to deliver on their mainline Linux support promise? Or is it Marvell who should have been more active in upstreaming their patches, instead of just providing an old kernel + a set of patches? 0 Quote Link to post Share on other sites
Pali 12 Posted Monday at 02:49 PM Share Posted Monday at 02:49 PM 16 hours ago, Anders said: Where should direct my frustrations on why this has taken so long? Is it the fault of GlobalScale who failed to deliver on their mainline Linux support promise? Or is it Marvell who should have been more active in upstreaming their patches, instead of just providing an old kernel + a set of patches? Well, I do not know. But I have not seen any contribution from globalscale in upstream. They were even lazy to document or say something about ddr4 initialization changes which they have done in their custom repositories forks as big hexdump blobs (@barish identified it and then prepared pull requests to Marvell with fixes!) Most initial A3720 work in upstream was done by Bootlin developers and then from more companies and individuals. If you look into kernel cpufreq driver for a37xx source code and git history, you will find here description about HW errata that CPU voltage is not stable when CPU is running at 1.2 GHz. This clearly identifies HW bug in A3720 SoC. So this is Marvell issue and affects all products based on A3720 (not only Espressobin). And if you look at patches which we sent to mailing list, we found another similar (hw?) bugs which affects also 1.0 GHz mode. So this is for Marvell as they have not addressed these issues yet. Thanks to Marek who very quickly wrote first three workaround patches. 0 Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.