Jump to content
  • 0

How to make ESPRESSObin v7 stable?

Anders

Asked by Anders,

 Share

Question

Anders

Anders

Posted
Posted (edited)
Armbianmonitor:
http://ix.io/1Jsj

Hi All!

 

I am having a lot of trouble making my ESPRESSObin v7 1GB DDR4 run without crashes. I have tried both Bionic (5.75 4.19.20) and Stretch (5.75 4.19.20) images, and neither are stable. I have tried with a lot of different PSUs (all switch-mode though) and booting from both microSD and USB sticks. My U-Boot is "flash-image-ddr4-1g-1cs-1000_800.bin".

 

It seems like there is about 50% chance that it will boot without a crash.

 

The type of crashes I get seems random. Ex

http://ix.io/1JGY

 

And then it just freezes.

 

Or this one which includes a proper kernel Oops:

http://ix.io/1JGZ

 

While running, I get errors like this one: 

[   71.136812] BUG: Bad page state in process khugepaged  pfn:31d99
[   71.140206] page:ffffffbf00c76640 count:0 mapcount:0 mapping:0000000000002000 index:0x0
[   71.148428] flags: 0x0()
[   71.151049] raw: 0000000000000000 0000000000000000 ffffffbf00c76648 0000000000002000
[   71.159015] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[   71.166975] page dumped because: non-NULL mapping
[   71.172329] BUG: Bad page state in process khugepaged  pfn:3261c
[   71.178001] page:ffffffbf00c98700 count:0 mapcount:0 mapping:0000000000002000 index:0x0
[   71.186236] flags: 0x0()
[   71.188853] raw: 0000000000000000 0000000000000000 ffffffbf00c98708 0000000000002000
[   71.196825] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[   71.204782] page dumped because: non-NULL mapping

 

 

Once successfully booted, setting the CPUfreq governor to "performance" seems to make it more stable.

 

Am I the only one having problems getting a stable boot on V7?

 

Has anyone of you any tips on how to make it stable? I am willing to try compiling a new kernel if some experimental patches exists.

Edited by Anders
0
Link to comment
Share on other sites

92 answers to this question

Recommended Posts

  • 0
Pali

Pali

Posted
Posted
On 2/23/2021 at 5:46 AM, Anders said:

Nice work. I'm unable to test it on my V7 1gb board though. Every time I fash it with a 1200mhz image, it bricks, and I can't even get to the uboot prompt.

 

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)

 

On 2/23/2021 at 5:46 AM, Anders said:

Are there anyone who's been able to boot the Espressobin V7 at 1.2 Ghz?

 

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.

 

On 2/23/2021 at 5:46 AM, Anders said:

By the way, who's sponsoring your work on this chip? :)

 

It is for Turris MOX, modular router: https://www.turris.com/en/mox/overview/

0
Link to comment
Share on other sites
Armbian is a community driven open source project. Do you like to contribute your code?

  • 0
Anders

Anders

Posted
  • Author
Posted

@Pali

 

Normal boot: 

TIM-1.0
WTMI-devel-18.12.1-0967979                                                   
WTMI: system early-init                                                      
SVC REV: 5, CPU VDD voltage: 1.155V                                          
NOTICE:  Booting Trusted Firmware                                            
NOTICE:  BL1: v1.5(release):1f8ca7e0 (Marvell-devel-18.12.2)
NOTICE:  BL1: Built : 10:12:00, Sep 18 2020
NOTICE:  BL1: Booting BL2               
NOTICE:  BL2: v1.5(release):1f8ca7e0 (Marvell-devel-18.12.2)
NOTICE:  BL2: Built : 10:12:01, Sep 18 2020
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v1.5(release):1f8ca7e0 (Marvell-devel-18.12.2)
NOTICE:  BL31: Built : 10:1

U-Boot 2018.03-devel-18.12.3-gc9aa92ce70-armbian (Sep 18 2020 - 10:07:21 +0200)

Model: Marvell Armada 3720 Community Board ESPRESSOBin
       CPU     1000 [MHz]
       L2      800 [MHz]
       TClock  200 [MHz]
       DDR     800 [MHz]
DRAM:  1 GiB
Comphy chip #0:
Comphy-0: USB3          5 Gbps    
Comphy-1: PEX0          2.5 Gbps  
Comphy-2: SATA0         6 Gbps    
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs
PCIE-0: Link down
MMC:   sdhci@d0000: 0
Loading Environment from SPI Flash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiBB
OK
Model: Marvell Armada 3720 Community Board ESPRESSOBin
Net:   eth0: neta@30000 [PRIME]
Hit any key to stop autoboot:  0

Marvell>> md d0012604 1; md d0012604 1; md d0012604 1
d0012604: 00000000                               ....
d0012604: 27236501                               .e#'
d0012604: 0000f580                               ....


With flash-image-ddr4-1g-1cs-1200_750.bin (md5sum 1c25222cd3cb9162547afa80eb280a26) from https://minio.k-space.ee/minio/armbian/dl/espressobin/u-boot/ I managed to get this output once:
  

