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


Liu, Baohong
 

Hi,

There can be a need to provide a generic interface API for getting the SOC ID, version, and
other identifying data. These data can be useful for an application to use to generate
unique Information (for example, MAC addresses).

This is based on ZEP-235.

Proposed Interface
***************

/**
* @brief Read SoC id
*
* @retval soc id. The information is SoC specific.
*/
static uint32_t soc_id_get(void);

For example, on Quark SE, this would return the value from the SCSS identification register.
On ARM based SOC, for example Atmel sam3, this would be the chip id from the id code
register.

/**
* @brief Read soc version
*
* @retval soc version. A platform dependent 32 bit version information.
*/
static uint32_t soc_version_get(void);

Depending on the SoC, this can include different types of version information for example,
SOC version, major, and minor revision numbers, etc.

For example, for Quark SE, this would be the rev number from the SCSS rev register.
For ARM based SOC, for example Atmel sam3, this will be the version value from id code
register.

Welcome feedback/comments or any concerns.

Thanks,
Baohong


Boie, Andrew P
 

There can be a need to provide a generic interface API for getting the SOC ID,
version, and other identifying data. These data can be useful for an
application to use to generate unique Information (for example, MAC
addresses).
Hi Baohong,

Can you give a little more detail about use-cases? Seems like the information being queried is not unique per-device data but identification values for the HW.
In Zephyr pretty much everything is known at build time, so I would to learn more about why we think we need runtime support for this.


Regards,
Andrew


Liu, Baohong
 

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Thursday, July 14, 2016 10:50 PM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID and
version

There can be a need to provide a generic interface API for getting the SOC
ID,
version, and other identifying data. These data can be useful for an
application to use to generate unique Information (for example, MAC
addresses).
Hi Baohong,

Can you give a little more detail about use-cases? Seems like the information
being queried is not unique per-device data but identification values for the
HW.
In Zephyr pretty much everything is known at build time, so I would to learn
more about why we think we need runtime support for this.
Good questions. My understanding the main idea is the scalability on reading
these information from registers at run time vs. hardcoding them at build time.

The MAC case mentioned may be a bit confusing (but if it in fact was a usage,
it should also reply on additional information, not just using only SoC id or rev
number in deriving a unique MAC, as you pointed out).



Regards,
Andrew


Boie, Andrew P
 

Good questions. My understanding the main idea is the scalability on
reading these information from registers at run time vs. hardcoding them
at build time.
Scalability across HW with the same binary is not one of Zephyr's goals. We really try to do everything at build time to make the OS as small and fast as possible. This is why dynamic interrupts were removed, for example.

So given a choice between doing something at runtime or coding it at build time, to date the preference has been for the latter.

Andrew


Liu, Baohong
 

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Friday, July 15, 2016 10:56 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID and
version

Good questions. My understanding the main idea is the scalability on
reading these information from registers at run time vs. hardcoding them
at build time.
Scalability across HW with the same binary is not one of Zephyr's goals. We
really try to do everything at build time to make the OS as small and fast as
possible. This is why dynamic interrupts were removed, for example.

So given a choice between doing something at runtime or coding it at build
time, to date the preference has been for the latter.
Actually that's not what this API meant to achieve. Some confusion in the text;
the purpose is to provide a generic API for retrieving this information. How the information
is obtained is implementation detail and in fact, As much possible should be build time
decided as you pointe it out.


Andrew


Kumar Gala
 

On Jul 15, 2016, at 1:50 PM, Liu, Baohong <baohong.liu(a)intel.com> wrote:

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Friday, July 15, 2016 10:56 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID and
version

Good questions. My understanding the main idea is the scalability on
reading these information from registers at run time vs. hardcoding them
at build time.
Scalability across HW with the same binary is not one of Zephyr's goals. We
really try to do everything at build time to make the OS as small and fast as
possible. This is why dynamic interrupts were removed, for example.

So given a choice between doing something at runtime or coding it at build
time, to date the preference has been for the latter.
Actually that's not what this API meant to achieve. Some confusion in the text;
the purpose is to provide a generic API for retrieving this information. How the information
is obtained is implementation detail and in fact, As much possible should be build time
decided as you pointe it out.
I think the application of this API needs to be much clearer. What use cases are their from the application side?

