Hi,
I’ve searched around and found many related questions but not exactly what I need.
I have a BBB completely set up (including uBoot/kernel/…) and want to make an image that I can give to scientists to replicate my setup. I specifically want to include the bootloader as well.
I used to boot from an sd card and dd the whole /dev/mmcblk1 to an file and redeploy that image to the same block device on the target device. Now, for the first time, this results in a device where the bootloader isn’t starting.
I can’t imagine this isn’t a common thing to do, so I would think better options exist. I believe creating a flasher image won’t copy everything, right?
Thanks,
dieter
For what it’s worth, I use
sudo mount /dev/mmcblk0p2 /mnt/temp/
sudo dd if=/dev/mmcblk1 bs=1M of=/mnt/temp/$1 bs=10M status=progress
in a batch script to create an image, and
sudo mount /dev/mmcblk0p2 /mnt/temp/
sudo dd of=/dev/mmcblk1 bs=1M if=/mnt/temp/$1 bs=1M status=progress
where /dev/mmcblk0p2 is a partition on the sd card where I keep my images.
This depends on the image, for Bullseye i cleaned up this process…
For the BeagleBone Black, there are two directions you can copy:
- microSD → eMMC
- eMMC → microSD
microSD → eMMC: (this is how the default flasher is configured)
Copy configuration file:
sudo cp -v /etc/beagle-flasher/beaglebone-black-microsd-to-emmc /etc/default/beagle-flasher
Then enable the “flasher” and reboot the board to have it flash the eMMC:
sudo enable-beagle-flasher
eMMC → microSD
Copy configuration file:
sudo cp -v /etc/beagle-flasher/beaglebone-black-emmc-to-microsd /etc/default/beagle-flasher
Then enable the “flasher” and reboot the board to have it flash the microSD:
sudo enable-beagle-flasher
Regards,
1 Like
I’m afraid I’m using Linux JAGUAR 5.10.162-ti-r58 #1buster SMP PREEMPT Sat Feb 25 19:28:34 UTC 2023 armv7l GNU/Linux.
There is no /etc/beagle-flasher so I presume this is something added to the Bullseye images?
Would this method include the bootloader etc?
I have no idea why the image I made with dd (from the whole block device) fails to even start the bootloader when copied on another BBB. Up until now, that worked fine. Any ideas? I’m lacking lots of knowledge there and find that is becoming a problem from time to time. Decided to start reading up but this has just come up as an issue…
So I back-ported this to buster it just wasn’t in older versions. You can also get u-boot for the BBB with this package bb-u-boot-am335x-evm
sudo apt update
sudo apt install bb-beagle-flasher bb-u-boot-am335x-evm
Can we assume your on the eMMC right now?
I would test:
sudo cp -v /etc/beagle-flasher/beaglebone-black-emmc-to-microsd /etc/default/beagle-flasher
Insert blank microSD, then run, the manual flasher:
sudo beagle-flasher
and watch it copy over your eMMC to microSD…
Then test this new microSD on another device to see if it’s what you expected…
Regards,
Unfortunately I’m at home and only have access through a reverse ssh connection right now, so no access to the SD card :).
The system runs from the eMMC indeed, and that is what I want to copy to another BB eMMC.
Is there any “obvious” reason why an image made with dd would not work for one specific image? Just wondering because up until now that was working and “good enough” for what I needed. I’m really in the dark as to why that could happen and would like to read up on it. I thought that if I copied everything sector-by-sector and the target device was similar to the source, it should work, but the last configured BBB deployment I tried to image that way just won’t work on other boards. Is there an offset of some sorts that needs to be set for some reason? Clearly I’m just guessing, and have not much knowledge…
I’ll test on Friday and report back. In any case, thank you for your help. Truly much appreciated.
dd would work if both devices had the exact same block size…
Hi Robert,
Got it to work but it seems the u-Boot does not get copied. The original BBB (where I made the image from) has 2019.04-g923f8b8 (jan 02 2022), the one on the deployed/new bbb has 2019.04-00002-g07d5700e21 (Mar 06 2020).
I know I can just update the u-Boot on each new deployment, but the idea is that I need to make it as simple as possible for the people using the images. Each option for errors will be exploited ;). Additionally, the network interface is configured to a static IP to be used inside a larger system. So they would have to change the network config, update, change network config again… I can add a shell script for them to run but still…
I realize that having an older version of the bootloader probably isn’t that much of a deal, but as I don’t really know too much about what happens during the imaging process I am wondering what else is missing?
Or maybe I’m wrong and there’s another explanation…
dd would work if both devices had the exact same block size
If anyone ever encounters the same issue as I had (making an image with dd, but having issues when deploying it on a chip with smaller size): I got around the size issue by:
- mounting the image file to a loopback device (ie
/dev/loopXX),
- then used Parted to resize the partition to fit on the target chip,
- unmount the image
After that I could use the image just fine.
1 Like
Robert,
Any idea why the bootloader would not get copied but I get an older version on the restored BBB? And most of all, how I could fix this so that it is included?
Thanks!
While it’s not 100% perfect, run beagle-version, to see what it detects, it’s packaged in the bb-beagle-version debian package:
debian@BeagleBone:~$ sudo beagle-version | grep bootloader
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL 2022.04-gd0771d53 (Jul 21 2022 - 02:13:23 +0000)]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL 2022.04-gd0771d53 (Jul 21 2022 - 02:13:23 +0000)]:[location: dd MBR]
Regards,