The first memory write is the password unprotecting, the second
disables LDO2 in the ENABLE register. Try it from the u-boot command
line. Then just put those two commands into a uEnv.txt and make sure
they get executed. The 'U-Boot# ’ part is the prompt.
Decoding the command:
i2c - i2c command set
mw - memory write
24 - i2c address of the tps65217
b or 16 - register to write to in the tps65217
6b or fe - data to write to said register
The ‘i2c help’ is useful in u-boot, too.
Tested on an A3 that’s now running with the power LED off (and all
other LEDs off too, since it’s not on Ethernet and I’m at the
u-boot prompt) with mainline u-boot 2013.01-rc1. Should also work fine
with the version of u-boot shipping with any bones.
-Andrew
I tried that on an A5A Beaglebone and it doesn’t seem to affect the power LED. I did:
Hit any key to stop autoboot: 0
U-Boot# i2c mw 24 b 6b
U-Boot# i2c mw 24 16 fe
Could it be different for A5?
Is there a similar command for disabling the ethernet LED’s even when using ethernet, or can that only be done by desoldering resistors?
> u-boot command lines to turn off LDO2 would be:
>
> U-Boot# i2c mw 24 b 6b
> U-Boot# i2c mw 24 16 fe
>
> The first memory write is the password unprotecting, the second
> disables LDO2 in the ENABLE register. Try it from the u-boot
> command line. Then just put those two commands into a uEnv.txt and
> make sure they get executed. The 'U-Boot# ' part is the prompt.
>
> Decoding the command:
> i2c - i2c command set
> mw - memory write
> 24 - i2c address of the tps65217
> b or 16 - register to write to in the tps65217
> 6b or fe - data to write to said register
>
> The 'i2c help' is useful in u-boot, too.
>
> Tested on an A3 that's now running with the power LED off (and all
> other LEDs off too, since it's not on Ethernet and I'm at the
> u-boot prompt) with mainline u-boot 2013.01-rc1. Should also work
> fine with the version of u-boot shipping with any bones.
>
> -Andrew
I tried that on an A5A Beaglebone and it doesn't seem to affect the
power LED. I did:
Hit any key to stop autoboot: 0
U-Boot# i2c mw 24 b 6b
U-Boot# i2c mw 24 16 fe
Could it be different for A5?
It should not be different for an A5 vs A3 or A6. You must do the
password unprotecting immediately before writing to the ENABLE register
or else it won't take. Please read the TPS65217 data sheet for more
information.
Is there a similar command for disabling the ethernet LED's even when
using ethernet, or can that only be done by desoldering resistors?
As stated before, no. You have to desolder resistors to make the LEDs
turn off at all times.
The first memory write is the password unprotecting, the second
disables LDO2 in the ENABLE register. Try it from the u-boot
command line. Then just put those two commands into a uEnv.txt and
make sure they get executed. The 'U-Boot# ’ part is the prompt.
Decoding the command:
i2c - i2c command set
mw - memory write
24 - i2c address of the tps65217
b or 16 - register to write to in the tps65217
6b or fe - data to write to said register
The ‘i2c help’ is useful in u-boot, too.
Tested on an A3 that’s now running with the power LED off (and all
other LEDs off too, since it’s not on Ethernet and I’m at the
u-boot prompt) with mainline u-boot 2013.01-rc1. Should also work
fine with the version of u-boot shipping with any bones.
-Andrew
I tried that on an A5A Beaglebone and it doesn’t seem to affect the
power LED. I did:
Hit any key to stop autoboot: 0
U-Boot# i2c mw 24 b 6b
U-Boot# i2c mw 24 16 fe
Could it be different for A5?
It should not be different for an A5 vs A3 or A6. You must do the
password unprotecting immediately before writing to the ENABLE register
or else it won’t take. Please read the TPS65217 data sheet for more
information.
I’ve tried it many times from the u-boot prompt with less than 1 second between the commands. I’ve also tried to execute the commands in uEnv.txt but I’m finding the extra layer of variables from am335x_evm.h difficult to work with (bootfile, loadaddr, loaduimage, mmcboot, etc). How can I break out of that and issue commands in uEnv.txt directly so that they won’t be overridden by am335x_evm.h stuff?
Fixed with an external Linear DC1562A-I [1] dev kit and an N-channel
FET. Now warm software resets are 100 ms long and the SMSC PHY likes it.
Tested on an A3 and an A6 bone. Ethernet LEDs now go the right way,
every time. No software changes needed.
I don’t believe I can “fix” this via SMSC PHY registers. It appears
that the only way to set the SMSC PHY LED operation is with the
strapping resistors. Thus, it would be nice if the SYSRESET_n would
stay asserted for > 100 usec. This seems to require a hardware change
in order to provide the minimum reset duration for the SMSC PHY.
It should be possible to extend the SYSRESET_n duration via a circuit
on a cape. If we’re successful implementing that, I’ll share.
Fixed with an external Linear DC1562A-I 1 dev kit and an N-channel
FET. Now warm software resets are 100 ms long and the SMSC PHY likes it.
Tested on an A3 and an A6 bone. Ethernet LEDs now go the right way,
every time. No software changes needed.
Circuit to perform this function will be going on our cape. Might be
worth looking into implementing a similar circuit on the next rev of
the bone.