- k


Boie, Andrew P
 

On Fri, 2016-07-15 at 18:50 +0000, Liu, Baohong wrote:
 
Actually that's not what this API meant to achieve. Some confusion in
the text;
the purpose is to provide a generic API for retrieving this
information. How the information
is obtained is implementation detail and in fact, As much possible
should be build time
decided as you pointe it out.
Since we've established we should do this at build time, why not make
this a Kconfig or some other #define instead of adding C code which
will add to the footprint?

Andrew


Liu, Baohong
 

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Friday, July 15, 2016 3:41 PM
To: devel(a)lists.zephyrproject.org; Liu, Baohong <baohong.liu(a)intel.com>
Subject: Re: [RFC] Provide a generic interface for getting the SOC ID and
version

On Fri, 2016-07-15 at 18:50 +0000, Liu, Baohong wrote:

Actually that's not what this API meant to achieve. Some confusion in
the text;
the purpose is to provide a generic API for retrieving this
information. How the information
is obtained is implementation detail and in fact, As much possible
should be build time
decided as you pointe it out.
Since we've established we should do this at build time, why not make
this a Kconfig or some other #define instead of adding C code which
will add to the footprint?
Yes, the implementation should be through #define.

As the requirement from the ZEP is to get this information from a HAL (e.g QMSI), we
can require HAL does this using #define. (current QMSI implements this as C function
though so that requires it changed to fit this requirement).

Andrew


Liu, Baohong
 

Thanks for the feedback.

I summarized the updated RFC with the feedback.

The SoC id and revision information would be using #define which would be SoC specific value.

/* This defines the SoC id */
#define SOC_ID XXXX

/* This defines SoC revision information. */
#define SOC_REV YYYY

Depending on the SoC, this can include different types of version Information.

If there is other feedback, please let me know and I can incorporate.

-----Original Message-----
From: Liu, Baohong
Sent: Friday, July 15, 2016 4:40 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID and
version

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Friday, July 15, 2016 3:41 PM
To: devel(a)lists.zephyrproject.org; Liu, Baohong
<baohong.liu(a)intel.com>
Subject: Re: [RFC] Provide a generic interface for getting the SOC ID
and version

On Fri, 2016-07-15 at 18:50 +0000, Liu, Baohong wrote:

Actually that's not what this API meant to achieve. Some confusion
in the text; the purpose is to provide a generic API for retrieving
this information. How the information is obtained is implementation
detail and in fact, As much possible should be build time decided as
you pointe it out.
Since we've established we should do this at build time, why not make
this a Kconfig or some other #define instead of adding C code which
will add to the footprint?
Yes, the implementation should be through #define.

As the requirement from the ZEP is to get this information from a HAL (e.g
QMSI), we can require HAL does this using #define. (current QMSI
implements this as C function though so that requires it changed to fit this
requirement).

Andrew


Liu, Baohong
 

Hi, Kumar,

-----Original Message-----
From: Kumar Gala [mailto:kumar.gala(a)linaro.org]
Sent: Friday, July 15, 2016 3:18 PM
To: Liu, Baohong <baohong.liu(a)intel.com>
Cc: Boie, Andrew P <andrew.p.boie(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] [RFC] Provide a generic interface for getting the SOC ID
and version


