Extracting eMMC contents using FAT formatted card

[Jason Kridner]

There are lots of ways to extract the contents of the eMMC to save off and reuse. I'm proposing a method using Buildroot and an initramfs such that you can simply drop a few files from a .zip onto a normal, FAT-formatted SD card to perform the extraction. There are several things really handy here, such as the ability to edit autorun.sh to be whatever script you want to run on your board at boot. In the archive, I only have the necessary autorun.sh for *saving* your eMMC content. The flip-side is provided here in the text such that you need to go through a couple of steps before you trash your eMMC.

The steps for saving off your eMMC contents to a file:

* Get a 4GB or larger uSD card that is FAT formatted.

* Download https://s3.amazonaws.com/beagle/beagleboneblack-save-emmc.zip and extract the contents onto your uSD card.

* Eject uSD card from your computer, insert into powered-off BeagleBone Black and apply power to your board.

* You'll notice USR0 (the LED closest to the S1 button in the corner) will (after about 20 seconds) start to blink steadily, rather than the double-pulse "heartbeat" pattern that is typical when your BeagleBone Black is running the typical Linux kernel configuration.

* It'll run for a bit under 10 minutes and then USR0 will stay ON steady. That's your cue to remove power, remove the uSD card and put it back into your computer.

* You should see a file called BeagleBoneBlack-eMMC-image-XXXXX.img, where XXXXX is a set of random numbers. Save off this file to use for restoring your image later.

Because the date won't be set on your board, you might want to adjust the date on the file to remember when you made it. Delete the file if you want to make room for a new backup image. For storage on your computer, these images will typically compress very well, so use your favorite compression tool.

To restore the file, make sure there is a valid BeagleBoneBlack-eMMC-image-XXXX.img file on the uSD card and edit autorun.sh with your favorite text editor to contain the following:

#!/bin/sh

echo timer > /sys/class/leds/beaglebone\:green\:usr0/trigger 

dd if=/mnt/BeagleBoneBlack-eMMC-image-XXXXX.img of=/dev/mmcblk1 bs=10M

sync

echo default-on > /sys/class/leds/beaglebone\:green\:usr0/trigger

*NOTE*: Be certain to replace the 'XXXXX' above with the proper name of your image file.

This image was built using Buildroot. The sources are at https://github.com/jadonk/buildroot with tag save-emmc-0.0.1. Download via https://github.com/jadonk/buildroot/releases/tag/save-emmc-0.0.1 or clone the git repo. It is a small fork from git://git.buildroot.net/buildroot tag e9f6011617528646768e69203e85fe64364b7efd.

To build, 'make beagleboneblack_defconfig; make; ./mkuimage.sh'.  Output files (am335x-boneblack.dtb, MLO, u-boot.img and uImage) will be in the output/images subdirectory. The following files were created manually.

uEnv.txt:

bootpart=0:1

bootdir=

fdtaddr=0x81FF0000

optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

uenvcmd=load mmc 0 ${loadaddr} uImage;run loadfdt;setenv bootargs console=${console} ${optargs};bootm ${loadaddr} - ${fdtaddr}

autorun.sh:

#!/bin/sh

echo timer > /sys/class/leds/beaglebone\:green\:usr0/trigger 

dd if=/dev/mmcblk1 of=/mnt/BeagleBoneBlack-eMMC-image-$RANDOM.img bs=10M 

sync

echo default-on > /sys/class/leds/beaglebone\:green\:usr0/trigger

The kernel is based on https://github.com/beagleboard/kernel/commit/9fdb452245a58158a4bea787cdc663c17681bcfe, but I applied the patches, added firmware and uploaded it to https://github.com/beagleboard/linux/commit/ddd36e546e53d3c493075bbebd6188ee843208f9 to pull down in the Buildroot makefile. The link to the source for the firmware is in the commit.

I've applied to join the Buildroot mailing list to send these patches upstream. The power management firmware is not yet loading properly, but that is something I can look into.

Happy hacking!

[David Anders]

Jason,

shouldn't this info go up on the elinux.org wiki?

Dave

[Jason Kridner]

On Thursday, September 26, 2013 1:20:18 PM UTC-4, David Anders wrote:

Jason,

shouldn't this info go up on the elinux.org wiki?

Absolutely. Any recommendation on the page location? I will upload it right away.

[David Anders]

http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents

is a good place to start. i am working with bill traynor to organize
howto pages along with other specific category groups...

Dave

[Jason Kridner]

On Thursday, September 26, 2013 1:26:27 PM UTC-4, David Anders wrote:

http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents

Added. Feedback welcome.

[Alexander Holler]

>> autorun.sh:
>> #!/bin/sh
>> echo timer > /sys/class/leds/beaglebone\:green\:usr0/trigger
>> dd if=/dev/mmcblk1 of=/mnt/BeagleBoneBlack-eMMC-image-$RANDOM.img bs=10M
>> sync
>> echo default-on > /sys/class/leds/beaglebone\:green\:usr0/trigger

I think using dd and creating an image is a pretty bad way to build a
backup.

I would suggest to use

sfdisk -d /dev/foo >sfdisk.emmc.txt
mount emmc
tar cpjf -C emmc .
umount emmc

Regards,

Alexander Holler

[Alexander Holler]

Of course, it should be

tar cpjf emmc.tar.bz2 -C emmc .

and another tar might be necessary for the second partition.

And putting such a script together with busybox into an in-kernel
initramfs, and people would just have to build a card with one file, the
uImage.

Regards,

Alexander Holler

[Jason Kridner]

I still like having autorun.sh such that the script can be easily customized without rebuilding.  Of course, MLO and u-boot.img are also required.  The discussed Buildroot-based image is using initramfs.

Seems like some work is required here to create the logic to make sure each partition is tar'd. Also, the restore script needs to be created. In general, this just requires some more testing. Any volunteers to try out the sfdisk/tar based solution?

Overall, I agree it is a much better approach and I will get started on it as soon as I've submitted the base Buildroot patches upstream. Is there an easy way to make subdirectories within the tar to hold the format table and each partition such that I don't have to run tar twice and potentially run out of card space?

[Alexander Holler]

As long as the eMMC still works (the first partition there is ok), there
is no need for mlo and u-boot on the sd-card.

>
> Seems like some work is required here to create the logic to make sure each
> partition is tar'd. Also, the restore script needs to be created. In
> general, this just requires some more testing. Any volunteers to try out
> the sfdisk/tar based solution?

To restore such a tar, use

tar xpjf emmc.tar.bz2 -C emmc --numeric-owner

after you've created or formatted and mounted the partition. And don't
forget that --numeric-owner on restore, otherwise bad things might happen.

Regards,

Alexander Holler

[Jason Kridner]

Any thoughts on saving off the format name and type of a partition?
sfdisk only saves that the partition is of type '83', not that it is
formatted as 'ext4' with a certain label.

>
> Regards,
>
> Alexander Holler
>
>
> --
> 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/groups/opt_out.

[vincent....@gmail.com]

Hi Jason,

I really like the method you propose. Except the fact I tried it and I can't get it to work, or at least not following your directions.

-          I’ve flashed my BBB to Debian (http://elinux.org/BeagleBoardDebian) worked like a charm – now booting to the SD by default

-          I followed your instructions (8GB µSD, FAT32 formatted)

o   If I press no button, the BBB boots on the eMMC

o   If I press the “boot” button while plugging the power, the BBB just doesn’t boot (stays in a “powered off” state, with only the LED near the power plug on)

 The BBB is brand new, so maybe they changed something.

 Thanks for your help.

[Jason Kridner]

On Thu, Oct 31, 2013 at 1:34 PM, <vincent....@gmail.com> wrote:
> Hi Jason,
>
> I really like the method you propose. Except the fact I tried it and I can't
> get it to work, or at least not following your directions.
>
> - I’ve flashed my BBB to Debian
> (http://elinux.org/BeagleBoardDebian) worked like a charm – now booting to
> the SD by default
>
> - I followed your instructions (8GB µSD, FAT32 formatted)
>
> o If I press no button, the BBB boots on the eMMC

This tells me that the bootloader you flashed onto the eMMC doesn't
properly work with the uEnv.txt put onto the uSD card as part of
following my instructions.

>
> o If I press the “boot” button while plugging the power, the BBB just
> doesn’t boot (stays in a “powered off” state, with only the LED near the
> power plug on)

This means that the uSD card FAT partition isn't marked as bootable.
You can do that with 'fdisk' from your BeagleBone running Debian in
all likelihood.

root@beaglebone:~# fdisk /dev/mmcblk1
Welcome to fdisk (util-linux 2.23.1).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): a
Partition number (1,2, default 2): 1

Command (m for help): p

Disk /dev/mmcblk1: 3904 MB, 3904897024 bytes, 7626752 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/mmcblk1p1 * 2048 133119 65536 e W95 FAT16 (LBA)
/dev/mmcblk1p2 133120 7626751 3746816 83 Linux

>
> The BBB is brand new, so maybe they changed something.

Who's "they"? It is possible CircuitCo switched the bootloader image
on the eMMC, but it sounds more like you did that above.

[vincent....@gmail.com]

On Thursday, October 31, 2013 2:10:24 PM UTC-7, Jason Kridner wrote:

> -          I followed your instructions (8GB µSD, FAT32 formatted) 
> o   If I press no button, the BBB boots on the eMMC

This tells me that the bootloader you flashed onto the eMMC doesn't properly work with the uEnv.txt put onto the uSD card as part of following my instructions. 

 

I've no idea what bootloader the Debian image flashed to my eMMC (as a lot of people, I know nothing about Angström, and the first thing I did was to put Debian into my device, a much more common distrib, because I just want a cheap linux server to do some stuff at home).

I'm kind of a noob using the BBB, sorry about that (I'm using a RPi for quite a while now, but I'm not considering myself as a power user -- despite managing some linux servers and having a master in embedded systems, I'm a web developer and I love high level programming). What I mean but all that is: something that could look obvious to you isn't for 95% of the people reading your guides, the 95% that aren't doing BBB related stuff for a living.

