Jump to content

jock

Members
  • Posts

    1811
  • Joined

  • Last visited

Everything posted by jock

  1. It depends what you want to do. 1Gb is plenty of memory if you want to build up a little home server or media center, but of course if you want to browse the internet with a recent full-featured browser in a rich GUI it is way too low, either if you use Focal or Bionic.
  2. rockchip armhf works fine for me, but I will be happy to fix any small issues if they come up in the short time. rk322x also works pretty fine on 5.9.y: polished a patch with some failed hunks recently due to inclusion in mainline, fixes are already in the master branch.
  3. Hello, Ubuntu bionic is kind of deprecated by Armbian itself, so it is not in the archive directory anymore. I don't really know if it is even possible to build an image. Why you really need Bionic anyway? Focal is way better because packages are just more up-to-date and if you really need stable older packages you may want to try a Debian Buster build. edit: sorry, my mistake. Ubuntu Bionic is deprecated as a building OS, but it is still supported as target OS, so it is possible to have an Ubuntu Bionic image, but you have to build it yourself because it is not in the archives anymore. Suggestions above are still valid (use Focal if you can, or Buster if you need older stable packages)
  4. @zero48 Apparently you have emmc and not NAND flash, so use the other instructions
  5. Unless you have rtl8189etv as wifi chip you don't need that. Just configure the board with rk322x-config so can you get back soon to spend some time with your family
  6. @megaduo Thanks for your patience too, reporting every step was very useful to pinpoint to issue Another hint: use rk322x-config to configure your box with the proper overlays. if the chip is a rk3228b/rk3229 it will gain 200 Mhz and the eMMC will be set to run in DDR mode for much faster speed. You will need to add back the wifi overlays manually after to get them working back. I would also like to add the led setup of your box to the list of led configurations. I see 5 leds on your board, am I right? What is the commercial name of the tv box? I confirm the board is very peculiar and would require some study because its hardware is not the common hardware of cheap rk322x tv boxes
  7. We're on the right way but maybe something still has to be refined. I have another suggestion: take the two dtbo I gave you in this previous post, put them in the proper place. Try first overlays=wlan-alt-wiring wlan8189-etv-ah and, if does not work, try overlays=wlan-alt-wiring wlan8189-etv-al in armbianEnv.txt The error -110 is the standard linux error for timeout, so probably the sdio works because wlan-alt-wiring fixed the GPIO wiring of the bus, but the power enable GPIO pin has the inverted polarity (al=ACTIVE_LOW, ah=ACTIVE_HIGH) so we still need to catch this to let the wifi chip correctly being powered on. edit: thanks for the photos, that's definitely not a board I have ever seen and does not resemble any of the common boards we encountered here on the forums.
  8. @megaduo Ah finally! I now see from dmesg that the SDIO device is correctly detected, but yet there is an error during the device probing. Is the wifi working well for you?
  9. @zero48 Your sdcard log is truncated at some point. It seems that the internal bootloader stops before loading the necessary binaries from the sdcard (see the LOADER error message...). It could happen though that the sdcard boots, switches the UART to 115200 bps and UART FIFO is flushed away, so we don't really get the latest messages. Anyway me and @fabiobassa lately discovered an incompatibility with some existing boards and a part of the bootloader on the sdcard. I just refreshed the multitool image with the incompatible code fixed, so you download it again from the first page and try again, maybe it solves your problem too
  10. @megaduo Here is the last one: rk322x-wlan-alt-wiring.dtbo Put this in /boot/dtb/overlay and as usual put overlays=wlan-alt-wiring in /boot/armbianEnv.txt. Note: the other 8189etv overlay is not needed anymore, wlan-alt-wiring is the only one you need. I hope this works, otherwise I don't know where the problem could be. PS: don't forget to paste a dmesg log even if the overlay works! In case it is successful I will include in the armbian installation
  11. @zero481.5 mbit/s has been always problematic even with my TTL converters, but your logs appear to me too much garbled with too many strange characters I never got. Are you sure the ground pin is well connected? Anyway, it looks to me that in both the logs just posted your box is booting Android, so no sdcard boot from what I see.
  12. @megaduo you had to use the overlays together, but anyway apparently I did a mistake in the wlan-alt-wiring because the kernel is complaining. Need to check it out first. The easier way to get the real gpio layout is with device trees, otherwise you can X-ray scan the board and search for the copper paths from the SoC to the wifi chip, but I think it is far harder
  13. Of course not Will keep my hands sane, I don't really want to discover if they put Android 10 in such a risky way
  14. @zero48 It would also be very nice to have the full original firmware, so we could inspect it and understand if there's something different with the Android 10 boot process. Maybe the box vendor gave you a link to the updated firmware or so... it would be very useful. Maybe I lost some pieces behind, but when you insert the SDcard with the multitool what does exactly happens? The screen stays black or it just boots Android like usual?
  15. @megaduo I made a couple of other device tree overlays. Could not test them at all, just wrote them from scratch based upon the original device tree you provided. It appears that your box has a different wiring for SDIO, so not only the power pin is different but also the data/clock pins. I attached them to this post, as usual put them in /boot/dtb/overlays directory and then change the overlays line in overlays=wlan-alt-wiring wlan-rtl8189etv in /boot/armbianEnv.txt. Reboot and hope! As usual, dmesg is appreciated for debug. rk322x-wlan-alt-wiring.dtbo rk322x-wlan-rtl8189etv.dtbo
  16. You may try this very work in progress build effort made by @fabiobassa, @hexdump and me. Burn it on a sdcard and try, but your mileage may vary
  17. Indeed, due date was Q2 2020, we are in Q4 2020 and all we got is an announcement But I think - hope, at least - we're getting close since source code was being added to their repository starting from august and I hope they don't take another year to prepare the software! I was also interested to see little rk3566 brother, but for this no announcement yet...
  18. Mmmh, the overlays have been correctly loaded, I see the pwrseq using the gpio2-29 in both dmesg logs, but indeed the device is not detected. Apparently there is something else in the recipe that is missing. I need some time to study the original dtb a bit better to understand what is wrong.
  19. Lately there have been many commits in the rockchip kernel github repository talking about imminent new chips (they have been removed though and the 4.19 kernel last commit "regressed" to 11 Aug 2020), but here there is the announcement of the rk3588: https://www.cnx-software.com/2020/11/26/rockchip-rk3588-specifications-revealed-8k-video-6-tops-npu-pcie-3-0-up-to-32gb-ram/ Enjoy!
  20. I took a look to the device tree and it seems to me that the one of overlays I provided should work. The gpio controlling the wifi chip power is gpio2-29 and so I set it in the overlays. The decompilation and recompilation of device tree overlays is slightly different than regular device tree. Check this page, in particular the paragraph 2.1: Fragments. In short. you need the -@ argument to dtc to recompile the overlay back. Anyway it would be very interesting to see dmesg when overlays are applied, to understand if the SDIO device is correctly recognized and there is an issue with the driver or the device still does not get recognized at all.
  21. Never tried Rufus in the last 6 or 7 years to be honest
  22. I understand perfectly you're building the kernel on the box, that's what I suggested, but the armbian image you used is using kernel 5.8.12-rk322x No, you need the kernel sources to build the whole kernel and the modules. The kernel headers (which are a part of the kernel sources, of course) are needed only if you want to build external (out-of-tree) modules. The initial image IS important if you want apt repositories with kernel sources of your installed kernel You need to follow the steps I suggested to you to build the whole kernel and the modules. Your steps just built the single module you needed but the kernel version mismatch and won't ever work.
  23. I don't understand what's wrong with your setup, but did you decompress the multitool (that's its name), as suggested by @fabiobassa before burning on the sdcard? If you are burning the .xz archive as is it will certainly never work! Also in Windows you must see the MULTITOOL FAT partition on the sdcard, otherwise you're doing it wrong.
  24. But I see the version magic error, if you want to install the module for kernel 5.9.10 you must be running kernel 5.9.10, otherwise it will never load. That's why I was suggesting to download the kernel sources via apt of your very same kernel and use them to build the module, so you could build the module alone without rebuilding the whole kernel and all the modules. But you need a stable armbian image to be sure you find the kernel sources in the apt repository. note: I found that there is linux-source-5.8.12-current-rk322x package in armbian repositories. You may install it via apt and you will find the xz compressed sources in /usr/src directory. Decompress the file and do the compilation of the module the way you already did. If you're lucky it will compile, install and load·
  25. Since you used one of my development builds you didn't get all the kernels sources for your specific kernel I guess. Normally the stable versions downloaded from armbian main download page are better if you're going to use the box for some stable usage. By the way, you just made a half compilation of the 5.9.10 kernel I guess Normally the steps I'm used to do on x86 are these, starting from clean sources: - copy the config file you find in /boot into the kernel source directory as .config - run make menuconfig to configure the kernel (enable and disable modules) - run make -j4 to compile the kernel (using 4 threads) - run make zImage to make a compressed kernel - run make modules -j4 to compile the kernel modules - run sudo make modules_install to install the kernel modules - run sudo make install to install the kernel - I don't know if this install the zImage or uncompressed image. You may want to run cp arch/arm/boot/zImage /boot/vmlinuz-5.9.10-rockchip and then cd /boot; ln -sf vmlinuz-5.9.10-rockchip zImage to manually install the kernel - run update-initramfs -c -k 5.9.10 to create the initramfs for kernel 5.9.10 That should do it, but beware that I never tested this on a box directly, so don't blame me if your system does not start back again
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines