Hi Maciek,
toggle quoted messageShow quoted text
-----Original Message----- From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com] Sent: Wednesday, April 20, 2016 22:10 To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no> Cc: Nashif, Anas <anas.nashif(a)intel.com>; devel(a)lists.zephyrproject.org Subject: Re: [devel] Re: Using IC manufacturer header files
On Wed, Apr 20, 2016 at 9:28 PM, Cufi, Carles <Carles.Cufi(a)nordicsemi.no> wrote:
Hi Maciek,
-----Original Message----- From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com] Sent: Wednesday, April 20, 2016 19:24 To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no> Cc: Nashif, Anas <anas.nashif(a)intel.com>; devel(a)lists.zephyrproject.org Subject: Re: [devel] Re: Using IC manufacturer header files
On Tue, Apr 19, 2016 at 10:50 PM, Cufi, Carles <Carles.Cufi(a)nordicsemi.no> wrote:
Hi Maciek,
-----Original Message----- From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com] Sent: Tuesday, April 19, 2016 17:27 To: Nashif, Anas <anas.nashif(a)intel.com> Cc: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>; devel(a)lists.zephyrproject.org Subject: Re: [devel] Re: Using IC manufacturer header files
On Tue, Apr 19, 2016 at 5:04 PM, Nashif, Anas <anas.nashif(a)intel.com> wrote:
Hi, Any files or headers included from an external project that need to be kept in sync with upstream can keep their style and formatting to allow updates in the future. This was the approach taken when we imported the IP stack from contiki AFAIK.
How about keeping the library/headers external and passing their location in Kconfig? Similar to what buildroot does with external kernel/toolchains. Is that acceptable too? Not sure if you mean pulling the source code from another repository at build time, since I don't know what buildroot does with kernel/toolchains.
However the MDK is not currently available in a repository, instead it is released as a .zip file by Nordic every time it gets updated. We could of course mirror it in a repo, but that would anyway require us to update it manually every time a new version is available.
What I meant is that you keep the {S,M}DK externally and just configure a path to it inside Kconfig. You can add a config entry like CONFIG_STM32F1_STDLIB_PATH. Then in project/driver makefiles -I$(CONFIG_STM32F1_STDLIB_PATH) and optionally add some files to the build as needed. This has one major advantage, that the 3rd party code is kept outside of Zephyr repository, so you basically don't care about the naming/conventions/licenses 3rd party libraries would use.
I couldn't find the CONFIG_STM32F1_STDLIB_PATH you mentioned, and I tried to build the "hello_world" sample for STM32 and it worked fine, even though I have no STM SDK installed at all.
Right, but only because the implementation was done in such way. Frankly, if I used ST's libraries, it would have saved me a lot of time during porting. Instead, I followed the example set by other, already supported, targets and implemented STM32 specific pieces from scratch by looking at the CPU manuals only.
With that I mean that it looks like, so far, archs are self-contained. The problem with the "-I$(NORDIC_MDK_PATH)" approach is that, as you mention later, Nordic might change the folder structure of the .zip file that it provides, rename some files and change it completely, leaving us at the mercy of the vendor.
As for mirroring 3rd party SDK in a repo. No matter the vendor's distribution method I always pull the source code into a git repository for two main reasons: By pulling into the repo I assume you mean actually duplicating the files inside the target repo, instead of "pulling" them from an external repo.
- I don't trust vendors to have a reasonable release management (more often than not they prove to have none) Agreed, see point above. Sometimes there's legitimate reasons to change the structure of the SDK provided by a vendor, but the OS build shouldn't be affected by it. Furthermore, relying on a particular version could potentially then introduce dependency hell into the Zephyr build for certain architectures, where some users would start to complain that the OS doesn't build for a particular IC because they have an older (or newer) IC vendor SDK than the one that Zephyr depends on.
I understand that it's nicer from user's perspective that the CPU support is integrated into the main codebase. I'm just not sure if it will be possible to maintain this state in the long run. Integrating code from a 3rd party into the main codebase means that we've officially made maintaining compatibility our problem. While, this is ok to do it with IP stack from contiki, it's just one 3rd party project after all, it will be hard with the multitude of CPUs out there. Well the only alternatives to directly integrating IC manufacturer header files into the Zephyr repo that I can conceive are: 1) Maintain the manufacturer files in a separate repository that we somehow (submodule or repo) pull into the build 2) Require the user to pre-install those header files as a dependency to be able to build for a particular architecture 3) Re-implement all the functionality provided by those IC manufacturer header files in our own style and inside the Zephyr repo I personally dislike 1) and 2) for the reasons I've already exposed in previous emails, so for me the only real alternative is 3). But let's remember that we are talking about header files that describe SoCs here, not specific libraries a version of which we maintain internally. Those header files reflect the register set and the memory map of the SoC, and for that reason they tend to be accurate and well-tested since they have been used to develop the source examples that IC manufacturers already provide in their SDKs. That is yet another reason for me to advocate for the usage of these files unchanged and integrated in our repository. Furthermore, SoCs do not tend to change often (they are hardware descriptions after all) and therefore maintaining them internally should not be too onerous. I know it sounds crazy, but OpenEmbedded BSP layers are not that bad to work with after all. I can imagine that having similar BSP layers for Zephyr would not be that complicated. These 'layers', maintained by community or interested parties, could provide a curated hardware enablement or support libraries.
This goes beyond the scope of the work we are trying to do here I believe. For now we want to add support for an architecture, and establishing a layer system for SoC support is not something we have contemplated so far. Thanks, Carles
|