Anders
-
Posts
30 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Anders
-
-
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).
-
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.
-
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 [...]
-
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 1625For 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?
-
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
-
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.
-
Interesting. All marketing on espressobin.net and from Globalscale claims that this chip is 1.2Ghz capable.
I'm going to need some help interpreting the labels on the chip:
https://drive.google.com/file/d/1dqvT6HzcH9VCEb4dPryXie61xP3WwY0B/view?usp=sharing
https://drive.google.com/file/d/1rldOzYHm3nWbHMIr08oCoLps1hM9dq_R/view?usp=sharing
-
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?
-
8 hours ago, Pali said:
Just to note, we have sent a new version (v3) of Armada 37xx cpufreq patches, now with fixes for 1.2 GHz boards: https://lore.kernel.org/linux-arm-kernel/20210222194158.12342-1-pali@kernel.org/
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.
Are there anyone who's been able to boot the Espressobin V7 at 1.2 Ghz?
By the way, who's sponsoring your work on this chip?
-
On 2/1/2021 at 1:09 AM, Pali said:
Perfect! Thank you for testing. Would you mind replying to that mailing list email with "Tested-by: your name" line? If it is stable on your board then I think other tests are not needed. You may try to enable ondemand governor and let board running under normal conditions for a longer time if you do not see any other issues.
Done! https://lore.kernel.org/linux-arm-kernel/cf766197-666f-3d7d-3b9e-ba512619004e@gmail.com/
-
Hi @Pali
Thank you for looking at this problem!
I updated my u-boot to flash-image-ddr4-1g-1cs-1000_800-2021-01-03.bin (sha256: e3a9d9605d5a9ad1ff848985c18b1ce41c2dddfffcc8f8364f2d57d833e652bb), and built your kernel like this:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git --depth 1 -b a3720-cpufreq-issues $ export ARCH=arm64 $ export CROSS_COMPILE=aarch64-linux-gnu- $ curl https://raw.githubusercontent.com/armbian/build/master/config/kernel/linux-mvebu64-current.config > .config $ make oldconfig (picked default for all new) $ make -j $(nproc) $ cp arch/arm64/boot/Image /mnt/sdcard/boot/ $ cp arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtb /mnt/sdcard/boot/dtb/marvell/ $ make modules_install INSTALL_MOD_PATH=/mnt/sdcard/
This is the result:
root@espressobin:~# uname -a Linux espressobin 5.11.0-rc1+ #1 SMP PREEMPT Sun Jan 31 23:35:17 CET 2021 aarch64 aarch64 aarch64 GNU/Linux root@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 - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:34.71%, 250 MHz:13.20%, 500 MHz:6.26%, 1000 MHz:45.83% (2015) 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 - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 500 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:34.71%, 250 MHz:13.20%, 500 MHz:6.26%, 1000 MHz:45.83% (2015) root@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: 974 997 993 996 997 997 996 997 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: 879 153 560 856 | 21904 199 941 1870 23: 871 154 576 888 | 21518 199 938 1863 24: 863 154 603 928 | 21147 199 935 1857 25: 857 154 634 979 | 20885 199 934 1859 ---------------------------------- | ------------------------------ Avr: 154 593 913 | 199 937 1862 Tot: 176 765 1387Yay! 1Ghz is finally working and is stable on Espressobin v7!
And the new u-boot seems to boot every time!
This is great - thanks! Time to push to mainline Linux, or do you want me to run more tests?
-
I'm getting tired of Globalscale deleting my post from the Espressobin forums, instead of either fixing or acknowledging the problem.
So I'll repost this here for future reference. This is the URL to the original thread: http://espressobin.net/forums/topic/mainline-linux-not-running-at-1ghz/
Hi All
That the Espressobin aims to support mainline is awesome – a lot of the benefits are described here http://espressobin.net/mainline-linux/.
But I’m unable to get my v7 board running at more than 800MHz using the mainline kernel (for some reason cpufreq-info insists on reporting 1GHz with actual benchmarking only showing 800MHz).
For the sake of this post, I tried pulling the most recent linux-next kernel. I’m using the config file from armbian.
export ARCH=arm64 export CROSS_COMPILE=aarch64-linux-gnu- git checkout next-20190614 curl https://raw.githubusercontent.com/armbian/build/master/config/kernel/linux-mvebu64-next.config > .config make oldconfig # Just picked the defaults for new options make -j7 Image dtbs modules cp arch/arm64/boot/Image /mnt/sdcard/boot/ cp arch/arm64/boot/dts/marvell/armada-3720-espressobin.dtb /mnt/sdcard/boot/dtb/marvell/ make modules_install INSTALL_MOD_PATH=/mnt/sdcard/
Here are the results. Notice the performance numbers and CPU Freq reported by 7-Zip:
root@espressobin:~# uname -a Linux espressobin 5.2.0-rc4-next-20190614 #7 SMP PREEMPT Sun Jun 16 10:27:52 CEST 2019 aarch64 GNU/Linux root@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 - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 250 MHz and 1000 MHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:0.09%, 250 MHz:3.60%, 500 MHz:0.16%, 1000 MHz:96.15% (152) 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 - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 250 MHz and 1000 MHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 1000 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:0.09%, 250 MHz:3.60%, 500 MHz:0.16%, 1000 MHz:96.15% (152) root@espressobin:~# lscpu Architecture: aarch64 Byte Order: Little Endian CPU(s): 2 On-line CPU(s) list: 0,1 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 1 NUMA node(s): 1 Model: 4 CPU max MHz: 1000.0000 CPU min MHz: 200.0000 BogoMIPS: 25.00 NUMA node0 CPU(s): 0,1 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid root@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: 794 794 794 794 794 794 794 794 RAM size: 986 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: 709 148 467 690 | 17938 199 771 1532 23: 701 149 480 715 | 17737 199 770 1535 24: 696 149 503 749 | 17395 199 768 1527 25: 688 149 528 786 | 17149 198 769 1526 ---------------------------------- | ------------------------------ Avr: 149 494 735 | 199 770 1530 Tot: 174 632 1133The following are the performance numbers I’m looking for, achieved using 4.4.8-armada-17.02-espressobin kernel downloaded from http://espressobin.net/tech-spec/. That one, and 4.4.52-armada-17.10.4-g719fc86-dirty are the only kernels I have been able to actually get 1GHz performance with:
root@espressobin:~# uname -a Linux espressobin 4.4.52-armada-17.10.4-g719fc86-dirty #7 SMP PREEMPT Tue Jul 3 10:59:53 UTC 2018 aarch64 GNU/Linux root@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: 734 997 998 998 998 992 996 996 RAM size: 927 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: 870 150 563 847 | 22431 198 969 1915 23: 860 151 582 876 | 22154 198 968 1918 24: 854 151 607 918 | 21735 198 963 1908 25: 848 152 639 969 | 21341 198 960 1900 ---------------------------------- | ------------------------------ Avr: 151 598 903 | 198 965 1910 Tot: 174 781 1406Following http://wiki.espressobin.net/tiki-index.php?page=Build+From+Source+-+Kernel to build 4.4.52-armada-17.10.4-g719fc86-dirty also works fine at 1GHz.
I’ve tried a bunch of different U-boots, all with the same result, so I really think the bug is in Linux.
(FYI this is not the only problem I have been having with the v7, but lets focus on one bug at a time. Not to mention that Globalscale claims 1.2 GHz for v7 which seems entirely out of reach as any 1200 u-boot bricks my board).
-
@FlashBurn I'm having the same problem - only getting 800MHz. It's frustrating, since I bought this board because it claimed to deliver 1.2GHz.
I think this is a problem in Linux, but I'm not sure where to report it, so I made a post in the espressobin.net forums.
Now I just discovered that they deleted my thread, but here's a repost:
-
Here's an update:
I've been running Armbian with nightly kernels, (currently on 4.19.50-mvebu64) and flash-image-ddr4-1g-1cs-800_800-2019-05-21.bin uboot entirely stable for some time now. The only two remaining problems being:
1) U-boot sometimes get stuck. I just reset the board until it boots.
2) With flash-image-ddr4-1g-1cs-1000_800-2019-05-21.bin I'm not getting 1GHz. (Also tested with 5.2.0-rc4-next-20190614).
To help address the last problem, I just posted in the Espressobin forums: http://espressobin.net/forums/topic/mainline-linux-not-running-at-1ghz/
UPDATE: wtf - espressobin deleted that thread from their forum. Here's a repost.
Hopefully someone is able to reach out to Marvell and make them fix the bug.
Thanks for all the help so far
-
1 hour ago, ebin-dev said:
Did you try this with the 800_800 or 600_600 bootloader ?
With 800_800 it works fine so far. Some strange messages in dmesg though: http://ix.io/1KDu
They may be actual bugs in linux-next though (including the "Kernel stack is corrupted in: write_irq_affinity" error) https://lkml.org/lkml/2019/5/31/761
Do you want me to test 600_600 as well?
-
> We need to identify the patch Armbian is missing ...
I though that would be simple. Turns out it is not. How to build 4.4.52 is documented here http://wiki.espressobin.net/tiki-index.php?page=Build+From+Source+-+Kernel but the code is vastly different from whats in mainline Linux.
Ex, this patch sounds interesting:
commit 6640985b0697f08d5106e6c4cd66dc61ec5e6a2d Author: Victor Gu <xigu@marvell.com> Date: Wed Sep 20 10:00:49 2017 +0800 fix: regulator: armada-37xx: overwrite CPU voltage values in 1000MHZ The original CPU voltage values from load 1 to load 3 are too low for EspressoBin board with Armada-37xx SoC when CPU is 1000MHZ, which leads to instability that CPU gets stuck soon during dynamic voltage scaling. In order to fix this issue, this patch adds the compatible string for EspressoBin AVS, and update the CPU voltage values from load 1 to load 3 in 1000MHZ mode accordingly, the value is updated from original 1.05v to 1.108v. Change-Id: Iae22cb3bb243b3345e7426e859313139637f09e7 Signed-off-by: Victor Gu <xigu@marvell.com> diff --git a/Documentation/devicetree/bindings/regulator/armada3700-regulator.txt b/Documentation/devicetree/bindings/regulator/armada3700-regulator.txt index 7ed7a619..5a853dd6 100644 --- a/Documentation/devicetree/bindings/regulator/armada3700-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/armada3700-regulator.txt @@ -1,7 +1,7 @@ Marvell Armada 3700 voltage regulator by AVS Required properties: -- compatible: must be "marvell,armada-3700-avs" +- compatible: must be "marvell,armada-3700-avs" or "marvell,armada-3700-espressobin-avs" - reg: avs register address, which is used to control CPU voltage - clocks: CPU core clock to get the MAX CPU frequency - any required generic properties defined in regulator.txt diff --git a/drivers/regulator/armada-37xx-regulator.c b/drivers/regulator/armada-37xx-regulator.c index bd3b9504..1185f6a5 100644 --- a/drivers/regulator/armada-37xx-regulator.c +++ b/drivers/regulator/armada-37xx-regulator.c @@ -274,6 +274,7 @@ static int armada_3700_avs_probe(struct platform_device *pdev) struct regulator_config config = { }; struct regulator_dev *rdev; u32 max_cpu_freq; + int idx; avs = devm_kzalloc(&pdev->dev, sizeof(*avs), GFP_KERNEL); if (!avs) { @@ -315,6 +316,13 @@ static int armada_3700_avs_probe(struct platform_device *pdev) avs->freq_level = CPU_FREQ_LEVEL_800MHZ; } else if (max_cpu_freq == CPU_FREQ_1000MHZ) { avs->freq_level = CPU_FREQ_LEVEL_1000MHZ; + /* + * Overwrite the VDD values from load 1 to load 3 in 1000MHZ + * for EspressoBin, otherwize the CPU gets stuck. + */ + if (of_device_is_compatible(np, "marvell,armada-3700-espressobin-avs")) + for (idx = VDD_SET1; idx <= VDD_SET3; idx++) + voltage_m_tbl[avs->freq_level][idx] = 1108; } else if (max_cpu_freq == CPU_FREQ_1200MHZ) { avs->freq_level = CPU_FREQ_LEVEL_1200MHZ; } else { @@ -399,6 +407,7 @@ static const struct dev_pm_ops armada_3700_avs_pm_ops = { static const struct of_device_id armada3700_avs_of_match[] = { { .compatible = "marvell,armada-3700-avs", }, + { .compatible = "marvell,armada-3700-espressobin-avs", }, {} };
But the file drivers/regulator/armada-37xx-regulator.c is nowhere to be found in mainline or espressobin kernels.
Also I just tried building Linux 5.2.0-rc4-next-20190614, which runs fine, and reports 1GHz but 7zip still reports 800MHz.
-
> Is it stable ??
-
> the boot loader needs some finishing touches for V7 (boot loader crashes, 1200_750 bricks the V7, CPU runs with 800MHz instead of 1000MHz)
@ebin-dev We agree that the first two (boot loader crashes, 1200_750 bricks the V7) are bootloader problems.
But I'm not sure "CPU runs with 800MHz instead of 1000MHz" is a bootloader problem. I just tried flashing flash-image-ddr4-1g-1cs-1000_800-2019-05-21.bin, and booting up 4.4.52-armada-17.10.4-g719fc86-dirty (from http://espressobin.net/tech-spec/) and now 7zip also reports 1000 MHz: http://ix.io/1KCN
-
> If you have a look at armada-37xx-cpufreq.c in the source tree of kernel 4.19.46 and 5.1.6 you will see that i.e. lines 449, 450 have changed to [...]
You are right, I didn't catch that. But that is only one of the 3 changes (L172, L423) from https://github.com/MarvellEmbeddedProcessors/linux-marvell/pull/19/commits/8fe9a4c4a024a6353e810a1dbb5e4bc78bff60a8
> Thank you for testing kernel 4.19.46 on your V7 EspressoBin. It is not stable with the 1000_800 bootloader - not even at the u-boot prompt, the CPU is clocked with 800MHz instead of 1000MHz
With 4.19.46 I haven't seen any Linux crashes yet (been running for about 8 hours), so in that sense it is stable. But yes, 7zip only reports 800 MHz, and u-boot sometimes fails to boot.
> 1200_750 bootloader even bricks your EspressoBin. I think that the vendor must be made aware of this.
Alright, anything else that you would like me to test? And what exactly should I report to them?
> If you now switch to the other bootloader 800_800 - is your V7 Espresso stable now with kernel 4.19.46 ?
Using flash-image-ddr4-1g-1cs-800_800-2019-05-21.bin (md5 09a1b1ecf658ed74802bc65806fa92af), u-boot still fails to boot sometimes, with the last line being "SVC REV: 5, CPU VDD voltage: 1.073V".
When the OS is running, everything seems fine so far: http://ix.io/1KCy
Also, did you see these two fairly new patches that mentions Espressobin?
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/655136.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/655147.html
Thanks for your help by the way
-
3 hours ago, ebin-dev said:
If you want to learn something you need to test with kernel 4.19.46 (please select next-nightly in armbian-config)
Done. Result: http://ix.io/1KAv
No crashes yet in Linux yet, but about 5% of the time U-boot comes no further than:
TIM-1.0 WTMI-devel-18.12.1-e6bb176 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.155V
On 5/28/2019 at 10:17 AM, ebin-dev said:The reason for the different CPU clock speeds with kernel 4.19.20 and 5.1.0 is that the above patches already made it into the kernel (since 4.19.4x).
No. The patches from https://github.com/MarvellEmbeddedProcessors/linux-marvell/pull/19 are neither in mainline nor in linux-next.
Update: I tried applying the patches, and now it always fails (Same as the one reported here: http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/638623.html):
Loading, please wait... starting version 232 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: Waiting for root file system ... [ 5.771744] Internal error: synchronous parity or ECC error: 86000018 [#1] PREEMPT SMP [ 5.777053] Modules linked in: [ 5.780191] CPU: 1 PID: 23 Comm: kworker/1:1 Not tainted 5.2.0-rc2+ #4 [ 5.786906] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT) [ 5.793550] Workqueue: 0x0 (events) [ 5.797211] pstate: 40000085 (nZcv daIf -PAN -UAO) [ 5.802147] pc : dequeue_entity+0x48/0x578 [ 5.806351] lr : dequeue_entity+0x24/0x578 [ 5.810559] sp : ffffff801139bc80 [ 5.813965] x29: ffffff801139bc80 x28: 0000000000000000 [ 5.819430] x27: 0000000000000000 x26: ffffffc03fb012c0 [ 5.824895] x25: ffffff8010bdf400 x24: ffffffc03fde1bc0 [ 5.830360] x23: ffffff8011009000 x22: 0000000000000009 [ 5.835827] x21: 0000000157a1bc9e x20: ffffffc03fb00e00 [ 5.841292] x19: ffffffc03fde1c40 x18: 0000000000000000 [ 5.846758] x17: 0000000000000000 x16: 0000000000000000 [ 5.852224] x15: 0000000000000000 x14: 0000000000000000 [ 5.857688] x13: 0000000000000001 x12: 0000000000000000 [ 5.863154] x11: 0000000000000026 x10: 0101010101010101 [ 5.868620] x9 : 0000000000000000 x8 : 7f7f7f7f7f7f7f7f [ 5.874086] x7 : 0000000000000000 x6 : 0000000018f0cb72 [ 5.879551] x5 : 00ffffffffffffff x4 : 0000000000000008 [ 5.885017] x3 : 000000003b4485a0 x2 : 0000000000000000 [ 5.890483] x1 : 0000000000000000 x0 : 00000001579f2800 [ 5.895949] Call trace: [ 5.898460] dequeue_entity+0x48/0x578 [ 5.902313] dequeue_task_fair+0x54/0x590 [ 5.906437] deactivate_task+0x70/0xc8 [ 5.910290] __schedule+0x2a4/0x4c0 [ 5.913870] schedule+0x38/0xc8 [ 5.917099] worker_thread+0xc8/0x460 [ 5.920862] kthread+0x124/0x128 [ 5.924177] ret_from_fork+0x10/0x1c [ 5.927851] Code: f944e800 cb0002b5 cb0102b5 f9406280 (b5001da0) [ 5.934121] ---[ end trace 21831cae888e94ae ]---
-
On 5/28/2019 at 10:17 AM, ebin-dev said:
@Anders The reason for the different CPU clock speeds with kernel 4.19.20 and 5.1.0 is that the above patches already made it into the kernel (since 4.19.4x). Therefore with newer kernels the CPU is clocked as expected. In kernel 4.19.20 (and with earlier kernels) the CPU was clocked with lower speeds (800MHz instead of 1000MHz, 300MHz instead of 600MHz) as you have seen yourself.
Now the new boot loader has to (ddr) tune the system such that it is stable under these new circumstances.
Would you please test the 1000_800 image again (from here) ? I am surprised that the CPU only runs at 800 MHz in this case. Please press the reset button once you have flashed the 1000_800 image ...
(You need to adapt the values in /etc/default/cpufrequtils to available values shown by cpufreq-info and to reboot)
@ebin-dev Using flash-image-ddr4-1g-1cs-1000_800-2019-05-21.bin (md5: 1b0cc3d743be6e5881d0f9010df79f4f), and mainline Linux with the config from https://github.com/armbian/build/blob/master/config/kernel/linux-mvebu64-next.config this is what I get:
Marvell>> version U-Boot 2018.03-devel-18.12.3-gc9aa92c-armbian (Feb 20 2019 - 09:45:04 +0100) aarch64-linux-gnu-gcc (Linaro GCC 7.4-2019.02) 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] GNU ld (Linaro_Binutils-2019.02) 2.28.2.20170706 root@espressobin:~# uname -a Linux espressobin 5.2.0-rc2+ #3 SMP PREEMPT Fri May 31 18:28:10 CEST 2019 aarch64 GNU/Linux root@espressobin:~# cat /etc/default/cpufrequtils # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=200000 MAX_SPEED=1300000 GOVERNOR=ondemand root@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 - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 200 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:81.44%, 250 MHz:1.75%, 500 MHz:0.79%, 1000 MHz:16.02% (193) 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 - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative, userspace, powersave, ondemand, performance, schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 200 MHz (asserted by call to hardware). cpufreq stats: 200 MHz:81.44%, 250 MHz:1.75%, 500 MHz:0.79%, 1000 MHz:16.02% (193) root@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: 500 794 794 794 794 794 794 794 RAM size: 987 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: 717 149 469 698 | 18046 200 772 1541 23: 708 149 485 722 | 17712 199 770 1533 24: 703 149 506 757 | 17468 200 769 1534 25: 699 150 534 799 | 17211 199 769 1532 ---------------------------------- | ------------------------------ Avr: 149 498 744 | 199 770 1535 Tot: 174 634 1139If I do "cpufreq-set -g performance", "cpufreq-info" reports: "current CPU frequency is 1000 MHz (asserted by call to hardware).", though 7zip continues to report 794.
No immediate crashes so far.Got a crash on boot:starting version 232 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: Waiting for root file system ... Begin: Running /scripts/local-block ... done. [ 6.189319] Internal error: Oops: 86000005 [#1] PREEMPT SMP [ 6.192204] Modules linked in: [ 6.195346] CPU: 0 PID: 211 Comm: spi0 Not tainted 5.2.0-rc2+ #3 [ 6.201522] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT) [ 6.208154] pstate: 80000005 (Nzcv daif -PAN -UAO) [ 6.213085] pc : 0x100000 [ 6.215778] lr : spi_res_release+0x5c/0x98 [ 6.219978] sp : ffffff801173bd00 [ 6.223382] x29: ffffff801173bd00 x28: 0000000000000000 [ 6.228848] x27: ffffff8011121b30 x26: ffffff8011029000 [ 6.234314] x25: ffffffc03fb5bba0 x24: dead000000000100 [ 6.239780] x23: dead000000000200 x22: ffffff801005b818 [ 6.245245] x21: ffffffc03fb5b800 x20: ffffff801005b7c0 [ 6.250710] x19: ffffffc03fbed040 x18: 0000000000000000 [ 6.256176] x17: 0000000000000000 x16: 0000000000000000 [ 6.261642] x15: 0000000000000000 x14: 0000000000000000 [ 6.267107] x13: 0000000000000001 x12: 0000000000000000 [ 6.272573] x11: 0000000000000001 x10: 0000000000000910 [ 6.278038] x9 : ffffff801173bbe0 x8 : ffffffc03c86e630 [ 6.283504] x7 : ffffffc03c86dd80 x6 : 0000000018f873c1 [ 6.288970] x5 : 0000000000000323 x4 : 0000000000000000 [ 6.294435] x3 : 0000000000100000 x2 : ffffffc03fbed058 [ 6.299901] x1 : ffffff801005b7c0 x0 : ffffffc03fb5b800 [ 6.305368] Call trace: [ 6.307877] 0x100000 [ 6.310210] spi_transfer_one_message+0x25c/0x3c8 [ 6.315047] __spi_pump_messages+0x32c/0x520 [ 6.319439] spi_pump_messages+0x14/0x20 [ 6.323474] kthread_worker_fn+0xac/0x198 [ 6.327591] kthread+0x124/0x128 [ 6.330908] ret_from_fork+0x10/0x1c [ 6.334584] Code: bad PC value [ 6.337717] ---[ end trace c792078f48e6ceda ]---
-
@ebin-dev Yes. I do not know why though.
Using flash-image-ddr4-1g-1cs-800_800-2019-05-21.bin also seems to work fine:
root@espressobin:~# uname -a Linux espressobin 4.19.20-mvebu64 #5.75 SMP PREEMPT Fri Feb 8 09:54:18 CET 2019 aarch64 aarch64 aarch64 GNU/Linux root@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: 793 793 794 794 794 794 794 794 RAM size: 990 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: 726 149 473 706 | 17714 200 758 1512 23: 721 150 488 735 | 17480 200 757 1513 24: 715 151 510 770 | 17197 200 755 1510 25: 711 151 538 812 | 16950 200 755 1509 ---------------------------------- | ------------------------------ Avr: 151 502 756 | 200 756 1511 Tot: 175 629 1133root@espressobin:~# uname -a Linux espressobin 5.1.0-g72cf0b074 #1 SMP PREEMPT Sun May 19 18:21:04 CEST 2019 aarch64 GNU/Linux root@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: 647 794 794 794 794 794 794 794 RAM size: 984 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: 715 147 474 696 | 17894 196 778 1528 23: 707 147 490 721 | 17845 198 778 1545 24: 702 148 512 755 | 17546 198 776 1540 25: 698 148 541 798 | 17261 198 774 1536 ---------------------------------- | ------------------------------ Avr: 147 504 742 | 198 777 1537 Tot: 173 640 1140flash-image-ddr4-1g-1cs-1000_800-2019-05-21.bin also works fine so far, but only runs at 800 mhz?:
root@espressobin:~# uname -a Linux espressobin 4.19.20-mvebu64 #5.75 SMP PREEMPT Fri Feb 8 09:54:18 CET 2019 aarch64 aarch64 aarch64 GNU/Linux root@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: 793 794 794 794 794 794 794 794 RAM size: 990 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: 730 150 472 711 | 17719 200 758 1513 23: 720 150 488 734 | 17447 199 757 1510 24: 716 151 510 770 | 17170 199 756 1507 25: 711 151 538 813 | 16964 200 756 1510 ---------------------------------- | ------------------------------ Avr: 151 502 757 | 199 757 1510 Tot: 175 630 1133root@espressobin:~# uname -a Linux espressobin 5.1.0-g72cf0b074 #1 SMP PREEMPT Sun May 19 18:21:04 CEST 2019 aarch64 GNU/Linux root@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: 794 794 793 794 794 794 794 794 RAM size: 984 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: 714 147 473 695 | 18084 198 778 1544 23: 707 147 490 720 | 17813 198 777 1542 24: 702 148 512 756 | 17451 198 775 1532 25: 699 148 541 798 | 17261 198 775 1536 ---------------------------------- | ------------------------------ Avr: 147 504 742 | 198 776 1539 Tot: 173 640 1140But sometimes it freezes very early in the boot process. This happened with all versions:
Marvell>> reset resetting ... TIM-1.0 WTMI-devel-18.12.1-e6bb176 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.073V (no more output)
flash-image-ddr4-1g-1cs-1200_750-2019-05-21.bin killed my board again. Same as above, but last line is: "SVC REV: 5, CPU VDD voltage: 0.898V".
Also, I haven't tested with the patches from https://github.com/MarvellEmbeddedProcessors/linux-marvell/pull/19 yet. Will do that once I recover my board.
-
@barish I managed to fix mine by following those two guides: https://dl.armbian.com/espressobin/u-boot/rescue/uart-rescue-espressobin.pdf and http://wiki.espressobin.net/tiki-index.php?page=Bootloader+recovery+via+UART+-+v7&highlight=recovery
I used the files from https://dl.armbian.com/espressobin/u-boot/rescue/uart-images-18.12-v2/uart-images-ddr4-1g-1cs-1000_800.tgz
@ebin-dev Using flash-image-ddr4-1g-1cs-600_600.bin from 2019-05-21 seems fine so far:
root@espressobin:~# uname -a Linux espressobin 4.19.20-mvebu64 #5.75 SMP PREEMPT Fri Feb 8 09:54:18 CET 2019 aarch64 aarch64 aarch64 GNU/Linux root@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: 296 296 296 296 296 296 294 RAM size: 990 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: 289 143 197 282 | 6691 199 287 571 23: 286 142 205 292 | 6616 199 287 573 24: 284 143 214 306 | 6553 199 289 575 25: 283 143 227 324 | 6476 199 290 576 ---------------------------------- | ------------------------------ Avr: 143 211 301 | 199 288 574 Tot: 171 249 437root@espressobin:~# uname -a Linux espressobin 5.1.0-g72cf0b074 #1 SMP PREEMPT Sun May 19 18:21:04 CEST 2019 aarch64 GNU/Linux root@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: 594 594 594 594 595 595 594 595 RAM size: 984 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: 532 147 353 518 | 13527 198 582 1155 23: 525 147 365 536 | 13303 198 581 1152 24: 521 147 381 561 | 13050 198 579 1146 25: 518 147 402 593 | 12934 198 580 1151 ---------------------------------- | ------------------------------ Avr: 147 375 552 | 198 580 1151 Tot: 173 478 851 -
@Igor Thanks!
8 hours ago, ebin-dev said:Could you flash your bootloader to 600_600 and try again ? If no errors occur in that case we could assume that the bootloader needs to be adapted at least for V7 boards ...
That seems to work fine. I only ran it for about 30 minutes though.
root@espressobin:~# uname -a Linux espressobin 5.1.0-g72cf0b074 #1 SMP PREEMPT Sun May 19 18:21:04 CEST 2019 aarch64 GNU/Linux root@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: 439 450 368 589 591 505 585 487 RAM size: 984 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: 438 122 349 427 | 13482 198 581 1151 23: 524 146 365 534 | 13276 198 580 1149 24: 520 147 381 560 | 12839 195 577 1127 25: 517 147 402 591 | 12862 198 580 1145 ---------------------------------- | ------------------------------ Avr: 141 374 528 | 197 580 1143 Tot: 169 477 835I'm confused. I do not understand what this has to do with the U-Boot bootloader? 1000_800 worked fine with 4.4.8-armada-17.02-espressobin kernel.
My board came with "U-Boot 2017.03-armada-17.10.2-g14aeedc" preinstalled, which on boot reported:
CPU @ 1000 [MHz]
L2 @ 800 [MHz]
TClock @ 200 [MHz]
DDR @ 800 [MHz]Which is why I choose to flash "flash-image-ddr4-1g-1cs-1000_800.bin".
Espressobin v7 should run at 1.2 GHz, so I just tried flashing "flash-image-ddr4-1g-1cs-1200_750.bin", but now my board does not boot:
Marvell>> bubt flash-image-ddr4-1g-1cs-1200_750.bin spi usb Burning U-BOOT image "flash-image-ddr4-1g-1cs-1200_750.bin" from "usb" to "spi" USB0: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 USB1: USB EHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 2 USB Device(s) found Image checksum...OK! SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB Erasing 917504 bytes (14 blocks) at offset 0 ...Done! Writing 889028 bytes from 0x8000000 to offset 0 ...Done! Marvell>> Marvell>> Marvell>> reset resetting ... TIM-1.0 WTMI-devel-18.12.0-a0a1cb8 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 0.898V
It never gets any further than "SVC REV: 5, CPU VDD voltage: 0.898V" - any ideas?
How to make ESPRESSObin v7 stable?
in Marvell mvebu
Posted
@Pali
Awesome.
Adding a fan has kept my device from crashing:
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?