Jump to content

Espressobin support development efforts

lanefu

By lanefu
in Marvell mvebu

 Share

Recommended Posts

FlashBurn

FlashBurn

Posted
Posted

This is getting annoying. The deeper I look the more errors I find :(

 

My fix seems to work. I tried my fix with the current uboot firmware´s supplied by armbian and these are my findings:

 

- 1200 MHz: working fine, sbc-bench: http://ix.io/1BQ9

- 1000 MHz: I´m still trying to find out why this wont work for me

- 800 MHz: working fine, sbc-bench: http://ix.io/1BQr

- 600 MHz: could work fine, if the cpufreq init code would not mess up; at the moment it is just running at 300 MHz, sbc-bench: http://ix.io/1BQF

 

The problem with the 600 MHz is, that the parent clocks are running at 1200 MHz and a divider by 2 is used, but this is a problem for the cpufreq init code, because the cpu core frequency is 600 MHz and the cpu frequency which gets reported to the kernel is 600 MHz divided by the divider found in the dvfs which is 2.

So to fix this problem, the parent frequency has to be taken to report the right frequency to the kernel. As I don´t intend to run at 600 MHz I will ignore this problem, but regard it as reported with this post. If someone wants to fix it and needs more information just ask.

 

When I found out what the problem with 1000 MHz is and I fixed it, I will post the needed patches for fixing the cpu frequency for 800, 1000 and 1200 MHz.

1
FlashBurn

FlashBurn

Posted
Posted

Ok, even with the stock armbian image I can´t get the board to boot the kernel with 1000 MHz firmware.

 

If someone tells me which firmware version I need to use for my V7 board to get the 1000 MHz version to run, I will test my fixes with this. But I give up trying to find out why this firmware does not work for me.

 

This is the output: 

TIM-1.0
WTMI-devel-18.12.0-a0a1cb8
WTMI: system early-init
SVC REV: 5, CPU VDD voltage: 1.132V
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.5(release):1f8ca7e (Marvell-devel-18.12.2)
NOTICE:  BL1: Built : 09:50:21, Feb 20 2019
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v1.5(release):1f8ca7e (Marvell-devel-18.12.2)
NOTICE:  BL2: Built : 09:50:23, Feb 20 2019
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v1.5(release):1f8ca7e (Marvell-devel-18.12.2)
NOTICE:  BL31: Built : 09:5

U-Boot 2018.03-devel-18.12.3-gc9aa92c-armbian (Feb 20 2019 - 09:45:04 +0100)

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, sdhci@d8000: 1
Loading Environment from SPI Flash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 64 KiB, total 4 MiB
OK
Model: Marvell Armada 3720 Community Board ESPRESSOBin
Net:   eth0: neta@30000 [PRIME]
Hit any key to stop autoboot:  0
/
Card did not respond to voltage select!
** Bad device mmc 1 **
## Executing script at 06d00000
Wrong image format for "source" command
/boot/
Card did not respond to voltage select!
** Bad device mmc 1 **
## Executing script at 06d00000
Wrong image format for "source" command
/
** File not found /boot.scr **
## Executing script at 06d00000
Wrong image format for "source" command
/boot/
1119 bytes read in 13 ms (84 KiB/s)
## Executing script at 06d00000
172 bytes read in 5 ms (33.2 KiB/s)
15897088 bytes read in 682 ms (22.2 MiB/s)
4673466 bytes read in 209 ms (21.3 MiB/s)
** File not found /boot/dtb/marvell/armada-3720-community.dtb **
8942 bytes read in 9 ms (969.7 KiB/s)
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    4673402 Bytes = 4.5 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 3f1b6000, end 3f62af7a ... OK
   Using Device Tree in place at 0000000006000000, end 00000000060052ed

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 4.19.14-mvebu64 (root@nightly) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5.69 SMP PREEMPT Thu Jan 10 12:03:52 CET 2019
[    0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board
[    0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '')
[    0.000000] bootconsole [ar3700_uart0] enabled
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 ... Scanning for Btrfs filesystems
done.
Begin: Will now check root file system ... fsck from util-linux 2.29.2
[/sbin/fsck.ext4 (1) -- /dev/mmcblk1p1] fsck.ext4 -a -C0 /dev/mmcblk1p1
/dev/mmcblk1p1: clean, 36742/81440 files, 276911/325632 blocks
done.
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.

 

0
spqr

spqr

Posted
Posted

Hi,

 

I built a wifi driver for rtl8822 on armbian stretch: Linux espressobin 4.19.20-mvebu64 #5.75

 

After downloading kernel headers, "make scripts" is failing because of "wireguard"

 

I commented out the line in net/Kconfig for wireguard and the make completed without error.

The driver also built successfully and seems to work.

 

Steve

0
kostap

kostap

Posted
Posted
On 2/23/2019 at 6:10 PM, FlashBurn said:

This is getting annoying. The deeper I look the more errors I find :(

 

My fix seems to work. I tried my fix with the current uboot firmware´s supplied by armbian and these are my findings:

 

- 1200 MHz: working fine, sbc-bench: http://ix.io/1BQ9

- 1000 MHz: I´m still trying to find out why this wont work for me

- 800 MHz: working fine, sbc-bench: http://ix.io/1BQr

- 600 MHz: could work fine, if the cpufreq init code would not mess up; at the moment it is just running at 300 MHz, sbc-bench: http://ix.io/1BQF

 

The problem with the 600 MHz is, that the parent clocks are running at 1200 MHz and a divider by 2 is used, but this is a problem for the cpufreq init code, because the cpu core frequency is 600 MHz and the cpu frequency which gets reported to the kernel is 600 MHz divided by the divider found in the dvfs which is 2.

So to fix this problem, the parent frequency has to be taken to report the right frequency to the kernel. As I don´t intend to run at 600 MHz I will ignore this problem, but regard it as reported with this post. If someone wants to fix it and needs more information just ask.

 

When I found out what the problem with 1000 MHz is and I fixed it, I will post the needed patches for fixing the cpu frequency for 800, 1000 and 1200 MHz.

 

Hello, @FlashBurn,

FYI, the XTAL clock readout was fixed by Marvall LSP, but not yet taken into the mainline sources.

The fix is available here:

https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/80d4cec4cef8282e5ac3aaf98ce3e68fb299a134

 

For reviewing the clock setup it is better to look though the a3700_utils sources.

There is a big text table here describing the divider values:

https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/blob/A3700_utils-armada-18.12/wtmi/sys_init/clock.c

 

 

1
FlashBurn

FlashBurn

Posted
Posted

@kostap

 

Yes, I already know that. I applied the patch.

 

The clock tables also have errors ;-)

 

I'm pretty busy at the moment, but if I find the time I will make a pull request for armbian with my fix.

0
FlashBurn

FlashBurn

Posted
Posted

I just made the pull request with the 2 needed patches to make cpu frequency scaling working. These patches also fixed the problem with the 600 MHz firmware and the cpu scaling.

 

Best would be if some people could test this on older revision boards. I also could not test this for the 1000 MHz firmware.

1
ebin-dev

ebin-dev

Posted
Posted
8 hours ago, FlashBurn said:

Best would be if some people could test this on older revision boards.

 

Unfortunately it does not work on a V5_0_1 EspressoBin with latest u-boot 1000_800 and 1200_750. The kernel starts to load but stops:  

[    0.000000] bootconsole [ar3700_uart0] enabled

You can download the patched kernel debs here (stretch 4.19.27) and give it a try.

 

Edit: With the latest u-boot 600_600 and 800_800 the patched kernel is working on my EspressoBin - it runs with 600MHz and 800MHz as expected ! With 1000_800 and 1200_750 the patched kernel stops loading or even produces a kernel panic.

 

0
FlashBurn

FlashBurn

Posted
Posted

Problem for me is that I did not get uboot to run with the 1000 MHz firmware the last times I tried.

 

So I need to do some tries with different uboot versions to get the kernel to run on my side with this firmware.

 

If the kernel also does not run on other firmwares I need to make a kernel with debug outputs so I can analyze further.

0
FlashBurn

FlashBurn

Posted
Posted

I just tested the kernel from ebin-dev and for me it works perfectly for 1200_750. Will test now with 600 and 800 MHz and then 1000 MHz.

 

So this seems to be a problem with older revisions. I will make a kernel only with debug output, but not the patch and then upload it somewhere so that others can try it and send me the needed information. This will take a while.

 

Edit::

 

600 and 800 MHz are working, but the 1000 MHz firmware (stock firmware from globalscale) is not working. I will test again a current 1000 MHz firmware built by armbian and then will prepare a kernel with debug outputs.

 

Edit::

I can confirm that the kernel does not run with 1000 MHz firmware. Also it seems upgrading and downgrading firmware is not always working, because I had the problem once again that uboot did not start, but the same firmware is now working.

0
FlashBurn

FlashBurn

Posted
Posted

So I built my test kernel and what should I say. There is something totally wrong with the 1000 MHz firmware. I get kernel panics and other failures, but in the end everytime a kernel panic. The board is not the problem as it runs for hours with 1200 MHz and also 600 and 800 MHz.

I also got the kernel panics with the stock kernel. So my kernel should not be the problem (but who knows for sure ;) ).

 

The information I got from this kernel is that my patches should also work for the 1000 MHz version. Everything is fine, all clocks are right, but it does not work.

 

Can others confirm that they get kernel panics with the 1000 MHz firmware and the stock kernel? Would also be good to know if this is only a problem of REV7 boards or if this also happens to other revisions.

0
spqr

spqr

Posted
Posted

I ordered eight of the v7 units from GS and six of them couldn't make 48 hours before a freeze or kernel panic. Two of them stay up indefinitely.

I concluded it was a hardware problem and am returning the units.

 

PS: this was with their stock ubuntu kernel...

1
Spemerchina

Spemerchina

Posted
Posted
2 hours ago, spqr said:

I ordered eight of the v7 units from GS and six of them couldn't make 48 hours before a freeze or kernel panic. Two of them stay up indefinitely.

I concluded it was a hardware problem and am returning the units.

 

PS: this was with their stock ubuntu kernel...

interesting. what was your application that needed so much bins?

0
spqr

spqr

Posted
Posted
2 hours ago, FlashBurn said:

@spqr

And what firmware did you use?

 

Their ubuntu kernel should be not so different to the mainline regarding the clocks and cpu frequency scaling.

sorry... I was only using whatever GS shipped, no changes at all.

U-Boot 2017.03-armada-17.10.2-g14aeedc (Jun 01 2018 - 15:39:10 +0800)

 

I've been trying to move toward armbian...

 

0
lanefu

lanefu

Posted
  • Author
Posted

I tried the patched debs. on my v4 espressobin.. running the 1000 800 firmware...  seems to just kind hang shorly after kernel loads..

 

Spoiler

TIM-1.0
WTMI-devel-18.07.0-6050fd5
WTMI: system early-init
CPU VDD voltage default value: 1.155V
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.5(release):711ecd3 (Marvell-armada-18.09.4)
NOTICE:  BL1: Built : 15:11:39, Sep  7 2018
NOTICE:  BL1: Booting BL2

NOTICE:  BL1: v1.5(release):711ecd3 (Marvell-armada-18.09.4)
NOTICE:  BL1: Built : 15:11:39, Sep  7 2018
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v1.5(release):711ecd3 (Marvell-armada-18.09.4)
NOTICE:  BL2: Built : 15:11:42, Sep  7 2018
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v1.5(release):711ecd3 (Marvell-armada-18.09.4)
NOTICE:  BL31: Built : 15:1

U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian (Sep 05 2018 - 21:49:34 +0200)

Model: Marvell Armada 3720 Community Board ESPRESSOBin
       CPU     1000 [MHz]
       L2      1000 [MHz]
       NB AXI  250 [MHz]
       SB AXI  250 [MHz]
       DDR     800 [MHz]
DRAM:  1 GiB



### snip

    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 4.19.27-mvebu64 (root@ubuntu) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5.76 SMP PREEMPT Thu Mar 7 11:54:00 CET 2019
[    0.000000] Machine model: Globalscale Marvell ESPRESSOBin Board
[    0.000000] earlycon: ar3700_uart0 at MMIO 0x00000000d0012000 (options '')
[    0.000000] bootconsole [ar3700_uart0] enabled
[    1.944669] SError Interrupt on CPU1, code 0xbf000002 -- SError
[    1.944673] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.19.27-mvebu64 #5.76
[    1.944675] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT)
[    1.944677] pstate: 40000085 (nZcv daIf -PAN -UAO)
[    1.944678] pc : advk_pcie_wr_conf+0x48/0x1b0
[    1.944680] lr : pci_bus_write_config_word.part.0+0x58/0x80

