No Boot, only 5vdc light

[Dinosaur]

Hi All

Posted this on Adafruit Forum, but have been trying to post on this Google group for some time on other issues, but I never seeem

to see my post anywhere. Hope this is better this time.

Have just received the second BBB's Rev.C from Adafruit and as I did on the first, I erased the MMCBLK1 so that it would
not boot on it and not interfere with the libpruio.
Used a good uSD and did: sudo dd if=/dev/zero bs=512 count=1024 of=/dev/mmcblk1

Once that was completed, sudo reboot.
However, the only light that was On and stayed on was the 5vdc power adapter.
Usually after a few sec's delay all 4 led's come on and the sequence starts.
Nothing, no amount of button pressing will bring it back to life.
Have of course confirmed the uSD on the other unit and all is ok.
The unit has not even had any connections other then the power.

Is this a warranty issue, how do I even go about that ?

Regards
Dinosaur

Does anyone have any suggestions (other then the garbage bin) as to how this "New" unit can be
recovered.

Dinosaur1946

 

Posts: 1

Joined: Thu Mar 28, 2019 9:32 am

Top

[Robert Nelson]

On Thu, Mar 28, 2019 at 10:25 AM Dinosaur <vande...@gmail.com> wrote:

Hi All

Posted this on Adafruit Forum, but have been trying to post on this Google group for some time on other issues, but I never seeem

to see my post anywhere. Hope this is better this time.

Have just received the second BBB's Rev.C from Adafruit and as I did on the first, I erased the MMCBLK1 so that it would
not boot on it and not interfere with the libpruio.
Used a good uSD and did: sudo dd if=/dev/zero bs=512 count=1024 of=/dev/mmcblk1

Once that was completed, sudo reboot.
However, the only light that was On and stayed on was the 5vdc power adapter.
Usually after a few sec's delay all 4 led's come on and the sequence starts.
Nothing, no amount of button pressing will bring it back to life.
Have of course confirmed the uSD on the other unit and all is ok.
The unit has not even had any connections other then the power.

Is this a warranty issue, how do I even go about that ?

Grab the latest image, thru: 

https://beagleboard.org/latest-images

use "etcher.io" to write the file to a microSD and retry..

Regards,

--

Robert Nelson
https://rcn-ee.com/

[Dinosaur]

Hi All

Many thanks for the reply.

Have already tried a current Flashing image, but there is absolutely NO disk activity.

Not even a single flash of light, only the 5vdc power stays lit.

Regards

[Dinosaur]

Worth noting that pressing the power button for 8 sec's DOES turn it off.

 

Top

[Dinosaur]

Hi All

Just to make sure, I used Etcher to put a console image on a uSD, and lo & behold it fired up.

So, I now have to find out why gui won't

When I bought the first unit, there was no mention of Element 14, just the Rev.C

When I bought the second one, the ONLY one on their site was Element 14.

Hopefully If I erase the MMCBLK1 disk, the boards should be identical.

Regards

[Dennis Lee Bieber]

On Thu, 28 Mar 2019 09:38:21 -0700 (PDT), Dinosaur
<vande...@gmail.com> declaimed the
following:

>
>Hopefully If I erase the MMCBLK1 disk, the boards should be identical.
>

I'm perplexed at your need to erase the eMMC? That is usually only
recommended when the u-Boot that is on-board is so old it can't boot new
images (often that means it is a u-Boot that expects the kernel to load the
device tree/overlays, but the Linux image has a kernel that expected u-Boot
to load the device tree/overlays).

Mine, once flashed (using the Boot switch to force SD card booting)
with a newer image have always detected if an SD card is inserted and will
boot using the SD card image (the u-Boot code is, I'm fairly certain,
coming from the eMMC, but the rest of the boot process detects the SD card
and accesses it for everything else).


--
Wulfraed Dennis Lee Bieber AF6VN
wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/

[Dinosaur]

Hi All

Thanks for the prompt responses.

The Libpruio had difficulties when booting from uSD with the MMCBLK1 in tact.

I quote the Freebasic post relating to this.

This is the problem, I guess. The kernel finds a valid drive system on eMMC and binds it as /dev/mmcblk0 in this case.
Instead it should bind the uSD as /dev/mmcblk0, and completly boot from uSD. You'll have to erase the partition table so that the kernel cannot bind this drive! I recommend

• create a uSD with an original image that boots
• boot form uSD and login as usual by debian/temppwd
• check for the 4GB eMMC with command df -h (either /dev/mmcblk0 or /dev/mmcblk1)
• then erase the first sectors on eMMC by executing (addapt the correct number [0|1])

Code: Select all