TIM-1.0
WTMI-devel-18.12.1-0967979
WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 0.898V

That voltage seems low, right?

 

Do you still need me to pull the heat sink to get the lables / indentifiers printed on SoC chip?

0
Link to comment
Share on other sites
  • 0
Pali

Pali

Posted
Posted
14 minutes ago, Anders said:

  


Marvell>> md d0012604 1; md d0012604 1; md d0012604 1
d0012604: 00000000                               ....
d0012604: 27236501                               .e#'
d0012604: 0000f580                               ....

 

 

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

 

14 minutes ago, Anders said:

  


TIM-1.0
WTMI-devel-18.12.1-0967979
WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 0.898V

That voltage seems low, right?

 

Do you still need me to pull the heat sink to get the lables / indentifiers printed on SoC chip?

 

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.

0
Link to comment
Share on other sites
  • 0
Pali

Pali

Posted
Posted

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.

0
Link to comment
Share on other sites
  • 0
Anders

Anders

Posted
  • Author
Posted
On 2/25/2021 at 1:35 AM, Pali said:

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.

With a Espressobin board?

 

@all Are there anyone who's been able to boot using flash-image-ddr4-1g-1cs-1200_750.bin or flash-image-ddr4-2g-2cs-1200_750.bin, or should they be warned against on https://www.armbian.com/espressobin/ since they just soft brick your board?

 

It would also be nice if someone with a chip with readable labels could take a picture and share. You'll need to wriggle the heat-sink quite a bit (maybe easier if the board is warm). I'm my case, I could just put it back on the chip with the glue still working.

0
Link to comment
Share on other sites
  • 0
Igor

Igor

Posted
Posted
On 3/3/2021 at 11:22 AM, Anders said:

or should they be warned against on https://www.armbian.com/espressobin/ since they just soft brick your board?


We don't have maintainer for this board anymore - he moved to another hardware. We also never received a cent from anyone for trying to keep this HW usable. We only got one free sample from vendor and one (sadly the same revision) from their lead developer. Since this product was never more then 1/4 baken we wasted insane a lot of time for little gain. But our OS was probably the only usable ...

 

Changing board status to EOS is all I can do. If someone has a desire to take over and keep information on that page relevant (Community supported status), send me a private message.

1
Link to comment
Share on other sites
  • 0
Pali

Pali

Posted
Posted
On 3/4/2021 at 11:32 AM, Igor said:

we wasted insane a lot of time for little gain

 

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?

 

On 3/4/2021 at 11:32 AM, Igor said:

We also never received a cent from anyone for trying to keep this HW usable.

 

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.

0
Link to comment
Share on other sites
  • 0
lanefu

lanefu

Posted
Posted
27 minutes ago, Pali said:

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?

 

Primarily our project integrates patches and wrangles configurations to create repeatable image builds for SBCs.    Some maintainers are able to go a bit deeper and send device tree patches etc upstream.

 

30 minutes ago, Pali said:

Because the only thing which I saw, was removal of MAC addresses and claiming that this is the best for everybody.

 

Not familiar with the best for everybody statement.. I think the primary misconfiguration of the MAC was done by me..and in the early stages... and never got improved.  I acknowledged that on a prior thread.

 

32 minutes ago, Pali said:

We have made 1GHz variant of A3720 SoC stable.

 

Are you interested in taking a more formal maintainer role for the ebin with Armbian?   I'd be glad to introduce you to the build tool, and the ways we add patches etc if you like.

 

 

0
Link to comment
Share on other sites
  • 0
lanefu

lanefu

Posted
Posted
1 minute ago, Pali said:

No, never.

 

Okay..  There's another open role that you may be interested in:

We're looking for someone who's interested in the hardware, likes to post on the forum to discuss and share technical improvements, but also get angry about low participation, and take any opportunity available to insult the Armbian project and yell at developers and contributors who generally have good intentions.

 

Is that something you'd be interested in taking on?

1
Link to comment
Share on other sites
  • 0
Igor

Igor

Posted
Posted
1 hour ago, Pali said:

Because the only thing which I saw, was removal of MAC addresses and claiming that this is the best for everybody.


Core of Armbian involvement into this hardware goes 3-4 years before you showed up. When almost nothing worked well! When you start complaining about things you don't or don't want to understand, we already cease all activities in semy broken stage - we lost interest. I understand some other company or even more of them took this design and are trying make something out of it. It seems you are a part of one and you are certainly not wasting your private time for it.

 

1 hour ago, Pali said:

which is erasing MAC addresses or project which is wasting time without any result.

 

I explained you, why dirty hack existed. I guess you have a lot to learn.

 

1 hour ago, Pali said:

We have made 1GHz variant of A3720 SoC stable.


10 (?) more to go.

0
Link to comment
Share on other sites
  • 0
Pali

Pali

Posted
Posted (edited)

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

 

Edited by Pali
printf bug
0
Link to comment
Share on other sites
  • 0
Anders

Anders

Posted
  • Author
Posted