## snip

[    1.944738] Kernel panic - not syncing: Asynchronous SError Interrupt
[    1.944740] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.19.27-mvebu64 #5.76
[    1.944742] Hardware name: Globalscale Marvell ESPRESSOBin Board (DT)

[    1.944787]  ret_from_fork+0x10/0x1c
[    1.944801] SMP: stopping secondary CPUs
[    1.944802] Kernel Offset: disabled
[    1.944804] CPU features: 0x0,2080200c
[    1.944805] Memory Limit: none
[    2.215685] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---

 

0
lanefu

lanefu

Posted
  • Author
Posted
31 minutes ago, lanefu said:

I tried the patched debs. on my v4 espressobin.. running the 1000 800 firmware...  seems to just kind hang shorly after kernel loads..

 

  Reveal hidden contents

 


Same after flashing flash-image-ddr3-1g-2cs-1000_800.bin as well

0
FlashBurn

FlashBurn

Posted
Posted

So, maybe some people can tell which firmware and which kernel version they use running at 1000 MHz that works for them (board revision just for the record). I want to find out if it maybe could be that the newer kernels are not working at 1000 MHz anymore.

0
ebin-dev

ebin-dev

Posted
Posted
42 minutes ago, FlashBurn said:

I want to find out if it maybe could be that the newer kernels are not working at 1000 MHz anymore.

 

