mdel

okay ubuntu direct upgrade is not recommended so i will not try it. I'll upgrade to a new kernel with your new image. Unfortunately my box has a s905 (the oldest one), yes the box is called a95x but does not have s905x which came later. i have seen your s9xxx thread and could not understand if it is compatible with s905 as well or not. I assume the images for s9xxx and aml+rk+aw are compatible with the old s905 too, please let me know if it's correct. thank you.

hello, i have an old nexbox a95x (s905, usb2, 100M eth) with an image from the "balbes150 (ver 5.44 =<)" thead. it still has the original ubuntu xenial 16.04 with kernel 3.14.29 and i would like to upgrade to a more recent ubuntu branch. Can i use the regular ubuntu "dist upgrade" process to do so, or will the armbian image break this process ? more info : I don't think i really need to upgrade the kernel, the system is installed on the emmc, it's a headless system so no need for wifi, sound or video. if it's been discussed in details somewhere else please send me a link where i can read about it. thx for your help, sorry if it's not directly related to this thread and thx for all the work done for those cheap tv boxes.

hard to say really, it's probably never graceful to force disable existing hardware, unless you can activate it manually through commands. i would assume BT to be "not so important" for headless servers, now since the debug serial console requires some hardware hacking (opening the box & soldering), you can't really argue that it should be the preferred hardware port.. in my opinion, the best solution would be to have it enabled by default with the option to disable it after boot (permanently or not). if the enable_dtoverlay script can be used in armbian then it could be included and a simple command script added to rc.local or somewhere to enable / disable hardware devices. i haven't checked if armbian-config has command a line mode, it probably has, then i could be enough for what we want to do. but as i was wondering above, it would also be nice to know if there's a preferred "cleaner/safer" way to disable hardware, through dt overlays after boot, or through software commands (rfkill and so on) or if it doesn't matter..

i though BT was managed by another uart port, the SDIO bus should only concern the wifi sdio 4bit interface of the module, i'll test that once i have a working BT image. thx for the additional info

yes i've heard about the rock64 gbe problem, don't know if it was finally solved (pcb tracks timings), but i don't know about a global rk3328 GMAC interface problem. So far i can't fault my z28pro Gbe, it has been running a torrent through vpn with continuous upload of 30-50Mbps and i haven't noticed any problem, nor any dubious log output.. i've done a short 6 min iperf test : i also transfered approx 750GB of real data to an attached USB drive and about 80MB/s and it didn't fail. If it's not a physical hardware issue, and yes the ethernet pcb design on that device is quite insane ( massive gap under the transformer, although strictly following the datasheet recommendation), i must say that all my traffic is going through quality shielded cat6 cables with proper earth. well the z28pro 2G/16G (Gbe, Wifi AC+BT) being often available at or below 40e, i don't think you'll find a Usb3/Gbe device at a lower price. I'll leave the dev boards aside although i don't think they are much cheaper and you should at least add the cost of a case and power adapter.

thx i don't know why i didn't find it.. the script tests if the kernel supports dt overlay and apparently my armbian kernel does : if [[ ! -d /sys/kernel/config/device-tree/overlays ]]; then echo "Your kernel does not support CONFIG_OF_OVERLAY." exit 1 fi i'll read the rpi documentation on the subject and test that. i'm wondering if it's a proper way to completely disable a hardware device or not, for example i'd like to get rid of the wifi/bt module on my headless z28pro.

nice, i'll see if i can test that. from your github thread, what kind of Gbe Lan problems are you referring to ? i'm testing a recent armbian image as stated above and haven't noticed anything wrong with the gbe lan link, neither on speed or stability.

well thx for the update on that one, i can remove it from my list, i'm quite amazed that so few rk3328 boxes actually include Gbe.. Anyways, could you elaborate on that "enable_dtoverlay" script you are using, i do see a dtoverlay tool implemented on rpi images but can't find where it was imported through a script, thx. i installed armbian (4.4.138) on my z28 pro and would very much like to use that to try and troubleshoot the missing bluetooth device.

