mdel

Members
  • Content Count

    175
  • Joined

  • Last visited

About mdel

  • Rank
    Elite member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

873 profile views
  1. 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..
  2. 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
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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..
  9. 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.
  10. 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.
  11. 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
  12. 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..
  13. 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..
  14. you can extract your rockchip box dtb with rockchip tools : https://www.cnx-software.com/2014/05/12/how-to-extract-a-device-tree-file-from-android-firmware-files/#comment-251518 Not sure if the binary dtb from android will work with those linux kernels, and how to inject them into your linux boot, amlogic boot scripts made that so easy..
  15. another Fast Ethernet (100M) box. I haven't figured out if that sdmmc0 fuck up on the z28 pro is global to all Gbe versions of rk3328 boards, probably not.. I'll have more time to play with my z28 pro over the weekend, test linux and so on.. those log entries got me a little worried (ayufan rock64 git) :