Pali

@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);

Sorry, no. I'm not going to take any role in any community.

No, never.

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? 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.

This is issue in ASMedia SATA controller card, not in Espressobin PCIe. Card announces support for 512 byte long PCIe packets, but when PCIe controller is configured for such long payload size then card cause system crash. We have reproduce this issue on other platform too. Marek sent kernel patch which adds quirk for this ASMedia SATA controller to set maximal payload size to 265 bytes https://lore.kernel.org/linux-pci/20210317115924.31885-1-kabel@kernel.org/T/#u and which should workaround this issue.

If you call 'boot' command it executes 'bootcmd' variable. And if you trace 'bootcmd' from your printenv output it can be clear that 'set_bootargs' is not called in this path. Seems that your 'bootcmd' ends in 'boot_a_script' variable which loads external boot script (from uSD card?) and this one boots kernel. Script can do anything, including setting new variables, etc. So it may be possible that this script set or does not set 'console' into 'bootargs'. You need to investigate it. You could try to unset 'console' (= booting without console=ttyMV0,115200), maybe it helps. For recent kernels this console should not be needed.

@Rötti: Also please boot linux kernel with console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 command line option so output on UART would contain full boot log.

Yes, ESPRESSObin_V7_1-0 with 88F3720-A0-C120 SoC. See whole discussion https://lore.kernel.org/linux-arm-kernel/20210209225630.mdwnzkvnaz3r4blt@pali/

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.

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 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.

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) 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. It is for Turris MOX, modular router: https://www.turris.com/en/mox/overview/

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/

@BenCranston Perfect, thank you for testing! Could you send an email reply to https://lore.kernel.org/lkml/20210114124032.12765-1-pali@kernel.org/ with your Tested-By: name line?

Ok! @BenCranston let us know if patches are working for you!

I have looked at email which you sent to mailing list https://lore.kernel.org/linux-ide/cbbb2496501fed013ccbeba524e8d573@posteo.de/T/#u and you did not provide all / enough information. At least output from lspci -nn -vv is needed to correctly identify type of your PCIe SATA controller. Also there is missing dmesg output between [ 0.000000] and [ 3.694604] period. Please provide these informations (to mailing list).

Do you mean loading firmware directly from SATA (without NOR)? Or loading firmware from NOR and only loading kernel from SATA? Last week I updated documentation how to build & store fimware to SATA disk (needs special partition), see: https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html (search for "SATA device boot") And last year I have tested that U-Boot loaded from NOR is able to access SATA disk and load kernel from it without need to use uSD card. If it does not work post U-Boot output from serial console.

You need to wait or you can try to remind your email on mailing list... I did not have time to look at it.

Perfect! Thank you for testing. Would you mind replying to that mailing list email with "Tested-by: your name" line? If it is stable on your board then I think other tests are not needed. You may try to enable ondemand governor and let board running under normal conditions for a longer time if you do not see any other issues.

@BenCranston We have sent second version of patches for A3720 which should make 1 GHz mode finally stable. See post https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/?do=findComment&comment=117511 If you want to test them, download all patches from emails via (raw) button near Message-ID: line and then apply them, either via `patch -p1 -i filename` or via `git am filename` (if working you have linux sources checkouted from git).

@RöttiThis looks like an AHCI or PCIe issue. Please report bug to the linux-ide@vger.kernel.org mailing list where are more SATA/AHCI developers and could help you to debug issue. Maybe it is also A3720 related PCIe issue, so send me an email I can provide you a A3720 PCIe patch which could fix some stability issues.

I have been communicating with Globalscaletechnologies and they confirmed me that LED2 is broken on v5 and cannot be fixed. On v7 it is working fine, I have prepared patch (now in mainline kernel) for it which other people tested and it worked. I do not have v7 so cannot show it, but relevant file is exported via /sys/class/leds/led2/brightness.

Hello! We have sent second version of patches for A3720 which should make 1 GHz mode finally stable: https://lore.kernel.org/linux-arm-kernel/20210114124032.12765-1-pali@kernel.org/

I have already wrote that led 2 connected to GPIO does not work on espressobin v5. And on espressobion v7 is already enabled and available in mainline kernel v7 dts files.

Yes, see my comment https://forum.armbian.com/topic/4089-espressobin-support-development-efforts/?do=findComment&comment=110303 After my tests it seems to be stable on 1GHz CPU, but testers are welcome! I'm planning to send a new version of patches. Do you have a board with 1.2GHz SOC variant? I'm asking because I have not seen Armada3720 SOC with 1.2GHz CPU yet. See my comment https://forum.armbian.com/topic/15059-espressobin-mainline-u-bootatf/?tab=comments#comment-109760 where I wrote how to detect CPU variant.

Which one is red led? IIRC espressobin v5 has only 2 leds: power which is always on (when power adapter is attached) and wifi led which is conrolled by wifi card (if you have e.g. ath9k card you can control it via ath9k driver). There is also third led (labeled led2) but this one is non-working due to HW bug.