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

Attachment: signature.asc
Description: PGP signature

Reply via email to