jock
-
Posts
2075 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
1 hour ago, primoitt said:
So I guess there is a problem with focal release?
🤷♂️ perhaps; the branch is at an old period in time and has not been updated anymore, so anything could be...
-
Hello @primoitt , yes it has been deprecated. It wasn't developer anymore, now has been fully removed.
You can find the latest iteration with the legacy kernel for rk322x family on this branch. After that, rk322x and rockchip familes have been merged and legacy kernels removed because old and unmaintained.
The main reason to keep legacy was raw NAND support, but we at last we decided it does not worth the effort to keep it.
-
12 minutes ago, suser said:
I have few USB dongles working, bough for 1.5EU each, it was not a matter of money, nor WiFi desperately needed. It's was a matter of "make things working" or at least "to know why it is not working". Thanks everybody here, you are such a talents !
i perfectly understand, I also hate when an available piece of hardware cannot be used, but really lost a lot of time in wifi drivers and, especially realtek drivers, need constant care because they are overbloated software written by simians.
When complied, any realtek driver is few megabytes large, while the average wifi driver is well below the 100kbytes.
The device id you see in rk322x-config 024c:8723 is clearly declares that your chip is rtl8723as (for some other references: https://forum.libreelec.tv/thread/27091-no-wifi-at-mxq-pro-4k-5g/)
-
4 hours ago, suser said:
What should i do about the Wifi ? I can even try to change the WiFi module with another HW...
Hello!
The problem is the missing driver for the rtl8723as. Actually, there is a driver floating around, but adapting and keeping it working on every kernel release require a lot of effort. I don't even have a board with such chip, so it is indeed very difficult, but it may become unworthy of the time spent because realtek drivers are very messy.
You could find the source code and compile it yourself, or perhaps desoldering the wifi module and change the chip with another one is easier!
It would be even easier to attach an USB wifi device.
BTW, in the forum thread there is a success story with rlt8723as driver, you may want to search with forum tools or google.
-
On 5/2/2024 at 4:10 PM, Netraam31 said:
I've now also got overlayroot setup to keep the internal flash mounted as readonly for normal operation. So as to not burn through the flash's endurance counters within a year on a device that's writing logs, status information, etc. to flash continuously. And also to protect it against issues when people just pull the plug while it's operational, potentially corrupting flash and making it unusable without physical recovery. Seems to be working great, but had to adjust the initramfs hook and script files (mount -o move instead of mount --move in script, and adding lines to copy_exec /bin/grep, /usr/bin/stat, and /bin/echo to the initramfs.
Not really needed to do that for wear prevention: armbian is already optimized to write logs in a zram device (so they are kept in ram and compressed on the fly) and also swap space is by default a zswap device.
On 5/2/2024 at 4:10 PM, Netraam31 said:My rk3318 android tv box "H96 Max v11" does have the two red/blue leds on the pcb, but no clock display. There are solder points on the pcb though. Would it be possible to use these pins for GPIO access (maybe even add an I2C RTC module), or would that not be possible within the limits of hardware/firmware? Any pointers on where to start looking, if at all possible?
Don't know, it could be possible if some pins are directly connected to gpios, but for what I know they are connected to another led driver chip which is surely missing on your board, so the answer is probably no.
On 5/2/2024 at 4:10 PM, Netraam31 said:In pikvm config, following generic instructions, I was able to easily add the usb ethernet gadget and do routing/masquerading for the attached device. Yet, when I tried to configure usb mass storage gadget, the result was that the keyboard/mouse stopped responding in pikvm. From the pikvm documentation (unfolding the USB limitations section) it looks like there could be an issue with capabilities of the chip in relation to the number of endpoints needed. Yet, that page mentions mass storage would require 2 endpoints for each msd, and usb ethernet would require 3 endpoints per emulated device. So it's strange that ethernet does work but msd does not. Enabling only one at a time, of course. Is there any data on the number of endpoints available on the rk3318 chip? Or maybe someone knows how to make msd working? Or.. maybe it was intentionally disabled in srepac's kvmd-armbian because it's not working either way? The usb ethernet gadget was disabled in the config as well but works like a charm, so not sure why msd didn't work as expected. Or maybe msd is only supported for the usb3 port and not on the usb2 port that I'm now using for otg connection to the remote? Sorry, too many question marks here... Any pointers would be much appreciated!
I tried msd on the usb2 port for both rk3318 and rk322x socs and it kinda works. The rockchip implementation of the dwc2 IP (the silicon behind the USB2 port) seems to be a bit buggy and the dwc2 driver also seems to be a bit buggy, so the whole thing is a bit buggy. Nonetheless it worked on my side, but had to make some patches for the kernel (see this) that you don't really need if you're running kernel >= 6.8 but definitely if < 6.8. As a note, audio gadget was totally out of reach.
Did not try having two or more USB gagdets at the same time. From the uboot dwc2 driver I'm inspecting, I see #define MAX_ENDPOINT 16, but take it with a grain of salt.
USB3 port seems to work a bit better.
edit: dmesg tells that the 3318/3328 has 10 EPs, so I guess it is an accurate number
-
-
AFAIK, to get fully working 4:4:4 modes, there is the need to import some "experimental" patches that are floating in the rockchip kernel mailing list.
The patches have been tested a lot by libreelec users on various rockchip platform (32 bit rockchip device like rk322x and rk3288 already have them merge in), but have been judged "too complicated to maintain" for rockchip64 repository.
You can see the last attempt here and the previous attempt here, useful to get the points of the discussion.
-
On 4/27/2024 at 8:44 AM, McTurbo said:
Thanks. Just to be clear, that's the rkvdec from staging drivers, right? It overrides hantro for H.264?
Oh and I'm assuming the reason hantro H.264 is disabled is rkvdec offers better performance. Is that right?
rkvdec does not technically "override" hantro h.264: hantro and rkvdec are two totally different devices and both are exposed by v4l2 framework to userspace. It's up to the user application to choose the preferred device. Ffmpeg, which is perhaps the most common user application around, has no way to choose the v4l2 device for h.264. The workaround to force ffmpeg to use rkvdec (yes, because it is more performant) was to avoid declaring hantro as capable of h.264, sto the only left h.264 decoder is rkvdec.
edit: and yes, rkvdec is in the kernel staging directory, plus armbian has a patch to enable h.265 decoding too
-
@im_chc those source code files are irrelevant for the boot issue: the rk322x has a SPI bus where the board maker can connect anything other than a flash memory. Those drivers handle the low level communications along that bus, but whatever is connected to that (a flash memory, a wifi devices, a led strip, a led panel driver, or whatever...).
You need a loader (specifically, the miniloader), which is engaged before uboot and the kernel, which should support reading from the SPI to load u-boot. You also will need u-boot and kernel compiled to read and write to the SPI flash of course, but the first step is the miniloader.
-
@im_chc AFAIK the loader firmwares around do not support anything else than sdcard and emmc, but I may wrong: I have never seen a rk322x device with SPI flash memory, so I can't bet on my affirmation.
Perhaps you should have a look to the rockchip repository on github or search around to see if there is a rk322x loader for SPI memories.
-
@ThaisTaki Hello! I did not remove any particular driver or feature from earlier versions.
Perhaps you were using the older vendor kernel 4.4 in the previous installation? In such case, it is not supported anymore, so some device may have lose support.
Also notice that, depending on your board (I can't read the signature/silkprint on that from the photo), you may have to run rk3318-config twice to enable the correct driver.
-
On 4/26/2024 at 2:18 PM, pessimism said:
One question: When I did the installation, I opted to do a full emmc backup. I am able to see that the resulting (60GB!) image has a GPT and named partitions inside. I attempted to loopback mount them via kpartx and mount, but only a couple out of the 15 partitions will mount. The rest seem to have no recognizable file system. AmlogicKitchen won't work as it doesn't start out as a rockchip packed image like the recovery firmware from the vendor's website. Do you have a script or tool to fully unpack the backups that multitool creates? (for grabbing nvram, firmware, dtb etc.)
Hello!
First of all, multitool creates a 1 to 1 image of the content of the eMMC; no bits are changed and nothing is rearranged in any way.
What you get in the backup is the exact content of the eMMC, some of those partitions are raw partitions that does not contain a filesystem, but rather just raw data. For example the uboot and trust partitions normally contain binary data, so you won't be able to mount them in any way because they are not filesystems. You could inspect with a hex editor though.
-
@Ikesankom sorry, I misunderstood your issue, which is not related to the rest of the thread.
It looks like the kernel does not enumerate the partitions of the USB drive, I just tested the bootloader which is not related at all with your issue.
It is weird though, because I have an rk3288 tvbox which boots from an external hard drive with ext4 partitions without issues.
Could you please post the results of the suggested commands cat /proc/modules and ls /dev/sd* ?
-
-
@Ikesankom I did a quick test jiggling with bootloader to try and test multiple cases with both sdcard and emmc.
I found a little "bug": there is no "alias" for the mmc devices in the device tree, so sometimes at boot the emmc is mmcblk0 and sdcard il mmcblk2, sometimes they get swapped.
Anyway, despite this bug, the installer never broke the existing bootloader, at most it could miss the right device (I should check the logic behind, as it is not so easy guess what is the booting device) if you have both emmc and sdcard plugged. It's not a big deal though: the bootloader has got no real updates in a while since it works fine and the important thing is that the script does not destroy anymore the existing bootloader 😁
Anyway, if the board is remotely installed and controls something important, and you want extra-safety, you can do apt-mark hold linux-u-boot-tinkerboard-current and prevent bootloader upgrades
-
@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.
-
-
@lucky62 looking with elixir, it turns out that the function was already deprecated in 6.6: https://elixir.bootlin.com/linux/v6.6.27/source/drivers/gpio/gpiolib.c#L1022
You could copy the body of the deprecated function in place of gpiochip_find
About of_get_named_gpio_flags you should see if you can afford to use the suggested function
-
@PLaume Hello!
Well, a power loss is a power loss... you won't know what will be gone when the cache is not flushed.
I read from the eMCP the code "JY941" or "JY94I", but according to micron part decoder (https://www.micron.com/sales-support/design-tools/fbga-parts-decoder), that chip does not exist. Perhaps it is a fake chinese chip with "micron" printed on it with unknown reliability?
About the errors, the hdmi "error" is rather an information and does not affect any feature.
The ssv6200 error instead says that the wifi chip does not work because the driver only support ssv6051p chip and not the ssv6256p your board has.
-
@astrosky I can't recommend you an image you can just install and everything works... tvboxes have this little problem about the changing hardware and that's not so easy.
I have repeated dozen of times that tvboxes are not the way to go, buy an SBC if you need reliability.
About 6.6.25 kernel, now I understand that you repeated the procedure starting from 6.6.23 image and this time the board rebooted fine but still without HDMI, am I right?
-
-
Hello, for anyone who is having difficulties with HDMI, I made an experimental 6.6.25 kernel with a very small number of patches from LibreELEC project available here.
I can't test by myself because the rk3318 board I have was already working with my monitor, yet the patched kernel did no harm on my setup.
If there are some successful reports, the patches will be merged into armbian and hopefully the HDMI issues will be fixed once and for all.
Thanks!
-
Hello; for anyone is still having issues with HDMI output, I have arranged a minimal set of patches that could go into mainline armbian.
The .deb packages for an experimental 6.6.25 kernel and dtbs are here. Just install them with dpkg -i
I can't test if they are effective by myself because I have no setup where HDMI fails, nonetheless they seem not to harm my current setup.
If you can afford to try that experimental kernel, please report your experience, thanks!
-
You can take a look to this thread also:
it does not contain any solution, but there I posted an experimental image with kernel 6.3 and some patches cut out from libreelec patches set that solved the problem.
The problem is that it is a wide number of patches to import to solve the issue, and since I don't have a setup with HDMI issues I can't do tests to reduce the number of patches to an essential set.
RK3399: H.264 decoding not exposed in v4l2, only MPEG2 and VP8
in Orange Pi 4 LTS
Posted
Definitely, if you look at the kernel source code you can enable the codec
Yes, it is. I think it is in the kernel mailing list, so it is something that is already floating around and eventually will be merged.