Re: [RFC] Provide a generic interface for getting the SOC ID and version


Nashif, Anas
 

Did not expect this to generate such a big discussion. Here is a use case in addition to what was mentioned in the thread below. Think of this API as a helper API for higher lever features and not a way to select/deselect features based on HW.

Depending on the HW/MCU being used, getting the hardware information such as model number, vendor ID, hardware revision might vary in complexity so implementing this for supported SOCs makes a lot of sense using an API that can be used by applications and higher level features such as IOT protocols. Originally this ZEP was created to prepare for LWM2M and specifically the device profile:

http://dev_devtoolkit.openmobilealliance.org/IoT/LWM2M10/doc/TS/index.html#!Documents/lwm2mobjectdevice.htm

To prepare for the implementation of the profile and to avoid implementing this for the various MCUs in different places where it can be used, the API was proposed.

Feeding this type of data at build time is always an option, but I do not think it makes sense in this case and especially when the HW has lots of information stored already that would make it very difficult to fill in at build time. Doing this at build time will encourage developers and users to enter random data and things like TODO or XYZ all over the place, just to get their app to build and move on. Why bother if the data is already provided by the hardware?

Uniqueness of the data is not key here, multiple boards of the same HW might end up generating the same ID, however, this depends on the hardware and some cases such data can be combined with other sources to achieve this.


Anas

On 29/07/2016, 23:48, "Kumar Gala" <kumar.gala(a)linaro.org> wrote:

If what you are talking about is really for errata than I think we should solve that specific problem. I think a combination of a consistent #define naming and usage convention:

#define CONFIG_ERRATUM_<VENDOR_NAME>_<CHIP>_<VND/CHIP SPECIFIC ERRATUM DESC>

For cases that could be handled at compile time. Than for runtime cases:

Something like:

bool has_erratum(enum erratum_list e).

where erratum_list can be defined in some SoC specific header and code to report if the given erratum is valid on the given chip.

Also, for what you describe, only the revision info is need so at most we’d have an internal API like:
uint32_t __get_soc_revision(void)

- k

> On Jul 28, 2016, at 11:01 AM, Vij, Gajinder S <gajinder.s.vij(a)intel.com> wrote:
>
> I'm confused as to what you mean by using features. Do you mean major silicon features such as different Cache size or different HW acceleration blocks? These would likely be a major rev of the silicon which would warrant a new binary. Also, how are silicon features determined without reading the underlying SOC version?
>
> The origin of the request for the API is for a very specific scenario. When SOC vendors bring up new silicon, there are often multiple revisions of silicon available to the dev/test team before the chip is commercially available. Early versions of the silicon invariably have hardware bugs and the driver SW needs to compensate. As new iterations of the silicon are available to the dev/test team, either run-time detection is used to apply/disable the HW work-arounds, or the older HW boards become deadweight. This has significant cost and efficiency implications. This API is intended to be used at a very low level to allow drivers to enable/disable HW work-arounds. Having the API in the kernel saves the dev team from deriving their own API. I've seen scenarios where different component teams on the same project each implement their own SOC version detection scheme for this purpose.
>
> The API is not intended for use by applications, and is not intended to distinguish between major chipset releases (example, not intended to distinguish between 384 vs a 486, or a Cortex M0 vs a Cortex M4). I'm still confused as to why a developer go through the trouble to have a single binary that runs on significantly different systems. This would be an inefficient use of FLASH and Memory, unnecessarily increasing cost of the end device.
>
> I maintain that if an OEM picks up new silicon that has additional functionality, there will be a new HW board to enable new features/sensors, a new display etc. The OEM will naturally go through the process to create a separate binary. They may decide to use the same code-base to create multiple binaries, but that will be at compile-time, and won't require run-time detection to distinguish code-paths. It is _more_ work to create a single binary that runs on multiple HW SKUs, and a _lot more_ work to create a single binary that runs on two platforms that are significantly different.
>
> Can you provide an example of an API that would provide feature level granularity?
>
> Thanks,
> Gajinder
>
>
>
> -----Original Message-----
> From: Kumar Gala [mailto:kumar.gala(a)linaro.org]
> Sent: Thursday, July 28, 2016 6:25 AM
> To: Vij, Gajinder S <gajinder.s.vij(a)intel.com>
> Cc: Morgaine <morgaine.dinova(a)googlemail.com>; devel(a)lists.zephyrproject.org
> Subject: Re: [devel] [RFC] Provide a generic interface for getting the SOC ID and version
>
> The use case you specify of picking SOC-version-specific code at run-time should be using features and not an ID for determining such things. This goes directly to Tixy’s email thread which I agree with 100%.
>
> - k
>
>> On Jul 22, 2016, at 8:02 PM, Vij, Gajinder S <gajinder.s.vij(a)intel.com> wrote:
>>
>> There is a clear use case for the API, as articulated by Morgaine and Pedro (included below). The purpose of the API is to provide the mechanism for a developer to be able to select SOC-version-specific code paths at run-time, reducing the need for a custom image per SOC version. When and if version specific code is used depends on the circumstances and should be left to the developer as a policy decision.
>>
>> I’d like to determine if there is still objections to this API being implemented in Zephyr. I read through the thread and will attempt to address the concerns raised.
>>
>> On the concerns articulated by Tixy, since the App, Kernel, and BSP are all compiled from source into a single binary, I don’t see the same app compatibility issues cropping up in a Zephyr scenario that have come up in Linux. It is conceivable that someone may attempt to use the SOC version as a way to distinguish between different variants of a product family, but that would be an inappropriate use of the API.
>>
>> I don’t know where the notion of using this API as an entropy source came from. I have removed this from the Jira description.
>>
>> To the question about forward support and uniqueness of the IDs – should this happen on different architectures, I don’t see a problem because I expect the BSPs will still be unique, and therefore I don’t expect a binary run on one platform to successfully be run on another.
>>
>> Comments welcome.
>>
>> Thanks,
>> Gajinder
>>
>>
>> Pedro’s use case:
>> Ø The user might know the SOC ID at compile time (although a user might want to check against the hardware in case of doubt).
>> Ø The SOC revision can change between hardware stepping, so the user might not know at compile time the version of a given model.
>> Ø In that case reading the hardware registers is the only way to know the revision.
>>
>> Morgaine’s use case:
>> Ø This API creates a 1:N relationship between compiled firmware and target behaviour. In other words it allows target behaviour to be parametrized by some target identifier in a standard way given by the API, without requiring each different target to be loaded with different firmware.
>>
>>
>>
>> From: Morgaine [mailto:morgaine.dinova(a)googlemail.com]
>> Sent: Thursday, July 21, 2016 10:27 AM
>> To: devel(a)lists.zephyrproject.org
>> Subject: [devel] Re: [RFC] Provide a generic interface for getting the SOC ID and version
>>
>> Kumar writes:
>>> So I ask again, what are we trying to accomplish?
>>
>> See my preceding reply, which explored exactly that question.
>>
>> From the original requirement expressed in the RFC and from Tixy's subsequent comments, it's clear that there are at least two distinct purposes in people's minds: the one mentioned in the RFC which required uniqueness for generating unique per-target data, and another purpose related to feature sets. It was noted that the second of these is somewhat problematic.
>>
>> My interest is in the simpler of these, the requirement expressed in the RFC, because it is such a common need. Someone else will have to argue in favour of the other if they feel it's important. The two could of course be combined if the agreed data width permits.
>>
>> Morgaine.
>>
>

Join devel@lists.zephyrproject.org to automatically receive all group messages.