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><arch_variant><vendor_customization> 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 <linux@rempel-privat.de> An: 917546@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; 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
Attachment:
signature.asc
Description: OpenPGP digital signature