Hi all,
I am experiencing strange behavior on my nanopi r2s with latest available version 161. If when I start the board I do not keep the usb-serial adapter connected to the PC, the system does not finish booting. When I reconnect the usb-serial adapter to the PC I find the system in u-boot. If I give the command boot the device continues booting and then everything works normally .
If I start the board with usb-serial adapter connected to the PC, no issue is observed.
Any idea how to solve ?
Regards
Carlo
I had this also with some usb serial adapters. If the adapters are are not powered the board gets it own output back and stops to boot. You have to disconnect the adapter from the board to boot without a pc. (At least the rx line)
This morning I downloaded the GA version of 161 for aarch64. Installed from scratch with initial setup done via usb-ttl. Then unplugged every cable from r2s board except lan network cable and power supply and rebooted. I waited for 5 minutes but the sys led remained red (not blinking). No response on the lan interface.
Then I tried to remove the sdcard and edit the uEnv.txt file and set “SERIAL-CONSOLE = OFF” and reinserted the sdcard on the board. Turned on and waited another 5 minutes but nothing happened. The sys led remained red (not blinking).
What am I doing wrong ?
Regards
Carlo
I can reproduce it. Looks like an hardware fault. The rx line collect the data that tx has transmittet and break uboot even if nothing is connected to the debug port.
You can work around this by connecting a 10KOhm restistor on the RX line to gnd.
2 Likes
First of all thanks for your answer.
Today I tried latest images of Armbian and Openwrt 21. for r2s to see if the problem also occurred on these two distributions, but it seems that on these two systems the hardware problem has been somehow overcome, allowing to use the board without connecting any resistance to the debug port and therefore to start correctly without serial connection.
Is this something that could also be implemented on ipfire? Maybe by editing the uEnv.txt file to modify uboot default behaviour?
Thanks in advance.
Carlo
u-boot hangs before uEnv.txt is loaded. Maybee there is a way to patch u-boot or a better version of the trusted-arm-firmware but without more infos i cannot do anything.
Also it is possible that the problem only occour with the reduced baudrate that IPFire uses.
Does the Raspberry Pi CM4 Compute Modul work as well?
Just curious if core 161 or core 162 does anything different for the NanoPi R4S?
Is the uboot still the issue?
As part of a project, I was looking for a reasonable CM4, sort of hard to find. Seeed Studios is selling a CM4 on a dual gigabit ethernet carrier board. I got one for the CM4, but decided to test if I could put ipfire on it. Sure enough it works! It runs very hot, so active cooling is required. Without a fan it runs at about 80 C, with a fan it drops down to about 30 to 35 C. I even got the WiFi working on the CM4, but not very well. While the CM4 has 2.4 GHz, 5.0 GHz IEEE 802.11 b/g/n/ac wireless, I could only get it to work in 802.11an, if I remember correctly. I did not explore it very hard on ways to get it to work better.
It is my understanding that DFRobot also offers a dual ethernet carrier board, that is supposed to run much cooler and consume less power. Another possibility is to use the official CM4 carrier board and put a second ethernet card onto the board. I have not tried this yet, but if I do I will report in and let folks know how it goes.
The DFRobot might be a better choice:
DFRobot’s board attaches the second Gigabit NIC directly to the bus, instead of through a USB 3.0 controller, like Seeed Studios did.
https://www.jeffgeerling.com/blog/2021/two-tiny-dual-gigabit-raspberry-pi-cm4-routers
Jon, I agree that the DFRobot carrier board would be the way to go for the CM4. But one would need to check and see if the ethernet controller on the board is supported.
After posting, I decided to test and see if I could get the CM4 to work with the Raspberry Pi IO carrier board. So I popped the CM4 off the Seeed Studios carrier board and put it on the Pi IO board, and combined it with an Intel I210 2x1 pcie ethernet card. It works. All I had to do was rerun “setup” to reconfigure the red interface and it worked.
One slight disadvantage with this setup. By default, the USB2 interface is disable by default on the CM4 (in order to save power). I have not figured a way to turn them on yet. There is video (HDMI) output, so you can watch the boot process, but no keyboard. If I remember correctly this kind of messes up the installer script. One needs to set up the interfaces in the installer script and with no keyboard I do not see how to do that. Otherwise, if one is willing to live with ssh as the only way to the command line then it works. I believe the same issue exists with the DFRobot carrier board as well as there are no USB ports. This might give the seeed studios board a slight advantage, as the USB ports work out of the box. It is all up to the user to choose what they are comfortable with.
By the way, I should have said the these tests have been run on Core Update 161.
I have added the CM4 dts with core162 but not tested because i have no CM4 based system.
The state for the R4S is unchanged because u-boot is unchanged.
1 Like
Which baudrate is used by Ipfire?
What is the issue with R4S uboot?
115200 wiki.ipfire.org - FriendlyElec NanoPi R2S
An error about the dram configuration if i try to compile the arm trusted firmware which is needed to compile u-boot
Sounds like cross compiling issue.
It compiles fine natively.
Might end up with garbage coz upstream uboot and linux kernel have 1.5m as per rockchip recommendation.
really would like to see ARM and RISCV hardware be a firewall 
until then:
x86 is “the way to go”
this (not yet released) jumped into my eye today:
massive amount of x86 (true) dual LAN boards
Hi,
I was trying to change uboot serial to 1.5m with setenv to test the suggested solutions but it seems it’s not possible to save the changes.
Is it possible to change the default baudrate to 1.5m for nanopi board in the upcoming 163 release to avoid soldering resistors ?
Regards
Carlo
I have not cross compiled. I have compiled it native on a RPi4.
Which parameters have you used to configure it.
I’m against this because many USB TTL adapter not support this non standard baudrate.
All Rockchip boards use 1.5M
All amlogic boards use 115200
All allwinner uses115200
Not with IPFire. The rate can set u-boot config before compile and i have set it to 115200 becaus my USB adapters give only garbage at 1.5M
I asked for the config of the trusted firmware.
for r2s i use
cd $(DIR_APP)/arm-trusted-firmware-2.5 && make PLAT=rk3328 ARCH=aarch64 DEBUG=0 bl31
but if i set the PLAT to rk3399 for the r4s i got a configuration error for the dram.