On Mon, Sep 28, 2015 at 6:55 PM, Rick Mann <[email protected]> wrote: > >> On Sep 28, 2015, at 16:48 , Robert Nelson <[email protected]> wrote: >> >> On Mon, Sep 28, 2015 at 11:46 PM, Rick Mann <[email protected]> wrote: >>> >>>> On Sep 28, 2015, at 16:43 , Robert Nelson <[email protected]> wrote: >>>> >>>> On Mon, Sep 28, 2015 at 11:11 PM, Rick Mann <[email protected]> wrote: >>>>> 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.. > > 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 :-) ). > > 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, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
