Pali

aarch64 is supported by debian. Now I checked my espressobin box with debian and it is still working fine, boot without issue. So if it does not work for you, I suggest to report a bug with error log what does not work.

It should work fine. At least half year ago it worked without any issue. Any specific error?

No, it does not. I have already reported lines which needs to be adjusted for mainline version, but they ignored it. So build mainline version manually and avoid usage of old version which is in Armbian. There are lot of fixes in mainline firmware version.

Yes, email was send and received without any issue.

I updated link to V3 version. Anyway, this patch is just WIP and is not finished yet. If it is working fine, repond to email with your Tested-by line.

A38x has 32-bit ARM cores. A3720 has 64-bit A53 ARM cores. 64-bit ARM cores compared to 32-bit cores have additional instructions for crypto operations. And based on some tests it seems that some crypto done via 64-bit ARM blocks is really faster than crypto done on CESA on the same SoC. So the best is to do own tests and measure if CESA or ARM is faster. So think about it like that 64-bit ARM CPU itself has some kind of crypto accelerator engine.

Mainline U-Boot should really work fine. Just build ARM trusted firmware and U-Boot according to the latest guide: https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html (search for example how to build production release of Marvell firmware image)

This is fixed in new U-Boot version, which automatically adjust kernel's DTS file to set correct offset ot these partitions.

Just to note, some people reported this issue about instability of 1.2 GHz mode of A3720 SoC to Marvell gtihub bug tracker: https://github.com/MarvellEmbeddedProcessors/linux-marvell/issues/20 You could followup this ticket and provide to Marvell needed logs to help them debugging this issue.

Now that fix was backported to stable versions 5.14.6, 5.13.19, 5.10.67, 5.4.148, 4.19.207, 4.14.247, 4.9.283 and 4.4.284.

Hello @Heisath! This is known problem. QCA98xx wifi chips are buggy, have timing and detection issues related to PCIe, which Qualcomm confirmed. Qualcomm recommendation is to increase PCIe pulse detection and for some (x86) motherboards, vendors released a new BIOS which do it. To make it worse, Marvell A38x SoC has also buggy PCIe which cause other issues and therefore combination of QCA98xx and A38x cause even more issues. I'm preparing patches for pci-mvebu.c kernel driver to fix some issues, but they are not ready yet. For QCA98xx I have prepared patch which are currently on linux-pci mailing list: https://lore.kernel.org/linux-pci/20210505163357.16012-1-pali@kernel.org/ Could you test it and check if it helps with new kernel versions?

On normal Debian stable is kernel upgraded automatically and without any problem just via apt update && apt upgrade

I'm not surprised. You have more than 2 years old version. See table on https://www.kernel.org/ where is list of latest versions. Please upgrade to some new version, all mentioned fixes are from this year.

Yes, C100 code means 1 GHz variant of A3720 SoC. It is unstable in U-Boot or in running Linux system? Because in Linux kernel since version 5.13 are all patches mentioned above for testing. Patches were backported also in stable Linux kernel versions. Which version of Linux kernel are you using? And what does ot mean _still unstable_?

Marking is directly on the SoC. A3720 SoC chip is on the first picture, big square on left, second one from the top. It has big M logo, below it chip number (3720) with other information. Look at my previous comment.

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: https://lore.kernel.org/linux-pm/20210630135942.29730-1-kabel@kernel.org/t/#u If you have any input on this or reaction from Marvell / GlobalScale, please reply.

Patch was merged, so you can build and use firmware from Marvell repository.

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.

I have sent that fallback vdd voltage patch to Marvell: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/pull/18

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

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.

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.

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.

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.

It would be merged either into next -rc version or into next mainline version (depends on how maintainers decide). See https://www.kernel.org/ for current released versions. And see https://www.kernel.org/category/faq.html 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.