On Jul 15, 2016, at 1:50 PM, Liu, Baohong <baohong.liu(a)intel.com> wrote:

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Friday, July 15, 2016 10:56 AM
To: Liu, Baohong <baohong.liu(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID
and version

Good questions. My understanding the main idea is the scalability on
reading these information from registers at run time vs. hardcoding
them at build time.
Scalability across HW with the same binary is not one of Zephyr's
goals. We really try to do everything at build time to make the OS as
small and fast as possible. This is why dynamic interrupts were removed,
for example.

So given a choice between doing something at runtime or coding it at
build time, to date the preference has been for the latter.
Actually that's not what this API meant to achieve. Some confusion in
the text; the purpose is to provide a generic API for retrieving this
information. How the information is obtained is implementation detail
and in fact, As much possible should be build time decided as you pointe it
out.

I think the application of this API needs to be much clearer. What use cases
are their from the application side?
Current ZEP does not call out other usage. The updated RFC would provide a common
Definition for all future usage.


- k


Morales Romero, Pedro <pedro.morales.romero@...>
 

Hi all,

The user might know the SOC ID at compile time (although a user might want to check against the hardware in case of doubt).
In that case we define the QUARK_D2000 and QUARK_SE via #define symbols.

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.

Cheers,
Pedro

-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Monday, July 18, 2016 11:51 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Provide a generic interface for getting the SOC ID and version

Thanks for the feedback.

I summarized the updated RFC with the feedback.

The SoC id and revision information would be using #define which would be SoC specific value.

/* This defines the SoC id */
#define SOC_ID XXXX

/* This defines SoC revision information. */
#define SOC_REV YYYY

Depending on the SoC, this can include different types of version Information.

If there is other feedback, please let me know and I can incorporate.

-----Original Message-----
From: Liu, Baohong
Sent: Friday, July 15, 2016 4:40 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID
and version

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Friday, July 15, 2016 3:41 PM
To: devel(a)lists.zephyrproject.org; Liu, Baohong
<baohong.liu(a)intel.com>
Subject: Re: [RFC] Provide a generic interface for getting the SOC
ID and version

On Fri, 2016-07-15 at 18:50 +0000, Liu, Baohong wrote:

Actually that's not what this API meant to achieve. Some confusion
in the text; the purpose is to provide a generic API for
retrieving this information. How the information is obtained is
implementation detail and in fact, As much possible should be
build time decided as you pointe it out.
Since we've established we should do this at build time, why not
make this a Kconfig or some other #define instead of adding C code
which will add to the footprint?
Yes, the implementation should be through #define.

As the requirement from the ZEP is to get this information from a HAL
(e.g QMSI), we can require HAL does this using #define. (current QMSI
implements this as C function though so that requires it changed to
fit this requirement).

Andrew
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.


Liu, Baohong
 

Hi Pedro,

-----Original Message-----
From: Morales Romero, Pedro
Sent: Tuesday, July 19, 2016 2:23 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; Boie, Andrew P
<andrew.p.boie(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID and
version

Hi all,

The user might know the SOC ID at compile time (although a user might want
to check against the hardware in case of doubt).
In that case we define the QUARK_D2000 and QUARK_SE via #define
symbols.

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.
Good point. If different stepping can have different revision, seems like the #define
method would need a configuration flag to distinguish the stepping within the SOC
which may not be preferable?

Cheers,
Pedro


-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Monday, July 18, 2016 11:51 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Provide a generic interface for getting the SOC ID
and version

Thanks for the feedback.

I summarized the updated RFC with the feedback.

The SoC id and revision information would be using #define which would be
SoC specific value.

/* This defines the SoC id */
#define SOC_ID XXXX

/* This defines SoC revision information. */
#define SOC_REV YYYY

Depending on the SoC, this can include different types of version
Information.

If there is other feedback, please let me know and I can incorporate.

-----Original Message-----
From: Liu, Baohong
Sent: Friday, July 15, 2016 4:40 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID
and version

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Friday, July 15, 2016 3:41 PM
To: devel(a)lists.zephyrproject.org; Liu, Baohong
<baohong.liu(a)intel.com>
Subject: Re: [RFC] Provide a generic interface for getting the SOC
ID and version

On Fri, 2016-07-15 at 18:50 +0000, Liu, Baohong wrote:

Actually that's not what this API meant to achieve. Some confusion
in the text; the purpose is to provide a generic API for
retrieving this information. How the information is obtained is
implementation detail and in fact, As much possible should be
build time decided as you pointe it out.
Since we've established we should do this at build time, why not
make this a Kconfig or some other #define instead of adding C code
which will add to the footprint?
Yes, the implementation should be through #define.

As the requirement from the ZEP is to get this information from a HAL
(e.g QMSI), we can require HAL does this using #define. (current QMSI
implements this as C function though so that requires it changed to
fit this requirement).

Andrew


Thomas, Ramesh
 

On 07/19/2016 12:15 PM, Liu, Baohong wrote:
Hi Pedro,

