Just to come back to the wifi performance issue, I found updating the
kernel to the latest 3.8 series helped a bit with stability (updated to
3.8.13-bone64 using the /opt/scripts/tools/update_kernel.sh).  I added a
really simple systemd script to automatically run 'ifdown wlan0' and 'ifup
wlan0' on boot and that helped reliability immensely.  I can now bring up
my RTL wifi card 10+ times on repeatedly on boot, which is a big
improvement and reliable enough for most needs.

Also I just got ahold of an Atheros-based wifi adapter, but I'm finding it
also has very poor reliability in 3.8.  It's an AR9271 chipset that uses
the ath9k_htc module.  It also doesn't come up reliably on boot like RTL
adapter, but luckily the systemd wlan0 restart script seems to make it work
well.  Just curious though since folks mentioned Atheros cards were much
better, is the ath9k_htc module not good with 3.8?  Or is it just a deeper
issue with the USB system in the 3.8 kernel?


On Sat, Aug 23, 2014 at 12:58 PM, Tony DiCola <t...@tonydicola.com> wrote:

> Yeah I actually had a similar thought, a web app to help tell you the
> current state of the pins and even let you change them by generating and
> loading the appropriate overlay.  Been too busy with other stuff to look at
> it yet, but maybe it would be easier to just start with something that
> builds a dts from a desired set of pin functionality instead of trying to
> build overlays and load them with the cape manager.
>
> I was actually curious, what's the best way to read the current state of
> each pin?  Would using the debugfs nodes
> at /sys/kernel/debug/pinctrl/44e10800.pinmux be the easiest way, or do you
> need to figure out the dtbs that are loaded, decompile them, parse the
> source, etc?
>
>
> On Fri, Aug 22, 2014 at 2:15 PM, Robert Nelson <robertcnel...@gmail.com>
> wrote:
>
>> On Fri, Aug 22, 2014 at 4:03 PM, Tony DiCola <t...@tonydicola.com> wrote:
>> > Thanks for the tips--I'll take a look at what you mention.  Do you
>> think the
>> > overlay manager will eventually make it to the later kernels or is it
>> best
>> > to get used to compiling and loading dtb's?
>>
>> "eventually"
>>
>> For most people, once they plug a cape/board into the bone's expansion
>> headers it stays in.  That's who i'm targeting with my v3.14.x branch.
>> Things on the backend are pretty straight forward for building a new
>> *.dtb (without re-building the kernel).
>>
>> One "dream" thing i'd like to see, to make things eaiser for new
>> users.  Some kinda nodejs/html gui to select pinmux based on
>> fuction/cape. This would call dtb-rebuilder with a custom *.dts, build
>> it and reboot..
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> http://www.rcn-ee.com/
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/IyeMT8j94mQ/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to