Jump to content

usual user

  • Posts

    265
  • Joined

  • Last visited

Recent Profile Visitors

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

  1. cat /sys/class/leds/n2:blue/trigger should list all available triggers for the LED, and echo mmc0 > /sys/class/leds/n2:blue/trigger should enable it as an HDD LED for the SD card. That was to be expected, because with it you have reactivated the legacy boot method, which of course has no idea how to boot my kernel and boots the stock Armbian kernel. This was just a hint, if a working Armbian kernel were available again, to switch back and forth between my additions and the Armbian method comfortably. I could also have added an option to offer the Armbian kernel with distro-boot as well, but since the kernel has been proven not to work, I left it out. Distro-boot can use as many kernels installed at the same time as the SD card space allows. Very convenient to quickly switch between multiple versions to compare. Like you just did to find out that it doesn't work even with an already configured userspace .😉
  2. This is now the part where the real work begins. My kernel proves that a solution exists and does not have to be developed first. If the solution to the issue came from the further development to my kernel version, it is sufficient to bring Armbian to at least this version. If the solution to the issue is due to a configuration of the kernel build and Armbian does not have it, it must be identified and possibly also applied in Armbian. I don't think it's because of patches I add, because as far as I see they are not relevant to the issue. If you have developed a solution that works with the Armbian build system, you need to read the Armbian documentation on how to add your work via a pull request to Armbian. I can still give some basic hints if needed, but I don't have the necessary interest in Armbian to want to do all this work. Maybe you can attract an Armbin maintainer to help with this.
  3. Congratulations, you have successfully proven that the stock Armbian kernel is the culprit of your issue. Here is a small summary of what we have achieved so far. You have changed your boot method to distro-boot. You successfully run a fedora kernel in an Armbian environment. Your image is now suitable for several devices, e.g. N2+, M1, NanoPC-T4, Helios64, ... Only the append line in the extlinux.conf has to be adjusted accordingly, because the SOCs require different kernel configurations. The boot method is quite fail-save and it takes some effort to create an unbootable system. The ledtrig heartbeat driver is built as a module and is not loaded automatically. This command should return your heartbeat: modprobe ledtrig-heartbeat Usually I configure it as an HDD LED for the SD card. Depends on what your intention is. You can insert my kernel into any image with mainline kernel this way. Legacy out-of-tree kernel images can also be booted, but userspace will lack legacy out-of-tree functionality that the kernel does not provide. In this way you could follow my kernel builds and request updates if necessary. You can wait until Armbian catches up with my kernel version and hope that your issue is fixed. To switch back to the legacy boot method, move extlinux.conf out of the way. E.g.: mv extlinux.conf extlinux.conf-disable You start with further investigations to identify the cause in the Armbian kernel build. Then prepare an pull request to get it integrated in Armbian. This is the fastest way to return to the stock Armbian system.
  4. I have prepared an extlinux.conf. Mount the Armbian SD card partition and create an /extlinux directory in the root filesystem of the Armbian SD card. Then copy the attached extlinux.conf in. Download this kernel package and unpack it with this command in your Armbian SD card /usr/lib/modules/ branch: tar -C ${mountpiont}/usr/lib/modules/ -xzf 5.19.0-0.rc6.46.fc34.aarch64.tgz Boot with the SD card and report if this changes anything.
  5. Looks like the firmware is not the culprit. Seems the kernel has some problem. We can install a newer one to prove this. For this I need the PARTUUID of the corresponding image for preparation. To get this, connect the Armbian SD card as if to run the dd commands, and then post the output of: lsblk --output +PARTUUID
  6. This is because anyone can upload files there and no one checks their content. This is because it only contains the firmware that you should replace in your Armbian image. To do this, you must first install your desired Armbian image to the SD card and then replace the firmware component with the given command. The screenshots indicate that you haven't previously installed an Armbian image.
  7. Only a shot in the dark. Download this firmware and extract it with: tar -xzf u-boot-meson.tgz Write it to your with Armbian prepared SD card: dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${entire-card-device-to-be-used} Boot with this SD card and report if this changes anything.
  8. I think I have to disappoint you, see here.
  9. usual user

    Mainline VPU

    So another reason why it doesn't hurt if RKVDEC HEVC only lands in 5.20.0. What is it good for if you can decode a video but can't see the result? What I miss is where rk3399 DRM KMS development is taking place, all current media improvements have been promoted mainly by developments for other SOCs. I do not expect DRM KMS development to be a duty of LE developers.
  10. usual user

    Mainline VPU

    If it doesn't land, it's not a show stopper. Adding this patch is a trifle. What I fear more is the availability of the necessary rebase of the LE patches: linux-0011-v4l2-from-list.patch linux-0020-drm-from-list.patch linux-1000-drm-rockchip.patch linux-1001-v4l2-rockchip.patch linux-2001-v4l2-wip-iep-driver.patch because I think some of it is still needed so that the VOP can also process all new output of the decoder.
  11. usual user

    Mainline VPU

    Went on to 5.19.0-rc6 with all in flight work on top. With all this in place I for the first time can confirm the HEVC decoder is working for me. \o/ See fluster-run.log for reference.
  12. I have nothing to decide here, if you want it to be in Armbian you have to convince an Armbian maintainer to pick it up. I also use Armbian only very sporadically for board bring-up and initial tests. Nevertheless, when the release has taken place, I will build a uboot-tools package for me and can, if you wish, upload the firmware. I use it to start my system from SD card or via USB connection. I don't see any reason why it shouldn't work with eMMC, but you only know for sure if you've tested it. For me it was the first action to replace Petitboot with a mainline uboot. You have to wait a little longer, see here. Release v2022.07 has taken place and the uboot-tools package has been build. I am running the firmware from SPI flash and it is working flawless for me. Since distro-boot is supported for free, the use of an extlinux.conf allows to select the current kernel, an previous one and a persistent one with the option to enable SPI flash for ODROID-N2 or ODROID-N2+. See the attached extlinux.conf as an example implementation. More details can be extracted from this thread, with its distracting posts in between. It is possible to keep as many different kernels installed as persistent space is available. A kernel upgrade will never leave an unbootable system behind as long as a previously working one is still installed. So if someone wants to experiment with u-boot-meson.bin, you have to let me know and I will upload the file. extlinux.conf
  13. Congratulations, I'm glad that it works for your usecase. Since I don't have an eMMC, it was just a shot in the dark, thanks for the confirmation that it also works with an eMMC. Since the release is already near, it is not worth taking another intermediate step, since most likely nothing earth-shattering will be added in relation to ODROID-N2+: I could still offer v2022.07-rc4 as an upload if you like. The use of the rc version should have no meaning in relation to the ODROID-N2+ as long as no malfunctions are noticeable. And even if some mainline bug is identified, I don't think there is enough time to introduce a fix in the planned release. By the way, I run the firmware only from the SPI flash, and in case of recovery from the SD card. In the end it's just: dd if=u-boot-meson.bin of=/dev/mtd0 ; sync
  14. The firmware (uboot) is loaded by the maskrom code in the safest and slowest mode to use only minimal eMMC requirements. When uboot takes over, an attempt is made to switch to a more efficient mode. If this does not succeed, it can lead to the observed behavior. Since I don't know if more recent uboot versions have already fixed a possible problem, I had offered my v2022.07-rc2 build for a quick test. Unfortunately, in the other thread it looked like the maskrom code couldn't even read the firmware blobs and without console logs it's not really to analyze. So if you want, try v2022.07-rc2 it's a simple: dd bs=512 seek=1 conv=notrunc if=u-boot-meson.bin of=/dev/${entire-card-device-to-be-used} ; sync
  15. 128MiB cma is probably not sufficient according to here:
×
×
  • Create New...