jock

Members
  • Content Count

    422
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Calendar

Everything posted by jock

  1. Not yet, I will do that soon, maybe in a couple of days or so
  2. You can use the multitool to dd image files directly on the device: it has a fully functional bash shell to do such kind of maintenance tasks. Nonetheless you need to do know what you are doing. Maybe you can burn the "bad" backup you made and then burn the rootfs from the image @fabiobassa provided. You need to do some juggling with the original image, but if you are able to do so you can try. Your board is a new revision of the r329q family. In alternative you may have more luck tryingr other images for boards which are older r329q revisions (v2.0, v3.0, v7.0, ...)
  3. The source code of the driver is available from https://github.com/jwrdegoede/esp8089 The patch form to directly paste the driver into the 4.4.194 rockchip kernel tree is available here
  4. 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.
  5. 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. 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/ 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!
  6. @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...
  7. 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
  8. Normally everything which is in the SD card has priority, but if you don't give details it is very difficult to have ideas
  9. 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!
  10. @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!
  11. @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: 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: 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: 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!
  12. Hello @victroniko, very glad you find our work useful! Well, it looks like there's another wifi chip in the cauldron of rk322x boxes 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
  13. I don't think so, that's the bad of closed source ARM Mali drivers
  14. 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.
  15. 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 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.
  16. @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.
  17. Applied the patch, left the rk3288 with 5 hours of this: it worked without an itch, dmesg was clean.
  18. 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: 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) 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 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.
  19. 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)
  20. 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!
  21. 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. 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.
  22. 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
  23. 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 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