Jump to content

The boot process and various devices


Recommended Posts

1 hour ago, usual user said:

UUID always requires user space support because there is no native support for this and thus always an initramfs

This is untrue.  The Helios64 can find the uuid of ext4 root without initrd.  However, yes, that's probably because ext support is compiled in.

 

1 hour ago, usual user said:

Keyword "bootflow", and also UEFI systems are to be supported.

Hey, great!  I look forward to it.

 

1 hour ago, usual user said:

I prefer the way mainline uboot goes, each distribution uses its own configuration and uboot uses distro-boot, uefi-boot, lecacy boot.scr

I can understand it.  Maybe with additional experience, I'll learn it too.

 

1 hour ago, usual user said:

When can I use your planned solution out-of-the-box for each distribution

Come on, you know the answer is "probably never".  I'm in the wishes and dreams stage, and the learning what the problem even looks like.  I do appreciate your guidance on other available solutions.  I definitely like the extlinux menu option situation, where the system can know its own list of kernels and cmdlines and present them to u-boot (and through u-boot to the user), I just want to know how to deconflict it with other distros.  And yes, that's very unusual for embedded boards... but doesn't something like the Station P2 want to be more like a PC?  Everyone's looking at the RK3588 boards as "desktop replacements" (in many years).

 

1 hour ago, usual user said:

only the install routine decides the details where to put the boot artifacts

Yeah, that seems like a good idea.  Armbian uses Debian's kernel packages.  Deviating from their standards should be done in a controlled way - And that's the install routine, as you said.

 

Thanks a lot for the education.

Link to comment
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

22 hours ago, ManoftheSea said:

This is untrue.  The Helios64 can find the uuid of ext4 root without initrd.

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.

Spoiler
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT      PARTUUID
sda            8:0    1  29,8G  0 disk.................
├─sda1         8:1    1   512M  0 part                 00000013-01
└─sda2         8:2    1  28,9G  0 part                 00000013-02
sdb            8:16   0 931,5G  0 disk.................
├─sdb1         8:17   0     2G  0 part                 50000002-01
├─sdb2         8:18   0     6G  0 part                 50000002-02
└─sdb3         8:19   0   900G  0 part /mnt/ssd-002-03 50000002-03
mmcblk2      179:0    0  14,6G  0 disk.................
mmcblk2boot0 179:8    0     4M  1 disk.................
mmcblk2boot1 179:16   0     4M  1 disk.................
mmcblk1      179:24   0  29,7G  0 disk.................
└─mmcblk1p1  179:25   0    20G  0 part /               696d6701-01
zram0        252:0    0   2,8G  0 disk [SWAP]..........
nvme0n1      259:0    0 931,5G  0 disk.................
├─nvme0n1p1  259:1    0     2G  0 part                 50000003-01
├─nvme0n1p2  259:2    0     6G  0 part                 50000003-02
└─nvme0n1p3  259:3    0   900G  0 part                 50000003-03

 

And since the PARTUUID use has worked equally since the beginning, I have never questioned it again.

 

22 hours ago, ManoftheSea said:

I just want to know how to deconflict it with other distros.

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.

 

22 hours ago, ManoftheSea said:

Armbian uses Debian's kernel packages.

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.

Link to comment
Share on other sites

22 hours ago, ManoftheSea said:

I'm in the wishes and dreams stage


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?

Link to comment
Share on other sites

u-boot has a configuration option "CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET".  If I understand it correctly, it says the number of sectors to skip after jumping over MBR.  If set to 33, I believe that means uboot will skip over the region used by the gpt, and begin at sector 34.  Not needed on rockchips which load from 64 to begin, but useful for amlogic which start with sector 0.

 

Even better, it appears u-boot can load from a specific partition type from mmc/sd.  This ought to be set as the BIOS type.  I'm going to have to try that.  (21686148-6449-6E6F-744E-656564454649)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

And the story goes on. I decided to put my ODROID-M1 into operation. Initial research shows that the SPI flash firmware supports distro-boot to a certain extent, but it is so poorly configured that it is not really usable. I then used the image of @rpardini to test that the hardware works. He uses extlinux.conf, so the minimum requirements for distro-boot must be met. In the first step, of course, I changed it to my structure. Then I built my kernel package with @tobetter his commit diff and added it to the rootfs. To my surprise, my very first attempt worked immediately. The image only starts as a command line version, so I started the SD card I used for my Odroid-N2+ bringup. Unfortunately, it only runs up to the greeter screen, as I have long forgotten the "secure password" that Armbian enforces at the first start. My fedora also works in command line mode, but as soon as I start a graphical user, the kernel explodes. I did not expect this to be any different, because mali support is still in its infancy.
Guess now I have to stay closer to the rk3568 development.
I used the @rpardini image as an ESP partition without FAT32 and UEFI. And all this was only possible with the attached extlinux.conf and my kernel package.

Link to comment
Share on other sites

I'll try to hijack this topic with my problems migrating a working Armbian from one SBC to another - Orange Pi One to Orange Pi PC and vice a versa. 

The SBCs have very small differences but at least they have so it's a good and (almost) safe experiment.

So far I succeeded to use the appropriate dtb file for every SBC as easy as adding the parameter fdtfile= to the file /boot/armbianEnv.txt

It works on the level to detecting the right hardware in the linux but u-boot is still detecting the old model board.

In the linux the /proc/device-tree/model is showing the right model and the hardware is working as it should.

But some cosmetic issues exist - armbian-config is still showing the old board and the MOTD on ssh login has the wrong model banner (I suspect that this info is taken from the file armbian-release).

 

So my questions:

1. Do you know what I have to do to change the u-boot to show the right board? (I tried menu config but saveenv failed)

2. What is exactly the process of detecting the right board (perhaps it's done in the linux image which is downloaded in ready state and compiled for that specific board) either in first run or in the compile image stage?

3. Can we make changes to already installed linux to change those small discrepancies for more comfortable feeling (as more issues seem cosmetic than real)?

 

 

The changes between the SBCs I mentioned are small (at least the SoC is same) but some of them are important:

- the ports are different (OPi One has two USBs instead of 4 in OPi PC, audio and IR connectors are missing)

- voltage regulator is missing on OPi One

Link to comment
Share on other sites

4 hours ago, surenz said:

Do you know what I have to do to change the u-boot to show the right board? (I tried menu config but saveenv failed)

I would not be surprised to find these are compiled in to the u-boot image.  For Rockchip boards, my understanding is that u-boot is on the SD card at sectors 64-32767.  You should generate a u-boot image for your board to write over that part of your SD card.  My guess is something like dd skip=64 seek=64 count=32703 if=new-board-armbian.img of=/dev/sdX

 

5 hours ago, surenz said:

What is exactly the process of detecting the right board (perhaps it's done in the linux image which is downloaded in ready state and compiled for that specific board) either in first run or in the compile image stage?

u-boot is told upon compile what board it's being built for, and there are some dtb modification routines that change the file read from disk before handing the memory location to the linux kernel.  I don't know how much modification for any given board.  Linux just takes the devices from the dtb.  As for the login text splash, yes, that's in armbian specific files on the image, which I think are in the armbian-bsp-board packages.

Link to comment
Share on other sites

2 minutes ago, ManoftheSea said:

I would not be surprised to find these are compiled in to the u-boot image.  For Rockchip boards, my understanding is that u-boot is on the SD card at sectors 64-32767.  You should generate a u-boot image for your board to write over that part of your SD card.  My guess is something like dd skip=64 seek=64 count=32703 if=new-board-armbian.img of=/dev/sdX

 

The u-boot can be reflashed very easily and secure with the armbian-config but it takes the image from some package which is downloaded from apt repo. Of course those packages are still not updated so they don't change even if flashed.

Link to comment
Share on other sites

Just as update I can say that the cosmetic issues in my previous question 3 are resolved with the change of BOARD_NAME and BOARD in  /etc/armbian-release to comply with the real board.

The only problem I see is the message at the top of the file PLEASE DO NOT EDIT THIS FILE and if the file is updated during some of the regular updates.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...