[U-Boot] [PATCH v2] wandboard: Add board revision detection support

Alexander Holler holler at ahsoftware.de
Tue May 26 20:55:24 CEST 2015


Am 25.05.2015 um 11:41 schrieb Wolfgang Denk:
> Dear Fabio,
>
> In message <CAOMZO5DFpUjmgF_SoRNaGtxExzBQ1-bVTFVTBnTMy40QpDwXZw at 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


More information about the U-Boot mailing list