usual user

Members
  • Posts

    228
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Everything posted by usual user

  1. First of all, a summary of what we have achieved. By confirming that my kernel package works we now have an Armbian system which boots on a Helios46, a NanoPC-T4, an Odroid N2+, an Odroid N2, and a Honycomb in the same way. I have the certainty that my fedora system works without modifications on a Helios64. And the only requirement to be fulfilled for this is that there is a suitable firmware (uboot) in the required place. Wherever this is (SPI flash, eMMC, SD card, ...). The extent to which the user space configuration has to be adapted is another story. For fedora I am sure that it works. You already know how to install a kernel package and enable it for the default boot option. For a kernel update you only need to ask me to provide the next version and can then install it with an equivalent tar command. If something goes wrong (e.g. a component is missing), you have seen the distro-boot try the next boot option. As long as distro-boot is in control, this will continue until all boot options have been tried. If the control has already been passed to the kernel and it stucks, it is necessary to select an "known good" option with the keyboard while the autoboot timeout has not yet expired. As you can see, you have to be relatively creative here to have a system that can't be started somehow. Now let's include a little convenience feature. We want to keep easy access to a previously installed kernel. To do this, we duplicate the first boot options entry, and replace the linunx path part with linux-previous everywhere. Now it is enough to run mv /usr/lib/modules/linux/ /usr/lib/modules/linux-previous/ before a kernel update to support the new boot option. If we want to keep a kernel permanently accessible via boot option, we replace the linux part with the real kernel branch part. But now you want to use Armbian kernel primarily. To do this, we duplicate the last boot options entry, and replace the real kernel branch part with e.g. linux-armbian everywhere. In the attached extlinux.conf I omitted the initrd line. So you can check if the Armbian kernel also works without initramfs and you can save the loading in the future. Before the new boot options work you have to create the new management links pointing to 5.15.31-rockchip64. Through different management link name bases, you can easily manage several kernel variants. To use the Armbian kernel as default, you could move the corresponding boot option in the first place, but there is the more elegant default distro-boot key. This is used to specify which boot option to start the boot trys with. As you have probably already noticed, the append lines differ between fedora and Armbian kernel. And even for different SOCs, different parameters may be required, e.g. serial device name. Also, parameters cannot be portable if kernels are built with other configurations. You therefore have to pay attention which kernel packages you use with which append lines. And now a few words about kernel packages. As you may have noticed, my package comes without an initramfs. This is possible because my kernel is built in such a way that all drivers necessary to access the rootfs are build-in and was my biggest concern that something would be missing for Helios64. Fortunately, this is not the case. The initramfs is always rootfs dependent, so it cannot be easily exchanged between different systems. It must always be generated in the current system. It is therefore good practice to build the kernel in such a way that no initramfs is needed to have a portable kernel package that can be used for each rootfs for a specific SBC, e.g. fedora kernel usable in Armbian. Oh, by the way, please try not to test multimedia components, it could be that you notice that they are technically up to 5.19.0+ ;-). But I'm afraid that your userspace components are not up-to-date enough. It requires at least the latest mesa and gstreamer releases and FFMPEG requires out of tree patches because mainline support is missing. And now a little digression, transfer your SD card to the ESPRESSOBin and post the log created with the default verbose boot option.I'm sure my kernel package won't start completely, but I'd still like to see how far it gets. We'll look at this again when you know all the complexity of extlinux.conf, there's still something to come. So now I have to think about how to continue the training, there are still so many aspects to explain. extlinux.conf
  2. Congratulations, now we are in business. It uses exactly what is described in your quote (https://www.kernel.org/doc/Documentation/arm64/booting.txt). The kernel is build with the Image.gz target and the firmware (uboot) decompresses it. And, surprise, uboot can automatically detect at what kind of kernel the extelinux.conf kernel key points. I have so much more to elaborate about what has been achieved so far, but no time right now. So I have to put you off on a follow-up post, please stay tuned.
  3. Exactly. Again you have modified my suggestions, so slowly I lose the desire to continue this training. A boot directory is a legacy boot artefact that isn't needed for distro-boot. Either you want to learn from me my distro-boot deployment and follow my suggestions, or we leave it and I save myself a lot of frustration. Since I am convinced from the previous observations that your system has the necessary prerequisites, here is a last attempt to continue the training. Use my unmodified extlinux.conf and use the locations that evoke these commands: cd /usr/lib/modules/5.15.31-rockchip64 cp --preserve --recursive /boot/dtb* . cp --preserve /boot/System* . cp --preserve /boot/config* . cp --preserve /boot/Image . cp --preserve /boot/vmlinuz* . cp --preserve /boot/initrd* . After the training, you can then make all the changes you want when you implement it for Armbian. As a next step, we will now install another kernel. Since I can assume that you do not have a suitable kernel package available, I have uploaded my kernel, as I currently use it on all my devices, here. It is a pure mainline kernel built as a generic kernel, i.e. it should be suitable for all aarch64 devices that have corresponding mainline support. Helios64 support is built, but I'm not sure if everything necessary is included, but the backup 5.15.31-rockchip64 is in place to keep your System usable. Unpack it with this command in your /usr/lib/modules/ branch: tar -C /usr/lib/modules/ -xzf 5.18.0-0.rc3.27.fc34.aarch64.tgz This will populte a new kernel package branch in /usr/lib/modules/ and aktivate it for the default boot option. Reboot your Helios64 and report if the new kernel fully starts.
  4. I am still in the phase to learn what your system exactly provides. I know what to look for, since I don't know the results before, I can't deliver a turnkey system. I therefore have to check individual points step by step and, if necessary, establish appropriate workarounds. Therefore, it is necessary to follow my instructions as unmodified as possible. For me it is: file vmlinuz vmlinuz: gzip compressed data, max compression, from Unix, original size modulo 2^32 46146048 A point that kann be tackled for Armbina afterwards. Well caught, you have applied the right solution, link and directory are needed. The logs are already very promising, but do not yet confirm all the required points. I need the outputs with my unmodified extlinux.conf as I attached it. Please repeat the process by removing the link /usr/lib/modules/linux, restore my extlinux.conf, restart the device, wait for the autoboot timeing out and post the log after the boot is complete. If everything is as I expect it to be, there is only one imponderable to check and we can finally start our distro-boot exercise.
  5. II never asked for, the cp command does a copy, i.e. the source file keeps in place. We only add files to the root filesystem and the lagacy support stays in place. You can always cancel our experiment by renaming extlinux conf, e.g. mv extlinux.conf extlinux.conf-disabled You are then back to your old method with some more files in the root file system. Of course, you can also delete all added files to remove them completely. With your wrong assumptions you come to wrong conclusions. Please let's do the experiment as I suggest, and you'll ask your questions at the end when you know the whole story. Please use the Helios64 for the experiment. I don't have any of your devices and using a well-known SOC is already complicated when I have to rely on your eyes and hands. We can come back to espressobin if we were successful with Helios64. When your boot process happens as always it sounds to me as if it has fallen back to the legacy method. It would therefore be important for me to know the exact messages. Oh, I forgot to ask, does your current uboot support the USB keyboard so you can interrupt autoboot and make keyboard inputs? If not, we need the serial console for now and take care of uboot USB keyboard support afterwards. The Image link point to vmlinuz and that is a compressed kernel and we are using distro-boot and that has nothing to do with the uefi methode. By the end of our experiment, it will be obvious to you. By the end of our experiment, you will know how it works.
  6. I am still awaiting the uboot messages log. We are still in the stage of redoing the legacy boot features with distro-boot method. If I have verified that it is working as I expect, I can start teach how to use the now possible new features of distro-boot.
  7. Please do not do this, it will prevent the usability of kernels installed at the same time. In the end, we won't use anything in /boot. Firmware (uboot) is the only device specific code and is dedicated to each SBC. Having it on the SD card prevents it usability for different devices. The best is if you can offload it in a SPI flash. There is not one uboot that suits everyone.
  8. For standard kernel updates, this is not even strictly necessary. We will see this as soon as my offered extlinux.conf works.
  9. OK, here is the preperation for our experiment: First step: prepare kernel package (copy files around) cd /usr/lib/modules/5.15.31-rockchip64 cp --preserve --recursive /boot/dtb . cp --preserve /boot/System* . cp --preserve /boot/config* . cp --preserve /boot/Image . cp --preserve /boot/vmlinuz* . cp --preserve /boot/initrd* . Second step: prepare for dristro-boot mkdir /extlinux - Copy the attached extlinux.conf into /extlinux/extlinux.conf over. - Reboot and check if the device is now booting with distro-boot method The auto boot timeout is set to 10 seconds, so be patient. Please post the uboot output because I wrote the extlinux.conf without any testing possibility and hopefully did not make any typos. extlinux.conf
  10. As a first step, I need some information about the running system on which we want to do the experiment. Please post the output of the following commands: cat /proc/cmdline ls -hal /boot lsblk -o +PARTUUID so I can prepare the experiment. It is the right DTB what really matters.
  11. I already have this with native mainline uboot without special boot partition or even a boot directory. My SD card boots on several SBCs (NanoPC-T4, ODROID-N2+, Honeycomb, ...) and the several kernels I have installed concurrently are only a reboot and a keypress, to select the desired one, away. Booting different systems (on separate partitions) is also working, but I use it seldom. And the good thing, to configure everything, only a simple text file is needed. I have already used this boot schema with various Armbian images for some reverse engineering tasks. Armbian had everything necessary available when using mainline uboot, at least with all images I used. It was only a question of creating a suitable configuration file and copy some files around. If you are eager to experiment, I can try to talk you thru the configuration. For our experiment an SBC with rk3399 and an SD card with an Armbian image which uses mainline uboot would be best suited because I am most familiar with this SOC.
  12. Thanks for the logs. Luckily, you didn't do what I asked for, but that gives me an idea of what's going on. Here are the log snippets of my device running with and without gpioset: On my device, pin 36 is configured as a GPIO resource, while pin 37 is not. With further consideration it is clear that even a non-wired SOC resource can be occupied by a process. However, the result is inaccessible from the outside. Because your gpio log has no entries for pin 79 and 104 without a running gpioset process, it can be assumed that they are not configured as GPIO resource (DTB). Your uboot probably configures these lines as GPIO resources, but if the kernel takes over later, they will probably be shut down by power management as an unconfigured resource (DTB).
  13. Out of curiosity, can you post the output of cat /sys/kernel/debug/gpio and cat /sys/kernel/debug/pinctrl/pinctrl-rockchip-pinctrl/pinmux-pins while the gpioset command is running? Don't forget to put the logs in spiolers (The eye icon in the tool line of the editor).
  14. The task of my discussion was to define a uniform GPIO naming scheme for the 40-pin connector of different devices, so that if e.g. user space addresses "con1-07", it does not matter on which device it is executed. It will always access pin 7 of the 40 pin connector. The mapping is done in an one effort via a devicetree-overlay and you get portable user space tools. However, this must be done in a collaborative effort, as no one has access to all devices to create the collection of overlays. Users can then reuse tools written for a specific task regardless of the current device and have no mapping problems like e.g. with WiringPi.
  15. Maybe start reading this thread where I discussed it a long time ago. If you then also create overlays for your devices with the same pin namespace, a repository for which portable GPIO programs can be written slowly arises, as long as the devices provide GPIO functionality on the same pins.
  16. #!/bin/bash gpio-event-mon -n gpiochip0 -o 4 -r -f -b 10000 ; shutdown Sorry, tried hard, but can't reach the requested 10 LOC in the bash script. And as device tree overlay: /dts-v1/; /plugin/; / { <------>compatible = "solidrun,cubox-i/q"; }; &{/} { <------>gpio-keys { <------><------>compatible = "gpio-keys"; <------><------>pinctrl-0 = <&pinctrl_gpio_key>; <------><------>pinctrl-names = "default"; <------><------>button_0 { <------><------><------>gpios = <&gpio3 8 GPIO_ACTIVE_LOW>; <------><------><------>label = "Power-Key"; <------><------><------>linux,code = <KEY_POWER>; <------><------>}; <------>}; };
  17. With the exception (AFAIU) that it is designed for PC video architecture. It uses the FFMPEG framework for GPU accelerated video operations. But SOC based ARM devices have dedicated VPU IPs (v4l2) where mainline FFMPEG framework has little support for. You have to apply out of tree patches if they exist at all for the desired version. Gstreamer based applications are better off, current mainline developer versions support everything current kernel provides. When it comes to hardware-accelerated video encoders, there is only marginal support in mainline kernel, if at all. Above all, they are waiting for the complete de-staging of the decoder APIs before their mainline development continues. Therefore, it will take some time until all current developments end up in the distributions and work out of the box. But the one who can follow the current developer versions comes a long way. When it comes to the SOC of devices, that of the N2+ (Amlogic) is less advanced because it has statefull decoders. For example, Rockchip based devices with stateless decoders are more advanced.
  18. No "trick" is required, dd only the space occupied from the start of the raw device up to the end of the last partition. The "count=..." Parameter of dd is your friend. See "man dd" for reference.
  19. For me the hardware decoder (v4l2h264dec) is working for 4K. video-pipeline-4K.pdf
  20. usual user

    Mainline VPU

    For rk3399 I have a NanoPC-T4. But any SBC with rk3399 should be supported by my kernel as the mainline support for rk3399 SOC is already very advanced and no major features are missing. I also run the same SD card on an ODROID N2+ for performance comparisons. On my LX2160A device it is also running, but I only use it as workhorse. In the meantime, I have discovered this, looks like something is still in flight before the HEVC decoder will be usable. Looks like the discussion about HEVC has stalled. Nevertheless, I continued with the 5.17.0 release. Media staging and LE patches are applied, so it is at 5.18.0+ media wise. I skipped the LE HEVC patches as they have merge conflicts and certainly need to be adapted to the latest changes of the api. For those who are interested I have attached a fluster-run.log, it shows what the usable decoders support. If someone still wants to play with my kernel build, let me know and I'll talk you through the procedur.
  21. usual user

    Mainline VPU

    I moved on to 5.17.0.rc3 with the latest LE patches on top. The H264, VP8 and VP9 decoders work as before. I have omitted current media staging patches (5.18.0) so far because the LE HEVC patch can no longer be applied afterwards. The kernel now makes a HEVC decoder available again: MPV and gstreamer enumerate HEVC components: But none of them work with it. MVP falls back to software decoding and gstreamer throws an error message: I'm not sure if there is actually an error, or if I'm trying to play a stream that is not supported by the hardware. Can anyone confirm that the HEVC decoder really works with the LE patches for a rk3399 SOC? If someone wants to try a preview of 5.17.0 and wants to save the hassle of self-building, I can upload my build. It is built as a generic kernel, meaning it should fit for any aarch64 SOC as long as it has sufficient mainline support and a DTB is available. Either a DTB that comes with the kernel, or one you supply which obeys mainline bindings. I can teach you how to put it alongside your current running kernel and decide at boot time which to run.
  22. I can now confirm that HDMI audio is up for me. I am still on my NanoPC-T4 MicroSD card but it was only necessary to insert appropriate Odroid-N2+ configurations. I used the settings from here.
  23. I have replaced Petitboot by u-boot. U-boot sits in SPI NOR and scans eMMC, MicroSD and USB storage for a loadable OS. It loads Armbian and even my NanoPC-T4 MicroSD sitting in a card-reader plugged in an USB port. The MicroSD has NanoPc-T4 u-boot in place and would not boot in the Odroid N2+ SD slot natively.
  24. Petitboot does not support my HDMI-DVI-Adapter connected 1280x1024 Display. Only my 1080p HD display produces output via a direct HDMI port. It also can't boot my preferred distribution. Therfore I deleted Petitboot and dropped mainline u-boot in my SPI NOR. Now both displays produce an output and my OS is loaded from MicroSD, USB and probably eMMC as well. I can't test eMMC yet, as I don't have one at the moment, but I don't see any reason why it shouldn't work. If there is interest, I am happy to discuss my findings.
  25. As long as the kernel boots, this message is harmless. The 5.16.0 one I am currently running does not emit it. It's been fixed on mainline for some time, but I don't remember when that was.