You could switch to Nightly builds in armbian-config -> System and Security Settings. Then 4.19.27 will be installed on your Espresso.

0
Smurfix

Smurfix

Posted
Posted
54 minutes ago, FlashBurn said:

So, maybe some people can tell which firmware and which kernel version they use running at 1000 MHz that works for them (board revision just for the record). I want to find out if it maybe could be that the newer kernels are not working at 1000 MHz anymore.

Or maybe only some boards don't. Reports of people sending back 6 of 8 boards because they can't run 24h before going belly-up kindof point towards that cause.

0
FlashBurn

FlashBurn

Posted
Posted

I can confirm that the kernel which is in the armbian image 5.69 is running with the 1000 MHz firmware and the kernel 4.19.20 is not. So this is a general kernel problem and not a problem of my patch.

 

We just need to find what the problem is ;)

0
FlashBurn

FlashBurn

Posted
Posted

There are 2 patches which were sent to the linux kernel mailinglist. I will change my patches to these 2 patches and adjust my pull request accordingly. With these patches the cpu frequency scaling is working.

 

"Only" problem left is that the current kernel is not working with the 1000 MHz firmware.

0
spqr

spqr

Posted
Posted
17 hours ago, FlashBurn said:

So, maybe some people can tell which firmware and which kernel version they use running at 1000 MHz that works for them (board revision just for the record). I want to find out if it maybe could be that the newer kernels are not working at 1000 MHz anymore.

