I had no trouble with my first experience with NanoPi R6S while installing and running the FriendlyWrt/OpenWrt 22.03 image, but that was another story when testing Ubuntu or Debian as the mini PC would not boot at all after flashing the images with eFlasher apparently successfully, but suspiciously fast (under 2 seconds).
I spent nearly four hours trying the different images and then the Rockchip Windows utility, but all my attempts failed, and FriendlyElec was not overly helpful. So I decided to connect a serial console to see what was going on. The NanoPi R6S comes with a 3-pin header for the serial console, but it’s not populated.
So I soldering one, but not at the top of the bottom, and instead at the bottom since it would allow me to still use the metal enclosure to cool the processor.
Some readers, or at least one, often complain about the lack of external access to the serial console in routers to debug issues without having to disconnect the device and open it up. But with the NanoPi R6S, it’s fairly easy to create to add an external serial console port by soldering the header on the bottom side of the board and then making a hole in the bottom plate.
I used a power drill and a file tool, and the result is functional but not exactly neat. People with better skills than me or a CNC machine could make something neater.
I’ll also pretend I did not center the hole on purpose in order to be able to see the markings (GND, Tx, Rx).
But it does the job and we can now access the serial console without having to tear down the router, simply connect Tx, Rx, and GND to a USB to TTL debug board with jumper wires and we are good to go. I had to cut the headers by about 1 mm to prevent them from touching the desk once we are not using the serial console anymore. A plastic cover would be nice, and looking around in my office, plastic bits covering HDMI cables seem to be good candidates for this purpose, provided we make a hole of the right size.
It works within the eFlasher utility or when I boot the FrienlyWrt/OpenWrt image using 1,500,000 bps baudrate stipulated in the wiki:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
jaufranc@cnx-laptop-4:~$ bt -b 1500000 No port specified, using ttyUSB0 (last registered). Use -l to list ports. Trying port ttyUSB0... Connected to ttyUSB0 at 1500000 bps. Escape character is 'Ctrl-]'. Use escape followed by '?' for help. DDR Version V1.08 20220617 LPDDR4X, 2112MHz channel[0] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[1] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[2] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB channel[3] BW=16 Col=10 Bk=8 CS0 Row=16 CS1 Row=16 CS=2 Die BW=16 Size=2048MB Manufacturer ID:0x1 Samsung CH0 RX Vref:31.7%, TX Vref:20.8%,19.8% CH1 RX Vref:32.7%, TX Vref:18.8%,18.8% CH2 RX Vref:30.7%, TX Vref:20.8%,20.8% CH3 RX Vref:31.7%, TX Vref:20.8%,20.8% change to F1: 528MHz change to F2: 1068MHz change to F3: 1560MHz change to F0: 2112MHz out U-Boot SPL board init U-Boot SPL 2017.09-g70503fb4d6-220928 #root (Oct 13 2022 - 18:11:22) unknown raw ID 0 0 0 unrecognized JEDEC id bytes: 00, 00, 00 Trying to boot from MMC2 Trying fit image at 0x4000 sector ## Verified-boot: 0 ## Checking atf-1 0x00040000 ... sha256(806278dba1...) + OK ## Checking uboot 0x00200000 ... sha256(2972509ab3...) + OK ## Checking fdt 0x0032ca68 ... sha256(e936f08b25...) + OK ## Checking atf-2 0x000f0000 ... sha256(c00c7fd75b...) + OK ## Checking atf-3 0xff100000 ... sha256(71c3a5841b...) + OK ## Checking atf-4 0xff001000 ... sha256(2301cf73be...) + OK ## Checking optee 0x08400000 ... sha256(fde0860845...) + OK Jumping to U-Boot(0x00200000) via ARM Trusted Firmware(0x00040000) Total: 280.498 ms INFO: Preloader serial: 2 NOTICE: BL31: v2.3():v2.3-405-gb52c2eadd:derrick.huang NOTICE: BL31: Built : 11:23:47, Aug 15 2022 INFO: spec: 0x13 INFO: ext 32k is valid INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: system boots from cpu-hwid-0 INFO: idle_st=0x21fff, pd_st=0x11fff9, repair_st=0xfff70001 INFO: dfs DDR fsp_params[0].freq_mhz= 2112MHz INFO: dfs DDR fsp_params[1].freq_mhz= 528MHz INFO: dfs DDR fsp_params[2].freq_mhz= 1068MHz INFO: dfs DDR fsp_params[3].freq_mhz= 1560MHz INFO: BL31: Initialising Exception Handling Framework INFO: BL31: Initializing runtime services INFO: BL31: Initializing BL32 INFO: hdmirx_handler: dma not on, ret I/TC: I/TC: OP-TEE version: 3.13.0-652-g4542e1efd #derrick.huang (gcc version 10.2.1 20201103 (GNU Toolchain for the A-profile Architecture 10.2-2020.11 (arm-10.16))) #5 2022年 09月 20日 星期二 09:41:09 CST aarch64 |
But there’s no output at all with Ubuntu or Debian. So something must be wrong while flashing the image inside the eFlasher utility especially since it just takes one or two seconds to complete the “firmware upgrade”, I’m guessing some issues with the MicroSD card (I/O errors or too small), but that will be for another day.
I hope FriendlyElec considers providing easy access to the serial console in their future routers, as it should cost close to nothing to implement a solution as described above.
[Update: Pastrav has come up with a nicer way to add a serial port to NanoPi R6S using a 2.5mm audio connector attached to the hole reserved for an antenna. See comments for details.
]
This is it for the 10,000th post published on CNX Software!
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
I feel like I’m “at least one” of the readers who often complain about the lack of console on their boards 🙂 Indeed it’s more accessible on this one, but frankly, having a micro-USB port accessible costs nothing either and provides way more value than just exposing pins and requiring the user to find a working USB-TTL adapter.
By the way the flashing problem you faced sounds very similar to the one I faced with my Station-M2 with the crappy rockchip flashing tool. This thing has trouble selecting the proper flash and in my case it mistakenly flashed the MMC image to the SPI NOR, failed after 16 MB and bricked it. Worse, the recovery procedure refused to reflash the correct image there, thinking there was already a valid one. The support insisted that I find a windows machine to reflash everything because the linux tool doesn’t work (the windows one doesn’t work much better, but if you ignore the numerous errors, at some point you get a booting machine).
Yes that was you I was referring to :p
I think giving access to the serial header without having to open the device would already be a nice improvement. They’d need to add a USB to a serial chip and a micro USB port otherwise.
With regard to the flashing problem, I think my problem may be different, as I can still go back to OpenWrt, it’s just the Debian and Ubuntu images that are not working at all. FriendlyElec told me eFlasher Ubuntu and Debian images work on their side. Another person also tested the Debian image successfully but they boot directly from a MicroSD card, instead of flashing it to the eMMC flash.
> I think giving access to the serial header without having to open the device would already be a nice improvement.
Sure, I don’t deny this, and that’s what I had done on a dockstar and a goflex home. But each time I want to use them I need to find an unused TTL adapter. It’s still better than having to also take the screwdriver.
> They’d need to add a USB to a serial chip and a micro USB port otherwise.
The CH340E was something like $0.50 or so last time I checked. There’s definitely no excuse for not having that, even in that price range. If I have the choice between a console-less device and one with a console, with a $5 price difference, I won’t even hesitate!
> With regard to the flashing problem (…)
OK at least yours is not bricked, that’s always better.
@@@@ Awarded For Excellent Article @@@@@
Given by Theguyuk ( creep 😇 )
To Jean – Luc Aufranc ( if as a award receiver, he accepts the Award ).
Publish long and financial proper 👍🎀 🎄⛄🇬🇧
PS No I don’t have substance, alcohol issues.
Pps the value of this Award is probably rated at 1% + – 10%
I think there’s an easier and cleaner way of adding a serial port to the R6S: insert a thin 2.5 mm audio jack into the antena hole in the case.
Here’s how it looks:
One of the regulars on cnx recently suggested using audio jacks, great advice.
Here’s a block terminal to 2.5 jacck converter hooked up to an ftdi 232
These are the socket and terminal adapter parts:
https://uk.farnell.com/clever-little-box/clb-jl-8103/phone-stereo-plug-3pos-2-45mm/dp/2931090
https://uk.farnell.com/pro-signal/mj-070n/socket-2-5mm-jack-3pole/dp/1267372
I’m one of those suggesting jacks when it’s too difficult to make a large hole (though the plug can be large behind). I’ve borrowed this idea from CASIO calculators 30 years ago when I was still a student, they were also using 2.5mm jacks for file transfers.
yes, I couldn’t find the original comment thread. Kudos !
This is a nice way to get a serial port. Thx
Yes, it’s indeed better, no need to drill a hole in the enclosure.
What voltage is required for the ftdi? 3.3 or 5? TIA.
Congratulations on post 10k !
Indeed, 1250 x 8 = 10,000.
10,000 kudos for all these posts!
Can’t you you use OpenOCD using the SWD port next to the serial port? Bypassing the bootloader, maybe? JTAG debug maybe?
I think I did the UART on a 3.5mm audio jack about 10 years ago, for my DNS323: http://dns323.kood.org/hardware:serial
It certainly is a neat and convenient way of doing it. Aided by the FTDI -AJ variant of their USB-UART, of course!
This is cnx Software at its best. Group think, blue sky, solution seeking. With participants feedback and lived experience expression.
Very most illuminating 😀👍
Finally found the issue with booting Ubuntu 22.04 on NanoPi R5S. I flashed the gz image with USBImager 1.0.8. It will somehow corrupt it leading to file systems errors when boot, and most compress firmware files from FriendlyElec will not work, with one exception being the FriendlyWrt image.
The workaround for Ubuntu and Debian images is to decompress the firmware with gzip first, and then I can flash the image with USBImager.
See issue @ https://gitlab.com/bztsrc/usbimager/-/issues/109
Does this mean USBImager is not verifying by default or is the verify OK (AKA similarly flawed since the corruption happens while decompressing)?
It looks like it is a 4GB limit issue, which explains why FriendWrt is working, but larger images are not.