Trying to clone my old BBB system with only half success.

General Discussion
1

I have been running a BBB as an aquarium controller for a really long time now, and until a lightning strike it was just fine. Now the ethernet jack is dead which is an issue (wifi dongle has always been iffy at best). I delayed dealing with it since it was still ‘working’ and the time was not drifting that fast for weeks, but then it lost power and time. Now i have to deal with it. Got a new board, serial cable and a micro hdmi since i wasn’t sure what would work or not.

Googlefu led me to a stack overflow question on how to clone the eMMC with some scripts. The onboard one doesn’t seem to work, i get this:
$ sudo ./beaglebone-black-make-microSD-flasher-from-eMMC.sh
Error: script halting, system unrecognized…

Another reply had a script that worked fine for saving the eMMC to the card, but uncommenting the script to run it back didn’t. The same reply also had a different script edit for the flashing which required the image be decompressed, but that also doesn’t go. Running this script:
#!/bin/sh
echo timer > /sys/class/leds/beaglebone:green:usr0/trigger
dd if=/mnt/.img of=/dev/mmcblk1 bs=10M
sync
echo default-on > /sys/class/leds/beaglebone:green:usr0/trigger

I get this:
Running /dev/mmcblk0p1/autorun.sh…
dd: writing ‘/dev/mmcblk1’: No space left on device

I assumed it was some size issue so i used wsl to shrink the image with a script called PiShrink from github. Seems to have done a good job going from under 4 to like 1.3 gig. But i get the same error.

I have also imaged the sd card with the img file from the first save from the original board and it boots fine on the new board. On the booted image i have tried the onboard scripts to flash the eMMC without success as well. Like so:
$ sudo ./init-eMMC-flasher-v2.sh
Valid EEPROM header found

debug copying: →
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 3.7G 0 disk
├─mmcblk0p1 179:1 0 96M 0 part
└─mmcblk0p2 179:2 0 3.5G 0 part /

Error: does not exist
writing to failed…

Both manually running it and running it from uEnv on init.

Now i have pretty much run out of googlefu. I am practically thinking of just running it off the sd card and replacing it when it dies, but i also don’t know how reliably it would boot off the sd card instead of the eMMC.

Almost seems like i have to be doing something fundamentally wrong for these different methods to all not work.

I know the original image is old and eol, its ubuntu-14.04-console-armhf-2014-08-13, kernel(?) 3.8.13-bone63, but i actually seem to have a copy of it on a drive still. Not sure if that would help though. I don’t remember half the things i have done make the thing work so updating would end up half building a new one which seems counter productive.

Any ideas?

2

That would be fun. Just get another board to dev on and when you get it dialed in swap it out. An overlay and some python you would be up and running.

As far as saving your old board???

3

Should not be too hard.

Get a new minimal image (NON FLASHER) and write to a sd-card - at least 8Gb in size

Best if you connect the serial debug console.

Insert card into BBB and hold down the boot button, by the sd-card holder. Insert power and wait for boot. First boot may take some time as it should resize the sd-card patition to fill the sd-card.

Once booted you can run df -h to check for free space. - might need a reboot.

Once you are sure you are running from the sd-card you can do

dd if=/dev/mmcblk of=image.img bs=32M
(can’t remember if emmc is blk0 or blk1, can try cat /proc/mounts to see which device is mounted)

It will take a while but should create a raw image of the emmc, around 4G in size.
Shutdown the board.

On new board insert the sd-card, keep boot button pressed and power on.
once booted you just need to

dd if=image.img of=/dev/mmcblk? bs=32M

It should be a bit faster writing the image back to the emmc, but will still take several minutes.
remove the sd-card and reboot.

3 Likes
4

Sounds like what i tried is correct then just somehow it lacks the ability to see the emmc on the old sd card booted image? Or something like that. Here is what i see on lsblk from the sd booted old image:

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
mmcblk0     179:0    0   3.7G  0 disk
├─mmcblk0p1 179:1    0    96M  0 part
└─mmcblk0p2 179:2    0   3.5G  0 part /

I got the image off the old BBB just fine, again, and when i went to dd it in it seemed fine, since it just locks up for a bit. But in the end it says it ran out of space. I actually didn’t try to see if it ‘worked’ at that point or not, instead started to google my way to shrinking the image on the BBB booted off the sd card with the image file saved. I thought i did it, instructions seemed to make sense, but it doesn’t boot successfully.

