Jump to content

mb16

Members
  • Posts

    12
  • Joined

  • Last visited

Posts posted by mb16

  1. 18 hours ago, NyxPDX said:

    Hi! I recently got a Leelbox Q4 Plus, which is very similar to yours (same board 'XT-RX4B-V02' and wifi 'RTL8723CS'... but has 64gb of storage). I wanted to ask if this is still your most up-to-date DTB file?

    Yes, I did not work further on this, as it fits my basic needs. Btw. i'm quite happy with the device, works stable and without severe issues for me.

  2. 17 hours ago, armar said:

    Edit: Looks like yours is looking for gLmpVersion of 0x8703 (and not 0x8723), maybe that needs different bt fw?

    Thank you for looking into this, I think you are right. I made a test, disabling the error check in the source - then the firmware gets uploaded to the chip but does not work. 

    Now, I found that there are patches to support the 8723cs bluetooth in the kernel ( https://patchwork.kernel.org/patch/10771231/ ) and found the related firmware files in /lib/firmware/rtlbt but I'm by far not brave enough to get stuff like that working. 

     

    So, I guess I'll just wait and use an usb dongle for bt meanwhile.

  3. 18 hours ago, armar said:

    I have bluetooth working on the A5X MAX

    Congrats, thanks for sharing!

     

    Unfortunately this does not work for me by now. May be a device-tree/wiring issue with my board or because there is an 8723cs in my case. The basic uart/hci communication seems to work, see attached file. But the BT-Adapter still does not show up.

     

    Could you upload hciattach.txt for comparison?

     

    hciattach.txt

  4. 49 minutes ago, wdtz said:

    Clearly,, you have not read whole thread,, about 5 pages back, but differently

    in adb# ,, ls -l /sbin/su;  ls -l /system/xbin/su   ,, notice that they are not the same?

    (google) verity off; mount -o remount,rw /system;  cd /system/xbin; mv su su.bak;  cp /sbin/su .

    and then root will work in android

    FWIW

    Sorry for that wdtz, i really honor your very helpful comments, but in my case, running literary "adb root" did work for me. 

  5. 1 hour ago, balbes150 said:

    Preferably the paragraph to describe in detail

    Agree. Getting to the Android .dts took me some time, as many of the proposed procedures did not work for me.
    My workflow:

    • Have Android running on the box, developper mode active.
    • In the settings I had a strangely named checkbox like "Internet debugging", switched on
    • Have Android studio installed
    • Could use adb to connect to the box, even without usb, just via lan/wlan
    • adb root worked out of the box, devices like this one seem to be rooted by default?
    • used adb to download the device-tree directory (have android not at hand now, should not be to hard to find)
    • used dtc to convert

    It took me some time to realize that dtc can handle device-tree directories (-I fs option, see manual)

     

    Starting point for documentation: https://www.kernel.org/doc/Documentation/devicetree/usage-model.txt

  6. On 1/31/2019 at 2:05 AM, armar said:

    Can you tell us a bit about how you came up with this dts, especially the wifi settings?

    Glad to read I seem to have created something useful.

     

    My box is a scishion ai one alike one, MXQ pro max labeled box. The board is labeled TX-RX4B-V02.

     

    My workflow:

    • Used adb to read the device tree directory from the box running android.
    • Converted to android.dts file using dtc.
    • For armbian used the ...box.dtb because the device could boot using that one.
    • Converted dtb to dts using the "sorted" option of dtc for comparison (a).
    • Converted dtb to dts without the "sorted" option for optimization (b).
    • Used a merge utility (meld) to compare (a) against android.dts
    • Put the found differences into (b), used dtc to compile.

    Too easy :)

     

    Now, compare and merge... Using dtc to decompile a dtb to text format means there is no symbolic info - names as found in the kernel sources .dts(i) files 
    and rockchip documentation are not available. Its just like reading and trying to understand a compiled app from a debugger listing without symbols.
    Reading the kernel documentation regarding the device tree mechanism turned out to be very helpful.

     

    I think this kind of workflow is suitable for proof of concept. It is really not suitable for anything else.

     

    Its very easy to make mistakes. Easy to detect if the device refuses to boot, but there are many more possibilities.

     

    Reading things like ... "did not work... suddenly did... then stopped to work again...":

    This can mean pin settings (called pad nowadays, ok) might be wrong.
    Reset or chip enable signals of peripheral chips are wired to soc gpios. If the mapping of those gpios to driver functions is wrong - anything can (and will) happen.

     

    Regarding dram settings

    These numbers count in pico seconds. And a pico second is a dammed short time. The right values depend on used chips and pcb layout and must be
    set very carefully. Just using the values suitable for one board with an other... might work - or not - or temporary.

     

    Regarding the wifi chip

    The soc pads wired to the 8723 on my pcb differ from the standard ones and an other mmc peripheral of the soc is used for sdio connection. 
    It might well be, that other pcb's are wired the same way and that 8723bs and 8723cs are mostly compatible.


     

  7. I made a few adjustments to the device tree for my XT-RX4B-V02 based box. The intermediate results look promising:

    • wifi (RTL8723CS) basically works
    • memory perf:
      armbian@rk3328:~$ dd if=/dev/zero of=/tmp/testfile bs=1M count=1000
      1000+0 records in
      1000+0 records out
      1048576000 bytes (1.0 GB, 1000 MiB) copied, 1.70386 s, 615 MB/s

    ... this was within an x11vnc session, on multiple tests I constantly get values greater than 550MB/s (The board has 4GB DDR3/1600 ram)

     

    Notes

    I never experienced stability issues. As the mounted "heatsink" is more than dubious, I lowered the temp limits just to stay on the safe side. Scaling down the cpu-frequency on temp limit works flawlessly.


    The voltage settings used in Android are slightly lower than the ones in use. I had no time to test, might improve temps a bit.

     

    There are still a number of issues, maybe someone around could kick in?

    • Wifi client: Connect using nmtui is fine, but how to auto-connect on system start?
      The adapter chooses a random mac on boot. I think assigning a static one would help - I just did not find a proper way of doing so...
    • dmesg tells me that there are still a number of device tree issues that might prevent the gpu from working properly.
    • Bluetooth (RTL8723CS) does not work yet (while usb bluetooth dongle is fine). I got the impression (might be wrong) that chip support will still take some time, but I'd like to get the device tree right and don't know how to prove that I got pins/uart/device tree settings right.
    • @balbes150 lsmod tells me 8723cs and 8723ds get loaded. Removing 8723ds.ko helps - what would be the right way of dealing with such situation?

    OT side notes:

    Best

    rk3328-box-RX4B-V02-WIP190129.dts

  8. Big thanks to Balbes, perfect work!

     

    I own a MXQ PRO max. This box looks like SCISHION AI ONE / RX4B. (rk3328, 4gb ram, 32gb emmc, 100mbit lan, 2.4ghz wlan, bt)

     

    Goal: Use box as thin client (vnc, rdp,...) using armbian/ubuntu desktop istalled on emmc.

     

    With Balbes newest image and jeanrhrum hints (https://forum.armbian.com/topic/8082-armbian-for-tv-box-rk3328/?do=findComment&comment=68975) i am able to make the box boot armbian from sd card. (SD card booting is not reliable. In many cases the box ignores the sd and boots Android. After a number of restarts the box boots from sd to Bionic desktop. I did not find the root cause, but i suspect the problem be around psu / sd card / timing. As soon as sd boot is detected, armbian boots and works very reliable) 

     

    /boot/extlinux/extlinux.conf
    
    LABEL Armbian
      LINUX /Image
      INITRD /uInitrd
      FDT /dtb/rockchip/rk3328-box.dtb
      APPEND root=LABEL=ROOTFS rootflags=data=writeback rw console=uart8250,mmio32,0xff130000 console=tty0 no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0 
    

    Using this dtb: lan and spdif work well, i did not go into details with bt, wifi.

     

    I find:

      armbian@rk3328:~$ ls /dev/mmc*
      /dev/mmcblk0    /dev/mmcblk0p2  /dev/mmcblk2boot0  /dev/mmcblk2rpmb
      /dev/mmcblk0p1  /dev/mmcblk2    /dev/mmcblk2boot1
      armbian@rk3328:~$ 

     

    I was able to backup emmc (/dev/mmcblk2) to an external usb disk drive using dd. I could not use the ddbr script  (sd card too small, forced into zip mode even though plenty of space on external drive)

     

    Now, I would like to extract the device tree from android image to optimize for bt, wifi and possibly access the 7-segment display of the box.

     

    How can I get access to androids device tree file? Could I mount /dev/mmcblk2boot<x> somehow?

     

    Any hints on this? Best,
    Markus

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines