Jump to content

jock

Members
  • Posts

    1811
  • Joined

  • Last visited

Reputation Activity

  1. Like
    jock reacted to svdmk in CSC Armbian for RK322x TV box boards   
    Two same boards but different cpu.
    Rockchip labeled works fine with armbian, multitool and libreelec.
    The board with huawei labeled cpu has the previously described problem, multitool and armbian stop working after a minute.
    Method of switching bootloaders suggested by @jock  works.


  2. Like
    jock got a reaction from fortdevv in Tinkerboard not booting after updates   
    Hello all, bootloader packages have been rebuilt and now upgrades should be fine!
  3. Like
    jock got a reaction from Scott Picton in Tinkerboard not booting after updates   
    Hello everyone, the broken upgrade process is my fault and I apologize everyone for the inconvenience.
    The reason behind the broken upgrade process is the merge of the rockchip and rk322x families, which introduced this regression.
    The problem went undetected because upgrades happens once in a while when there are armbian new releases.
     
    I will address the issue as soon as possible, in the meantime please avoid upgrading to latest armbian version. I will post here when I will be sure the issue is fixed!
     
    Thanks!
     
  4. Like
    jock got a reaction from Sigma7 in CSC Armbian for RK322x TV box boards   
    @KanexMarcus probably your board is a r29 and you need to enable the led-conf7 device tree overlay in /boot/armbianEnv.txt. Unfortunately it is a manual procedure that has to be done manually from the multitool.
  5. Like
    jock got a reaction from KanexMarcus in CSC Armbian for RK322x TV box boards   
    @KanexMarcus probably your board is a r29 and you need to enable the led-conf7 device tree overlay in /boot/armbianEnv.txt. Unfortunately it is a manual procedure that has to be done manually from the multitool.
  6. Like
    jock got a reaction from tinker in Tinkerboard not booting after updates   
    Hello everyone, the broken upgrade process is my fault and I apologize everyone for the inconvenience.
    The reason behind the broken upgrade process is the merge of the rockchip and rk322x families, which introduced this regression.
    The problem went undetected because upgrades happens once in a while when there are armbian new releases.
     
    I will address the issue as soon as possible, in the meantime please avoid upgrading to latest armbian version. I will post here when I will be sure the issue is fixed!
     
    Thanks!
     
  7. Like
    jock got a reaction from pakos96 in CSC Armbian for RK3318/RK3328 TV box boards   
    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.
     
  8. Like
    jock got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards   
    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.
  9. Like
    jock got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards   
    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.
     
     
  10. Like
    jock got a reaction from RaptorSDS in CSC Armbian for RK322x TV box boards   
    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.
     
     
  11. Like
    jock got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards   
    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
  12. Like
    jock got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards   
    @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.
  13. Like
    jock got a reaction from ochentay4 in Can't boot MULTITOOL on OTT MXQ 4K (not Pro) RK3229 box   
    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
  14. Like
    jock got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards   
    @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.
  15. Like
    jock reacted to svdmk in CSC Armbian for RK322x TV box boards   
    That's right.
    I use multitool only to erase internal flash and then use rkdeveloptool to flash loader and image as it is described in first page.
    The device boots from sdcard in both cases, blank or flashed emmc but if there is a proper partition on internal flash Armbian works right, otherwise turns off(I heve tried to erase emmc and create partition with fdisk tool in Armbian, and OS works properly ). Armbian boots from internal flash too.
    I think booting issue and turning off after minute are two different cases. Turning off probably is some kind of interaction between RAM and EMMC into EMCP chip itself(kingston 08emcp08-el3cv100).
    This is dumped android firmware:
    https://drive.google.com/file/d/1ZLl-KCvGS47SAO8tY1YDvCHDv6YWIWRP/view?usp=sharing


  16. Like
    jock got a reaction from ochentay4 in Can't boot MULTITOOL on OTT MXQ 4K (not Pro) RK3229 box   
    hmm, this is the commit that should have included the fix, but I made a quick diff and I could not find trace of the fix in the compiled u-boot dtb, so perhaps the fix didn't apply at all. Need to check better when I have more time, I hope I have the still the patch around.
  17. Like
    jock got a reaction from ochentay4 in Can't boot MULTITOOL on OTT MXQ 4K (not Pro) RK3229 box   
    Nope, they are not useful. To identify the issue I need the serial logs from the board UART when you boot multitool to understand the reason why it does not proceed.
     
    Did you try to burn a second multitool on a USB stick, plug both the sdcard with multitool and USB stick with multitool and see if it boots?
  18. Like
    jock got a reaction from ochentay4 in Can't boot MULTITOOL on OTT MXQ 4K (not Pro) RK3229 box   
    Hello, which one is your device? And no, MXQ 4K market name does not help at all, you have to open the tvbox and look for the name printed on the board PCB.
     
    What you can do to is:
    * downloaded and try the latest multitool
    * take photos of the board (both sides)
    * provide the output of the serial log for the failing condition
     
     
  19. Like
    jock got a reaction from ochentay4 in Can't boot MULTITOOL on OTT MXQ 4K (not Pro) RK3229 box   
    I perfectly remember the change @ilmich did on libreelec to fix your use case, but I applied to same fix to multitool and it didn't work, so without logs it is impossibile for me to guess what is the problem with multitool and your board.
  20. Like
    jock got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards   
    @audio kees if your need is just play video at 4k you probably won't go with armbian but rather with libreelec; if your goal is playing music you'd probably want to go with volumio either. Armbian is suited mostly for linux desktop replacement and server-like tasks.
    Said so, tv boxes are the worst choice around in any case, especially if you choose among the lowest budget.
    Much better if you go with properly supported Single Board Computer (SBC) and, as said, you'd better take a look to what libreelec suggests as preferred hardware (probably Raspberry Pi) if you want/need an out-of-the-box working system.
     
     
     
  21. Like
    jock got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards   
    From the datasheet it seems interesting, but no, never seen such chip and never seen a driver for it
     
  22. Like
    jock got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards   
    @audio kees Perhaps you can install armbian in eMMC and libreelec from sdcard/USB stick. It will work because armbian bootloader is capable of booting from several devices; altough it is quite strange libreelec bricks your board.
  23. Like
    jock reacted to fabiobassa in CSC Armbian for RK322x TV box boards   
    @audio kees
    you need the most simple and stupid usb keyboard, not sofisticated ones nor wireless because of lack of drivers in multitool that has a very basic kernel
    If you haven't one ... grab from a friend

    remember.. kiss !!!  keep it simple (and) stupid
  24. Like
    jock got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards   
    @audio kees did you try to press "Enter" on your keyboard?
  25. Like
    jock got a reaction from Alex ThreeD in CSC Armbian for RK3318/RK3328 TV box boards   
    @pakos96 attached to this message there is a script that does the trick to change the ddrbin frequency.
    Can be used on the boot block device directly on the board, or on a file to modify a ddrbin binary or an armbian image before sdcard burn.
     
    Usage and examples are in-built with the script, so launching it without arguments provides all the help that could be needed.
     
    Some notes:
    THIS IS AN EXPERT THING. If you're not an expert, do not do this; do not come here later sobbing you made a mistake, or you will receive more insults that will make you cry even more 🫣 always always always test the ddrbin frequency change on a system booting from sdcard if there is a bootloader installed in eMMC, it has priority: changing the ddrbin on sdcard won't have any effect until you clean the eMMC (or the bootloader) some boards (notably X88 Pro) do not like ddr frequencies above 330MHz: they won't boot changing the ddrbin frequency of the bootloader in the eMMC is very dangerous! You may brick the board (only way out: maskrom via eMMC clock pin gating)  
    ddrbin-switch-freq.sh
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines