jerryc

Hi Wondering if there are instructions on how to use the newer dwmac driver (instead of sun8i-emac.c) on the dev branch 4.10.x ? thanks jerry

thanks, the line worked, I see the compile now pulling orange-pi-4.9. Unfortunately, the compiled failed. Have anyone tried to 4.9? │ LD drivers/staging/built-in.o │ │ Makefile:988: recipe for target 'drivers' failed │ │ make: *** [drivers] Error 2 Problem is here, any quick thoughts how to proceed? Is this just me, or the current branch shouldn't compile with 4.9? result [-Wunused-result] devm_request_irq(dev, irq, sdio_irq_handler, 0, "xradio", func); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CC [M] drivers/media/usb/stkwebcam/stk-webcam.o CC [M] drivers/net/wireless/realtek/rtl8189fs/core/rtw_recv.o CC [M] drivers/scsi/iscsi_tcp.o CC [M] drivers/net/wireless/realtek/rtl8189fs/core/rtw_sta_mgt.o drivers/spi/spi-sun6i.c: In function ‘sun6i_spi_fill_fifo’: drivers/spi/spi-sun6i.c:160:12: error: ‘struct sun6i_spi’ has no member named ‘fifo_depth’ cnt = sspi->fifo_depth - sun6i_spi_get_tx_fifo_count(sspi); ^~ drivers/spi/spi-sun6i.c: In function ‘sun6i_spi_transfer_one’: drivers/spi/spi-sun6i.c:304:19: error: ‘struct sun6i_spi’ has no member named ‘fifo_depth’ if (tx_len > sspi->fifo_depth) ^~ drivers/spi/spi-sun6i.c: In function ‘sun6i_spi_handler’: drivers/spi/spi-sun6i.c:345:34: error: ‘struct sun6i_spi’ has no member named ‘fifo_depth’ sun6i_spi_drain_fifo(sspi, sspi->fifo_depth); ^~ drivers/spi/spi-sun6i.c:352:34: error: ‘struct sun6i_spi’ has no member named ‘fifo_depth’ sun6i_spi_drain_fifo(sspi, sspi->fifo_depth); ^~ drivers/spi/spi-sun6i.c:360:33: error: ‘struct sun6i_spi’ has no member named ‘fifo_depth’ sun6i_spi_fill_fifo(sspi, sspi->fifo_depth); ^~ LD [M] drivers/media/usb/gspca/gspca_sq905c.o

Hi I want to build armbian for nanopi neo with a different mainline. What I have done is 1. added lib.config file in userpatches with statement ARMBIAN_MAINLINE_KERNEL_VERSION='4.9' that didn't work, I still get a 4.10.1 kernel build 2. then changed configration.sh ARMBIAN_MAINLINE_KERNEL_VERSION='4.9' that didn't work either, I got 4.10.1 kernel build Any other tricks? -jerry

@kabturek are you fixing the half duplex issue? If not, could i get some general directions, I think i can of help as well.

Got my nano pi neo booted as well. Eth0 is stuck at half duplex, anyone else seen this?

@szwistak I can't find it any more either. I been trying to reproduce that build done by igore, but no success, so i give up and wait until some one build another working image with 4.9.4 or something like it ...

Hi Wondering if anyone knew the algorithm that assigns mac addresses to orange zero. Is it based on something static/cpu id /...? or it is purely random. Will this mac change over time or after it is generated, it will stay the same? I have one zero that mac is pretty static and another changed mac after I did a upgrade. If I want better control of the mac address, what's the best way to make it static? this is on the mainline -jerry

Regarding the ethernet driver development discontinued. Is that part of sunxi-linux or armbian? (sorry I am new to this). If the driver is no longer operational (or operate with some problems, possible to go back to something that was working?) Is this from upstream kernel or from armbian? Is this something that a newbie can help? -jerry

Got it, so the neo is a exact copy of orange one? I assume it is. Any idea on when will the ethernet be re-enabled? Yes, now I got the ethernet working with your new config line. Now I am running into the same issue that I am having in orange pi zero with the nano pi. The interface is again stuck at 100MB in half duplex. Are all of these problems all related?

My Zero works too. It is just the image with 4.9.0 kernel with Ethernet as 100 Full duplex and 4.9.4 with half duplex. 4.9.4 also doesn't work with my new Nano Pi Neo. Yes, I do understand, I need the console log. Still trying to figure out how to attach it and getting a USB to serial as well. My overall frustration is, I do understand perfectly that dev branches are not suppose to be release quality. It will be good if we mark as a community that certain images are better than others.

I have searched all the forums, can't find a way to use compile.sh build a image with the kernel to be 4.9.0 version. Is there a variable some where to set this? the latest 4.9.4 and 4.9.3 are not working well for my nanopi or my orange zero. and yes, i went through all the docs, and tried I can. -jerry

you should get the heat sink from them. they stick to the back and i get like 40 to 50 C

Same here, I got my Neo today unable to boot with the newer kernel (using nightly). Unfortunately, no serial output. will figure out how to connect the serial now. Still trying to figure out how to roll back the kernel to 4.9.0 ... no success yet. can't find the doc either.

@martinayotte Appreciate your help. Just cloned a workspace and build a fresh image. (no special config, just a orange pi zero debian 4.9 server image) I am still getting the eth0 at half Duplex. An older image given to be by @igor this image works perfectly (with Full Duplex and solved stability issues) root@orangepizero:~# uname -a Linux orangepizero 4.9.3-sun8i #1 SMP Sat Jan 14 17:08:59 PST 2017 armv7l GNU/Linux root@orangepizero:~# mii-tool eth0 -v eth0: negotiated 100baseTx-HD, link ok product info: vendor 00:11:05, model 0 rev 0 basic mode: isolate, autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-HD 10baseT-FD link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control

@martinayotte Just did a git pull and used compile.sh to create a new mainline image for orangepizero. The half duplex is still there. I assume you also used the compile.sh script for your images. If not let me know, I can try your way as well. root@orangepizero:~# uname -a Linux orangepizero 4.9.3-sun8i #5 SMP Fri Jan 13 15:57:42 PST 2017 armv7l GNU/Linux root@orangepizero:~# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Half Port: MII PHYAD: 1 Transceiver: external Auto-negotiation: on Current message level: 0x00000000 (0) Link detected: yes root@orangepizero:~# mii-tool -v eth0: negotiated 100baseTx-HD, link ok product info: vendor 00:11:05, model 0 rev 0 basic mode: isolate, autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-HD 10baseT-FD link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control root@orangepizero:~#

Is there a way to tell the tool That's why we have tools, to build using different kernel? or it is fixed?

@admin The kernel was build using the github repo that you listed. Hence my question on why the latest build locks into half duplex. Unless you mean there are other batches beside your repo? or other ways to build? (I am following your build instructions) Unless you are saying there are additional patches that are not in the repo that you listed. Also, I am very possitive it is not switch/cable/power issue. the test was done using two images. One was provided by you a while back on another question, and one is the image I build using the repo. any ideas? -jerry

Hi Pulled latest git repo and build mainline image (Ubuntu/Debian both) 4.9.2-sun8i kernel. Eth0 now stuck at 100mb/s and half duplex. I have tried using ethertool to make it full duplex. Not working. The previous image which I used and suggested was Armbian_5.24.170109_Orangepizero_Ubuntu_xenial_4.9.0 This image works with full duplex. Is this a bug or there is more configs needed when I building my own images? From ethtool output, looks like problem with auto negotiation. pi@orangepizero:~$ sudo ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Half Port: MII PHYAD: 1 Transceiver: external Auto-negotiation: on Current message level: 0x00000000 (0) Link detected: yes eth0: negotiated 100baseTx-HD, link ok product info: vendor 00:11:05, model 0 rev 0 basic mode: isolate, autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 100baseTx-HD 10baseT-FD link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control -jerry

That's certainly not my case. the initial problem is not power related. The same image with an apple iPad supply still reboots when network traffic is very high. This is only solved by the new kernel ...

Community driven testing is customer testing. Is it perfect, no ... Is it realistic ... yes. As the number of users grow, the coverage will increase. Even the test cases are not well defined, but law of big numbers will solve that. -jerry

The reason I am using the main line is the legacy kernel when doing high traffic on the ethernet will reboot for no reason. The mainline kernel seems to fix it nicely. With regard to nightly, my suggestion is to supply images periodically and have users verify and test them. (I will happy to do that). this way , you have a image that's more stable than the 'automated, untested image'. And it will be community driven testing. The key is to have a freeze point ..

Hi, thank you all for the support, I did change to another power supply, the one I used on my iPad, now it is very stable. I always thought the none portable 'bigger' plugs are more stable. Temperature is still high, so wondering will the h3consumption tool be ported to this kernel? if not, will armbian create something similar? And lastly, will there be an official release of this image from Armbian? -jerry

This this image is fairly stable, the temperature seems to be lower as well. Is the armbian team going to release this image any time soon? Also will h3consumption tool be included in this kernel? I find it extremely useful. Latest: the board will reboot after 1 hour or so when under iperf stress. the temperature 2 min before the reboot is 65C. Using the older image, it will reboot in less than 2 min.

Hi Just got my first Orange Pi Zero today. Everything looking good, with the exception, if I run iperf tests between this and a linux host, the Orange Pi Zero will reboot without any error messages. I changed my power supply to a wall plug which can support 2.4amp easily, also tried to tune down the frequency to 900Mhz max, 4 cores, turned off HDMI/GPU, USB. DRAM is at minimum, 408 I think. Temperature remains at 55 to 58C Still once a while during heavy network, the board will reboot. The image i used is the legacy image posted on orange pi zero, Armbian_5.24_Orangepizero_Debian_jessie_3.4.113 Thanks Jerry