Taz

It is not worth the effort to fiddle with a 256MB micro sd card, just get a at least 32 GB micro sd card and get on with it. I have 256 GB tf card and I am glad I chose this big and not smaller. Even if you managed to get 256MB /boot partition to boot and system from 32GB usb driver combo to work, you are asking for a massive headache if you ever run out. Generally speaking, the minimum I would go for is 64GB tf card with SDXC label(or UHS-1 I think) on it like Kingston Canvas Select Plus. Unless you live in something like North Korea, you should be able to get one for less than 10 euro.

That would be swell if everyone would follow the rules, but in reality some apps try to evade Pi-hole by providing their own DNS addresses.

I use Q96 Max to run Pi-hole, Home Assistant in supervised mode, WireGuard, NFS, qBittorrent and Apache. I have openwrt box setup so that it redirects all outgoing DNS to my Pi-hole instance, and since I have wireguard on my phone, I get zero advertisement even on google apps.

Well, the issue with r8152 and probably some other devices like 1000Mbps ethernet adapters and maybe SSDs is that these things have only limited amount of RAM for buffering. If the CPU just isn't fast enough to clear those buffers you are going to get buffer overruns.

X88 Pro 10 at least one I had is such a source of misery I swapped the SD card to H96 Max and now everything is much better. I will be flashing the android image back to it as soon as I get a fly mouse and use it to play angry birds or something on my projector instead. My advice, do not buy X88 Pro 10 instead stick with H96 Max only. At least on H96 Max reboot works so you can set up watchdog to reboot it unlike on X88 Pro 10 which has unreliable reboot. On my H96 Max there is no built-in wifi is not detected so I stuck a wifi adapter on it. I do not have much appetite to try to fix it. As soon as I plugged in r8152 to H96 Max it went completely bazooka with: [Thu Sep 28 01:17:41 2023] xhci-hcd xhci-hcd.0.auto: WARN: HC couldn't access mem fast enough for slot 1 ep 6 [Thu Sep 28 01:17:41 2023] r8152 3-1:1.0 enx00e04c6824a3: intr status -63 is causing something to occur in Home Assistant virtualization within seconds of any traffic taking down all wifi, eth within 10 seconds. So I spoke too soon, r8152 is not usable on these boxes at least not when plugged into usb 3 maybe there is a way to make it work as usb 2.0 but I was unsuccessful. For comparison r8152 chipset works fine with my Orange pi PC which has usb 2.0 and seems super fast as well. I found one seller on aliexp who sells RTL8156 2500Mbps Ethernet adapter: https://www.aliexpress.com/item/1005003432672849.html I think they both use same driver but hey I figure it is worth a shot.

Okay, it seems 6.5.x series kernels are not crashing but instead freezing with: [Thu Sep 28 09:59:54 2023] NOHZ tick-stop error: local softirq work is pending, handler #08!!! in dmest -T. To deal with this problem I went to armbian-config -> System -> Bootenv and added: extraargs='nohz=off' . I have a feeling this is an inherit problem with these slower arm based boards so I do not think this is not going to get fixed anytime soon. I also found: [Thu Sep 28 01:17:41 2023] xhci-hcd xhci-hcd.0.auto: WARN: HC couldn't access mem fast enough for slot 1 ep 6 [Thu Sep 28 01:17:41 2023] r8152 3-1:1.0 enx00e04c6824a3: intr status -63 But as far as I can tell this is not fatal anymore and one should be able to use RTL8153 Gigabit Ethernet Adapters without any major issues.

6.5.3-edge-rockchip64 kernel is crashing here as well. Have not found my uast usb adapter that works with this board yet and it is super annoying when my home assistant and therefore lights depend on this so will probably downgrade kernel to get out of this situation.

I did full "apt-get update && apt-get upgrade" and landed with 6.1.53-current-rockchip64 kernel. I have had two hard crashes of the system in two days with this kernel, edited /etc/default/armbian-ramlog to disable ram /var/log to see if I can track it. Also noticed that the 50MB /var/log is not big enough and it was full. I have also tested 256 GB SDXC1 (Kingston canvas select plus) on the armbian rk3318 and if there was any doubt of being able to access the whole card, it is working fine. EDIT: found nothing useful in logs. EDIT2: testing 6.5.3-edge-rockchip64 kernel now