@Pali

 

This is how I attempted to build an image (inspired by http://wiki.espressobin.net/tiki-index.php?page=Build+From+Source+-+Bootloader): 

$ mkdir espressobin-bootloader && cd espressobin-bootloader
$ git clone https://github.com/MarvellEmbeddedProcessors/u-boot-marvell.git -b u-boot-2017.03-armada-17.10
$ git clone https://github.com/MarvellEmbeddedProcessors/atf-marvell.git -b atf-v1.3-armada-17.10
$ git clone https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell.git -b master
$ git clone https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git -b master

$ cd u-boot-marvell
$ export CROSS_COMPILE=aarch64-linux-gnu-
$ make mvebu_espressobin-88f3720_defconfig
$ sed -i 's/-Werror //' Makefile
$ make DEVICE_TREE=armada-3720-espressobin

$ cd ..
$ mkdir -p A3700-utils-marvell/ddr/tim_ddr
$ ln -sr A3700-utils-marvell/script/ A3700-utils-marvell/ddr/tim_ddr/script       
$ ln -sr A3700-utils-marvell/wtmi/ A3700-utils-marvell/ddr/tim_ddr/wtmi
$ ln -sr A3700-utils-marvell/tim/ A3700-utils-marvell/ddr/tim_ddr/tim
$ ln -sr A3700-utils-marvell/wtptp/linux/tbb_linux A3700-utils-marvell/wtptp/linux/TBB_linux

$ cd atf-marvell    
$ export BL33=../u-boot-marvell/u-boot.bin
$ make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=5 BOOTDEV=SPINOR PARTNUM=0 WTP=../A3700-utils-marvell/ MV_DDR_PATH=../mv-ddr-marvell/ PLAT=a3700 all fip

// Now copy build/a3700/debug/flash-image.bin to a FAT32 USB, and flash it on the device:
Marvell>> bubt flash-image.bin spi usb

       
This is what I got trying to boot this 1000Mhz image: 

TIM-1.0
mv_ddr-devel-g7c35173 DDR4 16b 1GB 1CS
WTMI-devel-18.12.1-c444aeb
WTMI: system early-init

DDR topology parameters:
========================
ddr type               DDR4
ddr speedbin           11
bus width              16-bits
cs num                 1
  cs[0] - group num    0
  cs[0] - bank num     8
  cs[0] - capacity     1024MiB
SVC REV: 5, CPU VDD voltage: 1.155V

DRAM windows:
=============
WIN[0] - base addr     0x60000000
WIN[0] - size          0x40000000

memory test region:
===================
CS[0]                  0x60000000 - 0x9fffffff

SELF-REFRESH TEST PASSSetting clocks: CPU 1000 MHz, DDR 800 MHz

VREF READ TRAINING PASSED
VREF WRITE TRAINING PASSED
DLL TUNING PASSED
ASSERT: mmap_add_region <96> : IS_PAGE_ALIGNED(base_va)

 

 

And with the new patch applied, and configured to 1200mhz:
  

$ cd ../A3700-utils-marvell/
$ make clean
$ git apply cpu_vdd_fallback.patch
$ cd ../atf-marvell
$ make distclean
$ make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 CLOCKSPRESET=CPU_1200_DDR_750 DDR_TOPOLOGY=5 BOOTDEV=SPINOR PARTNUM=0 WTP=../A3700-utils-marvell/ MV_DDR_PATH=../mv-ddr-marvell/ PLAT=a3700 all fip

 

This results in: 

TIM-1.0
mv_ddr-devel-g7c35173 DDR4 16b 1GB 1CS
WTMI-devel-18.12.1-c444aeb-dirty
WTMI: system early-init

DDR topology parameters:
========================
ddr type               DDR4
ddr speedbin           11
bus width              16-bits
cs num                 1
  cs[0] - group num    0
  cs[0] - bank num     8
  cs[0] - capacity     1024MiB
SVC REV: 536817928, CPU VDD voltage is invalid, using default value: 

DRAM windows:
=============
WIN[0] - base addr     0x60000000
WIN[0] - size          0x40000000

memory test region:
===================
CS[0]                  0x60000000 - 0x9fffffff

SELF-REFRESH TEST PASSSetting clocks: CPU 1200 MHz, DDR 750 MHz

VREF READ TRAINING PASSED
VREF WRITE TRAINING PASSED
DLL TUNING PASSED
ASSERT: mmap_add_region <96> : IS_PAGE_ALIGNED(base_va)

 

 

I think this is what is causing me problems: "No input file for TIMN is supplied". I'll continue working on it tomorrow night! 

[...]
TBB Version		: 3.3.12.1
TBB Date		: 2017-03-17

Start time: 04/08/21 23:49:06

CommandLineOptions:
-r ../A3700-utils-marvell//atf-ntim.txt -v -D 

Verifying Descriptor Integrity...


Parsing non trusted TIM...


Parsing Instruction Labels....

Finished Parsing Instruction Labels....

Parsing Instruction Labels....

Finished Parsing Instruction Labels....

Parsing Instruction Labels....

Finished Parsing Instruction Labels....
  Success: Non-trusted Tim Descriptor file parsing has completed successfully!

Processing non trusted TIM...


  Prepending ImageTag <0x57544d49> to image file: <../A3700-utils-marvell//wtmi/build/wtmi_h.bin>.

  Prepending ImageTag <0x4F424d49> to image file: <./build/a3700/debug/boot-image_h.bin>.

'TIM_ATF.bin' size in bytes: 3064

Tim size to hash read from file: 3064

TIM Hash size (in bits) 256
0xEED27F4D
0xC1E7B5BF
0x93AC3F05
0x4440324F
0x10AB1D38
0x4536F14F
0x42199E01
0x2F67F28B



  Success: NTIM Processing has completed successfully!


Finish time: 04/08/21 23:49:06

TBB Exiting...!

Building flash image
../A3700-utils-marvell//script/buildtim.sh 0 SPINOR ../A3700-utils-marvell//tim/untrusted ../A3700-utils-marvell//ddr/tim_ddr CPU_1000_DDR_800 5 0 1 ../A3700-utils-marvell//atf-ntim.txt   1
sed -i 's|WTMI_IMG|../A3700-utils-marvell//wtmi/build/wtmi.bin|1' ../A3700-utils-marvell//atf-ntim.txt
sed -i 's|BOOT_IMAGE|./build/a3700/debug/boot-image.bin|1' ../A3700-utils-marvell//atf-ntim.txt
../A3700-utils-marvell//wtptp/linux/TBB_linux -r ../A3700-utils-marvell//atf-ntim.txt -v -D


TBB Version		: 3.3.12.1
TBB Date		: 2017-03-17

Start time: 04/08/21 23:49:06

CommandLineOptions:
-r ../A3700-utils-marvell//atf-ntim.txt -v -D 

Verifying Descriptor Integrity...


Parsing non trusted TIM...


Parsing Instruction Labels....

Finished Parsing Instruction Labels....

Parsing Instruction Labels....

Finished Parsing Instruction Labels....

Parsing Instruction Labels....

Finished Parsing Instruction Labels....
  Success: Non-trusted Tim Descriptor file parsing has completed successfully!

Processing non trusted TIM...


  Prepending ImageTag <0x57544d49> to image file: <../A3700-utils-marvell//wtmi/build/wtmi_h.bin>.

  Prepending ImageTag <0x4F424d49> to image file: <./build/a3700/debug/boot-image_h.bin>.

'TIM_ATF.bin' size in bytes: 3780

Tim size to hash read from file: 3780

TIM Hash size (in bits) 256
0xD38D2762
0xBA346897
0x6BB1D740
0xD44AB2CF
0x2C52F87B
0x92A99738
0x515873A2
0xD6648666



  Success: NTIM Processing has completed successfully!


Finish time: 04/08/21 23:49:06

TBB Exiting...!
../A3700-utils-marvell//script/tim2img.pl -i ../A3700-utils-marvell//atf-ntim.txt -o ./build/a3700/debug/flash-image.bin
No input file for TIMN is supplied
Total number of images to process in file[0] - 3
0 Image at offset 00000000 is TIM_ATF.bin
1 Image at offset 00004000 is ../A3700-utils-marvell//wtmi/build/wtmi.bin
2 Image at offset 00015000 is ./build/a3700/debug/boot-image.bin
Total number of images 3

 

0
Link to comment
Share on other sites
  • 0
Pali

Pali

Posted
Posted
2 hours ago, Anders said: 


$ git clone https://github.com/MarvellEmbeddedProcessors/u-boot-marvell.git -b u-boot-2017.03-armada-17.10
$ git clone https://github.com/MarvellEmbeddedProcessors/atf-marvell.git -b atf-v1.3-armada-17.10

 

 

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.

0
Link to comment
Share on other sites
  • 0
Anders

Anders

Posted
  • Author
Posted

@Pali

That actually seems to work: 

TIM-1.0
mv_ddr-devel-g7c35173 DDR4 16b 1GB 1CS
WTMI-devel-18.12.1-c444aeb-dirty
WTMI: system early-init

DDR topology parameters:
========================
ddr type               DDR4
ddr speedbin           11
bus width              16-bits
cs num                 1
  cs[0] - group num    0
  cs[0] - bank num     8
  cs[0] - capacity     1024MiB
SVC REV: 536817928, CPU VDD voltage is invalid, using default value: 

DRAM windows:
=============
WIN[0] - base addr     0x60000000
WIN[0] - size          0x40000000

memory test region:
===================
CS[0]                  0x60000000 - 0x9fffffff

SELF-REFRESH TEST PASSSetting clocks: CPU 1200 MHz, DDR 750 MHz

VREF READ TRAINING PASSED
VREF WRITE TRAINING PASSED
DLL TUNING PASSED

SELF-REFRESH TEST PASSNOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2)
NOTICE:  BL1: Built : 15:37:24, Apr 10 2021
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2)
NOTICE:  BL2: Built : 15:37:24, Apr 10 2021
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2)
NOTICE:  BL31: Built : 15:37:24, Apr 10 2021


