Pali

  • Content Count

    49
  • Joined

Reputation Activity

  1. Like
    Pali got a reaction from barish in How to make ESPRESSObin v7 stable?   
    I have sent that fallback vdd voltage patch to Marvell: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/pull/18
  2. Like
    Pali got a reaction from barish in How to make ESPRESSObin v7 stable?   
    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).
  3. Like
    Pali got a reaction from guidol in How to make ESPRESSObin v7 stable?   
    I have sent that fallback vdd voltage patch to Marvell: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/pull/18
  4. Like
    Pali got a reaction from Anders in How to make ESPRESSObin v7 stable?   
    I have sent that fallback vdd voltage patch to Marvell: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/pull/18
  5. Like
    Pali got a reaction from barish in How to make ESPRESSObin v7 stable?   
    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.
  6. Like
    Pali got a reaction from barish in How to make ESPRESSObin v7 stable?   
    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.
  7. Like
    Pali reacted to Anders in How to make ESPRESSObin v7 stable?   
    Done! https://lore.kernel.org/linux-arm-kernel/cf766197-666f-3d7d-3b9e-ba512619004e@gmail.com/
  8. Like
    Pali got a reaction from lanefu in Espressobin support development efforts   
    @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).
     
    Other option is to clone my git kernel repository https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/ and compile kernel from it. Fixes are in branch a3720-cpufreq-issues.
     
  9. Like
    Pali got a reaction from Werner in How to make ESPRESSObin v7 stable?   
    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/
  10. Like
    Pali got a reaction from lanefu in Espressobin v5 - any luck to get true 1Ghz or 1.2 Ghz?   
    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.
     
  11. Like
    Pali got a reaction from Werner in How to make ESPRESSObin v7 stable?   
    Hello! We found out that stability issue is not specific to Espressobin V7, but also for other boards with Armada 3720 SOC. And mentioned patch from Victor Gu which sets minimal voltage to 1.108V for 500 MHz and lower speeds seems to fixes this issue.
     
    Marek prepared new patches for mainline kernel which include that Victor's patch and other fixes for armada 3720 cpufreq driver. See link:
    https://lore.kernel.org/linux-arm-kernel/20201009125711.0176752a@kernel.org/
     
    Could you please test these patches if they finally fix also your instability issues on Espressobin V7?
  12. Like
    Pali got a reaction from Werner in EspressoBin mainline u-boot/atf   
    @dhewg: There are more variants of A3720 SOC and they differs in CPU freq. Variant number is printed on SOC. So if you have SOC with 1GHz CPU you should use/flash 1GHz firmware image, if you have only SOC with 800MHz CPU then you should flash 800MHz image. In part order number documents is also 1.2GHz variant of SOC but I have not see it yet. No idea if Marvell started producing it.
     
    In this public document https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-37xx-hardware-specifications-2019-09.pdf at page 154 is decoder of numbers printed on SOC and on page 153 is decoder of numbers, important is speed code. Based on SOC chip which you have on your Espressobin you should prepare firmware (WTM+ATF+U-Boot) and flash it.
     
    So this if somebody flashed incorrect variant then it is probably reason for instability of Espressobin.
  13. Like
    Pali got a reaction from Werner in espressobin uboot security concerns switch init portmask   
    Hello @FoodGenius!
     
    Proper fix for this issue will be part of U-Boot version v2020.10-rc4.
     
    But instead of doing hack/workaround by completely disabling all lan ports, fix in U-Boot v2020.10 just disables forwarding packets between lan and wan interfaces.
     
    So packets from non-CPU ports would not be forwarded to other non-CPU ports (fixes this security issue) and packets from CPU port would be still forwarded to all other ports like before (so netboot will work as before via any port, unlike your workaround).
     
    Plus configuration is set prior enabling Topaz forwarding, so there is no time window in which insecure configuration is active.