-----Original Message-----
From: Morales Romero, Pedro
Sent: Tuesday, July 19, 2016 2:23 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; Boie, Andrew P
<andrew.p.boie(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID and
version

Hi all,

The user might know the SOC ID at compile time (although a user might want
to check against the hardware in case of doubt).
In that case we define the QUARK_D2000 and QUARK_SE via #define
symbols.

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.
Good point. If different stepping can have different revision, seems like the #define
method would need a configuration flag to distinguish the stepping within the SOC
which may not be preferable?
Is there a specific requirement for the revision id? Is SOC ID enough to
meet the requirement?


Cheers,
Pedro


-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Monday, July 18, 2016 11:51 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Provide a generic interface for getting the SOC ID
and version

Thanks for the feedback.

I summarized the updated RFC with the feedback.

The SoC id and revision information would be using #define which would be
SoC specific value.

/* This defines the SoC id */
#define SOC_ID XXXX

/* This defines SoC revision information. */
#define SOC_REV YYYY

Depending on the SoC, this can include different types of version
Information.

If there is other feedback, please let me know and I can incorporate.

-----Original Message-----
From: Liu, Baohong
Sent: Friday, July 15, 2016 4:40 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID
and version

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Friday, July 15, 2016 3:41 PM
To: devel(a)lists.zephyrproject.org; Liu, Baohong
<baohong.liu(a)intel.com>
Subject: Re: [RFC] Provide a generic interface for getting the SOC
ID and version

On Fri, 2016-07-15 at 18:50 +0000, Liu, Baohong wrote:

Actually that's not what this API meant to achieve. Some confusion
in the text; the purpose is to provide a generic API for
retrieving this information. How the information is obtained is
implementation detail and in fact, As much possible should be
build time decided as you pointe it out.
Since we've established we should do this at build time, why not
make this a Kconfig or some other #define instead of adding C code
which will add to the footprint?
Yes, the implementation should be through #define.

As the requirement from the ZEP is to get this information from a HAL
(e.g QMSI), we can require HAL does this using #define. (current QMSI
implements this as C function though so that requires it changed to
fit this requirement).

Andrew


Liu, Baohong
 

-----Original Message-----
From: Ramesh Thomas [mailto:ramesh.thomas(a)intel.com]
Sent: Tuesday, July 19, 2016 1:05 PM
To: devel(a)lists.zephyrproject.org
Subject: [devel] Re: Re: [RFC] Provide a generic interface for getting the SOC
ID and version



On 07/19/2016 12:15 PM, Liu, Baohong wrote:
Hi Pedro,

-----Original Message-----
From: Morales Romero, Pedro
Sent: Tuesday, July 19, 2016 2:23 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; Boie, Andrew P
<andrew.p.boie(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID
and version

Hi all,

The user might know the SOC ID at compile time (although a user might
want to check against the hardware in case of doubt).
In that case we define the QUARK_D2000 and QUARK_SE via #define
symbols.

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.
Good point. If different stepping can have different revision, seems
like the #define method would need a configuration flag to distinguish
the stepping within the SOC which may not be preferable?
Is there a specific requirement for the revision id? Is SOC ID enough to meet
the requirement?
This is from the ZEP.
The information they carry are different.


Cheers,
Pedro


-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Monday, July 18, 2016 11:51 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Provide a generic interface for getting
the SOC ID and version

Thanks for the feedback.

I summarized the updated RFC with the feedback.

The SoC id and revision information would be using #define which
would be SoC specific value.

/* This defines the SoC id */
#define SOC_ID XXXX

/* This defines SoC revision information. */
#define SOC_REV YYYY

Depending on the SoC, this can include different types of version
Information.

If there is other feedback, please let me know and I can incorporate.

-----Original Message-----
From: Liu, Baohong
Sent: Friday, July 15, 2016 4:40 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC
ID and version

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Friday, July 15, 2016 3:41 PM
To: devel(a)lists.zephyrproject.org; Liu, Baohong
<baohong.liu(a)intel.com>
Subject: Re: [RFC] Provide a generic interface for getting the SOC
ID and version

On Fri, 2016-07-15 at 18:50 +0000, Liu, Baohong wrote:

Actually that's not what this API meant to achieve. Some confusion
in the text; the purpose is to provide a generic API for
retrieving this information. How the information is obtained is
implementation detail and in fact, As much possible should be
build time decided as you pointe it out.
Since we've established we should do this at build time, why not
make this a Kconfig or some other #define instead of adding C code
which will add to the footprint?
Yes, the implementation should be through #define.

As the requirement from the ZEP is to get this information from a
HAL (e.g QMSI), we can require HAL does this using #define. (current
QMSI implements this as C function though so that requires it
changed to fit this requirement).

