The boot process and various devices

[balbes150]

19 часов назад, iav сказал:

I run headless, with serial console

Version 20221013 with kernel 6.0.1. First of all, I am interested in how the UART console works in EFI mode. On my models (Firefly\Station) - it works well and I can control the selection of the system\core both on the TV screen (via USB keyboard) and via the UART console (if there is nothing connected to HDMI). By the way, I am also interested in installing multiple cores and the ability to choose (only the cores of the media-curren and media-edge versions are suitable for this)

[ManoftheSea]

@balbes150Are you writing an SD image that has u-boot for multiple rockchip processors, multiple allwinner and amlogic processors, all at the same time?  This is what I mean by a universal image, and it's my understanding that putting the SPL and maybe TPL on SD causes irreconcilable conflicts between different processors. 

 

 

[iav]

6 hours ago, balbes150 said:

Version 20221013 with kernel 6.0.1.  I am interested in how the UART console works in EFI mode.

serial console works as usual. grub menu selectable, in edit mode text can be edited.

with 6.0.1 system cooler runs on full speed, armbian-config not provide processor frequences to choose min and max.

[Igor]

41 minutes ago, iav said:

armbian-config not provide processor frequences to choose min and max.

This fix already inside?

[iav]

47 minutes ago, Igor said:

This fix already inside?

yes

Quote

root@helios64:~# ls /sys/devices/system/cpu/cpufreq/
policy0  policy4

 

[balbes150]

13 часов назад, ManoftheSea сказал:

Are you writing an SD image that has u-boot for multiple rockchip processors, multiple allwinner and amlogic processors, all at the same time?  This is what I mean by a universal image, and it's my understanding that putting the SPL and maybe TPL on SD causes irreconcilable conflicts between different processors. 

How do you imagine writing a lot of different data into the same sectors\bits? no, the desired loader option is recorded (immediately after recording the image), specific for a specific model. To launch from USB, it is assumed that any system has already been installed on the device (or u-boot update), with support for the necessary changes in u-boot for direct launch from USB, or there is a factory u-boot with support for direct launch from USB.

The option that you describe (an attempt to place and USE many loaders on the same media at once) is basically impossible. Initially (during assembly), the universal image does not have any loaders at all in the sectors where they are usually placed. Adding the desired version (for a specific model) is already performed by users, when preparing \ recording the image to the media (sequential recording - the universal image is recorded first and the loader is recorded immediately on top of it).

By the way, I understand that you have not tried to run the images to which I gave a link in this topic for Helios64? (it's better to run it once and see how it works) 

 

12 часов назад, iav сказал:

serial console works as usual. grub menu selectable, in edit mode text can be edited.

This is the main thing that interested me in this image. I have no task to provide full support for all functions with the new kernel (this is not possible without hardware, I do not have Helios64 for such procedures).

 

11 часов назад, Igor сказал:

This fix already inside?

The reason is the lack of patches for Helios 64 in my EDGE kernel (I do not know what is needed there).

[ManoftheSea]

7 hours ago, balbes150 said:

the universal image does not have any loaders

Then it's not a universal image.  It has to be customized to the board, because the board doesn't respect a standard that allows going to a universal image.

 

I suppose it depends on how we define universality.  My home directory can be used on multiple architectures, but ARM64 isn't gonna run on AMD64.  UEFI is bytecode that's supposed to launch on any architecture, but then the kernel has to match the architecture.  The UEFI apps are deconflicted by NOT using the same bits, but having separate paths for where there are necessary differences.  u-boot has to match the processor, but it can then launch a universal UEFI app that can then load an architecture specific kernel.  But even then, there's not a single arm64-5.19.x that carries patches for all the boards, right?

7 hours ago, balbes150 said:

I understand that you have not tried to run the images to which I gave a link in this topic for Helios64?

I haven't.  Why did this specific board discussion get tacked on to my thread about more general universality?  Anyway, I might be able to try it this weekend.

[balbes150]

16 часов назад, ManoftheSea сказал:

Then it's not a universal image.

Exactly the opposite.

 

16 часов назад, ManoftheSea сказал:

I suppose it depends on how we define universality.

This is the universal image, it is used without changes or additional settings. i.e. we do not change the image itself in any way. Adding a loader is not always required and does not change the "universal essence" of the image. If the device already has (from the factory or a one-time bootloader update/replacement procedure was performed to bring it to the standard procedure for launching universal images), then the universal image is used "as is" immediately after writing to the media, this is clearly visible when using USB media. I can use the same media without reconfiguration on dozens of different models with the same architecture (RK+AW+etc). The main thing is that the kernel has everything necessary for specific models (DTB drivers, etc.)

 

17 часов назад, ManoftheSea сказал:

UEFI is bytecode that's supposed to launch on any architecture,

You're wrong. EFI code is architecture-bound. The binary files for each architecture are different. But the settings files can be shared.

 

https://github.com/150balbes/build/blob/armbian-tv/extensions/grub.sh#L37

https://github.com/150balbes/build/blob/risc-v/extensions/grub-riscv64.sh#L25

 

17 часов назад, ManoftheSea сказал:

But even then, there's not a single arm64-5.19.x that carries patches for all the boards, right?

There is. More precisely, earlier I used a universal core (RK+AW+AML+ NVIDIA and other platforms can be added) and if desired, you can return to this option again. I just removed the "versatility" and limited myself to two platforms - RK+NVIDIA, because it makes no sense to spend resources on maintaining \assembling such an option if it is not used by additional platforms.