Search the Community

@voapilro, @bjorn, @electricworry I'm attempting to fix (at least a hack) the 1.5GB problem by attempting to build a custom u-boot to attempt to resolve the issue. The thing is the codes are pretty complex. https://docs.u-boot.org/en/latest/ https://source.denx.de/u-boot but that actually I succeeded in building u-boot The trouble is I'm getting this: U-Boot SPL 2024.04-00757-gbeac958153-dirty (Apr 18 2024 - 23:22:28 +0800) DRAM: 0 MiB Trying to boot from MMC1 NOTICE: BL31: v2.10.0(release):v2.10.0-729-gc8be7c08c NOTICE: BL31: Built : 23:11:18, Apr 18 2024 NOTICE: BL31: Detected Allwinner H616 SoC (1823) NOTICE: BL31: Found U-Boot DTB at 0x4a0be348, model: OrangePi Zero3 ERROR: RSB: set run-time address: 0x10003 ion U-Boot 2024.04-00757-gbeac958153-dirty (Apr 18 2024 - 23:22:28 +0800) Allwinner Technology size=30, ptr=590, limit=2000: 26370 CPU: Allwinner H616 (SUN50I) Model: OrangePi Zero3 DRAM: 0 Bytes So I literally need help with the codes, I'm doing pretty tedious debug etc with a 1.5G OPi Z3 board I bought for this purpose. if you run the 'original' images, that has a 'working' u-boot, it reads DRAM 2GB https://www.armbian.com/orange-pi-zero-3/ still 'incorrect' but that accordingly there'd be fixes for it (in u-boot) https://forum.openwrt.org/t/can-someone-make-a-build-for-orange-pi-zero-3/168930/42 https://gist.github.com/iuncuim The trouble as i try to trace where the calls are going is that it is not even going into the dram initialization codes in u-boot meant for H616/H618 to initialize and size up the lpddr4 dram. the codes are complex and I'd hope to get some leads there to attempt a solution. if a 'custom u-boot' can fix that, it'd at least help those who still only have 1.5GB boards to get Armbian running on it. By *replacing* the u-boot (practically the boot loader (and BIOS)) in the image or sd card. The image (and on the SD card) looks like this 0-7 KB (unused/reserved) 8 KB - 1 MB u-boot 1 MB - the rest of your sd card (this is your linux partition and Armbian proper (Debian or Ubuntu) lives here) u-boot does the bulk of the 'black magic' dealing with memory initialization and sizing, and then passing that across to linux during boot up. and linux uses the device tree (DTB, DTS) to configure the various devices uart, usb, sd card, leds, etc etc and subsequently present various of them in /dev. a 'custom u-boot' apparently seem to be a most feasible 'solution' (hack) to at least get past the 1.5GB problem. it is quite easy to simply take the original image, and substitute one u-boot made to say the memory is 1.5GB.

@darcyg First let me say that I am no expert on this. I have not tried to compile it lately, but I see that that commit does not longer exist on kwiboo's github. So I don't now if you need to revert to an older version of u-boot. And if you have an EmmC og SPI with u-boot, then it should work to boot from SC card with the new uboot anyway. My log was with debug enabled (and from uart), and I dont have that log anymore. mtty_probe+0x1e8/0x2b0 [sprdbt_tty] So I am not sure the error is the same wireless / bluetooth related error that I got . But I think it is. Make sure that the patch uw5622-fix-adjust-for-rockchip-post-6.1.patch got applied. Take a look in the /output/logs, If you have build the kernel several times it could be using a cached kernel and not included in the log!?, (look in the largest log files). And verify that uw5622-fix-adjust-for-rockchip-post-6.1.patch was included in your compilation: --> (15) INFO: Adding [ Drivers for Unisoc uwe5622 found on some Allwinner and Rockchip boards ] --> (15) INFO: * applying patch/misc/wireless-uwe5622/uwe5622-allwinner.patch --> (15) INFO: * applying patch/misc/wireless-uwe5622/uwe5622-allwinner-bugfix.patch --> (15) INFO: * applying patch/misc/wireless-uwe5622/uwe5622-warnings.patch --> (15) INFO: * applying patch/misc/wireless-uwe5622/uwe5622-park-link-v6.1-post.patch --> (15) INFO: * applying patch/misc/wireless-uwe5622/uwe5622-v6.1.patch --> (15) INFO: * patch/misc/wireless-uwe5622/uwe5622-adjust-for-rockchip-post-6.1.patch --> (15) INFO: * applying patch/misc/wireless-uwe5622/wireless-uwe5622-Fix-compilation-with-6.7-kernel.patch --> (15) INFO: * applying patch/misc/wireless-uwe5622/wireless-uwe5622-reduce-system-load.patch --> (15) INFO: * applying patch/misc/wireless-uwe5622/w-wireless-fix-out-of-tree-build.patch --> (15) INFO: Preparing driver [ driver_rtl8723cs ]

