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

Hello All Please be aware that the merge window will be closing on Aug 1st / 2nd (a wee fuzzy as I am traveling on different time zones). - First rc0 will be tagged on around Aug 3rd. RCs will be

No, they have not been discussed. Thanks for your feedbacks. I totally agree with you. Following are couple of options. 1. int fs_open(ZFILE *zfp, const char *file_name); - Opens file if

We don't have a non-re-entrant version so we don't need to differentiate the way stdio needs to. Also we are not strictly following stdio signature. These functions can be useful and we can add

Some random kibitzing. I'm new, so apologies if some of this has been discussed before: Why a stdio-style mode string that has to be parsed and not a fcntl-style flag word which seems like a better

While I do see benefit of using enum and (thus only one API is needed), what Morgaine pointed out is also a good point. I think I will stick to current two individual APIs w/o enum but am open if

Hi Morgaine, Thanks for the comment. As far as I know based on the requirement from the ZEP, the API would get the SoC id and rev information from SoC registers (or hard-coded). The current naming

See [Peter]

The use case Pedro articulated focused on the scenario where the board was the same but the SOC version changed. In response to some of the comments on inappropriate use of these types of APIs, we

That would create an artificial interdependency between the two unrelated types of data via their shared access method. Someone would have to maintain the enumerated type, and while that's not hard,

NEW JIRA items within last 24 hours: 0 UPDATED JIRA items within last 24 hours: 23 [ZEP-279] nios2: demonstrate nanokernel hello world https://jira.zephyrproject.org/browse/ZEP-279 [ZEP-254]

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/3461 : bluetooth: adding Direct Test Mode support to shell application - https://gerrit.zephyrproject.org/r/3450 : x86: improve

Suggestion: instead of different APIs for getting the ID and Version, how about one API which takes an enumerated type to select which data to retrieve? For example something like: enum

Hi, I've been able to flash the D2000 board with the Zephyr command line. I've been trying to follow the instructions here: https://www.zephyrproject.org/doc/getting_started/installation_win.html

Not an objection, but just a little query. Did you really intend the prefix of these two API calls to be "*soc_*", rather than say "*sys_*" or " *hw_*" or something like that? The reason I ask is

I’ll merge my kernel version with the master and commit patch for the review soon. For testing I’m using two targets: - Real Hardware with FPGA (ML605, KC705) - Platform

BTW try to keep all traffic in this mail thread. Error: unable to open ftdi device with vid 0403, pid 6014, description '*' and serial '*' Take the vendor and product id and create a udev rule. You

Hello Matt, Here you can find more info: https://wiki.zephyrproject.org/view/Quark_D2000_CRB This issue is related to your distro configuration. Nope. I have never seen this. Please attach the

A file system is necessary to store data reliably and to be accessed in a consistent and deterministic manner. Example applications are data logging, media files and file based databases which would

Thanks all for your feedback. Since I have not heard any objection to the usage cases clarified by Gajinder, I assume this is fine and conclude this RFC. The summary of the API interface: /** *