usual user
-
Posts
498 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by usual user
-
-
11 hours ago, tmountain said:
I could not get the aforementioned kernel to work
Sorry, but as this is working for me with Fedora userspace, I can't help any further.
But at least you found a solution for a working u-boot. -
1 hour ago, tmountain said:
And my boot log here (via UART):
Your log is only about kernel log. I wonder if your problem is a kernel build configuration. Any means to drop in my kernel also? Make sure you use the same kernel cmd line parameters as the defaut stanza as in the extlinux.conf. Of course, you need to adjust the PARTUUID.
-
5 hours ago, tmountain said:
The vanilla u-boot does not work out of the box.
Out of curiosity, does my mainline uboot without binary bloobs work for you?
-
10 hours ago, mbo said:
point me to a tutorial/documentation on how to setup a DS3231 RTC module
-
1 hour ago, tmountain said:
The full NanoPC-T4 pin spec is here: http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T4.
Restudy your referenced spec. The default serial console is located at "Debug UART".
-
20 hours ago, RussianNeuroMancer said:
Belkin dock is solution with most broad compatibility, and I have to choice but to stick with it for now.
You probably have a misunderstanding about what this thread is about. It is about to verify if my DT overlay is working in Armbian environment so it can be integrated in Armbian for out of the box operation of Armbian users. It is sufficient to aprove it is working in a similar manner as for me. If a special USB-C device does not work, this is possible to discuss with the patch autor. PD functionality is for NanoPC-T4 out of scope because it has no PD features desined in hardware. The NanoPC-T4 can e.g. operate an additional display via a cost-effective USB-C DP alternative mode adapter.
20 hours ago, RussianNeuroMancer said:Please clarify why you think this incompatibility is caused by patch, while even vendor kernel couldn't use this dock as video output on this specific board?
Vendor kernels are havy out of tree patched to showcase the key features of a specific hardware. But never implement everything perfect. Otherwise noone would have any demand for any update ever. The fact that the NanoPC-T4 vendor kernel does not have functional USB-C DP support is even understandable, as it already has three dedicated display connectors. Support for a fourth one is therefore likely to be a very low priority and left out. But the hardware is there and can be used with proper software, as proven for my environment. If other vendor kernels support your device they have probably some necessary modification in place and aprove the 3399 SOC can drive it.
Starting here and the following posts you can find success of using USB-C DP with legacy kernel.
-
IIUC the PINE64 and Firefly image use legacy kernel and don't use this particular kernel patch. Now that the only difference in our setups is the USB DP adapter, IMHO the only sensible way forward is to swap the dock for another DP alternate mode adapter. Swapping the board will not eliminate an incompatibility between the kernel patch and the dock. The USB-C hardware (DTB) seems to be set up correctly otherwise the USB functionality would not work. The DP alternate mode uses the same hardware lanes but only protocolly differently.
Off topic: Out of curiosity does the offered u-boot influence your Dell UP3017 incompatibility? -
Okay, I can only imagine two reasons for this still not working. Either the DP kernel patch doesn't support your DP hardware or u-boot doesn't set up the NanoPC-T4 as needed. To rule out u-boot, apply the extracted u-boot, which can be found here. E.g:
dd bs=512 seek=64 conv=notrunc if=u-boot-rockchip.bin of=${DEVICE} ; syncand test. Replace "${DEVICE}" by your micro-SD device.
-
4 hours ago, RussianNeuroMancer said:
I see menu but it's seems like it doesn't accept keyboard input, probably due to the fact that my keyboard is attached via USB dock.
IIUC the extlinux.conf is working with the current kernel for you. The USB keyboard is not expected to work, because mainline uboot does not yet have the necessary support enabled. Boot option selection is only available via serial console for now.
Extract the tar-gz kernel archive, which can be found here, in your /usr/lib/modules/ directory. E.g.:
tar -C /usr/lib/modules/ -xzf 5.10.0-98.fc34.aarch64.tgzand reboot. Extlinux.conf will pick it up by the default option. To fall back to original kernel without boot option selection, rename the symlink /usr/lib/modules/linux-default, e.g.: linux-default-disabled
-
9 hours ago, Ferdinand said:
As it's no longer available at the linked location, can you make it available to me somehow?
The image was provided to identify a boot.scr magic deficiency. Also Fedora 31 is EOL, so image RIP. Since there seems to be more shortage there, as long as no one who cares for Armbian shows up and maintain the boot.scr magic, you are on your own.
-
1 hour ago, Igor said:
some hw variants are not working and there is nothing
littlewe can do aboutIt is a hardware flaw due to a missing pull resistor and a software quirk.
A fix is discussed here but as long as noone with an affected device confirms it, probably nothing will happen.
-
On 12/28/2020 at 10:12 PM, hasselh said:
risk/extra effort that /boot/dtb gets overwritten and I have to adapt & apply the overlay again
IMHO I think from version 5.10.0 the path won't change again because generic node names have been around since then. Therefore, the same DTBO can always be applied. But as long as the hardware setup doesn't change, there's no reason to ever change the DTB. Therefore, after an update, restoring the DTB from a persistent location would also be an option.
But I guess you will have more fun to keep having the boot.scr magic in place. And tinkering with boot.scr magic opens even the option to load the DTB from the persistent location direct or choose a different DTB file name that wouldn't be overwritten.
-
OK, here is the preperation for our experiment:
- create an extlinux directory in your root, e.g. mkdir /extlinux
- copy the attached extlinux.conf into it
- reboot and check if the device is now booting with distro-boot methodThe auto boot timeout is set to 10 seconds, so be patient.
If this is working I will upload my kernel and you can put it in for the test. -
14 hours ago, hasselh said:
Any idea what I might have done wrong ?
Applies for me flawless.
fdtoverlay -V Version: DTC 1.6.0 fdtoverlay -v -i imx6q-hummingboard.dtb.orig -o imx6q-hummingboard.dtb imx6q-hummingboard-gpio.dtbo input = imx6q-hummingboard.dtb.orig output = imx6q-hummingboard.dtb overlay[0] = imx6q-hummingboard-gpio.dtboThe overlay is written for DTS comming with 5.10.0 kernel. Over time, some node names have been renamed to improve homogeneity. Attempting to apply it to an older release may fail.
-
On 12/23/2020 at 6:31 PM, hasselh said:
where do I find any documentation/examples how to properly create the correct DT-overlays for my Hummingboard ?
Maybe somthing like imx6q-hummingboard-gpio.dts. Compile it with DTC and apply it as follows:
mv imx6q-hummingboard.dtb imx6q-hummingboard.dtb.orig fdtoverlay -i imx6q-hummingboard.dtb.orig -o imx6q-hummingboard.dtb imx6q-hummingboard-gpio.dtboBut since I don't know your PAD configuration requirements, I only chose one random one. You
have to look up your needs yourself. -
Just switched to 5.10.0. I noticed that the DTB has changed multiple node names. As a result, my user space could no longer apply all configuration quirks due to the changed paths in sysfs. Useing a DTB before 5.7.x resolved all observed regressions for me. Perhaps it is also worth trying in your case to run the current kernel with a pre 5.7.x DTB as a test.
-
23 hours ago, RussianNeuroMancer said:
I don't know what components I should check.
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.
-
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.
Upgrading cubox-i Buster from Kernel 5.7.y to 5.8.y breaks ethernet
in Other families
Posted
The fix has landed in 5.11, but as I don't see any stable tag, you have to wait till Armbian moves to 5.11 or compose an Armbinan PR for the patch to have it backported for older kernels.