I have an old BBB with a 2Gb eMMC (A5A) and inadvertently plugged a
microSD with a 4Gb IOT version of Debian on it. What should happen?
I *think* it's simply running from the microSD card which seems quite
sensible. Is there an easy way of telling what memory it's running
from?
On Sat, 12 May 2018 13:46:57 +0100, Chris Green
<cl@isbd.net> declaimed the following:
I have an old BBB with a 2Gb eMMC (A5A) and inadvertently plugged a
microSD with a 4Gb IOT version of Debian on it. What should happen?
If the contents of the eMMC are really old, it likely doesn't even look
at the SD card unless you hold down the alternate boot button.
If the contents are rather modern, it may run uBoot from the eMMC and
then transition to the SD card (and that could fail if the eMMC uBoot
expects late [kernel] loading of device tree overlays, but the SD card
expects early [uBoot] device tree loading).
I *think* it's simply running from the microSD card which seems quite
sensible. Is there an easy way of telling what memory it's running
from?
Well, given the memory sizes, a quick test would just be to do "df"
from a console connection, and seeing what the largest partition comes up
as. Or try "uname -a" on the assumption that the SD card has a much newer
OS.
Or, maybe... closely observe the blinkenlights... One identifies mmc0
activity, and another mmc1 activity (now -- which is considered 0 and 1 is
an exercise for the user; I have a vague memory that at one point in the
past, 0 and 1 depended upon which device was used for booting, and was not
fixed to eMMC vs SD).
On Sat, 12 May 2018 13:46:57 +0100, Chris Green
<cl@isbd.net> declaimed the following:>I have an old BBB with a 2Gb eMMC (A5A) and inadvertently plugged a
(actually an A6A, misread the label)
>microSD with a 4Gb IOT version of Debian on it. What should happen?
>
If the contents of the eMMC are really old, it likely doesn't even look
at the SD card unless you hold down the alternate boot button.If the contents are rather modern, it may run uBoot from the eMMC and
then transition to the SD card (and that could fail if the eMMC uBoot
expects late [kernel] loading of device tree overlays, but the SD card
expects early [uBoot] device tree loading).
They're both modern as I'd already (after some hassle due the above
things you've noted) getting a Debian 9.4 console installed into the
eMMC. I was only trying to check whether the IOT image was good, I
didn't actually want it on the BBB. It's just a spare BBB, not being
used for anything at the moment.
>I *think* it's simply running from the microSD card which seems quite
>sensible. Is there an easy way of telling what memory it's running
>from?
>
Well, given the memory sizes, a quick test would just be to do "df"
from a console connection, and seeing what the largest partition comes up
as. Or try "uname -a" on the assumption that the SD card has a much newer
OS.
Yes, that's sort of how I concluded that it must be running from the
microSD but I wondered if there was a more definite way.
Or, maybe... closely observe the blinkenlights... One identifies mmc0
activity, and another mmc1 activity (now -- which is considered 0 and 1 is
an exercise for the user; I have a vague memory that at one point in the
past, 0 and 1 depended upon which device was used for booting, and was not
fixed to eMMC vs SD).
Yes, I don't think the mmc0/mmc1 thing helps much, they seem not to
relate spcifically to eMMC and microSD - which is a pity.
Thanks for all the ideas.
On Sun, 13 May 2018 09:36:09 +0100, Chris Green
<cl@isbd.net> declaimed the following:
Okay, I've not updated mine in some time...
Or, maybe... closely observe the blinkenlights... One identifies mmc0
activity, and another mmc1 activity (now -- which is considered 0 and 1 is
an exercise for the user; I have a vague memory that at one point in the
past, 0 and 1 depended upon which device was used for booting, and was not
fixed to eMMC vs SD).Yes, I don't think the mmc0/mmc1 thing helps much, they seem not to
relate spcifically to eMMC and microSD - which is a pity.
Booting from the eMMC showed most, if not all, activity on LED 3 (0
being the heartbeat).
debian@beaglebone:~$ uname -a
Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l
GNU/Linux
debian@beaglebone:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 10240 0 10240 0% /dev
tmpfs 99956 2924 97032 3% /run
/dev/mmcblk1p1 3704040 3064828 431340 88% /
tmpfs 249888 4 249884 1% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 249888 0 249888 0% /sys/fs/cgroup
tmpfs 49980 0 49980 0% /run/user/1000
debian@beaglebone:~$
Now, installing an old SD card and rebooting (forgot how long the BBB
takes to shutdown) had some flickers on LED 3, but most activity is now on
LED 1
debian@beaglebone:~$ uname -a
Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l
GNU/Linux
debian@beaglebone:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 10240 0 10240 0% /dev
tmpfs 99956 2924 97032 3% /run
/dev/mmcblk0p1 7570776 3037308 4174464 43% /
tmpfs 249888 4 249884 1% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 249888 0 249888 0% /sys/fs/cgroup
tmpfs 49980 0 49980 0% /run/user/1000
debian@beaglebone:~$
A second SD card (after a full shutdown, since I don't want to corrupt
it by having the system trying to flush to the old one)... Most activity
still on LED 1 during boot.
debian@beaglebone:~$ uname -a
Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l
GNU/Linux
debian@beaglebone:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 10240 0 10240 0% /dev
tmpfs 99956 2924 97032 3% /run
/dev/mmcblk0p1 7570776 3037312 4174460 43% /
tmpfs 249888 4 249884 1% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 249888 0 249888 0% /sys/fs/cgroup
tmpfs 49980 0 49980 0% /run/user/1000
debian@beaglebone:~$
Interesting -- all show the same "uname" results, but the "df" results
are different. Based on "apt-get update" all three must still be Jessie
installs. Time to configure one of the cards with the Stretch (or whatever
the current is called) build (and remember how to copy my home
configuration settings across, do an eMMC flash, and then "unflasher" the
SD card and resize the partition.
On Sun, 13 May 2018 09:56:44 -0400, Dennis Lee Bieber
<wlfraed@ix.netcom.com> declaimed the following:
debian@beaglebone:~$ uname -a
Linux beaglebone 4.4.54-ti-r93 #1 SMP Fri Mar 17 13:08:22 UTC 2017 armv7l
GNU/Linux
debian@beaglebone:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 10240 0 10240 0% /dev
tmpfs 99956 2924 97032 3% /run
/dev/mmcblk0p1 7570776 3037312 4174460 43% /
tmpfs 249888 4 249884 1% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 249888 0 249888 0% /sys/fs/cgroup
tmpfs 49980 0 49980 0% /run/user/1000
debian@beaglebone:~$Interesting -- all show the same "uname" results, but the "df" results
are different. Based on "apt-get update" all three must still be Jessie
installs. Time to configure one of the cards with the Stretch (or whatever
the current is called) build (and remember how to copy my home
configuration settings across, do an eMMC flash, and then "unflasher" the
SD card and resize the partition.
Just put the latest standard image on SD card and rebooted. LED 1
showed main activity again. I haven't resized the partition yet
debian@beaglebone:~$ uname -a
Linux beaglebone 4.9.78-ti-r94 #1 SMP PREEMPT Fri Jan 26 21:26:24 UTC 2018
armv7l GNU/Linux
debian@beaglebone:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 219744 0 219744 0% /dev
tmpfs 49584 5168 44416 11% /run
/dev/mmcblk0p1 3357264 2754468 412540 87% /
tmpfs 247912 0 247912 0% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 247912 0 247912 0% /sys/fs/cgroup
tmpfs 49580 4 49576 1% /run/user/110
tmpfs 49580 0 49580 0% /run/user/1000
debian@beaglebone:~$
Going to get nervy, and make it a flasher first, update the eMMC...