Is the BBB boot button necessary?

[Carl Johnson]

I built the latest Angstrom 3.8.10 kernel and put the distribution on an SD card.  When I put it into a brand new BBB, it boots from this card even if I don't press the boot button.  If I remove the card and reapply power it boots from the eMMC.  This is the behavior I would expect and prefer, quite frankly.  Is the SRM documentation wrong about the use of the boot button or am I missing something?

[Gerald Coley]

SRM is correct. This is not normal unless you have changed uneven.txt file,

Gerald

On Tuesday, April 30, 2013, Carl Johnson wrote:

I built the latest Angstrom 3.8.10 kernel and put the distribution on an SD card.  When I put it into a brand new BBB, it boots from this card even if I don't press the boot button.  If I remove the card and reapply power it boots from the eMMC.  This is the behavior I would expect and prefer, quite frankly.  Is the SRM documentation wrong about the use of the boot button or am I missing something?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Gerald

 

ger...@beagleboard.org

g-co...@ti.com

http://beagleboard.org/

http://circuitco.com/support/

[Carl Johnson]

Thanks for the quick response.  I ordered the commercial version of the board from special computing - perhaps that's why my behavior is different?  I haven't edited any files - this is the out-of-box behavior.  Where is the uneven.txt file?  I don't see it in the eMMC boot partition or in /boot of the rootfs partition, and can't find any reference to it in the SRM.

[Gerald Coley]

Oh? OK then you need to go back to Bill on this. I have no idea what he is doing,

Gerald

On Tuesday, April 30, 2013, Carl Johnson wrote:

Thanks for the quick response.  I ordered the commercial version of the board from special computing - perhaps that's why my behavior is different?  I haven't edited any files - this is the out-of-box behavior.  Where is the uneven.txt file?  I don't see it in the eMMC boot partition or in /boot of the rootfs partition, and can't find any reference to it in the SRM.

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Carl Johnson]

Thanks Gerald!  FWIW, I really prefer this behavior.

[Richard Krehbiel]

Could you possibly find and post this "uneven.txt" file?  I'd like to know how it was done so I can make my boards do it too - boot SD if there is one, else boot eMMC.

[Gerald Coley]

Jason,

Would you like to jump in on this one?

Gerald

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jason Kridner]

The boot behavior is:

1) If the button is not pressed, eMMC is tried ahead of uSD, where the
u-boot "MLO" program is found. If the BOOT button is pressed, the uSD
card would be tried. The hardware documentation in this regard is
correct.
2) I believe, and I need to confirm here though I'm pretty certain,
that MLO loaded from eMMC will always load the u-boot u-boot.img from
the same location, ie. eMMC.
3) u-boot.img has a default boot script, where the uSD card is
scanned! This is why you are seeing "boot" from the uSD card, even
though you haven't pressed the BOOT button. What is scanned for is
the file uEnv.txt (case-insensitive, I believe) on the first FAT
partition. You can use this to override the environment variables used
by u-boot and continue to boot off of eMMC (by setting mmcdev
properly), or use it to load Linux off of the uSD. The uEnv.txt file
you have seems to be encouraging u-boot to load the Linux kernel from
your uSD and mount your uSD card as the root file system device.

k, guys that know better, your turn to jump in and help refine this answer.

[Gerald Coley]

Well, I understood that.

Gerald

[Carl Johnson]

Thanks for that explanation, Jason!  My eMMC uEnv.txt file only contains this line:

optargs=quiet

I'll check to see if my u-boot.img is different from the one contained in the eMMC flasher.

[SKiAt]

Hi Jason I think it is like you mentioned.

there is a second issue related to this, if you try to put an SD into the slot to be used as "additional storage" u-boot will find the card inserted and tries to boot from it.. so it fails and the board doesn't boot!

Have you guys any idea if this can be avoided changing the default boot command of using a udevcmd? 

bye 

[Drew Moore]

On Tuesday, April 30, 2013 11:06:12 AM UTC-4, Richard Krehbiel wrote:

Could you possibly find and post this "uneven.txt" file?  I'd like to know how it was done so I can make my boards do it too - boot SD if there is one, else boot eMMC.

