• Content Count

  • Joined

About Pali

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Patch was merged, so you can build and use firmware from Marvell repository.
  2. 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 vo
  3. I have sent that fallback vdd voltage patch to Marvell:
  4. 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 st
  5. 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.
  6. 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
  7. Perfect! Thank you for testing. I will send this patch to Marvell. Ouch, this is a bug :-( I did mistake in that patch, in printf is missing svc_rev parameter. I updated post with my patch. 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 t
  8. These are old repositories. You should use upstream u-boot ( and upstream TF-A ( Also ensure that you have set correct DDR_TOPOLOGY= parameter. Whole build parameters are described in TF-A documentation at: 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.
  9. It would be merged either into next -rc version or into next mainline version (depends on how maintainers decide). See for current released versions. And see for question When will the next kernel be released? After it is merged into rc or mainline version then this patch (because it is marked as bugfix) would be automatically included also into all longterm versions. Unlikely. In case it is rejected it would mean it is needed to update this patch (fix issues) and Marek or me will do it.
  10. @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
  11. Sorry, no. I'm not going to take any role in any community.
  12. 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 o
  13. 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 and which should workaround this issue.
  14. 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 hel