U-Boot 2021.04-00640-g3f2e3c7845 (Apr 10 2021 - 15:27:13 +0200)

DRAM:  1 GiB
WDT:   Not starting
Comphy-0: USB3_HOST0    5 Gbps    
Comphy-1: PEX0          2.5 Gbps  
Comphy-2: SATA0         5 Gbps    
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs 
PCIE-0: Link down
MMC:   sdhci@d0000: 0, sdhci@d8000: 1
Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Globalscale Marvell ESPRESSOBin Board
Card did not respond to voltage select! : -110
Net:   eth0: neta@30000 [PRIME]
Hit any key to stop autoboot:  0

  

anders@espressobin:~$ uname -a
Linux espressobin 5.11.0+ #1 SMP PREEMPT Wed Mar 3 11:51:48 CET 2021 aarch64 aarch64 aarch64 GNU/Linux
anders@espressobin:~$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 0.97 ms.
  hardware limits: 200 MHz - 1.20 GHz
  available frequency steps: 200 MHz, 300 MHz, 600 MHz, 1.20 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 200 MHz and 1.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 600 MHz (asserted by call to hardware).
  cpufreq stats: 200 MHz:79.25%, 300 MHz:5.20%, 600 MHz:1.47%, 1.20 GHz:14.08%  (1095)
