Jump to content

usual user

Members
  • Posts

    416
  • Joined

  • Last visited

Everything posted by usual user

  1. Even without an eMMC mounted, you should see the following messages: And you are sure your boot mode switch is in the MMC position (towards the SD card slot)? Maybe something went wrong when preparing the SD card. This is what the messages look like when I write the SD card: Please be able to read back your prepared SD card with the following command: dd count=4096 if=/dev/${entire-SD-card-device-prepared} of=u-boot-meson-readback.bin If you upload the u-boot-meson-readback.bin, I can take a look and check if everything is ok. You may also post what your used command lines look like.
  2. The man page of my version corresponds with many hits of a google search of "man blkdiscard", e.g.:https://www.man7.org/linux/man-pages/man8/blkdiscard.8.html And looks like I fat finger typed the parameter, I meant -z, --zeroout.
  3. I uploaded an archive of my firmware here. Unpack it with tar -xzf u-boot-meson.tgz and use the dd command described above to write it to the prepared SD card. And then keep your fingers crossed, hopefully it works for your use case.
  4. I asked for a nulled SD card. Since you did not mention the "-k" parameter of blkdiscard in your proposal, this is not guaranteed. Firmware does not take into account filesystem structures and accesses storage media raw, so remaining data fragments can lead to disturbances. Since the write function of the storage medium accounts for the majority of the operation, the execution time of both programs should be almost identical. The use of an additional tool also requires appropriate knowledge to use it. This increases the complexity of the activity to be carried out. The use of the same tool always reduces the effort to explain the use of the tools used, you can build on already imparted knowledge.
  5. The boot flow they implemented is simply incompatible with Armbian boot method. And since it is also closed source, where I would not even have the opportunity to repair it, for me it is reason to reject it unconditionally. Since you don't have access to the serial console, a basic test only requires an SD card that you can delete completely. An installation in SPI flash or eMMC only makes sense if it is previously ensured that the firmware basically works for your use case. Debugging an installation in SPI flash or eMMC without access to log files is hopeless. If the firmware basically works, you can install it in SPI flash or eMMC in a next step. These are the necessary steps for the experiment: Prepare a completely blank SD card, e.g.: Copy my firmware binary to the empty SD card, e.g.: Now insert the SD card into the Odroid N2, mount the eMMC module with the system to be booted, switch the boot switch to the MMC position and start the Odroid N2. If the system boots successfully now, you can think about installing the firmware in the SPI flash or the eMMC. When you're ready to do the experiment, speak up and I'll upload the firmware.
  6. Petiboot can't cope with the Armbian distribution, the reason why I replaced it by mainline uboot.
  7. Version information is output to the serial console as well as other helpful information. It is therefore a good idea to post the entire log. I use my self-build firmware (2022.01) in the SPI flash. Since I don't have an eMMC available at the moment, I can't say if this version basically works with eMMC. I just built the 2022.07-rc2. If you want to experiment with it, I can upload the firmware and you can try it with a spare SD card. Maybe some improvements have already been incorporated there.
  8. Uboot is only the last component in the firmware running chain. Before passing control to uboot, several other firmware artifacts are executed in different security levels. ARM Trusted firmware is a open source reference implementation of secure world software for ARMv8-A including Exception Level 3 (EL3) software. For amlogic no TF-A exists, hence you have to use encrypted binay amlogic blob artifacts. Check from which components the Armbian uboot build composes (aml_encrypt_g12b --bootmk) the fip for e.g. Odroid N2+. The uboot code is located at the end of the fip. Read this how to try to bypass the firmware location restrictions.
  9. What firmware (uboot) version are you using and where is it located (SPI or eMMC)?
  10. Now I would also like to dream: When commissioning a new system, I imagine that I will be offered a menu at the first boot in which all configurations available for selection are displayed. Since the SBC can't read my mind, at least I hope so, I choose the one I want. The system then starts and performs its first boot routine. At the next start of the system I wish for a dedicated menu of my previously selected boot option. I'll leave it up to you to explore what changes you think are necessary. Nevertheless, let's see how I would approach the matter in my dream. First, I would create a numbered extlinux.conf for each configuration selection with the following naming scheme: extlinux.conf-xx with xx=01, 02, ... The initial extlinux.conf contains only the fail save boot options of the available configurations. In addition, I append a boot parameter of the following form to each append line: bootoption=xx with xx=01, 02, ... Then I write a shell script that searches /proc/cmdline for bootoption= and then copies the corresponding extlinux.conf-xx to extlinux.conf depending on the value found. Now I make sure that the script is executed as part of the first boot routine, and my dream should come true. Wait, do I have just developed a method how distro-boot can communicate to the running system which boot option for the successful boot has been used. Am I still dreaming now or is all this already really feasible?
  11. The time when I had the experience on which I base my statement is already many years ago, so you might be right and it is now available. Since I actively maintain the partition ID of my drives with talking values, I also use it for physical identification. And since the PARTUUID use has worked equally since the beginning, I have never questioned it again. As long as you do not want to control two systems from one menu, there are no conflicts. Only the selection of the system to be used is not quite as comfortable but it is still possible. And removable media always work. I still build my kernels from the original fedora source packages, but no longer use fedora binary packages. My kernels are installed by simply copying in place and can be used via a tar archive in any system. No complicated install routine. KISS Try this portability with a deb or rpm package.
  12. Because I work according to the KISS and DRY principle. The kernel can determine the position of the root file system with the help of the PARTUUID without the help of the user space. UUID always requires user space support because there is no native support for this and thus always an initramfs. The knowledge of which drivers are needed for a particular device must be available in any case in order to take them into account in the kernel build. If they are build as modules, you need to make sure that you set up an initramfs, that they are included in the initramfs, that initramfs is provided to the firmware and that the firmware loads it. So many additional possibilities where something can go wrong. If the drivers are build-in, all administrative overhead for the initramfs is natively included in the kernel config. This results in a less error-prone system and takes maintenace burden down. KISS Once the rootfs is mounted, the kernel can load any module, i.e. only the drivers for rootfs access are required as build-in. All others such as e.g. GPU, VPU network, ... can be modules. Without initramfs they are only available once in the system (/usr/lib/module/5.18....). DRY I don't really care, but if you insist on using GPT, use GPT PARTUUIDs and my implementation works equally. But good luck if the partition table collide with the areas where the maskrom code requires its firmware (e.g. amlogic) and no seperate firmware storage is available. This is only necessary if you colocate several systems, in my implementation each rootfs corresponds to a ESP. As soon as distro-boot finds /extlinux/extlinux.conf, this system will be started accordingly. At the moment a fixed scan sequence of uboot is predetermined, but it is already being worked on mainline uboot to scan all drives and a boot menu with all found systems will be offered for selection. Keyword "bootflow", and also UEFI systems are to be supported. This is a pious wish and I hope you will be heard by the board designers. I would be happy if they would offer always mainline uboot instead of bitrotten outdated BSP hacks. I could handle the rest. But good luck convincing all distributions to provide compatible configurations. I prefer the way mainline uboot goes, each distribution uses its own configuration and uboot uses distro-boot, uefi-boot, lecacy boot.scr, ... whatever it finds. The configuration structure is borrowed from the syslinux project.This was done so that distributions can continue to use their existing tools, only some keywords for the devicetree treatment were added because they were not necessary in the x86 world. But good luck convincing the distributions to take over your desired extensions. Not that I know, so my rename extlinux.conf solution. And even then it falls back on legacy boot, uboot exhausts all possibilities to start the system somehow. Multisystem configurations are not the standard in the embedded world. And now the absolute killer argument: When can I use your planned solution out-of-the-box for each distribution. Mine has been working productively for years. And I can switch other distributions to distro-boot by just adding an /extlinux/extlinux.conf, as we proved with our experiment because everything else necessary is obvious already available. All other measures where only there to show what new possibilities arise with distro-boot. Or can you explain to me, for example, how to install a second Armbian kernel in your system with the legacy boot system and select at boot time. During the experiment I have already identified some points that can better support distro-boot due to small modifications, but do not affect legacy boot. E.g. the kernel package: I let you put some files from the boot directory to /usr/lib/modules/5.15.31-rockchip64, which you eventually did.This served to show you how I am used to how fedora binary kernel packages create these directories. The downstream installation routine then copies necessary components into a possible /boot or ESP directory depending on the boot method used. The kernel binary package is therefore generic and can be used for different boot methods like syslinux, extlinux, grub, uefi, ... , only the install routine decides the details where to put the boot artifacts. DRY If you now modify the Armbian kernel deb package accordingly, the kernel package is already ready for multiple kernel installations and if your ESP is available only the install routine must be added appropriately. And of course disto-boot can use it out-of-the-box for multiple simultaneous kernel installations.
  13. In this exercise, we will work on two rootfs. To show that the distribution used is not important, I will use my fedora image for demonstration. First step, setup: Create a second partition on the same storage device. Choose a size as you want to use it in later use, but at least so large that the selected rootfs fits into it. Gain access to the desired image. Either via installed media or via loop-mount. Use dd to transfer the rootfs partition to the partition you created earlier. Resize (resize2fs) the copied file system to match the partition size. Second step, configuration: My fedora image already uses distro-boot, but the extlinux.conf needs a little adjustment. So mount the second partition (/mnt/second) and edit /mnt/second/extlinux/extlinux.conf. Update all PARTUUID values by the actual one. If you have used the second primary MBR partition entry this would be 8b029f90-02. But for safety you should check it (lsblk -o +PARTUUID). If you use a rootfs without distro-boot support, copy the current extlinux.conf, but also adjust all PARTUUID values. Also copy all relevant kernel packages from /usr/lib/modules. Make sure that they are portable kernel packages, i.e. do not use an intrd line (initramfs). If you want to use the original kernel, you should already know what to do. Prepare kernel package in /mnt/second/usr/lib/modules/${original-kernel}/ and create boot option in extlinux.conf. You should note that an append line matching the original kernel is to be used (cat /proc/cmdline running in the original system or extracted from the legacy boot artifacts). Third step, use: In standalone mode, the systems are used alternately and independently. To do this, set the MBR boot flag with your preferred partition manager (e.g. fdisk "a" command). The boot flag directs distro-boot in which partition to look for the extlinux.conf. If none is set, the first partition is chosen. In combined mode, dependencies of the systems involved arise, but you can start them from a single boot menu. To do this, the relevant unmodified extlinux.conf boot options from the secondary system are apended to the extlinux.conf of the distro-boot boot partition. The distro-boot boot partition is the one in which the used extlinux.conf is found. The dependency that arises during use is the necessity that the kernel packages used must be present both in the boot partition and the rootfs of the used system. They must therefore be copied over, and in the case of updates, attention must be paid to appropriate duplication. This is necessary because disto-boot expects kernel artifacts in the partition where extlinux.conf was found and a booting system expects kernel modules in the mounted root-file-system. The extlinux.conf and the extlinux directory in the secondary systems rootfs are not required for this mode and do not need to exist. And now the whole thing when the systems are on different drives. Now it gets complicated, it works the same as before only now the first component of the PARTUUID is different 😉 The standalone mode may not be possible. It only works if distro-boot also scans the corresponding drive for extlinux.conf. To bypass a drive in front of it in the scan priority list, deactivate the distro-boot there by renaming the extlinux.conf (extlinux.conf-disabled). Of course, you have to also deactivate a legacy boot there by renaming the corresponding script file. The combined mode works always. It's like legacy boot with a separate boot partition, but boot and system partition don't even need to reside on the same drive. If you want to do a real experiment, take a completely empty SD card (dd if=/dev/zero of=/dev/${to-clean-sd-card}), and copy only the firmware (uboot) artifacts starting at sectors 64 and 16384 to it. Now insert your Armbian system SD card into a USB card reader and then insert it into a USB port on your HELIOS64. When the previously prepared firmware SD card is in the SD card slot it should be booting your system.
  14. 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 Helios64, 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
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.
  21. For standard kernel updates, this is not even strictly necessary. We will see this as soon as my offered extlinux.conf works.
  22. 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
  23. 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.
  24. 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.
  25. 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).
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines