Preflighting /boot/uEnv.txt?

Robert, do you think it would be possible to write a bash script that could "preflight" uEnv.txt to let you know if it would successfully boot? More than once this weekend, while trying to downgrade to 3.8, I left uEnv.txt in a bad state and U-boot couldn't continue. It seems that all those mistakes could've been caught by a script before booting.

I just don't know how easy it would be to maintain such a script, as U-boot changed, it would have to change.

Just a thought…

#!/bin/bash

. /boot/uEnv.txt

if [ ! -d "/boot/dtbs/${uname_r}/" ] ; then
   echo "invalid uname_r in /boot/uEnv.txt"
fi

Regards,

Heh, it's more than that. For example, I had a dtb= set that it couldn't find, so it choked on that. I also have to remember to switch between 3.8-style capemgr enable/disable and 4.1-style. Those kinds of things.

I might try to figure something out. Is it possible to get at the U-boot environment (bootcmd, find_ftd, uname_boot, etc?) from the logged-in bash shell after boot is complete?

Robert, do you think it would be possible to write a bash script that could "preflight" uEnv.txt to let you know if it would successfully boot? More than once this weekend, while trying to downgrade to 3.8, I left uEnv.txt in a bad state and U-boot couldn't continue. It seems that all those mistakes could've been caught by a script before booting.

I just don't know how easy it would be to maintain such a script, as U-boot changed, it would have to change.

#!/bin/bash

. /boot/uEnv.txt

if [ ! -d "/boot/dtbs/${uname_r}/" ] ; then
  echo "invalid uname_r in /boot/uEnv.txt"
fi

Heh, it's more than that. For example, I had a dtb= set that it couldn't find, so it choked on that. I also have to remember to switch between 3.8-style capemgr enable/disable and 4.1-style. Those kinds of things.

then add:

if [ ! "x${dtb}" = "x" ] ; then
if [ ! -f /boot/dtbs/${uname_r}/${dtb} ] ; then
echo error
fi
fi

I might try to figure something out. Is it possible to get at the U-boot environment (bootcmd, find_ftd, uname_boot, etc?) from the logged-in bash shell after boot is complete?

For awhile i was defaulting to the default *.dtb when a dtb lookup
failed, but then a user couldn't understand why his "dtb=" override
wasn't working.. right now i just default to "umsboot" to give you
full eMMC access over otg to fix it..

Regards,

Which is great, but I can't get it to work, and wouldn't help in my current situation (I'm at work, the BBB is at home, and I'm logging in remotely :slight_smile: ).

I can build a script that mimics the steps U-boot goes through and emits errors for things, but I thought it could be made more accurate if it could look at the current U-boot environment.

yeah, not sure why printenv is causing that processor dump..

I had a big diagram setup somewhere, i'll try and update with the
newer /boot.scr /boot/boot.scr that debian wanted added..

Regards,