But well, if I could boot onto the µSD using the boot button that would be ever more fine to me (I could leave the µSD into the BBB and boot on it when I want to backup my distrib).

 

> o   If I press the “boot” button while plugging the power, the BBB just 
> doesn’t boot (stays in a “powered off” state, with only the LED near the
> power plug on)

This means that the uSD card FAT partition isn't marked as bootable.
You can do that with 'fdisk' from your BeagleBone running Debian in all likelihood.

Huge thanks for the step by step :)

I think it would be way easier for everybody (including you ^^) if you made a .img image of the card (maybe in different sizes?) -- this would eliminate any possible mistake in the process.

As most people, I'm using Windows and formatting a card doesn't mark the partition as bootable, so following your base instructions just doesn't work.

I've found that my µSD is in /dev/mmcblk0 (I tried /dev/mmcblk1 at first and it bricked my BBB, I had to flash it again -- not a big deal)

root@arm:~# cat /proc/partitions

major minor  #blocks  name

 179        0    7822336 mmcblk0

 179        1    7818240 mmcblk0p1

 179        8    1875968 mmcblk1

 179        9      72261 mmcblk1p1

 179       10    1799280 mmcblk1p2

 179       24       1024 mmcblk1boot1

 179       16       1024 mmcblk1boot0

The card is now bootable:

root@arm:~# fdisk /dev/mmcblk0  

Command (m for help): p

Disk /dev/mmcblk0: 8010 MB, 8010072064 bytes

214 heads, 8 sectors/track, 9138 cylinders, total 15644672 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x00000000

        Device Boot      Start         End      Blocks   Id  System

/dev/mmcblk0p1   *        8192    15644671     7818240    b  W95 FAT32

It was still booting to the eMMC by default, so I powered it on while having the boot button but -- no matter if I pressed the button for 4 seconds or until LEDs are on - it somewhat booted, but the USR0 was directly steady on. So I tried to reboot it (using the "reset" button) and it's now correctly writing the image to the SD. I don't really know how the "boot" button works, but considering this behaviour I would say it disables the eMMC while pressed, isn't?

So my "create image process" is: power the BBB on with the boot button pressed for like 5s, and once the USR0 is steady on, press the reset button and then wait 10min for USR0 to be steady on again.

Again, thank you a lot for your help. I really like the BBB, the only think I don't like is how difficult it is to make an image of the eMMC and your method is a huge step into making it simple.

 

root@beaglebone:~# fdisk /dev/mmcblk1
Welcome to fdisk (util-linux 2.23.1).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): a
Partition number (1,2, default 2): 1

Command (m for help): p

Disk /dev/mmcblk1: 3904 MB, 3904897024 bytes, 7626752 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk1p1   *        2048      133119       65536    e  W95 FAT16 (LBA)
/dev/mmcblk1p2          133120     7626751     3746816   83  Linux

> 
>  The BBB is brand new, so maybe they changed something.

Who's "they"? It is possible CircuitCo switched the bootloader image on the eMMC, but it sounds more like you did that above. 

Yeah, I thought maybe CircuitCo changed something in the bootloading or something, but it definitively doesn't seems to be the issue here.

[Robert Nelson]

