Is the BBB boot button necessary?

GoogleGroups
21

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

22

[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

23

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

24

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..

Regards,

25

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

26

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

Gerald

27

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.