BeagleBone Black doesn't sometimes start. Only Power LED is on

RobertCNelson · October 8, 2015, 8:57pm

Sorry that this is probably a dumb question, but is it possible to not blow
away the partition table since I just want to swap the MLO and u-boot.img?

Using dd, just re-write them to the microSD... The partition table is
safe at another location..

I'm just running the standard image on a Beagle Bone Black that does not
have an eMMC or hdmi chip. I assumed it was busy because I was trying to
reprogram the disk while on an OS that was using the disk?

This was the error:

Checking that no-one is using this disk right now ...
BLKRRPART: Device or resource busy

After adding the force option it said:

Checking that no-one is using this disk right now ...
BLKRRPART: Device or resource busy

This disk is currently in use - repartitioning is probably a bad idea.
Umount all file systems, and swapoff all swap partitions on this disk.
Use the --no-reread flag to suppress this check.

Disk /dev/mmcblk0: 121008 cylinders, 4 heads, 16 sectors/track

sfdisk: ERROR: sector 3069576189 does not have an msdos signature
/dev/mmcblk0: unrecognized partition table type
Old situation:
No partitions found
New situation:
Units = mebibytes of 1048576 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start End MiB #blocks Id System
/dev/mmcblk0p1 * 1 3780 3780 3870720 83 Linux
/dev/mmcblk0p2 0 - 0 0 0 Empty
/dev/mmcblk0p3 0 - 0 0 0 Empty
/dev/mmcblk0p4 0 - 0 0 0 Empty
Successfully wrote the new partition table

ah, sfdisk is just noisly, it worked ^^^^...

Re-reading the partition table ...
BLKRRPART: Device or resource busy

later versions don't show this extra stuff...

I have the serial output after the last test, but not from the test where I
did not recreate the partition table.

U-Boot 2015.10-rc2-00001-g5879130-dirty (Oct 09 2015 - 15:52:49 +0000)

Watchdog enabled
I2C: ready
DRAM: 512 MiB
Reset Source: Global external warm reset has occurred.
Reset Source: Power-on reset has occurred.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Net: <ethaddr> not set. Validating first E-fuse MAC
cpsw
Hit any key to stop autoboot: 0
gpio: pin 53 (gpio 53) value is 1
switch to partitions #0, OK
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
Checking for: /uEnv.txt ...
Checking for: /boot.scr ...
Checking for: /boot/boot.scr ...
Checking for: /boot/uEnv.txt ...
** Invalid partition 2 **
** Invalid partition 3 **
** Invalid partition 4 **
** Invalid partition 5 **
** Invalid partition 6 **
** Invalid partition 7 **

This looks fine, based on where you stopped... it was searching for
the microSD card...

Regards,

William_Hermans · October 8, 2015, 9:19pm

Sorry that this is probably a dumb question, but is it possible to not blow
away the partition table since I just want to swap the MLO and u-boot.img?

Read everything below before half fast attempting such procedure

If I understand what you’re asking here, yes it is possible. I’ve experimented with this personally. I talk about what I’ve done here in a blog post. http://www.embeddedhobbyist.com/2015/09/beaglebone-black-working-with-debianlinux-images/

So here is the idea.

First you would want to backup the MBR liek this: $ sudo dd if=/dev/sdb of=/home/william/mbr-sdb.bak bs=1M count=1

Second You write the wanted MLO / uboot.img file into the first 512k of the MBR. As demonstrated on Roberts eewiki guide - Which I think you linked to already ?

That should leave the partition table intact. But in case it fails, you can put the whole partition table, plus original MLO, and uboot.image back on the sdcard like so.

$ sudo dd if=/home/william/mbr-sdb.bak of=/dev/sdb bs=1M count=1

OR

It would probably be safer / easier to just dd the whole block device into an image file stored in a safe place.

William_Hermans · October 8, 2015, 9:20pm

Sorry not finished and accidentally hit “send”. But if you need more information on the steps. I can test, and duplicate exact step in order for you to do the same - In a safe way.

William_Hermans · October 8, 2015, 9:30pm

Read everything below before half fast attempting such procedure

If I understand what you’re asking here, yes it is possible. I’ve experimented with this personally. I talk about what I’ve done here in a blog post. http://www.embeddedhobbyist.com/2015/09/beaglebone-black-working-with-debianlinux-images/

So here is the idea.

First you would want to backup the MBR liek this: $ sudo dd if=/dev/sdb of=/home/william/mbr-sdb.bak bs=1M count=1

Second You write the wanted MLO / uboot.img file into the first 512k of the MBR. As demonstrated on Roberts eewiki guide - Which I think you linked to already ?

Before attempting the second step here. You would need to use tar to backup the rootfs as well. Because in effect you do have to wipe out the partition table. but it can be restored.

Christopher_Stack · October 8, 2015, 9:35pm

Don’t worry I had already made a backup img so continually messing things up wasn’t really an issue. Just takes a few minutes to download the img back to the sd.

It is similar to what is on both Robert’s and your blogs, so I’m not sure why it got messed up when I tried recreating the partition table as well.

Regardless:

I skipped this step: Erase partition table/labels on microSD card and it appeared the base uboot directly from Roberts guide worked properly. Then I added the patch from here http://www.mikini.dk/index.php/category/beaglebone-black/boot-issue and repeated the procedure. On power up while holding ‘a’ on the keyboard the boot process continued as desired. So knock on wood I think I got the bootloader replaced and the new patch worked.

Thank you both for your help and Miki for the patch!

Before I’m content is there any issue from not cleaning out the MBR? Like if the img after the last patch is a different size then Robert’s img file?

Intending to run reboot tests overnight to make sure the patch clears up the issue. Although if the “random” noise on the rx line spells out stop I’m going to be a little spooked.

Thanks,

Chris

RobertCNelson · October 8, 2015, 9:41pm

The only reason i clear out the mbr in the directions, is just to help
guarantee the user doesn't run into random
complaints/warnings/annoyances in later "mkfs.ext4" tools.

and it helps make sure they have a good state of the microSD...

Regards,

William_Hermans · October 8, 2015, 10:08pm

The only reason i clear out the mbr in the directions, is just to help
guarantee the user doesn’t run into random
complaints/warnings/annoyances in later “mkfs.ext4” tools.

and it helps make sure they have a good state of the microSD…

I’d also like to add that occasionally, and potentially semi, but not completely related. Sometimes you get an error message at boot instructing the user to to run fsck. I’ve found that simply running fsck when it asks does away with this “boot complaint” afterwords. i.e. the Problem has been fixed. Usually, this only happens after one does something like re-sizing the partition using fdisk when the disk is live. It does work, but the system temporarily gets confused by the existing partition table, until after fsck is run.

Christopher_Stack · October 9, 2015, 2:06pm

That makes sense, and is definitely what you would want if you are starting from scratch.

Just figured I’d pass along that I did 1700 power cycles last night and no failures occurred!

Thanks again for the help,

Chris

xmacleod · October 27, 2015, 6:02pm

The BB uses the TPS65217 power management IC. Per the data sheet, it will not turn on if the applied power has a ramp of greater than 50 mSec.

salahgafoor · March 14, 2018, 6:59am

Hi all,

I’ve two beaglebone black revC boards with debian 7.9, kernel 3.8 and debian 9.3,kernel 4.9 respectively.

I tried to power up these two boards using VDD pins on a board having some another interfaces like LCD etc,

But, only first board is booting up(debian 7.9). For second board, only power led is glowing.

Please help me on how to debug this