analyzing CPU 1:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0 1
  maximum transition latency: 0.97 ms.
  hardware limits: 200 MHz - 1.20 GHz
  available frequency steps: 200 MHz, 300 MHz, 600 MHz, 1.20 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil
  current policy: frequency should be within 200 MHz and 1.20 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 600 MHz (asserted by call to hardware).
  cpufreq stats: 200 MHz:79.25%, 300 MHz:5.20%, 600 MHz:1.47%, 1.20 GHz:14.08%  (1095)
anders@espressobin:~$ 7za b

7-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs LE)

LE
CPU Freq:  1195  1197  1197  1197  1197  1197  1197  1197  1196

RAM size:     983 MB,  # CPU hardware threads:   2
RAM usage:    441 MB,  # Benchmark threads:      2

                       Compressing  |                  Decompressing
Dict     Speed Usage    R/U Rating  |      Speed Usage    R/U Rating
         KiB/s     %   MIPS   MIPS  |      KiB/s     %   MIPS   MIPS

22:       1013   159    621    986  |      26035   199   1115   2223
23:        994   158    640   1013  |      25584   199   1110   2215
24:        989   159    667   1064  |      24925   198   1103   2188
25:        982   160    703   1122  |      24618   199   1099   2191
----------------------------------  | ------------------------------
Avr:             159    658   1046  |              199   1107   2204
Tot:             179    882   1625

 

For reference, this is how I built the bootloader (cpu_vdd_fallback.patch contains the patch you posted for wtmi/sys_init/avs.c): 

$ git clone https://source.denx.de/u-boot/u-boot.git
$ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
$ git clone https://github.com/weidai11/cryptopp.git
$ git clone https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell.git
$ git clone https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git

$ cd u-boot
$ export CROSS_COMPILE=aarch64-linux-gnu-
$ make mvebu_espressobin-88f3720_defconfig
$ make DEVICE_TREE=armada-3720-espressobin -j$(nproc)

$ cd ../A3700-utils-marvell/
$ git apply cpu_vdd_fallback.patch

$ cd ../trusted-firmware-a/
$ export BL33=../u-boot/u-boot.bin
$ make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 CLOCKSPRESET=CPU_1200_DDR_750 DDR_TOPOLOGY=5 WTP="$(realpath ../A3700-utils-marvell/)" MV_DDR_PATH=../mv-ddr-marvell/ CRYPTOPP_PATH="$(realpath ../cryptopp/)" PLAT=a3700 mrvl_flash -j$(nproc)

 

I'll let you know if I get a crash.

 

Should I be concerned about temperatures? How can I read the CPU temperature?

0
Link to comment
Share on other sites
  • 0
Anders

Anders

Posted
  • Author
Posted

Another nice-to-have is proper powerdown handling: 

anders@espressobin:~$ sudo shutdown -hP now
[...]
[  921.950348] reboot: Power down
ERROR:   a3700_system_off needs to be implemented
BACKTRACE: START: a3700_system_off
0: EL3: 0x4024d34
1: EL3: 0x4023834
2: EL3: 0x4029c2c
3: EL3: 0x4029b34
4: EL3: 0x402a43c
5: EL3: 0x4024ba0
BACKTRACE: END: a3700_system_off
Unhandled Exception from EL1
x0             = 0x0000000084000008
[...]

 

0
Link to comment
Share on other sites
  • 0
Pali

Pali

Posted
Posted
4 minutes ago, Anders said:

@Pali

That actually seems to work:

 

Perfect! Thank you for testing. I will send this patch to Marvell.

 

4 minutes ago, Anders said: 

