Working links to blank-EEPROM flasher image?

I have inherited responsibility for a bunch of 3rd-party direct clones of a Beaglebone Black C5 (only known change is in silkscreening).

Since none of these have any contents written to the onboard EEPROM, they fail to boot with “CCCCC” written to the serial console with no uSD card, and

U-Boot SPL 2015.01-00001-gb2412df (Jan 29 2015 - 15:01:06)
Incorrect magic number (0xffffffff) in EEPROM
Could not get board ID.
Incorrect magic number (0xffffffff) in EEPROM
Could not get board ID.
Unknown board, cannot configure pinmux.### ERROR ### Please RESET the board ###

…written to the console when I try to boot it from a uSD cards with a stock BBB image (the 2015-03-01 Debian 7.8 image). So clearly I need to get some good contents into the EEPROM.

I’ve been trying to hunt down instructions for how to access the U-Boot prompt to manually write the EEPROM via the i2c bus, but haven’t hit any luck there.

Robert Nelson’s posted links in the past to what he’s described as the “factory images for flashing boards with blank EEPROMs”, but those links (to rcn-ee.org) are stale/dead or behind apparently access-controlled folders on his server.

Could anyone provide a good set of instructions for getting access to a uBoot prompt from a stock flasher image OR provide current links to the blank-EEPROM manufacturing images (or equivalents) that RCN’s referenced?

Take a real BBB and copy the contents if you need to. EEPROM data varies with serial number and revision data. But the EEPROM data is described in the SRM, is still valid and is not stale or old.

Gerald

So the "blank-flasher" (did everything by default) went away. Instead
we now have a "usbflasher"..

Step 1: (microSD)

http://rcn-ee.com/rootfs/bb.org/testing/2015-09-06/usbflasher/BBB-blank-debian-8.1-usbflasher-armhf-2015-09-06-2gb.bmap
http://rcn-ee.com/rootfs/bb.org/testing/2015-09-06/usbflasher/BBB-blank-debian-8.1-usbflasher-armhf-2015-09-06-2gb.img.xz

(bmaptools 3.2)
sudo bmaptools copy --bmap *.bmap *.img.xz /dev/sdX

Step 2: (usb drive)
Format it as fat32, 2 or 3 files "custom: job.txt" and the image files..

For example:

to flash: 2015-03-01

First download the base image:

http://rcn-ee.com/rootfs/bb.org/release/2015-03-01/lxde-4gb/bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz

Then the "eeprom"

https://raw.githubusercontent.com/RobertCNelson/boot-scripts/master/device/bone/bbb-eeprom.dump

finally crate the "job.txt" file

abi=aaa
conf_eeprom_file=bbb-eeprom.dump
conf_eeprom_compare=335
conf_image=bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz
conf_resize=enable
conf_partition1_startmb=1
conf_partition1_fstype=0xE
conf_partition1_endmb=96
conf_partition2_fstype=0x83
conf_root_partition=2

Step 3: (flashing)

Insert "microSD" with usbflasher image bmap'ed to it..
Insert "usb flash drive" with
bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img.xz, bbb-eeprom.dump
& job.txt all in the base directory
GND TP4 (write protect on eeprom)
Power board

Serial Log the first one to make sure it correctly flashes..

Regards,

Gerald,

I’ve got the SRM and know the format of the data that needs to get written there - I’m just stuck on HOW to get it there:

Could anyone provide a good set of instructions for getting access to a uBoot prompt from a stock flasher image OR provide current links to the blank-EEPROM manufacturing images (or equivalents) that RCN’s referenced?

The two methods I’ve seen discussed on the forums are:

  1. Manually updating the EEPROM from i2c commands issued within uBoot
  2. Using a flasher image with a uBoot build that bypasses the magic-number-check and writes content to the EEPROM from a command-line script.

I2C writes is what we do.

Gerald

Robert,

Thanks for the prompt (and detailed!) reply. That’s exactly the information I’m trying to find.

…now I just have to convince our IT staff / McAffee to white-list your web server (if it ain’t one thing, it’s another) so I can get those files.

This may be useful information to add to a wiki somewhere - I can’t be the only person with blank (or inadvertently borked) BBB EEPROMs running around.

-phil

Just make sure you ground the Write Protect pin on the EEPROM.

Gerald

Robert,

Thanks for the prompt (and detailed!) reply. That's exactly the information
I'm trying to find.

...now I just have to convince our IT staff / McAffee to white-list your web
server (if it ain't one thing, it's another) so I can get those files.

make sure to use the https version too.. "https://rcn-ee.com/" missed
the s in my copy/paste...

This may be useful information to add to a wiki somewhere - I can't be the
only person with blank (or inadvertently borked) BBB EEPROMs running around.

It only sets the initial "code" A335BNLT, just enough to assume to be a bbb..

But i don't want it make it too easy.. it's really for
CircuitCo/cm's/cloner's/etc to use.. :wink:

and if you are making a "98%" clone that's going to be sold into the
general population, we really want you to contact beagleboard.org and
we have empty bits for you to use for identification.. (the
beaglebone-green is the most recent example..)

Regards,

