written data successfully to the eeprom, but after power up board is not booting.

69 views
Skip to first unread message

Sachin Sagar

unread,
Apr 12, 2016, 8:13:41 AM4/12/16
to BeagleBoard
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

William Hermans

unread,
Apr 12, 2016, 11:49:19 AM4/12/16
to beagl...@googlegroups.com
#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 <sachins...@gmail.com> 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 beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

William Hermans

unread,
Apr 12, 2016, 12:20:22 PM4/12/16
to beagl...@googlegroups.com
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.

William Hermans

unread,
Apr 12, 2016, 12:25:04 PM4/12/16
to beagl...@googlegroups.com
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.

Robert Nelson

unread,
Apr 12, 2016, 12:29:18 PM4/12/16
to Beagle Board
On Tue, Apr 12, 2016 at 11:24 AM, William Hermans <yyr...@gmail.com> wrote:
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.


William Hermans

unread,
Apr 12, 2016, 12:36:04 PM4/12/16
to beagl...@googlegroups.com
Hi Robert,

Thanks for the reply. So the code you've linked there seems to be in relation to reading from the eeprom, making assumptions based on values in the eeprom, and setting the PMIC values accordingly ?

So if I understand this correctly, this means *if* no eeprom *then* no PMIC settings ? Re-reading the source again . . .

--

Robert Nelson

unread,
Apr 12, 2016, 12:39:15 PM4/12/16
to Beagle Board
On Tue, Apr 12, 2016 at 11:35 AM, William Hermans <yyr...@gmail.com> wrote:
Hi Robert,

Thanks for the reply. So the code you've linked there seems to be in relation to reading from the eeprom, making assumptions based on values in the eeprom, and setting the PMIC values accordingly ?

So if I understand this correctly, this means *if* no eeprom *then* no PMIC settings ? Re-reading the source again . . .

Correct.. if no eeprom, the boot stops very early and just bail's..

Regards,

William Hermans

unread,
Apr 12, 2016, 12:42:39 PM4/12/16
to beagl...@googlegroups.com
Correct.. if no eeprom, the boot stops very early and just bail's..

Regards,

Ah, so it used to be that we could manually set the device tree board file. I guess this is no longer possible ?

--

Robert Nelson

unread,
Apr 12, 2016, 12:48:57 PM4/12/16
to Beagle Board
On Tue, Apr 12, 2016 at 11:42 AM, William Hermans <yyr...@gmail.com> wrote:
Correct.. if no eeprom, the boot stops very early and just bail's..

Regards,

Ah, so it used to be that we could manually set the device tree board file. I guess this is no longer possible ?

Well, you could manually set the device tree, but the eeprom lookup happens in the SPL, so you never get into the full u-boot.img..

For "blank" boards, we do have a patch to assume bbb.. (for the oem's that produce the bbb's)


if this is done on the white, lots of bad things can happen, ddr2 vs ddr3, ldo3...

Regards,

William Hermans

unread,
Apr 12, 2016, 1:09:53 PM4/12/16
to beagl...@googlegroups.com
Well, you could manually set the device tree, but the eeprom lookup happens in the SPL, so you never get into the full u-boot.img..

For "blank" boards, we do have a patch to assume bbb.. (for the oem's that produce the bbb's)


if this is done on the white, lots of bad things can happen, ddr2 vs ddr3, ldo3...

Regards,

Yeah, sorry, I asked the wrong question. Although you answered the question I had anyway. I know there is the ${dtb} environment variable. Then, I'm reasonably sure what that variable is for. I just was not sure how that played out with the eeprom checks and all. Now, I know.

So without ${dtb} we'd not have a way to set various board files, for the same board, from within the second stage uEnv.txt file.

--
Reply all
Reply to author
Forward
0 new messages