Andrew


Liu, Baohong
 

I tried to summarize from additional feedback with pro-and-cons (please correct if I missed anything).

We have two options discussed for the generic interface.

1) Read SoC register at run time
2) Use #define (build time decided)

For 1), This would address the issue Pedro pointed out on revision number per stepping.
However, concern is that it increases code size as pointed out by Andrew.

For 2), it won't increase code size. However, SoC stepping info may not be available (Pedro).

I propose we go with 1) based on feedbacks but am open if anyone has strong objection.

Thanks
Baohong

-----Original Message-----
From: Liu, Baohong
Sent: Tuesday, July 19, 2016 12:16 PM
To: Morales Romero, Pedro <pedro.morales.romero(a)intel.com>; Boie,
Andrew P <andrew.p.boie(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID and
version

Hi Pedro,

-----Original Message-----
From: Morales Romero, Pedro
Sent: Tuesday, July 19, 2016 2:23 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; Boie, Andrew P
<andrew.p.boie(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC ID
and version

Hi all,

The user might know the SOC ID at compile time (although a user might
want to check against the hardware in case of doubt).
In that case we define the QUARK_D2000 and QUARK_SE via #define
symbols.

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.
Good point. If different stepping can have different revision, seems like the
#define method would need a configuration flag to distinguish the stepping
within the SOC which may not be preferable?

Cheers,
Pedro


-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Monday, July 18, 2016 11:51 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: [devel] Re: [RFC] Provide a generic interface for getting the
SOC ID and version

Thanks for the feedback.

I summarized the updated RFC with the feedback.

The SoC id and revision information would be using #define which would
be SoC specific value.

/* This defines the SoC id */
#define SOC_ID XXXX

/* This defines SoC revision information. */
#define SOC_REV YYYY

Depending on the SoC, this can include different types of version
Information.

If there is other feedback, please let me know and I can incorporate.

-----Original Message-----
From: Liu, Baohong
Sent: Friday, July 15, 2016 4:40 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: RE: [RFC] Provide a generic interface for getting the SOC
ID and version

Hi Andrew,

-----Original Message-----
From: Boie, Andrew P
Sent: Friday, July 15, 2016 3:41 PM
To: devel(a)lists.zephyrproject.org; Liu, Baohong
<baohong.liu(a)intel.com>
Subject: Re: [RFC] Provide a generic interface for getting the SOC
ID and version

On Fri, 2016-07-15 at 18:50 +0000, Liu, Baohong wrote:

Actually that's not what this API meant to achieve. Some
confusion in the text; the purpose is to provide a generic API
for retrieving this information. How the information is obtained
is implementation detail and in fact, As much possible should be
build time decided as you pointe it out.
Since we've established we should do this at build time, why not
make this a Kconfig or some other #define instead of adding C code
which will add to the footprint?
Yes, the implementation should be through #define.

As the requirement from the ZEP is to get this information from a
HAL (e.g QMSI), we can require HAL does this using #define. (current
QMSI implements this as C function though so that requires it
changed to fit this requirement).

Andrew


Boie, Andrew P
 

-----Original Message-----
From: Liu, Baohong

I tried to summarize from additional feedback with pro-and-cons (please
correct if I missed anything).

We have two options discussed for the generic interface.

1) Read SoC register at run time
2) Use #define (build time decided)

For 1), This would address the issue Pedro pointed out on revision number
per stepping.
However, concern is that it increases code size as pointed out by Andrew.

For 2), it won't increase code size. However, SoC stepping info may not be
available (Pedro).
I think we now have a use-case to make this a C API.

Andrew


Kumar Gala
 

On Jul 19, 2016, at 7:44 PM, Boie, Andrew P <andrew.p.boie(a)intel.com> wrote:



-----Original Message-----
From: Liu, Baohong

I tried to summarize from additional feedback with pro-and-cons (please
correct if I missed anything).

