How to prevent flashing SD card image to eMMC?

GoogleGroups
1

I downloaded a new image onto an SD card and booted my BBB. I then edited the /boot/uEnv.txt file to remove the comment from the last line to enable flashing to the eMMC upon reboot. It worked as expected.

Now I have an SD card with an image that I could use again as a backup boot device - but I need to re-comment the flasher line. If I boot from the SD card it will flash again (correct?). How can I get access to the /boot/uEnv.txt file on the SD card? Can I mount it somehow after booting from the eMMC? I tried to mount the SD card on a Mac to edit the file, but only the FAT partition was accessible.

2

Just plug it in after it boots off the eMMC..

Regards,

3

Well yes, I can mount and edit. It didn’t occur to me that a card inserted after boot would be detected. Thanks for that advice. Following up with more on the topic:

  1. Is there a reason that the SD card isn’t in /etc/fstab to make mounting simple for beginners - or auto-mounted? In other words, is that a bad idea to be avoided? Perhaps an issue with trying to share a single image for SDcard and eMMC boooting?
  2. On the image I downloaded and put on the SD card there is both /boot/uEnv.txt and /uEnv.txt. What is the reason/purpose for the /uEnv.txt? I’m pretty sure I didn’t create/copy it - it’s totally different than /boot/uEnv.txt - from comments it looks like it aims to support older Angstrom/2014 Debian systems?
  3. If I understand correctly there is another FAT volume on the eMMC as shipped, that is seen as a remote (FAT?) volume when the BBB is connected as a USB client. Is there any way to mount that for access from the bone directly?

Thanks for the earlier response.

4

Well yes, I can mount and edit. It didn't occur to me that a card inserted
after boot would be detected. Thanks for that advice. Following up with more
on the topic:

1) Is there a reason that the SD card isn't in /etc/fstab to make mounting
simple for beginners - or auto-mounted? In other words, is that a bad idea
to be avoided? Perhaps an issue with trying to share a single image for
SDcard and eMMC boooting?

There's no guarantee users would plug in a microSD with the exact same
configuration..

2) On the image I downloaded and put on the SD card there is both
/boot/uEnv.txt and /uEnv.txt. What is the reason/purpose for the /uEnv.txt?
I'm pretty sure I didn't create/copy it - it's totally different than
/boot/uEnv.txt - from comments it looks like it aims to support older
Angstrom/2014 Debian systems?

/uEnv.txt is just for backwards compatibility with older eMMC images.

3) If I understand correctly there is another FAT volume on the eMMC as
shipped, that is seen as a remote (FAT?) volume when the BBB is connected as
a USB client. Is there any way to mount that for access from the bone
directly?

It's a raw image file, /var/local/*.img

Regards,

5

…

  1. Is there a reason that the SD card isn’t in /etc/fstab to make mounting
    simple for beginners - or auto-mounted? In other words, is that a bad idea
    to be avoided? Perhaps an issue with trying to share a single image for
    SDcard and eMMC boooting?

There’s no guarantee users would plug in a microSD with the exact same
configuration…

I was able to mount the card without knowing the type, apparently mount is smart enough to determine on its own. Does this mean that despite this capability, each /etc/fstab entry requires full type&option specification?

  1. On the image I downloaded and put on the SD card there is both
    /boot/uEnv.txt and /uEnv.txt. What is the reason/purpose for the /uEnv.txt?
    I’m pretty sure I didn’t create/copy it - it’s totally different than
    /boot/uEnv.txt - from comments it looks like it aims to support older
    Angstrom/2014 Debian systems?

/uEnv.txt is just for backwards compatibility with older eMMC images.

This confused me (the image on the SD card is a new version, how can backwards compatibility be needed?) Not arguing, as you certainly are correct. Can a system running an older version from eMMC be used to boot from the SD card, requiring a read of the older format uEnv.txt? I’m just grasping for an explanation with this.

  1. If I understand correctly there is another FAT volume on the eMMC as
    shipped, that is seen as a remote (FAT?) volume when the BBB is connected as
    a USB client. Is there any way to mount that for access from the bone
    directly?

It’s a raw image file, /var/local/*.img

Thanks for this (partial) answer (not sarcasm here). It required that I do some research to fully understand your response, so I learned even more. I had assumed it was a separate partition on the SD card, exposed by the USB client. Now I see that there is only one partition on the SD card, and these “file systems” presented by the USB interface are just image files, which themselves can be mounted (if you know the magic, i.e. starting sector). I never tried to modify this content when accessed through USB - I didn’t realize it is read-only. (please correct me if any of this is wrong)

6

I was able to mount the card without knowing the type, apparently mount is
smart enough to determine on its own. Does this mean that despite this
capability, each /etc/fstab entry requires full type&option specification?

Yet, you specified the partition number.

/uEnv.txt is just for backwards compatibility with older eMMC images.

This confused me (the image on the SD card is a new version, how can
backwards compatibility be needed?) Not arguing, as you certainly are
correct. Can a system running an older version from eMMC be used to boot
from the SD card, requiring a read of the older format uEnv.txt? I'm just
grasping for an explanation with this.

Well, the am335x bootrom reads the eMMC first on poweron. Thus for
older versions of U-Boot in eMMC, the backwards compatibility is
needed.

> 3) If I understand correctly there is another FAT volume on the eMMC as
> shipped, that is seen as a remote (FAT?) volume when the BBB is
> connected as
> a USB client. Is there any way to mount that for access from the bone
> directly?

It's a raw image file, /var/local/*.img

Thanks for this (partial) answer (not sarcasm here). It required that I do
some research to fully understand your response, so I learned even more. I
had assumed it was a separate partition on the SD card, exposed by the USB
client.

It use to be it's own partition, but this led to other user issues, so
it was moved to an *.img file. That file is also maintained by an apt
package, so updates can be pushed.

Now I see that there is only one partition on the SD card, and these
"file systems" presented by the USB interface are just image files, which
themselves can be mounted (if you know the magic, i.e. starting sector). I
never tried to modify this content when accessed through USB - I didn't
realize it is read-only. (please correct me if any of this is wrong)

or just use losetup/kpartk:

#find free loop device
sudo losetup -f
/dev/loop0

sudo losetup /dev/loop0 beaglebone-getting-started-2017-01-25.img
sudo kpartx -av /dev/loop0

sudo mkdir disk
sudo mount /dev/mapper/loop0p1 disk/

cd disk/
ls -lh
total 90K
drwxr-xr-x 2 root root 2.0K Feb 14 15:50 App
-rwxr-xr-x 1 root root 288 Feb 14 15:50 autorun.inf
drwxr-xr-x 4 root root 2.0K Feb 14 15:50 Docs
drwxr-xr-x 5 root root 2.0K Feb 14 15:50 Drivers
-rwxr-xr-x 1 root root 41K Feb 14 15:50 LICENSE.txt
-rwxr-xr-x 1 root root 17K Feb 14 15:50 README.htm
-rwxr-xr-x 1 root root 428 Feb 14 15:50 README.md
drwxr-xr-x 2 root root 2.0K Feb 14 15:50 scripts
-rwxr-xr-x 1 root root 17K Feb 14 15:50 START.htm

Regards,

7

I was able to mount the card without knowing the type, apparently mount is
smart enough to determine on its own. Does this mean that despite this
capability, each /etc/fstab entry requires full type&option specification?

Yet, you specified the partition number.

Ugh. Yes, I did. Point being (point taken) that partitioning on the SD card is unknowable, so no way to auto-mount the SD card. I suppose the first partition could be auto-mounted, but that may or may not be what is desired, so best to do nothing. Sorry I missed that obvious issue…

/uEnv.txt is just for backwards compatibility with older eMMC images.

This confused me (the image on the SD card is a new version, how can
backwards compatibility be needed?) Not arguing, as you certainly are
correct. Can a system running an older version from eMMC be used to boot
from the SD card, requiring a read of the older format uEnv.txt? I’m just
grasping for an explanation with this.

Well, the am335x bootrom reads the eMMC first on poweron. Thus for
older versions of U-Boot in eMMC, the backwards compatibility is
needed.

Does that mean that it’s not possible to boot a bone from SD card if there is no uboot in eMMC? Or is eMMC uboot needed to provide logic that overrides the bootrom search order, bypassing valid boot code that is found before reaching the SD card?

  1. If I understand correctly there is another FAT volume on the eMMC as
    shipped, that is seen as a remote (FAT?) volume when the BBB is
    connected as
    a USB client. Is there any way to mount that for access from the bone
    directly?

It’s a raw image file, /var/local/*.img

Thanks for this (partial) answer (not sarcasm here). It required that I do
some research to fully understand your response, so I learned even more. I
had assumed it was a separate partition on the SD card, exposed by the USB
client.

It use to be it’s own partition, but this led to other user issues, so
it was moved to an *.img file. That file is also maintained by an apt
package, so updates can be pushed.

Clever - particularly being able to push updates.

Now I see that there is only one partition on the SD card, and these
“file systems” presented by the USB interface are just image files, which
themselves can be mounted (if you know the magic, i.e. starting sector). I
never tried to modify this content when accessed through USB - I didn’t
realize it is read-only. (please correct me if any of this is wrong)

This will need more study. Thanks for the homework… :slight_smile:

8

Does that mean that it's not possible to boot a bone from SD card if there
is no uboot in eMMC? Or is eMMC uboot needed to provide logic that overrides
the bootrom search order, bypassing valid boot code that is found before
reaching the SD card?

microSD is after eMMC. The bootrom is only looking for a simple magic
header, if it finds the magic header it jumps to that code. Otherwise
it just moves on to the next supported bootable media type.

Regards,