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 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. If I would say, i wont to provide toolchain called, bla-blu-MOPS instead of MIPS and say: I and my friends started to call it MOPS and think it is cool, so lets provide package with this name. What kind of medical treatment I'll get as friendly suggestion from debian devs? 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. -- Regards, Oleksij
