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 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?
>
> I think when the manufacturer of the SoC is shipping toolchains with a
> particular naming convention that's a different situation to a packager
> deciding they want to call their toolchain something new.
Non of debian mips toolchains has identical names with official vendor
toolchains. Please see my last comment.
>
>> 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
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.
--
Regards,
Oleksij
Reply to: