Willy Moto

@olivluca well, it is not totally a stupid idea, but consider that tv boxes are mostly just-for-fun kind of product; I would rather go with a properly supported SBC, or at least a community supported SBC. For example, today I test a Radxa Pi-e board (very small, one gigabit eth, one fast eth, 802.11ac/b/g/n wifi) that turned out being a very impressive throughput of > 100mbps on a 300mbps 802.11n 2.4ghz link, and the access point was one floor above! SImilar results came from an Orange Pi 4 LTS; the tv boxes I tried couldn't reach such bitrate and one of them which had the ssv6051 wifi on board was not even working right.
 
I never tried RaspAp, but looks very good if it does what it promises.
But if you want something reliable, go with an SBC + armbian, otherwise find an access point that supports openwrt.

hello again. @jocki'll be taking pics of both boards tonight and extracting the dtb's. some vendors do give clues as to what wifi chip is placed on the board. my squared h96 max v1.4 board works fine on 2.4GHz and 5GHz and works on default distro of the 5.15 kernel build including hdmi, hdmi does not work on the 5.19 kernel though. my rounded one which i will disassemble seems to have the same board but has no 8 segment lcd. it works almost the same as the squared one with the exception of the nvram that needs replacing.
edit:
i seem to have identical boards for the rounded one and the square one, both are rk3318 v1.4 dated 2020/06/29.
differences are square and rounded respectively.
wifi chip: fx8934, sp2734c
crystal beside wifi chip: none, 37.4MHz
inductor beside wifi chip: none, 4R7
fd6551 and 8 segment: yes, no
 
square pics:https://photos.app.goo.gl/U5LEJrav5FZMh6LEA
 
rounded pics:
https://photos.app.goo.gl/dUBqpmVfWpshq4PV9
 
i think @fabiobassa can chime in on the hardware part because it seems we can put in an fd6551 and an 8 segment on the rounded h96 max box easily and make openvfd work on it too. i also think we can transplant a similar but better wifi chip on it if ever we have those on hand.

Removing this made it work however I had an kernel oops on the legacy kernel and it soon after that stopped booting.
I tried reinstalling kernel by booting from tf card:
mkdir -p /tmp/emmc mount /dev/mmcblk2p1 /tmp/emmc/ mount --bind /dev/ /tmp/emmc/dev/ mount --bind /proc/ /tmp/emmc/proc/ mount --bind /sys/ /tmp/emmc/sys/ chroot /tmp/emmc/ #ping 8.8.8.8 should now work on chrooted env apt remove linux-image-legacy-rockchip64 apt-get install linux-image-current-rockchip64 it seems to have worked but I have not bothered uart to see what is going on.
5.15.68-rockchip64 is the only kernel I get hdmi with others are blank IIRC.
I was able to get home assistant supervised working perfectly(esphome, tasmota, integrated mqtt server) if I select raspberrypi as machine type. Raspberry pi 4 and tinker I tried failed.
Armbian 22.11.0-trunk Jammy is the only one with docker-ce per https://github.com/home-assistant/supervised-installer and one needs to repackage homeassistant-supervised.deb:
dpkg-deb -R homeassistant-supervised.deb content sed -i "s/os-agent/os-agent:armhf/" content/DEBIAN/control dpkg-deb --build content/ homeassistant-supervised_new.deb dpkg --install homeassistant-supervised_new.deb  

@DavidJS
you SHOULD at least know that FAT has a limitation to maximum 4gb for a single file so the problem isn't the partition but the file itself
Anyway when you insert SD for 1st time without any image inside the fat partition is resized to maximum. Then remove the SD and out the image on it
you can try to compress .GZ the image and see if it Is under 4gb and fit
 
 
 

@Krotosz6 Good you discovered it by yourself
 
current and edge are kernel flavours.
Current is the stable one, which is older but expected to always work. At the moment the current kernel is 5.15.
Edge kernels are experimental/development. They are newer (at the moment 5.19) but can break anytime because they are not guaranteed to work, since they are... experimental!
 
I don't have anything against tutorials, they are welcome, but the problem with them is that they become obsolete. In fact the apt-mark step is not necessary anymore, since support for rk3318 is now part of mainline armbian.
The best tutorial is described in the first page of this thread, plus it is always kept up to date.
Also images are now compiled and signed by armbian servers too, not anymore by myself - full instructions are again in the first post.
 

@Krotosz6 Hello, indeed you're not seeing the internal memory: as long as the two pins are shorted, the clock of the internal flash is gated to ground: basically it does not receive any clock and that's the reason it is bypassed.
You should short the two pins, turn the board on and then release the pins almost immediately.
 
So far, even if the image installation has been interrupted, multitool should be able to boot anyway unless you wrote an image for another similar soc or you interrupted it so soon it was not able to write the bootloader.
 
By the way, once armbian has booted, you should be able to see the internal flash as /dev/mmcblk2, thus blkdiscard /dev/mmcblk2 or dd if=/dev/zero of=/dev/mmcblk2 bs=1M count=32 oflag=direct should both be able to clean the existing bootloader on internal flash to let it boot again; otherwise you can use the multitool to do the same.

armbian does not boot from sdcard with Android bootloader.
It will boot from sdcard once it is installed in emmc, so you can test other armbian images from sdcard without overwriting emmc.

LIRC comes after the kernel-based handler. You should investigate ir-keytable instead, that will change the kernel-level key bindings for the remote.

Many of us are using Armbian not just on ARM single board computers but also on servers (bare metal & virtual). We use our builds since we trust it more then Debian, Ubuntu, not to mention other distributions that are recklessly updating and one ends up as an OS tester and not OS user. Personally I use Armbian Jammy on Ryzen 9 workstation with great success. My primary use case is development / productivity. For the road I used to have 13" Dell notebook which recently suddenly died. It was out of warranty so I had to get something new. After some testings of various devices I settled with 12th Gen Intel i5-1240P powered Lenovo. Then I tried many general purpose distros to see how well they work and all had some (minor) troubles ... 

We are having UEFI images (common image) since some time, but UEFI nor desktops were fine tuned nor ready for such performance daily driver desktop usage. We were close, but not close enough to just run it. Past two weeks we have been lifting general UEFI support, fixed many bugs and what came out is "Armbian ultimate developers desktop build".
 

 
- improved support in GRUB (armbian wallpaper) & HiDPI GRUB support
- all preinstalled applications are normal apt packages
- current 5.15.y kernel, Jammy userland (5.19.y has some strange issues)
- snapd is not installed (user can install it)
- HiDPI support (automated adjustments on big screen resolutions)
- NVIDIA graphics acceleration with proprietary driver (x86 only)
- Intel graphics acceleration also works out of the box
- preinstalled Google Chrome (x86 only)
- preinstalled Microsoft Visual Studio Code (x86 only)
- ZFS 2.1.5 ready (apt install zfsutils-linux zfs-dkms)
- face unlock works perfectly fine on this laptop
- installation to SSD drive to dual boot with Windows 10/11 is supported Armbian classical way by transferring actual live image to the prepared partition via nand-sata-install. All you need to do is prepare spare space on your drive, Windows 10/11 or Linux, UEFI support (most if not all hardware for past 10 years has it).
 
I have tweaked images (XFCE, Gnome, Cinnamon) a bit to my personal needs, but making changes is welcome.
 
Nice to have: disk encryption within nand-sata-install, small bug fixing, additional DEs. Currently we have CLI, XFCE, Gnome and Cinnamon. Others are too buggy.
 
https://www.armbian.com/uefi-x86/
https://www.armbian.com/uefi-arm64/
 
Please report where it works and how (well)!

Glad to hear that you solved the issue; I will put this nvram in the armbian firmware repository as well, thanks!

happy to report that the official CSC build from github works flawlessly on my rk3318 box that has ap6334. everything seems to be in order, i did have to rename box64 though to fix the slow dependency building, i also have the smartmontools problem on first boot, but not on the second boot, i have not checked succeeding reboot dmesg though since i had to rebuild my klipper environment. running it at 1.3GHz without any problems so far. uses very little resource when printing, 1-5% cpu usage and 14% ram. 2GB ram and 16G EMMC.

@Willy Moto I had time to check the apt issue about being slow... it definitely too slow when it generates the dependencies tree, so a get a bit deep into.
In my case I solved going into /etc/apt/sources.conf.d, renaming of any repository (I suggest box64.conf or nala.conf) with suffix .disabled, run apt update, then enabling back the repository and running again apt update.
Now the dependencies tree is built in a blink of an eye.

@MBB Are you working to get your patches submitted back to base Armbian?  The reason I'm asking is given your current instructions (pull armbian source, apply your zip of patches) you will run into problems over time as the armbian codebase changes, since you aren't tied to a specific git commit or label.  Also long term where do your end users turn for software support?  Armbian certainly isn't setup to provide end user support for projects like this.  Just wondering about how you envision long term support working as it relates to the armbian code you are building on top of.

For anyone wanting to build from mainline, we have posted an article with our patches.  These include AC200 Ethernet and XR819 wifi support in kernel 5.15.y.  For edge builds, AC200 Ethernet is supported.  To support the XR819, we'll have to create more patches for the changes in kernel 5.19.  The link is https://www.inovato.com/article/building-armbian.

Hi @SteeMan!  Thanks for reaching out.  We are great fans of Armbian!  This project rests on the great previous work by @balbes150 and as followed up on by @awawa.  We have simply updated those patches.  Currently, our plan was to keep updating our patches (and add other boxes such as the work being done by @jock), but if there is interest in making this a CSC build, I am more than happy to discuss how you'd like us to proceed.  It is certainly our intent to handle all support and not place any burden on Armbian folks.  Is there a good way to discuss in real time?  You can reach me here:  mike at inovato.com.  I am US West Coast.