I can confirm success with RTL8153 1000Mbps usb 3.0 ethernet adapter like https://www.aliexpress.com/item/1005003293799477.html . I had to copy firmware file from my main pc. I initially got very poor 2MB/s big file transfer rates but after replacing cable, https://askubuntu.com/questions/1345256/cant-get-rtl8153-gigabit-ethernet-adapter-usb-3-0-working-on-ubuntu-20-04 and forgetting about it for a couple of weeks I tested again. Somehow even though I have different IP addresses for the links, they seem to still get little mixed by the linux kernel and openwrt router so I am going to disable the wifi altogether. I measured around 20 MB/s big file(from TF card) transfer speed over NFS while MT7601U clocks at 3.3 MB/s. AP6330 is some 20% faster than MT7601U. Now we are cooking with fire!

@olivluca There is also Orangepi 5. If I were to become trapped in island with only one SOC this is probably the one I would pick since RK3588S cpu on these should be somewhere around 2-4 times faster than RK3318(and everything that is available). Especially 8GB and 16GB models are suitable for a lot of tasks such as browsing, emulation even running multiple applications at once. Supposedly there is a debian image for Orangepi 5 with video and opengles acceleration but do not take my word for it. https://github.com/morrownr/USB-WiFi/blob/main/home/USB_WiFi_Adapters_that_are_supported_with_Linux_in-kernel_drivers.md suggests mt7612u of the cheap category can do access point mode at 5Ghz. I think these rk3318 boxes are great for running klipper, web server, pihole, wireguard, home assistant and network share. I used to have home assistant and samba running on openwrt but because it resets settings once you upgrade openwrt I eventually got tired of it all and moved everything out to the RK3318. Also pihole and probably bunch of rpi style services does not work on openwrt. I am not sure I would bother pursuing the matter of usb tethering. If you can get wifi to act as an access point just add another usb wifi adapter to connect to you phone. Either way with charging phone or having another usb wifi you are pushing the power supply to its limits maybe beyond.

Two days of uptime on X88 pro using original power supply and the AP6330 wifi crashed again flooding dmesg with "err=-110". https://lkml.iu.edu/hypermail/linux/kernel/2105.3/05569.html goes into some detail about -110. "rmmod cfg80211 brcmfmac && modprobe brcmfmac" caused firmware loading error. So is this limited to X88 pro or all AP6330 I do not know. However since this a hard to reproduce bug there probably isn't much that can be done to actually fix it. I've been using MT7601U usb wifi module that landed on my hands for 5 days without issues. I measured about 600mA current draw on these devices under load so the power supply should be fine I guess. Using MT7601U it takes about 100mA more than with AP6330. I haven't bothered to measure but MT7601U feels about as fast AP6330.

@xlordxcheater You can try to debug such issues by connecting eth after the wifi has stopped working and checking if there is anything interesting in dmesg output. I found a bunch of errors suggesting the wifi chip had crashed. I am testing again with the original power supply but I think I get another Comfast CF-812AC(RTL8812BU) usb wifi adapter or 1000Mbps usb ethernet adapter. You should consider getting a more proper raspberry pi power supply with 3A or 4A rating if you want connect things to the usb ports. The original on these is only 2A and pictures show input capacitor is like 100uF which is kind of ridiculously small. You could solder 2200uF 16V capacitor to the input. I originally had SSD on it that was consuming some mere 200mA current but it caused the whole tv-box to become unstable so I had to tear it down. I have also had issues with the eth link going down and not recovering after a week of uptime.

I just let you know if I ever manage to fix it. I kind of think these bugs reports should go to kernel has bugzilla or somewhere not here but that is just my opinion.

@jock Oh I totally missed the part of ddrbin being proprietary. armbian forum search functions do not work anymore so I could not search the old posts anymore. Hmm, that kind of sucks actually. So in the event that the ddrbin versions are different then would have to find version that works on all. I would much rather rockchip deal with this. Yes, I meant that I cannot test the original firmware on X88 pro until I back it up to another rk3318. Too bad about the LibreELEC patches. I could see myself wanting 6.0 kernel at some point when the time comes. Perhaps it would be possible to filter out which of the patches fixes hdmi. Oh yeah, if someone is considering running like web services on these kinds of boxes I would suggest using ethernet instead of 5ghz wifi. 5ghz wifi on Linux at least in my experience is nowhere near as stable as eth.

@jock I'll check the original firmware once I get H96 MAX 4gb. Do not wanna risk downtime on PiVPN(which works fine BTW once you figure out the fw kinks) and HA. I did pay premium for the 4gb and there is a little "4GB" sticker inside so I am leaning towards ddrbin having some issue. Does this ddrbin have sources, named author somewhere ?

DDR version 1.16 20190713 ID:0xFFF In SRX DDR3 666MHz Bus Width=32 Col=11 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=2048MB ddrconfig:2 OUT I am not very good at reading these. I think I'll grab another box soon. These go as low as 25e for 2gb model from aliexp eu warehouses.