SVC REV: 536817928, CPU VDD voltage is invalid, using default value:

 

 

Ouch, this is a bug :-( I did mistake in that patch, in printf is missing svc_rev parameter. I updated post with my patch.

 

4 minutes ago, Anders said:

I'll let you know if I get a crash.

 

Should I be concerned about temperatures? How can I read the CPU temperature?

 

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.

0
Link to comment
Share on other sites
  • 0
Pali

Pali

Posted
Posted
5 minutes ago, Anders said:

Another nice-to-have is proper powerdown handling: 


anders@espressobin:~$ sudo shutdown -hP now
[...]
[  921.950348] reboot: Power down
ERROR:   a3700_system_off needs to be implemented
BACKTRACE: START: a3700_system_off
0: EL3: 0x4024d34
1: EL3: 0x4023834
2: EL3: 0x4029c2c
3: EL3: 0x4029b34
4: EL3: 0x402a43c
5: EL3: 0x4024ba0
BACKTRACE: END: a3700_system_off
Unhandled Exception from EL1
x0             = 0x0000000084000008
[...]

 

 

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.

1
Link to comment
Share on other sites
  • 0
Anders

Anders

Posted
  • Author
Posted (edited)
8 hours ago, Pali said:

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.

Entering a low power state would be nice.

 

I just got a crash on 1200Mhz. It may be due to temperature. I'm trying to reproduce it now to get a crashlog.

 

Got something: 

TIM-1.0
mv_ddr-devel-g7c35173 DDR4 16b 1GB 1CS
WTMI-devel-18.12.1-c444aeb-dirty
WTMI: system early-init

DDR topology parameters:
========================
ddr type               DDR4
ddr speedbin           11
bus width              16-bits
cs num                 1
  cs[0] - group num    0
  cs[0] - bank num     8
  cs[0] - capacity     1024MiB
SVC REV: 536817928, CPU VDD voltage is invalid, using default value: 

DRAM windows:
=============
WIN[0] - base addr     0x60000000
WIN[0] - size          0x40000000

memory test region:
===================
CS[0]                  0x60000000 - 0x9fffffff

SELF-REFRESH TEST PASSSetting clocks: CPU 1200 MHz, DDR 750 MHz

VREF READ TRAINING PASSED
VREF WRITE TRAINING PASSED
DLL TUNING PASSED

SELF-REFRESH TEST PASSNOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2)
NOTICE:  BL1: Built : 15:37:24, Apr 10 2021
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2)
NOTICE:  BL2: Built : 15:37:24, Apr 10 2021
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2)
NOTICE:  BL31: Built : 15:37:24, Apr 10 2021


U-Boot 2021.04-00640-g3f2e3c7845 (Apr 10 2021 - 15:27:13 +0200)

DRAM:  1 GiB
WDT:   Not starting
Comphy-0: USB3_HOST0    5 Gbps    
Comphy-1: PEX0          2.5 Gbps  
Comphy-2: SATA0         5 Gbps    
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs 
PCIE-0: Link down
MMC:   sdhci@d0000: 0, sdhci@d8000: 1
Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Globalscale Marvell ESPRESSOBin Board
Card did not respond to voltage select! : -110
Net:   eth0: neta@30000 [PRIME]
Hit any key to stop autoboot:  0 
starting USB...
Bus usb@58000: Register 2000104 NbrPorts 2
Starting the controller
USB XHCI 1.00
Bus usb@5e000: USB EHCI 1.00
scanning bus usb@58000 for devices... 1 USB Device(s) found
scanning bus usb@5e000 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
/
Can't set block device
## Executing script at 06d00000
Wrong image format for "source" command
/boot/
Can't set block device
## Executing script at 06d00000
Wrong image format for "source" command
scanning bus for devices...