On Thu, Oct 31, 2013 at 7:52 PM, <vincent....@gmail.com> wrote:
> On Thursday, October 31, 2013 2:10:24 PM UTC-7, Jason Kridner wrote:
>>
>> > - I followed your instructions (8GB µSD, FAT32 formatted)
>> > o If I press no button, the BBB boots on the eMMC
>>
>> This tells me that the bootloader you flashed onto the eMMC doesn't
>> properly work with the uEnv.txt put onto the uSD card as part of following
>> my instructions.
>
>
> I've no idea what bootloader the Debian image flashed to my eMMC (as a lot
> of people, I know nothing about Angström, and the first thing I did was to
> put Debian into my device, a much more common distrib, because I just want a
> cheap linux server to do some stuff at home).
> I'm kind of a noob using the BBB, sorry about that (I'm using a RPi for
> quite a while now, but I'm not considering myself as a power user -- despite
> managing some linux servers and having a master in embedded systems, I'm a
> web developer and I love high level programming). What I mean but all that
> is: something that could look obvious to you isn't for 95% of the people
> reading your guides, the 95% that aren't doing BBB related stuff for a
> living.
> But well, if I could boot onto the µSD using the boot button that would be
> ever more fine to me (I could leave the µSD into the BBB and boot on it when
> I want to backup my distrib).

Well, grab a usb-serial adapter and find out what u-boot is doing. I
have a couple failsafe's in the bootloader i used when you flashed it
with debian to more 'easily' support empty microSD cards. However if
the "uEnv.txt" on your other microSD is not valid, it still keep
booting from eMMC.

So grab a usb-serial adapter and find out what u-boot's doing, as i
print out a few hints..

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[vincent....@gmail.com]

On Friday, November 1, 2013 10:09:58 AM UTC-7, RobertCNelson wrote:

 

Well, grab a usb-serial adapter and find out what u-boot is doing.  I have a couple failsafe's in the bootloader i used when you flashed it with debian to more 'easily' support empty microSD cards.  However if the "uEnv.txt" on your other microSD is not valid, it still keep booting from eMMC.

So grab a usb-serial adapter and find out what u-boot's doing, as i print out a few hints..

Well, I'm perfectly fine with the way it behaves right now (I can keep the "imager/flasher" SD card plugged into the board).
Also I was unable to install the BB drivers on my computer (yes, the "Microsoft Visual C++ 2010 SP1 Redistributable Package (x64)" is installed, as well as everything needed -- I'm a .net web developper, Visual Studio installs all that stuff), I think there is a conflict with my existing TAP drivers or something (OpenVPN and/or Hamachi). But I don't care enough to investigate this.

This won't give you any hint I guess, but here is the failure screenshot: http://s16.postimg.org/md2nehe6t/Capture.png 

[Wilfredo Nieves]

Hi Vincent,

From your screen shot it looks like you are running Win8. Have you disabled driver signature verification to see if the drivers will install?

-Wil

[vincent....@gmail.com]

On Friday, November 1, 2013 5:13:02 PM UTC-7, Wilfredo Nieves wrote:

  From your screen shot it looks like you are running Win8. Have you disabled driver signature verification to see if the drivers will install?

Hi Wil,

This worked! Thanks you very much for pointing this out! This is something that should be in the getting started...

Is there any particular reason why the driver is not signed?

The getting started guide is very detailed and very well done, giving lot of useful information, but don't even address a major issue that affects a growing number of users (Windows 7 and Vista don't have this issue?).

In my opinion, the BBB is an incredible piece of hardware, way superior to the RPi. But it's WAY (and I mean WAY WAY WAY) less user friendly than the RPi: no guide is up to date, nothing is working like described in the guides, Angstrom is a confidential distrib (why choosing this by default? power users can install Angstrom by their own! People wants Ubuntu/Debian! (I personally prefer Debian when no GUI because Ubuntu's do-release-upgrade always breaks everything)), and this is very unfortunate.

This gives a poor first user experience, limiting the growth of the community. It looks like the product is made for and by hyper specialized nerds.

As I understand, the beagleboard.org projects are community driven, so making the product accessible only to a very small part of the population is definitively not a good thing.

NB: I tried to edit the getting started guide to add the driver related issue in the troubleshooting section, but I guess it's not a wiki -- no edit link once logged in.

[Wilfredo Nieves]

No problem, glad it worked.

-Wil

[jim.la...@gmail.com]

Hello,

I realize that this is an old thread, but was hoping that one of y'all might see this and shed some light on what I'm doing wrong...

