What is the expected timeline for getting this into master with proper snapshots now that it is in staging?
Also, looks like there is no resolution for getting the real mac address off the device, very poor design of FriendlyARM that we need to work with randomised address
Generating rendom MAC addresses works around this issue. Otherwise, all
boards running the same image have identical MAC addresses.
It's already in master: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=b7a9a183fb44f77d9f95c20bcec1db0edea9e206
Using Snapshot build, the green link light on the WAN RJ45 is blinking every ~2 seconds rather than staying solid. The green link light on the LAN RJ45 seems fine (solid).
It's working fine for me, but i compiled the firmware my self.
Does anyone else have the problem with the 2 August official snapshot that there is no network connectivity?
While troubleshooting a connectivity issue on the WAN side, I loaded the August 2 snapshot this morning and got no connectivity whatsoever. Links are reported UP but DHCP, ping etc. don't work on either LAN or WAN. See New OpenWrt device does not work behind RFC1483 VDSL bridge?
I'm having the same problem, whether I compile my own code from the OpenWrt master branch or download the compiled file from the OpenWrt website, I only see the SYS light on after startup and the network interface is unresponsive.
I think the problem may be caused by commit d1a8217d87bffa33fd7d4562b3ed2f797c14beaf.
I'm trying to return the previous code for re-compile testing, I'll come back up with a response if I get results.
I've returned several versions and recompiled them and they still don't work.
So I tried using the serial port to receive logs to find the problem, and I found that it wasn't a kernel problem, but a problem that happened before UBoot started the kernel.
This is the start-up serial logs.
The firmware from: https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-friendlyarm_nanopi-r2s-squashfs-sysupgrade.img.gz
SHA256: 34864101ba2cbda0f022af04596da04594bf2a599fa55e39fb39cc8a99e82cf2
U-Boot TPL 2020.07 (Aug 03 2020 - 21:34:34)
DDR4, 333MHz
BW=32 Col=10 Bk=4 BG=2 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL 2020.07 (Aug 03 2020 - 21:34:34 +0000)
Trying to boot from MMC1
spl: mmc init failed with error: -95
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
I will continue to update the post if there are any updates
I'm also can't boot the device only when I use the squashfs images, however from ext4 images boot fine.
So far my attempts at ext4 or squashfs have failed to boot, and I get the same error code -95.
It's working well for me on today locally build image.
-----------------------------------------------------
OpenWrt SNAPSHOT, r14032-e47bec489f
-----------------------------------------------------
root@OpenWrt:/# uname -a
Linux OpenWrt 5.4.52 #0 SMP PREEMPT Tue Aug 4 13:51:08 2020 aarch64 GNU/Linux
I think this is a problem caused by the differences between TF cards.
I traced the function call in question.
There are two possible ways to return error -EOPNOTSUPP(-95)
mmc_init() -> mmc_start_init() -> mmc_get_op_cond() -> mmc_send_op_cond() -> mmc_send_op_cond_iter()
mmc_init() -> mmc_complete_init() -> mmc_complete_op_cond() -> mmc_send_op_cond_iter()
Returning this result means that the TF card did not want to respond to a command that eventually caused a wait timeout.
Maybe a different TF card would have turned out differently.
But there are some firmwares that are able to boot on this TF card of mine, and I think it's still an issue that can be solved by software.
@wevsty could you please try with this image and report back: https://github.com/jayanta525/openwrt-nanopi-r2s/releases/tag/v2.0r1
I've tried this firmware and it boots normally on this TF card of mine.
As I continued to search for the problem I found that as long as the DEBUG macro is defined during u-boot compilation, it will boot properly on this TF card.
The specific operations are
Modify u-boot/include/config_defaults.h add
#define DEBUG
Due to compilation errors in the compilation process:
u-boot/arch/arm/lib/reset.c:42:(.text.do_reset+0x28): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `reset_cpu'
So an empty function was added to reset.c.
__weak void reset_cpu(ulong addr)
{
}
Write to TF card after successful compilation, then it can be started normally.
I'm guessing that with the DEBUG macro turned on, due to the large number of print functions that need to be executed, the wait time for the TF card becomes longer, so the TF card can respond to CPU commands in time.
Maybe adjusting the run frequency of u-boot would solve this problem?
@mj82 @SvenH
After I added startup-delay-us the TF card has been able to boot up properly.
I created a PR to fix the problem, if anyone else is experiencing similar issues feel free to test it.
@wevsty Insted of defining startup-delay-us = <100000>; in vcc_sd.
It's more proper to define it in vcc_sdio
| + | regulator-name = "vcc_sdio"; | |
|---|---|---|
| + | regulator-settling-time-us = <5000>; | |
| + | startup-delay-us = <2000>; |
I've tested it and only adding startup-delay-us to vcc_sdio still doesn't boot up.
@wevsty have a look at the dts from the vendor friendlyarm: https://github.com/friendlyarm/kernel-rockchip/blob/nanopi-r2-v5.4.y/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2-common.dtsi
From what I've read vccio_sd seems to only be used in SDIO bus and UHS mode .
However, UHS mode is not used in the OpenWrt version of the device tree.
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ disable-wp;
+ max-frequency = <150000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_dectn &sdmmc0_bus4>;
+ vmmc-supply = <&vcc_sd>;
+ vqmmc-supply = <&vcc_sdio>;
+ status = "okay";
+};
If UHS is needed we see that perhaps it should be
&sdmmc {
bus-width = <4>;
cap-sd-highspeed;
cap-sdio-irq;
disable-wp;
keep-power-in-suspend;
max-frequency = <100000000>;
mmc-pwrseq = <&sdio_pwrseq>;
non-removable;
num-slots = <1>;
pinctrl-names = "default";
pinctrl-0 = <&sdmmc0ext_clk &sdmmc0ext_cmd &sdmmc0ext_bus4>;
rockchip,default-sample-phase = <120>;
supports-sdio;
sd-uhs-sdr104;
status = "okay";
};