sudo dd if=/dev/zero bs=512 count=1024 of=/dev/mmcblk0 "should be mmcblk1"


Regards

[Dennis Lee Bieber]

On Thu, 28 Mar 2019 10:24:20 -0700 (PDT), Dinosaur
<vande...@gmail.com> declaimed the
following:

>Hi All
>
>Thanks for the prompt responses.
>
>The Libpruio had difficulties when booting from uSD with the MMCBLK1 in
>tact.
>I quote the Freebasic post relating to this.
>
>This is the problem, I guess. The kernel finds a valid drive system on eMMC
>> and binds it as /dev/mmcblk0 in this case.
>> Instead it should bind the uSD as /dev/mmcblk0, and completly boot from
>> uSD. You'll have to erase the partition table so that the kernel cannot
>> bind this drive! I recommend
>>

That hasn't been the situation for years as I recall... I think Wheezy
(Debian 7.x) was the last OS image that had the behavior of changing device
binding.

Booting my BBB with only the eMMC gives:

debian@beaglebone:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 220164 0 220164 0% /dev
tmpfs 49476 5292 44184 11% /run
/dev/mmcblk1p1 3704040 3036352 459816 87% /
tmpfs 247376 0 247376 0% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 247376 0 247376 0% /sys/fs/cgroup
tmpfs 49472 0 49472 0% /run/user/1000
debian@beaglebone:~$ ls -l /dev/m*
crw-r----- 1 root kmem 1, 1 Mar 25 14:13 /dev/mem
crw------- 1 root root 10, 59 Mar 25 14:13 /dev/memory_bandwidth
brw-rw---- 1 root disk 179, 0 Mar 25 14:12 /dev/mmcblk1
brw-rw---- 1 root disk 179, 8 Mar 25 14:12 /dev/mmcblk1boot0
brw-rw---- 1 root disk 179, 16 Mar 25 14:12 /dev/mmcblk1boot1
brw-rw---- 1 root disk 179, 1 Mar 25 14:13 /dev/mmcblk1p1
brw-rw---- 1 root disk 179, 24 Mar 25 14:13 /dev/mmcblk1rpmb

/dev/mapper:
total 0
crw------- 1 root root 10, 236 Nov 3 2016 control

/dev/mqueue:
total 0

eMMC is mmcblk1 device... Inserting an SD card and rebooting gives:

debian@beaglebone:~$ df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 220168 0 220168 0% /dev
tmpfs 49476 5928 43548 12% /run
/dev/mmcblk0p1 7570776 2928044 4283728 41% /
tmpfs 247376 0 247376 0% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 247376 0 247376 0% /sys/fs/cgroup
tmpfs 49472 0 49472 0% /run/user/1000
debian@beaglebone:~$ ls -l /dev/m*
crw-r----- 1 root kmem 1, 1 Mar 28 21:27 /dev/mem
crw------- 1 root root 10, 59 Mar 28 21:27 /dev/memory_bandwidth
brw-rw---- 1 root disk 179, 0 Mar 28 21:27 /dev/mmcblk0
brw-rw---- 1 root disk 179, 1 Mar 28 21:27 /dev/mmcblk0p1
brw-rw---- 1 root disk 179, 8 Mar 28 21:27 /dev/mmcblk1
brw-rw---- 1 root disk 179, 16 Mar 28 21:27 /dev/mmcblk1boot0
brw-rw---- 1 root disk 179, 24 Mar 28 21:27 /dev/mmcblk1boot1
brw-rw---- 1 root disk 179, 9 Mar 28 21:27 /dev/mmcblk1p1
brw-rw---- 1 root disk 179, 32 Mar 28 21:27 /dev/mmcblk1rpmb

/dev/mapper:
total 0
crw------- 1 root root 10, 236 Mar 28 21:26 control

/dev/mqueue:
total 0

debian@beaglebone:~$ uname -a
Linux beaglebone 4.14.49-ti-r54 #1 SMP PREEMPT Fri Jun 15 22:14:13 UTC 2018
armv7l GNU/Linux

SD card is mmcblk0, and with or without SD card, eMMC is mmcblk1. What
does change is the device number/node data... Without SD card, mmcblk1 is
179,0; with SD card mmcblk0 is 179,0 and mmcblk1 is 179,8

The u-Boot image that is used to start the boot may be coming from eMMC
{the full boot sequence is a mystery to me}, but when it detects the SD
card, it appears to transfer control to it.


Have you flashed the eMMC using one of the standard images (LXQT or
IoT) before going on to your SD image? My recommendation would be to ensure
the system works with a standard image in eMMC, then with a standard image
on SD card withOUT erasing eMMC blocks.