Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

FriendlyARM NanoPi R1 not booting in 22.03.01-rc4 #10080

Open
mmeelix opened this issue Jun 18, 2022 · 8 comments
Open

FriendlyARM NanoPi R1 not booting in 22.03.01-rc4 #10080

mmeelix opened this issue Jun 18, 2022 · 8 comments
Labels
target/sunxi pull request/issue for sunxi target

Comments

@mmeelix
Copy link

mmeelix commented Jun 18, 2022

FriendlyARM NanoPi R1 not booting in 22.03.01-rc4, 22.03.01-rc1 or snapshot
All is well on 21.02.3 (r16554-1d4dea6d4f)
@pepe2k pepe2k added target/rockchip pull request/issue for rockchip target insufficient details issue without enough details/information provided labels Jun 18, 2022
@ghost
Copy link

ghost commented Nov 19, 2022

I think there is indeed something wrong with Openwrt 22 on this particular device. I suspect there is an issue with the network configuration.

Tested version: OpenWrt 22.03.2, r19803-9a599fee93

On my test setup the WAN interface seems to pick an IPv6 address but there is no IPv4 connectivity:

root@OpenWrt:/# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether e2:9e:6e:6a:b9:9f brd ff:ff:ff:ff:ff:ff
    inet6 2a02:2788:1004:909:e09e:6eff:fe6a:b99f/64 scope global dynamic noprefixroute 
       valid_lft 1209591sec preferred_lft 604791sec
    inet6 fe80::e09e:6eff:fe6a:b99f/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 8c:f7:10:46:a0:8c brd ff:ff:ff:ff:ff:ff
4: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel master br-lan state DOWN qlen 1000
    link/ether 5e:fe:f0:4b:1c:fe brd ff:ff:ff:ff:ff:ff
5: br-lan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
    link/ether 5e:fe:f0:4b:1c:fe brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fd2d:5058:a0ab::1/60 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::5cfe:f0ff:fe4b:1cfe/64 scope link 
       valid_lft forever preferred_lft forever

Contents of /etc/config/network:

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd2d:5058:a0ab::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option device 'eth0'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth0'
        option proto 'dhcpv6'

The file looks wrong to me. Isn't the bridge section supposed to have two interfaces?

However, I have become aware of an important change between Openwrt 21.x and 22.x (not sure if it's related but mention it just in case):

OpenWrt 22.03 and later ships with firewall4 by default, which uses nftables as a backend (instead of iptables).

Source: Firewall configuration /etc/config/firewall

I have noticed no problem on other devices like the Nanopi R4S.

@981213 981213 added target/sunxi pull request/issue for sunxi target and removed target/rockchip pull request/issue for rockchip target labels Dec 2, 2022
@linxcow
Copy link

linxcow commented Dec 11, 2022

Yes i have the same problem with a fresh nanopi r1 and testing with 22.03.2 images for this device.

Does not hand out ip to a wired device on LAN interface, so from here on its a dead device.

Friendlywrt image based on 19.07 works but is too old for current use.

@AiyionPrime
Copy link
Contributor

@mmeelix, @pepe2k Must have overlooked this before, as I opened #11104 in october.

@linxcow opened #11469 yesterday. Where do we want to continue the bughunt? :)

@linxcow
Copy link

linxcow commented Dec 12, 2022

Yes for me it wasnt clear if the cpu frequency problem was also causing the problem i experienced with not handing out an ip address.

@AiyionPrime
Copy link
Contributor

Your device is not only not giving out ip-addresses, but fails to boot from mmc entirely, as your posted log suggests.

@linxcow
Copy link

linxcow commented Dec 12, 2022

Oh thx for pointing that out , i didnt realize it.

@stintel
Copy link
Member

stintel commented Dec 22, 2022

Sorry, used the wrong issue in the commit message. The idea is to backport bf06a7c to 22.03 early 2023 if there is no fallout reported.

@stintel stintel reopened this Dec 22, 2022
@stintel stintel mentioned this issue Dec 22, 2022
Closed
@stintel stintel removed the insufficient details issue without enough details/information provided label Dec 22, 2022
Vladdrako pushed a commit to Vladdrako/openwrt that referenced this issue Dec 22, 2022
@AiyionPrime @karlp @Vladdrako
uboot-sunxi: use UUID of bootdev and bootpart
01aee07 
Several sunxi devices come with multiple mmc devices. On such devices,
the mmc device order is unpredictable, so using /dev/mmcblk0p2 as root
device doesn't always work, which results in unbootable devices.

For the Banana Pi BPI-R3 in the mediatek target, this has been solved by
defining aliases for the mmc devices in the DTS. Ideally we would do the
same here, but for sunxi-a64 we already use UUID probing, so let's start
with that (5f2ff60 ("uboot-sunxi: a64: allow booting directly from
eMMC")).

Since we're building and including u-boot in each supported device
image, and this method has been proven to work fine for a64, let's just
change the default u-boot env file to do the same.

Fixes: openwrt#10080
Fixes: e6d9f6f ("sunxi: add support for FriendlyARM NanoPi R1")
Co-authored-by: Karl Palsson <karlp@etactica.com>
Signed-off-by: Jan-Niklas Burfeind <git@aiyionpri.me>
[use UUID in default u-boot env, rewrite commit message]
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
@AiyionPrime AiyionPrime mentioned this issue Dec 22, 2022
Closed
22 tasks
@linxcow
Copy link

linxcow commented Mar 29, 2023 •
edited

I've tried the 22.03.3 from file selector for my nanopi R1 hoping it was fixed but it seems it still has the same issue.( not booting)
https://firmware-selector.openwrt.org/?version=22.03.3&target=sunxi%2Fcortexa7&id=friendlyarm_nanopi-r1

When can we expect that the patch is incorporated when downloaded from firmware-selector ?

So i've gone back to openwrt-21.02.5-sunxi-cortexa7-friendlyarm_nanopi-r1-squash-sdcard.img.gz for now , no problems but probably unfixed security issues being a year old.

fengmushu pushed a commit to fengmushu/openwrt that referenced this issue Nov 18, 2023
@Beginner-Go
toolchain/gcc: GCC12 sync upstream (openwrt#10080)
985cc94
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
target/sunxi pull request/issue for sunxi target
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@stintel @pepe2k @981213 @AiyionPrime @linxcow @mmeelix