usual user

  • Content Count

    152
  • Joined

  • Last visited

About usual user

  • Rank
    Elite member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This is only feeling and guesswork. I don't have your device model so can't check your setup by myself. Hence my request for a tmon log to see what is really going on. But if you are satisfied with your results, I have no further request and stop my curiosity.
  2. I'm curious how your thermal system performs, an opinion to post a tmon log while your device is being stressed? This is mine running for three hours with all six cores at 100%:
  3. i.MX6 support is feature complete since long time in mainline, I'm running fully flagged fedora on my i.MX6 devices for years. Not running current releases will missing bugfixes and latest features. No i.MX6 development is required, only an administrator who knows how to integrate software in his system. So you are fully qualified. You want the xf86-video-armada driver as referenced in the other thread. If you want to know how it fits together, see buffer-flow.pdf Armbian manages their build system with git. So you issue a pull request (PR) to
  4. This is about i.MX6 SOC and the device it is equipped on does not matter. Since not many Armbian i.MX6 SOC users, even you till now not, contribute much to the Armbiban project, you can imagine why few improvements happen. The same responses from "No gpu support on Udoo?" apply here, so I'll leave it to a moderator to possibly close this topic as a dublicate. To begin with, you can provide a PR to add the pointed out xorg driver to the Armbian build system.
  5. I stumbled across a patch set that enables higher resolutions than FHD. I'm wondering if this has some impact on your HDMI issue. Since I built a kernel for other reasons, I pulled the patches also in. Is there an interest in trying it out with my uboot on your NanoPC-T4? It will be picked up by the test verbose option.
  6. 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.
  7. 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.
  8. 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.
  9. Out of curiosity, does my mainline uboot without binary bloobs work for you?
  10. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/rtc/maxim,ds3231.txt
  11. Restudy your referenced spec. The default serial console is located at "Debug UART".
  12. 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.
  13. 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 influenc
  14. 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} ; sync and test. Replace "${DEVICE}" by your micro-SD device.
  15. 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.tgz and 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,