• Posts

  • Joined

  • Last visited

Everything posted by jock

  1. @paradigman I don't what to say, that's just a problem that has been rarely seen before and I don't have such a problematic board to investigate further. I see that your board has "R29-MXQ" marking, but we have only seen "R28-MXQ" which is indeed different. I may suggest you, if you didn't already, to try an image with the mainline kernel.
  2. @marshall Thanks for the 32 bytes of the image, but actually I meant the first 32 megabytes eheheh . No problem however, I managed to extract the original dtb from the tvbox image. I took a look into and yes, there is the need to adjust the secondary led and something seems to be a bit different for wifi too. I will craft a special overlay so you can test the whole thing.
  3. Sorry for breaking into discussion, but I'm puzzled about u-boot chainloading. What problem does it solve?
  4. Yes thanks, indeed the original firmware will be very useful! Actually I just need the original device tree overlay, but if you're not able to extract it by yourself, just post the first 32 megabytes of the original firmware and they will suffice. Most surely the led problem on the second board is a misconfiguration: that's something I can adjust taking a look into the dtb. esp8089 driver and firmware are already into the package, but it is very probable that your board has a particular gpio configuration to let it work, and the dtb can reveal that to us. Curious is the fact that it is randomly detected: maybe you can check if the device is correctly detected after warm reboots and not detected after cold reboots, or things like that. Any hint of this kind (plus some dmesg) are helpful with such situations. By the way, I see a big 26MHz crystal near the esp8089 on the board, so surely the .conf file has to be set accordingly.
  5. @MX10.AC2N Great, happy that we're very close to the solution To get 1.3Ghz, just add rk3318-box-cpu-hs overlay. If I read the dtb correctly, also the wifi is attached to the extra sdio bus on your board, so you'd better add rk3318-box-wlan-ext overlay too! Reboot and you should get these two other things. BTW: you can also use rk3318-config to do all the necessary overlay configuration with the comfy menu interface. Just need to manually edit armbianEnv.txt before rebooting and set rk3318-box-led-conf3 in place of any other led-conf (there must be only one led-conf overlay). In the next update I will add the led-conf3 to rk3318-config so coming people with boxes like yours will find the recipe ready-made
  6. @MX10.AC2N Thanks for the dmesg log and the whole diagnostic Despite I said the previous dtbo was the latest for today, here I propose another one. I spotted a subtle error in the dtb that I fixed: I was too zealant to give a voltage to the ddr regulator, while documentation says I should not do that. Install this other dtbo whenever you want, reboot and please post again diagnostics. I will check dmesg for any residual errors. I hope this is the last time. I don't know what's wrong with armbian-config. You may try to update it with apt install armbian-config and see if the error disappears, but from what I read you already updated packages. It could however be a side effect of the slightly wrong dtb, so maybe try again with this other one and then try again to change the governor. rockchip-rk3318-box-led-conf3.dtbo
  7. @MX10.AC2N Here it is another attempt, last one for today I rewrote the overlay and double checked anything I could simulate on my board. If the system boots, please send back a dmesg log! rockchip-rk3318-box-led-conf3.dtbo
  8. @MX10.AC2N Hmm, would try with this other dtbo? rockchip-rk3318-box-led-conf3.dtbo
  9. @MX10.AC2Nwell at least some error is showing up: Failed to register regulator: -517 I will try to find what's wrong with that.
  10. @MX10.AC2NWell I guess I missed something Most probably it is something related to the emmc/sdcard, depending upon what is your booting device actually. That behaviour is common when the booting device is not detected, thus the initramfs can't find the root filesystem. increase verbosity to 7 and you should also get some kernel messages on screen and a full boot dump on UART. The full boot dump would be very useful to find what is missing there.
  11. @marshall Hello. The NAND problem is just unsolvable without any clues. The commercial name of the tv box is totally useless: what is outside is not what is inside; the board name may give some more hints about but surely won't solve the mistery. About the latter board, that's a very recent eMCP board, some of which we've never experienced directly but just seen in photos. Providing a dtb overlay that fixes leds is usually quite simple, less simple is understanding what's wrong with the esp8089.
  12. Look at the post edit I made a little after, clarifies why the thing can't work on our tv boxes. I learned things are and there on the internet, could not find a proper guide. Anyway google reports this forum thread, which is a good starting point: Yeah, undervolting is cool, but results vary a lot depending on the cpu sample. GPU can be tweaked too. RAM can't be tweaked for three reasons: the dmc (dram memory controller) node in the dtb is disabled the dmc driver in the kernel is a bit broken the piece of code that does the dram frequency scaling is not present The dram frequency is fixed by a thing which is called ddrbin, and it is the very first thing that boots (even before u-boot). It is fixed to 330 Mhz currently, but probably I will push it to a higher yet safe value. You need to put together an idbloader, which is composed of ddrbin + u-boot SPL. You can inspect armbian sources for that, but if you're not an expert in compiling u-boot, I would rather suggest you to stay away from that to avoid lose mental sanity.
  13. @Gausus thank for sharing that tip. The main problem I see with your approach is that the vqmmc supply is wired to sdmmcio-regulator, which in turn is not really wired to a proper gpio pin controller. This line: gpios = <0x68 0x00 0x00>; Converts into: gpios = <&pcfg-pull-none-2ma RK_PA0 GPIO_ACTIVE_HIGH>; which does not make sense, since pcfg-pull-none-2ma is not a GPIO controller. There is not real voltage switching to 1.8v for the sdcard controller part as required by UHS modes, in your case the sdcard is incidentally working in UHS mode with 3.3v for the signalling part, but another card may not work or may not be stable. By the way, looking into rk3328-roc-cc device tree there is some reference about sdmmcio regulator, and it is wired to the SoC General Register File (GRF), so it could be possible for any rk3318/rk3328 board to achieve UHS speed modes. This is a good catch, because any rk3318 original firmware allows this, thus the original dtbs never expose such capability. I will look into! edit: hmmm, this definitely looks like a red herring. I followed the rk3328-roc-cc approach but, after measuring the voltage on the sdcard pins, the regulator is not really changing voltage. In fact, some sdcard are happily recognized and work in UHS mode with 3.3v, some others absolutely don't (a couple of Sandisk ones) because require the 1.8v, as specs say. Then I found this discussion: where is stated that Firefly (the guys behind roc-cc board) rewired the GRF gpio pin (which is normally used to mute the analog audio) to the sdmmc_io pin. That's it, the roc-cc (which is the same board in station m1) has a custom design for that pin that switches between 1.8v and 3.3v. So on tv boxes that pin enables and disables analog audio signal, on the roc-cc switches the sdmmc io regulator.
  14. @MX10.AC2N Here it is, I prepared a DTBO following the Station M1 and the original device tree of the board from the firmware you shared. Put the file in /boot/dtb/rockchip/overlay directory, then as usual add rk3318-box-led-conf3 to overlays= in /boot/armbianEnv.txt Reboot and hope...! rockchip-rk3318-box-led-conf3.dtbo
  15. @tommy Here it is, the latest 5.14 kernel with Ubuntu Hirsute: I didn't even test the image, I hope it boots!
  16. @andybo it's wrong that the vendor of the box just faked specs. Your box has a 1GByte of RAM, no less, no more.
  17. @nafanovich sorry but can't see anything wrong in the log you provided, except for the last message Failed to start Create System Users which is something I really don't have any clue about. You may try to boot from sdcard, mount /dev/mmcblk2p1 on /mnt and add emmc-pins overlay to overlays in /mnt/boot/armbianEnv.txt directory reboot and see if something changes, but otherwise it looks like a pretty clean log to me with no particular hardware errors.
  18. There is only one led (called working) in the base dtb because that led is commonly attached to the same GPIOs on (presumably) all boards. Other leds will spawn once rk3318-config is run, because every board type has a different led configuration. The dtb must describe the GPIOs of the leds correctly, otherwise they won't work. Your board is not yet in the list, so you may want to give a shot the the existing two boards until I make a specific overlay for yours. Chances are very low though.
  19. Can't remember if the upstream image has lima enabled in X11 or not. Anyway check /etc/X11/xorg.conf.d/40-serverflags.conf and in case Option "AccelMethod" is set to "none" change it to "glamor". It was set to none because performance is very slow with older lima + mesa and software cursor. If you wish to try I can provide a cutting edge image with kernel 5.14 and Ubuntu Hirsute (=> much newer Mesa) and hardware cursor, which should radically change the experience. BTW: I'm pretty interested in trying retroarch just for fun; there is a "gaming on arm" club where you may give some hints or write down a tutorial on how to compile. Maybe @NicoD may give you some help.
  20. I understand your doubts, but the fact is that the kernel that runs on android is not the exact copy of the kernel of the multitool, probably neither the same version. HDMI timings are differently arranged on multitool and armbian kernels, that's something inherited from libreelec patches I merged in, so I can just trust them. This in turn causes different behaviour than stock android.
  21. @paradigman ah ok, now I get it... you posted the multitool uart log. Anyway, changing dtb is not useful. multitool dtb is made on purpose to have the main blinking led to show that the board and kernel are functioning. Also multitool dtb is made to boot with very conservative options to increase compatibility and stability with boards, since its purpose is to do maintenance. The problem that you don't see anything on HDMI may be due to multiple factors: the kernel, the HDMI cable and, most of all, the monitor. If you can try another HDMI cable and monitor we can start to remove some variables from the equation.
  22. Uhm, I see that you have and old full-hd monitor. It should not be an issue, but apparently it is. From the hints about your experiences (working on Android, working on multitool, not working with armbian), I guess you installed armbian with mainline kernel: there are some tweaks in the mainline kernel that alter the HDMI timings, thus they may be better with some monitors and worse with others. In your case it may be that your monitor does not like those timings. You may give a chance to the legacy kernel image, you can just put in on sdcard, plug the sdcard and boot: the box should automatically boot from sdcard, so you can easily test if HDMI is properly working with legacy kernel at least.
  23. @MX10.AC2N The sv6051p has a driver only in the legacy kernel. In terms of source code, the driver is quite ugly so noone tried to fix or rewrite it for mailnine kernel; the chinese company that manufactured the chip disappeared some years ago, so at the moment there is no support on mainline kernel. It will just not work, no need to handle that manually.
  24. Good you posted logs, bad you changed the dtb. From the log I see, your sdcard/emmc is mounted read-only by kernel. Maybe it is faulty? Can't say for sure, since you changed the dtb and who knows what's happening... Follow the instructions, use another sdcard if you can, then came back with fresh logs if you still have problems.