+- PINE64 (https://forum.pine64.org)
+-- Forum: PinePhone Pro (https://forum.pine64.org/forumdisplay.php?fid=177)
+--- Forum: PinePhone Pro Software (https://forum.pine64.org/forumdisplay.php?fid=179)
+--- Thread: Boot code (/showthread.php?tid=16311)
Boot code - Emilio - 03-14-2022
Can anybody tell me what exactly
Does this sentence mean?
booti ${kernel_addr_r} - ${fdt_addr_r};
RE: Boot code - wibble - 03-17-2022
https://u-boot.readthedocs.io/en/latest/usage/booti.html
RE: Boot code - Emilio - 03-17-2022
(03-17-2022, 03:12 AM)wibble Wrote: https://u-boot.readthedocs.io/en/latest/usage/booti.html
Dear professor
I asked the question after reading the boot and the pages you send me
I only write the last code but this is the
Whole one
if load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} /initramfs-linux.img; then
gpio set 157
booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
else
gpio set 158
booti ${kernel_addr_r} - ${fdt_addr_r};
fi;
And what I understand is that if the if statement goes well load the kernel otherwise what?
exit the boot? Remove some code loaded?
RE: Boot code - wibble - 03-17-2022
If loading the initramfs from file succeeds then boot the kernel with the initramfs and device tree, otherwise only boot the kernel with the device tree. I don't know what the gpio set is doing - I'd guess the LED but it could be something else.
RE: Boot code - Emilio - 03-18-2022
(03-17-2022, 11:45 AM)wibble Wrote: If loading the initramfs from file succeeds then boot the kernel with the initramfs and device tree, otherwise only boot the kernel with the device tree. I don't know what the gpio set is doing - I'd guess the LED but it could be something else.
Could you explain the full boot file for us to understand,?
RE: Boot code - wibble - 03-19-2022
I've got the PinePhone not the Pro, and haven't looked into the uboot details, but if you post the file or a link to it I'll have a go. I last looked at uboot configs in detail back in the openmoko days, but it looks like the concepts haven't changed much.
RE: Boot code - Emilio - 03-19-2022
(03-19-2022, 05:14 AM)wibble Wrote: I've got the PinePhone not the Pro, and haven't looked into the uboot details, but if you post the file or a link to it I'll have a go. I last looked at uboot configs in detail back in the openmoko days, but it looks like the concepts haven't changed much.
Thanks. I inserted de SD card in my laptop and enter de fat partition and copied
The boot to my desktop. I will copy it here in my android smartphone and paste it here.
#
# /boot/boot.txt
# After modifying, run "ppp-uboot-mkscr" to re-generate the U-Boot boot script.
#
#
# This is the description of the GPIO lines used in this boot script:
#
# GPIO #105 is GPIO3_B1, or RK3399 ball C27, which controls the vibrator motor
# GPIO #154 is GPIO4_D2, or RK3399 ball AH3, which controls the red part of the multicolor LED
# GPIO #157 is GPIO4_D5, or RK3399 ball AJ3, which controls the green part of the multicolor LED
# GPIO #158 is GPIO4_D6, or RK3399 ball AG4, which controls the blue part of the multicolor LED
#
gpio set 105
gpio set 154
# Set root partition to the second partition of boot device
part uuid ${devtype} ${devnum}:1 uuid_boot
part uuid ${devtype} ${devnum}:2 uuid_root
setenv bootargs loglevel=4 console=tty0 console=${console} earlycon=uart8250,mmio32,0xff1a0000 consoleblank=0 boot=PARTUUID=${uuid_boot} root=PARTUUID=${uuid_root} rw rootwait quiet audit=0 bootsplash.bootfile=bootsplash-themes/manjaro/bootsplash
if load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} /Image; then
gpio clear 105
if load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} /dtbs/${fdtfile}; then
if load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} /initramfs-linux.img; then
gpio set 157
booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
else
gpio set 158
booti ${kernel_addr_r} - ${fdt_addr_r};
fi;
fi;
fi
# EOF
_-----
The gpios are clear. First you hear the sound of motor and inmedistely there's a red led and then
The sound of motor stops and the led become green. Of course if the "if" statements are ok. And
It is these if statements the I would like to understand. I Imagine that
Are variables containing values given by the ROM boot loader
RE: Boot code - wibble - 03-20-2022
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/usage/environment.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/usage/partitions.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.