I pulled the buildroot project from "https://github.com/jadonk/buildroot/releases/tag/save-emmc-0.0.1" since it's exactly what I need (an initramfs with working support for the SD card; I can't get MMC/SD to work with the mainline kernel and Buildroot 2013.11).

Problem is, when I follow the build instructions, it goes off to do a GIT clone on from GitHub of tag "ddd36e546e53d3c493075bbebd6188ee843208f9" to get Linux kernel patches.  It appears to contact the GIT server, processes some 697MB with of data, builds a tarball on the remote end, and then downloads a "linux-ddd36e546e53d3c493075bbebd6188ee843208f9.tar.gz" tarball file with 20 bytes in it.

At this point, the Buildroot compile dies, since the tarball is truncated/corrupted/something.

I'm not very well versed in GIT internals; can anyone shed some light on what might be wrong so I can get this compiled?  I will happily provide any logs or other information, but am too new at using GIT to know what to post up.

Thanks,
Jim

[Dieter Wirz]

Did you try something like:
git clone git://github.com/jadonk/buildroot
in your terminal

[Robert Nelson]

On Mon, Jan 6, 2014 at 1:02 PM, <jim.la...@gmail.com> wrote:
> Hello,
>
> I realize that this is an old thread, but was hoping that one of y'all might
> see this and shed some light on what I'm doing wrong...
>
> I pulled the buildroot project from
> "https://github.com/jadonk/buildroot/releases/tag/save-emmc-0.0.1" since
> it's exactly what I need (an initramfs with working support for the SD card;
> I can't get MMC/SD to work with the mainline kernel and Buildroot 2013.11).
>
> Problem is, when I follow the build instructions, it goes off to do a GIT
> clone on from GitHub of tag "ddd36e546e53d3c493075bbebd6188ee843208f9" to
> get Linux kernel patches. It appears to contact the GIT server, processes
> some 697MB with of data, builds a tarball on the remote end, and then
> downloads a "linux-ddd36e546e53d3c493075bbebd6188ee843208f9.tar.gz" tarball
> file with 20 bytes in it.

Yeah... I think i see an issue with github.com/beagleboard/linux the
current practice has always been to push over the old branch, so when
i pushed to fixes to the 3.8 branch last week that rewrote the history
and now ddd36e546e53d3c493075bbebd6188ee843208f9 is probally a single
file no longer connected to anything...

Can buildroot just use the "3.8" branch instead of a specific commit?

>
> At this point, the Buildroot compile dies, since the tarball is
> truncated/corrupted/something.
>
> I'm not very well versed in GIT internals; can anyone shed some light on
> what might be wrong so I can get this compiled? I will happily provide any
> logs or other information, but am too new at using GIT to know what to post
> up.

[jim.la...@gmail.com]

Thanks for replying so quickly, I really do appreciate it.

Dieter:

   Yes, I can pull directly as you indicated to try, thanks.

Robert:

   It would appear that Buildroot can just pull from 'head' or whatever GIT calls the current copy.  If I clear out the tag entry in Buildroot, I get the following:

>>> linux  Downloading
Doing shallow clone
Cloning into 'linux-'...
warning: Could not find remote branch --bare to clone.
fatal: Remote branch --bare not found in upstream origin
Doing full clone
Cloning into bare repository 'linux-'...
remote: Counting objects: 3445333, done.
remote: Compressing objects: 100% (526886/526886), done.
Receiving objects:  76% (2620199/3445333), 381.07 MiB | 1.07 MiB/s

This is still in progress as I type this, but it looks promising since the number of objects matches what it indicated when it was attempting to pull the tagged version. I'll post up if this works after the download completes.

Thanks again,
Jim

[jim.la...@gmail.com]

Oh well, that didn't work.  Same MO, fails with a 20-byte tarball image named 'linux-'.

It would seem that there needs to be something useful in the field for Buildroot (and maybe GIT) to work:

BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION:                                                                                        │ 
  │                                                                                                                             │ 
  │ Git revision to use in the format used by git rev-parse,                                                                    │ 
  │ E.G. a sha id, a tag, branch, ..

The build results indicate that there might be a problem with 'linux-' as well:

>>> linux  Downloading
Doing shallow clone
Cloning into 'linux-'...
warning: Could not find remote branch --bare to clone.
fatal: Remote branch --bare not found in upstream origin
Doing full clone
Cloning into bare repository 'linux-'...
remote: Counting objects: 3445333, done.
remote: Compressing objects: 100% (526886/526886), done.

