Banana Pi M2U - A40 - ethernet interface problem

[zakri]

Hey. I have a banana pi m2u (Allwinner A40), I created a debian stretch console image, but ethernet interface does not work. The eth0 interface is not visible in the system. Could you say what could be wrong?

[Xalius]

Hi, what kernel did you use? Can you upload your dts to pastebin?

[zakri]

Hi. Now I have 4.17 but now I know that form 4.18 etherne will be work.

[Igor]

It works the latest DEV build out of the box: http://ix.io/1kVR

[guidol]

14 minutes ago, Igor said:

It works the latest DEV build out of the box: http://ix.io/1kVR

maybe a option for my BPi M2 Berry (the little brother of the M2 Ultra)

[Igor]

1 minute ago, guidol said:

maybe a option for my BPi M2 Berry ( the little brother of the M2 Ultra

Probably it works with the same image? I don't have Berry around ...  https://dl.armbian.com/bananapim2ultra/

[guidol]

1 hour ago, Igor said:

Probably it works with the same image? I don't have Berry around ...  https://dl.armbian.com/bananapim2ultra/

there a good chances, because the BPI M2 Ultra and the M2 Berry do share the same download section at

http://www.banana-pi.org/downloadall.html

 

I will test it - because I got the Berry here

[guidol]

So - short test with the BPi M2 Berry

Ethernet does work now  automatic DHCP ( I did reconfigure to static via "legacy" /etc/network/interfaces)

At first Boot it will take a long time to get a Login prompt at the HDMI-Monitor (first only flashing cursor).

 

LEDs are working for heartbeat and mmc0
 

Spoiler

echo 'heartbeat' > /sys/class/leds/bananapi:red:pwr/trigger

echo 'mmc0' > /sys/class/leds/bananapi:green:user/trigger

 

Temperature sensor isnt correctly configured:

ls -l /etc/armbianmonitor/datasources/soctemp
lrwxrwxrwx 1 root root 47 Aug 22 14:58 /etc/armbianmonitor/datasources/soctemp -> /sys/devices/virtual/thermal/thermal_zone0/temp

ls -l /sys/devices/virtual/thermal/thermal_zone0/temp
ls: Zugriff auf '/sys/devices/virtual/thermal/thermal_zone0/temp' nicht möglich: Datei oder Verzeichnis nicht gefunden

(File not found)

 

Raw temp is in /sys/devices/platform/soc/1c2ac00.i2c/i2c-1/1-0034/axp22x-adc/iio:device0/in_temp_raw

 

So I did:

rm /etc/armbianmonitor/datasources/soctemp
ln -s /sys/devices/platform/soc/1c2ac00.i2c/i2c-1/1-0034/axp22x-adc/iio:device0/in_temp_raw /etc/armbianmonitor/datasources/soctemp

 

Now the temperature is shown too low
 

root@bpi-m2-berry(192.168.6.20):~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time      CPU n/a    load %cpu %sys %usr %nice %io %irq   CPU

15:08:46:   ---      0.00   2%   0%   0%   0%   0%   0%  3.0°C
15:08:51:   ---      0.16   0%   0%   0%   0%   0%   0%  3.0°C
15:08:56:   ---      0.15   0%   0%   0%   0%   0%   0%  3.0°C

I did try to edit /the function getboardtemp in /etc/update-motd.d/30-armbian-sysinfo:

Spoiler

function getboardtemp() {
        if [ -f /etc/armbianmonitor/datasources/soctemp ]; then
                read raw_temp </etc/armbianmonitor/datasources/soctemp 2>/dev/null
                if [ ! -z $(echo "$raw_temp" | grep -o "^[1-9][0-9]*\.\?[0-9]*$") ] && (( $(echo "${raw_temp} < 2$
                        # Allwinner legacy kernels output degree C
                        board_temp=${raw_temp}
                else
                        # Marvell gets special treatment for whatever reasons
                        grep -qi Marvell /proc/cpuinfo && \
                                board_temp=$(( $(awk '{printf("%d",$1/1000)}' <<<${raw_temp}) - 20 )) || \
                                board_temp=$(awk '{printf("%d",$1/100)}' <<<${raw_temp})
                fi
        elif [ -f /etc/armbianmonitor/datasources/pmictemp ]; then
                # fallback to PMIC temperature
                board_temp=$(awk '{printf("%d",$1/1000)}' </etc/armbianmonitor/datasources/pmictemp)
        fi
} # getboardtemp

 

OR

 

function getboardtemp() {
        if [ -f /etc/armbianmonitor/datasources/soctemp ]; then
                # Allwinner legacy kernels output degree C
                board_temp=$(awk '{printf("%.1f",$1/100)}' </etc/armbianmonitor/datasources/soctemp)

        elif [ -f /etc/armbianmonitor/datasources/pmictemp ]; then
                # fallback to PMIC temperature
                board_temp=$(awk '{printf("%d",$1/100)}' </etc/armbianmonitor/datasources/pmictemp)
        fi
} # getboardtemp

 

So I did get (I think) the right Temperature at the Login:
 

 ____  ____  _   __  __ ____    ____
| __ )|  _ \(_) |  \/  |___ \  | __ )  ___ _ __ _ __ _   _
|  _ \| |_) | | | |\/| | __) | |  _ \ / _ \ '__| '__| | | |
| |_) |  __/| | | |  | |/ __/  | |_) |  __/ |  | |  | |_| |
|____/|_|   |_| |_|  |_|_____| |____/ \___|_|  |_|   \__, |
                                                     |___/
Welcome to ARMBIAN 5.59.180823 testing Debian GNU/Linux 9 (stretch) 4.18.4-sunxi
System load:   0.00 0.00 0.00   Up time:       40 min           Local users:   3
Memory usage:  7 % of 1001MB    IP:            192.168.6.20
CPU temp:      29°C
Usage of /:    7% of 15G

[ General system configuration (beta): armbian-config ]

Last login: Wed Aug 22 15:21:48 2018 from 192.168.6.17

but armbianmonitor -m does only show a 1/10 of the temperature:

root@bpi-m2-berry(192.168.6.20):~# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time      CPU n/a    load %cpu %sys %usr %nice %io %irq   CPU

15:40:00:   ---      0.00   1%   0%   0%   0%   0%   0%  3.0°C
 

Looks like I am not the shell-script master for editing the getboardtemp-function

 

BUT its working much better than on older images of armbian for the M2 Ultra !!

 

System-Info:
armbianmonitor -u
http://ix.io/1kWF

[guidol]

if I edit in /usr/bin/armbianmonitor

the divisor for soctemp freom /1000 to /100 then I also will get the (real?) temperature in armbianmonitor -m

 

if [ "X${SocTemp}" != "Xn/a" ]; then
                        read SocTemp <"${Sensors}/soctemp"
                        if [ ${SocTemp} -ge 1000 ]; then
                                SocTemp=$(awk '{printf ("%0.1f",$1/100); }' <<<${SocTemp})
                        fi
                        echo -e " $(printf "%4s" ${SocTemp})°C\c"
                fi

 

root@bpi-m2-berry(192.168.6.20):/etc/update-motd.d# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time      CPU n/a    load %cpu %sys %usr %nice %io %irq   CPU 

16:21:09:   ---      0.04   0%   0%   0%   0%   0%   0% 30.0°C 
16:21:14:   ---      0.03   0%   0%   0%   0%   0%   0% 29.9°C 
16:21:19:   ---      0.03   0%   0%   0%   0%   0%   0% 29.9°C

 

 

[tkaiser]

18 hours ago, guidol said:

I also will get the (real?) temperature in armbianmonitor -m

 

What's the ambient temperature of the place the board is in? If that's more than 20"C you obviously just managed to display an irrelevant number but nothing related to 'real' temperatures. 'iio:device0/in_temp_raw' already indicates that's just a raw value needing some calibration.

 

And you're querying the PMIC and not the SoC BTW... and all of this is just an insane waste of time given what boring and dead SoCs R40 and V40 are (only used on Bananas, not picked up by a single other SBC vendor)

[guidol]

4 hours ago, tkaiser said:

'iio:device0/in_temp_raw' already indicates that's just a raw value needing some calibration.

 

BTW... and all of this is just an insane waste of time given what boring and dead SoCs R40 and V40 are
(only used on Bananas, not picked up by a single other SBC vendor)

in the past (older kernel) we had /sys/class/thermal/thermal_zone0/temp with about 45C

The raw show abot 2945 - so I divided by 100 to get a temperature in a "normal" temperature level.... but when you tell its needs a offset then its useless like on a OPi Zero

 

Scale 100 seems to be OK (I think) because

/sys/devices/platform/soc/1c2ac00.i2c/i2c-1/1-0034/axp22x-adc/iio:device0/in_temp_scale shows 100

/sys/devices/platform/soc/1c2ac00.i2c/i2c-1/1-0034/axp22x-adc/iio:device0/in_temp_offset shows -2677

/sys/devices/platform/soc/1c2ac00.i2c/i2c-1/1-0034/axp22x-adc/iio:device0/in_temp_raw show 2918

But 2918-2677 = 241 is to high...

 

Yes - for some people is working on a R40/V40 a waste of time and it would be better to work on a wider used chipset/SoC,

but I am quite happy that @Igor released the image with kernel v4.18.y for the M2 Ultra/Berry, because for me its better to use this little board than putting it in the drawer or to recycling.

 

I am happy about that, because at this time I hadnt something to do with (my) newer boards (NanoPi K1 Plus is running fine at the first try), so I can do some testing with my "abandoned" M2 Berry (also "abandoned" like my NanoPi A64).

Both do have 1GB of Ram, whats the double of the most H3/H5 boards.... so I am very pleased about the "upcycling".

 

 

 

[tkaiser]

3 hours ago, guidol said:

in the past (older kernel) we had /sys/class/thermal/thermal_zone0/temp with about 45C

 

This is SoC temperature. There's no THS driver in mainline kernel for R40/V40 and if wens or Icenowy stop working on these boring SoCs there never will be one.

 

You're dealing with the AXP221s PMIC which has an own thermal sensor and exposes a bunch of data via I2C. You try for whatever reasons to use some raw values as something that pleases you. I've not the slightest idea why people are so obsessed by numbers without meaning all the time (same with benchmarks)

 

The correct way to deal with boards that use these SoCs is to avoid buying them. But since Igor sends out the signal they will be supported in the future people will never learn this lesson, buy this hardware and either deal with a crappy 3.10 EOL kernel or wait another few years until mainline kernel will be ready for these boring SoCs. What a waste of time and resources...

[guidol]

4 hours ago, tkaiser said:

You're dealing with the AXP221s PMIC which has an own thermal sensor and exposes a bunch of data via I2C. 

You try for whatever reasons to use some raw values as something that pleases you.

I've not the slightest idea why people are so obsessed by numbers without meaning all the time (same with benchmarks)

 

But since Igor sends out the signal they will be supported in the future people will never learn this lesson,

buy this hardware and either deal with a crappy 3.10 EOL kernel or wait another few years until mainline kernel will be ready for these boring SoCs. 

I didnt know that this I2C-Temperature is from the PMIC - so I will live without a real temperature.
Some people - like me - may think they would try to help and get some infos out of the system (not only on this SBC)

for supporting armbian or other people on the forum. But it seems we doesnt know to less
I think the most people do try to find a way, but we didnt got the sytsem-overview like you.

 

Igor may build the image, because he has already a M2 Ultra (like I have a M2 Berry) - and if he find the time - he would also see the board at his home running armbian.

And this board is not nailed to kernel 3.10 (like the Pinebook the most time). OK the M2 Ultra/Berry are not the newest, but their time can come - here or anywhere on the net.

 

Old SBCs like Marvell on the SheevaPlug and BeagleBoard Black are also running newer systems without problems.

And for many people they are not a waste of time.

Other people will concentrate their development to more common systems/CPUs - thats OK.
I think we should have both type of people and they all should have fun with their systems

 

[tkaiser]

8 hours ago, guidol said:

I think we should have both type of people and they all should have fun with their systems

 

The lack of project goals and the way work is done (not coordinated, no communication) is not fun but only causes frustration.

[Igor]

30 minutes ago, tkaiser said:

The lack of project goals and the way work is done (not coordinated, no communication) is not fun but only causes frustration.

Main project goals haven't changed: making good Linux for SBC, make them usable. I am not doing any major short-term plans until major maintenance work and infrastructure changes are (almost) finished. I am drowning in those tasks and image for R40 is a side product of doing that. It was like - ler's play a little in between and since basic things works, I made an image. It is not present at the download page as you expressed that you don't want to see them there.  I'll write sum up what has been done when possible. 

[guidol]

@Igor it seems that there will be a 

Long Term Support (LTS for about 10 years) of the M2 Ultra/Berry with the A40i (fully compatible to R40/V40) and for deeper temperatures:

A40i temperature range is -40 to 85 ,and for LTS ,and R40/V40 is -25 to 85.  features are the same

 

Info at:

http://forum.banana-pi.org/t/bpi-m2-ultra-and-bpi-m2-berry-can-use-allwinner-a40i-chip-onboard/6584

[Igor]

1 minute ago, guidol said:

it seems that there will be a 

Long Term Support (LTS for about 10 years) of the M2 Ultra/Berry with the A40i (fully compatible to R40/V40) and for deeper temperatures:

 

That is just yet another marketing BS which usually originating from upstream, from Allwinne's claim that they will produce the chip this or that long.

 

In reality - it means nothing since all other chips will be produced at least that long.

[tkaiser]

13 minutes ago, guidol said:

A40i (fully compatible to R40/V40)

 

Bullshit.

 

These chips are not "fully" compatible but according to the 'sinovoip bpi team' muppet provide 'PIN to PIN compatibility'. What does this mean? That a careless board maker can replace the reels in a pick-and-place machine and produces something which mechanically fits but where previous software does not work any more.

 

Allwinner H2+/H3 and H5 are pin compatible. Ever looked at how different software support situation looks like?!

 

https://www.cnx-software.com/2018/05/06/allwinner-unveils-a40i-a40pro-and-a60i-a60pro-industrial-military-grade-processors/#comment-553489

 

It's all about software support. Pin compatibility is 100% irrelevant if you look at boards from the user's perspective (and not from board maker's perspective who brags about his ability to replace one SoC with another to re-use their PCBs).

 

Also you should keep in mind where the real work happens. That's linux-sunxi community or to be more precise wens and @Icenowy when it's about R40 and derivates (nobody else is working on these SoCs).

[guidol]

24 minutes ago, tkaiser said:

 

Bullshit.

These chips are not "fully" compatible but according to the 'sinovoip bpi team' muppet provide 'PIN to PIN compatibility'. What does this mean? That a careless board maker can replace the reels in a pick-and-place machine and produces something which mechanically fits but where previous software does not work any more.

I only asked Lion Wang from BPi at Facebook and he answered... thats the only information I did get.

 

https://www.cnx-software.com/2018/05/06/allwinner-unveils-a40i-a40pro-and-a60i-a60pro-industrial-military-grade-processors/

Quote

Allwinner Unveils A40i/A40pro and A60i/A60pro Industrial & Military Grade Processors

 

Allwinner A20 dual core Cortex A7 processor was/is one of the most popular Allwinner SoCs thanks to its low cost, the availability of interfaces such as SATA, Gigabit Ethernet, HDMI 1.4, and multimedia support with H.264 encoding and decoding.

 

The company has now introduced new processors that build upon A20, but working in industrial and military temperature ranges, and compliant with various standards (TBD).
 

Allwinner A40i & A40pro

The first two models are quad core Cortex A7 processors with A40i being the industrial version, and A40pro the military grade one. Both share most of the same specifications:

CPU – 4x Arm Cortex A7 @ 1.2 GHz

GPU – Mali-400 MP2

Memory I/F – DDR2/DDR3/LPDDR2/LPDDR3 up to 3GB RAM

Storage I/F – 32-bit NAND, eMMC, SD card, SPI NOR flash, SPI NAND flash, 1x SATA

Video Engine

Decoder – Multi-format decoder up to 1080p60

Encoder – H.264 encoder up to 1080p45

Video I/F

Output – 1x HDMI, 4x TVOUT, 2x 4-lane LVDS, 2x RGB, 4-lane MIPI DSI

Input

2x parallel CSI, 4x TVIN

No ISP; No EVE (Embedded Vision Engine)

Audio – 2x DAC, 2x ADC

USB – 4x USB 2.0 (3x host interfaces,  1x OTG interface)

Ethernet – 1x EMAC (Fast Ethernet), 1x GMAC (Gigabit Ethernet)

Others – 8x UART, 4x SPI, 5x TWI (I2C), 2x TS, PS2, RTP

I’ve been informed all A-series processors have a 10-year life cycle.  Software (SDK) provided by Allwinner might be different than for Allwinner A20, as I’ve been told the automotive business unit (BU4) is in charge of those new processors, while processors like A20 or A33 for consumer goods are managed by BU2.

 

[tkaiser]

34 minutes ago, guidol said:

Info at:

http://forum.banana-pi.org/t/bpi-m2-ultra-and-bpi-m2-berry-can-use-allwinner-a40i-chip-onboard/6584

 

Where do you find 'info' over there? There are two pictures of the same board showing two different SoCs. And two links to a wiki that is flooded with BS since they still allow their copy&paste monkey to harm their reputation. Quick look at http://wiki.banana-pi.org/Banana_Pi_BPI-M2_Berry: 'he BPI-M2 Ultra has 4 USB A 2.0 ports' (BS!), picture shows R40 (BS!), 'cortex -A7,the most power efficient CPU core ARM's ever development' (BS!), 'dual-core MALI-400 MP2 and runs at 500MHz' (BS! It's 360), '1GB DDR3 with 733MHz' (BS! It's 576 MHz maximum and BSP code even throttles DRAM clockspeeds when overheating) and so on...

 

ZERO information AT ALL as usual. Only BS generated by one or more copy&paste monkey(s).

 

If they would provide information they would show at least a boot log. In case you are member of this forum over there you could ask for. My posts have been censored there way too often to ever write anything there again.

[tkaiser]

4 minutes ago, guidol said:

I only asked Lion Wang from BPi at Facebook and he answered

 

LOL! If that's the case why don't they show a full boot log? That's the only real information and all we need to get a clue about compatibility. Unless a boot log is provided I don't believe anything (especially not when originating from SinoVoip CEO on marketing mission )

[Icenowy]

22 minutes ago, tkaiser said:

 

LOL! If that's the case why don't they show a full boot log? That's the only real information and all we need to get a clue about compatibility. Unless a boot log is provided I don't believe anything (especially not when originating from SinoVoip CEO on marketing mission )

Mikey from Sinovoip showed me some photos on kernel logs that is said to be booting A40i with mainline U-Boot.

 

(Of course this makes no difference as mainline U-Boot doesn't try to recognize the print on the chip ;-) )

[guidol]

46 minutes ago, tkaiser said:

Unless a boot log is provided I don't believe anything (especially not when originating from SinoVoip CEO on marketing mission )

OK - I have requested the boot log:

Guido Imran Lehwalder:
Lion Wang If you got an example of the board with A40i would it be possible to get a bootlog of armbian with kernel 4.18.y from this A40i device?
This would much help for working on armbian for the A40i version of the board ;)
And maybe if you logged in in armbian also a the info from:
armbianmonior -u

Lion Wang:

Guido Imran Lehwalder Ok ,i will let my R&D ( Research and development ) do this work ,thank you.

i see armbian have a beta image for Ultra and berry .

 

I also doubled the request in their forum.
 

[guidol]

On 4/1/2018 at 10:25 PM, zakri said:

Hey. I have a banana pi m2u (Allwinner A40)

If your m2u has a A40 or A40i CPU - could you please make a picture of the board and provide a bootlog and
armbianmonitor -u from the armbian with 4.18.x kernel?
Because we mostly have the "older" boards with R40 or V40 CPU.
 

Thanks in advance

[tkaiser]

56 minutes ago, Icenowy said:

Of course this makes no difference as mainline U-Boot doesn't try to recognize the print on the chip

 

Judging by specs A40i could be an R40/V40 with just 1 more USB2 host port. But then I don't understand the pin to pin compatibility (1 more USB host port that is not exposed?). Or maybe it's a simple typo on cnxsoft and A40i is really just a rebranded R40/V30/T3 with different temperature range and another BU in charge?

[guidol]

here the boot-log from Lion Wang:

http://ix.io/1l6s

[tkaiser]

1 hour ago, guidol said:

I also doubled the request in their forum

 

And they delivered. So given this was on the A40i board it's the same as R40/V40/T3 but just different temperature range, different markings and different BU. CPU info is the same with R40 and A40i:

model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 48.00
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

 

Ok, doesn't change anything since putting an A40i on a BPi M2U or M2 Berry PCB doesn't make them 'industrial grade' boards (at least different eMMC and GbE PHY needed to to withstand extended temperature requirements). But we know that OS images for R40 and V40 also work with A40i (and of course with T3 too since they're all simply the same)

[guidol]

there is also another log on the bpi-forum page where the cpu-identification says R40:

http://forum.banana-pi.org/t/bpi-m2-ultra-and-bpi-m2-berry-can-use-allwinner-a40i-chip-onboard/6584/2

[tkaiser]

6 minutes ago, guidol said:

there is also another log on the bpi-forum page where the cpu-identification says R40:

 

Are you referring to this?

CPU:   Allwinner R40 (SUN8I 1701)
Model: Banana Pi BPI-M2-Ultra

That's just what has been defined in u-boot that will be printed. Will say R40 on a V40 or in this case A40i.

[Icenowy]

2 hours ago, tkaiser said:

 

Judging by specs A40i could be an R40/V40 with just 1 more USB2 host port. But then I don't understand the pin to pin compatibility (1 more USB host port that is not exposed?). Or maybe it's a simple typo on cnxsoft and A40i is really just a rebranded R40/V30/T3 with different temperature range and another BU in charge?

Currently what I heard is that the extra USB2 port is on some NC pin.