jock

Members
 View Profile  See their activity

  • Content Count

    420

  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Calendar

Posts posted by jock

  2. Posted ·

    Edited by jock
    changed senseless sentences

    There is not really "translation" between android dts to linux dts. Android could be considered a Linux distribution like Ubuntu or Debian.

    What you are referring as "android" dts is nothing more than a device tree wrote for a very old Linux kernel (probably 3.10 or 3.14).

    As long as things change during time, so the device tree specifications become more standardized and well-defined. Device trees for old kernels (3.10 is very old nowadyas) are very messy and generally harder to read and understand.

     

    Device trees describe the hardware equipment of  your board. On the x86 world there is something which was used to be called Plug&Play in the early days: Plug&Play let the devices expose themselves to the operating system, which is able to discover and configure them properly without the user intervention. On ARM side this mechanism does not yet exists (to be precise, something exists, but is not available on SBCs), so to let the hardware being discovered you have to tell the operating system. The device tree does exactly this.

     

    All the properties and nodes in the device tree are read back by the kernel and kernel drivers. The "compatible" property tells the kernel which driver needs to be loaded, the driver then reads the node properties to know the resources associated with the device (memory regions, registers, interrupts, dma channels, gpio pins, etc...) and its specific characteristics (for example the clock frequency, FIFO queues, etc...), so it can proceed to initialize and make the device available to the system.

     

    Being aware of this and getting back to the original question, there is no magic translation tool, you have to do the hard job of reading the old device tree and translate into the new. Experience and documentation are fundamental (you can find the documentation on the device tree bindings shipped with every linux kernel in Documentation/devicetree/bindings directory). Intuition and general knowledge of how electronic devices work are very helpful for such task.

     

     

    0

  3. Posted

    On 8/3/2020 at 7:17 PM, victroniko said:

    About /etc/modprobe.d/esp8089.conf - already gone, first tests were done on 20.05.6, after the wipe I mentioned earlier i'm on 20.08.0 now. What I do find strange, is that relying on default setting does not work. Passing the crystal_26M_en=0 parameter did the trick, on this board at least... Every test was with an inmediate power off-on cycle instead of a reboot, to discard possible quirks from the already initialized (firmware loaded) ESP8089 chip.

    Ok, that's interesting, you can then to put options esp8089 crystal_26M_en=0 in /etc/modprobe.d/esp8089.conf to see if it works like being modprobed manually. I'll definitely add this conf file in the final distribution.

     

    On 8/3/2020 at 7:17 PM, victroniko said:

    offtopic. I said I don't know C/C++, that's true... But I did some things in VB6 many years ago, it's not as if I saw modern code and felt totally lost.. And my day-job is electronics so I understand quite a bit how microcontrollers work 

    Doing some research about the es8089, it turns out that it is nothing different than an esp8266 with less pins and interfaces. esp8266 is a very cheap and flexible microcontroller that is pretty assimilated as "the arduino with wifi". Some people attached the esp8266 modules to sdio pins of raspberry pi zero to gain wifi and this esp8089 driver module is the software part to make it work: https://hackaday.com/2016/04/21/usb-less-wifi-for-the-pi-zero/

     

    15 hours ago, Rajesh said:

    Just wondering if this will also work on ARMv8 64 bit boards? Probably not, but if there is a similar solution for this on other boards it would be great!

    Usually kernel driver source code is happy to compile on both 32 and 64 bit modes without any modification, so there good chances it will!

    0

  4. Posted

    @victroniko

    Glad to hear progress! I'm sorry I pointed you to use crystal_26M_en=2, but that was because all the rk322x boxes I have seen use a 24Mhz crystal, so I thought the same was for yours. I first checked on the pictures you provided, but the crystal was totally unreadable.

     

    If you created /etc/modprobe.d/esp8089.conf file (as I suggested you in this other post), remove it. Also unblacklist the esp8089 module and reboot.

    From what I see from source code, the 40Mhz crystal is the default when no options are passed to the kernel module.

     

    I prepared this other kernel module: esp8089.nop2p.ko  I blindly changed a couple of source code lines to avoid the p2p0 interface creation. I don't know if this works, but you may give it a chance. Overwrite the existing esp8089.ko with this one and reboot to see if it has any effect...

     

    For the issue about the media framework, I'll take a look into it...

     

    0

  5. Posted

    2 hours ago, jaum20 said:

    What information do you need?

    My board us "R3229Q _V8.0". I was using LibreELEC-RK322x.arm-9.2-devel-20200427213119-b7186bc-rk3228a-mxq4kpro.img.gz flawlessly on a 4g Toshiba sd. I downloaded the image Armbian_20.05.6_Rk322x-box_focal_legacy_4.4.194_desktop.img.xz and followed the instructions of the first post for install on eMMC. I used a 32gb Samsung SD. Everything succeeded with no problems

    When I connect the board to the power with the LibreELEC sd inserted it doesn't boot anymore. The blue led is on but no output from HDMI.

    If I remove the sd, Armbian boots form internal storage with not problem.

    Ok much better, but at the moment I have no idea this is happening.

    The libreelec boot is somehow engaged because the behaviour changes if you leave the sdcard into, but the reason why it hangs is not clear to me yet.

    I will try to replicate soon on a board of mine

     

    edit: @jaum20 problem solved! Long story short: substitute the file rk3228a-box-mxq4kpro.dtb in the root of the libreelec sdcard with the one attached here. Important: if you're going to update/upgrade LibreELEC, you will need to replace again this file. This is a "problem" I will likely ask to @knaerzche if it can be solved somehow.

     

    Detailed answer for experts: the device tree with the legacy kernel is missing the property arm,cpu-registers-not-fw-configured in the timer section. It is needed on armbian but it is not needed on Libreelec because armbian has OPTEE as trust os (which requires the property), instead Libreelec uses the proprietary u-boot and trust os (which does the timer initialization by itself).

    rk3228a-box-mxq4kpro.dtb

    1

  6. Posted

    21 hours ago, jaum20 said:

    I followed the instructions to install to eMMC and everything worked as expected. The problem is that now the box can't boot my LibreELEC sd. Any ideas ?

    Normally everything which is in the SD card has priority, but if you don't give details it is very difficult to have ideas

    0

  7. Posted

    Good news, expecially for @nokirunner and @DaviMesquita

     

    Finally we managed to make the ssv6x5x driver work on the ssv6256p chipset and it turns out the it is also working pretty well. I removed most of the logging messages it was spamming on the dmesg log, now it is much more silent and it is ok this way. Teaming with @fabiobassa we optimized performances quite a bit, so expect ~60 Mbit/s at least on optimal setups. It works on both 2.4Ghz and 5Ghz bands.

     

    The driver will be included in the armbian images soon, but in the meantime anyone can test it.

    • Download ssv6x5x.koand put it into /lib/modules/$(uname -r)/kernel/drivers/net/wireless
    • Download ssv6x5x-wifi.cfgand put it into /lib/firmware
    • Download ssv6x5x-sw.bin and put it into /lib/firmware
    • Run depmod -a
    • Add blacklist ssv6051 in /etc/modprobe.d/blacklist-rk322x-box.conf (ssv6051 and ssv6x5x kernel modules clashes, we need to blacklist ssv6051 for the other to work)
    • Reboot!

     

    Any testing report is appreciated!

     

    3

  8. Posted

    @victroniko

    I see promising results, very well! ;)

     

    "queuing unknown CIS tuple" are not really errors, you can safely ignore them.

    For what I know, p2p0 and wlan0 interfaces appears with most of these android-derived wifi drivers.

    I have some boards with ssv6051 wifi chip and I have to connect using p2p0 interface because wlan0 always crashes kernel, don't know really why, I never spent time into.

     

    About the autoloading of the esp8089 module at startup, you can create a file in /etc/modprobe.d/esp8089.conf and put this content into: 

    options esp8089 crystal_26M_en=2

    so when the module is autoloaded, it is also given the appropriate module parameter.

     

    As another hint, to test the firmwares and things avoid the Network Manager. It is slow and has latency, and does not always reacts immediately. Use the command line tools to scan the networks, for example (always use sudo, or do it as superadmin, otherwise you get cached data): 

    sudo iwlist wlan0 scan

    You may also scan the p2p0 interface and see what changes. Usually you won't get more than 10-12 access points in the list.

     

    I could not find any evidence in the source code that the files should be placed in esp8089 subdirectory, so I'm not totally convinced about the firmware placement in /lib/firmware/esp8089. Double check that this is really what the kernel module wants: loading the kernel module and doing a successful scan should be enough. Every kernel module developer decides where the files are put, some wants their own subdirectory, some others don't. dmesg should tell you if the firmware was in the right position or not, always read its output very carefully!

     

    Once you get sane and predictable results with iwlist, you may proceed to use the Network Manager to connect to a network. From the command line you can also use the handy nmtui tool

     

    Always reboot between tests, even though I read that rmmod (prefer modprobe -r to unload a module, anyway) crashes the kernel and freezes the system, so there is no other chance :)

     

    Good luck!

     

    1

  9. Posted

    @victroniko Great job indeed, extracting the device tree "like cavemen" made me laugh :) There are other ways, but all of them are not easier and still requires some steps.

     

    From the logs you provided I can see from dmesg that the chip itself is not recognized at all:

    Spoiler

    paolo@raziel:~/rk3229/esp8086 dtb victroniko$ egrep 'mmc1|30010000' dmesg.txt
    [    3.719868] dwmmc_rockchip 30010000.dwmmc: num-slots property not found, assuming 1 slot is available
    [    3.719977] dwmmc_rockchip 30010000.dwmmc: IDMAC supports 32-bit address mode.
    [    3.720117] dwmmc_rockchip 30010000.dwmmc: Using internal DMA controller.
    [    3.720138] dwmmc_rockchip 30010000.dwmmc: Version ID is 270a
    [    3.720213] dwmmc_rockchip 30010000.dwmmc: DW MMC controller at irq 46,32 bit host data width,256 deep fifo
    [    3.720287] dwmmc_rockchip 30010000.dwmmc: No vmmc regulator found
    [    3.720301] dwmmc_rockchip 30010000.dwmmc: No vqmmc regulator found
    [    3.720324] dwmmc_rockchip 30010000.dwmmc: GPIO lookup for consumer wp
    [    3.720336] dwmmc_rockchip 30010000.dwmmc: using device tree for GPIO lookup
    [    3.720351] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/dwmmc@30010000[0]'
    [    3.720360] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/dwmmc@30010000[0]'
    [    3.720370] dwmmc_rockchip 30010000.dwmmc: using lookup tables for GPIO lookup
    [    3.720380] dwmmc_rockchip 30010000.dwmmc: lookup for GPIO wp failed
    [    3.720478] dwmmc_rockchip 30010000.dwmmc: allocated mmc-pwrseq
    [    3.731916] mmc_host mmc1: Bus speed (slot 0) = 2343750Hz (slot req 400000Hz, actual 390625HZ div = 3)
    [    3.744618] dwmmc_rockchip 30010000.dwmmc: 1 slots initialized
    [    4.098145] mmc_host mmc1: Bus speed (slot 0) = 2343750Hz (slot req 300000Hz, actual 292968HZ div = 4)
    [    4.150250] mmc_host mmc1: Bus speed (slot 0) = 2343750Hz (slot req 200000Hz, actual 195312HZ div = 6)
    [    4.202331] mmc_host mmc1: Bus speed (slot 0) = 2343750Hz (slot req 100000Hz, actual 97656HZ div = 12)

    This above is an extract of your dmesg. dwmmc@30010000 is the MMC controller (in the SoC) and the SDIO chip (the ESP8089) is attached to it. The controller works ok, but the chip is not recognized: as you can see from the last 5 lines, the kernel tries to detect something on that bus lowering the frequency 4 times, then gives up.

     

    This instead is a box of mine where the chip is correctly detected:

    Spoiler

    root@rk322x-box:/sys/class# dmesg | egrep 'mmc1|30010000'
    [    3.789785] dwmmc_rockchip 30010000.dwmmc: num-slots property not found, assuming 1 slot is available
    [    3.789891] dwmmc_rockchip 30010000.dwmmc: IDMAC supports 32-bit address mode.
    [    3.790045] dwmmc_rockchip 30010000.dwmmc: Using internal DMA controller.
    [    3.790072] dwmmc_rockchip 30010000.dwmmc: Version ID is 270a
    [    3.790154] dwmmc_rockchip 30010000.dwmmc: DW MMC controller at irq 46,32 bit host data width,256 deep fifo
    [    3.790232] dwmmc_rockchip 30010000.dwmmc: No vmmc regulator found
    [    3.790244] dwmmc_rockchip 30010000.dwmmc: No vqmmc regulator found
    [    3.790266] dwmmc_rockchip 30010000.dwmmc: GPIO lookup for consumer wp
    [    3.790276] dwmmc_rockchip 30010000.dwmmc: using device tree for GPIO lookup
    [    3.790291] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/dwmmc@30010000[0]'
    [    3.790303] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/dwmmc@30010000[0]'
    [    3.790311] dwmmc_rockchip 30010000.dwmmc: using lookup tables for GPIO lookup
    [    3.790321] dwmmc_rockchip 30010000.dwmmc: lookup for GPIO wp failed
    [    3.790556] dwmmc_rockchip 30010000.dwmmc: allocated mmc-pwrseq
    [    3.803434] mmc_host mmc1: Bus speed (slot 0) = 976562Hz (slot req 400000Hz, actual 244140HZ div = 2)
    [    3.816143] dwmmc_rockchip 30010000.dwmmc: 1 slots initialized
    [    3.863585] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
    [    3.866293] mmc1: new high speed SDIO card at address 0001

    You can see that there is just one detection attempt at 400KHz, then the frequency is pushed up at 50MHz and the SDIO "card" is finally detected.

     

    Now this is the first problem at all, so we need to let the kernel detect the chip first, otherwise we don't get far. Looking in the device tree you provided, I found a couple of things that may be important. One, which maybe is the most important, is this:

    Spoiler

    wireless-wlan {
            compatible = "wlan-platdata";
            wifi_chip_type = "esp8089";
            sdio_vref = <0x708>;
            WIFI,poweren_gpio = <0x7b 0x1b 0x00>;
            WIFI,host_wake_irq = <0x74 0x1c 0x00>;
            status = "okay";
        };

    tells us that the GPIO that give power to the chip is "0x7b 0x1b", which translates to human readable to the active low pin #27 of gpio bank #2. The SoCs have usually several banks of GPIO pins (RK322x have 4) and each bank has several GPIO pins itself (each RK322x bank has 32) attached to the various peripherals and leds. The pin #27 of the gpio bank #2 is attached to the Wifi chip power on/off switch.

     

    Comparing this with the device tree supplied with armbian, I can see that the pin which is usually connected to the Wifi power switch is the #26, so probably we need to adjust this to properly power the chip.

     

    I crafted a device tree overlay which can be useful: rk322x-wlan-esp8089.dtbo

    Put this dtbo file in /boot/dtb/overlay directory, then edit /boot/armbianEnv.txt and append wlan-esp8089 to the overlays line, then reboot and look if dmesg is showing the "new high speed SDIO card" string.

     

    Once there, you may try again to modprobe (there are differences between insmod and modprobe, you can consult the manpages for that) the esp8089 kernel driver and see what happens!

     

     

    0

  10. Posted

    Hello @victroniko, very glad you find our work useful!

     

    Well, it looks like there's another wifi chip in the cauldron of rk322x boxes :rolleyes:

    Found some informations about the ESP8089 on the linux-sunxi site which points to this other repository that already has some kernel integration and, most of all, the firmware files.

     

    I managed to integrate it very easily into rockchip 4.4 kernel, and compiled it into a kernel module: esp8089.ko.gz

     

    Now first of all download the three firmware files from the jwrdegoede's repository I linked above and put them in /lib/firmware

     

    Copy that file in your box root and then execute: 

    gzip -d esp8089.ko.gz
mv esp8089.ko /lib/modules/4.4.194-rk322x/kernel/drivers/net/wireless
depmod
modprobe esp8089 config=crystal_26M_en=2

    This other repository (it's a fork from al177's) contains a PDF file with some compilation and usage informations from ESP8089 manufacturer you may wish to try in case it does not really work.

    It looks like the chip also requires some GPIO juggling to make it work: the original device tree (DTB or resource.img) of the board could be very helpful here. Also dmesg log is always very helpful!

     

    Here you can download the kernel headers as a DEB package. You will need to install this in case you want to compile the driver directly on the board. Install it this way: 

    sudo su
export ARCH=arm
dpkg -i linux-headers-legacy-rk322x_20.08.0-trunk_armhf.deb

     

    0

  12. Posted

    1 hour ago, Yeoj Henrie Sayadi said:

    These boxes are really nice. After 2 days of compiling 0ad (yes it took that long) I need to allocate more vram as I am getting segmentation fault. I have tried many different things but nothing worked. Is it possible to allocate more ram for the gpu? How?

    VRAM is allocated on demand, there isn't any option to allocate is statically. Mali OpenGL ES can be very picky, and often results in segmentation fault just because the game does something the libraries dislike.

    1

  13. Posted

    5 hours ago, Maker39 said:

    It may be that for the 8723cs to work in Armbian, some other manipulations are needed at

    the level firmware or drivers?

    Well, for what I can say the 8703bs worked only using the rtl8723cs driver: not the 8723bs, not the 8723ds, but only the 8723cs one, but never had the chance to try a real rtl8723cs chip.

     

    Since you did some kind of chip transplantation :rolleyes: you should first understand if the chip is correctly communicating on the SDIO bus. You can look for dwmmc (SDIO bus should be dwmmc@30010000 device) messages in dmesg, then look into /sys/bus/mmc1 for important informations (like vendor and device id of the chip). Once you're sure the hardware level is ok, then you may work further for software issues.

    0

  14. Posted

    @DaviMesquita unfortunately, as @fabiobassa already said, ssv6256p is not yet supported because the driver is missing. The source code is available and we did experimentation with, it also compiles but once I load it, the kernel crashes. We could not get further for an usable interface, so we parked it to work on other tasks. I can definitely do some more experiments to try to get it on, but indeed the driver is so messy it makes the debug an even harder task.

     

    A bad thing that makes people do mistakes is the fact that both ssv6051p and ssv6256p share the same vendor and device ID (3030:3030), so you need to open it to understand if the chip is one or the other; nonetheless the ssv6256p has support for 802.11a (the 5 Ghz bands), which is not present at all in ssv6051p and if the board has the first chip you usually see large "5G" letters on the box. rk322x-config also is unable to distinct between the two chips.

     

    If you're planning to buy other boxes, I would rather suggest to keep an eye on rk322x boxes with bluetooth: usually they get realtek or ampak (=broadcom) chips which should have better support, even with mainline kernels.

     

    About chromium, there may be some tricks to speedup the rendering and the video decoding, but I didn't experiment them yet on the rk322x. We talked about trying to recompile chromium and make experiments which may make things faster, it's on our TODO list.

    0

  16. Posted

    11 hours ago, Yeoj Henrie Sayadi said:

    Hello, the RAM seems to have become the bottleneck now. No changes in the dtb makes no difference whatsoever. How do I make it so that I can control the ram?

    Hello,

    memory performance is a bit problematic. The frequency is fixed at boot time to 300 Mhz for DDR2 and 600 Mhz for DDR3 boxes. There are three main reasons:

    1.  there is a constraint against an internal clock running at 1200 Mhz and RAM must be an integer divisor of that frequency (1200/300 = 4, 1200/400 = 3)
    2. the kernel memory controller driver, that does the memory reclocking up to 800 Mhz, needs the proprietary rockchip trust os to work, but since I use an open source trust os (OPTEE) here, it will never work
    3. DRAM chips among boards are different and may have different access timings, so something that works for a box may not work for another one, even if it is configured at the very same frequency. Sometimes the boards are so cheap the manufacturer installs faulty memory banks that are not even able to work at their rated frequency. To reduce the number of non-booting boards, I chose to take the conservative approach, which is also enforced by the limits of the point 1

    Changing the dram frequency is not an easy task: you need the right ddrbin (the binary piece of code that initializes the DRAM), recompile u-boot, glue them together with the trust os to produce the idbloader and finally install it at sector 0x40 of the flash/sdcard.

     

    This is all done automatically by armbian scripts, so you can read the code to make your way through.

     

    BTW, I'm taking in consideration to experiment with the ARM trusted firmware (ATF) and maybe in the future activate the DMC kernel driver to allow reclocking.

     

    1

  17. Posted

    7 hours ago, Yeoj Henrie Sayadi said:

    how do I remove the fps limit? glmark2 is limited to 60 fps while Quake 3 is limited to 15 even when staring at the floor or when shooting enemies.

    It's the vsync, I don't know if it is possible to disable it with the current Mali drivers. 15fps in Quake3 also is a vsync limit (60/4)

    0

  18. Posted

    23 hours ago, Yeoj Henrie Sayadi said:

    Thank you for enlightening me, I managed to overclock my rk3228a to 1.46Ghz stable and it only needed an adjustment to the clock latency. Now there is a massive improvement in performance 1.2Ghz to 1.46Ghz with the memory clocked to 2133mhz and the gpu to 700mhz and it is pretty stable. I can finally play quake 3 very smoothly. Thanks a lot

    Glad to hear that ;)

    I tried running Quake2 on stock frequencies with Mali libraries, it worked but after I while I had issues from Mali kernel driver. It was long ago and also installation was not yet in a stable status.

    BTW, I'm interested in your clock latency adjustment, can you describe what you did and what problem it addressed? It is my feeling that there is still something not properly right that causes some boxes to be a bit unstable, so I'm looking for any experience that could increase general stability.

    Thank you!

    0

  19. Posted

    On 7/11/2020 at 8:22 AM, Yeoj Henrie said:

    Hello! I opened my box and it has KMF720012M-B214 which is a 8GB e.MMC D-die R11 and 8Gb LPDDR3 SDRAM B-die R02 so it is a 1GB ram right? or is it 8gb ram if so, how do i address that much ram if it would be possible

    Hello, eMMC is 8GB, GB here stands for gigabytes.

    RAM memories are advestised to the general public in gigabytes also, but the technical datasheets of the chips reports the chip sizes in gigabits, so 8 gigabits = 1 gigabyte.

     

    20 hours ago, Yeoj Henrie Sayadi said:

    Is it possible to overclock these boxes? I've tried modifying the dtb but it seems that nothing works? It can go to ~1.4Ghz just fine but anything beyond that gets "ignored" I was hoping that I could go to 1.5Ghz but it seems that something is holding me back at 1.4Ghz it is not unstable or anything but if it would be possible to remove the "restriction" I would be really happy. I am using Armbian_20.08.0-trunk_Rk322x-box_focal_legacy_4.4.194_desktop

    Clock frequencies are "unrestricted", in the sense you can set the device tree to report the SoC is capable of any reasonable frequency. A restriction, as @hexdump said, is applied to the voltage you set for a specific OPP: the SoC frequency is linked to the voltage regulator which has to be programmed on the fly to provide higher or lower voltages depending on the operating frequency. The regulator also has an operating voltage range (also described in the device tree) and the kernel will cut out those OPPs that are requesting voltages outside this range. dmesg will tell you if an OPP has been cut away.

     

    Overclocking these chips should be quite easy, but don't expect great performance advancements, they are low power chips and the architecture is quite old nowadays.

    Lately instead I was trying to undervolt them to see if I can let them consume less current and produce less heat too and I think there is great room for improvement here.

     

    1

  20. Posted

    11 hours ago, k0m37 said:

    Now it works... 

    
