>
> *check_dtb=if test -n ${dtb}; then setenv fdtfile ${dtb};fi;*
>Actually now that I think on this, I believe this variable to be set, or settable from the second stage uEnv.txt file. On Tue, Apr 12, 2016 at 9:20 AM, William Hermans <[email protected]> wrote: > So . . . > william@beaglebone:~$ cat /uEnv.txt > ##These are needed to be compliant with Angstrom's 2013.06.20 u-boot. > > loadaddr=0x82000000 > fdtaddr=0x88000000 > rdaddr=0x88080000 > > <snip> > > *loadxfdt=load mmc 0:1 ${fdtaddr} /boot/dtbs/${uname_r}/${fdtfile}* > > <snip> > > *check_dtb=if test -n ${dtb}; then setenv fdtfile ${dtb};fi;* > > <snip> > > Ok, in order to understand fully what is happening here, we'd need to read > through the source for uboot, But I can in short tell you with reasonable > certainty what is going on here. > > > > *loadxfdt=load mmc 0:1 ${fdtaddr} /boot/dtbs/${uname_r}/${fdtfile}* > This is attempting to load the board device tree file from the first > partition of device mmc0. ${fdtaddr} is a variable created in this file > near the top, so we know what this is. ${fdtfile} however is not defined in > this file so we have to assume it is defined by uboots executable. How does > uboot do this ? We'd have to read the source code to be 100% sure, but like > I said I am reasonably sure that uboot reads from the eeprom, to make this > determination. > > > > > *check_dtb=if test -n ${dtb}; then setenv fdtfile ${dtb};fi;* > This, I'm not sure exactly what is going on. What is obvious however that > when some condition is met( this is the part im not sure of ), then the > environment variable fdtfile is set to environment variable dtb. I can make > several assumptions here what exactly ${dtb} *is*, but I would not feel > comfortable without reading through uboots source code . . . > > Anyway, "we" can bypass a lot of this behavior simply by hard coding the > value for the required device tree file. However, if one burns up their > board( and this is possible )in the process. Then that is their own > responsibility. > > On Tue, Apr 12, 2016 at 8:49 AM, William Hermans <[email protected]> > wrote: > >> #1 You're writing *what* to the eeprom ? >> #2 Which Linux image are you attempting to use ? >> #3 Which TI SDK ? >> >> So the Debian images now days I believe go by what is in eeprom, to >> decide which board file to load at boot. No properly formatted, or >> recognized eeprom, no board file detection, no boot. >> >> On Tue, Apr 12, 2016 at 5:13 AM, Sachin Sagar <[email protected]> >> wrote: >> >>> Hi, >>> >>> I am able to read/write the data from beagle bone black A5 after >>> disabling the WP . But after power cycle the board it is not getting >>> booted. Iam not getting why it is happening like this. Iam using ti SDK >>> >>> -- >>> 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. >>> >> >> > -- 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.