Device 0: unknown device
/
Can't set block device
## Executing script at 06d00000
Wrong image format for "source" command
/boot/
Can't set block device
## Executing script at 06d00000
Wrong image format for "source" command
/
Can't set block device
## Executing script at 06d00000
Wrong image format for "source" command
/boot/
Can't set block device
## Executing script at 06d00000
Wrong image format for "source" command
/
Failed to load '/boot.scr'
## Executing script at 06d00000
Wrong image format for "source" command
/boot/
1119 bytes read in 17 ms (63.5 KiB/s)
## Executing script at 06d00000
237 bytes read in 14 ms (15.6 KiB/s)
21432832 bytes read in 910 ms (22.5 MiB/s)
12287307 bytes read in 533 ms (22 MiB/s)
Failed to load '/boot/dtb/marvell/armada-3720-community.dtb'
11459 bytes read in 35 ms (319.3 KiB/s)
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    12287243 Bytes = 11.7 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 06000000
   Booting using the fdt blob at 0x6000000
   Loading Ramdisk to 3ef51000, end 3fb08d0b ... OK
   Using Device Tree in place at 0000000006000000, end 0000000006005cc2

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.11.0+ (anders@ubuntu-desktop) (aarch64-linux-gnu-gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1 SMP PREEMPT Wed Mar 3 11:51:48 CET 2021
[    0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board
[    0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '')
[    0.000000] printk: bootconsole [ar3700_uart0] enabled
Loading, please wait...
starting version 237
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Will now check root file system ... fsck from util-linux 2.31.1
[/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 
/dev/mmcblk0p1 was not cleanly unmounted, check forced.
ERROR:   Unhandled External Abort received on 0x80000000 at EL3! /  7.0%   
ERROR:    exception reason=0 syndrome=0xbf000001
BACKTRACE: START: plat_ea_handler
0: EL3: 0x4024d34
1: EL3: 0x4028438
2: EL3: 0x402416c
BACKTRACE: END: plat_ea_handler
Unhandled Exception from EL0
x0             = 0x00000055a51c5f60
x1             = 0x00000055a51add20
x2             = 0x00000000000008b0
x3             = 0x00000055a51c6620
x4             = 0x00000055a51ae620
x5             = 0x00000055a51c6f60
x6             = 0x432e6d6574737953
x7             = 0x746e656e6f706d6f
x8             = 0x6f432e6c65646f4d
x9             = 0x6f697469736f706d
x10            = 0x70642e6c6c642e6e
x11            = 0x000077656e2d676b
x12            = 0x0132003c000580ea
x13            = 0x432e6d6574737953
x14            = 0x0000000000000000
x15            = 0x0000000000000000
x16            = 0x0000007faf405bd8
x17            = 0x0000007faf241f90
x18            = 0x0000007faf312a70
x19            = 0x00000055a51a8098
x20            = 0x0000000000000000
x21            = 0x00000055a51c5f60
x22            = 0x00000055a51a7f60
x23            = 0x00000055a51a8030
x24            = 0x0000000000000001
x25            = 0x0000000000181e01
x26            = 0x0000007fdba04d08
x27            = 0x0000000000000040
x28            = 0x00000055a51c5f60
x29            = 0x0000007fdba04ca0
x30            = 0x0000007faf3eaf28
scr_el3        = 0x0000000000000739
sctlr_el3      = 0x0000000030cd183f
cptr_el3       = 0x0000000000000000
tcr_el3        = 0x0000000080803520
daif           = 0x00000000000002c0
mair_el3       = 0x00000000004404ff
spsr_el3       = 0x0000000020000000
elr_el3        = 0x0000007faf2420c4
ttbr0_el3      = 0x0000000004031c80
esr_el3        = 0x00000000bf000001
far_el3        = 0x0000000000000000
spsr_el1       = 0x0000000020001000
elr_el1        = 0x0000007faf27ff9c
spsr_abt       = 0x0000000000000000
spsr_und       = 0x0000000000000000
spsr_irq       = 0x0000000000000000
spsr_fiq       = 0x0000000000000000
sctlr_el1      = 0x0000000034d4d91d
actlr_el1      = 0x0000000000000000
cpacr_el1      = 0x0000000000300000
csselr_el1     = 0x0000000000000000
sp_el1         = 0xffffffc011704000
esr_el1        = 0x0000000056000000
ttbr0_el1      = 0x000000003f1e0000
ttbr1_el1      = 0x01040000080ec000
mair_el1       = 0x000c0400bb44ffff
amair_el1      = 0x0000000000000000
tcr_el1        = 0x00000032b5593519
tpidr_el1      = 0xffffffc02ec2f000
tpidr_el0      = 0x0000007faf42a700
tpidrro_el0    = 0x0000000000000000
par_el1        = 0xff00000004024980
mpidr_el1      = 0x0000000080000000
afsr0_el1      = 0x0000000000000000
afsr1_el1      = 0x0000000000000000
contextidr_el1 = 0x00000000000000f1
vbar_el1       = 0xffffffc010010800
cntp_ctl_el0   = 0x0000000000000005
cntp_cval_el0  = 0x000000000e45c556
cntv_ctl_el0   = 0x0000000000000000
cntv_cval_el0  = 0x0080000000000030
cntkctl_el1    = 0x0000000000000096
sp_el0         = 0x0000000004030e50
isr_el1        = 0x0000000000000040
dacr32_el2     = 0x0000000000000000
ifsr32_el2     = 0x0000000000000000
cpuectlr_el1   = 0x0000000000000040
cpumerrsr_el1  = 0x00000000001c00f2
l2merrsr_el1   = 0x80000100911820b0
cpuactlr_el1   = 0x00000000090ca000
icc_hppir0_el1 = 0x00000000000003fd
icc_hppir1_el1 = 0x000000000000001e
icc_ctlr_el3   = 0x0000000000000410
gicd_ispendr regs (Offsets 0x200 - 0x278)
0000000000000200:               0x0000000000000002
0000000000000208:               0x0000000000000000
0000000000000210:               0x0000000000000000
0000000000000218:               0x0000000000000000
0000000000000220:               0x0000000f00000024
0000000000000228:               0x0000000000000000
0000000000000230:               0x0000000000000000
0000000000000238:               0x0000002400000000
0000000000000240:               0x00000000000000c0
0000000000000248:               0x0000000000000000
0000000000000250:               0x0000000000000000
0000000000000258:               0x0000000000000000
0000000000000260:               0x0000000000000000
0000000000000268:               0x0000000000000000
0000000000000270:               0x0000000000000000
0000000000000278:               0x0000000000000000
Unhandled Exception in EL3.
[...]

 

It may just need something better than the standard heat sink.

 

Even if it is not stable, the patch is still nice to have since it lets you flash a new bootloader without moving jumpers around and doing recovery using UART.

Edited by Anders
crashlog
0
Link to comment
Share on other sites
  • 0
Pali

Pali

Posted
Posted

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.

1
Link to comment
Share on other sites
  • 0
Anders

Anders

Posted
  • Author
Posted
15 hours ago, Pali said:

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.

 

Can an External Abort trigger because of temps?

 

I should already be on v3 of the a3720 cpufreq patches.

 

Here's the output after fixing printf: 

TIM-1.0
mv_ddr-devel-g7c35173 DDR4 16b 1GB 1CS
WTMI-devel-18.12.1-c444aeb-dirty
WTMI: system early-init

DDR topology parameters:
========================
ddr type               DDR4
ddr speedbin           11
bus width              16-bits
cs num                 1
  cs[0] - group num    0
  cs[0] - bank num     8
  cs[0] - capacity     1024MiB
SVC REV: 5, CPU VDD voltage is invalid, using default value: 1.202V

DRAM windows:
=============
WIN[0] - base addr     0x60000000
WIN[0] - size          0x40000000

memory test region:
===================
CS[0]                  0x60000000 - 0x9fffffff

SELF-REFRESH TEST PASSSetting clocks: CPU 1200 MHz, DDR 750 MHz

VREF READ TRAINING PASSED
VREF WRITE TRAINING PASSED
DLL TUNING PASSED

SELF-REFRESH TEST PASSNOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2)
NOTICE:  BL1: Built : 15:18:32, Apr 11 2021
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2)
NOTICE:  BL2: Built : 15:18:32, Apr 11 2021
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.4(debug):v2.4-556-g8078b5c5a (Marvell-devel-18.12.2)
NOTICE:  BL31: Built : 15:18:32, Apr 11 2021


U-Boot 2021.04-00640-g3f2e3c7845 (Apr 10 2021 - 15:27:13 +0200)

DRAM:  1 GiB
WDT:   Not starting
Comphy-0: USB3_HOST0    5 Gbps    
Comphy-1: PEX0          2.5 Gbps  
Comphy-2: SATA0         5 Gbps    
SATA link 0 timeout.
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
flags: ncq led only pmp fbss pio slum part sxs 
PCIE-0: Link down
MMC:   sdhci@d0000: 0, sdhci@d8000: 1
Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Globalscale Marvell ESPRESSOBin Board
Card did not respond to voltage select! : -110
Net:   eth0: neta@30000 [PRIME]
Hit any key to stop autoboot:  0

 

 

I added a fan to my Espressobin, and I'm currently testing to see if that keeps it from crashing (running `stress --cpu 2` on the device. I've had it running for about 30 min so far).

