Jump to content

mdel

Members
  • Posts

    177
  • Joined

  • Last visited

Everything posted by mdel

  1. 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.
  2. 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.
  3. 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..
  4. 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
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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..
  11. 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.
  12. 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.
  13. 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
  14. 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..
  15. 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..
  16. 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..
  17. 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) :
  18. well i've studied the dts and datasheet a bit, quite interesting things to learn in there and much closer to my microcotroler knowledge than i thought it would be, hardware is hardware i guess.. i'll start by saying that if of course that dtb (from the "resource" emmc block) is not the one actually used at boot, the comments below will not be very or at all useful. i will also mention that the hardware reference pdf shows 3 ETH+Wifi+BT configuration examples, none use sdmmc0, only a mix of sdmmc1 / sdmmc0ext (not the same pins and address as sdmmc0) / usb, and that the only sdcard example uses sdmmc0. then from the z28 pro dts file you get the following sdmmc bus defined : quick recap of the datasheet address mappings : FF50_0000 SDMMC (probably both for SDMMC0 & SDMMC1 ?) FF51_0000 SDIO FF52_0000 EMMC FF5F_0000 SDMMC_EXT (datasheet only mentions SDMMC0_EXT, i still don't understand what's with the EXT, alternate SDMMC0 pins ?) pinctrl-0 = <0xc5 0xc6 0xc7 0xc8>; ( sdmmc0-clk / sdmmc0-cmd / sdmmc0-bus4 / sdmmc0m1-pwren?? ) pinctrl-1 = <0xc9>; ( sdmmc0-gpio) those phandles point to the following pins in the dts : this is slightly different from the rock64 dts which is as follows : sdmmc0_dectn (card present pin) is not included in the phandles and is "replaced" by sdmmc0m1-pwren. the very weird thing is that for sdmmc0m1-pwren : rockchip,pins = <0x0 0x1e 0x3 0xe8>; seems completely bogus as there are no GPIO0_1E (or any 1E pin in the datasheets). then again i don't quite understand how the hex value of pins is set in that dts, so 1E may be a shift from the datasheet value.. you can also see in the dts that sdmmc0ext is "status = okay" (enabled) and has all the correct phandles, so is the "sdmmc0_ext" used instead of sdmmc0 ? Seeing that UHS_SDR104 is only defined for sdmmc0 i would assume it's the real sd card slot bus.. also that "broken-cd" (no card detection) is set for sdmmc0ext seems weird for a sd slot.. The thing i have not yet figured out is how to identify which external device (sdcard slot, wifi) is actually connected to that hardware bus configuration.. i would assume you can't or only guess by the bus configuration. I'll stop for now by mentioning that ayufan's rock64 dts is slightly different form the current mainline rock64 dts but i may be wrong it's getting confusing.
  19. i'm still looking at my original z28 pro before testing linux images i have extracted the dtb from the resource partition (didn't know it was there with rockchip) and converted it to dts. It's not easy to read as "aliases or defines" are not there anymore and everything is in hex. but it should be intesresting to compare it to rock64 dts to see hardware configuration variations. One thing i'm still not sure about is if that dtb (from the "resource" block) is actually used by the box at boot or if there's another dtb somewhere.. here's the boot serial output : rk-kernel.dts.zip
  20. i have only followed (and found) the open datasheet provided by rockchip, [not a very detailed datasheet (no mention of registers and addresses) : false statement see edit below ], but until i get a better explanation my point is still that sdmmc1 share pins with gmac and as far as i understand it should be one or the other (or the datasheet is wrong). You also get some pretty detailed rockchip soc boot sequence on the wiki, including alternative boot sources like spi or u-disk but this is off topics. I didn't read it thoroughly but i don't think there was any mention of sdmmc0 or 1 only "emmc/sd card" as a boot source. then i was investigating the maskrom and/or rockusb "loader" boot (achieved with bootloader reboot from recovery menu), and i discovered that you can trigger the recovery menu by slamming CTRL+C when the device powers on. It's a bit weird, the device boots to android and then reboots right away to recovery menu.. Still useful to get to recovery. And CTRL+C was apparently a way to interrupt uboot even if bootdelay has been configured to 0 (seconds), but it doesn't seem to work or i couldn't trigger it. I was also not able to extract the dtb file from the boot block yet, it seems to be very different from the ones from my amlogic devices or maybe it's just an android 7 thing, no idea. -- edit -- all datasheets/TRM/Layout are present on the main summary wiki page but only one of them is present on the 3328 page so check out the main page first for all the documents..
  21. "logging in" after you flashed a linux image on the emmc, right ? i'm still investigating the stock android features at the moment so i haven't flashed anything yet. i don't quite understand how sdmmc1 (not bootable sd port, according to the datasheet) would be used on this device, when those pins are shared with the gmac bus which is activated on the z28 pro with gigabit. Also seeing that the same routing exists on the rock64 schematics (gmac pins + rtl8111) and sdmmc1 is not routed on the board. there are also some sdmmc0_ext pins i don't quite understand the purpose in the datasheet. I will extract the android dts and compare it to the rock64 one or to a z28 (not pro) one if i can find any, but i still don't know how dts really works and if you specify which sd port is enabled, or only that "there's a sd card port on the device".. Anyways i can't interrupt uboot and even if i could there's always a chance you can't input anything, as seen on other devices. I was hoping for a extremely favorable uboot with pxe boot =)
  22. nice soldering, did you manage to interrupt uboot by pressing a key. i've been trying for 10 minutes but no luck so far. by chance my HL-340 chip can handle 1500000 bauds and i see the not very verbose boot output in minicom (not in sreen) and the line : "Hit any key to stop autoboot: 0" (0 as in disabled ?) but so far all i can get is some smoke coming off of my keyboard by hitting the keys so fast =)
  23. hello @r1kaomsk i received a z28 pro a few weeks ago and didn't really bother to read about it, so i discovered that very bad news here. i did try to read the 4pda thread (and your tutorial) before ordering but well google translate doesn't like russian.. A "couple" of things i'd like to know : how did you figure the sd module was routed to sdmmc1 on this device ? Looking at the rk3328 datasheet it seems SDMMC1 is shared with GMAC (z28 pro uses gmac+rlt8111e phy), so what's happening then ? Can those multi purpose pinouts be changed at runtime on arm socs ?? (i'm only used to basic microcontrollers) Now seeing you directly flashed linux on the emmc, i'd like to know what methods of recovery you have in case you system doesn't boot. I've seen about maskrom mode and androidtool, i have not tested yet, is it restricted to flashing android to the emmc ? can you point me to the current working z28 pro linux image (your 0.4?), i understand that latest ayufan images will not boot from emmc anymore ? if you have a z28 pro running your linux image can you tell me if usb3 is stable, and if you have aes128-ce in /proc/crypto ? Sorry for all those questions. I'm currently trying to access uboot console to see what's available there, and then i'll try the maskrom stuff. thx !
  24. mdel

    ROCK64

    @tkaiser thx for the very thorough test, and 2/4GB comparison, at least that is clear. i'm a bit surprised by the lower performances of arm64 builds, do you have any idea what's going on there ? armhf figures are almost identical to my Amlogic s905 devices (around 56k for aes-128 which is always the fastest for some reason). It's interesting to see that it has about the same performance at 1296MHz as the s905 at 1.75GHz (?, well the fake 2GHz..) I was looking at the recently published rockchip documentations (3288 and 3328), and i'm quite surprise to find almost nothing concerning the HW Crypto block, something like only one register address.. I'm assuming those "amrv8 cryptography extensions" are the same on all a53 socs but was never included in a linux kernel which sounds odd to me, but i don't know anything about it so.. I'm still not sure if it has to be declared in the Device Tree to be accessible by the kernel, if that's the case then i believe i've never seen it in those cheap socs DTs and is totally ignored by everyone. I vaguely recall seeing it mentioned on a timeline from a baylibre presentation about amlogic mainlining. So far the only soc i saw that had crypto hw support (displayed on cpuinfo "Features") is the Marvell 3700 from Espressobin board, not sure it can be used though. The driver apparently also exist but not for that family, so i guess it's a matter of time until it's ported to that Marvell soc, i doubt adding compatibility flags would suffice. thx again for the benchmarks. -- off topic -- if anyone's interested with a 56k value you should be able to achieved an absolute max of 80-90Mbps with openvpn (single thread). so in that context it would be definitely a bottleneck bandwidth wise, usb3 (well even usb2) and Gbe would be only useful in a unencrypted/lan context.
  25. mdel

    ROCK64

    hello could someone post some figures for ssl performance on that rk3328 cortex A53 soc : openssl speed -elapsed -evp bf-cbc aes-128-cbc aes-256-cbc please specify your board ram configuration (1/2/4GB), it seems ram (larger/faster bus) has quite an impact on those performances. thx
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines