Hello Thomas, Am 15.04.2018 um 20:16 schrieb Thomas Zimmermann:
On 2018 M04 15, Sun 18:40:08 CEST Andreas Färber wrote:
I've submitted esptool 2.3.1 for inclusion in Tumbleweed:
https://build.opensuse.org/request/show/596756
esptool is a set of tools to work with Espressif ESP8266 and ESP32 microcontrollers.
Hi, it seems we have two devel projects for esptool, the other one is here: https://build.opensuse.org/package/show/CrossToolchain:xtensa/esptool
We should have a look at both of them and decide in which project should be used as devel project.
There is nothing really to decide here... I've already tried to hint you in 2016 that putting random packages into CrossToolchain:xtensa is not a helpful idea - it's not an official devel project for anything. GCC toolchains belong into devel:gcc, Python packages into devel:languages:python and other microcontroller tools into electronics or hardware. Either you want to contribute to Tumbleweed or you want to do your own thing in a hidden corner - that's _your_ decision, not mine. If you don't submit, don't complain! I checked in Factory and d:l:python for an existing package, none, after Espressif a month ago at Embedded World pointed me to their esptool for lack of upstream-ready OpenOCD. Your package is at version 1.3 (one year old), mine at 2.3.1. Yours doesn't follow the new Python Singlespec packaging conventions and is pre-python3, so it can't be submitted to Factory as is; mine got accepted into d:l:p some weeks ago and is on its way to Factory now. So you're welcome to contribute to my package in devel:languages:python, I'd happily make you co-maintainer. You could add "Obsoletes: esptool" to the python2- sub-package, but Factory is building python3-esptool only, so they should install side-by-side. https://en.opensuse.org/openSUSE:Packaging_Python_Singlespec Since 2016 I have an untested cross-xtensa-binutils sitting in my home: I replied to you on 2016-05-18 on opensuse-packaging list:
In particular I am wondering whether it might be possible to build a non-Espressif based xtensa toolchain with my pending newlib package and our binutils and gcc5/gcc6. In a quick experiment binutils succeeds to build [1] but I don't spot xtensa support in newlib - is libc one of those binary libraries [that you had mentioned]?
[1] https://build.opensuse.org/package/show/home:a_faerber:xtensa/cross-xtensa-b... But instead of working with me to figure out what standard C library to use, to turn that into a full cross-toolchain, you went on to tell me that you only need libraries for peripherals because you already use crosstool-ng ... which from my perspective is not suited for Factory, so our paths parted with - disappointingly - no common objective. Background: https://events.opensuse.org/conference/oSC16/program/proposal/918 Note that while my cross-xtensa-binutils package is not official in any way, it is a _branch_ of the official one in devel:gcc, so that I can eventually submit back and get it into Factory. My problem is, I don't know what triplet and name to use since I'm not so familiar with those architectures and implementations - can we have a binutils shared across GCC targets? Do we need a GCC for ESP32, one for ESP8266, one for any other Xtensa? I.e., how much is compiled-in, how much is just command line argument defaults? Richie doesn't like copying whatever hardware vendors are doing, asking me for better code sharing (e.g., cross-arm-none-gccX toolchains are reusing cross-arm-binutils). Espressif pointed me to https://esp-idf.readthedocs.org/ but that doesn't appear to explain details of how to build a cross-toolchain in terms of configure arguments and target triplet differences. It rather instructs to either download a binary xtensa-esp32-elf toolchain or use their crosstool-NG like you did. https://esp-idf.readthedocs.io/en/latest/get-started/linux-setup-scratch.htm... I just checked my latest newlib package (3.0.0) and I still don't spot any xtensa or esp* code in the upstream tarball: https://build.opensuse.org/package/show/devel:gcc/newlib Apparently all the xtensa code still sits downstream in patches: https://github.com/espressif/crosstool-NG/tree/xtensa-1.22.x/local-patches/n... For GCC it doesn't look as extreme: https://github.com/espressif/crosstool-NG/tree/xtensa-1.22.x/local-patches/g... Espressif only mentioned to me some errata for PSRAM access not being upstream - I'm guessing that's GCC patches 0007 and 0013 then. So we'll need to talk to Espressif, Tensilica or whomever to make them understand it's a bad idea hording downstream patches and to get that situation fixed somehow. For RISC-V we were in a similar situation with newlib being the bottleneck, and they got it resolved - so there's hope! Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org