How to confirm if a beaglebone black has factory defaults after flashing with a MicroSD card

Hello,
I have been using a MicroSD card to flash a Beaglebone black back to factory defaults using the image for Debian Linux Version 8.4 from the following link: https://debian.beagleboard.org/images/bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz
After running a “df” command in ssh, I was consistently getting a value of 95% used space for the item /dev/mmcblk0p1 after flashing. However, when I got a new beaglebone, I tried the same command and got a value of 98% used space for /dev/mmcblk0p1. Does this mean the beaglebone is not true factory defaults after flashing? If not, what is the best way to confirm/compare a flashed beaglebone to a truly new beaglebone?

@ chenselman - Are you talking about the module or just an ordinary BBB? I think that the Module doesn’t have the GUI components so that image size will be smaller.

@ Mr. John Smith - sorry if this question is rather dumb but I don’t actually know the difference between a module and an ordinary bbb. I believe I’m using an ordinary bbb? What is a module?

@ cyberh0me - I’m just trying to see if there is a way to verify flashing a bbb with a microSD card is returning it to factory defaults correctly or not.
how do I make sure the included partition is not mounted, and then what tools would I need to use to do what you said? Sorry your terminology is new to me so I’m not sure what a hash calculated over the complete filesystem structure means.

If you reflash with the latest image, it may or may not be the same as what came from the factory (because the ‘factory’ may have used an earlier image, and the web site has the ‘latest’ image).

The ‘latest’ image is as close as you are going to get to the factory image and is really the only public option. You might be able to grab an earlier image used when your board was manufactured, but I’m not sure there’s much point to that exercise, as currently manufactured boards will have the newer image.

Does anyone know if the ‘factory’ uses jtag or some other mechanism to pre-load the eMMC? I would be surprised if they used flasher images, as those are deathly slow to load (20-30 minutes or more).

if you want to check if it setting it back to factory defaults, change your user password, Stick the uSD card in and reboot letting it do its thing to flash the eMMC, then on next reboot see if that precious password works. If it does not then you know it was set back to defaults.

@ mcalsyn - I don’t know if you can tell how they are doing it from the video

@ Mr. John Smith - well it’s not with a uSD card from the video - the uSD card slots in the bbb’s are all empty.

1 Like

It’s entirely possible that the factory version is using an older version that the current version. If they kept updating the to the new firmware, then it could break their automated tests and quality control.

1 Like

@ Mr. John Smith - Very interesting. The LEDs were flashing in the double-beat heartbeat pattern, but maybe the flash cycle was done already on those units. I can’t tell for sure if there is an SD card mounted, but the JTAG, usb and serial connectors look empty (which are the other ways you can boot and flash).

Maybe there are SD cards there and they just flash them that way in large batches over the course of a half-hour per batch. Maybe SD cards are just cheaper than JTAG pogo setups.

EDIT: I think @ chenselman is right - I don’t see SD cards, so whatever they did, we aren’t seeing it in that video.

The caption said flash and burn-in. I think what we were seeing was the burn-in phase. I don’t think we saw the flashing stage.

2 Likes

In large volumes you can have the factory that sells the eMMC flashed before they ship them.
Not saying that is what they did, just another possibility.

@ cyberh0me - well, is the important thing to check to make sure i’m flashing a bbb correctly the image name? will “uname -a” be a sufficient command to confirm flashing was done correctly?

@ chenselman - No, as cyberh0me said, you will have to do a checksum on the entire partition to verify that what was written is what was sent.

@ Mr. John Smith - oh ok, I’ve never done a checksum before. I’m assuming this can be done with SSH. What commands can I use to run a checksum?

@ chenselman - I’m not sure how; but it’s a linux thing : [SOLVED] How do i check hash checksum of boot partition? (encryption security)

Note, you can’t boot the partition and then attempt to run a checksum. The logs will change the data so you can’t do that. You will have to boot with SD card and then check the sum.

This might be a lot easier with a JTag header. I really need to get one myself.

@ Mr. John Smith - I’ve got the tincan jtag adapter and Segger j-link and I can confirm they work, but can’t say much more than that. The software setup is pretty fiddly. That said, I did get VisualGDB to talk to it, but haven’t done enough that I’m ready to write an article yet.

@ mcalsyn - I’ll consider it.