I'm running Armbian 4.19.20 on both v5 and v7 boards 1000 MHz... on the right boards it is perfectly stable.

I'm the guy who returned 6 of 8 because they would freeze or kernel panic in under 24 hours even with the GS shipping ubuntu...

The devices that worked and were stable with ubuntu are stable with Armbian.

 

0
spqr

spqr

Posted
Posted

PS: In addition to the 8 I ordered from GS, I ordered one of the v7 units in the plastic case off Amazon, and that one has also been perfect. I had a v5 unit from over a year ago as well and that one is stable too.

0
FlashBurn

FlashBurn

Posted
Posted

@spqr

 

I would need the precise kernel version, especial the number "y" of your kernel (4.19.y), because for me the newer kernels don´t work with 1000 MHz, but older do.

 

Edit::

Just saw that you edited your post and now you gave the precise version. Strange, for me this is a version which does not work. I will have time for this next weekend, maybe I can find a change which broke the kernel for me.

0
ebin-dev

ebin-dev

Posted
Posted

In order to exclude any issues potentially caused by other kernel versions, I compiled a patched kernel 4.19.20 (download links: kernel debs, patches).

 

Without the patches kernel 4.19.20 operates 24/7 on my Espresso without any issues with any of the current Armbian bootloader versions (but with a reduced CPU clock).

 

The patched kernel is stable with latest Armbian boot loader 800_800. Kernel panics are observed upon reboot - but no issues occur after a power cycle.

 

I observe kernel panics with 1000_800. The kernel stops loading with 1200_750 (latest Armbian boot loader). 

 

So - I can't confirm that the patched kernel would work without issues on a V5_0_1 EspressoBin with the current boot loader.

0
spqr

spqr

Posted
Posted

I want to build the specific kernel version 4.19.20 ... but when I do the armbian build of "next" it builds 4.19.27

I don't see anywhere in the build tool doc's where it tells me how I can do that.

My primary purpose is to flip WAN and LAN1 to match the v7 layout...

 

0
ebin-dev

ebin-dev

Posted
Posted
15 minutes ago, spqr said:

I want to build the specific kernel version 4.19.20 ... but when I do the armbian build of "next" it builds 4.19.27

 

There are probably more elegant ways of doing that - but you can simply replace the content of ~/build/cache/sources/linux-mainline/linux-4.19.y by the 4.19.20 tarball and switch off your network connection. You will then build in offline mode - without any further modifications to the sources.

0

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
Reply to this topic...

×   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 topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept