Jump to content

jock

Members
  • Posts

    1804
  • Joined

  • Last visited

Other groups

Contributor/Maintainer

Recent Profile Visitors

12156 profile views
  1. @AndrejM please read the first post of this thread, and prefer an updated image rather than an old one
  2. Nope, because what works on your sample is not guarenteed to work on others. Overclock is just meaningless on these chips, you only lose stability and get higher temperatures for a very little increase in performance.
  3. because the android stock bootloader allows to boot from sdcard if you package the bootloader on sdcard using the rockchip proprietary tools. The android stock bootloader is loaded first (because it is on emmc), but then it check for specific bits on sdcard; if found, it passes control to the sdcard Multitool and libreelec image bootloaders are made with proprietary tools, instead armbian uses a bootloader made with opensource u-boot tools and thus is not recognized as a boot device from stock bootloader. Mainline u-boot supports dtb overlays, USB and PXE boot - in addition to other basic features - that are not supported in stock android bootloader. To test the image before burning it on eMMC: if you burn an image that does not boot, you may soft-brick your board and then it would be required to short eMMC clock pin to enter maskrom mode and clean the eMMC flash to restore functionality. If you have a R29, R2B or H20 board, led-conf7 overlay is essential to get stable operation. Here is a post on how to activate it manually via multitool on eMMC or plugging the sdcard in your PC and editing the file (ignore the part on copying things around, they are now already in place).
  4. @mocarela Yes, it is possible to boot from sdcard, but you need first to: erase the eMMC, so the SoC will attempt to boot from sdcard, or install armbian on the eMMC, whose bootloader gives priority to sdcard, then USB, then eMMC Also Rockchip SoCs always attempt to boot from eMMC, if they find a valid bootloader.
  5. @mocarela this is the reference thread for rk322x Your board probably is a r29, r2b or h20 of some sort. Once installed, you have to login, run rk322x-config and select led-conf7 when appropriate. Reboot and you should get HDMI.
  6. Nope, because this is a very specific problem of tvboxes; regular single board computer users and maintainers don't have to mess with such unknown variables. That is the main reason why tv boxes, along the funny and always changing hardware they carry, are not and will never be officially supported by armbian, but just by community members.
  7. It looks to me way too complex from the maintenance point of view: users may create unwanted mixtures installing things from the multitool over already installed systems (for example 24.02 bootloader on an older armbian release); and also when armbian advances I have to keep the multitool binaries updated as well. It is already very tiring keeping the thing aligned against mainline kernel on every release I don't want to add another burden. One thing that solves all the boot problems is to reintroduce the OPTEE trust os: it surely does not unwanted things in the background, but then we lose some useful features. Otherwise I would keep the "manual" procedure for the time being for the problematic boards, until I get the hands on one of them and can study the issue with detail, or some bright idea pops out.
  8. Yes they are "normal" errors: the brcmfmac driver probes for such firmware files, does not find them and proceeds with other filenames. It just reports what is an information as an error, and also does not report that it finally found a valid firmware file. brcm4334 chip has no clm_blob binary; AFAIK only newer/bigger broadcom chips have it, but older chips like 4330/4334 don't have and don't need it.
  9. It is not possible unfortunately. The bootloader is built and packaged by armbian scripts, it is not supposed to have two different boot loaders for the same "board". Once the deb package with the bootloader is downloaded, it is unpacked and a script is run to upgrade it. The only thing I may think about is a flag somewhere on the filesystem that is checked by the script and avoids the real bootloader upgrade. Or people can manually do apt-mark hold linux-u-boot-rk322x-box-current to avoid the bootloader upgrade and that's it
  10. The problem with this is that on next bootloader upgrade via apt upgrade, any custom solution will be wiped away and being overwritten by the regular bootloader. I can reinstate the opensource optee as Trust OS, which seems to be more compatible, but we lose DDR clock scaling - that increases a lot the general performances - and virtual poweroff from the closed source rockchip Trust OS. Which one to choose?
  11. @svdmk ok so that gpio-poweroff is a leftover or some copy/paste from another board done by the manufacturer. The more I read the more I think it is related with the trust os: when you leave the first 8192 sectors from armbian 21.02.1 on the eMMC, you actually leave all the boot pieces there. The boot process is made of 4 pieces: ddrbin, u-boot SPL, Trust Os and u-boot. Rockchip devices always boot from eMMC first, so whatever you put in the sdcard, the boot process always happens in the eMMC, then u-boot steers to the sdcard. My best guess for your problem is that armbian 21.02.1 bootloader still had OPTEE opensource Trust OS I was using in the past (see here for source code); it is the same base that also rockchip uses for its Trust OS, but rockchip proprietary trust os has some closed-source code that is added on top for added features like DDR clock scaling and virtual poweroff and who knows what else... Nowadays I use the rockchip proprietary optee for those added features, but very seldom it causes issues like yours and it is impossible to debug because it is closed source. What you can do in the meantime, hoping it works install armbian 24.02 on the emmc via multitool using the regular burn to image function then get a shell and do a dd to copy the bootloader from armbian 21.02.1 image over the 24.02 u-boot and Trust Os are "packaged together". The package starts at sector 0x200 AFAIR and is around one megabyte large, but I suggest to you to copy all the bootloader that starts at 0x20 A command like this would do the trick: (of course change armbian21.img with the actual image) dd if=armbian21.img of=/dev/mmcblk2 skip=32 seek=32 count=8160 sync Or, if you have the .xz compressed image: xz -c -d -k armbian21.img.xz | dd of=/dev/mmcblk2 skip=32 seek=32 count=8160 sync Then you should be able to boot multitool, libreelec and armbian from sdcard and also armbian should boot from eMMC without issues. I will have some confrontation with @fabiobassa and @ilmich to see if there is a viable general solution.
  12. it's a bit of choosing among liquid shit, solid shit or dry shit.
  13. It is not just your opinion that they are poor quality, it is well known they are poor quality. You can't expect quality from cheap 20$ chinese boards, whatever manufacturer, brand or version you look for.
  14. Hello, I had a feedback from @ilmich and now I'm back with a couple of device trees you can test on the multitool and see if they change something. I'm not sure they will fix your issue, because it may be necessary to recompile u-boot too and that would cost me a bit more time to setup the whole thing, but in the meantime you can try these two dtbs overwriting rk322x-box.dtb in extlinux folder of the multitool. Try both of them and tell me if any (or both) do have any effect rk322x-box.dtb.2 rk322x-box.dtb.1
  15. @svdmk Thanks for posting the photos and the firmware! I took a look to the device tree and found something that could be somehow intersting. I'm not absolutely sure it may be related to your issue, but there the device tree contains this gpio switch which is not usual: gpio_poweroff { compatible = "gpio-poweroff"; gpios = <0xb3 0x11 0x01>; status = "okay"; }; it maps to gpio3 bank and pin 17 (PC1, in the rockchip documentation). That string says that the pin is active low, it means that when it is 0, the poweroff is active; when it is 1 the poweroff is inactive. I may assume that gpio pin is used by the operating system to power off the system. On other board that pin is not mapped in the device tree, so I may also assume it is not used anywhere. In your case may (or may not) be related to the weird behaviour you're experiencing. With this command (to be run as root), you can see how the pins is configured. In my case, the pin is set to output at 0 level, but since it is not wired on my board it just does not do anything. Could you please execute the same command on your board? # grep 'gpio3-17' /sys/kernel/debug/pinctrl/pinctrl-rockchip-pinctrl/pinconf-pins pin 113 (gpio3-17): input bias pull down (1 ohms), output drive strength (8 mA), pin output (0 level) You can also control that pin: # cd /sys/class/gpio # echo 113 > export # cd gpio113 # cat direction in # cat value 0 # echo out > direction # cat direction out # echo 1 > value # cat value 1 # echo 0 > value # cat value 0 with echo 113 > export you will make the pin available for userspace, then a directory gpio113 will spawn and you can echo to direction and value to change the pin as input or output and switch levels. If the pin is actually wired to something, it may be that when you switch direction of level the board may suddenly turn off. Now you can also do another test: erase the emmc and verify you still have the shutdown issue. If that is the case, it may be interesting to see what is the pin state in that condition and if switching its condition causes the weird behaviour to stop or does not change anything.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines