Am 25.05.2015 um 11:41 schrieb Wolfgang Denk:
Dear Fabio,
In message <caomzo5dfpujmgf_sornagtxexzbq1-bvtfvtbntmy40qpdw...@mail.gmail.com>
you wrote:
"If the gpio command would be enabled, it would even be possible to reset the
BRCM- WLAN and Bluetooth modules by just adding some stuff to uEnv.txt."
This sounds like a real hack for me, sorry.
Consider it as an example for being able to do many different things
that have not even been thought of at the time of implementations. to
try out things. Maybe we decide later to implement the features a C
code, but for testing or working aound problems is is always nice to
have scripting capabilities.
Exactly. It's just another example besides the possibility to choose the
correct dtb based on the board revision without modifying u-boot at all
(if gpio would be enabled). And also the example is a hack, that's the
stuff which is necessary very often, until someone fixes something in a
driver (and managed it to get the fix upstream), or even to circumvent
problems with some HW.
Btw., in regard to the above specific hack, the same problem (failure to
upload firmware because it's already uploaded) exists for Bluetooth too.
Personally I've modified (hacked) the wandboard-rfkill-driver a year ago
to disable the regulator of the brcm-module completely for some
milliseconds at startup (and when the module is unloaded, to save
power). But that involves having to manage own patches for the kernel,
so I might even prefer to use just a hack in uEnv.txt to fix the reset
problem with the brcm-module.
Besides that I don't really care what a maintainer said to some previous
similiar problem. Maintainers are humans too, maybe he just had
forgotten about the gpio-command.
Regards,
Alexander Holler
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
