BBB doesn't boot after inserting uSD card having linux, even after pressing the S2 button for long

GoogleGroups
1

Dear members of the BBB community,

I flashed the linux disk image (which I downloaded as .img.xz and extracted using 7zip to .img) to a microSD card of SanDisk 16GB Class 4, using Win32 Disk Imager.

After flashing the image, I got the following partitions in the uSD (which I checked using Windows 8.1 Disk Management Utility)

  1. 128 MB FAT Healthy Primary Partition
  2. 6.71 GB Linux Partition - Healthy Primary Partition
  3. 8.00 GB Unallocated

I inserted the uSD to the powered off BBB, and then after pressing the S2 button, powered the BBB using USB power from my PC.
Even after several minutes (prob. 5 mins), of holding the S2 button, the only LED glowing was PWR LED.
None of the USER LEDS were glowing.

I removed the uSD card and powered the BBB again (without holding the S2 button) and everything ran fine.

Please help me run the linux image on the BBB.

Thank you,
Viswadeep

2

On Sun, 18 Sep 2016 10:27:55 -0700 (PDT), Viswadeep Sarangi
<deepun.deep@gmail.com> declaimed the
following:

I flashed the linux disk image (which I downloaded as .img.xz and extracted

  Down-loaded from where?

After flashing the image, I got the following partitions in the uSD (which
I checked using Windows 8.1 Disk Management Utility)
1. 128 MB FAT Healthy Primary Partition
2. 6.71 GB Linux Partition - Healthy Primary Partition

  The "standard" images create a 4GB Linux partition (the size of the
eMMC should one use the image to flash the eMMC). To use the rest of an SD
card requires playing games with the partition table (somewhat scary to
"delete" the only partition on the card, before writing a new definition
using the whole card, without losing the data itself). I don't think the
current images create a FAT partition at all.

  So... How you managed to get a nearly 7GB Linux partition implies using
a "non-standard" OS image. What are the contents of the FAT partition? It's
potentially a case that the boot sequence is looking for u-Boot
initialization on that partition.

  Oh, BTW, I haven't had to use the "boot switch" since last year. Insert
SD card and restart device... Boots OS from SD card (might still be reading
u-Boot info from the eMMC but then transfers over... I admit I'm not
skilled enough with boot systems to know for sure)

3

Hi Dennis,

On Sun, 18 Sep 2016 10:27:55 -0700 (PDT), Viswadeep Sarangi
deepu...@gmail.com declaimed the
following:

I flashed the linux disk image (which I downloaded as .img.xz and extracted

Down-loaded from where?

I downloaded a kali linux image from : https://images.offensive-security.com/arm-images/kali-2.1.2-bbb.img.xz
The image itself uncompressed itself to be 6.8 GB.
Does it mean that I cannot flash the eMMC because of the large size ?

After flashing the image, I got the following partitions in the uSD (which
I checked using Windows 8.1 Disk Management Utility)

  1. 128 MB FAT Healthy Primary Partition
  2. 6.71 GB Linux Partition - Healthy Primary Partition

The “standard” images create a 4GB Linux partition (the size of the
eMMC should one use the image to flash the eMMC). To use the rest of an SD
card requires playing games with the partition table (somewhat scary to
“delete” the only partition on the card, before writing a new definition
using the whole card, without losing the data itself). I don’t think the
current images create a FAT partition at all.

So… How you managed to get a nearly 7GB Linux partition implies using
a “non-standard” OS image. What are the contents of the FAT partition? It’s
potentially a case that the boot sequence is looking for u-Boot
initialization on that partition.

The contents of the FAT partition include :

  • a “dtbs” directory, which contains a lot of .dtb files
  • uEnv.txt
  • zImage file

Oh, BTW, I haven’t had to use the “boot switch” since last year. Insert
SD card and restart device… Boots OS from SD card (might still be reading
u-Boot info from the eMMC but then transfers over… I admit I’m not
skilled enough with boot systems to know for sure)

I tried to boot the same without touching the S2 button during power up (with the uSD card inside BBB)
The BBB started with only 2 LEDs constantly lit (USR0 and USR1) and the other USER LEDs not glowing at all.

4

On Sun, 18 Sep 2016 21:19:49 -0700 (PDT), Viswadeep Sarangi
<deepun.deep@gmail.com> declaimed the
following:

I downloaded a kali linux image from :
https://images.offensive-security.com/arm-images/kali-2.1.2-bbb.img.xz
The image itself uncompressed itself to be 6.8 GB.
Does it mean that I cannot flash the eMMC because of the large size ?

  Rev. C BBB only has a 4GB eMMC (and older BBB were only 2GB). You will
not be able to fit that 6+GB image onto the eMMC. (If I understand the web
site -- the images include full kernel source code, which could be part of
why they are so large)

  That said, if it is a validly built image, it should still permit
booting from the SD card itself. (I don't have the download speed to make
it worth testing on my unit)

5

Hi Dennis,

I have given up on trying to install and run Kali Linux.
I downloaded a Ubuntu image to try and run that instead.

To my pleasant surprise, it seemed to installed perfectly : with the sweeping LED lights and the terminal codes saying that it has flashed properly to the eMMC (which is a 2 GB eMMC, and the image size is 1.7 GB)

But when I started the BBB after flashing. Only the first two LEDs flashed and stayed lit ( USR0 and USR1). But nothing else happened. It’s been like that since about 30 minutes now.
There is not HDMI output either.

Any idea what might be happening and how I can fix it ?

Thanks.

6

On Sun, 18 Sep 2016 21:19:49 -0700 (PDT), Viswadeep Sarangi
<deepun.deep@gmail.com> declaimed the
following:

  {I was running late getting to work and missed this part}

The contents of the FAT partition include :
- a "dtbs" directory, which contains a lot of .dtb files
- uEnv.txt
- zImage file

  If the card isn't booting off the SD card, you might have to examine
that uEnv.txt file for things that may be erroneous, since (as I understand
things) it defines some of the stuff used by u-Boot to get to the rest of
the OS.

7

At minimum:

$ cat /boot/uEnv.txt | grep uname
uname_r=4.4.14-ti-r34

This is needed in order to find. . . I forget off the top of my head, but
for instance, it refers to the kernel version you wish to run. So without
this set, the default 1st stage uEnv.txt file wont know where to look for
the kernel, and probably the board file device tree overlay.

This is really easy to check on a Linux system, but would require
*something* in order for Windows to read ext4 file systems.

8

Ah, and right. This value can be modified in order to reflect a known working kernel. Or “point” to a known working kernel. If you know what you’re doing . . . Which is not very simple to explain but not overly hard either. For instance:

$ ls /boot/
SOC.sh config-4.4.14-ti-r34 initrd.img-4.4.14-ti-r34 uboot
System.map-4.4.14-ti-r34 config-4.4.14-ti-rt-r34 initrd.img-4.4.14-ti-rt-r34 vmlinuz-4.4.14-ti-r34
System.map-4.4.14-ti-rt-r34 config-4.4.8-ti-r22 initrd.img-4.4.8-ti-r22 vmlinuz-4.4.14-ti-rt-r34
System.map-4.4.8-ti-r22 config-4.4.9-bone-rt-r10 initrd.img-4.4.9-bone-rt-r10 vmlinuz-4.4.8-ti-r22
System.map-4.4.9-bone-rt-r10 dtbs uEnv.txt vmlinuz-4.4.9-bone-rt-r10

and

$ ls /boot/dtbs/
4.4.14-ti-r34 4.4.14-ti-rt-r34 4.4.8-ti-r22 4.4.9-bone-rt-r10

As you can see I have the possibility to load any of these 4 kernel directory “trees” that I show listed in my last command. simply by editing the “uname_r” parameter in the /boot.uEnv.txt file.

9

On Mon, 19 Sep 2016 08:55:42 -0700 (PDT), Viswadeep Sarangi
<deepun.deep@gmail.com> declaimed the
following:

But when I started the BBB after flashing. Only the first two LEDs flashed
and stayed lit ( USR0 and USR1). But nothing else happened. It's been like

  USR1 is defined to be SD card access, and USR3 is the eMMC.

  But where in the OS those get controlled I can't say... nor if any of
the third-party OS releases don't bother installing the handlers for the
LEDs.

Any idea what might be happening and how I can fix it ?

  My first suggestion would be to revert to a 2GB compatible official
image first -- which would be this old one:
https://debian.beagleboard.org/images/BBB-eMMC-flasher-debian-7.5-2014-05-14-2gb.img.xz

  If the BBB won't run that after flashing (and removing the SD card) you
have some significant problem. Actually, I'd suggest first booting an SD
card with
https://debian.beagleboard.org/images/bone-debian-7.5-2014-05-14-2gb.img.xz
just to make sure the BBB runs with that OS, period... THEN flash the eMMC
and check that it still runs.

  IF you get the unit to run with the 2GB flasher image above... THEN try
your third party OS on the SD card in a NON-flasher mode; ensure that OS
works before flashing it to the eMMC... And make sure it does fit
(depending on how "GB" is being computed -- you may still be running over:
decimal 2GB is only binary 1.86GB).

10

As with anything else computer related. You should be mindful of where you get your OS images from. Clearly the one the OP is working with is not a standard “official” image. Since Robert has not built any using a FAT partition in quite some time. As in more than a year ago.

So in order to get better help. You should be contacting the people from where you got your image from. As no one here is likely familiar with that image. Unless the person who created it also lurks here.

11

Hi Dennis,

{That’s alright, I am just glad I am getting help from you that’s all as I have given up on the documents in the forum already}

As my BBB isn’t booting anymore, my PC isn’t able to read the contents of BBB anymore. (As usual, as soon as I power my BBB, the USR0 and USR1 get lit and stay like that forever)

Well, actually this is what is happenening, if I had to denote the lit LED as [x] and turned off LED as [], and the USR0 to USR3 LEDs as [] [] [] [] , then this is the pattern I am getting :

[] [] [] [] → [x] [] [] [] → [x] [x] [] [] → [x] [x] [x] [] → [] [] [] [] → [x] [] [] [] → [x] [x] [] [] (and it stays like this forever)

Basically the first three LEDs light up for a fraction of a second, and then everything goes blank and the first two LEDs stay lit forever.

I couldn’t find what’s wrong in the uEnv.txt of the debian image that I am trying to flash on the BBB.

I am no longer flashing or trying to boot from unofficial images.

Earlier I had flashed the following image : BBB-eMMC-flasher-ubuntu-16.04.1-console-armhf-2016-09-09-2gb.img (from https://rcn-ee.com/rootfs/2016-09-09/flasher/BBB-eMMC-flasher-ubuntu-16.04.1-console-armhf-2016-09-09-2gb.img.xz)— after which the problem of only 2 LEDs lighting started.

Right now, I have installed the following image onto my uSD card : https://debian.beagleboard.org/images/BBB-eMMC-flasher-debian-7.5-2014-05-14-2gb.img.xz — but the BBB doesn’t boot from it anymore (even after pressing the S2 button) and still shows the top 2 LEDs lit forever.

I am attaching the uEnv.txt file along with this reply just for further clarification. But as a quick reference I found this part interesting :

loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile}

and as Hermans mentioned, it might have something to do with this.

uEnv.txt (1.63 KB)

12

Hi William,

I couldn’t find anything in the uEnv.txt having uname. I am attaching the uEnv.txt file here again for reference.

The BBB currently has a flashed Ubuntu image from : https://rcn-ee.com/rootfs/2016-09-09/flasher/BBB-eMMC-flasher-ubuntu-16.04.1-console-armhf-2016-09-09-2gb.img.xz
And I am trying to flash it with a Debian image from : https://debian.beagleboard.org/images/BBB-eMMC-flasher-debian-7.5-2014-05-14-2gb.img.xz

I am not sure about the Ubuntu one, but I think the one below is definitely official, as it was mentioned on the BBB official site itself : http://beagleboard.org/latest-images

Also interesting was that of the contents of /boot you mentioned, I went into the Ext4 partition of the uSD card and into /boot and found only one directory called “uboot” with No files inside. The directory was empty.

But when I checked the FAT16 partition of the uSD, I found some of the files you mentioned, which I was supposed to find in /boot (red colored files are the ones I couldn’t find)

SOC.sh config-4.4.14-ti-r34 initrd.img-4.4.14-ti-r34 uboot
System.map-4.4.14-ti-r34 config-4.4.14-ti-rt-r34 initrd.img-4.4.14-ti-rt-r34 vmlinuz-4.4.14-ti-r34
System.map-4.4.14-ti-rt-r34 config-4.4.8-ti-r22 initrd.img-4.4.8-ti-r22 vmlinuz-4.4.14-ti-rt-r34
System.map-4.4.8-ti-r22 config-4.4.9-bone-rt-r10 initrd.img-4.4.9-bone-rt-r10 vmlinuz-4.4.8-ti-r22
System.map-4.4.9-bone-rt-r10 dtbs uEnv.txt vmlinuz-4.4.9-bone-rt-r10

I found these additional files and directories which you haven’t mentioned :
App (directory)
debug (directory)
Docs (directory)
Drivers (directory)
scripts (directory)
flash-eMMC.txt
ID.txt
initrd.img
MLO
u-boot.img
zImage

I am using Win32 Disk Imager to transfer the contents of the .img file to the SD card.
I used ‘DiskInternals Linux Reader’ to access the contents of the SD card’s Linux Partition.

Inside the ‘dtbs’ folder, I found the following :
am335x-boneblack.dtb
am335x-bone.dtb
am335x-evm.dtb
am335x-evmsk.dtb
am335x-tester.dtb
omap2420-h4.dtb
omap3-beagle.dtb
omap3-beagle-xm.dtb
omap3-evm.dtb
omap3-tobi.dtb
omap4-panda-a4.dtb
omap4-panda.dtb
omap4-panda-es.dtb
omap4-sdp.dtb
omap4-var-som.dtb
omap5-evm.dtb

I am surprised that your directory and file structure and mine are completely different.
Am I doing something wrong here ?

uEnv.txt (1.63 KB)

13

On Tue, 20 Sep 2016 02:59:09 -0700 (PDT), Viswadeep Sarangi
<deepun.deep@gmail.com> declaimed the
following:

But when I checked the FAT16 partition of the uSD, I found some of the
files you mentioned, which I was supposed to find in /boot (red
colored files are the ones I couldn't find)

SOC.sh config-4.4.14-ti-r34
initrd.img-4.4.14-ti-r34 uboot
System.map-4.4.14-ti-r34 config-4.4.14-ti-rt-r34
initrd.img-4.4.14-ti-rt-r34 vmlinuz-4.4.14-ti-r34
System.map-4.4.14-ti-rt-r34 config-4.4.8-ti-r22
initrd.img-4.4.8-ti-r22 vmlinuz-4.4.14-ti-rt-r34
System.map-4.4.8-ti-r22 config-4.4.9-bone-rt-r10
initrd.img-4.4.9-bone-rt-r10 vmlinuz-4.4.8-ti-r22
System.map-4.4.9-bone-rt-r10 dtbs uEnv.txt
vmlinuz-4.4.9-bone-rt-r10

  Most of that is having variant kernels on the device -- though only one
set should be the active set (possibly defined in uEnv.txt).

I found these additional files and directories which you haven't mentioned :
App (directory)
debug (directory)
Docs (directory)
Drivers (directory)
scripts (directory)
flash-eMMC.txt
ID.txt
initrd.img
MLO
u-boot.img
zImage

  zImage is likely that build's equivalent of vmlinuz* -- but that's all
I can say.

I am surprised that your directory and file structure and mine are
completely different.
Am I doing something wrong here ?

  Which image did you read those off (since you did mention also trying
the last 2GB Debian image, which /might/ be old enough to still be a FAT
partition startup -- as was mentioned, those haven't been part of
"official" builds for a year or so).

14

On Tue, 20 Sep 2016 02:39:50 -0700 (PDT), Viswadeep Sarangi
<deepun.deep@gmail.com> declaimed the
following:

Right now, I have installed the following image onto my uSD card :
https://debian.beagleboard.org/images/BBB-eMMC-flasher-debian-7.5-2014-05-14-2gb.img.xz
--- but the BBB doesn't boot from it anymore (even after pressing the S2
button) and still shows the top 2 LEDs lit forever.

  Try the version that does not have "flasher" in the name, just to see
if the system can boot from a plain SD card image.

  When booting a flasher image, the LEDs normally do a 0-3 fill sequence
at the start of flashing, then to some pattern that may vary with the image
before going to a solid all on at the end (Molloy's website says a
side-to-side sweep while flashing).

  You seem to be seeing the first phase of a flasher start.

  Hmm -- how are you powering the unit? A USB connection may not be
providing enough power to sustain eMMC flashing.

loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile}

  Other than the fact that I don't know where the environment variables
are defined... mmcdev, mmcpart, and fdtfile are not defined in uEnv.txt;
the first two define the flash device and partition, and the last specifies
the device tree file.

  The contents do show that it expects the kernel image to be: zImage
and initrd to be: initrd.img
so those match the directory content.

15

zImage is the old way Robert used to build kernels. As in . . .http://www.embeddedhobbyist.com/2013/07/beaglebone-black-usb-boot/ Look towards the bottom where I discuss mkimage. But anyway that post I made way back in july 2013, and it’s very outdated. It’s not how things are done any more.

But quite honestly I really do not understand the kernel images in depth, so perhaps as I’m an applications developer. Not a kernel developer. Granted with a good bit of low level software experience too . . .

16

Hi Dennis,

I finally got the Board working !!!

Right now, it’s booting from the uSD card. The OS in the eMMC is still causing problems though, but at least it’s working somehow now.
I downloaded the image : https://debian.beagleboard.org/images/bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz from https://beagleboard.org/latest-images

I am powering the BBB using the USB, but have connected the USB to a cell phone charger of 5 V - 2 Amps

I am glad that it’s working now, and I can look into the eMMC issue in detail at my convenience. I needed this to setup a Python script to run periodically every day and I can do that now.

Thanks a lot, Dennis, but at least guiding me till this point.

Sincerely,
Viswadeep

17

Hi William,

I finally got the Board working !!!

Right now, it’s booting from the uSD card. The OS in the eMMC is still causing problems though, but at least it’s working somehow now.
I downloaded the image : https://debian.beagleboard.org/images/bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz from https://beagleboard.org/latest-images

You were right about the zImage issue. Makes sense now, now that I downloaded the 2016 edition of the image. I realized that I had the 2013 version of the image earlier.

Thanks a lot, William for helping me come to this point at least.

Sincerely,
Viswadeep

18

On Wed, 21 Sep 2016 08:18:56 -0700 (PDT), Viswadeep Sarangi
<deepun.deep@gmail.com> declaimed the
following:

I downloaded the image
: https://debian.beagleboard.org/images/bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img.xz
from https://beagleboard.org/latest-images

  Just take note that, if your BBB is a 2GB model, you CAN NOT FLASH THIS
IMAGE -- that's why I had specified the older 2GB images for testing.

19

You’re right. My BBB is a 2 GB eMMC model. And I know I have to boot from the SD card, at least for the time being.
I did try your suggestion and tried older debain images anf flashed it to the eMMC, but it didn’t work so I am okay with booting from the SD card, I think I’ll buy a smaller sized SD card for this (about 4 GB) and use my 16 GB SD card for some other purpose.

Thank you.

SIncerely,
Viswadeep