Hello all. I can say that now I'm almost happy owner of the Orange Pi Zero 3 board. It took me weeks of googling to get to this awsome thread. Links from official OPi site lead to outdated images where many things didin't work as expected and with broken graphics acceleration. Finally I found armbian and its latest builds for Orange Pi Zero 3 board with working graphics at least. So, first of all, thanks to all people who contributed to this builds, it's an awsome work. I'm total noob in Linux, so I can't do much help here, however, if something needs testing with this board (OPi Zero 3, 2Gb RAM) I'll try to help. Inspite of being able to make my own toy OS for x86 platform I struggle with Linux as it is seems very complex to me so I came here for help or at least right direction. My current goal with Zero 3 board is to get very minimal Linux build which includes: - all CPU cores workig and ability to run single graphics application without desktop environment at all - working 3D acceleration for smooth graphics - working sound (either built in or through i2s interface, preferably) - working GPIO/SPI/UART for communicating with other peripherials built with 8-bit MCUs like ATmel 8-bit chips Currently I'm just learning how to build such kind of Linux images. I've already tried buildroot and "default" build didn't work for me, I guess it is not configured to use HDMI output for terminal by default and I couldn't find how to do that. I also found sunxi site and as I understood armbian is based on that. I tried to follow their instructions to build uboot and kernel however stuck with some steps and errors, and it's also not very clear if they managed to set up HDMI/Mail graphics working with their builds as some instructions labeled as outdated. I also tried Bookworm image and it works pretty well, I even set up xorg there and run glgears app for testing it, but it still pretty big to me and there are several issues with running graphical apps without desktop environment. So, any help on these two topics is very appreciated: - How to get really minimum build and where to find actual informaton about that kind of builds as there are many tutorials but they seems to be outdated/incomplete or do not cover board specifics. - How to get single graphics app running fullscreen without desktop environment (for this experiment I can start with Bookworm build) Thank you.

