|
Re: Next supported boards on Zephyr - STM32L0 ?
Neil Armstrong
Hi Felix,
On 06/16/2017 02:26 PM, Erwan Gouriou wrote: Hi Felix,Indeed, it's planned but I still need to debug the base port. If you want to give a try, here is my base branch : https://github.com/superna9999/zephyr/commits/stm32l0x I'll be happy to cooperate and get this merged when working ! Having STM32L073 working won't be hard if 053 is working. Neil Erwan
|
|
|
|
Is possible move to CMake and crosstools-ng in 1.9
jack ma
Hi, I am looking forward to that zephyr wil move to crosstools-ng and cmake just want to know if there are detailed plans for these great work in the next release? Thanks
|
|
|
|
Re: Zephyr help
Hi Tamra,
I do not know much about the Z-tree myself but assuming this is equivalent to the Zephyr kernel running on Arduino 101, you could get a lot of info directly from the Zephyr Project website: * All documentation: https://www.zephyrproject.org/doc/ * Arduino/Genuino 101 documentation: https://www.zephyrproject.org/doc/boards/x86/arduino_101/doc/board.html
HTH, Geoffroy
From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...]
On Behalf Of Tamra Oyama
Sent: Friday, June 16, 2017 8:46 AM To: zephyr-devel@... Subject: [Zephyr-devel] Zephyr help
Hello Zephyr Team,
|
|
|
|
Re: Next supported boards on Zephyr - STM32L0 ?
Erwan Gouriou
Hi Felix, From what I'm aware of, there is no such plan. Though, I know Neil as some L0 port working on his own (though on SoC STM32L053). I'm not sure what are his plans on that, but maybe you could check with him what is missing to get it upstreamed (might just be time). In any case, your help would be welcomed to get the board you need supported. With some help, you could get it working in few hours and upstreamed in couple of weeks (so you don't have to wait for next Zephyr release :-)). Erwan
On 16 June 2017 at 11:11, Felix Levitre <Felix.Levitre@...> wrote: Hi,
|
|
|
|
Re: Zephyr 1.8.0 Released
Erwin Rol
Thanks for including my Olimex BSP.
toggle quoted messageShow quoted text
- Erwin
On 16-6-2017 5:37, Nashif, Anas wrote:
Hi,
|
|
|
|
Next supported boards on Zephyr - STM32L0 ?
Felix Levitre <Felix.Levitre@...>
Hi,
I would like to know if the Nucleo STM32L0xx boards from ST (for example STM32L073 with Cortex ARM M0+) will be part of the supported board in the next release of Zephyr ? If it's not the case, is there a plan to port this board in the future ? (And when ? ) Thanks, Félix Levitre
|
|
|
|
Zephyr help
Tamra Oyama <tamrako@...>
Hello Zephyr Team, I am using the Arduino 101 Curie Open Developer Kit Z-tree. Link: https://software.intel.com/en-us/node/675544 When I try to compile a file in Zephyr using make config, there are a bunch of choices I need to pick. Is there a standard or default way to set up the zephyr compiler in the Z-tree? I want to set up the Zephyr OS so I can compile C++ files, how would I go about doing this? In the github below, there are various bluetooth files about controlling bluetooth. I am interested in gaining control of the curie Bluetooth so I can write and compile my own programs. Do you have any suggestions? https://github.com/zephyrproject-rtos/zephyr/tree/master/samples/bluetooth Thank you, Tamra
|
|
|
|
Zephyr 1.8.0 Released
Nashif, Anas
Hi,
We are pleased to announce the release of Zephyr kernel version 1.8.0.
Major enhancements with this release include:
* Tickless kernel * IP Stack improvements * Bluetooth 5.0 features * Ecosystem: Tracing, debugging support through third-party tools (openocd, Segger Systemview) * Improved build support on Mac and Windows development environments * Xtensa GCC support * Initial implementation of MMU/MPU support * Expanded device support
More details can be found here: https://github.com/zephyrproject-rtos/zephyr/releases
Many thanks to all of you who made this release happen. Thank you for the contribution and participation.
Regards, Anas
|
|
|
|
CAN drivers/infrastructure
Erwin Rol
Hey all,
is there anybody working on CAN drivers and/or higher level CAN stacks like CANOpen ? - Erwin
|
|
|
|
Re: sdk-ng
Erwin Rol
Hey Anas,
On 14-6-2017 3:56, Nashif, Anas wrote: Erwin,Well than I will be happy :-) I did notBut do they offer what Zephyr needs? Especially when it comes to the C library. To take the RTEMS example again, newlib has a lot of RTEMS support in it. https://www.sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libc/sys;hb=HEAD When things like that are also needed for Zephyr how will those things end up in the vendor toolchains (and in what timeframe) ? Membership in the yoctoWhen working for small companies one can quickly forget that at Intel not everybody talks to each other during the coffee break :-) We are trying to keep things simpleBut Yocto does offer infrastructure to download and build tools via a documented setup. And no, yocto does not give us an SDK on no Linux platforms andI thought there was the possibility to do a Candadian cross via meta-mingw. But never used it so can't say if it would work for the Zephyr toolchain. I am not sure what you mean with ptxdist...www.ptxdist.org is a buildroot-like tool that also used crosstools. It is mainly used in Germany I guess. For the Zephyr developerStill not convinced it is the right way, but since I can not "put my money where my mouth is", I will just accept what ever will be offered. :-) - Erwin
|
|
|
|
Re: ELCE participation
Michael Turquette <mturquette@...>
Hi,
On Thu, Jun 15, 2017 at 7:57 AM, Kumar Gala <kumar.gala@linaro.org> wrote: On 15 June 2017 at 09:08, Geoffrey LE GOURRIERECSome engineers from BayLibre will be there, as usual :-D Best regards, Mike
-- Michael Turquette CEO BayLibre - At the Heart of Embedded Linux http://baylibre.com/
|
|
|
|
Re: Situation with net APIs testing
Paul Sokolovsky
Hello Jukka,
toggle quoted messageShow quoted text
On Thu, 15 Jun 2017 10:46:29 +0300
Jukka Rissanen <jukka.rissanen@linux.intel.com> wrote: [] That explains it, thanks.as part of sanitycheck testsuite! But, 8 tests of tests/net/ haveWhen we had gerrit and jenkins, some of the net tests run slightly [] All other tests programs (24 pieces), that consists of quite manyGreat, thanks for clarifying this. Though I hope you'd agree that seeing such tests as "context" or "tcp" fail does lead to concerns. I will fix the relevant failing tests as they have bit rotted afterNice, thanks for finding time for this! Converting two mqtt tests to not use real qemu [] I see. I may imagine they offer more functionality than just a loopbackOne would think that if we have 22 repetitive implementations ofNo, the interface is not a loopback interface although it might look interface. I also may imagine that each of 22 test device implementations are slightly different to cater for particular testcases. Nothing of that help someone wanting to write a new test unfortunately. How would one know that there's no standard device implementation for dependency-free testing, and having figured that, how one would choose which of 22 cases to use as a template? The loopback support has limited use cases actually and we probablyI absolutely agree that loopback device would be mostly useful for development and testing, not for production. It also offers limited testing indeed. But it has one big advantage: tests using it can be easily run using existing sanitycheck framework. And if loopback device existed in the main code, such tests would be also easy to write, unlike now. Summing up, I'd like to give a try to implement one for the mainline. Well, patches alone won't help here. Writing tests is always hard (forthenI am not sure what kind of mess you mean here but patches are welcome various reasons, including "tests are code, so why not write 'real' code instead?"). So, it would be nice to think how to facilitate that. Specific proposal is to add a loopback netif, I assume it's ok, so will go for a patch. [] Well, it's the same issue: various things in Zephyr are "harder thanthere'sHmm, I missed the point of your last sentence. necessary", so one can never know if something really broke or one doesn't do all the needed things to run it successfully. It would be nice to think of making the default config of Zephyr either run OOB, or fail with clear error messages, not crash or lockup. That's again a big meta-task, not something which can be "fixed with a patch", but would be nice to see if different stakeholders of Zephyr agree that there's an issue which needs attention. Thanks for all the replies! -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
|
|
Re: ELCE participation
Kumar Gala
For the last few years there has been an IOT track at ELCE. Not sure what the plan is this year for that. I know a fair number of Zephyr developers and maintainers have attended in the past. - k
On 15 June 2017 at 09:08, Geoffrey LE GOURRIEREC <geoffrey.legourrierec@...> wrote: Hi all,
|
|
|
|
ELCE participation
Geoffrey LE GOURRIEREC <geoffrey.legourrierec@...>
Hi all,
Not sure if this is the right mailing list for this, but does anybody plan to participate at the Embedded Linux Conference Europe in Prague, this October? If so, what are the subject(s) about to be discussed? Cheers, -- Geoffrey
|
|
|
|
Re: Situation with net APIs testing
Jukka Rissanen
Hi Paul,
On Wed, 2017-06-14 at 18:10 +0300, Paul Sokolovsky wrote: Hello,When we had gerrit and jenkins, some of the net tests run slightly longer that what was desired, so they were marked as build only. Now that situation is different with github and shippable, we can change this. So I will prepare a patch that activates those tests that can be activated. I looked through tests/net what is current status of the tests: ieee802154/crypto * This cannot be run on qemu as it requires suitable hw tcp * Test does not pass, needs fixing mld * Test does not pass, needs fixing ipv6 * Test does not pass, needs fixing lib/mqtt_publisher * Test requires real qemu to run. This needs to be converted lib/mqtt_subscriber * Test requires real qemu to run. This needs to be converted buf * This test runs ok so build_only=true can be removed. all * This is intentional compile test that activates all network config options and tries to compile the binary. The result binary cannot be run mostly because of memory requirements and no suitable test environment. The only issue with this test is that we should remember to add and enable new net config options into this test case. All other tests programs (24 pieces), that consists of quite many individual tests, are run automatically by CI, so the situation is not so bleak as you indicated here. I will fix the relevant failing tests as they have bit rotted after the tests were written. Converting two mqtt tests to not use real qemu requires a bit more work. No, the interface is not a loopback interface although it might look like that. The purpose of the interface that is created in each of the test is to simulate a real network so that we do not have to connect to outside world but the test is self contained. So it kind of looks like a loopback interface but in this case the source and destination IP addresses are not the same (as would be the case with loopback interface), as typically we want to test some real behavior of the system so src/dest addresses should differ. The loopback support has limited use cases actually and we probably need to make that optional (behind Kconfig option) in the code as normally there should be no need to send anything back to itself in the real world. thenI am not sure what kind of mess you mean here but patches are welcome as always to rectify this. Some explanation given above. there'sHmm, I missed the point of your last sentence. Cheers, Jukka
|
|
|
|
Situation with net APIs testing
Paul Sokolovsky
Hello,
As I'm approaching final steps in preparing BSD Sockets patchset for submission, I'm looking into a way to add some tests for it. Testing of networking functionality is by default hard, because in general, networking hardware would be required for that, even if "virtual", like tunslip6, etc. tools from net-tools repo running, to support QEMU networking. During prototyping work, I learnt there're loopback capabilities when binding and connecting to the same netif, but it still requires net-tools running just to get QEMU start up with networking support. Well, I took a look at tests/net and saw the whole bunch of tests, whoa! I gave a try to tests/net/tcp , some cases passed, some failed, hmm. But then I killed net-tools/loop-slip-tab.sh script and the test ran in the same manner. Whoa, so we have means to run networking without any requirements on the host side, which means we can run them as part of sanitycheck testsuite! But, 8 tests of tests/net/ have build_only=true, any wonder they're broken? Anyway, I looked at what's involved in net-tools free running, and figured it's CONFIG_NET_L2_DUMMY. Added it to my sockets test, and got only segfault in return. After debugging it, turned out it's the same issue as already faced by me and other folks: if there're no netifs defined, networking code is going to crash (instead of printing clear error to the user): https://jira.zephyrproject.org/browse/ZEP-2105 But how the tests/net/ run then and don't crash? Here's the answer: zephyr/tests/net$ grep NET_DEVICE -r * | wc 22 42 1532 So, almost each and every test defines its own test interface. One would think that if we have 22 repetitive implementations of test interfaces, whose main purpose is to be just loopback interfaces, then we'd have a loopback interface in the main codebase. But nope, as confirmed by Jukka on IRC, we don't. Summary: 1. Writing networking tests is hard, but it Zephyr, it takes extraordinary, agonizing effort. The most annoying is that all needed pieces are there, but instead of presenting a nice picture, they form a mess which greets you with crashes if you try to change anything. 2. There're existing big (~20K each) test which fail. Apparently, because they aren't run, so bitrot. Why do we need these huge, detailed tests if we don't run them? (An alternative explanation is that there's something wrong with my system, and yep, I'd be glad to know what I'm still don't do right with Zephyr after working on it for a year.) I'd be glad if more experienced developers could confirm if it's really like the above, or I miss something. And I'll be happy to work on the above issues, but in the meantime, I'll need to submit BSD Sockets with rather bare and hard to run (not automated) tests due to the situation above. Thanks, -- Best Regards, Paul Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
|
|
|
|
Zephyr 1.8.0-rc4 tagged
Nashif, Anas
Hi, I just noticed all my previous rc notifications were stuck and not sent out. Sorry about that.
We have just tagged rc4 which is is very close to the final release pending completion of the release notes. If all goes ok with that rc, we will release it as 1.8 in the next 1-2 days.
Changes since rc1 are below…
Adithya Baglody (2): tests: benchmark: app_kernel: Return values from kernel APIs are read. tests: benchmark: Fixed build error from icx toolchain.
Anas Nashif (17): boards: microbit: enable flashing with pyocd Revert "xtools: get rid of warnings about wrong path" doc: remove links to wiki xtools: add new configurations for xtools 1.23 doc: update macOS getting started documentation doc: also require dtc to be installed for linux doc: emphasize usage of MSYS2 MSYS Shell dts: make extract script take options dts: generate definitions for build system release: Zephyr 1.8.0-rc2 Revert "x86: call gen_idt with $ZEPHYR_BASE too" quark_d2000_crb: increase default stack size gitlint: Ignore signed-off-by line release: Tag 1.8.0-rc3 license: add missing licenses and copyright tests: remove obsolete usage of defrag release: Tag 1.8.0-rc4
Andrew Boie (22): bbc_microbit: fix 'make debugserver' arm: implement __svc on Cortex M0 arm: fix k_oops on armv6 with interrupts locked Makefile.toolchain.zephyr: fix C++ on Xtensa samples: restore cpp_synchronization test doc: add interrupt implementation details printk: fix printing of long long types gccarmemb: don't assume 'dtc' is in /usr/bin kernel: fix short time-slice reset schedule_api: don't exclude Nios II nios2: reset timeslice on interrupt-induced swap riscv32: update time slice before swap tests: context: make some failures less ambiguous tests: context: allow 2 ticks of slop sam3x: report correct number of IRQ priority bits frdm_k64f: default to pyocd.sh for flashing/debug stack_sentinel: change cooperative check arches: declare _SysFatalErrorHandler __weak k_oops: force unlock IRQs on ARMv7M tests: fatal: increase coverage stack_sentinel: hang system on failure tests: context: move idle test to the end
Andy Gross (4): Makefile: Add dts config include file doc: Add Device Tree documentation dts: yaml: Add YAML template file scripts: Makefile.lib: Add dependency for DTS overlay
Carles Cufi (6): Bluetooth: controller: Increase RX prio stack size Bluetooth: controller: Conditionally include conn-related options Bluetooth: Consolidate all role configuration build: Fix DTC overlay file paths on MSYS2 doc: getting_started: Add WSL instructions doc: Fill the Bluetooth section in the 1.8 release notes
David B. Kinder (4): doc: fix linenum references in api example doc: starting draft for 1.8 release notes doc: fix misspellings in docs doc: fix board/sample broken links
David Brown (1): dts: Allow override of dts overlay directory
Harry Jiang (2): sensor: lps22hb: fix the pressure sensor fractional value dts: 96b_carbon: Fix the model name and compatible
Inaky Perez-Gonzalez (1): scripts: look for files with no licensing info
Jaganath Kanakkassery (1): Bluetooth: SDP: Fix possible out of bound memory access
Johan Hedberg (4): Bluetooth: AVDTP: Remove dead code Bluetooth: Fix missing test for BLUETOOTH_CONN with DLE Bluetooth: ATT: Fix canceling ATT timeout upon response Bluetooth: L2CAP: Remove redundant checks for chan->ops
John Andersen (1): samples: net: mqtt_publisher: fixed formatting
Jukka Rissanen (31): net: zoap: Fix NULL pointer access tests: net: zoap: Add path uri matching tests net: zoap: Remove extra null checks net: http: Add timeout to HTTP server response sample: net: http: Add Basic auth support to server sample net: Print characters in hexdump net: pkt: Handle out-of-mem case properly net: ipv6: Skip unknown options in NS message net: http: Handle HTTPS connection closing gracefully samples: net: mbedtls_dtlsclient: Fix compile issues samples: net: mbedtls_dtlsclient: Fix testcase.ini samples: net: coaps_client: Fix compile issues samples: net: coaps_client: Fix testcase.ini net: ipv6: Default reassembly timeout set to 5 sec net: ipv6: Memory leak during fragment reassembly net: ipv6: Fix the IPv6 packet fragmentation sending net: ipv6: Fix fragmentation cancellation net: ipv6: Make max number of fragmented pkt configurable tests: net: ipv6: Test IPv6 fragmentation sending net: shell: Enhance IPv6 fragmentation debugging prints net: http: Parsing state was not cleared samples: net: zperf: Fix llvm compiler warnings samples: net: dtls_client: Fix Coverity warning samples: net: http_client: Increase the number of buffers net: http: Use random source port when connecting net: http: Avoid unnecessary net_pkt error print net: tcp: Timeout memory allocations net: https: Allow mbedtls debugging for https-server samples: net: Fix README.rst file documentation net: tcp: Check pkt before sending RESET doc: Add networking changes to 1.8 release note
Justin Watson (3): arch: arm: Fix SoC issues with Atmel SAM4S series. boards: arm: Added doc. image for the SAM E70 Xplained. boards: arm: arduino_due: Added doc. image for the Arduino Due.
Kumar Gala (1): toolchain.gccarmemb: Fix support for where to find newlib
Leandro Pereira (6): drivers: spi_mcux_dspi: Fix unlikely but possible division by zero tests: clock: Initialize d64 value ieee802154_shell: Only accept channels within expected range samples: mqtt_publisher: Try connecting a few times before giving up net: tcp: Limit number of segment retransmissions samples: dns_resolve: Clarify documentation about DNS configuration
Luiz Augusto von Dentz (3): net: shell: Move SHELL_REGISTER out of net_shell_init net: shell: Remove extra help command Bluetooth: GATT: Fix not queuing writes to CCC
Marti Bolivar (5): stack.h: add missing include guard lib: json: fix JSON_OBJ_DESCR_ARRAY Doxygen example tests: json: fix sense of test result string lib: json: add JSON_OBJ_DESCR_*_NAMED variants tests: json: test JSON_OBJ_DESCR_*_NAMED
Maureen Helm (1): arm: nxp: mpu: Return constant number of mpu regions
Michael Scott (3): arm: soc: nordic nRF52: Add MPU support arm: soc: nxp k6x: mpu: clarify magic numbers for UM/SM defines arm: soc: nxp k6x: mpu: add Bus Master 3 User Mode access bits
Patrik Flykt (1): zoap: Include net/net_ip.h when sockaddr is used
Paul Sokolovsky (6): subsys: console: Fix signed vs unsigned char issues. drivers/ethernet/eth_mcux: Fix extra PHY debug Kconfig name. tests: net: ipv6: Fix possible NULL pointer dereference behind a macro drivers/ethernet/eth_mcux: Fix selection of promisc mode IPv6 workaround drivers: serial: Clarification for uart_fifo_fill()/read() calls net: context: Operations on unused context should lead to EBADF.
Piotr Mienkowski (1): watchdog: atmel_sam: enable build for all SAM family
Ravi kumar Veeramally (2): net: rpl: Update RPL header net: 6lo: Fix source address uncompression
Sharron LIU (4): tests: kernel: added tests for timeslice reset tests: kernel: added tests for k_mem_pool_alloc from isr samples: fixed typo in README.rst samples: static_lib: conditional assign BOARD (?=)
Tomasz Bursztyka (1): api/spi: Change transceive functions signature
Vinayak Kariappa Chettimada (7): Bluetooth: controller: Fix DLE crossover assert Bluetooth: controller: Handle Rej Ext Ind for Length Req PDU Bluetooth: Auto-update LE data length to max. supported Bluetooth: controller: Fix CSA#2 assert Bluetooth: controller: Fix failing fast encryption setup feature drivers: timer: Fix nRF RTC timer _timer_cycle_get_32 arch: arm: Fix compile error on ARMv6-M SoCs with TICKLESS_KERNEL
Vincenzo Frascino (1): arm: core: mpu: Add core support to NXP MPU
chunlin (1): arm: core: mpu: Prevent updating unexpected region
ruuddw (1): Create release-notes-1.8.rst
Thanks, Anas
|
|
|
|
Re: sdk-ng
Nashif, Anas
Erwin,
toggle quoted messageShow quoted text
The experience should be the same as with the current SDK. I did not say anything about downloading IDEs and from various vendors. There are well-established, standalone toolchains available that are better supported than what we have in the current SDK. Membership in the yocto project is really not a factor here. We are trying to keep things simple and remove the burden of having to maintain toolchains as part of the project. Believe it or not, the Zephyr SDK is also a one man show, yocto being a tool here that has nothing to do with the content of the SDK itself. And no, yocto does not give us an SDK on no Linux platforms and I am not sure what you mean with ptxdist... For the Zephyr developer just like with the current SDK it will be a downloadable file that installs some toolchains, in other cases it will download toolchains maintained by vendors like ARM, Intel and Synopsys etc. Anas
-----Original Message-----
From: Erwin Rol [mailto:mailinglists@erwinrol.com] Sent: Tuesday, June 13, 2017 9:44 PM To: Nashif, Anas <anas.nashif@intel.com>; zephyr-devel <zephyr-devel@lists.zephyrproject.org> Subject: Re: [Zephyr-devel] sdk-ng Hey Anas, thanks for the explanation, I just wondered because Intel, Linaro, the Linux Foundation, etc. all seem Yocto members, where crosstools-ng seems to be pretty much a one-man-show (looking at the github commits). On 14-6-2017 2:11, Nashif, Anas wrote: The current SDK is very difficult to maintain, requires lots ofAnd crosstools-ng is easier? Looking at ptxdist (which I already use for years) there is still a lot of tuning needed. Same with RTEMS, they also seem to put a lot of effort in toolchain maintenance and tuning, especially integration with newlib. And what about tools like openocd, they aren't part of crosstools-ng, are they? and is not compatible with how crosstool compilers from vendors areIn what way "not compatible"? Aren't most vendors distributing some huge (eclipse)IDE with some GCC deep inside? (I am thinking about things like AC6, Atmel-Studio, etc.) Is there any "general" way to distribute a toolchain? There are a few other issues, forIsn't Yocto capable to build SDK/toolchains that can run on Windows, Mac and Linux? Another things is portability, try moving binaries around, this failsThat sounds a bit like a non-issue to me. Most big software packages can not be moved around. Of course others might have usecases where being able to move around the binaries is useful. All in all, we are trying toMy experience is that those vendors are in the business of selling chips, and most software that comes from them is terrible. Look at the AVR32 support from Atmel, they proudly present a GCC 4.4.X (http://distribute.atmel.no/tools/opensource/Atmel-AVR32-GNU-Toolchain/3.4.3/) in the form of patches that apparently no GCC developer wants to touch. And from a user point of view, I thought it was very easy to download and install the Zephyr toolchains, and get to work with them. I would hate to have some readme.txt explaining to me I have to install 1 toolchain from Atmel, 1 from ST, 1 from Intel, all with different GUI installers (of course we want point-and-click) and all with their own huge (eclipse) IDE. - Erwin
|
|
|
|
Re: sdk-ng
Erwin Rol
Hey Anas,
thanks for the explanation, I just wondered because Intel, Linaro, the Linux Foundation, etc. all seem Yocto members, where crosstools-ng seems to be pretty much a one-man-show (looking at the github commits). On 14-6-2017 2:11, Nashif, Anas wrote: The current SDK is very difficult to maintain, requires lots ofAnd crosstools-ng is easier? Looking at ptxdist (which I already use for years) there is still a lot of tuning needed. Same with RTEMS, they also seem to put a lot of effort in toolchain maintenance and tuning, especially integration with newlib. And what about tools like openocd, they aren't part of crosstools-ng, are they? and is not compatible with how crosstool compilersIn what way "not compatible"? Aren't most vendors distributing some huge (eclipse)IDE with some GCC deep inside? (I am thinking about things like AC6, Atmel-Studio, etc.) Is there any "general" way to distribute a toolchain? There are a few other issues, forIsn't Yocto capable to build SDK/toolchains that can run on Windows, Mac and Linux? Another things is portability, try moving binariesThat sounds a bit like a non-issue to me. Most big software packages can not be moved around. Of course others might have usecases where being able to move around the binaries is useful. All in all, we are trying toMy experience is that those vendors are in the business of selling chips, and most software that comes from them is terrible. Look at the AVR32 support from Atmel, they proudly present a GCC 4.4.X (http://distribute.atmel.no/tools/opensource/Atmel-AVR32-GNU-Toolchain/3.4.3/) in the form of patches that apparently no GCC developer wants to touch. And from a user point of view, I thought it was very easy to download and install the Zephyr toolchains, and get to work with them. I would hate to have some readme.txt explaining to me I have to install 1 toolchain from Atmel, 1 from ST, 1 from Intel, all with different GUI installers (of course we want point-and-click) and all with their own huge (eclipse) IDE. - Erwin
|
|
|
|
Re: sdk-ng
Nashif, Anas
The current SDK is very difficult to maintain, requires lots of resources to build and is not compatible with how crosstool compilers from vendors are being distributed. There are a few other issues, for example it is only available on Linux, crosstools-ng gives us support for the Mac as well. Another things is portability, try moving binaries around, this fails with the current SDK. All in all, we are trying to make it simpler and easier to maintain and we want to rely on vendor toolchains rather than build everything ourselves in one giant blob and then have to support it. We are not in the toolchain business, we want to leave this to the experts and rely on recipes that are simple that the way it is right now.
toggle quoted messageShow quoted text
Anas
-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Erwin Rol Sent: Tuesday, June 13, 2017 7:21 PM To: zephyr-devel <zephyr-devel@lists.zephyrproject.org> Subject: [Zephyr-devel] sdk-ng Hey All, when going over the 1.9 plans I noticed "sdk-ng". When looking into the "sdk-ng" repo I noticed switching from yocto to crosstools-ng. One question; why ? - Erwin _______________________________________________ Zephyr-devel mailing list Zephyr-devel@lists.zephyrproject.org https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
|
|
|