USR0 and USR1 leds.

GoogleGroups
1

Hi,

I got the rev C4 board from special computing.
The USR0 and USR1 leds are always on.

So looks like the uboot is seeing that the userbutton is always pressed.

Multiple things can be bad here

  1. user button itself. – may be the it is a bad part. I plan to remove it and check
  2. bad trace… or bad solder somewhere.

How can I correct this? Any tips…

Worst case, where can I send for RMA?

Thanks
Arun

2

Does the board boot?

If the user switch is on then this should change the way the system
boots. You can watch the pre-U-boot output on serial and compare with
expected behaviour with/without the user switch on.

3

if I use the latest u-boot.bin from angstrom/demo there is a message in u-boot that “User button is pressed” and I never hold or press this button.

2010/6/20 Richard Andrews <bflatmaj7th@gmail.com>

4

Board does boot. it reads boot code from MMC and boots.
The problem is not about board booting, the problem is this user button always pressed.

I want to know if it is hardware problem or something to do with software.

Maxim,

  1. Is the USR0 and USR1 Leds always on?
  2. Changing to old u-boot, will it make it go away?

You are seeing same problem as I am seeing.

-Arun

5

Arun,

my board boots fine either. If I change to old u-boot then you don’t have this message at all because of its absence in old u-boot. About leds - I don’t remember about them and don’t have a board now check, but I remember very well about button message

2010/6/20 arun kalmanje <akalmanje@gmail.com>

6

Hey guys!

I’m a little annoyed to see always in u-boot:

The user button is currently pressed.
reading user.scr

** Unable to read “user.scr” from mmc 1:1 **
reading uImage

3176260 bytes read
reading ramdisk.gz

** Unable to read “ramdisk.gz” from mmc 1:1 **
So I decided to find the reason. I can see in u-boot sources “common/cmd_boot.c” the following lines:

int do_userbutton (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])

{
…

omap_request_gpio(4);
omap_set_gpio_direction(4, 1);
printf("The user button is currently ");
if(omap_get_gpio_datain(4))
{
button = 1;
}

…
Can you notice anything strange? I can see that the requested GPIO is 4! If you look at Beagleboard schematic - GPIO_4 is always pulled-up because it is one of BOOT-pins.
The user button is connected to GPIO_7.

I’ve changed the code (4 to 7) and tested it - works well. But I don’t understand why does not the button does not change the whole behavior of the booting?

regards,
Max

2010/6/21 Maxim Podbereznyy <lisarden@gmail.com>

7

What board and UBoot are you working with? The -xM board has the button in a different spot than the Rev C4, but it is low when pushed, not High. On the -xM the button does not change the boot order because there is no NAND to boot from, only MMC. I am not sure, but could you have a UBoot that has some of the new -xM capable UBoot code in it? If it does an it is looking for a high to indicate button is pushed, then we have an issue. If it is looking for the button to be pushed on a rev C4, then we have even more issues to deal with in the SW.

Gerald

8

Gerald,

I have C3 and uboot from OE-dev tree.

2010/6/25 Gerald Coley <gerald@beagleboard.org>

9

I see. Well, this seems to be using the new UBoot code that is designed to support the -xM as well as the other revisions of the board. In my humble opinion, it is not working properly on a Rev C3 board. It sounds like it is looking for the switch in the wrong place.

Gerald

10

FWIW, they questionable patches are gone now:

http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=371343e2ccc38648bbcc35599b48d12e98d3a7cc