@Hqnicolas Nice Job! Sorry I was away for the weekend and I already see that I need to reflash the board. Well I needed to start again with the version 1.2 - I started with Bluetooth and made it work - Although still not sure what is physically written on the chip and how it behaves. I have hcy6335, which in turn should be AP6335 containing the BCM4335 and for Bluetooth BCM4339. Somehow the chip gets represented as hci0: BCM4335A0 (002.001.006) build 0000. I am attaching the hcd file to this post that needs to be copied to the /lib/firmware/brcm. I also changed the dtb for the uart1 as there is no UART1 DMA mode possible otherwise. One just needs to add the dma-names to serial@fe650000 node: serial@fe650000 { compatible = "rockchip,rk3568-uart\0snps,dw-apb-uart"; reg = <0x00 0xfe650000 0x00 0x100>; interrupts = <0x00 0x75 0x04>; clocks = <0x0e 0x11f 0x0e 0x11c>; clock-names = "baudclk\0apb_pclk"; dmas = <0x24 0x02 0x24 0x03>; dma-names = "tx\0rx"; pinctrl-0 = <0x91 0x92 0x93>; pinctrl-names = "default"; reg-io-width = <0x04>; reg-shift = <0x02>; status = "okay"; phandle = <0x10a>; bluetooth { compatible = "brcm,bcm43438-bt"; clocks = <0x94 0x01>; clock-names = "lpo"; device-wakeup-gpios = <0x95 0x11 0x00>; host-wakeup-gpios = <0x95 0x10 0x00>; shutdown-gpios = <0x95 0x0f 0x00>; max-speed = <0x16e360>; pinctrl-names = "default"; pinctrl-0 = <0x96 0x97 0x98>; vbat-supply = <0x23>; vddio-supply = <0x63>; }; }; These are now the dmesg logs that I am getting [ 16.268929] Bluetooth: hci0: BCM: chip id 82 [ 16.269548] Bluetooth: hci0: BCM: features 0x2f [ 16.272162] Bluetooth: hci0: BCM4335A0 [ 16.272173] Bluetooth: hci0: BCM4335A0 (002.001.006) build 0000 [ 16.274413] Bluetooth: hci0: BCM4335A0 'brcm/BCM4335A0.hcd' Patch [ 17.114840] systemd[1]: Finished Armbian memory supported logging. [ 17.152605] systemd[1]: Starting Journal Service... [ 17.299179] systemd[1]: Started Journal Service. [ 17.339995] systemd-journald[632]: Received client request to flush runtime journal. [ 17.369055] Bluetooth: hci0: BCM: features 0x2f [ 17.372008] Bluetooth: hci0: BCM4335B0 JF-LTE MurataXJ AFH_LimitPwr_EDR 2STOPBIT-0343 [ 17.372025] Bluetooth: hci0: BCM4335A0 (002.001.006) build 0353 [ 17.482709] RPC: Registered named UNIX socket transport module. [ 17.482729] RPC: Registered udp transport module. [ 17.482733] RPC: Registered tcp transport module. [ 17.482736] RPC: Registered tcp-with-tls transport module. [ 17.482740] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 18.604874] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 18.604896] Bluetooth: BNEP filters: protocol multicast [ 18.604914] Bluetooth: BNEP socket layer initialized [ 18.647499] Bluetooth: MGMT ver 1.22 ... [ 23.677339] Bluetooth: RFCOMM TTY layer initialized [ 23.677399] Bluetooth: RFCOMM socket layer initialized [ 23.677430] Bluetooth: RFCOMM ver 1.11 h96-tvbox-3566-wifi:~:% hciconfig -a hci0: Type: Primary Bus: UART BD Address: 43:35:B0:07:1F:AC ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING RX bytes:4846 acl:0 sco:0 events:556 errors:0 TX bytes:71684 acl:0 sco:0 commands:556 errors:0 Features: 0xbf 0xfe 0xcf 0xff 0xdf 0xff 0x7b 0x87 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH SNIFF Link mode: PERIPHERAL ACCEPT Name: 'h96-tvbox-3566-wifi' Class: 0x6c0000 Service Classes: Rendering, Capturing, Audio, Telephony Device Class: Miscellaneous, HCI Version: 4.0 (0x6) Revision: 0x161 LMP Version: 4.0 (0x6) Subversion: 0x4106 Manufacturer: Broadcom Corporation (15) h96-tvbox-3566-wifi:~:% bluetoothctl Agent registered [CHG] Controller 43:35:B0:07:1F:AC Pairable: yes [bluetooth]# show Controller 43:35:B0:07:1F:AC (public) Name: h96-tvbox-3566-wifi Alias: h96-tvbox-3566-wifi Class: 0x006c0000 Powered: yes Discoverable: no DiscoverableTimeout: 0x000000b4 Pairable: yes UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb) UUID: Handsfree Audio Gateway (0000111f-0000-1000-8000-00805f9b34fb) UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb) UUID: Headset (00001108-0000-1000-8000-00805f9b34fb) UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb) UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb) UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb) Modalias: usb:v1D6Bp0246d0540 Discovering: no Roles: central Roles: peripheral Advertising Features: ActiveInstances: 0x00 (0) SupportedInstances: 0x05 (5) SupportedIncludes: tx-power SupportedIncludes: appearance SupportedIncludes: local-name [bluetooth]# scan on Discovery started [CHG] Controller 43:35:B0:07:1F:AC Discovering: yes [NEW] Device 4C:BA:D7:02:F5:B7 4C-BA-D7-02-F5-B7 @ning @Hqnicolas UART1 speed is set to max-speed = <1500000>; but according to the datasheet (still no clue if it is the right one) we can go up to 4 MBit/s. Another thing is the schematics that I found somewhere on the internet, but still they are using some AP6xxx wifi/BT chip. Need to dive into this, but hey, now we see the missing components needed for SD-Card slot. Heartbeat is a nice thing, but I will try to enable the backlight blue LEDs, WiFi runniung, and then try to get some HDMI audio out of this thing. BCM4335A0.hcd p562297-AP6335 datasheet_V1.3_02102014.pdf ROC-3566-PC-V10-20210419.pdf

The cable is fine. Also tried a different one. I tested it with UART connected to my notebook. The system is available after I have disconnected the network cable. But I can see that some tasks running in docker container after a few seconds cause 100% CPU usage. And the load of the system is growing again and again. I guess that this will kind of „lock“ the device after a few minutes, this tasks are running as root. Thank you for the support and hint with the UART, now I can go on to figure out what the problem is with those tasks…

