BeagleBone image question

jkridner · July 1, 2014, 4:51pm

Jason

I'm searching for one of the old BB images that allowed to write the EEPROM
from u-boot. One of those that you could use to access the u-boot even if
the EEPROM was empty.

You don't have to go old for that. Robert continues to build updated
u-boot images that ignore the EEPROM such that you can boot and
program it. Realize there is a test-point on the board if you want to
un-write-protect the EEPROM.

The image-builder specifies the image to get here:

github.com

beagleboard/image-builder/blob/master/tools/setup_sdcard.sh#L1220


      
          				echo "#uboot_overlay_addr2=<file2>.dtbo" >> ${wfile}
          				echo "#uboot_overlay_addr3=<file3>.dtbo" >> ${wfile}
          				echo "###" >> ${wfile}
          				echo "###Additional custom capes" >> ${wfile}
          				echo "#uboot_overlay_addr4=<file4>.dtbo" >> ${wfile}
          				echo "#uboot_overlay_addr5=<file5>.dtbo" >> ${wfile}
          				echo "#uboot_overlay_addr6=<file6>.dtbo" >> ${wfile}
          				echo "#uboot_overlay_addr7=<file7>.dtbo" >> ${wfile}
          				echo "###" >> ${wfile}
          				echo "###Custom Cape" >> ${wfile}
          				echo "#dtb_overlay=<file8>.dtbo" >> ${wfile}
          				echo "###" >> ${wfile}
          				echo "###Disable auto loading of virtual capes (emmc/video/wireless/adc)" >> ${wfile}
          				if [ "x${uboot_disable_emmc}" = "xenable" ] ; then
          					echo "disable_uboot_overlay_emmc=1" >> ${wfile}
          				else
          					echo "#disable_uboot_overlay_emmc=1" >> ${wfile}
          				fi
          				if [ "x${uboot_disable_video}" = "xenable" ] ; then
          					echo "disable_uboot_overlay_video=1" >> ${wfile}
          				else

That means that the actual built u-boot images are at
Index of /deb/tools/am335x_boneblack.

I'm not sure where the sources are! Robert, please jump in here as it
isn't obvious, especially since the image build script doesn't have an
option for rebuilding the bootloader (it seems it should).

I see a bunch of patches here:

github.com

eewiki/u-boot-patches/blob/master/v2014.07-rc3/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

From 748322cce2b5dcd532aff6329ab8d34ffcf0b2a5 Mon Sep 17 00:00:00 2001
From: Robert Nelson <robertcnelson@gmail.com>
Date: Sat, 10 May 2014 17:59:33 -0500
Subject: [PATCH] am335x_evm: uEnv.txt, bootz, n fixes

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
---
 include/configs/am335x_evm.h      | 37 ++++++++++++++++++++++++++-----------
 include/configs/ti_armv7_common.h |  1 +
 2 files changed, 27 insertions(+), 11 deletions(-)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 762f6d2..20f84a6 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -63,8 +63,9 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
 	DEFAULT_LINUX_BOOT_ENV \
 	"boot_fdt=try\0" \
-	"bootpart=0:2\0" \

This file has been truncated. show original

(per http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot),
but I don't see the one for am335x-boneblack.h.

Robert?!?

I believe we should push the am335x-boneblack.h file into mainline and
annotate it clearly to be used only in cases of a board without an
EEPROM.

RobertCNelson · July 1, 2014, 5:06pm

Jason

I'm searching for one of the old BB images that allowed to write the EEPROM
from u-boot. One of those that you could use to access the u-boot even if
the EEPROM was empty.

You don't have to go old for that. Robert continues to build updated
u-boot images that ignore the EEPROM such that you can boot and
program it. Realize there is a test-point on the board if you want to
un-write-protect the EEPROM.

The image-builder specifies the image to get here:
image-builder/tools/setup_sdcard.sh at master · beagleboard/image-builder · GitHub

That means that the actual built u-boot images are at
Index of /deb/tools/am335x_boneblack.

I'm not sure where the sources are! Robert, please jump in here as it
isn't obvious, especially since the image build script doesn't have an
option for rebuilding the bootloader (it seems it should).

Well, i really don't have a script to build "one" bootloader.

I kinda ended up in a situation where i'm tracking 15 boards in u-boot
mainline. opps!

As u-boot releases happen, i push those patches to "
GitHub - eewiki/u-boot-patches " so we can hard link to
them. The patches in Bootloader-Builder tend to churn a lot.

I see a bunch of patches here:
u-boot-patches/v2014.07-rc3/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch at master · eewiki/u-boot-patches · GitHub
(per http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot),
but I don't see the one for am335x-boneblack.h.

Oh, I'm just ignoring the fact u-boot has a "am335x-boneblack" config,
as "am335x-evm" supports both beaglebone's... Easier to share a
microSD between the white/black.

Robert?!?