[    3.249919] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[    3.289591] mmc_host mmc1: Bus speed (slot 0) = 12000000Hz (slot req 50000000Hz, actual 12000000HZ div = 0)
[    3.291661] mmc1: new high speed MMC card at address 0001
[    3.292447] mmcblk1: mmc1:0001 M62704 3.53 GiB 
[    3.292832] mmcblk1boot0: mmc1:0001 M62704 partition 1 2.00 MiB
[    3.293205] mmcblk1boot1: mmc1:0001 M62704 partition 2 2.00 MiB
[    3.293550] mmcblk1rpmb: mmc1:0001 M62704 partition 3 512 KiB

    Many thanks for your support!

    You're welcome ;)

    0

  22. Posted

    On 7/6/2020 at 2:32 PM, Luis said:

    Hello dear community, I am very anxious to be able to use android and armbian for you.
    for now, is there any way to start my Android on the sd card? lla armbian I installed it in la nand, thanks for your great support 😀

    If I remember well, once I tried to run Android from sdcard on a rk3288 tv box, but it didn't work. I just didn't spent any more time on that because the Android version was ancient (4.4) and had better things to do :rolleyes:

    0

  23. Posted

    Dealing with decompiled device trees is a bit tricky and copy&paste if often a bad idea.

    In your particular case, copying the pin controller entries you are linking the mmc controller to the USB physical-level chip, which is something you definitely may not want to do :rolleyes:

     

    I rearranged a bit the node:

    • fixed the pinctrl to point to the right ones
    • removed the mmc-hs200 property: this can be harmful in case the PMIC is not configured correctly
    • added the default-sample-phase property, I guess it is safe since it comes from the manufacturer
    • added sd-uhs-sdr50 property, which should not be there since it should affect only sd cards and sdio, but who knowns...

     

    Try this one and tell me if it works.

     

     

    rk3229-respeaker-v2-armbian-rev2.dtb

    0

  24. Posted

    1 hour ago, nokirunner said:

    hey I can use firefox from the tv box, and the scrolling of the pages is superfast!,  I managed to activate the 2d acceleration, the only thing is that it takes a long time to load the pages, how could I get around this problem? ... however this is the configuration I'm using on the xorg config file

    Yeah firefox scrolling is very good, about the load time... well the CPU is not strong enough for that :unsure:

     

    1 hour ago, nokirunner said:

    actually checking the xorg log file it tells me that it takes the first device ... I tried to do the opposite, putting armsoc first ... the configurations took them with armsoc driver, but was slow as the shit  ...

    Looking at that onf I'm astonished X.org really starts :D

    Are you on legacy or mainline kernel? Because mixing things can be make the box explode!

     

    Good luck for the multiboot project, it is rather interesting and I'm sure a lot of people here will be interested (myself included)

    0

  25. Posted

    2 hours ago, k0m37 said:

    From u-boot commandline I can access the emmc.

    That's good, u-boot is using my "generic" device tree which is embedded into u-boot itself. At least we know the emmc is working with a basic configuration.

     

    2 hours ago, k0m37 said:

    I think it has something to do with the device tree file, but I can't figure it out. In the patch I didn't see anything mmc related. Could this be the reason? How should the dt-source look like ?

     

    I have added the u-boot & dmesg logs to the first post.

    Thanks for the logs, I think the problem is related to this one: 

    [    3.771361] dwmmc_rockchip 30020000.dwmmc: All phases bad!
[    3.771367] mmc1: tuning execution failed
[    3.771382] mmc1: error -5 whilst initialising MMC card

    which may be related to pin initialization or most probably to eMMC DDR mode. U-boot does not use eMMC in DDR mode.

    I didn't spot any mmc-ddr strings in the ReSpeaker patches. I can take a look to the compiled device tree if you attach it here, but in the meantime you can decompile it, find the dwmmc@30020000 node and comment all the properties starting with pinctrl-names, pinctrl-0, mmc-ddr-1_8v and rockchip,default-sample-phase. Recompile it back and try again.

    0