Here all other Armbian related videos.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

And lots of review videos on my channel. So subscribe if you're interested.
Greetings, NicoD

@oolonthegreat @uehqsvbm Do not get too attached to devices that refuse to cooperate after a reasonable amount of effort. Just sell it and recover what you can and get one that people have had better success with. I recently fell into this trap with one particular openwrt supported device I have already spent months on it.
 

It appears it does not matter when you plug in HDMI cable. But for 3d printer owners out there I made a parametric cooler case(well top of it anyway)
https://www.thingiverse.com/thing:5447782
Certainly sorts out the overheating issue for the time being. Tested with cpuburn-a53
ln -s /sys/devices/virtual/thermal/thermal_zone0/temp /root/temp; cat /root/temp  

Rock 5b test images, from armbian-next. Using vendor u-boot + patches, and vendor kernel, both straight from radxa's git
 
XFCE desktop with "browsers" app group
- https://github.com/rpardini/armbian-release/releases/download/20220710b/Armbian_20220710b-rpardini_Rock-5b_jammy_legacy_5.10.66_xfce_desktop.img.xz
 
CLI
- https://github.com/rpardini/armbian-release/releases/download/20220710b/Armbian_20220710b-rpardini_Rock-5b_jammy_legacy_5.10.66.img.xz
 
PR: https://github.com/armbian/build/pull/3984 (against master)
All work by @amazingfate I just gathered stuff and built images.
Thanks to @monkaBlyat @lanefu @piter75 @amazingfate for tests / patches etc
 
 

Announce:
 
Hello, I want to announce that Community Supported Configuration (CSC) board images are now built again by Armbian servers on a weekly basis!
This means that you can now download images for CSC boards (including rk3318-box) browsing from https://github.com/armbian/community
 
Images are built from trunk, GPG-signed and SHA-sum is provided.
 
I also removed the manual instructions for upgrades: Armbian 22.08 release is imminent and from that time on it will be sufficient to use apt to get kernel upgrades too! Thanks for your patience!
 
Feel free to donate if you find this useful and wish to offer support to the Armbian developers and maintainers.
 
Enjoy!

@rzu- i did not try the images from waprme's minimyth2, but i'm using the patches for both the h6 and h616 to build my own images (not armbian) and they are working very well so far - i would say its the most complete patch collection for h616 right now
 
best wishes and good luck - hexdump

So I build a minimal image from sources with Armbian 22.08.0-trunk Bullseye with Linux 5.15.58-rockchip64 and burned it with multitool without erasing emmc this time.
Connected sigrok-pico to uart tx line and pulseview at 3mhz and 100M samples uart protocol decoder. It was a bit of a pain using a logic analyzer first time but I found a login prompt and so replaced sigrok-pico with ch340g usb uart and was able to login and create account without any issue this time. No wifi so I just stuck ethernet cable to my router and dhcp gave ip address to it. I connected hdmi and now that works as well. It seems that only 2gb of 4gb ram is detected but I can see that this kind of issues has been discussed before on this thread.

So to sum it up, it seems 5.18 kernel has no hdmi but if you stick ethernet cable to a dhcp capable router one can get the ip and ssh into it - you probably want to use 5.15 kernel for the time being though. Perhaps something along the lines of git-bisect to get to the bottom of the hdmi issue. I do find it a bit strange that hdmi did not seem to work immediately after flashing. Perhaps one needs to replug the hdmi cable after it has booted.
 
Feel like a winner already, thanks to everyone working on this!
 

I finally managed to solve the problem, my box can connect to wifi with that new 2734C chip.  Thanks to @jock for directing my attention to the nvram file, I was wrong, dtb was not needed to solve it. However, Google didn't help with the solution (I don't even understand how it could have helped), but I contacted the Chinese manufacturer of the box and they helped. I have attached the correct nvram file, the content of which I overwrote the brcm/brcmfmac4334-sdio.rockchip,rk3318-box.txt file that comes with the current image. I recommend that you integrate it into the kernel, because the current kernel does not, or at least does not, support this widely used wireless chip.
nvram_2734c.txt

@MX10.AC2N Didn't you try already 5.18? I remember you already had issues with 5.18, but that was my fault because I downvolted the CPU by mistake; upgrade debs should be fixed now and there should be no issues anymore, as long as also other people found them working stable so far.
 
About the Jammy edge image, it is an experimental image with KDE Plasma preinstalled. It works, but there is a kernel bug in lima that often causes kernel panics, so it is not "public" not suggested to put in any kind of use.
The bug seems to be fixed in 5.19, so I guess soon there will be a proper publishing.