Bug#1059414: open-ath9k-htc-firmware: diff for NMU version 1.4.0-108-gd856466+dfsg1-1.5
Hi Chris, I'm developer, not the package maintainer. On the source code side didn't happened anything for some years, so there are no conflicts are expected. From my perspective there is no need to wait. Regards, Oleksij
Bug#1050682: WiFi stopped working
Hi Daniel, Am 28.08.23 um 04:53 schrieb Daniel: Package: firmware-ath9k-htc Version: 1.4.0-108-gd856466+dfsg1-1.4 In a recent upgrade, firmware-ath9k-htc has been installed and firmware-atheros has been removed, after a system reboot my WiFi stopped working. To fix it I had to download and reinstall firmware-atheros. lspci shows Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter (rev 31) I'm using Linux debian 6.4.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.11-1 (2023-08-17) x86_64 GNU/Linux firmware-ath9k-htc do not supports QCA9377, it supports only ar9271 and ar7010. If firmware-ath9k-htc and firmware-atheros are conflicting packages it should be fixed. -- Regards, Oleksij
Bug#1038684: firmware-ath9k-htc: TP-Link TL-WN722N is not reported by "iw dev".
Am 03.07.23 um 02:21 schrieb pe...@easthope.ca: [43926.807143] usb 1-2: ath9k_htc: Firmware ath9k_htc/htc_9271-1.dev.0.fw requested This is the firmware name provided by firmware-ath9k-htc package. [43927.619075] ath9k_htc 1-2:1.0 wlxe894f6248352: renamed from wlan0 This line shows that devices was successfully registered and renamed to wlxe894f6248352 by udev. Is it the kernel log of good/working case? -- Regards, Oleksij
Bug#951891: open-ath9k-htc-firmware FTBFS with binutils 2.34
Hi John, Am 18.04.20 um 18:39 schrieb John Scott: >> thank you! >> >> I updated the package. > > Hi, > > I see you've fixed this upstream. firmware-ath9k-htc has been removed from > Bullseye, could you use some help with a new Debian package? Yes, I need help. I already overloaded this months, but it will be even worse in a in few months. I'll be thankful if some one can take over this task. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
Bug#951891: open-ath9k-htc-firmware FTBFS with binutils 2.34
Hi Adrian, thank you! I updated the package. Am 22.02.20 um 19:10 schrieb Adrian Bunk: > Source: open-ath9k-htc-firmware > Version: 1.4.0-97-g75b3e59+dfsg-3 > Severity: serious > Tags: ftbfs bullseye sid > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/open-ath9k-htc-firmware.html > > ... >debian/rules override_dh_auto_configure > make[1]: Entering directory > '/build/1st/open-ath9k-htc-firmware-1.4.0-97-g75b3e59+dfsg' > mkdir -p > /build/1st/open-ath9k-htc-firmware-1.4.0-97-g75b3e59+dfsg/cross-toolchain/binutils-source > cd > /build/1st/open-ath9k-htc-firmware-1.4.0-97-g75b3e59+dfsg/cross-toolchain/binutils-source > && \ > tar --strip-components=1 -xf /usr/src/binutils/binutils-*.tar.* && \ > patch -p1 < > /build/1st/open-ath9k-htc-firmware-1.4.0-97-g75b3e59+dfsg/local/patches/binutils.patch > patching file bfd/xtensa-modules.c > Hunk #9 FAILED at 211. > Hunk #10 FAILED at 220. > Hunk #11 FAILED at 236. > Hunk #12 FAILED at 252. > Hunk #13 succeeded at 20606 (offset -139 lines). > Hunk #14 succeeded at 20672 with fuzz 2 (offset -118 lines). > Hunk #15 FAILED at 20799. > Hunk #16 FAILED at 20894. > Hunk #17 FAILED at 20988. > Hunk #18 FAILED at 21011. > Hunk #19 FAILED at 21033. > Hunk #20 succeeded at 20692 (offset -396 lines). > Hunk #21 succeeded at 20702 (offset -396 lines). > Hunk #22 succeeded at 20722 (offset -396 lines). > Hunk #23 succeeded at 20756 (offset -396 lines). > Hunk #24 succeeded at 20771 (offset -396 lines). > 9 out of 24 hunks FAILED -- saving rejects to file bfd/xtensa-modules.c.rej > patching file include/xtensa-config.h > Hunk #1 succeeded at 43 (offset -1 lines). > Hunk #2 succeeded at 55 (offset -1 lines). > Hunk #3 succeeded at 99 (offset -1 lines). > Hunk #4 succeeded at 113 (offset -1 lines). > Hunk #5 succeeded at 151 (offset -1 lines). > make[1]: *** [debian/cross-toolchain.mk:42: > /build/1st/open-ath9k-htc-firmware-1.4.0-97-g75b3e59+dfsg/cross-toolchain/stamp-binutils_unpack] > Error 1 >
Bug#895696: firmware-ath9k-htc: workaround info. added on the wiki page
Hi Awalis, Am 05.12.19 um 20:01 schrieb awalis: > Package: firmware-ath9k-htc > Version: 1.4.0-97-g75b3e59+dfsg-3 > Followup-For: Bug #895696 > > Dear Maintainer, > > Done, the workaround was added into the wiki page. Please find the link below. > > https://wiki.debian.org/ath9k_htc/open_firmware#Fix_the_.22Scan_but_not_Connect.22_issue_.28NetworkManager.29 Great work! Thank you! > Regards, > Awalis. > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores) > Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > -- no debconf information -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
Bug#895696: Bullseye: firmware-ath9k-htc: does not work with network-manager wifi.scan-rand-mac-address
yes, it is. please add needed information to the wiki. -- Regards, Oleksij
Bug#931526: firmware-ath9k-htc: Same as bug #891060, Atheros AR9271 ath9k_htc USB WiFi connected but IP traffic stops
Hi, please, make sure it is not this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895696 In any case, there was no change in firmware-ath9k-htc. So, if there is any issue, it is most probably kernel and not firmware. -- Regards, Oleksij
Bug#664257: Fwd: Bug#917546: binutils-xtensa-lx106 is a wrong name
Hi all, it is at least second time as we needed to have a discussion about tool-chains for Xtensa based devices (for firmware-ath9k-htc and for esp8266). With the time we will get probably more discussions for similar platforms. Since there is no official or documented statement or naming schema for debian, it will be good if we can start to work in the right direction. The problematic of this platform can be described as follow: "The Xtensa processor architecture is a configurable and extensible synthesizable 32-bit RISC processor core. SoC and processor designers can select from a variety of options, such as instruction-set extensions (for example, narrow instructions, floating point instructions, etc.), memory, cache, and interrupt configurations. Moreover, Xtensa processors also support custom-defined instructions and registers. Nevertheless, all Xtensa processors share a common base instruction set architecture, thereby ensuring compatibility of third party application software and development tools." See http://wiki.linux-xtensa.org/index.php/Supported_Processors As you can see, there are number of devices or configuration able to run linux on Xtensa: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/xtensa/configs?h=v4.20 It means, this discussion related not only to bare-metal configurations. So far, binutils and GCC do not support a usual way to dynamically configure for some specific platform. Usually "configuration" is distributed as set of patches against binutils and gcc with related project. It means, there is no way to provide a tool-chain which is able to cover all configurations. There is a project to provide a way to use architecture related configurations as a plugin against binutils or gcc: https://github.com/jcmvbkbc/xtensa-dynconfig Even if we will move to xtensa-dynconfig, we should use normalized names for plugins. By analyzing different xtensa toolchain patches I made following assumptions: - all Xtensa architectures designed as customizable, but not all vendors customize it. - code build for some base version of Xtensa, will always run on the custom version of this architecture but not other way around. Based on this assumptions and experience with MIPS names I would suggest following naming schema: arch_main_name - usually xtensa arch_variant - for example lx2, or 106micro vendor_customization - it is hard to get any description from vendor, so i would suggest to use one of chip names used with this customization. In case of Atheros devices, we have same CPU variant for ar9271 and ar7010, may be other controller use same variant as well. Since ar9271 is more popular, using this chipname should be enough. Atheros ar9271 is using Xtensa LX2.1.0, so the name would probably be: xtensa-lx2.1.0-ar9271 or xtensalx2.1.0ar9271 esp8266 seems to use Xtensa Diamond 106Micro, so the name would be: xtensa-d106micro-esp8266 or xtensad106microesp8266 As reference I redirect initial discussion for binutils-xtensa-lx106. Weitergeleitete Nachricht Betreff: Re: Bug#917546: binutils-xtensa-lx106 is a wrong name Datum: Sat, 29 Dec 2018 21:38:46 +0100 Von: Oleksij Rempel An: 917...@bugs.debian.org Am 29.12.18 um 19:37 schrieb Jonathan McDowell: > On Sat, Dec 29, 2018 at 07:26:12PM +0100, Oleksij Rempel wrote: >> Am 29.12.18 um 19:11 schrieb Jonathan McDowell: >>> On Sat, Dec 29, 2018 at 05:41:47PM +0100, Oleksij Rempel wrote: >>>> If it is plain Xtensa Diamond 106Micro, then it should have proper >>>> naming. If there are some differences, it is better to know about it. >>>> Seeking for Xtensa lx106 provides no usable result to get idea about >>>> this architecture. >>> >>> I don't think we're going to come to agreement here. I've chosen the >>> package naming that matches current usage. lx106 seems to be used >>> extensively in the ESP8266 and not elsewhere, so if your concerns about >>> variations are correct then that isn't stomping on a 106micro package >>> option, or a different variation for the other 106Micro variants. >> >> A assume this kind of disagreement can be solve only by official >> distribution regulations/conventions: >> https://wiki.debian.org/Multiarch/Tuples >> https://wiki.debian.org/CoinstallableToolchains > > Those pages talk about triples for Debian multiarch compilers; we're > talking about an embedded platform compiler here. > >> We are missing only architecture name. From my understanding lx106 is >> just some name. It is not architecture name. Please provide >> documentation if I'm wrong. > > As I have stated several times this toolchain is named after the > standard toolchain for the platform. It does not appear to conflict with > any other usage of the prefix. As such I'm not going to rename things;
Bug#917546: binutils-xtensa-lx106 is a wrong name
Am 29.12.18 um 19:37 schrieb Jonathan McDowell: > On Sat, Dec 29, 2018 at 07:26:12PM +0100, Oleksij Rempel wrote: >> Am 29.12.18 um 19:11 schrieb Jonathan McDowell: >>> On Sat, Dec 29, 2018 at 05:41:47PM +0100, Oleksij Rempel wrote: >>>> If it is plain Xtensa Diamond 106Micro, then it should have proper >>>> naming. If there are some differences, it is better to know about it. >>>> Seeking for Xtensa lx106 provides no usable result to get idea about >>>> this architecture. >>> >>> I don't think we're going to come to agreement here. I've chosen the >>> package naming that matches current usage. lx106 seems to be used >>> extensively in the ESP8266 and not elsewhere, so if your concerns about >>> variations are correct then that isn't stomping on a 106micro package >>> option, or a different variation for the other 106Micro variants. >> >> A assume this kind of disagreement can be solve only by official >> distribution regulations/conventions: >> https://wiki.debian.org/Multiarch/Tuples >> https://wiki.debian.org/CoinstallableToolchains > > Those pages talk about triples for Debian multiarch compilers; we're > talking about an embedded platform compiler here. > >> We are missing only architecture name. From my understanding lx106 is >> just some name. It is not architecture name. Please provide >> documentation if I'm wrong. > > As I have stated several times this toolchain is named after the > standard toolchain for the platform. It does not appear to conflict with > any other usage of the prefix. As such I'm not going to rename things; I > don't believe that serves any useful purpose to our users. > > If FTP-master wishes to disagree that's of course within their rights, > and they can reject the package from NEW. I'll take that risk; I think > I've explained my reasoning throughout this ITP discussion. For who ever it may concern: My reasoning is following: Xtensa is undocumented mess of assumptions and esoteric believes. This discussion showed it just one more time. If some one will seek how to support next chip running Xtensa, this person should start from scratch. Even if it is plain unchanged platform provided by Tensilica/Cadence. With nearly no help from any company to identify and sort things we spread our man power to support in some case just same architecture or variant. I've got attention to this issue, only because it may cover architecture of other package. After some investigation, I can say - no, it is not. Alone the time needed to investigate what architecture it is and is it similar with other arch, is an indicator for huge issues in this case. For the archive, here is short summary for some of know chips using Xtensa https://wikidevi.com/wiki/Xtensa, hope it will save time for some one. As independent review for this package i would suggest: - please clean binutils-xtensa-lx106/debian/overlay. Convert it from dos to unix formatting and create a diff against mainline projects. It will help to see what was actually changed. - please change the package name. searching for existing accepted binutils for not linux will give: binutils-arm-none-eabi binutils-avr binutils-h8300-hms binutils-i686-gnu binutils-i686-kfreebsd-gnu binutils-m68hc1x binutils-mingw-w64 binutils-mingw-w64-i686 binutils-mingw-w64-x86-64 binutils-msp430 binutils-x86-64-kfreebsd-gnu binutils-z80 In most cases we use chip name or architecture. binutils-xtensa-lx106 is confusing, lx106 is not official xtensa platform, not official chip name and even not architecture specified in esp8266 documentation. It seems to be some kind of tradition. Since MIPS seems to have long list of architecture variants, similar rule should be applied for Xtensa: binutils-mips-linux-gnu binutils-mips64-linux-gnuabi64 binutils-mips64-linux-gnuabin32 binutils-mips64el-linux-gnuabi64 binutils-mips64el-linux-gnuabin32 binutils-mipsel-linux-gnu binutils-mipsisa32r6-linux-gnu binutils-mipsisa32r6el-linux-gnu binutils-mipsisa64r6-linux-gnuabi64 binutils-mipsisa64r6-linux-gnuabin32 binutils-mipsisa64r6el-linux-gnuabi64 binutils-mipsisa64r6el-linux-gnuabin32 It can be: bintuils-xtensa106mesp8266 or bintuils-xtensa106micro-esp8266, which will be translated as "ESP8266 specific architecture based on Xtensa 106Micro" Some one who will seek for all utils for 106micro should be able to find it. - I would recommend to clarify real CPU architecture with Espressif or Cadence. In case it is a plain Xtensa Diamond 106Micro architecture, most of name related issues will be solved and this package will be clearly interesting for other users. -- Regards, Oleksij
Bug#917546: binutils-xtensa-lx106 is a wrong name
Am 29.12.18 um 19:11 schrieb Jonathan McDowell: > On Sat, Dec 29, 2018 at 05:41:47PM +0100, Oleksij Rempel wrote: >> Am 29.12.18 um 16:56 schrieb Jonathan McDowell: >>> On Sat, Dec 29, 2018 at 02:02:01PM +0100, Oleksij Rempel wrote: >>>> Am 29.12.18 um 12:16 schrieb Jonathan McDowell: >>>>> On Sat, Dec 29, 2018 at 08:11:31AM +0100, Oleksij Rempel wrote: >>>>>> in my experience with xtensa, it has some basic customizable >>>>>> core/instruction set (in this case it is lx106) which is then optimized >>>>>> for some application (for example for esp8266). At the end, this >>>>>> toolchain won't be able to build binary for different lx106 based >>>>>> hardware. In this case the naming is wrong. It should be: >>>>>> binutils-xtensa-lx106-esp8266 >>>>>> binutils-espressif-esp8266 >>>>>> binutils-xtensa-lx106-espressif-esp8266 >>>>>> or some thing like this... >>>>> >>>>> My understanding is the core is the "xtensa" architecture and "lx106" >>>>> refers to the customizations of that core. The ESP8266 and ESP32 both >>>>> use the Xtensa architecture, but the variant in the ESP8266 is the lx106 >>>>> and in the ESP32 it's an lx108. >>>> >>>> Uff.. let's do together your home work in manner of OSINT investigation. >>>> https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf >>>> "Besides the Wi-Fi functionalities, ESP8266EX also integrates an >>>> enhanced version of Tensilica’s L106 Diamond series 32-bit processor and >>>> on-chip SRAM." >>>> >>>> I interpret is as following: >>>> 1. not xtensa lx106, it is xtensa Diamond variant L106 >>>> 2. it is enhanced version of Tensilica’s L106 Diamond >>>> >>>> Means, what ever toolchain is provided by this request, it is not clean >>>> Xtensa Diamond L106. >>> >>> There's no indication that the enhancements of the ESP8266 change the >>> architecture / instruction set. The Diamond L106 is cacheless while the >>> ESP8266 has internal cache, for example. >> >> Really? >> >> the config provided by you looks like this: >> #undef XCHAL_ICACHE_SIZE >> #define XCHAL_ICACHE_SIZE 0 >> >> #undef XCHAL_DCACHE_SIZE >> #define XCHAL_DCACHE_SIZE 0 >> >> #undef XCHAL_ICACHE_LINESIZE >> #define XCHAL_ICACHE_LINESIZE 16 >> >> #undef XCHAL_DCACHE_LINESIZE >> #define XCHAL_DCACHE_LINESIZE 16 >> >> #undef XCHAL_ICACHE_LINEWIDTH >> #define XCHAL_ICACHE_LINEWIDTH 4 >> >> #undef XCHAL_DCACHE_LINEWIDTH >> #define XCHAL_DCACHE_LINEWIDTH 4 >> >> #undef XCHAL_DCACHE_IS_WRITEBACK >> #define XCHAL_DCACHE_IS_WRITEBACK 0 >> >> If both caches have no size, are they limit less? > > I'm guessing GCC cares about the internal caches, but the Espressif chip > has some caches outside the 106 core to handle the flash. I don't know > for certain, I'm just going on the data sheets you provided. In my experience data sheet is not always in sync with the code. Some of parts can be wrong. If code is wrong, then it is good time to fix it. >>> I'm not disagreeing it's probably the 106Micro which is also referred to >>> as the L106 in various places. It's not clear to me that this means >>> there's a *different* variant with a different binary requirement than >>> the lx106 toolchain proposed here. >> >> can you proof it? > > No, I can't prove there isn't an lx106 that is different enough to need > a separate compiler, all I can say is that all indications of the lx106 > are related to the ESP8266 and that it appears to be a 106Micro core. > >>>>> Looking at the HTC firmware package it appears *it's* the one >>>>> engaging in namespace problems by using xtensa-elf for the >>>>> customised core. I think it should probably be xtensa-htc-elf at >>>>> least. >>>> >>>> What ever is used insight of the package can't be seen as "engaging in >>>> namespace problems". >>> >>> Sure, internal names used only in build don't matter, but you brought >>> up the HTC case as another example of Xtensa hardware and I'm pointing >>> out I don't believe the naming chosen for this package causes problems >>> for the HTC firmware building case. >> >
Bug#917546: binutils-xtensa-lx106 is a wrong name
Am 29.12.18 um 16:56 schrieb Jonathan McDowell: > On Sat, Dec 29, 2018 at 02:02:01PM +0100, Oleksij Rempel wrote: >> Am 29.12.18 um 12:16 schrieb Jonathan McDowell: >>> On Sat, Dec 29, 2018 at 08:11:31AM +0100, Oleksij Rempel wrote: >>>> in my experience with xtensa, it has some basic customizable >>>> core/instruction set (in this case it is lx106) which is then optimized >>>> for some application (for example for esp8266). At the end, this >>>> toolchain won't be able to build binary for different lx106 based >>>> hardware. In this case the naming is wrong. It should be: >>>> binutils-xtensa-lx106-esp8266 >>>> binutils-espressif-esp8266 >>>> binutils-xtensa-lx106-espressif-esp8266 >>>> or some thing like this... >>> >>> My understanding is the core is the "xtensa" architecture and "lx106" >>> refers to the customizations of that core. The ESP8266 and ESP32 both >>> use the Xtensa architecture, but the variant in the ESP8266 is the lx106 >>> and in the ESP32 it's an lx108. >> >> Uff.. let's do together your home work in manner of OSINT investigation. >> https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf >> "Besides the Wi-Fi functionalities, ESP8266EX also integrates an >> enhanced version of Tensilica’s L106 Diamond series 32-bit processor and >> on-chip SRAM." >> >> I interpret is as following: >> 1. not xtensa lx106, it is xtensa Diamond variant L106 >> 2. it is enhanced version of Tensilica’s L106 Diamond >> >> Means, what ever toolchain is provided by this request, it is not clean >> Xtensa Diamond L106. > > There's no indication that the enhancements of the ESP8266 change the > architecture / instruction set. The Diamond L106 is cacheless while the > ESP8266 has internal cache, for example. Really? the config provided by you looks like this: #undef XCHAL_ICACHE_SIZE #define XCHAL_ICACHE_SIZE 0 #undef XCHAL_DCACHE_SIZE #define XCHAL_DCACHE_SIZE 0 #undef XCHAL_ICACHE_LINESIZE #define XCHAL_ICACHE_LINESIZE 16 #undef XCHAL_DCACHE_LINESIZE #define XCHAL_DCACHE_LINESIZE 16 #undef XCHAL_ICACHE_LINEWIDTH #define XCHAL_ICACHE_LINEWIDTH 4 #undef XCHAL_DCACHE_LINEWIDTH #define XCHAL_DCACHE_LINEWIDTH 4 #undef XCHAL_DCACHE_IS_WRITEBACK #define XCHAL_DCACHE_IS_WRITEBACK 0 If both caches have no size, are they limit less? >> Continue to seek for Xtensa L106 gives me this link: >> https://ip.cadence.com/uploads/white_papers/Diamond_Tensilica.pdf >> >> Diamond Controller Cores: >> 106Micro - Smallest 32-bit, ultra-low power, cache-less RISC controller >> with local memories. >> 108Mini - Ultra-low power, cacheless controller core with rich interrupt >> architecture, minimal gate count for lowest silicon cost. >> 212GP - Flexible mid-range controller core with instruction and data >> caches and user-defined local memory sizes >> Diamond CPU Cores: >> 232L - Flexible mid-range CPU with a Memory-Management Unit (MMU) for >> Linux OS support >> 570T - Extremely high-performance, 2- or 3-issue static superscalar >> processor. >> >> The price segment of ESP8266 let me assume, it is not a new Xtensa >> development, it is probably some thing old and not so expensive. I would >> say, most probably it is Xtensa Diamond 106Micro. > > I'm not disagreeing it's probably the 106Micro which is also referred to > as the L106 in various places. It's not clear to me that this means > there's a *different* variant with a different binary requirement than > the lx106 toolchain proposed here. can you proof it? >>> Looking at the HTC firmware package it appears *it's* the one >>> engaging in namespace problems by using xtensa-elf for the >>> customised core. I think it should probably be xtensa-htc-elf at >>> least. >> >> What ever is used insight of the package can't be seen as "engaging in >> namespace problems". > > Sure, internal names used only in build don't matter, but you brought > up the HTC case as another example of Xtensa hardware and I'm pointing > out I don't believe the naming chosen for this package causes problems > for the HTC firmware building case. I didn't said, that naming of this package can cause a problem for the htc package. Back in 2016 I tried to provide a tool chain for HTC firmware and the answer was, there is no reason to accept a toolchain to support only one chip. If your package will be accepted, this mean, the toolchain for HTC firmware should be accepted as well. And both should be prope
Bug#917546: binutils-xtensa-lx106 is a wrong name
Am 29.12.18 um 12:16 schrieb Jonathan McDowell: > On Sat, Dec 29, 2018 at 08:11:31AM +0100, Oleksij Rempel wrote: >> in my experience with xtensa, it has some basic customizable >> core/instruction set (in this case it is lx106) which is then optimized >> for some application (for example for esp8266). At the end, this >> toolchain won't be able to build binary for different lx106 based >> hardware. In this case the naming is wrong. It should be: >> binutils-xtensa-lx106-esp8266 >> binutils-espressif-esp8266 >> binutils-xtensa-lx106-espressif-esp8266 >> or some thing like this... > > My understanding is the core is the "xtensa" architecture and "lx106" > refers to the customizations of that core. The ESP8266 and ESP32 both > use the Xtensa architecture, but the variant in the ESP8266 is the lx106 > and in the ESP32 it's an lx108. Uff.. let's do together your home work in manner of OSINT investigation. https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf "Besides the Wi-Fi functionalities, ESP8266EX also integrates an enhanced version of Tensilica’s L106 Diamond series 32-bit processor and on-chip SRAM." I interpret is as following: 1. not xtensa lx106, it is xtensa Diamond variant L106 2. it is enhanced version of Tensilica’s L106 Diamond Means, what ever toolchain is provided by this request, it is not clean Xtensa Diamond L106. Continue to seek for Xtensa L106 gives me this link: https://ip.cadence.com/uploads/white_papers/Diamond_Tensilica.pdf Diamond Controller Cores: 106Micro - Smallest 32-bit, ultra-low power, cache-less RISC controller with local memories. 108Mini - Ultra-low power, cacheless controller core with rich interrupt architecture, minimal gate count for lowest silicon cost. 212GP - Flexible mid-range controller core with instruction and data caches and user-defined local memory sizes Diamond CPU Cores: 232L - Flexible mid-range CPU with a Memory-Management Unit (MMU) for Linux OS support 570T - Extremely high-performance, 2- or 3-issue static superscalar processor. The price segment of ESP8266 let me assume, it is not a new Xtensa development, it is probably some thing old and not so expensive. I would say, most probably it is Xtensa Diamond 106Micro. After some voodoo with your overlay hack, i got more or less readable diff with original binutils. With this diff it is possible to see the architecture differences. Most important is the "Copyright (c) 2003-2010 Tensilica Inc." which confirms my assumption about Xtensa Diamond 106Micro. >> If debian maintainers will decide to include this toolchain, then we >> need to develop unified naming shema for this kind of toolchains, >> because we already have completely opened firmware based on xtenas for >> different hardware, see firmware-ath9k-htc package. Extra toolchain for >> this package will make step forward reproducible builds. > > xtensa-lx106-elf is the common prefix in the wild for the ESP8266, > xtensa-esp32-elf is in use for the ESP32/lx108 pairing. Most probably it is Xtensa Diamond 108Mini > Looking at the > HTC firmware package it appears *it's* the one engaging in namespace > problems by using xtensa-elf for the customised core. I think it should > probably be xtensa-htc-elf at least. What ever is used insight of the package can't be seen as "engaging in namespace problems". > > There's an open RFP for gcc-xtensa (#868895). I think with the right > amount of work a single pair of binutils-xtensa/gcc-xtensa packages > could be built that allowed run time configuration of which core was > being targeted Probably it should go as is... see my last comment. > but I've been using these ESP8266/lx106 packages for the > past 4 months and it seems reasonable to get them uploaded and available > for use. NACK. It looks like work made by Max Filippov is in usable shape, so i hope, it is a way to go: https://github.com/jcmvbkbc/xtensa-dynconfig -- Regards, Oleksij
Bug#917546: binutils-xtensa-lx106 is a wrong name
Hi, in my experience with xtensa, it has some basic customizable core/instruction set (in this case it is lx106) which is then optimized for some application (for example for esp8266). At the end, this toolchain won't be able to build binary for different lx106 based hardware. In this case the naming is wrong. It should be: binutils-xtensa-lx106-esp8266 binutils-espressif-esp8266 binutils-xtensa-lx106-espressif-esp8266 or some thing like this... If debian maintainers will decide to include this toolchain, then we need to develop unified naming shema for this kind of toolchains, because we already have completely opened firmware based on xtenas for different hardware, see firmware-ath9k-htc package. Extra toolchain for this package will make step forward reproducible builds. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
Bug#915737: open-ath9k-htc-firmware still uses GCC 7
If I see it correctly, there is no way to have (default) gcc-source. I'll update it to gcc-8-source. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
Bug#902854: openocd: depends wrongly depends on libjaylink already included in to openocd
Package: openocd Version: 0.10.0-4 Severity: normal Dear Maintainer, The package depends on libjaylink0 which is already included in to the source code of OpenOCD. See openocd/src/jtag/drivers/libjaylink/ -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.8-bla (SMP w/24 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages openocd depends on: ii libc6 2.27-3 ii libftdi1-2 1.4-1+b1 ii libhidapi-hidraw0 0.8.0~rc1+git20140818.d17db57+dfsg-2 ii libjaylink00.1.0-1 ii libjim0.77 0.77+dfsg0-3 ii libusb-0.1-4 2:0.1.12-32 ii libusb-1.0-0 2:1.0.22-2 openocd recommends no packages. openocd suggests no packages. -- no debconf information
Bug#895696: firmware-ath9k-htc: doesn't work with wlx* interface names
Hi, firmware has no idea about interface name. Most probably you are affected by this bug: https://github.com/qca/open-ath9k-htc-firmware/issues/132 -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
Bug#875426: firmware-ath9k-htc: Kernel don't find the firmware
Am 11.09.2017 um 21:41 schrieb Diego Roversi: > On Mon, 11 Sep 2017 19:36:46 +0200 > Oleksij Rempel <li...@rempel-privat.de> wrote: > >>> I didn't expected that a reboot was needed. I wonder if there is a way to >>> avoid to reboot. >> >> Suddenly not really. It is kind of compromise between bad and worse >> options. I hope it is not the worse one :) > > For me the bug can be closed, if it cannot be fixed. I have a suggestion: > could you explain the problem, so that the information is available to other > users? > > Thanks again, > Diego. > There are fallowing issue which was needed to solve: - have tested "certified" binary firmware know to work (path 1) from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ - have different firmware versions on one system for regression testing (path 2). The reason: if firmware update will kill single usable netowrok interface it will be hard to roll back to working version. - have open source firmware compiled within debian build system (path 3) With kernel version v4.4 was added support for multiple firware paths in the ath9k-htc driver. One of paths was reserved for development FW version, which is not enabled by default. We have decided to use development FW name for debian package. In this case it will not conflict with stable/tested FW version. So the debian package is providing modprobe config which is setting use_dev_fw flag. To make this flag work, we need to reload ath9k-htc module or reboot the system. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
Bug#875426: firmware-ath9k-htc: Kernel don't find the firmware
did you tried to reboot the system or reload driver? This name needs extra module parametr to be enabled. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
Bug#873727: open-ath9k-htc-firmware: dbgsym package should not be in debian/control
Am 30.08.2017 um 16:05 schrieb Stuart Prescott: > Source: open-ath9k-htc-firmware > Version: 1.4.0-81-gf206e56+dfsg-2 > Severity: important > > Dear Maintainer, > > The dbgsym package firmware-ath9k-htc-dbgsym should not be listed in > debian/control and should not end up in the main Debian archive but > instead in the debug archive. In the future, inclusion of the package > in debian/control will lead to the upload being automatically rejected. After long discussion on IRC #debian-mentors we was not able to find a proper solution for *not*native* debug symbols. If debian packaging system is now able to handle it, please, let me know. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
Bug#859066: linux-image-*: recommend firmware-ath9k-htc
Am 31.03.2017 um 19:17 schrieb Ben Hutchings: > On Fri, 2017-03-31 at 18:52 +0200, Oleksij Rempel wrote: > [..] >> I don't think it makes any sense. Why should we symlink some thing >> different/not_stable to file name of stable firmware? >> Especially if we have 1.dev.0? >> firmware-ath9k-htc package should and can provide any latest possible >> version of firmware form git. All possible distribution patches are >> welcome as well. >> firmware-ath9k-htc-v1.5 should provide stable version without any >> chanes. This is needed to make sure suers are able to fall back to >> working version of firmware even if firmware-ath9k-htc will brake >> connection. > > If this package is not going to provide a stable ABI then I'll consider > adding a Breaks instead. I'm not sure what you mean. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
Bug#859066: linux-image-*: recommend firmware-ath9k-htc
Am 31.03.2017 um 15:26 schrieb Ben Hutchings: > On Fri, 2017-03-31 at 08:15 +0300, Paul Fertser wrote: >> On Thu, Mar 30, 2017 at 10:04:24PM +0100, Ben Hutchings wrote: >>> On Thu, 2017-03-30 at 09:22 +0800, Paul Wise wrote: Source: linux Version: 4.10~rc6-1~exp1 Severity: wishlist X-Debbugs-CC: open-ath9k-htc-firmw...@packages.debian.org Now that open-ath9k-htc-firmware has been accepted into Debian unstable, please add "Recommends: firmware-ath9k-htc" to the metadata for the linux-image-* packages in Debian experimental. >> >> Not many linux-image-* users have ath9k-htc hardware so I do not see >> how this recommendation can make sense here. > > This is also true for most of the devices supported by firmware-linux- > free, but it's small so it shouldn't hurt. > >> The package should have provided appropriate AppStream metainformation >> so Debian should be able to suggest installing it when the device is >> plugged in for the first time. > > Unfortunately I don't think we have all the infrastructure in place for > that yet. > >>> As this firmware has gone through at least one ABI bump, I think we >>> need to plan for a future ABI bump. >> >> So far the idea was to upload a package named firmware-ath9k-htc-1.5.0 >> after the next ABI bump. There's no reason why >> firmware-ath9k-htc-1.5.0 shouldn't be able to co-exist on the same >> system with e.g. firmware-ath9k-htc-1.6.0, as the user should be able >> to choose different kernel versions on boot, and hence different >> firmware versions will be appropriate. >> >>> Therefore: >>> - You should not name the files as simply '1.dev.0' versions, but by >>> the implemented ABI version (as the driver expects by default). >> >> The code that's currently packaged is definitely not 1.4.0 code, it >> got some non-trivial changes (not affecting ABI though) after the >> 1.4.0 was released. So naming an intermediate version in any way other >> than 1.dev.0 would only add to the confusion IMHO. > > So install your files with the real version number and make a symlink > with the '1.4.0' name. I don't think it makes any sense. Why should we symlink some thing different/not_stable to file name of stable firmware? Especially if we have 1.dev.0? firmware-ath9k-htc package should and can provide any latest possible version of firmware form git. All possible distribution patches are welcome as well. firmware-ath9k-htc-v1.5 should provide stable version without any chanes. This is needed to make sure suers are able to fall back to working version of firmware even if firmware-ath9k-htc will brake connection. -- Regards, Oleksij signature.asc Description: OpenPGP digital signature
Bug#859066: linux-image-*: recommend firmware-ath9k-htc
Hi, Am 31.03.2017 um 07:15 schrieb Paul Fertser: On Thu, Mar 30, 2017 at 10:04:24PM +0100, Ben Hutchings wrote: On Thu, 2017-03-30 at 09:22 +0800, Paul Wise wrote: Source: linux Version: 4.10~rc6-1~exp1 Severity: wishlist X-Debbugs-CC: open-ath9k-htc-firmw...@packages.debian.org Now that open-ath9k-htc-firmware has been accepted into Debian unstable, please add "Recommends: firmware-ath9k-htc" to the metadata for the linux-image-* packages in Debian experimental. Not many linux-image-* users have ath9k-htc hardware so I do not see how this recommendation can make sense here. The package should have provided appropriate AppStream metainformation so Debian should be able to suggest installing it when the device is plugged in for the first time. As this firmware has gone through at least one ABI bump, I think we need to plan for a future ABI bump. So far the idea was to upload a package named firmware-ath9k-htc-1.5.0 after the next ABI bump. There's no reason why firmware-ath9k-htc-1.5.0 shouldn't be able to co-exist on the same system with e.g. firmware-ath9k-htc-1.6.0, as the user should be able to choose different kernel versions on boot, and hence different firmware versions will be appropriate. Therefore: - You should not name the files as simply '1.dev.0' versions, but by the implemented ABI version (as the driver expects by default). The code that's currently packaged is definitely not 1.4.0 code, it got some non-trivial changes (not affecting ABI though) after the 1.4.0 was released. So naming an intermediate version in any way other than 1.dev.0 would only add to the confusion IMHO. Probably it would make sense to have the minor number indicate a subversion of same-ABI firmwares, but for some reasons the kernel driver maintainers decided against that. I hope Oleksij will correct me if I'm missing something here. no. nothing is missing. thank you -- Regards, Oleksij
Bug#840515: RFS: open-ath9k-htc-firmware/1.4.0-25-gf6af791-1 ITP #751339
Am 13.10.2016 um 05:55 schrieb Paul Wise: > On Wed, Oct 12, 2016 at 7:38 PM, Paul Fertser wrote: > >> Cc: Oleksij Rempel <li...@rempel-privat.de> > > Please use the X-Debbugs-CC pseudo-header when submitting bugs instead > of CC, so that the recipients get the bug number too. Put it just > after Severity in the mail body so those CCed can see it: > > https://www.debian.org/Bugs/Reporting#xcc > >> I am looking for a sponsor for my package "open-ath9k-htc-firmware" > > Correct me if I'm wrong but IIRC either yourself or Oleksij have > commit/release access upstream? correct. > The comments for the overrides for lintian tag source-is-missing > should indicate which file is the source for each prebuilt file. I > would have one comment per instance of the tag. Just one comment > saying they are removed at build time is enough for all of the > overrides for lintian tag source-contains-prebuilt-binary. Personally, > I would suggest removing all of these files from the upstream git > repository and always building them from source. If you need to keep > them, put them in tarballs in the github releases. I can answer this part, especially because most of comments are related to sboot/ folder. sboot contains ROM code flashed to the chip or eeprom. Not all ROM parts seems to be open (fix me if i'm wrong), but at least contain some binary. If some person will decide to RE closed parts, it will be easier to know what exactly should be RE instead of work on complete ROM. No one will ever touch/patch sboot. At least i will not allow it. The actual firmware is located in RAM and to reduce memory usage, it is using ROM functions. To understand what is used and to be able to fix any thing in the firmware you need to read sboot. The sboot should reflect state of the code with all this bugs and problems. Even if this is wrong FSF address. For most paranoid persons we remove sboot before build is started. > Personally, I would recommend the generated files docs/*.png be > removed from the upstream git repo and rendered at build time from > their source SVG files if they are needed. ok, i'll remove pngs. > I think you should also remove the prebuilt files before > dh_auto_configure so that they can never get used by a build, even a > manual one where `debian/rules clean` is not run. > > What is the reason for removing the docs/ and sboot/ directories in > override_dh_clean? AFAICS both of these contain source files. IMO you > should just remove the generated files. > > The cmake part of the build process does not print compiler > invocation. Debian requires full compiler flags/output in build logs. > For cmake usually debhelper automatically passes > -DCMAKE_VERBOSE_MAKEFILE=ON but it doesn't seem to be working here? > > The debian/watch file needs adjusting for the new source package name: > s/firmware-ath9k-htc/open-ath9k-htc-firmware/ > > Personally I would leave "debian uupdate" out of the watch file > because it can be annoying for people who just want to download. > > I would use a debian/clean file instead of override_dh_clean. > > Please get the FSF address corrected in the upstream copyright info. > > debian/cross-toolchain.mk needs copyright/license info filled in, > preferably in both the header of it and in debian/control. > > The Uploaders field is empty. I would have expected to your name there > if you intend to co-maintain it with Oleksij. > > I would recommend running this command (from the devscripts package) > so that future diffs of the Debian packaging are easier to read: > > wrap-and-sort --short-indent --wrap-always --sort-binary-packages > --trailing-comma > > The Vcs-* fields should point at the repository containing the Debian > packaging, not upstream: > > https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields > > The Conflicts/Suggests fields are empty, you can remove them from > debian/control. > > For merged bugs, you only need to close one of them and the rest will > be closed too. > > What is the reason for renaming the upstream firmware files? Does the > Linux kernel detect the new names? upstream file names have old name schema without version numbers. Since we are not able to guarantee 100% backwards compatibility and testing coverage for all available kernel version we need to have different fw binaries for different version. For example linux-firmware repo contains both 1.3 and 1.4 binaries. The same is about debian firmware-atheros packet, it contains: /lib/firmware/ath9k_htc/htc_7010-1.4.0.fw /lib/firmware/ath9k_htc/htc_9271-1.4.0.fw /lib/firmware/htc_7010.fw /lib/firmware/htc_9271.fw Only way to avoid conflict between packages and be able to provide FW version different from actual re
