mb16

Members
  • Content Count

    12
  • Joined

  • Last visited

2 Followers

About mb16

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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. 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. 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. Sorry for that wdtz, i really honor your very helpful comments, but in my case, running literary "adb root" did work for me.
  5. I think there are a hand full of reasons but a major point might related to the "chosen" node.
  6. 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
  7. 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.
  8. 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: x11vnc. I had issues with disconnecting windows viewers that took me some time to resolve. I found the resolution here: https://thespecter.net/blog/technology/opensourcediy/x11vnc-stack-mashing-detected/ (just add -noxrecord to x11vnc command line) In headless mode I get 1024*786 on boot. Simply calling xrandr --fb 1920x1080 works well. Best rk3328-box-RX4B-V02-WIP190129.dts
  9. Should that be 'sudo make modules_install'? Very helpful, thanks a lot!
  10. Thank you for all these details! I can connect adb and have root. Lets see, what I can get, will take me some time.
  11. Thank you, will have a look there.
  12. 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