Help or suggestions for getting debugging-friendly ath9k_htc devices or evaluation-type boards

[Oleksij Rempel]

Hi John,

glad to see someone is still hacking on this. Sadly, these chip variants 
are End Of Life, and as far as I know there’s no active production 
anymore. Some adapters can still be found, but most vendors already 
marked them as EOL.

I also can’t spend more time on this project. Some years ago I tried to 
collect as much info as possible for the wikidevi page:
https://wikidevi.wi-cat.ru/Atheros_AR9271 
<https://wikidevi.wi-cat.ru/Atheros_AR9271?utm_source=chatgpt.com>

I even looked into upstream GCC support and related work, but in the end 
I gave up due to lack of time and interest from others.

For easy UART (and maybe JTAG) hacking I can recommend the AWUS036NHA or 
clones with a similar form factor.

I see you’re working on keeping the firmware package for Debian - thank 
you for your work on that!

Best regards,
Oleksij

Am 30.08.25 um 21:50 schrieb John Scott:
> Hi,
> To help make improvements and tinker with, I'm looking for any AR9271, AR7010, or (not ath9k_htc) AR9170 hardware that might have the JTAG, UART, (ABC, XYZ...) and other bells and whistles broken out or at least relatively accessible. I have a lot of ideas in my imagination I'd like to explore and using them for continuous integration would be really cool. I'm in the Midwest United States if that matters.
> I have a couple gizmos with the UART pins broken out into contacts but they are so tiny that soldering by hand isn't going very well with my fat fingers and shaky hands. I can't invest in more serious tools or equipment right now but maybe someday.
>
> My rookie electronics knowledge means I don't really understand how the firmware works but anyway here are some things I might try to do around it and send merge requests as appropriate:
> • Autotools has a (probably not too well-known?) feature called CONFIG_SITE. The idea is if you're building a bunch of software for a system, you can set common configuration parameters in a "config.site" file such as the installation prefix as well as options that should apply only to those applications that care about them. This would make it a lot easier for downstreams to build Binutils and GCC as appropriate with the Xtensa configuration. The xtensa-config.h header and other patching that might need to be done can probably go into the same file as I think the file pointed to is treated as an executable shell script (that might be just an implementation detail however). This would allow us to completely mitigate the need to point users at particular Binutils/GCC versions for example.
> • If I recall correctly, the ath9k_htc firmware doesn't use really any functionality from the ISO C standard library—I guess this is where the Xtensa HAL picks up the slack—so we don't build one. (carl9170, on the other hand, uses Newlib.) If we are still passing a bunch of options to GCC's configure like '--disable-libssp', that's a fragile denylist approach that doesn't scale nicely to new GCC releases or other Sourceware software like GDB or Newlib being in the combined tree. It's correct that we can't build libssp, since that is "stack-smashing protection" around the standard string functions we don't have. However GCC provides special makefile targets for such tasks as "build me an early-stage C compiler with the minimal target libraries (e.g. libgcc) so I can at least build a program with an empty main() function."
> • I haven't played with it yet or seen if it's been merged, but Espressif has proposed a "dynconfig" system for the Binutils/GCC Xtensa target to specify what kinds of instructions are supported for a system and how. This sounds cool, but since Xtensa is kind of esoteric anyway I don't think this offers a whole lot of convenience. It's not a priority but I'll see if that might be useful.
> • Some stuff belongs "behind the curtain" from the firmware's point of view because it has more to do with building any application at all for the platforms rather than the free firmware in particular. I'm mainly thinking of linker scripts or other fixups done to the binaries. It would be nice to permit GCC to have a default notion of how memory should be laid out without passing these parameters explicitly for every file to be built (this will remove a barrier to running GCC's test suite on emulated or even real hardware, more in the next point). GCC plugins and tweaking of "specs files" are other tools that could help make this clean.
> • I'm interested in emulating the hardware at least well enough to see some console messages and assert that the compiler probably isn't super broken. It helps that the boot ROM source is also in Git. Even if QEMU doesn't meet our needs well or support specifying the TIE customized instructions, there is another option that can be a lot easier: GDB's simulator, which I do believe has an Xtensa target. I believe it ought to be able to take our 'xtensa-config.h' info just the same as Binutils and GCC do. GDB simulators provide runtime options for adjusting memory layout, adding peripheral devices, and a lot of neat voodoo. It is also possible to use the simulator to run GCC's test suite as a way to test the binaries produced by GCC without real hardware.
> 	◦ Of course, building GDB with the needed parameters could allow it to debug the hardware using its JTAG or JTAG-like interface with something like OpenOCD serving as the GDB server. It would probably need Newlib, but maybe gdbserver can be made to run on the Xtensa device itself and communicate over the UART. That'd be magic.
>
> I am glad that ath9k_htc has given me motivation to go deeper than software and seek to understand electronics over the past few years.
>
> _______________________________________________
> ath9k_htc_fw mailing list
> ath9k_htc_fw at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath9k_htc_fw