usual user
-
Posts
481 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by usual user
-
-
4 hours ago, hasselh said:
But how can I tell Armbian to use it at boot time ?
Either fix the boot.scr magic or switch to distro-boot by inserting an extlinux.conf. For background maybe start reading here and here.
4 hours ago, hasselh said:Also, any idea how to mux GPIO pins under 5.x kernels ?
I usually write DT-overlays for my board extensions and apply them to the base DTB.
-
1 hour ago, hasselh said:
SolidRun Cubox-i Dual/Quad
Useing imx6q-cubox-i.dtb for hummingboard carrier won't work. You need imx6q-hummingboard.dtb. In my environment I use mainline uboot build with mx6cuboxi target and distro-boot method. This way uboot identifies at which SolidRun imx6 device it is running and selects the appropriate DTB.
IIRC Armbian uses also mainline uboot but boot.scr magic to select the DTB. -
Post output of:
cat /sys/kernel/debug/gpioand:
cat /sys/firmware/devicetree/base/modelwith 5.x kernel running.
-
28 minutes ago, RussianNeuroMancer said:
Yes, it's installed as part of linux-firmware package.
And USB Type-C kernel components are build as modules? If build-in, the firmware must also be build-in, otherwise it cannot be loaded.
-
On 12/17/2020 at 12:04 PM, RussianNeuroMancer said:
displayport over typec - doesn't
What's in my mind right now, you have dptx.bin firmware in place since it is required for USB DisplayPort?
-
3 hours ago, RussianNeuroMancer said:
I wonder if mixed mode (when connector is used for both of USB and DP) is excepted to work at this stage?
I don't know what the kernel patch code is capable of. Was just through your link aware of its existence
I only extended my DT-overlay with the support for the patch. Maybe I'm just lucky it fits my needs. The extcon-cables property may determine to some extent the capabilities, but I see no binding documentation. Since the patch is used by Pinebook Pro and Helios64, there may be some reports about its capabilities to be found there.
-
1 hour ago, RussianNeuroMancer said:
displayport over typec - doesn't
The only observation I made during the test was that I must have connected the monitor to the adapter and turned it on before connecting the Type-C connector. Otherwise the display won't be working.
-
1 hour ago, TRS-80 said:
I am only partially understanding the issue, and how it differs from OP, to be honest
This discussion is about USB Type-C DisplayPort Alternate Mode support on mainline kernel. It was introduced for Pinebook Pro with the referenced kernel patch. This thread is about Helios64 DTB making use of this funktionality. My discussion is about doing the same for NanoPC-T4. So, IMHO this belongs in a place where NanoPC-T4 is discussed with a title like "USB Type-C DisplayPort Alternate Mode Support for NanoPC-T4".
-
13 hours ago, RussianNeuroMancer said:
Could you please share your solution here:
This discussion is off-topic here, a moderator should move it to a proper thread starting with my previous post in this thread.
I do not use code referenced here. I also do not use Armbian user space, but IMHO my overlay should also work there.
To verify this a test has to be done:- Use a mainline kernel with this patch applied
- Backup the original dtb, e.g.:
mv rk3399-nanopc-t4.dtb rk3399-nanopc-t4.dtb.orig- Apply rk3399-nanopc-t4-tc.dtbo, e.g.:
fdtoverlay -i rk3399-nanopc-t4.dtb.orig -o rk3399-nanopc-t4.dtb rk3399-nanopc-t4-tc.dtbo- Reboot and test if Type-C DP is working
If confirmed I will also provide the overlay source for Armbian integration.
-
On 12/13/2020 at 6:31 PM, RussianNeuroMancer said:
Pull request mention HDMI specifically:https://github.com/armbian/build/pull/2302
Thank you for sharing the link. Inspired me to write an overlay for my NanoPC-T4.
Now I can attach an additional monitor via my Delock 63959 USB-C to VGA / HDMI / DVI / DisplayPort Adapter with 5.10.0. -
5 hours ago, hexdump said:
but those are fixed ip cores in the hardware and not loaded later
The only difference here is the location of the persistent storage where the blob is located. I would prefer if all blobs I have to use be stored at a location I have control about, but this is not easy to get. In this way, I could at least control which blob is used and after a restart the device is in a known state. Where the blob is stored on the device, it is quite difficult to detect manipulations of malware that takes place at run time and then remains persitent.
-
9 hours ago, hexdump said:
boards sometimes come with wifi requiring blobs
If you care about the wifi blob, don't forget the blobs in SD-card-, EMMC-, Hardisk-, USB-stick-, Keyboard-controller, ... to have a complete system.
-
-
2 hours ago, Pencheff said:
DRM rendering works with X11 and GLES/EGL.
Mainline hardware acceleration does not work efficiently for X11 because it does not have a suitable ddx driver with the correct render node GPU and v4l2 mem2mem VPU support.
I discussed my results in a thread that starts here with some follow-up posts while I examine it for myself. -
3 hours ago, TRS-80 said:
Also, I am still a little worried about the results of fsck from above.
You referenced the raw device by "/dev/mmcblk1" where MBR , u-boot and partitions reside.
You need to reference a partition by "/dev/mmcblk1pX" where a suitable filesystem resides.
Replace "X" with the number of the partition you want to check. -
10 hours ago, martinayotte said:
Alternatively, it is possible maybe to workaround by editing main DT instead of using overlay.
Or, apply overlay static to base blob.
fdtoverlay --helpMuch easier
-
9 hours ago, fromport said:
Crashed within _minutes_
It was only a shot in the dark. I was inspired by this post. Attempting to trigger a next frequency change while a previous one is still in progress would have been a good explanation, as the crash appears to occur through dynamic frequency scaling. But having this configuration right is a good idea in any case. It's not always about it working or not. Most of the time, it's about not working as well as possible and all the small drawbacks add up in overall performance.
-
Out of curiosity, with mainline kernel and ondemand governor in place.
Apply this:echo 40000 > /sys/devices/system/cpu/cpufreq/policy0/ondemand/sampling_rate echo 465000 > /sys/devices/system/cpu/cpufreq/policy4/ondemand/sampling_rateDoes it still crash in your use case?
If it does not crash any longer I will explain what is going on. -
2 hours ago, jock said:
armbianmonitor -m should be useful for that task
I doubt it collect enought fine grained data for a good interpretation.
Here is a tmon log visualisation of a glmark2-es2 run:Spoiler
Look at the temperature differences between CPU and GPU, despite the small distance.
-
2 hours ago, GreyLinux said:
any direction , advice or information would be appreciated
For a first test replace your rk3399-rockpro64.dtb by the one provided in this post.
If your original dtb is carriing different configuration you can use the fdtoverlay method to apply rk3399-rockpro64-tz.dtbo (build from rk3399-rockpro64-tz.dts) static to your base dtb. This will work with mainline fdtoverlay without modification. Using it as dynamic overlay should also work.
The second rk3399-rockpro64-tz.dts post was only to showcase how to change a value of an existing binding. -
1 hour ago, jock said:
Uhm, on my libreelec box I see the first trip point at 90°C and critical at 115°C.
I have only looked at the attached dtb and there only the 105°C trip point is bound to a cooling device. But without a tmon log I can't tell how often this is fireing.
1 hour ago, jock said:Could you please clarify the second sentence?
Fequency scaling is controlled by CPU load via governor or user settings. It does not obey any thermal restrictions. Cooling devices obey thermal restrictions and control the scaling.
-
5 hours ago, jock said:
the temperature seems to be erratic because the heatsink is usually just a bit warm while the software reports temperatures that may cause you a burn.
Don't confuse the junction temperature with the ambient temperature of the heatsink, as that is the one the CPU temperature sensor is reporting. How long it takes to propergate to the surface depends on the thermal resistance and can take quite some time.
5 hours ago, jock said:I have no real problems running boxes at 70°C, actually I have one which is happily running at 89°C with libreelec, then happens the thermal throttling which keeps frequencies low.
If I read the previous attached dtb correctly, then the thermal system kicks in at 105°C. Relying on load dependent DVFS does not take any account in thermal constraints. How the thermal system really works can be deduced from a tmon log created during a stress test.
-
-
1 hour ago, DevShanky said:
Pirated? I am sure I am missing some thing here.
English is probably not balbes150 native language and he is using a translator.
"Hijacked" would be a better translation, your post is off topic in that thread.
USB Type-C DisplayPort Alternate Mode Support for NanoPC-T4
in Rockchip
Posted
Unfortunately my config and the armbian config diverge quite a lot and it is not easy to identify the relevant differences. The only help I could offer further is to run your environment with my kernel to identify whether the kernel is the culprit or something else.
If you want to try this, you have to post the output of the following commands:
cat /proc/cmdline ls -hal /boot lsblk -o +PARTUUIDso I can prepare the experiment.