jock
-
Posts
2170 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jock
-
-
tm16xx driver from @Jean-Francois Lessard is already integrated in the armbian rockchip64 family patches, this is a typical device tree overlay configuration you can take as an example that is, by the way, basically similar to my (discontinued) driver
-
@paradigman try looking here for latest rockchip64 kernel headers, but I'm not sure the version will match.
Usually I install the kernel headers via regular apt, so don't know if armbian-config is ok or is broken.
-
@Constantin Gatej added on first page, thanks!
-
@Christopher Ruehl thanks for looking into this issue, I will incorporate the fixes into mainline armbian as soon as possible!
-
@Christopher Ruehl congratulations, great finding! That could explain some of the compatibility issues people is still having.
I have a couple of questions:
1) what is the purpose of enabling the internal gpio pull-up when there already is the external pull-up?
2) do you have any suggestions to apply to existing device tree to enhance compatibility for other users? Exchanging SMD components on the board is out of the league for most people
Thanks!
-
-
17 hours ago, A t said:
The Hdmi didnt turn on its black screen and the led still blinking. what should i do next? should i wait more ?
Find a possible IP address for the box and try to access via SSH, or use the UART serial to debug the issue
-
2 hours ago, ToShuk said:
One more question, I have MX10 with an sv6051p wifi chip, but the os is not see any wifi devices, is it possible to turn on sv6051p chip?
There is a driver for ssv6051p in the armbian images, but if the kernel does not see the chip it is probably turned off.
You need to set the right led-conf using rk322x-config script that enables the GPIO to turn on the wifi chip. MX10 is the tv box commercial name, but it tells nothing about the board which is inside: you have to look for the signatures on the board itself and see if you have a match with the led-conf proposed by rk322x-config
-
40 minutes ago, ToShuk said:
wow, good news! just a small clarification, Do you mean pins that turn on maskrom mode? in my side on the other side of the board under emmc.
Yes, the same.
Technically the SoC enters in maskrom mode when all the boot devices fails. Gating the eMMC will make the SoC boot from sdcard, if there's no sdcard, the SoC will attempt other boot options programmed in its ROM. Finally, if nothing is available, will sit and wait in maskrom mode.
-
Yes, ffmpeg needs some patches (borrowed from LibreELEC project) to add support for v4l2request, which is in turn the interface for the kernel to use the hardware decoders on allwinner and rockchip platforms.
-
2 minutes ago, ToShuk said:
one second, if i short the clock ping of eMMC, what are the next steps ? how to boot Armbian from sd card? just flash img to sd card, put it to box and it will boot from sd card ?
exactly; shorting the clock pin will make the eMMC disappear from the system, hence the SoC will boot from sdcard
-
Just a note: there is no modified mpv. Ubuntu Jammy just requires an updated version which my repository provides. Debian bookworm works fine with the packaged version it comes with.
-
53 minutes ago, ToShuk said:
it looks like the bootloader is in stock because the multitool is loaded successfully, but I cant burn Armbian to emmc, it is stuck. How can I run Armbian from sdcard ?
As said, you can either remove the eMMC or short the clock pin to ground.
Otherwise learn how the rockchip vendor boot happens and use the multitool binaries to hack the armbian boot
-
@ToShuk it depends upon a tree of factors.
mmc is totally invisible to the SoC
- The the SoC will automatically look for the sdcard - just plug armbian in the sdcard and it will work
- the above won't work if the sdcard slot is attached to the sdmmc_ext controller of the SoC; this depends on how the manufactured designed the board and, if this is your case, your only solution is to replace the onboard eMMC
mmc is stuck in read-only mode
- the SoC will indeed execute the bootloader, if any was present in the eMMC when it went read-only
- If the existing bootloader is the stock one, then you're stuck with the possibilities of the stock bootloader (eg: see the rockchip boot process wiki page): multitool will boot, but not plain armbian images; tinkering with armbian images bootloader will let them boot though. You can either short permanently the eMMC clock pin to ground, so the eMMC is clock gated and actually excluded from the system, or phisically remove the eMMC chip, so you can reconduct to the "totally invisible" case above
- if the existing bootloader is the one provided with armbian, the you're lucky and it should be possibile to boot from sdcard and USB
-
@Francisco Hasuky it is a known problem: some boards are sent to "suspension" after one minute by the proprietary Trust OS; you need to build u-boot with an opensource Trust to overcome the problem. At the moment I'm unable to build an image or provide the binary, but will do in the forthcoming hours/days
@Jota Ce if you got ssv6051p chip, then you should be ok using any recent armbian image with kernel 6.12 (you could upgrade to edge kernel via armbian-config, or use the beta.armbian.com APT repository). Also kernel 6.6 should work with ssv6051p because the (horrible) driver has been ported from 4.4 kernel.
-
-
-
Hello @Francisco Hasuky, does the HDMI turns off but the board is still responsive or the board just drops dead?
-
-
@Budi Pekerti boot via sdcard with multitool, mount the block device where you installed armbian and then remove the overlays=... line from /boot/armbianEnv.txt
If you don't know how to do this, you have to reinstall from scratch
-
5 hours ago, Obmor said:
By the way, you don't have to apply this patch. You just need to install the driver.
Do you mean the led-conf9 device tree overlay? Does the wifi works even without this overlay applied?
-
8 hours ago, Obmor said:
Do I understand correctly that when changing/updating the kernel version, the driver will not load and you will need to rebuild the module?
Yes, it is correct. But I will enable the rtl8189es module in the armbian mainline so forthcoming kernels will have the module compiled in. Just not update the kernel in the meantime.
-
2 hours ago, Obmor said:
It worked! thank you very much! There are already 2 WLANs: WLAN0 and WLAN1 hmm..
That's because usually these drivers are suited for Android and they expose by default a "regular" interface and a "P2P" interface for direct connection.
Just use wlan0, or there should be a module option to disable the p2p interface.
-
here it is a module for kernel 6.6.67 and rtl8189es. Put this module in /lib/modules/6.6.41-current-rockchip/kernel/drivers/net/wireless directory, then run sudo depmod -a and reboot.
If everything went ok, you should get 8189es driver loaded after boot; perhaps you may need a firmware to put somewhere in /lib/firmware. In case, the driver should complain about in dmesg that something is missing or wrong, and that may serve as hint to proceed further.
Help wanted to test a new OpenVFD alternative
in Amlogic meson
Posted
I would say, and I bet @Jean-Francois Lessard agrees, that is not a matter of "messing with my code" thing, but rather a matter of principles.
A kernel module is supposed to do a kernel module or, In simple words, it interfaces the kernel with the hardware. The kernel means are to give the userspace a way to access the hardware.
The module should not run any user business (eg: display something user-specific at boot/shutdown/whatever), but should in turn provide a service for the userspace to control the hardware.
That's a simple principle in software engineering that's called "separation of responsibility", and is generally considered a good habit to agree with that principle.
By the way, if your board has one or more colored leds, they are generally set up in the device tree and access basic GPIO system, so they are turned on as soon as the kernel starts.