Le Potato Ethernet Problems

[TonyMac32]

You could do an iperf test between the potato and a "known good" device.  At the moment I'm trying to figure out the ethernet MAC issue, ideally I'd have the system use the efuse, but I think these SoC's come "empty"as far as MAC address goes.  Could you give me the output of
 

hexdump /sys/bus/nvmem/devices/meson-efuse0/nvmem

For all 4 boards?  (unless all identical outputs, then 1 will do.  ;-)

 

My guess is you'll get

[BL31]: tee size: 0
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
00000c0

meaning all 0's all the time.

 

Using U-boot I manually stuffed a value in there, the command was 'efuse write 0x34 0x6 <6 characters ASCII >'  so now I get this result:

 

[BL31]: tee size: 0
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000030 0000 0000 3561 3462 3363 0000 0000 0000
0000040 0000 0000 0000 0000 0000 0000 0000 0000
*
00000c0

Be careful, I haven't tested if this is one time programmable or not.   <<--- warning stands

 

I will try to get u-boot to set the ethernet mac address using the efuse, and work out some logic for either letting the user set it, or have it burn the first random it produces into the efuse and then use it permanently.  I'm not the expert on this, so feel free to bash the idea/mock me/etc.

 

pseudo-code:

ethMac = efuse read 0x34 0x6;

if(ethMac == 0)
{
	ethMac = random_address;
	efuse write 0x34 0x6 ethMac;   // <-- will have to work out the ASCII wrinkle
}
                                      
setEthernetMacAddress( ethMac );

The savvy user could set their own and this would not conflict.

[Tido]

@TonyMac32, do the lights on your ethernet port blink ?  mine are just dark, but the connection works

 

root@lepotato:~# uname -a
Linux lepotato 4.14.7-meson64 #51 SMP PREEMPT Tue Dec 19 12:33:49 CET 2017 aarch64 GNU/Linux

Welcome to ARMBIAN 5.37.171220 nightly Debian GNU/Linux 9 (stretch) 4.14.7-meson64

 

init 0   still triggers reboot.

[TonyMac32]

13 minutes ago, Tido said:

mine are just dark, but the connection works

Mine are dark as well, it's low on the list but yes, a problem that will need addressed.

 

14 minutes ago, Tido said:

init 0   still triggers reboot.

Unrelated to ethernet, but will add to the proper thread.

[NinjaKitty]

On 12/20/2017 at 12:13 PM, TonyMac32 said:

Could you give me the output of
 

hexdump /sys/bus/nvmem/devices/meson-efuse0/nvmem

For all 4 boards?  (unless all identical outputs, then 1 will do.  ;-)

 

Did you want these on boot? or just whenever? Anyways they all look just like as you said

0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
00000c0

 

 

I ran iperf between 2 PI's and I noticed something strange:

When I use UDP mode, I get around 1.03 Mbps on transfer rates (average over 10 second intervals)

When I use TCP mode, I get around 94 Mbps transfer rates

 

I can also try to do an iperf from another known device, but I don't have a linux machine available outside of the lepotatoes at the moment, so I'll do that another time.

[lanefu]

 
Did you want these on boot? or just whenever? Anyways they all look just like as you said

0000000 0000 0000 0000 0000 0000 0000 0000 0000*00000c0

 
 
I ran iperf between 2 PI's and I noticed something strange:
When I use UDP mode, I get around 1.03 Mbps on transfer rates (average over 10 second intervals)
When I use TCP mode, I get around 94 Mbps transfer rates
 
I can also try to do an iperf from another known device, but I don't have a linux machine available outside of the lepotatoes at the moment, so I'll do that another time.

Iperf's UDP defaults are low bandwidth and I think focused on latency. You can explicitly set a desired bitrate for UDP with a parameter. Try that and see if things are better.

Sent from my SM-G950U using Tapatalk

[NinjaKitty]

7 hours ago, lanefu said:

Iperf's UDP defaults are low bandwidth and I think focused on latency. You can explicitly set a desired bitrate for UDP with a parameter. Try that and see if things are better.

 

Used iperf -ub 100 -c [server-ip] as the command (should be 100 Mbps bandwidth), and i still get the same 1Mbps

server is running using iperf -us

[Andro]

Hello All, I have been away from this board for a while. Apologies for the very basic question, but how can I obtain or build an image for the Potato with the fixes described here?

 

I read something about Armbian nightly builds no longer being made available (and, even more basic, I don't know where they are. Just the head of the git repo?)

 

[NinjaKitty]

On 1/3/2018 at 12:08 AM, Andro said:

Hello All, I have been away from this board for a while. Apologies for the very basic question, but how can I obtain or build an image for the Potato with the fixes described here?

 

https://dl.armbian.com/lepotato/

 

If you're just installing a fresh image, you can just grab the latest nightly build, then do a sudo apt-get update/upgrade cycle to get the latest nightly version.

 

If you're doing it on an already installed image, and you're not on nightly builds, then you have to follow this: http://www.armbian.com/kernel/

You could use armbian-config if you have it, but in my experience, I can't even use it properly.

 

[zikzak]

Is the Ethernet issue fixed?

If so, how can I fix it?

 

cat /etc/*-release
# PLEASE DO NOT EDIT THIS FILE
BOARD=lepotato
BOARD_NAME="Le potato"
VERSION=5.35
LINUXFAMILY=meson64
BRANCH=next
ARCH=arm64
IMAGE_TYPE=user-built
BOARD_TYPE=conf
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image
# PLEASE DO NOT EDIT THIS FILE
BOARD=lepotato
BOARD_NAME="Le potato"
BOARDFAMILY=meson64
VERSION=5.37
LINUXFAMILY=meson64
BRANCH=next
ARCH=arm64
IMAGE_TYPE=user-built
BOARD_TYPE=conf
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

 

I still have issues, when I upload via SCP after a couple of seconds I lose the connectivity and I have to power down the board.

[Andro]

I think the vendor has fixed the ethernet problem in their release build. Has this fix made it into armbian yet or not? Sorry, it's not clear to me from reading this thread whether that is a definite yes or no.

[TonyMac32]

1 minute ago, Andro said:

I think the vendor has fixed the ethernet problem in their release build.

 

We use the same patchset for kernel 4.14 as the vendor, so yes, the fix has been in, I believe, all 4.14 builds, certainly is in the linked downloads.

[plizt]

Hi folks,

 

I am experiencing quite some problems (concerning the networking) with the le potato right now.

I started out with the Armbian Stretch mainline kernel 4.14.y and lost complete network connection on simple update.

I could log in with peripherals but could not get a valid ip via eth0 or a wireless dongle (I could connect to my wifi though)

 

I then reflashed version 4.14 and updated without modifications aside from adding ssh-keys. => same failure.

 

Just before this entry I flashed the 4.17. mainline on the card and I have now no network connection to begin with...
Downloaded from here: https://dl.armbian.com/lepotato/Debian_stretch_default.7z

I rebooted, but no nothing. Right at the start. It seems to me the image is missing something?

 

So I wonder: Is there a stable armbian build atm for headless usage of the le potato that can be safely updated?

Because I don't run my single board machines near peripherals usually...

 

Thanks in advance for any advice!

 

Phil

 

[TonyMac32]

I would recommend reflashing 4.14 and freezing the kernel for now using the armbian-config tool.  We will have to verify this failure (I was not aware of it) and look for a solution.