a quick feedback on my test of a recent armbian image on my z28 pro device (2GB/16GB/Gbe) : Armbian_5.51_Z28pro_Debian_stretch_default_4.4.138 (headless) - boot shows nothing on hdmi until login prompt. - usb 2.0 and the usb 3.0 ports are working fine - wlan is working fine out of the box, dmesg shows a rtl8822bs wireless device and we get wlan0 and wlan1 i was able to connect both to my 2.4GHz and 5GHz networks on either of the wlans using armbian-config. iperf3 tests gave me around 55Mbps on 2.4GHz and around 65Mbps on 5Ghz. - Gbe works perfectly, iperf3 shows around 930Mbps bidirectionally. - usb 3.0 throughput gives around 230-350 MB/s read/write speeds (dd / sequential) with uas SSD external drive - bluetooth is not working as printed on dmesg : - armbianmonitor doesn't seem to read the temperature correctly and shows 70-75C idle which is quite far from the 40-45C measured with an ir thermometer on the chip heatsink. Maybe that flimsy taped/glued on heatsink is playing tricks, i'll try to remove it and put something larger with proper paste. i can't really comment on stability as the device has been up for only a week and mostly idle, i will do some real world tests (vpn / torrent / usb 3 storage) this week. i'm using a basic (crappy) tv box 5v/2A power adapter and the usb 3.0 SSD is a quite power hungry one, so the 5v power rail seems to be okay on that pcb. I'll have to do some cpu stress tests to check that but the faulty temperature reported scared me off at first.

it's not really an answer to your problem but i'll mention that for headless server oriented devices with good performance for the price, i have moved to rockchip and specifically rk3328 devices (same as rock64 board) which (should) have good Gbe and usb3. The rk3328 is not more powerful than a s905 (i don't care about hw decoder and 3D stuff) but it has a crypto extension module that works fine and will almost saturate a Gbe openvpn link, i bought a 2g/16g + bt/802ac (not working in linux yet) for around 35e, it's the alfawise z28 pro, here's a thread about it https://forum.armbian.com/topic/4708-z28-rk3328-18/ Read the thread carefully it has some serious caveats (can't boot from sdcard which it could, but no on that particular board) so it may not be a device for everyone and we are currently waiting for other box reviews to see if another one has less "linux install" problems.. i've been using a linux mainline kernel (17.04 server) on it for a month and i don't think i'll need a device more fully featured that this one for quite some time..

some of those boxes have completely crippled Gbe out of the box, i have two of them, one s912 and another one i can't remember the soc model of. for my s912, Gbe already behaved poorly in android, i would suggest you test your gbe speed with iperf in android to make sure it's actually working properly. In my case it is rx/tx timings defined in the dts file, they should match the physical track properties of the board, and so testing different dtb i did see changing performances of the ethernet port, but it never got anywhere near >850Mbps stable bidirectional speeds. also 4.14 kernel images are using a mainline (?) kernel and i don't know how stable it is with amlogic at the moment so you should double check that as well or stick to old BSP 3.14 kernels.

yes i forgot about my beelink x2, good that you mention it, with allwinner having good (?) mainline support, it could be a better alternative but as this is an amlogic thread, i'll leave it there. i don't know about those MXQ boxes, i don't have any s905x/w at the moment but as they are cheap ones i don't mind getting one if it's my only option.. From what i read on forums, librelec has spdif support on amlogic s905, so i imagine it should work on my tv boxes with armbian as well. I will test libreelec and latest armbian and if it does work i'll have to dig through audio patches and ask @balbes150 if he can add them to his armbian image.

sorry i don't have any usb dacs (i have some cheap 2$ usb soundcards.. if it can help) but i'm currently looking into spdif or analog audio output on my amlogic tv boxes (s905 s912 s805). Can you tell me if there's support for those outputs in your armbian images (or in armbian in general), for which soc (if not for all) ? At the moment i'm looking at my A95X (s905) box with your armbian image and it shows : No sign of analog, and since that box does not have spdif (there's a "stereo" jack A/V, composite+stereo ?), i imagine spdif and i2S are only internal peripherals. I'd be more interested in SPDIF than analog, many boxes have optical outputs, at the moment my alternative would be external hdmi>spdif converter, not very nice. I'll try to do my own tests but it would be nice if you could tell me what you already know. thx

ok, i was more asking if it's a complicated process to get armbian to build a kernel source against a different dts file. i don't know armbian internals but found that some scripts like rk3328-default/packaging-4.x-with-postinstall-scripts.patch or other DT patche files, do a lot of manipulation of dtb "stuff".. i known there's a detailed armbian documentation and will take a look at it. alternatively if it's easier, maybe simply try to reuse the android dtb, but i don't know much about rockchip, it was simple enough with amlogic and boot scripts..

thx @Igor for testing armbian's image. I see that it's using ayufan's kernel source, from what i know his rock64 images have working ethernet on z28 pro, something different in the kernel config or dts ? Also if i wanted to build armbian rock64 against my z28 pro dts, full disassembled dts not dtsi includes (available in this thread), how would i go about that ? I also have spotted that box, haven't found any tests so far. If i'm correct you should be able to use SDMMC0 (boot sd card slot) along with the GMAC interface, Alfawise decided for some reason not to use it, that's why you can't boot from sdcard on their box..