Hi @Hqnicolas I am currently still doing some research as I found out that Bluetooth does not work and it has to do something with the UART1 line. I will first try to fetch the low-hanging fruits. Meanwhile, I replaced the debian with ubuntu image for now and I extracted all of the firmware drivers from my backup dump from the super.img file. I am attaching them to this post and they are coming from the vendor/firmware part. I currently do not know if they need to be statically or dynamically linked with the kernel. If they help in any way, we can include them in the armbian Linux. Link I have a few questions for you as well. Do we have some sort of PCBA schematics and the HW setup with the external hardware: direct pins connections, what goes via muxes, etc.? This would speed things up. I requested this from the buyer, but the chances are really low that he will send anything back. What is the latest dts version? Do we have it in the form of mnemonics and not as bare pointers in byte values (&gpio instead of some 0x8e value)? Now to the Bluetooth problem I found somewhere in this forum that someone fixed the Bluetooth by changing the TX and RX pins in the dts. Link to git commit Looking at what is currently in (I am using some rk3566-firefly-roc-pc.dts - there are multiple of them and changes are phandles for USB 2.0) and what is in the git and the version originally coming from this device show that there is a TX and RX swap in the file (maybe due to different PCB layouts and hoping that there is one bit that allows UART alternate function RX/TX swap - not sure as the datasheet for RK3566 is far from being useful). So the file should be at least changed to: bluetooth { compatible = "brcm,bcm43438-bt"; clocks = <0x8d 0x01>; clock-names = "lpo"; device-wake-gpios = <0x8e 0x10 0x00>; host-wake-gpios = <0x8e 0x11 0x00>; shutdown-gpios = <0x8e 0x0f 0x00>; pinctrl-names = "default"; pinctrl-0 = <0x8f 0x90 0x91>; vbat-supply = <0x24>; vddio-supply = <0x92>; status = "disabled"; }; In the original dump file there is also UART8 messing around, but I am currently not sure what her role is. @Hqnicolas If you have everything setup on you side, can you quickly check this out? Or I will try to fiddle around with armbian-config and device tree entries and let's see where it gets me.

@Werner Are your CP2102 fake? I Have the Chinese Fake CP2102 and it works at 1.5M baud rate This gui's are fake ^^^^^^^^^ and this CP2102 works at 1.5M baud rate but the PL2303HX dont work with anithing is an absolute wast of metal Prolific PL2303 have fake versions to The Serial UART to USB looks like the TV-Box Market

Yes, that appears to be correct. I couldn't figure out why the UART on the p26 pin header wasn't working. Found your post and tried ttyS1 instead. Working beautifully now. Thanks 🙂.

Please, Use a debug Tool TTL UART Baud rate: 1500000 Data bit: 8 Stop bit: 1 Parity check: none Flow control: none ☑️ CP2104 TTL Tested the original one! ☑️ CP2102 TTL Tested the chinese fake one!

