03-20-2022, 07:40 AM
The environment docs cover several of the variables like the ram addresses for kernel, ramdisk and devicetree. For the others you'll have to check for a separate environment variable file, or check the source for the default values for those variables.
https://u-boot.readthedocs.io/en/latest/...nment.html
It's a fair guess that ${devtype} and ${devnum} are the type and number of the device uboot started from, but they might be in an environment file. If you wanted to use the uboot on the emmc to load from a partition on the uSD, or a different partition on the same device, you could specify different values here. tow-boot will be doing something similar to boot from different devices based on button presses.
The 'part' command doesn't seem to be fully documented - it's in an example on the page about partitions, but its operation isn't explained. From the context I suspect it is being used to read the uuid of the boot and root partitions and set the variables uuid_boot and uuid_root respectively. These are then used in setting the bootargs that will be sent to the kernel when it gets booted later. It's curious that the boot partition is hardcoded as 1 here rather than using ${distro_bootpart} which we'll see used a bit later.
https://u-boot.readthedocs.io/en/latest/...tions.html
I hope the kernel bootargs don't need explaining here - they're fairly normal, apart from perhaps the console and earlycon bit.
Now we get to the nested ifs which are about trying to load in turn the kernel, the devicetree and the initramfs. If the kernel load fails then there's nothing more to do, and you 'll be stuck with a red light and a vibrating phone. If the kernel load succeeds then the vibration stops and the devicetree load is attempted. If that succeeds then we're at the previous explanation, but if it fails we're stuck as both the kernel and the devicetree are needed to boot.
https://u-boot.readthedocs.io/en/latest/...nment.html
It's a fair guess that ${devtype} and ${devnum} are the type and number of the device uboot started from, but they might be in an environment file. If you wanted to use the uboot on the emmc to load from a partition on the uSD, or a different partition on the same device, you could specify different values here. tow-boot will be doing something similar to boot from different devices based on button presses.
The 'part' command doesn't seem to be fully documented - it's in an example on the page about partitions, but its operation isn't explained. From the context I suspect it is being used to read the uuid of the boot and root partitions and set the variables uuid_boot and uuid_root respectively. These are then used in setting the bootargs that will be sent to the kernel when it gets booted later. It's curious that the boot partition is hardcoded as 1 here rather than using ${distro_bootpart} which we'll see used a bit later.
https://u-boot.readthedocs.io/en/latest/...tions.html
I hope the kernel bootargs don't need explaining here - they're fairly normal, apart from perhaps the console and earlycon bit.
Now we get to the nested ifs which are about trying to load in turn the kernel, the devicetree and the initramfs. If the kernel load fails then there's nothing more to do, and you 'll be stuck with a red light and a vibrating phone. If the kernel load succeeds then the vibration stops and the devicetree load is attempted. If that succeeds then we're at the previous explanation, but if it fails we're stuck as both the kernel and the devicetree are needed to boot.
