Add NVStore (A.K.A SOTP) feature #5900

davidsaada · 2018-01-23T01:38:27Z

Description

Adding the NVStore feature.

Status

READY

Migrations

If this PR changes any APIs or behaviors, give a short description of what API users should do when this PR is merged.

NO

Related PRs

None.

branch	PR
other_pr_production	link
other_pr_master	link

Todos

Documentation
Need to move configuration of area addresses and sizes from targets.json to local mbed_lib.json.

Steps to test or reproduce

See README.md for testing instructions.

0xc0170 · 2018-01-23T08:15:26Z

features/nvstore/source/nvstore_shared_lock.cpp

+
+#include "nvstore_shared_lock.h"
+
+#include "mbed.h"


replace this header file with inclusion what is required here in this file

0xc0170 · 2018-01-23T08:15:46Z

features/nvstore/source/nvstore_shared_lock.cpp

@@ -0,0 +1,120 @@
+/*
+ * Copyright (c) 2016 ARM Limited. All rights reserved.


2018 should be year for all new files

0xc0170 · 2018-01-23T08:18:13Z

features/nvstore/source/nvstore_shared_lock.h

+    NVSTORE_OS_NO_MEM_ERR  = -3,
+};
+
+class SharedLock {


I am interested in this SharedLock - missing docs here to describe the scope of this. And if we do not have already something similar in the codebase?

This definitely needs documentation, which will be added. This class implements a shared lock mechanism (AKA RW lock). Now this implementation isn't like the classic one ,the one that needs two Mutexes and a counter. Instead it has one Mutex and an atomic counter, favoring the usage of shared lock/unlock on the count of the exclusive lock/unlock. This will be added in the documentation.

And there doesn't seem to be an implementation for it, at least not under rtos.

0xc0170 · 2018-01-23T08:19:00Z

features/nvstore/source/nvstore_int_flash_wrapper.h

+
+size_t nvstore_int_flash_get_sector_size(uint32_t address);
+
+int nvstore_int_flash_init(void);


should this API be documented in this header file?

Will add short documentation. This is basically a wrapper for the FlashIAP operations, but it should be documented indeed.

0xc0170 · 2018-01-23T08:19:28Z

features/nvstore/source/nvstore_int_flash_wrapper.cpp

+    }
+
+    while (size)
+    {


on the line 172

Please elaborate. Seems like a partial comment.

{ misplaced (as the rest of file has it fine)

0xc0170 · 2018-01-23T08:19:56Z

features/nvstore/source/nvstore_int_flash_wrapper.cpp

+
+// ----------------------------------------------------------- Includes -----------------------------------------------------------
+
+#include "mbed.h"


same as another comment, include what is needed here

you could do - first include project header files, then libs.

0xc0170 · 2018-01-23T08:26:06Z

features/nvstore/source/nvstore.h

+        // Use this implementation of singleton (Meyer's) rather than the one that allocates
+        // the instance on the heap, as it ensures destruction at program end (preventing warnings
+        // from memory checking tools such as valgrind).
+        static NVStore instance;


thread safe for the C++ standard we use at the moment?

Yes - this implementation is thread safe. It's similar to the static implementation tested in TESTS/mbed_drivers/race_test.

Meyer's singleton is thread safe in C++11 and later revisions of the language; not C++98/03.
Note that it's supposed to be safe with ARM ABI with the help of __cxa_guard_acquire.

Indeed so. However, as far as I managed to understand, this specific feature (accessing static member for the first time by multiple threads) has been verified to work in our currently supported tool chains. I don't mind adding a lock there, but this would affect performance (each time get_instance is invoked).
@c1728p9, @geky - care to elaborate about this?

Anyway, I can add a lock there the same way as SingletonPtr does.

We have quite a bit of code relying on this being thread-safe, and I believe/hope it is with all our toolchains.

Technically nothing's thread-safe in C++98/03, because they don't have threads.

We provide guards for ARMCC and GCC, not certain about IAR but should (they mention guard calls and multithreaded lib support that we both enabled).

should be fine as it is

@kjbracey-arm Out of curiosity I've made a quick check. It is safe with all the compilers we support.

As @davidsaada mentioned, there's also a test specificaly to check this in mbed-os:
https://github.com/ARMmbed/mbed-os/blob/master/TESTS/mbed_drivers/race_test/main.cpp#L50

So right now I'm keeping this as is.

0xc0170 · 2018-01-23T08:27:09Z

features/nvstore/source/nvstore.cpp

+    // wait until init is finished.
+    _init_attempts_val = safe_increment(&_init_attempts, 1);
+    if (_init_attempts_val != 1) {
+#if NVSTORE_THREAD_SAFETY


NVSTORE_THREAD_SAFE vs NVSTORE_THREAD_SAFETY

See comment below regarding thread safety.

0xc0170 · 2018-01-23T08:27:39Z

features/nvstore/source/nvstore_shared_lock.cpp

+#include <stdlib.h>
+#include <stdio.h>
+
+#ifndef NVSTORE_THREAD_SAFE


Why is this macro needed? Is it explained anywhere? Why would we want to disable this?

Originally this was there in the client code in order to allow users to reduce code size, if it is clear that no thread safety is required (for instance if there's only one thread). This will be removed altogether, as well as the NVSTORE_PROBE_ONLY define (reducing code size even more aggressively).

0xc0170 · 2018-01-24T12:56:12Z

features/nvstore/README.md

+### Configuring NVStore for your board
+NVStore requires the addresses and sizes of both areas in flash. For this purpose, the following values should be defined in 
+configuration:
+NVSTORE_AREA_1_ADDRESS


separate with , or use a list, otherwise this becomes one liner that is not much readable

0xc0170 · 2018-01-24T12:56:43Z

features/nvstore/README.md

+### Using NVStore
+NVStore is a singleton class, meaning that the system can have only a single instance of it.
+To instanciate NVStore, one needs to call its get_instance member function as following:
+    NVStore &nvstore = NVStore::get_instance();


Should use code highlight

code

0xc0170 · 2018-01-24T12:59:17Z

features/nvstore/module.json

@@ -0,0 +1,18 @@
+{


is this json needed - its not usable in this codebase

0xc0170 · 2018-01-24T13:01:08Z

features/nvstore/source/nvstore.h

+#if defined(NVSTORE_AREA_1_ADDRESS) && defined(NVSTORE_AREA_1_SIZE) && \
+    defined(NVSTORE_AREA_2_ADDRESS) && defined(NVSTORE_AREA_2_SIZE) && \
+    defined(DEVICE_FLASH)
+#define NVSTORE_ENABLED 1


what is the intention here with enabled flag - why cant this always be present?

What others think about this ?

This was actually proposed by the folks from the Austin team. Right now, NVStore is currently supported on two boards (K64F & K82F) only. The defines configuring NVStore addresses and sizes must be there for each supported board, otherwise the module will not build properly. However, we don't want to fail the build for all other boards. So, any board that has these defines is considered to support NVStore, with the enabled define denoting it. All other boards will fail the build only when trying to access the NVStore class. In addition, the NVStore test is declared unsupported based on this define (much cleaner than checking all other defines again).

0xc0170 · 2018-01-24T13:04:57Z

features/nvstore/source/nvstore.h

+#include "nvstore_int_flash_wrapper.h"
+#include "nvstore_shared_lock.h"
+
+enum {


shall this have a name, and return types in the NVStore to be type of this enumeration ??

also limit the scope to be in the class?

Wanted to keep it as simple as possible, having all functions returning int (as it's done in some of the block devices code). Is there any common practice here (int vs. enum)?

0xc0170 · 2018-01-24T13:05:12Z

features/nvstore/source/nvstore.h

+ *
+ * @returns Number of keys.
+ */
+    uint16_t get_max_keys();


can be const, similar other methods like size()

This one can indeed be const and will be modified. The size function can't, as it lazily calls the init function, required in order to determine the NVStore size.

0xc0170 · 2018-01-24T13:06:48Z

features/nvstore/source/nvstore.h

+/**
+ * @brief Programs one item of data on Flash, given key, allowing no consequent sets to this key.
+ *
+ * @param [in] key


can these be on the same line

@param [in] key Key of stored item.

0xc0170 · 2018-01-24T13:07:54Z

features/nvstore/source/nvstore.h

+    // Declare these (not implemented) to make sure they're not accidentally declared
+    // by derived classes
+    NVStore(NVStore const&);
+    void operator=(NVStore const&);


NonCopyable class in the codebase for this

0xc0170 · 2018-01-24T13:09:07Z

features/nvstore/source/nvstore_shared_lock.h

+ * Instead, it uses one Mutex and one atomic counter, favouring the shared usage of the exclusive one.
+ */
+
+class SharedLock {


@kjbracey-arm Can you review this SharedLock class ?

This is a SharedMutex, not a SharedLock.

If this was for general use, I'd be happier without it having a "poll and retry", so that a writer can get in immediately. A ConditionVariable would enable proper waking.

And I'd be happier with a fairer algorithm - Terekhov's is the classic - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html and https://stackoverflow.com/questions/12082405/boost-shared-lock-read-preferred . The condition-variable-based algorithms there would be implementable in mbed OS now.

The promote functionality is a trap - it will deadlock if ever called from two threads. NVStore's extra synchronisation with the atomic free space pointer avoids that, but having it just there in the API without warnings is scary.

Other notes would be to standardise naming - lock/unlock (making #5852 work with it) and lock_shared/unlock_shared and eliminate the return values - "can-fail" locks call too many problems. (I believe there's broad agreement to make non-timed Mutexs assert on failure.)

But I'm not sure we really want to spend much time trying to design "mbed OS" shared locks at this point - we've had enough trouble with the ScopedLock.

I would kind of suggest we just accept this as-is for NVStore's internal use - rename it with some sort of NVStore prefix or namespace to avoid collisions with any potential general-purpose one. Maybe we could start a separate issue about agreeing an API/implementation for general use elsewhere. Don't want to totally derail this PR.

Thanks for the thorough review. This was indeed implemented privately for NVStore, with the intention of favoring the shared usage (writers) over the exclusive one (GC), which is why I didn't use the classic two mutexes implementation. Guess that if there was such an mbed-os class, I'd use it instead. Anyway I'll add an NVStore namespace there to keep it bounded to NVStore.

Fine. But do check my top-level PR comments that I failed to attach to the diff - I think there may be a couple of flaws in how it's used by nvstore.

0xc0170 · 2018-01-24T13:12:54Z

Thanks for the quick update for my comments, I reviewed again, left few comments, nothing major.

I added 2 reviewers, if you know someone else, please mention them here, assign as reviewers.

davidsaada · 2018-01-24T15:23:45Z

Sam/Martin - It has just occurred to me that the NVSTORE feature I had added in a few config files (like targets.json) was probably redundant. It probably was required when the feature had been under the FEATURE_NVSTORE directory, but not any more as this directory was renamed to nvstore. Is this correct? If so, I'll remove these occurrences.

0xc0170 · 2018-01-25T10:48:09Z

Sam/Martin - It has just occurred to me that the NVSTORE feature I had added in a few config files (like targets.json) was probably redundant. It probably was required when the feature had been under the FEATURE_NVSTORE directory, but not any more as this directory was renamed to nvstore. Is this correct? If so, I'll remove these occurrences.

If not needed, please remove

kjbracey

Can't seem to actually get the GitHub diff of nvstore.cpp to load in a way I can comment on.

So two notes on the "wait for another thread to GC" bit.

There seems to be an out-of-place exclusive_unlock before the loop. Do you mean shared_unlock?
The 100% CPU spin isn't ideal, and isn't the active area check racy, in theory? Couldn't someone other writes cause GC to happen again and flip back to the same area? For now, how about releasing the shared lock, waiting 1ms (given that the lock does that anyway), then just retrying the whole operation from line 634.

kjbracey · 2018-01-25T12:36:57Z

features/nvstore/source/nvstore_shared_lock.h

+ * Instead, it uses one Mutex and one atomic counter, favouring the shared usage of the exclusive one.
+ */
+
+class SharedLock {


This is a SharedMutex, not a SharedLock.

If this was for general use, I'd be happier without it having a "poll and retry", so that a writer can get in immediately. A ConditionVariable would enable proper waking.

And I'd be happier with a fairer algorithm - Terekhov's is the classic - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html and https://stackoverflow.com/questions/12082405/boost-shared-lock-read-preferred . The condition-variable-based algorithms there would be implementable in mbed OS now.

The promote functionality is a trap - it will deadlock if ever called from two threads. NVStore's extra synchronisation with the atomic free space pointer avoids that, but having it just there in the API without warnings is scary.

Other notes would be to standardise naming - lock/unlock (making #5852 work with it) and lock_shared/unlock_shared and eliminate the return values - "can-fail" locks call too many problems. (I believe there's broad agreement to make non-timed Mutexs assert on failure.)

But I'm not sure we really want to spend much time trying to design "mbed OS" shared locks at this point - we've had enough trouble with the ScopedLock.

I would kind of suggest we just accept this as-is for NVStore's internal use - rename it with some sort of NVStore prefix or namespace to avoid collisions with any potential general-purpose one. Maybe we could start a separate issue about agreeing an API/implementation for general use elsewhere. Don't want to totally derail this PR.

davidsaada · 2018-01-29T11:25:20Z

@kjbracey-arm - for some reason, can't reply on your two "wait for another thread" comments, so answering you here:

Good catch. Changed to shared_unlock.
I guess you referred to the code in the do_get function here. This shouldn't have been spinning, Forgot the 1 msec wait, will add it. The race condition you described (GC returning to the same area) is very very unlikely to happen (as Flash writes also wait on mutexes), but it's valid and should be addressed. Not sure I understand your comment about releasing the shared lock here. Up until now, readers weren't part of the locking/unlocking game, because it wasn't needed (only problematic case was the reader-GC encounters, to which you referred in this comment). Maybe a shared lock and unlock can wrap the next retries, but I don't think it'll solve the race condition you have described.

kjbracey · 2018-01-29T11:31:00Z

The racy active area check I meant was at line 666 - writer finding themselves out of space and waiting for someone else to do GC, and deducing it had happened by seeing active area flip (and then assuming there would now be space). That would be solid if they instead they just released the shared lock, waited 1ms, then tried the whole "try-to-claim-space" process again - (I might do it by a "goto 634", but I'm more of a goto fan than many).

I hadn't spotted that one in do_get. I'll leave that with you.

davidsaada · 2018-01-29T11:34:44Z

Gotcha. Will review this code again considering this race condition.

kjbracey · 2018-01-29T12:00:15Z

For future enhancement, you could consider ConditionVariable - this is an ideal use case, to replace the 1ms delay and retry loop.

Although I suppose in this case because you're using a SharedMutex, you'd actually need a ConditionVariableAny<SharedMutex>. We currently don't have ConditionVariableAny. You could maybe pop that alongside your private SharedMutex. Implementation from the C++ paper will work - again I have a draft kicking around somewhere.

Looked at do_get a bit. I'm thinking you're trying to maybe be overclever and lock-free here, and I'm really not sure why. This is not performance critical-code, surely?

I would have thought the reader should claim the same shared mutex as writes do. Readers and writers both have the same sort of relationship with GC. (That would also give you automatic wake-up when GC finishes, just using the SharedMutex implementation).

davidsaada · 2018-01-29T12:08:28Z

Absolutely right. This was in fact what I planned of doing following the problem raised in do_get.

davidsaada · 2018-01-29T14:41:21Z

Committed all changes based on @0xc0170 and @kjbracey-arm comments.
@0xc0170 - Wasn't sure about your comment regarding enums (see above).
@kjbracey-arm - Code modified reflecting our conversation. Would appreciate a re-review of the modified parts (mainly the do_get and do_set functions).

kjbracey · 2018-01-30T12:28:42Z

features/nvstore/source/nvstore.cpp

-                if (save_active_area != _active_area) {
+                new_free_space = safe_increment(_free_space_offset, record_size);
+                // Use the same logics as before to check whether GC is complete
+                if (new_free_space < _size) {


Still racy - while you were meditating lots of other people could have used the new area, and you might now turn out to be the person who is expected to actually do the GC on that area! (record_offset < _size). I still think goto 634 or its logical equivalent is required.

If you really have a philosophical objection to goto, then put the entire block in a do {} while (0 or something) and call it continue instead. But I think goto retry is fine.

Thanks - embraced your solution (got no problems with goto - use it a lot in my code whenever needed).

kjbracey · 2018-01-30T12:32:51Z

features/nvstore/source/nvstore.cpp

-            return NVSTORE_NOT_FOUND;
-        }
+    // We only have issues if we read during GC, so shared lock is required.
+    _write_lock.shared_lock();


Yes, but shouldn't really be called write_lock any more. It's I guess it's a "layout" lock? Or a "gc" lock? (And if I'm still being that picky, it's a mutex).

Hmmm... Maybe just lock...

kjbracey · 2018-01-31T16:20:05Z

features/nvstore/source/nvstore.cpp

+            // In the case we have crossed the limit, and the initial offset was also after the limit,
+            // this means we are not the first writer (uncommon case). Just wait for GC to complete.
+            // then retry the operation
+            _lock.shared_unlock();


I think this can be simplified to

_lock.shared_unlock(); rtos::Thread::wait(MEDITATE_TIME_MS); goto retry;

with retry moved above the shared_lock() above.

This version fails to set record_offset and has a no-longer-doing-anything for (;;)

Right. This is the cleanest way to go.

SenRamakri · 2018-02-02T15:35:53Z

features/nvstore/source/nvstore.cpp

+    return do_set(key, 0, NULL, DELETE_ITEM_FLAG);
+}
+
+int NVStore::init()


Can you please review and see if we can optimize the stack usage of this function?

Yes, the local variables aren't optimally arranged (alignment-wise). After arrangement they'll use 55 bytes of stack (all arrays there have two indexes). Is this problematic? Note that this is the init function, which should be called once at system life time.

SenRamakri · 2018-02-02T15:41:22Z

features/nvstore/source/nvstore.cpp

+
+#ifdef NVSTORE_TESTING
+
+int NVStore::force_garbage_collection(void)


Whys is this bound with NVSTORE_TESTING? Shouldn't we be doing garbage collection for targets smaller flash footprint/smaller NVStore as well?

Please note that this is is not the actual garbage collection function, which is simply called garbage_collection, but the force garbage collection function, used for testing purposes.

@davidsaada Why would garbage collection need to be forced durring collection? Is this the same testing as mbed test or something different?

Actually this should be removed altogether. It was used to debug garbage collection, but it's not used for that purpose any more. Will remove it.

0xc0170 · 2018-02-05T09:25:35Z

targets/targets.json

@@ -691,7 +691,7 @@
        "macros": ["CPU_MK82FN256VDC15", "FSL_RTOS_MBED"],
        "inherits": ["Target"],
        "detect_code": ["0217"],
-        "device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG"],
+        "device_has": ["ANALOGIN", "ANALOGOUT", "I2C", "I2CSLAVE", "INTERRUPTIN", "LOWPOWERTIMER", "PORTIN", "PORTINOUT", "PORTOUT", "PWMOUT", "RTC", "SERIAL", "SLEEP", "SPI", "SPISLAVE", "STDIO_MESSAGES", "TRNG", "FLASH"],


enabling flash for a target should be separate PR , tests provided there as well

Right. Will be moved to a separate PR.

0xc0170 · 2018-02-05T09:26:40Z

features/nvstore/mbed_lib.json

+	    }
+    },
+	"target_overrides": {
+		"K64F": {


If a target needs to define these, and we got only 2 targets available for this feature, this PR will need to be redirected to own feature branch.

I can create one for you, feature-nvstore ?

@sg- @bulislaw @theotherjimmy We need to enhance the definition for additional targets but I think we can do it internally and do not need partners for it. We need some help with targets that we do not have. Also need the new tools from @theotherjimmy

@dannybenor Which new tools are these? Is there an associated PR with them, or are they in a different repo?

@cmonr This Jira was created to follow up the tools improvements https://jira.arm.com/browse/IOTMORF-1991
For managed BL mode, the addresses are outputs.

@dannybenor Sounds good, but I think @0xc0170's question is still unanswered. At this time, this feature is still only targeting a few targets, instead of the entire ecosystem.

Going to add support for a whole lotta boards in this PR, hopefully soon.

cmonr · 2018-02-08T02:23:50Z

@davidsaada, if you haven't rebased this PR in a while, I would suggest doing so. TravisCI keeps failing for this PR, and I think it's because this PR is missing a particular commit.

davidsaada · 2018-02-12T10:52:41Z

Thanks @cmonr - rebasing indeed fixed the Travis issue.
Still fails on Jenkins, but not sure why, or if it's related to the PR itself.

0xc0170 · 2018-02-12T12:10:23Z

Something went wrong with rebase , please look at the commits there (they are duplicated)

cmonr · 2018-02-13T16:38:53Z

@0xc0170 The commits look alright. They look the same at a glance due to the way the commit was formatted, and how GitHub is collapsing the commit.

davidsaada · 2018-02-13T16:44:10Z

@cmonr - The commits are OK now. Fixed them thanks to @0xc0170 comment (my rebase was problematic - fixed it and performed a force push).
TravisCI still fails on the K82F board. The build command also failed for me locally, but after a clean build it stopped failing. Does TravisCI perform a clean build?

cmonr · 2018-02-13T17:35:36Z

@davidsaada, TravisCI and Jenkins both do clean builds, and they also build and test separate things.

It looks like TravisCI is about to pass (wohoo!), but Jenkins builds are still failing, due to build failures with mbed-os-cliapp (it's a private repo, and I'm actually confused as to why it's a part of PR build checks).

mbed-ci · 2018-02-27T15:04:50Z

Build : FAILURE

Build number : 1280
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5900/

davidsaada · 2018-02-27T15:11:38Z

/morph build

mbed-ci · 2018-02-27T15:46:31Z

Build : FAILURE

Build number : 1284
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5900/

davidsaada · 2018-02-27T16:07:14Z

<sigh> Now there's a problem with the ARM compiler licenses. Will try invoke the morph build later.

cmonr · 2018-02-27T17:39:09Z

@davidsaada This isn't the only PR being hit with ARM license server issues. I can restart the build once it looks like the dust has settled.

cmonr · 2018-02-27T20:34:18Z

Fingers crossed: /morph build

mbed-ci · 2018-02-27T20:52:38Z

Build : SUCCESS

Build number : 1291
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5900/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

mbed-ci · 2018-02-27T23:34:20Z

Exporter Build : SUCCESS

Build number : 953
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5900/

mbed-ci · 2018-02-28T01:46:58Z

Test : SUCCESS

Build number : 1078
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5900/1078

LiyouZhou · 2018-02-28T11:06:13Z

features/nvstore/mbed_lib.json

+            "help": "Area 2 size"
+        }
+    }
+}


can we have some target defaults in here?

By design, there are no target defaults in mbed_lin.json. By default, we take the last two sectors of the flash and use them for NVStore, one per area. If they are smaller than 4KB, we take a few consecutive ones to form areas >= 4KB. One can set values in mdeb_lib.json to override this default behavior, but that's entirely up to the specific application.

Copy edit for typos and minor spelling nits.

Edit README with changes from docs site and minor formatting changes.

davidsaada · 2018-03-01T11:16:15Z

/morph build

mbed-ci · 2018-03-01T11:44:11Z

Build : SUCCESS

Build number : 1313
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5900/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build
/morph mbed2-build

mbed-ci · 2018-03-01T13:26:39Z

Exporter Build : FAILURE

Build number : 973
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5900/

cmonr · 2018-03-01T17:49:35Z

SUCCESS exporting mbed-os-example-mesh-minimal UBLOX_EVK_ODIN_W2 gnuarmeclipse
Building mbed-os-example-mesh-minimal UBLOX_EVK_ODIN_W2 gnuarmeclipse
==========STDOUT==========

Create.
Opening 'mbed-os-example-mesh-minimal'.
Refreshing '/mbed-os-example-mesh-minimal'.

==========STDERR==========
Eclipse:
An error has occurred. See the log file
/tmp/tmpS2Dn48/.metadata/.log.

SUCCESS
FAILURE

/morph export-build

mbed-ci · 2018-03-01T19:30:59Z

Exporter Build : SUCCESS

Build number : 975
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5900/

davidsaada · 2018-03-01T19:35:49Z

@cmonr Thanks for triggering the exporter. Looks like morph test has been manually aborted.

cmonr · 2018-03-01T19:38:03Z

Good eye. I'll re-trigger it.
/morph test

cmonr · 2018-03-01T19:39:05Z

@davidsaada Also, as a reminder, only the maintainers should be triggering the morph commands, especially being this close to a release PR being made.

cmonr · 2018-03-01T20:56:13Z

@pan- @sg- @geky @LiyouZhou @dannybenor @kjbracey-arm @SenRamakri Any final comments on the PR?

mbed-ci · 2018-03-01T23:26:21Z

Test : SUCCESS

Build number : 1101
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5900/1101

cmonr added the needs: review label Jan 23, 2018

0xc0170 requested changes Jan 23, 2018

View reviewed changes

davidsaada force-pushed the david_sotp_cpp branch from 197fb88 to f9da807 Compare January 24, 2018 02:38

0xc0170 requested review from sg- and SenRamakri January 24, 2018 12:50

0xc0170 requested changes Jan 24, 2018

View reviewed changes

0xc0170 added needs: work and removed needs: review labels Jan 24, 2018

kjbracey reviewed Jan 25, 2018

View reviewed changes

kjbracey reviewed Jan 30, 2018

View reviewed changes

kjbracey reviewed Jan 31, 2018

View reviewed changes

SenRamakri reviewed Feb 2, 2018

View reviewed changes

0xc0170 requested changes Feb 5, 2018

View reviewed changes

davidsaada force-pushed the david_sotp_cpp branch from c00acc4 to 2aa08c5 Compare February 12, 2018 13:20

cmonr added the ready for merge label Feb 28, 2018

LiyouZhou reviewed Feb 28, 2018

View reviewed changes

Amanda Butler added 2 commits February 28, 2018 18:47

Copy edit nvstore.h

6ddff63

Copy edit for typos and minor spelling nits.

Edit README.md

f078124

Edit README with changes from docs site and minor formatting changes.

AnotherButler approved these changes Mar 1, 2018

View reviewed changes

cmonr added the release-version: 5.8.0-rc1 label Mar 1, 2018

cmonr removed the ready for merge label Mar 1, 2018

SenRamakri approved these changes Mar 1, 2018

View reviewed changes

cmonr merged commit 2532196 into ARMmbed:master Mar 2, 2018

cmonr removed the needs: review label Mar 2, 2018

theotherjimmy mentioned this pull request Mar 5, 2018

Digital Signatures and Secure In-Field Updates #6222

Closed

		@@ -0,0 +1,120 @@
		/*
		* Copyright (c) 2016 ARM Limited. All rights reserved.


		size_t nvstore_int_flash_get_sector_size(uint32_t address);

		int nvstore_int_flash_init(void);


		// ----------------------------------------------------------- Includes -----------------------------------------------------------

		#include "mbed.h"


		#ifdef NVSTORE_TESTING

		int NVStore::force_garbage_collection(void)

Add NVStore (A.K.A SOTP) feature #5900

Add NVStore (A.K.A SOTP) feature #5900

Uh oh!

Conversation

davidsaada commented Jan 23, 2018

Description

Status

Migrations

Related PRs

Todos

Steps to test or reproduce

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pan- Jan 24, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

geky Jan 25, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

davidsaada Jan 23, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xc0170 Jan 24, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

pan- Jan 24, 2018 •

edited

Loading

geky Jan 25, 2018 •

edited

Loading

davidsaada Jan 23, 2018 •

edited

Loading

0xc0170 Jan 24, 2018 •

edited

Loading

davidsaada Jan 29, 2018 •

edited

Loading