As it seems interesting, I also purchased a new device RK3566 from Aliexpress. I started at the beginning by wanting to backup what is currently on a device (just in case I fuck something up later on). After reading a few threads I embarked on a journey to dump the eMCC contents. I started with the RKDev Tool and RkDumper with various drivers in Windows 11. I did not get very far, so I gave up for now and switched to Kali. I cloned the redeveloptool git repo, tried to compile it, but it failed out of the box. There is a warning treated as an error so you need to correct the code with static pointer casting and then it compiles. Lets try to get some info from the flash: ┌──(xxx㉿yyy)-[~] └─$ sudo rkdeveloptool ld DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=102 Loader ┌──(xxx㉿yyy)-[~] └─$ sudo rkdeveloptool rfi Flash Info: Manufacturer: SAMSUNG, value=00 Flash Size: 59640 MB Flash Size: 122142720 Sectors Block Size: 512 KB Page Size: 2 KB ECC Bits: 0 Access Time: 40 Flash CS: Flash<0> ┌──(xxx㉿yyy)-[~] └─$ sudo rkdeveloptool ppt **********Partition Info(GPT)********** NO LBA Name 00 00002000 security 01 00004000 uboot 02 00006000 trust 03 00008000 misc 04 0000A000 dtbo 05 0000C000 vbmeta 06 0000C800 boot 07 00020800 recovery 08 00056800 backup 09 00110800 cache 10 001D0800 metadata 11 001D8800 baseparameter 12 001D9000 logo 13 001E1000 super 14 007F5000 userdata ┌──(xxx㉿yyy)-[~] └─$ sudo rkdeveloptool rci Chip Info: 38 36 35 33 0 0 0 0 0 0 0 0 0 0 0 0 ┌──(xxx㉿yyy)-[~] └─$ sudo rkdeveloptool rcb Capability:15 07 00 00 00 00 00 00 Direct LBA: enabled First 4m Access: enabled Read Com Log: enabled Read Secure Mode: enabled New IDB: enabled So we have a nice partition info with an address table. Nice. I started to read the eMMC from the first 0 sector till the end sector 122142720. It took a while and to my surprise, the .xz file was only 12ish MB large, which was nearly impossible. So I started to analyze the hex dump and to my surprise, after a while, there were only 0xCC values read from the module. After some digging around I found out that there is a protection in uBoot (I would really like to meet this guy or some stupid project lead that has come up with this idea, which is not secure nor meaningful) that prevents reading anything larger in size than 0x10000. As luck would have it uboot was completely dumped from sector 0x4000 onwards so by extracting it from the whole dump I stored the uboot.img. I found a Python script lying around somewhere that needed to be changed to my needs (offsets and length), which dumped uboot.bin. By loading it into ghidra one could search for this function and edit the branch call. I packed everything back into uboot.img and flashed it to the sector 0x4000 and dumped again. This time the .xz was something more than 2.2 GB, which is in a range of images on China Gadgat reviews page. Just to be sure I also retried with the RkDumper as the author suggested that his tool works till driver version 4.5 (if I remember correctly) and I knew that the last time I was able to fiddle around with changing driver *.inf files was in Win7, I searched for an already available VirtualBox image and I found a torrent. With some magic, I was able to edit and add the VID and PID device IDs to the driver and install it. After some trial and error, it persuaded VB to mount the RK Loader in win7. RkDumper did its job, but way slooooower as in Linux. Anyway, I have to separate and complete dumps of the whole eMMC. In the meantime I was also curious about the serial port connector on the board so I soldered the connector. I saw an Image @Hqnicolaswhere he soldered cables for the TTL UART converted and posted UART settings. I used the same principle, but how I was wrong the ground is on this board the middle pin, which I must say that in 20 years in the embedded world have not seen. I needed to prove this with a multimeter. From the UART log I got new information U-Boot 2017.09-dirty #s02 (Jul 27 2023 - 21:33:25 +0800)<CR><LF> <CR><LF> Model: Rockchip RK3568 Evaluation Board<CR><LF> PreSerial: 2, raw, 0xfe660000<CR><LF> DRAM: 7.7 GiB<CR><LF> Sysmem: init<CR><LF> Why the use of RK3568??? I have 8 GB of DDR4 RAM running with the frequency of 1056 MHz and also that dtb files are loaded from the kernel partition. Also, the I2C frequency of the bulk converter seems to be the right one for tcs4525 (also to format is correct, but the numbers are so small that I can't read them)., what was mentioned by @Hqnicolas in the 4G thread. So the next move was to dump/extract them all. There is also one Python script somewhere in git repo that dumps them - not so perfectly though. In Linux, I converted them into dts and I am sharing them in this post. @Hqnicolas For the card reader did you only solder the socket or you also added other components (I don't have the BOM list) as it appears that a lot of condensators were not placed on the board? So the next steps are going to be analysis of the log files and probing out the armbian linux installation. androidBoot_asc.txt dts_files.7z dtb_dump.7z

thanks for the reply @SteeMan . I don't have the connector for uart, but I should be able to post a video clip (hopefully with OK quality) later today. I will get a USB UART connector over the weekend. When you turn on the power for one of these sorts of boards, is it normal for the led to just stay red for 5+ seconds ? From what I can see, it's actually only spending a few seconds in u-boot before it starts showing the systemd services (the messages like "[ OK ] ...") I'm starting to wonder if it's my power supply..

Do you have the boot log from the uart port? If so please post, if not I'd suggest you capture the boot console messages to see which step of the boot process is taking the time.

ok, many thanks so far. Will take some time to get the serial console output, the n2's UART port is not usable with normal jumper cables... so will need to get the official uart kit, I fear. But until then, one last question: as the to bookworm upgraded system was fine until the last updates from the armbian repository, would it be ok to use bookworm with the old kernel 5.10.60?

Hi Nick, thanks for adding the patches. I updated from git, recompiled the image and wrote it to SD. All is as expected. Here is my bluetooth output from dmesg: I thick communication with the BT module is not coming up on your board because otherwise there should be a message line BCM: chip id xx. My suspicion would be that some of the BT control signals are connected to different GPIO or UART on your hardware. I have used the gpio utilities to identify the ports (without bluetooth being in the device tree).

This board have SD CARD READER!!!!!!! Use the SD card to test DTB files!!!! just drop in replace DTB and boot again Use TTL UART to debug e go Keep pushing bro

Hi afiftyp, Thanks for the patches. I added them to my build. Unfortunately, bluetooth doesn't work for me. [ 7.691181] Bluetooth: Core ver 2.22 [ 7.691282] NET: Registered PF_BLUETOOTH protocol family [ 7.691287] Bluetooth: HCI device and connection manager initialized [ 7.691306] Bluetooth: HCI socket layer initialized [ 7.691315] Bluetooth: L2CAP socket layer initialized [ 7.691331] Bluetooth: SCO socket layer initialized . . . [ 7.873425] Bluetooth: HCI UART driver ver 2.3 [ 7.873455] Bluetooth: HCI UART protocol H4 registered [ 7.873460] Bluetooth: HCI UART protocol BCSP registered [ 7.873560] Bluetooth: HCI UART protocol LL registered [ 7.873565] Bluetooth: HCI UART protocol ATH3K registered [ 7.873603] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 7.873789] Bluetooth: HCI UART protocol Intel registered [ 7.873882] Bluetooth: HCI UART protocol Broadcom registered [ 7.873914] Bluetooth: HCI UART protocol QCA registered [ 7.873919] Bluetooth: HCI UART protocol AG6XX registered [ 7.873949] Bluetooth: HCI UART protocol Marvell registered . . . [ 10.147991] Bluetooth: hci1: command 0x0c03 tx timeout [ 10.148042] Bluetooth: hci1: BCM: Reset failed (-110)

First off, (and you likely know this already), Armbian doesn't support userspace upgrades to newer distributions. (But they usually work in my experience). Second, you are running on a board that Armbian doesn't support. It is a community supported board, which means that no Armbian resources are put in this board, it is soley maintained (or not maintained) by volunteers in the community. On to your issue. You are going to need to capture the boot log to see where it is failing to boot. You need to hook up a usb uart connector to your board to capture the boot output. I would also suggest trying to fresh install on your board to make sure that your target release actually works on your board at all (don't want to spend a lot of time debugging an upgrade issue, if it isn't an upgrade issue, and is just an issue in the current release).

Hello Armbian Team, i have the wish for the integration of - GPIO Support for RockPi 5b to the Edge Kerne - dtb's which are aviable for Kernel 5.10.160 mostly importend for me are the UARTS ( if tryed to compile the DTS files form 5.10.160 for the 6.8.2 .. ends after sending some to the UART with a Kernel segfault 😞 ) Thanks a lot for the good Work 🙂 René

@astrosky as I already told you, there are no spare buses to tinker with on tvboxes. The second uart (ttyS0 usually) you found perhaps is in use for communications with the bluetooth chip which happens via plain serial data. If your board has no bluetooth, then you may use it for your business, otherwise you will get garbage there too. Still an SBC is far better for these tasks, you easily get three or four UARTs on the pin headers you know what purposes are for.

If you want to dig deeper into this, you will need to find the uart pins on the board, hookup USB uart connector and capture the boot messages to see what is actually happening when booting. Since I don't have this board nor know of anyone that has tried running Armbian on that board.

@jock I knew something was off.....that's why I was seeing Random characters output when I echo ..thanks for telling me that and it also explains why I get permission denied sometimes. ...guess I still need to make it where it's a virgin uart with no influence on debug too! I thought it was just a console control. Yeah this took extra steps but it frees up a USB port on the box itself for keyboard and mouse with out using a hub and it sorta copies a pi now and I had all this laying around anyways so. Update:1 Ok successfully fixed the issue, disabled all access to that uart part temporarily. Was able to successfully communicate to the Arduino through nanpy. No more permission issues. This is super cool. Now the Arduino works like an extension to the TV box. The processing power of the TV box is way better than the Arduinos so this opens up a bit of a cool niche use case. I'll call it THE ARMBIAN PI.. Still dont have wifi though. I ran the config and such but wifi isn't being able to run. Not sure what's stopping that but I'm sure it's not too hard to fix. Update:2 Finally I do see one more serial port that I have yet to figure out what exactly it's for. But this gives me another idea to attach one more Arduino or to connect directly to a 3d printer. It shows up as a device in the serial list tree. Got any idea what it is? Would it might be the IR port?