New BBB booting into the old image on emmc:

[    0.820511] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single
[    0.885692] mmc1: unrecognised EXT_CSD revision 8
[    0.890663] mmc1: error -22 whilst initialising MMC card
Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/disk/by-uuid/8b3a60b2-0fe8-497b-acd6-523681bb66aa does not exist.  Dropping to a shell!

Old BBB booting at the same point:

[    0.822537] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single
 * Starting Mount filesystems on boot                                    [ OK ]

As an aside this is the new BBB booting off the sd with the old image:

[    0.824461] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single
[    0.918921] mmc1: unrecognised EXT_CSD revision 8
[    0.923887] mmc1: error -22 whilst initialising MMC card
 * Stopping Send an event to indicate plymouth is up                     [ OK ]
 * Starting Mount filesystems on boot                                    [ OK ]

I tried to ls for /dev/disk and i didn’t see it at all when it dropped into shell. But that would make sense if it can’t find it to boot off it, i can’t find it either.

I got the old image again assuming i messed up the shrinking and these are the dd out and in:

368+1 records in
368+1 records out
3867148288 bytes (3.9 GB, 3.6 GiB) copied, 264.853 s, 14.6 MB/s

dd: error writing '/dev/mmcblk1': No space left on device
366+0 records in
365+0 records out
3827957760 bytes (3.8 GB, 3.6 GiB) copied, 230.625 s, 16.6 MB/s

It did not even attempt to boot with that… Power on nothing happens in console. Shrink it again i guess?

5

Not all 4G emmc are the same size same with different brands of sd cards.
If it runs out of room copying back it will probably boot just fine. The end sector in the main partition will probably point beyond the end of the emmc. I belive ext4 has a copy of file system info at the end of the partition, which is going to be invalid.

You might be able to use one of the disk partitioning tools ( maybe sfdisk) to correct the end sector and the do an fsck on the patition.

Assuming you don’t use dd to copy, the other option would be to rsync the emmc root file system with the correct flags to a backup directory on the sd card. But that potentially won’t copy the boot stuff properly.

6

You really have an old image… i fixed this on Jun 15, 2016, you need to upgrade to 3.8.13-bone80 or greater first!!!

Regards,

7

That error only appears on the new BBB. Either with the old image on SD card, which boots fine, or off the emmc which did not. The old BBB doesn’t show that and i do think its the same kernel version? Did something physically change on the BBB emmc and the old kernel can’t find it? That would explain also why i can’t see the emmc while booted off the old image on SD card, and why the original script to clone directly didn’t work… I sort of assumed because of the missing ‘e’ the MMC card was the SD card for some reason and just glossed over that error thinking its weird it complains but still works fine.

Now i am sure i did at one point update the kernel a bunch of times, i remember following along getting 1 wire to work with .dts files and whatnot, pretty sure it only became possible around this time. But i have lost all that knowledge since. Other than the minimum being 3.8.13-bone80 is there a max where things would change significantly enough to break stuff? Or kernel updates fairly safe?

Thanks

8

Made some progress again i think. Got yakbuild working based on some other posts here and built a 3.8.13-bone80 setup with:

toolchain="gcc_linaro_gnueabihf_4_7" 
kernel_tag="3.8.13-bone80"

Not sure if the first thing is right it just looked the oldest and my memory liked the gnueabihf thing, i remember typing that. At least it built, so probably fine. Based on that same post i am now again slightly confused since i could either build a zImage or a uImage but i can’t find either in my image, so is it something else entirely? Read some other things here and decided to boot up the old image with console again to see:

Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt...
...
Running uname_boot ...
loading /boot/vmlinuz-3.8.13-bone63 ...
5515696 bytes read in 367 ms (14.3 MiB/s)
loading /boot/dtbs/3.8.13-bone63/am335x-boneblack.dtb ...
25926 bytes read in 54 ms (468.8 KiB/s)
loading /boot/initrd.img-3.8.13-bone63 ...
2972804 bytes read in 222 ms (12.8 MiB/s)
Kernel image @ 0x82000000 [ 0x000000 - 0x5429b0 ]
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Ramdisk to 8fd2a000, end 8ffffc84 ... OK
   Loading Device Tree to 8fd20000, end 8fd29545 ... OK

Starting kernel ...

It loads 3 files and i only have two from the build. Based on size alone the vmlinuz seems like it would be the zImage kernel equivalent. But i doubt its that simple. The other seems to be a container in 7z and based on its contents maybe its fine in any 3.8 kernel (contains a initrd.img-3.8 archive)? So maybe i just need to rename/copy that as the new kernel version. Then copy over the dtbs file it loads and all good?

9

Yeah, eMMC 5.1 was ratified and hardware using that spec got released… which broke things years ago.

10

Correct just rename the zImage as: /boot/vmlinuz-3.8.13-bone80

Boot without it, then run:

sudo update-initramfs -ck `uname -r`

To generate it.

Regards,

1 Like
11

Been trying to get this latest step to work. I first assumed i broke the img file shrinking it, so i’ve re-done that multiple times and multiple ways. I’ve also tried just on SD card with the full file system size and it comes out with the same errors on boot.

[    0.635701] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single
Mount failed for selinuxfs on /sys/fs/selinux:  No such file or directory
 * Stopping Send an event to indicate plymouth is up                     [ OK ]

And a bit later.

Errors were found while checking the disk drive for /.
keys:Press F to attempt to fix the errors, I to ignore, S to skip mounting, or M for manual recovery
 * Stopping Send an event to indicate plymouth is up                     [ OK ]
[   18.210719] libphy: PHY 4a101000.mdio:01 not found

Ignoring the disk error did get me past, then i ran the update-initramfs but now it simply stops loading at the same spot in the console each time, right before where the other error appeared:

loading /boot/vmlinuz-3.8.13-bone80 ...
5547120 bytes read in 373 ms (14.2 MiB/s)
loading /boot/dtbs/3.8.13-bone80/am335x-boneblack.dtb ...
26118 bytes read in 60 ms (424.8 KiB/s)
loading /boot/initrd.img-3.8.13-bone80 ...
Kernel image @ 0x82000000 [ 0x000000 - 0x54a470 ]
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Ramdisk to 8fff9000, end 8ffff606 ... OK
   Loading Device Tree to 8ffef000, end 8fff8605 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.178157] omap2_mbox_probe: platform not supported
[    0.335455] tps65217-bl tps65217-bl: no platform data provided
[    0.397720] bone-capemgr bone_capemgr.9: slot #0: No cape found
[    0.434827] bone-capemgr bone_capemgr.9: slot #1: No cape found
[    0.471934] bone-capemgr bone_capemgr.9: slot #2: No cape found
[    0.509044] bone-capemgr bone_capemgr.9: slot #3: No cape found
[    0.524011] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN conflict P8.45 (#5:BB-BONELT-HDMI)
[    0.533623] bone-capemgr bone_capemgr.9: slot #6: Failed verification
[    0.540367] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 BB-BONELT-HDMIN:00A0 (prio 2)
[    0.555164] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed
[    0.616748] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8
[    0.628412] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22
[    0.635695] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single

I didn’t think the first would matter, google made it sound like just a thing that it checks and if it isn’t there thats fine. But results seem more like it is hard stopping trying to find it.

12

Took a break from this over the holidays, but i tried some more things. First, i tried different kernel versions, with 3.8.13-bone86 now as my test subject. Doesn’t seem to matter though. I tried changing the command line in uEnv.txt to have selinux=0:

##enable BBB: eMMC Flasher:
cmdline=selinux=0

But i wasn’t sure that even did anything. So i changed the quiet command line to verbose (guessing thats a valid option) hoping to see it at least try, and possibly fail, with to use that option. I do see a whole lot more, specifically I see this now, right before it just locks up on boot as before:

[    2.476657]   #0: TI BeagleBone Black
[    2.480997] RAMDISK: gzip image found at block 0
[    2.486157] uncompression error
[    2.489719] Waiting for root device UUID=8b3a60b2-0fe8-497b-acd6-523681bb66aa...

Now, i had changed CONFIG_SECURITYFS=y to =n in the config-3.8.13-bone86 before running
update-initramfs this latest time, but i don’t suspect that changed the error since it happened on multiple different attempts just silently before.

Here is all the log past the previous attempts stopping point:

[    2.003232] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22
[    2.010514] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single
[    2.019640] leds-gpio gpio-leds.8: pins are not configured from the driver
[    2.027623] ledtrig-cpu: registered to indicate activity on CPUs
[    2.034216] edma-dma-engine edma-dma-engine.0: allocated channel for 0:36
[    2.041364] omap-sham 53100000.sham: hw accel on OMAP rev 4.3
[    2.048759] omap-aes 53500000.aes: OMAP AES hw accel rev: 3.2
[    2.054977] edma-dma-engine edma-dma-engine.0: allocated channel for 0:5
[    2.062100] edma-dma-engine edma-dma-engine.0: allocated channel for 0:6
[    2.072160] usbcore: registered new interface driver usbhid
[    2.078048] usbhid: USB HID core driver
[    2.082913] ashmem: initialized
[    2.086318] mmc0: host does not support reading read-only switch. assuming write-enable.
[    2.095020] logger: created 256K log 'log_main'
[    2.100020] logger: created 256K log 'log_events'
[    2.105069] mmc0: new high speed SDHC card at address 1234
[    2.111020] logger: created 256K log 'log_radio'
[    2.116331] mmcblk0: mmc0:1234 SA04G 3.63 GiB
[    2.121215] logger: created 256K log 'log_system'
[    2.128160]  mmcblk0: p1 p2
[    2.133566] davinci_evm sound.14:  nxp-hdmi-hifi <-> 48038000.mcasp mapping ok
[    2.143242] TCP: cubic registered
[    2.146848] NET: Registered protocol family 10
[    2.152300] NET: Registered protocol family 17
[    2.157283] Key type dns_resolver registered
[    2.161945] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[    2.170052] ThumbEE CPU extension supported.
[    2.174560] Registering SWP/SWPB emulation handler
[    2.180259] registered taskstats version 1
[    2.186235] tilcdc 4830e000.fb: No power control GPIO
[    2.243651] mmc1: BKOPS_EN bit is not set
[    2.251224] mmc1: new high speed MMC card at address 0001
[    2.257360] mmcblk1: mmc1:0001 MT3204 3.56 GiB
[    2.262331] mmcblk1boot0: mmc1:0001 MT3204 partition 1 2.00 MiB
[    2.268734] mmcblk1boot1: mmc1:0001 MT3204 partition 2 2.00 MiB
[    2.276285]  mmcblk1: p1 p2
[    2.279443] mmcblk1: p2 size 7354368 extends beyond EOD, truncated
[    2.288260]  mmcblk1boot1: unknown partition table
[    2.295011]  mmcblk1boot0: unknown partition table
[    2.302414] tilcdc 4830e000.fb: found TDA19988
[    2.307658] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    2.314573] [drm] No driver support for vblank timestamp query.
[    2.321056] tilcdc 4830e000.fb: No connectors reported connected with modes
[    2.328348] [drm] Cannot find any crtc or sizes - going 1024x768
[    2.343446] Console: switching to colour frame buffer device 128x48
[    2.355666] tilcdc 4830e000.fb: fb0:  frame buffer device
[    2.361316] tilcdc 4830e000.fb: registered panic notifier
[    2.366978] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0
[    2.420926] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[    2.427317] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
[    2.434809] libphy: 4a101000.mdio: probed
[    2.439035] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[    2.448733] Detected MACID = 98:89:24:73:91:aa
[    2.453305] cpsw 4a100000.ethernet: NAPI disabled
[    2.459842] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 00:00:01 UTC (946684801)
[    2.473497] ALSA device list:
[    2.476657]   #0: TI BeagleBone Black
[    2.480997] RAMDISK: gzip image found at block 0
[    2.486157] uncompression error
[    2.489719] Waiting for root device UUID=8b3a60b2-0fe8-497b-acd6-523681bb66aa...

Is it trying to boot off the start of the SD card, which is the ‘BeagleBone Getting Started’ windows partition? But why does it only do that after running the update-initramfs?

13

I think my original BBB is failing worse now, its I2C control may have gone or at least its spamming console about it. Either way i was getting desperate and about to just chuck the img on a SD card and run it off that.

But i decided to try one more thing. Since it ‘runs’ off the new kernels and only fails to finally boot with the update-initramfs done, what would it do if i didn’t run the script and just copied the old one? Apparently, it just works. I booted the new BBB off the SD card with kernel 3.8.13-bone86 and initrd.img-3.8.13-bone63 (renamed to 86) and even ran the built in script to flash it to eMMC successfully. Then it booted off the eMMC successfully too. Yay!

Last login: Tue Jan  7 17:50:31 CST 2025 on ttyO0
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.8.13-bone86 armv7l)

Not sure what the difference is between the initrd.img files is, i have looked all around them for clues before too, but it probably doesn’t matter as it works.