Date
1 - 20 of 37
[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,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,
toggle quoted messageShow quoted text
-----Original Message-----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).
|
|
|
|
Boie, Andrew P
Good questions. My understanding the main idea is the scalability onScalability 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,
toggle quoted messageShow quoted text
-----Original Message-----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.
|
|
|
|
Kumar Gala
On Jul 15, 2016, at 1:50 PM, Liu, Baohong <baohong.liu(a)intel.com> wrote: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:
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,
toggle quoted messageShow quoted text
-----Original Message-----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.
toggle quoted messageShow quoted text
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-----
|
|
|
|
Liu, Baohong
Hi, Kumar,
toggle quoted messageShow quoted text
-----Original Message-----Current ZEP does not call out other usage. The updated RFC would provide a common Definition for all future usage.
|
|
|
|
Morales Romero, Pedro <pedro.morales.romero@...>
Hi all,
toggle quoted messageShow quoted text
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------------------------------------------------------------------- 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,
toggle quoted messageShow quoted text
-----Original Message-----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,
|
|
|
|
Thomas, Ramesh
On 07/19/2016 12:15 PM, Liu, Baohong wrote:
Hi Pedro,Is there a specific requirement for the revision id? Is SOC ID enough to-----Original Message-----Good point. If different stepping can have different revision, seems like the #define meet the requirement? Cheers,
|
|
|
|
Liu, Baohong
toggle quoted messageShow quoted text
-----Original Message-----This is from the ZEP. The information they carry are different. Cheers,
|
|
|
|
Liu, Baohong
I tried to summarize from additional feedback with pro-and-cons (please correct if I missed anything).
toggle quoted messageShow quoted text
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-----
|
|
|
|
Boie, Andrew P
toggle quoted messageShow quoted text
-----Original Message-----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: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.-----Original Message-----I think we now have a use-case to make this a C API. 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 forAnd 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:
I think your comment was very useful, as you've highlighted that there areSorry, if that was all a bit rambling. 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.
|
|
|