I believe we should push the am335x-boneblack.h file into mainline and
annotate it clearly to be used only in cases of a board without an
EEPROM.

The

I've been trying with some of the images available at
http://downloads.angstrom-distribution.org/demo/beaglebone/archive/.
But i keep getting something like:

U-Boot SPL 2011.09-00000-gf63b270-dirty (Nov 20 2011 - 19:58:24)
Texas Instruments Revision detection unimplemented
Incorrect magic number in EEPROM
read_eeprom() failure
: 0
spl: fat register err - -1
### ERROR ### Please RESET the board ###

or

U-Boot SPL 2011.09-00010-g81c8c79 (Feb 13 2012 - 14:48:03)
Texas Instruments Revision detection unimplemented
Incorrect magic number in EEPROM
read_eeprom() failure
: 0
mmc_read_data: timedout waiting for status!
mmc_send_cmd: timedout waiting for cmddis!
** Can't read partition table on 25000000:0 **
** Partition 1 not valid on device 25000000 **
spl: fat register err - -1
### ERROR ### Please RESET the board ###

and doesn't allow me to actually access u-boot prompt to write the magic
number.

Do you happen to have one of those images around (i believe that the right
u-boot.img would be enough)?

GND test point TP4 and boot with:

http://rcn-ee.net/deb/testing/2014-05-14/BBB-blank-eMMC-flasher-debian-7.5-2014-05-14-2gb.img.xz

as long as your i2c bus works, this'll boot and program the eeprom..

Regards,

jkridner · July 1, 2014, 5:46pm

Jason

I'm searching for one of the old BB images that allowed to write the EEPROM
from u-boot. One of those that you could use to access the u-boot even if
the EEPROM was empty.

You don't have to go old for that. Robert continues to build updated
u-boot images that ignore the EEPROM such that you can boot and
program it. Realize there is a test-point on the board if you want to
un-write-protect the EEPROM.

The image-builder specifies the image to get here:
image-builder/tools/setup_sdcard.sh at master · beagleboard/image-builder · GitHub

That means that the actual built u-boot images are at
Index of /deb/tools/am335x_boneblack.

I'm not sure where the sources are! Robert, please jump in here as it
isn't obvious, especially since the image build script doesn't have an
option for rebuilding the bootloader (it seems it should).

Well, i really don't have a script to build "one" bootloader.

GitHub - RobertCNelson/Bootloader-Builder: create sanity in the insanity

I kinda ended up in a situation where i'm tracking 15 boards in u-boot
mainline. opps!

As u-boot releases happen, i push those patches to "
GitHub - eewiki/u-boot-patches " so we can hard link to
them. The patches in Bootloader-Builder tend to churn a lot.

This is all fine, but it should be clear what is going on to someone
visiting Source released for the Beagle Board - BeagleBoard. Perhaps I just missed it.

I see a bunch of patches here:
u-boot-patches/v2014.07-rc3/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch at master · eewiki/u-boot-patches · GitHub
(per http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot),
but I don't see the one for am335x-boneblack.h.

Oh, I'm just ignoring the fact u-boot has a "am335x-boneblack" config,
as "am335x-evm" supports both beaglebone's... Easier to share a
microSD between the white/black.

OK, so where you use it in setup-card.sh is simply a hack to give a
different URL to fetch it?

You are using this patch
(https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.07-rc3/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch)
and then building normally for am335x-evm?

Robert?!?

I believe we should push the am335x-boneblack.h file into mainline and
annotate it clearly to be used only in cases of a board without an
EEPROM.

The

Seems like you hesitated here. Perhaps we could #include
<am335x-evm.h> and then overwrite some settings and add a clear note
that this is for ignoring that EEPROM? The reasons are that lots of
people look for boneblack in the u-boot sources (without success),
lots of people try to build clones without EEPROMs and struggle to
figure out how, and out-of-tree patches are always hard to locate with
confidence they are used in the build of the software at hand.

Victor_MV · July 1, 2014, 5:47pm

Robert,

Thanks for pointing it out. I flashed the image and put the TP2 to GND (using the BeagleBone white).

Tried it and got an infinite loop with the following:

U-Boot SPL 2014.04-00015-gb4422bd (Apr 22 2014 - 13:24:29)
Incorrect magic number (0xffffffff) in EEPROM
Could not get board ID.
Incorrect magic number (0xffffffff) in EEPROM
Could not get board ID.
Unknown board: assuming BeagleBone Black.Incorrect magic number (0xffffffff) in EEPROM
Could not get board ID.

…

Any ideas?

RobertCNelson · July 1, 2014, 5:48pm

Doh! You have a white, don't use that file.. It assumes a "bbb" which
include 1Ghz + ldo rails!!!

Regards,

Victor_MV · July 1, 2014, 5:51pm

Mmm too late but the board doesn’t seem to be damaged. Any ideas on how to flash EEPROM on the BB?

RobertCNelson · July 1, 2014, 5:53pm