One picture is more than 1000 words. 4 more chips on the other side.

Oh yes, it seems X88 pro RAM amount is detected wrong. I have https://pdf1.alldatasheet.com/datasheet-pdf/view/347892/SAMSUNG/K4B4G0446C.html 8 chips so 4000000000 * 8 / 8 / 1024 / 1024 / 1024 = 3.7253 GB. Have not really needed the extra memory for anything yet. Any ideas on what to do about it?

I have two acer ips displays that are about 8 years old(and still going strong!) with dvi-d only input so I have been using hdmi to dvi-d adapter and DP to dvi-d it always gets the resolution right on nvidia and intel graphics drivers. However orangepi pc does not work with these displays nor does rk3318. I get "(II) modeset(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e)" which is not correct modeline for this monitor. To me this just tells that the desktop gpu drivers have better compatibility and maturity than these SOCs like rk3318. Also the 1080p projector by vankyo has slightly questionable HDMI receiver on it so it is not exactly surprising that there are issues with it. It shows up as "MStar Demo" in EDID. Best just to use LE patches and leave it at that.

I also get picture reliably at boot up hdmi with testing Kernel 5.19.15 image. Seems I have messed something up on the buster because Xorg does not start: https://pastebin.com/p8cRSF5L But does the debian bullseye image still have U-Boot SPL 2022.04-armbian (Aug 23 2022 - 17:04:26 +0300) with that rather apparent "voltage select" bug? I get: [ 108.358432] ff000000.i2s-i2s-hifi: soc_pcm_open() failed (-22) [ 108.361402] hdmi-audio-codec hdmi-audio-codec.3.auto: Only one simultaneous stream supported! [ 108.362178] hdmi-audio-codec hdmi-audio-codec.3.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -22 On the Home assistant image

I found this on the uart line trying to boot from the old buster image I still have on emmc: DDR version 1.16 20190713 ID:0xFFF In DDR3 666MHz Bus Width=32 Col=11 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=2048MB ddrconfig:2 OUT U-Boot SPL 2022.04-armbian (Aug 23 2022 - 17:04:26 +0300) Trying to boot from MMC1 Card did not respond to voltage select! : -110 spl: mmc init failed with error: -95 Trying to boot from MMC2 mmc_load_image_raw_sector: mmc block read error SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### I found some cheap faster(than 32GB) 64GB SDXC(kingston canvas select plus) cards so I have been less reliant on the emmc Successful boot does two rounds of "Card did not respond to voltage select! : -110" IIRC and boots just fine. So this is a random failing event at boot to be exact.

@FRIKIdelTO IIRC wifi channel names are transmitted using lower frequency and more reliable tech that the actual data. Perhaps switching to other channel on your access point or changing bandwidth makes it work. Also without encryption is worth a try.

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

Okay, so I wanted to give a whirl to buster and legacy kernel as to get video acceleration going. Very rough set of commands to mutate minimal command line buster image to a working desktop. I did get armbian-buster-desktop-cinnamon to display lightdm but cinnamon was crashing as it tried to start. Apparently I kind of messed up something since then and now I just get "(EE) Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices" in Xorg.0.log. ``` apt update apt-cache search desktop # few broken dependencies apt install dconf-cli libglib2.0-bin # the desktop install - this should download about 500MB of packages *when* working correctly # in case of failure "apt-get remove" or "apt-get --install-recommends remove" or "apt autoremove" and try again apt-get --install-recommends install armbian-buster-desktop-cinnamon apt-get --install-recommends install armbian-buster-desktop-xfce # duplicate files. looks pretty bad actually apt-get -o Dpkg::Options::="--force-overwrite" install armbian-bsp-cli-renegade # acceleration apt install media-buster-legacy-rk3328 --install-recommends #swap to a legacy kernel by uninstalling current one and installing deb packages built from source # P.S. booting linux without a installed kernel package can prove to be a quite a challenge so be careful with this one - boot from tf and chroot apt remove linux-image-current-rockchip64 dpkg --install armbian-firmware-full_22.08.0-trunk_all.deb dpkg --install linux-image-legacy-rockchip64_22.08.0-trunk_arm64.deb dpkg --install linux-dtb-legacy-rockchip64_22.08.0-trunk_arm64.deb ``` hdmi not working on later than 5.15.62 kernels is likely caused by kernel folks doing some reworking of drm code related to vblanks. That would explain why console sometimes works because it does not need vblanks but xorg does so crashes or hangs. https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg153211.html for instance has some perhaps relevant information. Unfortunately blinking led is not a reliable indication of whether the system is booting or not because it is not until running rk3318-config that led becomes active.