-
Posts
1847 -
Joined
-
Last visited
Reputation Activity
-
jock got a reaction from Ikesankom in Tinkerboard not booting after updates
@Ikesankom hello, no I didn't test it yet. Actually, I have been busy with other issues and totally forgot to test for the upgrade path.
If you have a bit of patience I may give it a shot in the next few days, probably tomorrow.
-
jock got a reaction from Ikesankom in Tinkerboard not booting after updates
Ok then I would first try with a pristine image on a different sdcard if possible, just to understand if the problem is the sdcard itself or something messed up in the kernel
-
jock got a reaction from Tudor Dobrota 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
-
jock reacted to SteeMan in 20USD 4GRAM RK3528 host (cheap dq08 tvbox)
They aren't officially supported, but there are many TV boxes that are Community Maintained and available on the Armbian download page.
No need to remove the binaries, your warnings are good enough.
-
jock got a reaction from ulumid in h96 max 8k ultra hd rk3528 dtb dump
@Hqnicolas thanks for the instructions, but I already have a backup of my box I had taken with multitool.
The problem that is puzzling me is why the box does not boot from sdcard when the emmc is empty, something which is absolutely normal for other rockchip devices.
-
jock got a reaction from fedes_gl in h96 max 8k ultra hd rk3528 dtb dump
i have one of those boards, the silkprint on the PCB says RK3528_DDR3, that's the one I used to bring up the mutltool for rk3528.
A major "problem" I have it is that the board does not boot from sdcard when the eMMC is blanked. I had no time to understand what is the reason behind. Though it should boot when a bootloader is available in eMMC.
-
jock got a reaction from Netraam31 in CSC Armbian for RK3318/RK3328 TV box boards
@Netraam31 I did a quick check on a board with rk3328 (not rk3318, but should be the same) and you can use both the USB2 OTG port or the USB3 port as peripheral.
in the device tree the device usb@ff580000 is the USB2 OTG port controller and usb@ff600000 is the USB3 port controller.
I quickly tried ethernet gadget to check if it works. This command loads the USB ethernet gadget module. which is a bit of "deprecated" in favor of configfs, but it is handy for tests (run it with the USB cables connected):
modprobe g_ether iSerialNumber=0x00000001
Then a device usb0 should spawn on both the machines, which is nothing more and nothing less than a regular network interface. You have to give an address to both the endpoints and then you should be able to ping and exchange data.
The result is that, at the current state of the kernel 6.1 I have right now (but 6.6 is exactly the same, since nothing changed), the USB 3.0 port is working plenty well, instead the USB 2.0 port is suffering the same problems experienced for rk322x, which disconnection and system freeze.
Things seems to have changed with kernel 6.8, where also the USB 2.0 ports seems to work, thanks to the upstreamed fix for clock gating. You should be able to upgrade to kernel 6.8 installing the linux-image-rockchip64-edge package or, more appropriately, via armbian-config.
Don't forget to put kernel and dtb packages in hold if you modify them manually, otherwise updates will overwrite your modifications!
-
jock got a reaction from Netraam31 in CSC Armbian for RK3318/RK3328 TV box boards
@Netraam31 hello! You're in the right direction, dr_mode="otg" simply can't work without a micro/typec usb connector. The main feature of the OTG port is the capability to switch on the fly in host or peripheral mode, but to do that a fifth pin in required. Regular USB-A ports have only 4 pins, so when you get them you surely cannot exploit the OTG feature.
The USB port is still called OTG because it is "dual role" (host vs. peripheral), but simply cannot switch automatically, hence you have to change it in the device tree.
Finally what is true for the rk322x is true also for rk3318: during my tests the peripheral mode was not behaving correctly without disabling the clock gating and adjusting the core reset timing. The clock gating issue has been fixed in kernel 6.8 (the patch addresses the issue on 6.6), but the reset timing can still give some trouble.
Mass storage mode was my testbed, along ethernet emulation; what is still not working at all is the audio gadget which, I guess, uses isochronous mode which is still buggy.
Anyway you surely have to set the OTG port as device mode you have to use dr_mode="peripheral" in the device tree. On rk322x there is a quick device tree overlay to do that, without editing and fiddling with details. I don't remember if there is a similar overlay for rk3318/rk3328, but I guess not.
Notice also that you will not see any USB device connected on the other side when USB2 port is in peripheral mode until a gadget is set up.
There are several guides around (especially for raspberry pi) on how to setup a gadget, you can use them to actually test the port.
-
jock got a reaction from fabiobassa in CSC Armbian for RK322x TV box boards
@moddien Why did you try to burn the image in the eMMC without being sure it would have worked?
If you can boot multitool again, clean the eMMC and start fresh.
I have prepared an armbian bookworm image with opensource optee in place of the proprietary one, you can download from here; I have not tested it at all, so can't guarantee it works.
If you want to try it, first clean the eMMC with multitool and then try to run the image from an sdcard to see the outcome.
-
jock got a reaction from moddien in CSC Armbian for RK322x TV box boards
@moddien Why did you try to burn the image in the eMMC without being sure it would have worked?
If you can boot multitool again, clean the eMMC and start fresh.
I have prepared an armbian bookworm image with opensource optee in place of the proprietary one, you can download from here; I have not tested it at all, so can't guarantee it works.
If you want to try it, first clean the eMMC with multitool and then try to run the image from an sdcard to see the outcome.
-
jock got a reaction from fortdevv in Tinkerboard not booting after updates
@fortdevv you're welcome and thanks for reporting 👍
-
jock reacted to SteeMan in Tinkerboard not booting after updates
@tj13You get details by hooking up a USB uart adapter and reading the serial console output of the boot process.
-
jock reacted to 송호상 in CSC Armbian for RK322x TV box boards
Hey, @jock! After selecting led-conf7 (R29 MXQ, R2B MXQ, H20) in rk322x-config, the screen was displayed immediately without the need to boot from the SD card. Thank you for helping me install Armbian on my tv box.
-
jock reacted to Igor in CSC Armbian for RK322x TV box boards
Temporarily network maintenance issue at that segment Sadly can't fix remote. Tomorrow...
Wrote on mobile
-
jock got a reaction from moddien in CSC Armbian for RK322x TV box boards
@moddien thanks for the firmware, I will try to inspect as soon as possible.
Usually the first page of the thread and the last 3/4 pages are enough to get up to date with recent developments.
Many useful experiences are scattered through the thread, but usually the most important things are collected in the first page.
-
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.
-
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!
-
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!
-
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.
-
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.
-
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!
-
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.
-
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.
-
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.
-
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.