September Posted September 2, 2015 Posted September 2, 2015 Hi Igor, I encountered an issue on Bananapi with kernel 4.2 using your latest SDK: A reboot or powercycle will fail with getting eth0 up and running (no IP address). I tried these both combinations: u-boot: 2015.04 + kernel: 4.2 u-boot: 2015.07 + kernel: 4.2 dmesg delivers: [ 13.387092] sun7i-dwmac 1c50000.ethernet: no reset control found [ 13.394879] Ring mode enabled [ 13.402647] No HW DMA feature register supported [ 13.402814] Normal descriptors [ 13.418061] TX Checksum insertion supported [ 13.498887] libphy: PHY stmmac-0:ffffffff not found [ 13.507177] eth0: Could not attach to PHY [ 13.515283] stmmac_open: Cannot attach to PHY (error: -19) [ 13.615876] libphy: stmmac: probed [ 13.623515] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [ 13.631591] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) [ 98.534925] nf_conntrack version 0.5.0 (15937 buckets, 63748 max) Don't know if eth0 interface received a new code base. Using a search engine I only found links related to sunxi 1Gbps eth0 interface which were fixed in u-boot. That's the reason I tried both u-boot releases with kernel 4.2. Compared with u-boot: 2015.04 and kernel: 4.1.6 (used branch 'next' with some warning messages during patch process but not related to BPi): [ 11.861140] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=writeback,commit=600,errors=remount-ro [ 12.194582] systemd-journald[106]: Received request to flush runtime journal from PID 1 [ 13.947698] RX IPC Checksum Offload disabled [ 13.955635] No MAC Management Counters available [ 17.937024] stmmaceth 1c50000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 28.140918] nf_conntrack version 0.5.0 (15941 buckets, 63764 max) Any idea? Thanks, ~September~
Igor Posted September 2, 2015 Posted September 2, 2015 I only tried to compile 4.2 Haven't got a chance to boot it. If kernel is ok than the most problematic part is patching. This cannot work properly for all new versions. I suspect this: https://github.com/igorpecovnik/lib/blob/next/patching.sh#L57 Restore that file from original and try again. BR
Igor Posted September 2, 2015 Posted September 2, 2015 I just try to boot 4.2 ... no problem. (Uboot 2015.04)Have you install a new DTB packets together with kernel too?
September Posted September 2, 2015 Author Posted September 2, 2015 I only tried to compile 4.2 Haven't got a chance to boot it. If kernel is ok than the most problematic part is patching. This cannot work properly for all new versions. I suspect this: https://github.com/igorpecovnik/lib/blob/next/patching.sh#L57 Restore that file from original and try again. BR Not sure if I get you correctly ... BPi is A20 but the refered patch is A10. I presume the hardware wiring/connection is the same for A20 and A10? Another point: # copy orange pi DTS if [ "$(cat arch/arm/boot/dts/Makefile | grep sun7i-a20-orangepi)" == "" ]; then sed -i 's/sun7i-a20-bananapi.dtb \\/sun7i-a20-bananapi.dtb \\\n sun7i-a20-orangepi.dtb \\/g' arch/arm/boot/dts/Makefile cp $SRC/lib/patch/sun7i-a20-orangepi.dts arch/arm/boot/dts/ cp $SRC/lib/patch/sun4i-a10.h arch/arm/boot/dts/include/dt-bindings/pinctrl fi So the patch for the orange pi applies to the bananapi as well? May I have to change the if-construct? Thank you, ~September~
Igor Posted September 2, 2015 Posted September 2, 2015 Certain things are shared among A10 / A20. I am just guessing here ... but like I said. It's working for me. Are you compiling on Ubuntu 14.04 LTS ?
September Posted September 2, 2015 Author Posted September 2, 2015 I just try to boot 4.2 ... no problem. (Uboot 2015.04) Have you install a new DTB packets together with kernel too? Yes, I did: root@bananapi:~/42# dpkg -i *.deb Selecting previously unselected package linux-dtb-next-sunxi. (Reading database ... 117730 files and directories currently installed.) Preparing to unpack linux-dtb-next-sunxi_4.2_armhf.deb ... Unpacking linux-dtb-next-sunxi (4.2) ... dpkg: error processing archive linux-dtb-next-sunxi_4.2_armhf.deb (--install): trying to overwrite '/boot/dtb/sun4i-a10-chuwi-v7-cw0825.dtb', which is also in package linux-dtb-4.1.6-bananapi 3.2 Preparing to unpack linux-firmware-image-next-sunxi_4.2_armhf.deb ... Unpacking linux-firmware-image-next-sunxi (4.2) over (4.2) ... Preparing to unpack linux-headers-next-sunxi_4.2_armhf.deb ... Unpacking linux-headers-next-sunxi (4.2) over (4.2) ... Preparing to unpack linux-image-next-sunxi_4.2_armhf.deb ... Unpacking linux-image-next-sunxi (4.2) over (4.2) ... Preparing to unpack linux-u-boot-next-bananapi_4.2_armhf.deb ... Unpacking linux-u-boot-bananapi-next (4.2) over (4.2) ... Setting up linux-firmware-image-next-sunxi (4.2) ... Setting up linux-headers-next-sunxi (4.2) ... Setting up linux-image-next-sunxi (4.2) ... Setting up linux-u-boot-bananapi-next (4.2) ... Errors were encountered while processing: linux-dtb-next-sunxi_4.2_armhf.deb root@bananapi:~/42# dpkg -r linux-dtb-4.1.6-bananapi (Reading database ... 117730 files and directories currently installed.) Removing linux-dtb-4.1.6-bananapi (3.2) ... root@bananapi:~/42# dpkg -i linux-dtb-next-sunxi_4.2_armhf.deb (Reading database ... 117685 files and directories currently installed.) Preparing to unpack linux-dtb-next-sunxi_4.2_armhf.deb ... Unpacking linux-dtb-next-sunxi (4.2) ... Setting up linux-dtb-next-sunxi (4.2) ... root@bananapi:~/42# If I issue a 'reboot' now, the system comes up as expected. dmesg: [ 11.128017] sun7i-dwmac 1c50000.ethernet: no reset control found [ 11.128069] Ring mode enabled [ 11.128089] No HW DMA feature register supported [ 11.128099] Normal descriptors [ 11.128124] TX Checksum insertion supported [ 11.186223] libphy: stmmac: probed [ 11.186278] eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active [ 11.186301] eth0: PHY ID 001cc915 at 1 IRQ POLL (stmmac-0:01) [ 11.347732] RX IPC Checksum Offload disabled [ 11.347794] No MAC Management Counters available [ 15.337060] sun7i-dwmac 1c50000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 24.103321] nf_conntrack version 0.5.0 (16063 buckets, 64252 max) Now I issued a 'halt' and waited. Removed power supply and reconnected. Boot fails. If I'm lucky it succeeds after a number of power-off/power-on/reset tries. Tried several power supplies already as well as SD-cards. MacBookPro:~ $ ssh user@bananapi.local ssh: Could not resolve hostname bananapi.local: nodename nor servname provided, or not known Need to grab a keyboard and monitor to recover ... ~September~
Igor Posted September 2, 2015 Posted September 2, 2015 If I issue a 'reboot' now, the system comes up as expected o.k. If I'm lucky it succeeds after a number of power-off/power-on/reset tries. You are running latest version of kernel. You can't expect that everything works well yet. I also can't assist since i did one single boot with latest kernel. ssh user@bananapi.local Wrong approach. Use ip address.
September Posted September 2, 2015 Author Posted September 2, 2015 Hi Igor, problem(s) solved! My BPi seems to be sensitive (timewise during boot, I guess). A friend's BPi didn't show this issue and was booting/rebooting all times with and without power cycling. Followed your advice: Reinstalled a vanilla 14.04.03 in a VM, updated suggested patches and left locale on en_US except keyboard. With this configuration my BPi "survives" powercycling too ... I owe your at least a beer. Thanks for your patience and hints. Cheers, ~September~ PS: Please add a 'solved' to the topic. Can't access the headline. Thanks.
Igor Posted September 2, 2015 Posted September 2, 2015 Nice to hear this. Hardware quality can be an issue too but it's rear according to my experiences so this is usually the last option left. At least language settings on host should not affect on compilation. I covered that part but of course the "not-us language bug" can be somewhere.
Recommended Posts