it actually did not require recompiling the bootloader at all actually heres what i did and it works! I worked on connecting a TV box running Armbian with an Arduino using a UART connection, allowing them to communicate. The aim was to control the Arduino using commands sent from the TV box. Firstly, I programmed the Arduino to react to simple text commands that would turn an LED on or off. This step was crucial to test whether commands from the TV box were being correctly received by the Arduino. Next, I focused on setting up the TV box for UART communication. Through the terminal, I found the UART device (/dev/ttyS2) and temporarily disabled its console service using the command sudo systemctl start serial-getty@ttyS2.service or sudo systemctl stop serial-getty@ttyS2.service This was necessary to use the port for sending commands to the Arduino without interference from the TV box’s system. To ensure the setup worked, I connected the TV box to a Windows computer using a USB-to-Serial adapter ( using my Arduino uno for this shorting the reset and GND together to by pass the chips mcu ) and monitored the communication with PuTTY. By sending a test message from the TV box and seeing it in PuTTY, I confirmed the UART port was functioning correctly. This allowed for successful data transmission between the two devices. A key part of this was a external port i made. i went in and solder on pin cables and routed it as neat as i could permanently so i can access the UART easily . This setup made it easy to connect and disconnect the Arduino without opening the TV box each time. It effectively allowed the Arduino to act like a USB-to-Serial device and vice versa, simplifying the communication process. I adjusted permissions to access the UART port without needing administrative rights and ensured the baud rates on both devices matched. this has thus far enabled general commutations through the UART and when i want to log back in through uart if ever i can simply start the serial -getty and log in this then allows me to run NANpy, making the arduino act like a slave to the tv box much like how people take rasberry pis and do the same thing to expand the gpio ports through serial communication using nanpy on the pi! this basically turns our silly ole tv box with the rk3318 into a raspberry pi with out the features lacking! that was the one thing about the pi that made it better for most tasks. well this helps level that disadvantage! @jock

@tj13 don't worry, it's no pain. Bug reports are always appreciated, but without logs or whatever it is very uneasy to guess if the problem is related with the broken installation script or whatever. Surely you can follow the posts of this thread to get a clue; if you installed the system in eMMC perhaps you can try the Multitool from this page and see if it works (I never tried it on TInkerboard), so at least you have a way to backup and access the filesystem. At last, the uart adapter suggested by @SteeMan can give some important hints about what went bad.

