jerryc
-
Posts
24 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jerryc
-
-
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 2Problem 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
Not a copy, but most things will be compatible enough for the purpose of testing.
When/if anybody of the devs creates a patch or if anybody makes a pull request. For now this is a very low priority task.
No idea. As I said before in some other thread, the driver development was discontinued, so everything will be as it is now for a while.
-
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.
Adding something like
[[ $BOARD == orangepizero && $BRANCH == dev ]] && KERNELBRANCH="tag:v4.9.0"
to userpatches/lib.config may work, but
- You may need to adjust some patches if there are any conflicts
- H3 specific fixes that were added after 4.9.0 will not be included, so you may create more problems than solve
- 4.9.4 works for me on Zero, tested today. The best way to solve any issues is providing a serial console log
-
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
Yes, it was my own builds done with compile.sh
-
My OPiZero is in full duplex, either with last week's build or today's build.
@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:~#
-
You are trying to use kernel built from developer branch where problems are more than expected. This kernel is not ready for usage ... we can't and we don't waste time on supporting something that changes within hours.
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
@jerryc
Our kernel sources are attached to development branches and there are a list of patches on top of this, that things works. Building from mainline sources without additional patches is not the way to go. Waste of time. ATM.
-
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 ...
In other words: You fixed your power supply problem in the meantime and blame the kernel
Again: OPi Zero unfortunately uses the most crappy connector on earth for DC-IN. If you experience a 'reboot for no reason' then this is most probably related to powering problems. If you still have problems 'with legacy kernel' then search for a proper USB cable between PSU and board as already suggested.
-
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
Nightlies work fine for now, but the build process needs to be extended in order to report if there were any rejected kernel/u-boot patches, so there are ways to make the nightlies system better and more reliable.
"Community driven testing" doesn't work in reality as far as I can see - people don't know what they are testing, don't know what to expect from experimental images, don't know how to properly report any problems (and what is a real problem and what is not).
As for a "freezing point" - we have stable releases, where even if there are problems, they are expected.
-
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
dwmac driver for orange pi/nanopi neo
in Armbian build framework
Posted
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