jock
-
Posts
2170 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
hardware video decoding is still a complex beast, mostly because ffmpeg is still missing the necessary bits which are available as separate patches.
v4l2m2m is not the right codec: those are suitable for stataful decoders (rpi and amlogic), but rockchip has a stateless decoder and you have to use v4l2_request decoders.
I'm currently working on bringing a ubuntu and debian apt repository which should ease the pain with ffmpeg. It is in an early state and works better in debian bookworm rather than ubuntu jammy currently. I would not disclose the repository yet because it is very early and hosted in my personal lan, but if you're interested in give it a chance I may give you some instructions via private message.
-
@gpsvitor perhaps your multitool copy is an old version. Download a new copy from the first page of this thread
-
51 minutes ago, Ben Voutour said:
and can you make it so that the composite video and audio actually work on ntsc/pal 720x480 and 720x576?
No chances you ever get that working if there's no driver. And there's no driver, unless you want to write it.
-
3 hours ago, Energokom said:
grey screen and nothing works
so is life 🤷♂️
-
6 hours ago, NiTr0 said:
how LED behavior can be changed? are they blinking by some script/binary, or?
https://linuxreviews.org/HOWTO_Control_LED_Lights
6 hours ago, NiTr0 said:also, question about DDR/eMMC settings - when they're applied, and how device can be crash-recovered if settings are wrong (boot button should work, or only resistors shorting will help)?
They are not applied at level of ddrbin, but the DMC driver is loaded by kernel; in case you're stuck and your system does not boot anymore, you can always boot via multitool, mount the rootfs partition and remove the ddr3-* overlay in /boot/armbianEnv.txt to restore the default.
6 hours ago, NiTr0 said:and what is default DDR freq - 300MHz, or 600MHz? I looked up into factory dts and there was 600MHz frequency; but in rk322x-config there's no 600MHs option - there are 528 and 660 MHz...
Default frequency is 333 Mhz and is defined in ddrbin. Armbian is not the stock firmware, hence the factory dts is absolutely not applicable here and would lead you to misunderstandings.
-
2 hours ago, NiTr0 said:
small question: how to check (and change) GPIO pin assignment? currently I have only dark red light; it seems like it's looks like GPIOs mismatched.
I've extracted and decompiled DTS from original firmware, but at first quick look I can't see pin assignments here - maybe I'm hav no enough experience...
DId you already run rk322x-config and select the proper led-conf gpio preset for your board?
There are several presets to chose from depending on the board signature and design; if you don't find any match perhaps your board is new and would be very nice if you could share high resolution photos of the board front and back, the original device tree and, if possible, the backup of the original firmware.
-
52 minutes ago, Ben Voutour said:
is there a build of Trixie for this system?
Nope, but I think you can install bookworm and then upgrade to testing repositories.
armbian repositories should stay with bookworm though
-
@NiTr0 in fact it is very strange, and I may guess there's a bug somewhere in the armbian building script.
Also running ./compile.sh ARTIFACT_IGNORE_CACHE=yes that forces uboot and kernel being rebuild still produces images with v1.10, despite the bootloader package u-boot-rk322x-with-spl.bin has v1.11 in it. 🤔
-
24 minutes ago, hexdump said:
@jock - that not booting with a clean emmc reminds me a bit on the rk3328 box i have which has the sd card connected to the wrong mmc port and thus cannot boot from sd card - it works with a workaround to install some special u-boot in emmc which then boots from sd card via extlinux.conf or boot.scr ... can it be that those rk3528 boxes are similar?
It could indeed be, looking at the rk3528 device trees, it has 4 mmc controllers as like as rk3328.
Looking in the vendor kernel 5.10, I can guess that the "right" mmc controller for the sdcard is the 4th (mmc@ffc30000), and this matches my board device tree; nonetheless the board refuses to boot from sdcard when internal flash is empty.
-
@gpsvitor you clearly need to go in maskrom mode shorting the emmc clock pin to ground.
You installed armbian on emmc without testing first on sdcard, which is something I always suggest to do.
Perhaps your board has 1.5gb of ram like @NiTr0's one?
In such case you will need an image with an updated ddrbin, which is the component failing in your situation.
If you get in maskrom mode, just erase the flash; don't try to reinstall any armbian image because they will all fail and wait for an updated image.
-
4 hours ago, NiTr0 said:
unfortunately they're built with ddrbin 1.10...
I tried to built images with ddrbin 1.11 (I placed it into blob and changed config/sources/families/rk322x.conf) but got image with ddrbin 1.10 for some reason - maybe there's cached intermediate results?
Oh right, you still need the v1.11
There are some caches around, but should not affect the bootloader which is always rebuilt from scratch AFAIK.
Will double check soon, stay tuned!
-
6 hours ago, Ben Voutour said:
i'm testing dietpi 8.23
Which are known to "steal" the work of others without giving credits and support.
That's the best way to kill armbian project 😒
-
@Rodrigo Campos hello; I don't think HDMI stopped working, but instead something went wrong with xfce installation via armbian-config.
Honestly, I never try to install a desktop enviroment via armbian-config, but instead I usually build and use images with xfce already installed.
Some fresh debian and ubuntu images have been built by armbian servers just yesterday: https://imola.armbian.com/dl/rk322x-box/archive/
You may want to give a chance to them perhaps? They are still command-line only, but maybe they work better.
In case they don't work, maybe you could post on this other forum, since I guess it is a userspace issue.
-
51 minutes ago, Ben Voutour said:
could you tell me if there is a working memory oc with working trust blob and get my cpu to hit 1.5 GHz (It has a nice cooler on it already.
don't know, I don't care about overclocking
52 minutes ago, Ben Voutour said:is there a higher verbosity other than 10?
No, maximum is 7
32 minutes ago, Ben Voutour said:should i use a 5v 5a power brick?
no, it is useless
-
11 hours ago, Ben Voutour said:
the system has a 1,296 MHz clock but i assume that the ddr clocking is default...
can it be overclocked further?
i have a fan and heat sink on the cpu
the power supply is a 5v 2a D-Link Power Supply (Wall Brick) (Hardwired to PCBA)
the case is gone in favor of open board design
the cvbs+Analog Left/Right is Also Hard-Wired as well.
the issue is atm i'm on bookworm (6.6.1) (Nightly) and my LED Clock is Not Working...
And Yes, I'm Back again
Hello!
If you mean overclock the cpu, it depends on your sample. rk3318 are rated for 1.1ghz, for so far it looks like a software limitation rather than a hardware one. Some people pushed them up to 1.5ghz, but the increased horsepower is not worth the heat at all IMHO.
About overlocking the ddr, actually they are underclocked at 333mhz: dynamic reclocking requires a proprietary Trust OS blob, but this won't allow CPU to go beyond 1.1ghz. On the other side, booting the device at 667mhz caused many boards to not boot at all (notably X88 Pro 10 market models)
About the LED Clock, if you mean the frontal led panel, there is a kernel driver + userland application which work together; they do the job, but are rather suboptimal for technical reasons and not included into regular images.
-
@Ineptitude unfortunately the driver is not yet included into armbian. I tried to take a quick look to it and there is the usual mess of preprocessor directives to compile and run on the various manufacturer platforms, plus some low general quality code. I gave it some hours for inspection, then I gave up. Perhaps I will give some more love to it sooner or later, but I don't promise anything.
-
10 hours ago, H1H1 said:
From what I've been reading, there's no solution to this so far.
it would require more inspection to understand why your board requires that specific version of the trust, but it is something hard to do without the board at hand 🫤
-
Well, rk3528 are a new thing around; multitool is half-working so far. It is enough to grab a backup in my case.
During my tests and experimentations, I found I was unable to boot from sdcard if the eMMC was completely erased. I would like to understand what is wrong here and why this boot issue is happening, since all other rockchip socs I know do boot from sdcard when the eMMC is empty. This is quite essential for multitool, since it should be a maintenance tool and if it does not boot in maskrom mode it loses half the uses. Anyway in my case it boots fine when the original firmware is installed.
At the moment my experiments go really slow because I'm busy with other things, but I managed to bring up am working rk3528-box config for armbian scripts that produces a working image. It can be found in my personal github repo.
Since rockchip dropped their proprietary miniloader in favor of their proprietary (but open) u-boot, the armbian image should boot fine from sdcard without erasing the internal flash memory first. I don't know if I will keep this behaviour, but for now it is so.
edit: ah, photos are very welcome, but perhaps logs from the serial, original firmware and the original dtb are indeed very useful in this discovery phase.
edit 2: I'm just realizing I never published a working multitool image for rk3528, which one are you using? Did you built one yourself? By the way, here is a build for rk3528 soc, but your mileage may vary a lot: https://users.armbian.com/jock/rk3528/multitool/multitool.img.xz
-
@H1H1 I managed to build another multitool, this time with the Trust OS coming from your image.
I noticed that your trust is one of the "bad" ones, in the sense it forces the box to sleep after a while if there is no activity. It was supposed to bring the box in suspended mode when not in use in Android, so probably after some seconds your box may become unresponsive and screen will go blank. @fabiobassa will surely remember such issue; nonetheless you can try it to see if at least multitool boots. You can download it from here
Also you and @NiTr0 may also give shot to the latest multitool updated with the latest ddrbin v1.11 @NiTr0 has posted in the other thread. You can download it here
@NiTr0 also you may send back feedback if it boots for you, so I may build an armbian image with the updated ddrbin before the official updates
-
18 hours ago, H1H1 said:
@jock I finally managed to extract the firmware. Here's the trust partition https://drive.google.com/file/d/1E7mxBVE1lUshqdcjqTMfxKQMW2iLUvye/view?usp=drive_link. And here's the rest of the backup https://drive.google.com/drive/folders/165r4bV3jFj8Ptx4yY2sXmbmOUOBIMWaW?usp=drive_link. I've been trying to install Armbian via USB cable, but no luck so far, always getting Test device fail. Thanks
It looks like a very old trust, I see version 1.0.1-88 from the binary; currently there's the version 1.1.0-333.
I will try to extract it from the partition and make a custom multitool with the old one!
-
36 minutes ago, Aapo Tahkola said:
Well, the issue with r8152 and probably some other devices like 1000Mbps ethernet adapters and maybe SSDs is that these things have only limited amount of RAM for buffering. If the CPU just isn't fast enough to clear those buffers you are going to get buffer overruns.
More than that, which is something would just affect performance rather than "stability", most of the issues with USB devices are
1) the USB current of the ports on tvboxes is kind of limited. Gigabit ethernet requires a decent amount of current by design, and the USB ports can't always supply the requirements
2) PSU adapters coming with tvboxes are crappy chinese cheap devices as the box themselves. Don't expect great numbers from them despite what their labels say.
A serious SBC with a decent PSU will probably handle anything much better and provide onboard gigabit ethernet
-
-
-
@baryon actually you don't need to take @ilmich's branch 4.4.1, but you can use the ffmpeg 6.0 coming from libreelec's master branch: the package details, it's source and the patches to apply are self-explained in the package.mk file; compilation flags also are in the package.mk, you just need to assemble them "manually"
CSC Armbian for RK322x TV box boards
in Rockchip CPU Boxes
Posted
@Bert Kortenbach Hello; indeed it fails. There's a reason the file is .dtbo and not .dtb: it is an overlay which applies on top of the base dtb.
Restore the original rk322x-box.dtb file exactly where it was and restore also the entry in /etc/armbianEnv.txt.
rk322x-led-conf7.dtbo has to be put into /boot/dtb/overlay directory, and then has to be activated by adding a line:
overlays=led-conf7in /boot/armbianEnv.txt.
Note that rk322x-config script will overwrite the overlays= line in armbianEnv.txt, so you should manually add led-conf7 if you run it