Ah.. "uneven.txt" is actually "uEnv.txt".. must be Gerald's spellchecker having fun with us.

[Gerald Coley]

Isn't mine! It belongs to Google!

Gerald

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Eric Brundick]

Ah, just saw this thread, I'm seeing the same thing... Inserted a uSD card from an old Blackberry I had, and it refuses to boot indicating that it can't read uEnv.txt from that file.

Considering the BBBlack also doesn't seem to autoscan or autodetect the uSD when I insert it after it's fully booted from the eMMC, this renders the uSD slot completely useless.  Is there a way to change the default boot script?

[Eric Brundick]

Nevermind, sounds like I need to add a uEnv.txt file to this SD card and make it set the mmcdev to 1.  Not really my preferred way to go... if I want the bootloader to have any interaction with the uSD card I'd prefer to hold S2!  Makes it confusing to get a brand new uSD card going particularly since I don't have any SD-to-uSD adapters hanging around here...

On Tuesday, April 30, 2013 10:37:17 AM UTC-4, Carl Johnson wrote:

[Gerald Coley]

Noted. Hopefully the SW people are listening.

Gerald

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Eric Brundick]

Ok I ended up using my Android phone as a uSD card reader with the USB link to a Windows PC...

Created a uEnv.txt with:

mmcdev=1

bootpart=1:2

mmcroot=/dev/mmcblk1p2 ro

It seemed to have an issue with CR+LF's in Windows so I had to dos2unix the file before it would boot properly.  But it's booting now, and the computer attached the BeagleBone (Macbook Pro) now sees the uSD card instead of the eMMC's BEAGLEBONE volume.

On Tuesday, April 30, 2013 10:37:17 AM UTC-4, Carl Johnson wrote:

[William A. Mills]

I have been playing with this last night.  I got 2 BBB from digi-key last night.

I agree with SKiAt that any card in the uSD slot prevents it from booting kernel from eMMC.

To my way of thinking uboot should check for uEnv.txt and if found assume that uSD should be used for kernel and rootfs.

HOWEVER, if uEnv.txt is not found on uSD, then it should boot kernel and rootfs from eMMC and assume uSD is just extra storage.

However, I don't know if this is going to help currently. 
W/o a blank uSD card at boot the system boots with eMMC on /dev/mmcblk0 even though physically it is on MMC1.

If you plug a uSD card in while it is running, no new /dev/mmcblk* devices show up.

Is the kernel only mapping one or the other MMCx interface? 
How would the eMMC update uSD image work then?

I am trying to download the eMMC update image but am currently looking at a 5 hour download time.  I guess everyone got their BBB's last night.

Bill

[William A. Mills]

Still confused.  I looked at Robert's eMMC update for Ubuntu.[1]
It definitly expects eMMC to be on /dev/mmcblk1

https://github.com/RobertCNelson/tools/blob/master/scripts/beaglebone-black-sync-nand.sh

[Robert Nelson]

On Wed, May 1, 2013 at 10:09 AM, William A. Mills <wm.a....@gmail.com> wrote:
> Still confused. I looked at Robert's eMMC update for Ubuntu.[1]
> It definitly expects eMMC to be on /dev/mmcblk1
>
> https://github.com/RobertCNelson/tools/blob/master/scripts/beaglebone-black-sync-nand.sh

It's a kernel feature: ;)

with no microSD card:
eMMC is /dev/mmcblk0

with microSD card:
microSD : /dev/mmcblk0
eMMC: /dev/mmcblk1

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[William A. Mills]

Thanks Robert.

I answered another key question myself.  The Boot button must be held at POWER CYCLE.  It is not enough to hold the boot button while pressing the reset button.

To quote the chip manual:
"SYSBOOT[15:0] terminals are respectively LCD_DATA[15:0] inputs, latched on the rising edge of PWRONRSTn."

This signal is on ball B15 in the datasheet and labelled PORZn w/ net PMIC_PGOOD in the BBB schematics.

The reset button generates a low on ball A10, datasheet signal WARMRSTn, labelled NRESET_INOUT and net SYS_RESETn in the BBB schematics.

(I don't remember having to do this on the original beagleboard.   I have to go back and check now.)

I have verified this this way:

* power via 5V barrel

* nothing in uSD slot

* FTDI cable attached to 6 pin header

* no other connections (esecially no uUSB)

Hold BOOT button while connecting 5V, get CCCCC XMODEM download attempt on UART

Don't hold BOOT button connecting 5V, boot from eMMC

So to summerize the current state w/ stoc

[William A. Mills]

[Sent to soon. Don't like web based e-mail clients]

Thanks Robert.

I answered another key question myself.  The Boot button must be held at POWER CYCLE.  It is not enough to hold the boot button while pressing the reset button.

To quote the chip manual:
"SYSBOOT[15:0] terminals are respectively LCD_DATA[15:0] inputs, latched on the rising edge of PWRONRSTn."

This signal is on ball B15 in the datasheet and labelled PORZn w/ net PMIC_PGOOD in the BBB schematics.

The reset button generates a low on ball A10, datasheet signal WARMRSTn, labelled NRESET_INOUT and net SYS_RESETn in the BBB schematics.

(I don't remember having to do this on the original beagleboard.   I have to go back and check now.)

I have verified this this way:

* power via 5V barrel

* nothing in uSD slot

* FTDI cable attached to 6 pin header

* no other connections (esecially no uUSB)

Hold BOOT button while connecting 5V, get CCCCC XMODEM download attempt on UART

Don't hold BOOT button connecting 5V, boot from eMMC

       w/o powering off now hold Boot button while hit & release of Reset button, continue to boot from eMMC.

Note that U-boots use of the BOOT pin is not bound to this restriction as it samples the pin directly via GPIO.

This also means that you need to hold it until u-boot is done looking for it.

If your driving this pin from the outside world you will not be able to make the drive conditional based on SYS_RESETn as suggested in the BBB SRM. 
Instead the drive will need to be shut off after a fix time or from some signal from the BBB under SW control like a GPIO.

So to summarize the current state w/ stock u-boot and u-boot env

   If you have uSD populated at boot, you must boot kernel and rootfs from it

   If you don't have uSD populated at boot, adding it later does not get you access to it.

On We

[Gerald Coley]

That is correct. SYSBOOT pins are only sampled on power on reset, not warm reset. It is the same as the original BeagleBoard. Same processor and same design.

Gerald

[Robert Nelson]

On another board i patched uboot with:

+ "mmc dev 0; if mmc rescan ; then " \
+ "setenv mmcdev 0; " \
+ "echo SD/MMC found on device ${mmcdev}; " \
+ "if run loadbootenv; then " \
+ "run importbootenv; " \
+ "fi; " \
+ "if test -n $uenvcmd; then " \
+ "echo Running uenvcmd ...; " \
+ "run uenvcmd;" \
+ "fi; " \
+ "fi;" \
+ "mmc dev 1; if mmc rescan ; then " \
+ "setenv mmcdev 1; " \
+ "echo SD/MMC found on device ${mmcdev}; " \
+ "if run loadbootenv; then " \
+ "run importbootenv; " \
+ "fi; " \
+ "if test -n $uenvcmd; then " \
+ "echo Running uenvcmd ...; " \
+ "run uenvcmd; " \
+ "fi; " \
+ "fi"

Where only "uEnv.txt" touches uenvcmd, so that if card 0 doesn't have
the "uEnv.txt" it moves on to the 2nd mmc card..

[William A. Mills]

Gerald,

Can I suggest that you state this explicitly in the SRM in the areas that talk about the boot button?
"Processor power-up" is more explicit that "boot". 
To a software guy the reset button sure looks like a "boot" to me.

Bill

[Gerald Coley]

Sure! I will add a paragraph in the next version.

Gerald

[jorge.b...@batsac.com]

Hi Eric,

I've tried creating a uEnv.txt with the same contents as you posted in the micro SD, I've been able to make it boot from the SD an was able to see the volume of the SD on my windows PC. However when I SSH it I am interacting with the OS from the eMMC (I know this because I set two different static IPs on each OS: the one on the SD and the one on the eMMC). So I'm really confused at to what could be happening, do you have any idea? Thanks a lot in advance.

Jorge.