Gerald,

Robert’s given me a workable answer to my question already, so I’m set, BUT it seems like a pretty heavy-weight option - totally suitable for manufacturing / mass-production / other “blank slate” scenarios, but very heavy for Joe User who’s just accidentally typed “i2cset -y 1 -0x50…” with a paperclip in the wrong spot and corrupted the EEPROM on his BBB that he’s spend the last month working on.

Your “I2C writes is what we do” response seems to imply that you’ve got a lighter-weight method to edit contents on the EEPROM than what RCN’s described?

If so, I’d really appreciate a description of how YOU get to an unbootable BBB to a state where you can write to a blank/corrupted EEPROM.

-phil

CircuitCo actually has two stages.

First they run my "usbflasher" on all boards to set the initial eeprom..

Next all boards go thru a "tester" which adds the unique serial number
in eeprom, along with a 100% functionality test..

Regards,

Ugh, where do you work that you have such restrictions on servers?

We’re not doing retail distribution, but I’ll remind our product manager to check in w/ BeagleBoard.org to make sure we’re not stepping on toes.

As long as I can get it to boot / flash (thank you again!), the scripts to get it serialized & date-stamped as part of our configuration sequence won’t be any trouble at all.

While I’m asking questions: is there a good reference script / utility to create an image file (.img.xz format) from an existing BBB ?

-phil

Silly, ain’t it.

From the McAfee naughty-naughty screen:
URL Categories: Malicious Sites, Personal Pages, Technical/Business Forums, Malicious Downloads
Reputation: High Risk (127)

-phil

Well Intel owns McAfee, rcn-ee.com only provides ARM stuff, and i once
told an Intel recruiter x86 was boring..

Not surprised. :wink:

Regards,

https://github.com/beagleboard/image-builder

Regards,

Well Intel owns McAfee, rcn-ee.com only provides ARM stuff, and i once
told an Intel recruiter x86 was boring…

Not surprised. :wink:

That’s pretty funny. Probably since it’s true. heh

But when will Intel realize that x86 is boring I wonder ?

Robert,

I’m not having success - the serial monitor continues to display “CCCCC” as soon as it’s powered up, so that seems to indicate that it’s not finding anything bootable on that SD card with the blank flasher image.

  1. My setup: 64-bit Debian Jessie (as VirtualBox VM on a Win7 host);
    2GB uSD card, freshly formatted & overwritten in a uSD->USB converter (Virtualbox won’t pass the built-in card reader on my laptop into the VMs)
    16GB uSD card, freshly formatted in a uSD->SD converter
  2. Installed bmaptool ver3.2 via apt-get
  3. Brought 2GB card over to VM
  4. mounted as /dev/sdd1; did “umount /dev/sdd1” to allow bmaptool to open w/ exclusive access
  5. Ran bmaptool as described above - no errors indicated.
  6. Ejected uSD from VM image, host.1. Inserted 16GB uSD into Win7 system,
  7. copied 2015-03-01 debian 7.8 image
  8. copied eeprom dump
  9. created new job.txt file with contents as described above (UNIX line endings)
  10. ejected uSD from Win71. 2GB uSD into reader on BBB
  11. 16GB uSD into USB adapter, then to USB on BBB
  12. Serial cable connected
  13. TP4 grounded to P8-1
  14. Power applied via mini-USB cable
  15. “CCCCCCCC”

Suggestions or troubleshooting steps?
I have erased/re-formatted/reloaded the cards 2x with same results.

-phil

Robert,

I'm not having success - the serial monitor continues to display "CCCCC" as
soon as it's powered up, so that seems to indicate that it's not finding
anything bootable on that SD card with the blank flasher image.

Yeah... "VirtualBox"....

Just use 'win32imager" on the base *.img.xz with Windows 7...

All the vm's are crap when it comes to writing to a microSD card..

My setup: 64-bit Debian Jessie (as VirtualBox VM on a Win7 host);
2GB uSD card, freshly formatted & overwritten in a uSD->USB converter
(Virtualbox won't pass the built-in card reader on my laptop into the VMs)
16GB uSD card, freshly formatted in a uSD->SD converter
Installed bmaptool ver3.2 via apt-get
Brought 2GB card over to VM

mounted as /dev/sdd1; did "umount /dev/sdd1" to allow bmaptool to open w/
exclusive access
Ran bmaptool as described above - no errors indicated.
Ejected uSD from VM image, host.

Inserted 16GB uSD into Win7 system,

copied 2015-03-01 debian 7.8 image
copied eeprom dump
created new job.txt file with contents as described above (UNIX line
endings)
ejected uSD from Win7

2GB uSD into reader on BBB
16GB uSD into USB adapter, then to USB on BBB
Serial cable connected
TP4 grounded to P8-1
Power applied via mini-USB cable
"CCCCCCCC"

Suggestions or troubleshooting steps?
I have erased/re-formatted/reloaded the cards 2x with same results.

Regards,

Did you set the “boot” bit on the uSD card?
— Graham

'boot' bit is set in the raw *.img

If the vm skipped setting that one bit, who knows what else it skipped.. :slight_smile:

Regards,