-----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