I will look at that code and see if there is a way I can make it “automatic”, given that my goal is to not need a monitor and keyboard connected to get things set up.
I’ve found an ugly way to make this work. If I delete boot.scr
and add console=ttyS0,115200n8
to all of the grub loader strings I get control via serial console. I don’t know if there is a better/easier way to accomplish this, but wanted to report my progress.
Just to check, are you saying that when you follow @arne_f suggestion when doing the install
that your serial console does not work for the following boot cycles?
Sorry for confusion. I’ve been focused on not needing a monitor and keyboard from the start. Given that the default grub configuration is not serial console, Arne’s suggestion would require at least one cycle using a keyboard and monitor.
What I was trying to say is that if I hack up the grub configuration on my SD Card prior to inserting it, I can get the serial console working without needing a monitor or keyboard. This is not ideal, but at least proves that the only thing missing is the additional kernel configuration option in order to make serial console work.
What would be ideal would be setting it up such that if SERIAL_CONSOLE in uenv.txt is ON that the serial console grub environment would be selected by default. Either that or figuring out how to pass the same kernel parameters without requiring grub.
I cloned the IPFire 2.x and was trying to figure out where the boot code is at in the repo, but thus far not finding it. Are there any pointers or documentation about how the boot stuff is set up? I’m just wondering what options there are and how things are stitched together. I see, for example, the boot.cmd
and that it appears to be setting up the console, but I don’t see how grub is set up as the fallback. (FWIW… I’ve never dug into the boot sequence for a Pi, so this is a bit of a stretch for me)
I opened up the GitHub IPFire code (because I am more familiar with GitHub) at:
and I did a search for grub
.
https://github.com/search?q=repo%3Aipfire%2Fipfire-2.x%20grub&type=code
and then serial
and found this:
Is this what you are long for??
EDIT: or maybe this:
Thanks @jon … those definitely look like potentials. I’m realizing that I was also being kind of stupid by not trying to search the code base. I was clicking through the folder structure trying to see if something “looked right”. Thanks for the pointers!
Grub should send the output of first boot to both (Keyboard/Monitor and serial console). So you can select the third option without keyboard and monitor.
The problem is that uENV.txt is ignored by grub. (uENV stands for u-boot Environment.)
I think I’ve probably gone all the way down the rabbit hole of u-boot at this point. I’ve been able to create a boot.scr file that properly boots into serial console without monitor being required. In addition, this works to pick the correct fdt_addr for this Pi 4B board revision. For console, this works:
if test "${fdtfile}" = "broadcom/bcm2837-rpi-3-b.dtb"; then
setenv console ttyS1,115200n8;
else
if test "${fdtfile}" = "broadcom/bcm2711-rpi-4-b.dtb"; then
setenv console ttyS0,115200n8;
else
setenv console ttyAMA0,115200n8;
fi;
fi;
The address is:
setenv booti_fdt_addr ${fdt_addr_r};
if test "${board}" = "rpi"; then
if test ${cpu} = "armv8"; then
if test "${fdtfile}" = "broadcom/bcm2711-rpi-4-b.dtb"; then
if test ${board_revision} = 0xC03114; then
setenv booti_fdt_addr ${fdt_addr};
fi;
fi;
fi;
fi;
bootz ${kernel_addr_r} ${ramdisk_addr} ${fdt_addr_r};
booti ${kernel_addr_r} ${ramdisk_addr} ${booti_fdt_addr};
bootz ${kernel_addr_r} - ${fdt_addr_r};
booti ${kernel_addr_r} - ${booti_fdt_addr};
Obviously, this only works for a single board revision. Unfortunately the test
command doesn’t make a multiple test particularly easy.
@arne_f - Would there be any interest in carrying some of this forward into the IPFire core? If so, what would be required?
I still not fully understand how this may work. For me this looks like an error.
You change only the address where the kernel is serching for the ftd but not on the place where the file is loaded. Looks like there is a fdt on this memory location from u-boot. I think the dtb provided by kernel-6.6.x is simply not support the revision but the version compiled into u-boot does. I will compare this devicetrees…
If you boot this did you get the sensor values of the soc?
The test
command is the same as […] in bash. You can try:
setenv booti_fdt_addr ${fdt_addr_r};
if [ "${board}" = "rpi" ] && [ ${cpu} = "armv8" ] && [ "${fdtfile}" = "broadcom/bcm2711-rpi-4-b.dtb" ] && [ ${board_revision} = 0xC03114 ]; then
setenv booti_fdt_addr ${fdt_addr};
fi;
You can do the same using the test
key word.
@arne_f - I won’t claim to understand the address stuff at all. I got that from Raspberry Pi 4 Model B Rev 1.5 - error -5 whilst initialising SD card - #8 by wiesel . I guess what I’m trying to do is to find a way to make this part of the standard installation, so I’ve been playing with boot.cmd to integrate the calculation.
I will give this a try.
Nick - I tried to use your syntax, but I’m seeing an error with that:
Unknown command '[' - try 'help'
The mkimage
command is fine with the syntax, but it seems like running it on the Pi won’t work.
Any tips?
Craig
Is it a bash script? Or some other shell or what?
This is a U-Boot script. Not even sure it is a full-fledged shell, although I have read that sometimes they use Hush shell.
I missed that. It is beyond my knowledge. It just looked like bash. If &&
still works as and
, can you do:
setenv booti_fdt_addr ${fdt_addr_r};
if test "${board}" = "rpi" && test ${cpu} = "armv8" && test "${fdtfile}" = "broadcom/bcm2711-rpi-4-b.dtb" && test ${board_revision} = 0xC03114; then
setenv booti_fdt_addr ${fdt_addr};
fi;
But is it worth it if your nested ifs work?
Maybe not. However, I was planning to submit a patch that included not only my board identifier, but the others that appear to have the same need to use a different address. The other part I don’t know about all of this is what limits, if any, there are in size of this script. I would hope the fact that it is “compiled” means that it can be a larger script without impacting the execution.
@arne_f - I created a patch, trying to follow all of the documentation for properly submitting the patch. I must be doing something wrong. I attempted to send the patch to development-owner@lists.ipfire.org, but it bounced back with this error:
The message is not from a list member
Is there something more I need to do to submit a patch? I did install Patchwork, but it didn’t look like that was involved in submitting patches.
did you set up an account for the List?
https://lists.ipfire.org/postorius/lists/development.lists.ipfire.org/
-and-
Can you log in?
https://lists.ipfire.org/accounts/login/?next=/postorius/lists/development.lists.ipfire.org/