it should be 'fine' just don't let it sit for a hours...

If you can boot to userspace... This is how i flash the eeprom on the black.

https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L29

But i don't have the 'bbw.eeprom' on me. Should be safe to dump it
from on in the lab.. I'll have to dig a bit..

Not sure how to flash from u-boot..

Regards,

RobertCNelson · July 1, 2014, 6:11pm

This is all fine, but it should be clear what is going on to someone
visiting Source released for the Beagle Board - BeagleBoard. Perhaps I just missed it.

I see a bunch of patches here:
u-boot-patches/v2014.07-rc3/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch at master · eewiki/u-boot-patches · GitHub
(per http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot),
but I don't see the one for am335x-boneblack.h.

Oh, I'm just ignoring the fact u-boot has a "am335x-boneblack" config,
as "am335x-evm" supports both beaglebone's... Easier to share a
microSD between the white/black.

OK, so where you use it in setup-card.sh is simply a hack to give a
different URL to fetch it?

Yeah, i use the "--uboot boneblack_flasher" flag in my setup-card.sh
creator script to grab the "blank eeprom" u-boot, vs the normal
am335x_evm build.

beaglebone & BeagleBone Black
ABI2:am335x_evm:SPL
http://rcn-ee.net/deb/tools/am335x_evm/MLO-am335x_evm-v2014.07-rc3-r8
ABI2:am335x_evm:BOOT
http://rcn-ee.net/deb/tools/am335x_evm/u-boot-am335x_evm-v2014.07-rc3-r8.img

beaglebone Black (eeprom)
ABI2:am335x_boneblack:SPL
http://rcn-ee.net/deb/tools/am335x_boneblack/MLO-am335x_boneblack-v2014.07-rc3-r8
ABI2:am335x_boneblack:BOOT
http://rcn-ee.net/deb/tools/am335x_boneblack/u-boot-am335x_boneblack-v2014.07-rc3-r8.img

You are using this patch
(https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.07-rc3/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch)
and then building normally for am335x-evm?

Correct.. For devices programmed at the factory, users should only use
the 1st patch.

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.07-rc3/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

This is also located under /opt/source/ of the production image.

It contains a few tweaks for where we have the kernel boot files
located in the debian image. Along with a poor man's cape manager
checker..

However, the second patch really should only be used by oem's who are
flashing the bbb, as it assumes 1Ghz, the black's ldo setting etc.

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.07-rc3/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch

Robert?!?

I believe we should push the am335x-boneblack.h file into mainline and
annotate it clearly to be used only in cases of a board without an
EEPROM.

The

Seems like you hesitated here. Perhaps we could #include
<am335x-evm.h> and then overwrite some settings and add a clear note
that this is for ignoring that EEPROM? The reasons are that lots of
people look for boneblack in the u-boot sources (without success),
lots of people try to build clones without EEPROMs and struggle to
figure out how, and out-of-tree patches are always hard to locate with
confidence they are used in the build of the software at hand.

Well, when i set this up originally, we didn't have much for a clone
market. So we definitely need to look at this again. I just didn't
want people running this image on clones that did have the 1Ghz or the
black's ldo setup. I need to think, what's still safe for a blank
bbw..

Regards,

Victor_MV · July 2, 2014, 8:32am

A small update on this matter:

I tried booting with different images, specially with one that in the past probed to do the job (refer to this thread): Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.11.22.img.xz.

The odd thing is that the board doesn’t boot (the PWR LED doesn’t even light up) when this image is used. If new images are used PWR LED switches on but i get messages as:

-Boot SPL 2013.07-dirty (Sep 01 2013 - 12:08:18)
Incorrect magic number (0xffffffff) in EEPROM
Could not get board ID.
Unknown board, cannot configure pinmux.### ERROR ### Please RESET the board ###

Not being able to access u-boot to flash the EEPROM. Has anyone seen such a behaviour (some images make the board work and some not)?

@Gerald, do you thing this could be hardware related?

jkridner · July 2, 2014, 12:04pm

Don’t know if you should be thinking hardware issues yet. I don’t think you’ve said why the EEPROM wasn’t programmed.

Victor_MV · July 2, 2014, 1:13pm

Jason,

This is a new board developed to support BeaglePilot (a simplification of what i’ve been doing with Erle) thereby i need to flash the EEPROM myself.

After removing some components that were creating conflicts with SYS_BOOT pins the behavior changed:

Out of 5 boards we manufactured we’ve been able to program the EEPROM of only one using the image i mentioned before (Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.11.22.img.xz). This is what leads me to thing to a manufacturing issue.
The other 4 boards, apparently look good (tty interface appears when connected through miniUSB, no microSD card on) but once I introduce a microSD card with Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.11.22.img.xz image and the miniUSB is connected, the PWR LED turns on for about a second and then it switches off. No new tty interface appears under /dev/.

This behavior doesn’t happen with newer images but neither i can use them to flash the EEPROM.

Kind regards