jock
-
Posts
852 -
Joined
-
Last visited
Everything posted by jock
-
You can't take blood from a turnip, as we're used to say in my country. The SoC is very limited in power and browsers are demanding tasks. In general desktop usage, video playing into browsers is quite a challenge and it is software decoded on rk322x (as it is on probably ALL other ARM SoCs). The rk322x is simply not powerful enough to do the task in software. The SoC is very capable to do h.264 (and friends) decoding in hardware, but integrating such hardware decoding into browsers is a very complex task. -
@RaptorSDS The led configurations are not for intended as on/off switches, you should use the one and only that is suitable for your board because the led GPIO pins changes among boards (ie: the leds are connected to different "ports" on the SoC). You have to spot the led configuration that works for your board, or just read the board signature and find a match in rk322x-config proposals. Once you do that, the leds can be controlled independently via /sys/class/leds/working and /sys/class/leds/auxiliary sysfs paths. By default the working led is set to stay always on and auxiliary is set to blink when there is MMC access, but you can change writing into trigger file you find in those paths. Use cat trigger to show the list of possible values that you can write into and search google for documentation.
-
@beretas Can't say anything about upgrade_tool error. I have only one board with NAND and it always worked so far. I asked @fabiobassa to do some tests with his NAND board and AFAIK it worked there too. rkdeveloptool ul with NAND boards often tell you everything went well, but does not always work (on my board it does not do anything). Did you try the other bootloaders available in the instructions post? Do you have any serial log?
-
@elbuit cool, thanks! Your board has a nice ap6255 wifi chip, looks life a fully fledged awesome board! The original dtb is always welcome, as usual if you feel that something is not working as expected report here and we will see what can be done (I suspect bluetooth is the worst offender )
-
Thanks for reporting! rk3318-config script should have been integrated into the image, but I checked and you're right, it's not there! I have to check why the script has not been included in debian image, but in the meantime you can download it from here , give the execution rights and execute it. Could you please post photos of the board? Thanks!
-
If it was not clear enough from the previous post, the only way to enter maskrom mode when the box is bricked is short the eMMC clock pin. The reset button is useless in such case I don't know where you get such template, but indeed it is the wrong one. The right template is this: [CHIP_NAME] NAME=RK322H [VERSION] MAJOR=2 MINOR=50 [CODE471_OPTION] NUM=1 Path1=rk3328_ddr_333MHz_v Sleep=1 [CODE472_OPTION] NUM=1 Path1=rk322xh_usbplug_v2. [LOADER_OPTION] NUM=2 LOADER1=FlashData LOADER2=FlashBoot FlashData=rk3328_ddr_333MHz_v FlashBoot=miniloader.bin [OUTPUT] PATH=rk3328_loader.bin but I really don't understand what are you trying to achieve trying to add up dangerous steps to something that already does not seem to work because of a reason not yet clear enough. If you don't clarify the reason why you have such issues, creating your own bootloader does not solve anything. The most probable issue is that your sdcard is wired differently than normal, so the SoC does not boot from sdcard. Also there is another issue that is the bootloader not responding after being downloaded to the board, which is strange and requires attention too. At last, it is warmly suggested to use the precompiled rkdeveloptool because if you compile from sources you may have issues, so why are you deliberately using a potentially misbehaving software? You may discover something more attaching a serial adapter to the board UART and providing logs (real textual logs, not those annoying screenshot stamps), otherwise it is just walking in the dark where every step is dangerous. edit: this is the dts of your board:dts , your box has SDIO Wifi and sdcard controllers swapped and who knows what other goodies are in this chinese box...
-
Very cool you found those two pads with the eMMC clock pin with ease! Often manufacturers provide such "hidden" debug and test points on the boards (like the serial uart) but it's a matter of experience, knowledge and luck to find them. Could you please post a couple of photos of the whole front and back of the board? The original device would been very helpful to understand if your board has somehow different led/wifi internal wiring, but I understand you lost the original firmware, so it's up to someone else who has the very same board to provide that.
-
It is right that after rkdeveloptool rd 3 you are not able to execute any other command: that's because the board is in maskrom mode. Once there, you must run rkdeveloptool db loader.img to have access to further commands. When done, rkdeveloptool ef will clean the existing data, and finally you need also upgrade_tool binary to finally install the new bootloader in the NAND. This is the procedure to upgrade to NAND bootloader: https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes/page/28/?tab=comments#comment-121103 If you don't install a bootloader, you will never be able to boot from NAND neither the Multitool will detect it.
-
Also disabling the windows compositor from System -> Window Manager Tweaks will indeed give less pressure over the GPU and a bit better desktop experience
-
Not with old kernel, but with proprietary Mali + proprietary opengl driver indeed are. Nonetheless the proprietary driver is somehow buggy and often it causes graphical issues and even crashes. It is indeed possible to run the proprietary things on mainline kernel though, but you need to compile the kernel driver yourself and install the opengl mali libraries manually You're right, but it is possible that the timings are not perfect because nobody checked on such resolution. You can inspect the edid installing edid-decode package and running: edid-decode < /sys/class/drm/card0/card0-HDMI-A-1/edid Paste the result of the command here, along with Xorg.0.log, maybe someone may help you out. Actually I'm now aware of possible bugs for edid retrieval in rockchip64 architecture.
-
Yep GPU performance is not so good, expecially with the opensource Lima driver and mesa code which is not optimized as well as the closed source binary blob. About the resolution issue, I guess that 1920x1200 is not a so common resolution; it's a matter of internal timings that are multiplied and divided to derive the various clocks to get the various resolutions. Often these timings are adjusted to accomodate some resolutions, but break others. I'm no expert at all in this matter and never dig into personally so can't say anything more precise about Had no time lately to look into libreelec patches, maybe there is something useful there.
-
Hmmm, that could really be the issue. I found only boxes using the alternative mmc controller to allocate the wifi chip, but not the microsd slot so far. In such case there is the need for an alternative bootloader and different dtb than the regular image However @Generic_user can burn the Armbian image directly on the internal flash using rkdeveloptool. It's a bit of a hazard though, because if the image does not boot getting maskrom mode back is very difficult Also the dtb of the original image would clarify if the issue is that one.
-
You don't have to convert anything. The extension is purely cosmetical. Maybe you didn't read, but I edited two posts were I clearly declared that the loader file has been updated because the previous one was not working, as long as I also clearly stated that it was untested. I also posted a live usage example, but you didn't read that too. Ok that's not normal, it should not happen. No bootloader in internal flash -> the SoC looks for bootloader on sd -> no bootloader on sdcard -> go in maskrom mode. Now there are four options I may guess about: you did not expand the multitool image or the armbian image, but burned the .xz file as is your microsd is faulty the microsd slot is faulty your board/soc is so special as we never seen any like that
-
@Generic_user I was referring to your previous post where all the commands were failing. When the device is in maskrom mode (but not loader mode), the only accepted command is rkdeveloptool db loader.img. Only after db you can use the other commands, including rl or wr to read and write sectors, or ef to clean the whole flash. By the way, did you try armbian from sdcard yet? edit: I updated the binary in the previous post because had the chance to test it and it was not working; the new version instead is working: paolo@predatorg:~/Scrivania/rk3318-loader$ sudo ./rkdeveloptool rd 3 Reset Device OK. paolo@predatorg:~/Scrivania/rk3318-loader$ sudo ./rkdeveloptool db rk3328_loader.bin Downloading bootloader succeeded. paolo@predatorg:~/Scrivania/rk3318-loader$ sudo ./rkdeveloptool rid Flash ID: 45 4D 4D 43 20 paolo@predatorg:~/Scrivania/rk3318-loader$ sudo ./rkdeveloptool rfi Flash Info: Manufacturer: SAMSUNG, value=00 Flash Size: 14910 MB Flash Size: 30535680 Sectors Block Size: 512 KB Page Size: 2 KB ECC Bits: 0 Access Time: 40 Flash CS: Flash<0> paolo@predatorg:~/Scrivania/rk3318-loader$ sudo ./rkdeveloptool rci Chip Info: 48 32 32 33 32 29 82 E 21 42 6A 88 78 0 8A 89 paolo@predatorg:~/Scrivania/rk3318-loader$ sudo ./rkdeveloptool rcb Capability:07 00 00 00 00 00 00 00 Direct LBA: enabled Vendor Storage: enabled First 4m Access: enabled Read Com Log: enabled
-
I extracted the bootloader part (usually called MiniLoaderAll, or similarly way) from an original image. This file can be used with rkdeveloptool db when the device is in maskrom mode to load the initial loader that allows the other commands to work. Your mileage may vary, it did not test it at all. If you have a serial adapter attached to the UART you can also read the log messages that the thing is reporting. edit: updated the binary bootloader with a working one rk3328_loader.bin
-
Ok, mainline kernel images have been updated, hopefully lightdm should be fixed from upstream Ubuntu and Lima driver + 3d acceleration is back in town! I suggest however to disable the compositor from Windows Manager Tweaks menu and enabling show on window dragging for faster desktop experience.
-
@kruzer You were right there was an issue with the dtb also. Mysteriously it was missing the gpu operating points table. I'm building new images right now, hopefully X.org will works without issues anymore.
-
Yes @kruzer , the right memory map size is 0x30000. As stated by rockchip documentation, the memory mapping for the gpu device is 192kb in size (0x30000 in hex). Setting it to 256kb (0x40000) overlaps the rkvdec device, hence the error in dmesg. Note that actually the Lima acceleration is disabled in a X.org .conf file. Look for 40-serverflags.conf in /etc/X11/xorg.conf.d, and change AccelMethod option from "None" to "Glamor" to enable it. I disabled the Lima 3D acceleration for two reasons though: 2D is less reactive, as once @usual user explained, modesetting X.org driver is not suited for embedded SoC which have to share buffers between subsystems the X server was not starting at all, but this could be a problem due to lightdm-gtk-greeter issue
-
@ArkhanLK I confirm that slick-greeter is a much better choice, X.org now works and I'm able to login finally!
-
That won't be useful unfortunately. That particular bootloader is only available in the original firmware upgrade images. Maybe @hexdump has some of them. Try first the images from the post @hexdump already gave you. They are specifically for rk3318.
-
@Generic_user If you correctly erased the whole eMMC, when you plug the USB cable in the OTG port it should automatically bring you into maskrom mode without the need to push the reset button with the toothpick. Also consider that if the eMMC is empty, the board should automatically use the sdcard as boot device, so first try to put the Multitool image and see if it boots, if it does not work, try also burning the Armbian image on the sdcard and see if it boots. If you compiled rkdeveloptool yourself, consider using the rockchip provided one, I had severe problems with the version compiled by me, but did not investigate the causes. Reading the partition table is not really useful, to make a full backup you can just use the rl command, specifying sector 0x0 as start and calculating the whole size of the eMMC in 512 byte sector as length. This is explained in the rk322x post mentioned before. To clear the eMMC use rkdeveloptool ef command; it should not fail to be sure the eMMC has been cleared. If the eMMC is clean, the only rkdeveloptool command that will work is db. Db command uploads a minimal bootloader that enables other commands: you need a bootloader blob which, at the moment, I don't have as it needs to be built from rockchip blobs or extracted from an original firmware upgrade. If you have the original firmware/upgrade provided directly by the manufacturers, this is the right time to point it out. If rkdeveloptool refuses to execute any command and lsusb tells you the device is in maskrom, probably the eMMC is just clean, so you should be able to boot from sdcard using multitool or armbian image directly.
-
Hello @Huafu, the memory amount is normally autodetected: first by the rockchip blob (the ddrbin) that does the very first SDRAM initialization and then by u-boot. Now I didn't change any bits in the u-boot code, but it may be that, for a reason or another, the rockchip blob is not able to detect the whole amount of memory. The only way to know if the memory is correctly detected is read the serial output with a serial adapter. You can however post a dmesg log here, but I guess it will just say that you have 2gb of ram and that's all. Another thing that could be useful is the first megabyte of the original firmware, where the ddrbin is stored. Now we are using version v1.15 which turned out to be stable and compatible, but it could be that your board has a different memory arrangement that require a different version (I think it is a remote chance, but never say never ...)
-
Yeah I wanted to mention in the previous post but I forgot! However today had access to the box and it was still not logging in. I'll check further later, but this lightdm thing is very annoying Uh, to be honest I never tried armbianmonitor -v. Actually the packages installed by media framework are "overwriting" those from armbian/ubuntu, I don't really know how armbianmonitor -v reacts to. rk3228b and rk3229 are enabling exactly the same overlay, which brings the cpu to 1.4ghz, nothing else. emmc overlay enabled the ddr mode for eMMC and some other configuration bits. eMMC, sdcard and Wifi share the same subsystem since they are all controlled by mmc controllers, so it is very possibile that a malfunction/misconfiguration on eMMC reflects also over Wifi; usually badly designed boards do this. Usually it will work fine even if the board is slightly different; you can however clone the thing and, if it boots, run rk322x-config to reconfigure the overlays for the other board
-
@ArkhanLK I made some further investigation and it seems that lightdm-gtk-greeter is the great offender: the package in Ubuntu Focal seems to be broken for armhf architecture: https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1897491 I just tried to install the lightdm-autologin-greeter and uninstall lightdm-gtk-greeter and, after a reboot, it looks like it works: apt install lightdm-autologin-greeter && apt remove lightdm-gtk-greeter If apt is lamenting issues about armsoc, that's because of a previous package upgrade. I don't know why, but it tries to install armsoc-exynos as a dependency of Kodi. It is unclear to me why it tries to install packaged Kodi instead of keeping the one from media-framework, but probably I made some mess with versioning. However, to try to get back the media framework situation, first uninstall the wrong armsoc driver: apt remove xserver-xorg-video-armsoc The install the media framework packages manually: apt install armsoc/*.deb apt install kodi/*.deb apt install ffmpeg/*.deb And finally mark the packages as hold, so apt upgrade won't try to update them: apt-mark hold xserver-xorg-video-armsoc apt-mark hold kodi kodi-addon-dev kodi-bin kodi-data kodi-tools-texturepacker apt-mark hold ffmpeg libavutil56 libpostproc55 libswscale5 libavutil-dev libpostproc-dev libswresample3 libavresample4 libswscale-dev libavcodec58 libavcodec-dev libavresample-dev libavformat-dev libavfilter7 libavfilter-dev libavdevice58 libavdevice-dev If you start from a fresh system, just run the apt-mark hold commands after installing the media framework and you should be fine enough. This is not exactly tested, because I'm headless right now, so if you feel comfortable enough, it may be a wise idea to start from a fresh system. I will update the media framework in the next days to include the apt-mark commands automatically, so this further step won't be needed. edit: ah, another thing about /etc/X11/xorg.conf.d directory... The stable image from the download page include 40-serverflags.conf file which should not be there! Curiously a freshly built image by me instead does not include that file, which should be there only on mainline images... so please delete it. I will ask the high towers what happened, maybe fix the lightdm greeter thing and ask for a stable image rebuild.
-
Isn't it possible to use short the eMMC clock pin to ground, boot from sdcard, then erase the eMMC to start fresh?