Thank you, looking more calmly, I found the headers marked as G, R, T. Would these be: ground, tx, rx? I think I'm confusing it with my second TVbox which has a slightly different PCB, if this is the UART interface, I'll solder headers and connect my USB adapter, at what baud rate should I listen? It worked, it was these pads, here is the output with booting from the SD card: DDR Version V1.10 20190926 In ID:0xFFF 660MHz DDR3 Bus Width=16 Col=11 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB mach:2 OUT U-Boot SPL 2021.04-armbian (May 06 2021 - 19:15:25 +0000) Trying to boot from MMC2 I/TC: I/TC: Non-secure external DT found I/TC: Switching console to device: /serial@11030000 I/TC: OP-TEE version: 3.10.0-40-ga1d5c81f (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10))) #6 Wed Sep 16 21:36:15 UTC 2020 arm I/TC: Primary CPU initializing M/TC: Not protecting region 1: 0x68400000-0x68600000 I/TC: Primary CPU switching to normal world boot U-Boot 2021.04-armbian (May 06 2021 - 19:15:25 +0000) Model: Generic Rockchip rk322x TV Box board DRAM: 992 MiB MMC: dwmmc@30000000: 1, dwmmc@30020000: 0 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** In: serial@11030000 Out: serial@11030000 Err: serial@11030000 Model: Generic Rockchip rk322x TV Box board Net: eth0: ethernet@30200000 starting USB... Bus usb@30040000: USB DWC2 Bus usb@30080000: USB EHCI 1.00 Bus usb@300c0000: USB EHCI 1.00 Bus usb@30100000: USB EHCI 1.00 scanning bus usb@30040000 for devices... 1 USB Device(s) found scanning bus usb@30080000 for devices... 1 USB Device(s) found scanning bus usb@300c0000 for devices... 1 USB Device(s) found scanning bus usb@30100000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found U-Boot script /boot/boot.scr 2909 bytes read in 5 ms (567.4 KiB/s) ## Executing script at 60000000 Boot script loaded from mmc 1 238 bytes read in 5 ms (45.9 KiB/s) 6094752 bytes read in 282 ms (20.6 MiB/s) 8771448 bytes read in 475 ms (17.6 MiB/s) 50042 bytes read in 10 ms (4.8 MiB/s) 786 bytes read in 7 ms (109.4 KiB/s) Applying kernel provided DT overlay rk322x-emmc.dtbo 1286 bytes read in 7 ms (178.7 KiB/s) Applying kernel provided DT overlay rk322x-led-conf1.dtbo 232 bytes read in 7 ms (32.2 KiB/s) Applying kernel provided DT fixup script (rk322x-fixup.scr) ## Executing script at 600f0000 ## Loading init Ramdisk from Legacy Image at 64000000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 6094688 Bytes = 5.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 61f00000 Booting using the fdt blob at 0x61f00000 EHCI failed to shut down host controller. EHCI failed to shut down host controller. Using Device Tree in place at 61f00000, end 61f74fff Starting kernel ... I/TC: Secondary CPU 1 initializing I/TC: Secondary CPU 1 switching to normal world boot I/TC: Secondary CPU 2 initializing I/TC: Secondary CPU 2 switching to normal world boot I/TC: Secondary CPU 3 initializing I/TC: Secondary CPU 3 switching to normal world boot Armbian 24.2.1 bookworm ttyS2 rk322x-box login: this is the emmc boot output running the same image from the sd card written on it: ⸮⸮DDR Version V1.10 20190926 In ID:0xFFF 660MHz DDR3 Bus Width=16 Col=11 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB mach:2 OUT U-Boot SPL 2021.04-armbian (May 06 2021 - 19:15:25 +0000) Trying to boot from MMC2 I/TC: I/TC: Non-secure external DT found I/TC: Switching console to device: /serial@11030000 I/TC: OP-TEE version: 3.10.0-40-ga1d5c81f (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10))) #6 Wed Sep 16 21:36:15 UTC 2020 arm I/TC: Primary CPU initializing M/TC: Not protecting region 1: 0x68400000-0x68600000 I/TC: Primary CPU switching to normal world boot U-Boot 2021.04-armbian (May 06 2021 - 19:15:25 +0000) Model: Generic Rockchip rk322x TV Box board DRAM: 992 MiB MMC: dwmmc@30000000: 1, dwmmc@30020000: 0 Loading Environment from EXT4... ** File not found /boot/boot.env ** ** Unable to read "/boot/boot.env" from mmc0:1 ** In: serial@11030000 Out: serial@11030000 Err: serial@11030000 Model: Generic Rockchip rk322x TV Box board Net: eth0: ethernet@30200000 starting USB... Bus usb@30040000: USB DWC2 Bus usb@30080000: USB EHCI 1.00 Bus usb@300c0000: USB EHCI 1.00 Bus usb@30100000: USB EHCI 1.00 scanning bus usb@30040000 for devices... 1 USB Device(s) found scanning bus usb@30080000 for devices... 1 USB Device(s) found scanning bus usb@300c0000 for devices... 1 USB Device(s) found scanning bus usb@30100000 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Card did not respond to voltage select! : -110 Device 0: unknown device switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC 7[r[999;999H[6n8Card did not respond to voltage select! : -110 Scanning disk dwmmc@30000000.blk... Disk dwmmc@30000000.blk not ready Scanning disk dwmmc@30020000.blk... Found 2 disks No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 missing environment variable: pxeuuid missing environment variable: bootfile Retrieving file: pxelinux.cfg/01-8e-44-db-3b-e1-5d ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 missing environment variable: bootfile Retrieving file: pxelinux.cfg/00000000 ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 missing environment variable: bootfile Retrieving file: pxelinux.cfg/0000000 ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 missing environment variable: bootfile Retrieving file: pxelinux.cfg/000000 ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 missing environment variable: bootfile Retrieving file: pxelinux.cfg/00000 ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 missing environment variable: bootfile Retrieving file: pxelinux.cfg/0000 ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 missing environment variable: bootfile Retrieving file: pxelinux.cfg/000 ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 missing environment variable: bootfile Retrieving file: pxelinux.cfg/00 ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 missing environment variable: bootfile Retrieving file: pxelinux.cfg/0 ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 missing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm-rk322x-rk322x-box ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 missing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm-rk322x ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 missing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 missing environment variable: bootfile Retrieving file: pxelinux.cfg/default ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 Config file not found ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 ethernet@30200000 Waiting for PHY auto negotiation to complete......... TIMEOUT ! Could not initialize PHY ethernet@30200000 =>

@Caio Lima Viana If you post pictures of the front and back of your board, someone on here may be able to identify the uart connection points