We have two options discussed for the generic interface.

1) Read SoC register at run time
2) Use #define (build time decided)

For 1), This would address the issue Pedro pointed out on revision number
per stepping.
However, concern is that it increases code size as pointed out by Andrew.

For 2), it won't increase code size. However, SoC stepping info may not be
available (Pedro).
I think we now have a use-case to make this a C API.

Andrew
I still don’t see the point of this API at all. In the ZEP it mentions using for entropy source or for MAC address creation. I don’t think this ID is a good choice for either purpose. I still don’t see the point at all of adding such an API w/o having a clear understanding of what we expect an app developer to do with it.

We end up creating a legacy that we have to maintain for a long time. For example, are we ok if these IDs aren’t unique across different architectures? Is this even an application level API or internal for zephyr kernel? If internal, is there actually any user?

- k


Morgaine
 

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.

It's an important feature. Without such an API, product developers have
only two options, neither of which is very palatable:


1. Let's say that there are a million target devices which each require
distinct behavior. The developer must now create a million different
sourcefiles and build a million different firmware images, then in
production each target must be flashed with a different image. Needless to
say, no sane engineer would take this option in production.
2. Alternatively, the developer can create a bespoke query function for
access to target identification, thus allowing a single image to be
programmed into all targets on a given assembly line. The benefits of this
are gigantic, but it has the consequence of departing from the standard API
and hence compromising portability of the code.


Since in practice nobody would take the first option above, not
implementing the API is tantamount to requiring developers to go outside
the API to obtain target identification by other means, resulting in a
plethora of different solutions. The technical phrase for this is "a
non-portable mess".


I recommend implementing this proposed API. In applications that don't use
it, the API code is easily elided and will consume zero target resources.


Morgaine.


Jon Medhurst (Tixy) <tixy@...>
 

On Wed, 2016-07-20 at 15:46 +0100, Morgaine wrote:
2. Alternatively, the developer can create a bespoke query function for
access to target identification, thus allowing a single image to be
programmed into all targets on a given assembly line.
And fail on half of them in weird ways because the heuristics they are
using to match machine type to required code behaviour go wrong. E.g.
they assume something like SOC X implies hardware Y available, but then
someone produces a device with SOC X and without Y. What they really
needed was a way of testing for hardware Y, but if they lack that, or
are lazy, they'll use whatever hacks they can to get the current product
shipped. I guess they will anyway, I'm just suggesting that adding
features to a kernel or OS to make that easier may not be beneficial in
the long run.

This sort of thing seems to crop up quite regularly on Linux lists for
example, and to maintain compatibility with apps, the kernel ends up
having to lie to apps and provide false information, because that's what
apps expect. So, with Zephyr, you might end up with SOC X actually
saying it's SOC Z, because that what gets 'Some Important App' TM
working in it's target market.

This sort of issue has been around forever and I've come across it many
times over many decades. Good code should go:

if feature A available then use feature A
else if feature B available then use feature B
else use sane default or error out.

So, if apps need a test for feature A, why not give them a test for
that? Until those requirements come up, I'd suggest steering clear of
generic device or SOC identification APIs.

Sorry, if that was all a bit rambling.

--
Tixy


Morgaine
 

Tixy wrote:

Sorry, if that was all a bit rambling.
I think your comment was very useful, as you've highlighted that there are
at least two different types of requirement being combined here:


- Identification for establishing unique target identity.


- Identification for feature discovery (or in lieu of it).


These are not quite the same thing, and should not be confused.

Querying for a unique target identity is the purpose that I had in mind,
since lots of unique information can be generated from this data by a
single firmware image. This is very useful in many applications,
particular when equipment is online and identity may be important. This
goes far beyond just generating MAC addresses. The ability of a single
image to be parametrized by unique target identity is very powerful.

In contrast, using identification in lieu of automatic feature discovery
introduces desync-type pitfalls as Tixy pointed out, and should be used
only when feature probing cannot be done safely or reliably. One reason
for target identification may be to *disable* automatic feature discovery,
for example when a feature interface is automatically discoverable but the
feature is not fully operational on particular targets. I'm not advocating
for or against such uses, but they are quite distinct from the use of
unique target IDs to generate unique data.

Morgaine.