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
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. J. -- Web [ Asking whether machines can think is like asking whether ] site: https:// [ submarines can swim. ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 signature.asc Description: PGP signature
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. >> >> 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 properly named. > > I can't comment on the HTC compiler not being accepted, but I think the > ESP8266 platform is more widely developed for than the HTC wifi chipset > in terms of Debian users wanting access to it. > > In terms of naming for the ESP8266 this *is* the name users will expect > and that existing tooling uses. > > 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
Bug#917546: binutils-xtensa-lx106 is a wrong name
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. > > 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. > > 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 properly named. I can't comment on the HTC compiler not being accepted, but I think the ESP8266 platform is more widely developed for than the HTC wifi chipset in terms of Debian users wanting access to it. In terms of naming for the ESP8266 this *is* the name users will expect and that existing tooling uses. > >>> 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 >
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 properly named. > >>> 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
Bug#917546: binutils-xtensa-lx106 is a wrong name
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. > 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. > > 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. > > 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 Longer term I think that's the ultimate solution (dynamic config with -xtensa packages) but for now I think our users are well served by a set of build tools for the ESP8266 which don't obviously stamp over any other usage of the xtensa-lx106- namespace and match the naming already used throughout the ecosystem. J. -- Never test for an error unless you're ready to handle it. This .sig brought to you by the letter P and the number 29 Product of the Republic of HuggieTag signature.asc Description: PGP signature
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
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. > 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. 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. 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, 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. J. -- ] https://www.earth.li/~noodles/ []Why do I get the feeling I'm[ ] PGP/GPG Key @ the.earth.li[] going to regret this?[ ] via keyserver, web or email. [][ ] RSA: 4096/0x94FA372B2DA8B985 [][ signature.asc Description: PGP signature
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
