• Content Count

  • Joined

  • Last visited

About jock

  • Rank
    Elite member

Recent Profile Visitors

832 profile views
  1. jock

    CSC Armbian for RK3288 TV Box boards (Q8)

    Sorry, but it won't work: rk3229 it a totally different SoC which requires different kernel drivers and thus different device trees etc... etc... Also rk3229 is not supported by mainline kernel and rockchip does not provide any sort of opensource documentation or source code for it. You may try to tinker with the original android kernel: booting a debian stretch using that kernel may be at hand, but surely it may require quite some work and knowledge.
  2. jock

    CSC Armbian for RK3288 TV Box boards (Q8)

    rkdeveloptool, as far as I can remember, can't backup the existing bootloader. When you read the whole eMMC using rkdeveloptool, it skips the first 4 megabytes where the bootloader resides. I think other tools, like the AndroidTool for Windows, can backup the existing bootloader too. You could backup manually the bootloader partition accessing a running android installation via serial port. rk3288_ubootloader_v1.01.06.bin came from the original rockchip rkbin repository, now removed but mirrored on github by armbian people. It is a collage of some rockchip binaries and an ancient u-boot binary into a single file. I don't think backing up the bootloader worth it, as the one provided by rockchip looks the same as the one installed on the device. Also if you want to run armbian, the original bootloader is replaced by a recent and up-to-date mainline u-boot.
  3. maybe sudo depmod -a can be useful to refresh the modules depencies
  4. Are you sure you have NAND chip? Usually tv boxes have standard eMMC chips which should be supported by latest mainline kernels:
  5. AFAIK 8189ETV driver is not in armbian for meson64 and neither in mainline kernel at the moment. You have to compile it yourself from sources you can find here: You may also integrate it into armbian build system as a patch for the kernel, so when you build your armbian distro you also compile the driver as module: I did it as an experiment in my own armbian fork for mxq-s905-v20 tv box board (which is commercially known as Nexbox MXQ Pro, with S905 SoC) and it works very well. You may try to use this patch, which should be enough to integrate the driver into the kernel during armbian building. Just put the patch in the same directory (patch/kernel/meson64-next) and you should go. If you want to compile the driver yourself on the running system instead, don't forget to install the linux headers first. Side note: the driver works flawlessy with 4.19 kernel, but you report your next flavour is using 5.0 which looks strange to me since 5.0 should be dev flavour. Maybe the driver works on 5.0 too, but I never tried
  6. jock

    Slow (~3 MB/s) SMB write speeds

    @bambam Are you still connected with wifi? 3Mb/s over wifi is respectable for a basic 802.11n wifi link, considering also that SMB has some amount of traffic overhead. The iperf log you posted, looks like it is over local loopback, since 4Gbit/s seems way too much to me...
  7. The kernel log is quite explicit: the gpio-rc-recv kernel driver is failing to use the gpio pin. Most probably the gpio pin is not correctly configured in the device tree so the driver does not know which gpio pin to use.
  8. jock

    CSC Armbian for RK3288 TV Box boards (Q8)

    Hello @hexdump, I'm glad you find my work useful! About your questions: 1. I programmed a small userspace program that reads the memory controller memory-mapped space to get most of the timings and settings. In the u-boot device tree source file I commented the exact location where the bits are extracted (see here). This stack overflow post may be useful for you, also I distinctly remember had to recompile kernel with CONFIG_STRICT_DEVMEM option disabled to access memory-mapped device memory. 2. low chance, mostly because q8 uses LPDDR2 and other tvboxes uses DDR3. It is very unlikely that a board works and works stable with the timings of another board. By the way, for Q8 the timings in the device tree file are not used actually. 3. as long as you get the memory timings, u-boot should boot fine. For Q8 boards I must use the rockchip binary bootloader (see here) that does memory initialization and timings autodection, so the timings in the DTB file are not used at all. I put them there for completeness and because I wanted to explore the possibility to add LPDDR2 support to u-boot. For your board, you can either use the rockchip binary bootloader or directly start from u-boot, because u-boot can do memory initialization for DDR3 memory, but you have to supply the memory timings yourself via DTB-file because u-boot can't do timings autodetection.
  9. jock

    Miqi board RK3288

    I don't have a MiQi, but AFAIK armbian-config should already do what you ask
  10. jock

    USB Serial Support not working

    I can confirm that latest armbian with next kernel (4.19) on rk3288 works flawlessy with prolific USB-to-serial adapters: 15567.072909] usb 2-1: new full-speed USB device number 2 using dwc2 [15567.281604] usb 2-1: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00 [15567.281616] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [15567.281623] usb 2-1: Product: USB-Serial Controller [15567.281630] usb 2-1: Manufacturer: Prolific Technology Inc. [15567.318362] usbcore: registered new interface driver pl2303 [15567.323408] usbserial: USB Serial support registered for pl2303 [15567.323550] pl2303 2-1:1.0: pl2303 converter detected [15567.327312] usb 2-1: pl2303 converter now attached to ttyUSB0 I use it daily with Arduino IDE to develop and push things to ESP8266 and works without issues.
  11. jock

    Asus Tinkerboard

    Looking for No currently active connector found on google tells that it is probably a message coming from kernel DRM. Maybe the 7" LCD screen is not advertising itself correctly to the HDMI interface, or there's a bug in the DRM kernel code which prevents it working correctly. I had to deal with a couple of Full-HD industrial panels (via DVI) and they usually refuse to display anything when they are not configured exactly with the resolution and refresh rate they expect. I think this is a remote possibility, but supplying EDID manually may interfere somehow. You can read back EDID from the display using get-edit tool (see this for an example), at least you can understand if the display is advertising its modes correctly: get-edid -b 5 | parse-edid
  12. jock

    Proof of concept - Realtek 1295

    Pretty interesting device! I see from the Internet it has an embedded SATA slot, RTC, 802.11ac wifi, HDMI IN and it has Mali-T860 GPU on a 4-core A53 design, where all other chinese propose outdated GPUs Also the "legacy" kernel looks recent enough, which is nice to start with. Congratulations and keep it up edit: bringing u-boot to boot is one of the most difficult tasks, I faced it when I had to deal with it and Chiptrip Q8 RK3288 (xt-q8l-v10) tv box because I had to use the vendor bootloader and chaining it to u-boot SPL which, in turn, boot the real u-boot.
  13. jock

    Is Mali GPU driver available in Mainline for H3?

    The answer is yes, it can be done, but you need a bit of knowledge about compiling kernel modules. I made it on an Orange PI PC (Allwinner H3) to test my armsoc drivers and it worked, although Mali-400 MP2 embedded into H3 was quite slow. You should be able to take everything you need (both the kernel driver and the userland EGL+OpenGL ES drivers) from Kernel and userland libraries should match their versions to be sure that they work correctly together: if you use r6p2 kernel driver, use r6p2 for userland too. Instructions are easy but here are some hints: You need the kernel headers package installed, you won't get far without this; you should be able to use apt-get to install the appropriate package for your armbian version You can compile the kernel driver on your very same board (I strongly suggest this), so you don't need to export the CROSS_COMPILE environment variable export the KDIR env variable to point to your kernel headers. Typically: export KDIR=/lib/modules/$(uname -r)/build export INSTALL_MOD_PATH env variable to point to your kernel modules:. Typically: export INSTALL_MOD_PATH=/lib/modules/$(uname -r)/kernel follow the instructions as described, but expect some patch won't work or compile fail. Just don't be scared to get your hands dirty, it is common that you may need to do some little manual adjustments (a missing kernel file here, a missing header there...) Once the driver is compiled and installed, you should be already able to modprobe it. Follow the instructions to install the userland EGL and OpenGL ES libraries too. If you are using the X server, you need the x11_dma_buf flavour and you also need to compile this armsoc driver too (maybe you can try the already compiled version I published on this post, it should work for your SoC too. Ignore the media script part which is for rockchip socs). If you don't use X you can use the fbdev flavour, in this case add extraargs=drm_kms_helper.drm_fbdev_overalloc=200 to /boot/armbianEnv.txt as per-instructions.
  14. jock

    M9Plus 4k TV Box - An Exercise in Futility?

    AFAIK, the problem usually is not related to the hardware itself. Some people reports that often these tvboxes are equipped with defective RAM or flash memories, which should be downclocked to work right, but it is common that they just work. The boards follow more-or-less the chipmaker reference design, but it is very common to see some different chips to deal with Wifi, bluetooth, ethernet, PMU, RTC, etc... As long as your box has a S905 SoC, you must use gxbb p200 device tree, otherwise the box won't boot at all! Unfortunately, as I previously said, the peripheral chips are not always the same, so it is very common that the device boots but you don't get all the goodies from it (in your case, the gigabit ethernet), just because the ethernet/wifi/bluetooth/audio/whatever chip is not described in the device tree you used. Probably there isn't an already cooked device tree for your particular board, so you have to deal by yourself, but editing device trees requires deep hardware knowledge and is not at the reach of an average user. I don't know if there is some armbian or community effort here, but device tree overlays are perfect for such job: you have the basic description of the SoC hardware in the main device tree, then every user manually add overlays for each piece of peripheral hardware of it's own board.
  15. you can export LIBGL_ES=2 environment variable and retry launching the binary. Normally GL4ES supports a variety of OpenGL 2 functions, but some are missing. The documentation on official github page covers them in detail