1
Link to comment
Share on other sites
  • 0
Pali

Pali

Posted
Posted

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

1
Link to comment
Share on other sites
  • 0
Anders

Anders

Posted
  • Author
Posted

@Pali

Awesome.

 

Adding a fan has kept my device from crashing: 

$ uptime -p
up 7 hours, 42 minutes
$ cpufreq-info
[...]
analyzing CPU 0:
current CPU frequency is 1.20 GHz (asserted by call to hardware).
  cpufreq stats: 200 MHz:0.72%, 300 MHz:0.05%, 600 MHz:0.06%, 1.20 GHz:99.16%  (2626)
[...]
analyzing CPU 1:
  current CPU frequency is 1.20 GHz (asserted by call to hardware).
  cpufreq stats: 200 MHz:0.72%, 300 MHz:0.05%, 600 MHz:0.06%, 1.20 GHz:99.16%  (2628)
[...]

 

 

AFAIK that means that everything now works on my Espressobin v7 1GB board. The bootloader is stable, the CPU frequency is correctly reported and you can even clock the CPU at the advertised 1.2Ghz.

Thanks @Pali!

 

Where should direct my frustrations on why this has taken so long? Is it the fault of GlobalScale who failed to deliver on their mainline Linux support promise? Or is it Marvell who should have been more active in upstreaming their patches, instead of just providing an old kernel + a set of patches?

0
Link to comment
Share on other sites
  • 0
Pali

Pali

Posted
Posted
16 hours ago, Anders said:

Where should direct my frustrations on why this has taken so long? Is it the fault of GlobalScale who failed to deliver on their mainline Linux support promise? Or is it Marvell who should have been more active in upstreaming their patches, instead of just providing an old kernel + a set of patches?

 

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.

0
Link to comment
Share on other sites
  • 0
Pali

Pali

Posted
Posted

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.

1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
 Share
Go to question listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept