• Posts

  • Joined

Recent Profile Visitors

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

Pali's Achievements

  1. It looks like that even with latest patches is 1.2 GHz mode unstable on more boards. Therefore there is a proposed patch which completely disables cpufreq driver on 1.2 GHz variant of all A3720 SoC including Espressobin: If you have any input on this or reaction from Marvell / GlobalScale, please reply.
  2. Patch was merged, so you can build and use firmware from Marvell repository.
  3. 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.
  4. I have sent that fallback vdd voltage patch to Marvell:
  5. 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).
  6. 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. 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.
  8. 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 too hot. I was told that SoC should have some sensor for HW overheat detection, but not sure how it works.
  9. 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.
  10. 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. For rest of armbian related questions ask armbian people.
  11. @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);
  12. Sorry, no. I'm not going to take any role in any community.
  13. 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.
  14. 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.