> If any people more familiar with ARM are reading this - does the value
> 0x5b35da40 ring a bell?
It could be anything. It depends on the chip implementation. For instance on an
exynos that is an undefined region. What device are we talking about?
Bruce
___
No. I've been online for ahtc_9271 hour or so and everything
seems to be fine. I downloaded a 329Mbyte file and a
169Mbyte file, got on IRC talked for a While and so on.
As for firmware I am using a personal tree but all of
changes over the last 8 months always ended with a
cmp htc_9271 ht
: not so bad
4828 of misc which is very unusual
These numbers are coming from /proc/net/wireless
Bruce
On 8/31/16, Oleksij Rempel wrote:
> Am 31.08.2016 um 05:52 schrieb bruce m beach:
>>> I'm starting to get concerned that it will never get fixed, especially
>>> sin
> I'm starting to get concerned that it will never get fixed, especially since
> I can't seem to convince anybody that it's real or that it's a problem. I've
> got wireshark installed and I can watch the signal gum up quickly with
> malformed packages, dup awks, spurious retransmissions, and termin
Hello
Just mention that I'm using kernel 4.2.2, a 35 ft usb cable going
up a 20 ft pole
into a parabolic trough, through a forest, across a river and through another
forest to my access point about a mile away and normally get about 1.2 mbits/s
The only problem I have is the USB overheats
>> I'm looking for some kind of simple request in the ath9k_htc driver, through
>> the usb ep0, like a memory read on the card, where a urb is sent with
>> the resulting chain of events. The simpler the better. The simplest.
> For EP0 on drivers site:
> static int ath9k_hif_usb_download_fw(struct
Hello All
I am still working on cleaning up ath9k_htc firmware build tree for about 6
months now ( and looks like I'll be doing this for all eternity**2 ) and am
not clear myself what I'm looking for right now.
I'm looking for some kind of simple request in the ath9k_htc driver, through
the usb