Receiving objects: 100% (3445333/3445333), 697.64 MiB | 1.20 MiB/s, done.
remote: Total 3445333 (delta 2898718), reused 3435074 (delta 2888463)
Resolving deltas: 100% (2898718/2898718), done.
usage: git archive [options] <tree-ish> [<path>...]
   or: git archive --list
   or: git archive --remote <repo> [--exec <cmd>] [options] <tree-ish> [<path>...]
   or: git archive --remote <repo> [--exec <cmd>] --list

    --format <fmt>        archive format
    --prefix <prefix>     prepend prefix to each pathname in the archive
    -o, --output <file>   write the archive to this file
    --worktree-attributes
                          read .gitattributes in working directory
    -v, --verbose         report archived files on stderr
    -0                    store only
    -1                    compress faster
    -9                    compress better

    -l, --list            list supported archive formats

    --remote <repo>       retrieve the archive from remote repository <repo>
    --exec <command>      path to the remote git-upload-archive command

>>> linux  Extracting
gzip -d -c /home/build/mi/beaglebone/buildroot-save-emmc-0.0.1/dl/linux-.tar.gz | tar --strip-components=1 -C /home/build/mi/beaglebone/buildroot-save-emmc-0.0.1/output/build/linux-  -xf -
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors

Ugh.  Is there a new(er) tag that I can use, one some sort of 'head' tag or something?

Thanks,
Jim

On Monday, January 6, 2014 2:52:00 PM UTC-5, RobertCNelson wrote:

[jim.la...@gmail.com]

OK, more digging.

Putting 'HEAD' in for BR2_LINUX_KERNEL_CUSTOM_GIT_VERSION forces a complete pull of the latest code (there isn't a tag called 'HEAD', so GIT punts and creates a local repository called 'linux-HEAD' with all of the latest commits).

But of course, there is always something... there appears to be a problem with the power management stuff, resulting in a build failure:

  LD      sound/soundcore.o
  LD      sound/built-in.o
make[2]: *** No rule to make target `firmware/am335x-pm-firmware.bin', needed by `firmware/am335x-pm-firmware.bin.gen.o'.  Stop.
make[1]: *** [firmware] Error 2
make[1]: *** Waiting for unfinished jobs....
  CC      drivers/net/mii.o
  CC      drivers/mtd/ubi/upd.o

There is a 'am335x-pm-firmware.bin.gen.S' file in the firmware directory, but this is not present in other versions of the kernel that I have been working with from the TI GIT repository.  When booting those variants (which don't have working MMC/SD support), they all seem to load up an 'am335x-pm-firmware.bin' file, which they are getting from who knows where; perhaps the 'am33x-cm3-AM335xPSP_04.06.00.10-rc1' project in output/build?

Argh. 

Sorry to vent,
Jim

[Jason Kridner]

It is possible to use a head tag, but I just pushed that particular
commit back in on a new branch and tagged it. That should mean it is
there if you try again.

[jim.la...@gmail.com]

Jason,

Thanks so much for pushing the commit!

I can now successfully build a bootable version of the sources and access to the MMC/SD seems to work (all I needed was the SD for persisting configuration data).

Thanks again,
Jim

[Felipe ordoñez]

Hi, 

I have tried to save my information with this procedure,  but when the BBB start  (Power led ON),  with the S2 pushed,  The USR leds are not Blinked (OFF), I pushed for several seconds and minutes, but they do not turn ON,    after 15 or 20 min. nothing happen inseide the uSD,  no data are save?

Could someone help me?,   can't have my data save in order to reflashed the BBB

[Felipe ordoñez]

[sh...@m2mac.com]

First of all, thank you for this post, it works great on my latest BBBs (REV C). However, I cannot get it to work with my older BBBs (REV A6). We have quite a few of the older versions laying around and would like to use those for some KIOSKs we are setting up in house. Unfortunately, the script does not want to work on these boards. The script is booting to the SD card but it does not appear to recognize (or mount) the eMMC. I added `ls /dev > /mnt/dev.txt` to the bash script so I could see the device list, and there is only mmcblk0, there is not a mmcblk1. I am powering the device with a 5V, 2A power supply and have disconnected all other cables (as suggested in other posts) and still no luck. The device goes straight to a solid LED and writes the dev.txt and a 1KB img.gz file. I have tried running it on multiple boards and am unsure what to try next. Any thoughts as to why the eMMC is not being loaded/mounted?

[swilli...@gmail.com]

I had this same problem. I hadn't set the SD disk partition to "ACTIVE". Once I did that the LEDs came on.