STORAGE: Merging feature-storage branch commits to master #3762

simonqhughes · 2017-02-13T17:30:04Z

Description

This PR is to bring the new commits added to the feature-storage branch into master in preparation for creating the mbed-os 5.4 release candidate. The time line is as follows:

13 Feb- 24 Feb: merging of feature-storage work into master.
25 Feb - 10 March: working on master: generation of 5.4 release candidate, final testing, final fixing work
10 March: creation of mbed-os 5.4 release.

In addition to the commits cherry-picked from the feature-storage branch, the following modifications have been made to make a clean delivery to master:

The removal of the SDCard driver (SDBlockDevice module) and associated test cases, support code(basic.cpp, fopen.cpp) and documentation. These have been moved into the support repository https://github.com/ARMmbed/sd-driver.
Removal of the a redundant test case features/filesystem/sd/TESTS/block_device/main.cpp.

The files that have been removed are as follows:

mbed-os/features/filesystem/README.md
mbed-os/features/filesystem/sd/SDBlockDevice.cpp
mbed-os/features/filesystem/sd/SDBlockDevice.h
mbed-os/features/filesystem/sd/TESTS/block_device/main.cpp
mbed-os/features/filesystem/test/fsfat_debug.h
mbed-os/features/filesystem/test/fsfat_test.c
mbed-os/features/filesystem/test/fsfat_test.h
mbed-os/features/TESTS/filesystem/basic/basic.cpp
mbed-os/features/TESTS/filesystem/fopen/fopen.cpp

As the above files are no longer in the final PR (but many commits are present including changes to those files before being removed), any changes to the above files in intermediate commits can be ignored.

Background Information

It appears that (for reasons unknown) rebasing of the feature-storage branch with master (so that PAL team could have reasonably up-to-date feature-storage branch) has created commits with new sha's, now making it difficult to rebase the feature-storage branch with master again, or merge the existing feature-storage branch into master. After discussion with Martin, it was decided the best course of action was to:

In my fork, branch off latest master (ms_20170213_fs_integration branch)
Cherry-pick commits (newly added onto feature-storage branch) onto ms_20170213_fs_integration.
Push ms_20170213_fs_integration into fork
Submit this PR to merge the work into master.

The list of commits cherry-picked into this branch is in the attached file.

Status

undergoing CI testing

feature_storage_commits.txt

simonqhughes · 2017-02-13T17:43:13Z

@geky Please could you check this over to make sure I haven't missed any commit from the feature-storage branch? Thanks.

geky · 2017-02-14T14:48:24Z

This looks good to me 👍

Thanks for going through the pain of rebasing this branch.

As a side note, here are the remaining important paches: #3766, #3764, #3747. They can just as easily be moved against master once this first push is in, so I don't think we need to worry about them right now.

Is there any other work that needs to be done on this pr?

simonqhughes · 2017-02-17T09:24:54Z

Hi

I've been reviewing the SPIFBlockDevice and the Microchip flash documentation and thought I should provide some
better feedback than I gave in Oulu. I'm not proposing any changes to the block api for 5.4
but I think it will be important to review the API in light of the other filesystem
work we're going to be doing. Some notes follow in preparation for that review.

First some definitions with respect to flash memories:

flash is divided into "sectors" or "pages" e.g. typically 4kB in size.
n sectors are collected into a blocks.
Sometimes the blocks are all the same size e.g. 64kB = 16 x 4kB sector-pages
Sometimes there are blocks of different sizes e.g. microchip part has 8x8kB, 2x32kB and 30x64kB blocks.
blocks have to be erased before they're programmed. Hence devices have a sector
erase operation to set all the bits to 1's in a block, and usually a block erase, to set the
whole block.
after an erase, a "program" operation is used to write part of a sector e.g. for the microchip part
this is a 256byte operation.
Note the flash memory part "block size" is usually different from the Block API block size, the
later typically being identified with the size of the program-write operation (256bytes)
File storage is more efficient using a block size smaller than the sector size (less wasted
space).

For the above part a simple block API would probably have:

block_size = 256bytes. read and writes would both use this size.
erase_size = 4kB i.e. the sector size.

<<<<<<< TEXT/FILES DELETED See email for details.

I've attached to this email the following files from

TEXT DELETED >>>>>>>>>>>

Note the following:

The API read and write (xxx_ReadSector() and xxx_WriteSector() operations deal in fixed size blocks.
The fact that both these methods have xxxSector() in the name indicates that (for common flash parts)
read_blen = write_blen = sector size i.e. 4kB on microchip part, rather than using the
better 256bytes (i.e. less wasted space per file).
The block API doesnt expose an erase operation. This is because of the xxx_WriteSector() will
perform the erase operation prior to the write internally.
There is a query method xxx_ReadInfo() for the block API client to discover the number of blocks,
and the block sizes for read and write operations.

By way of comparison, here is the yaffs block API (nand):

int yflash2_EraseBlockInNAND(struct yaffs_dev *dev, int blockNumber);
int yflash2_WriteChunkToNAND(struct yaffs_dev *dev, int nand_chunk,
const u8 *data, const struct yaffs_spare *spare);
int yflash2_WriteChunkWithTagsToNAND(struct yaffs_dev *dev, int nand_chunk,
const u8 *data, const struct yaffs_ext_tags *tags);
int yflash2_ReadChunkFromNAND(struct yaffs_dev *dev, int nand_chunk,
u8 *data, struct yaffs_spare *spare);
int yflash2_ReadChunkWithTagsFromNAND(struct yaffs_dev *dev, int nand_chunk,
u8 *data, struct yaffs_ext_tags *tags);
int yflash2_InitialiseNAND(struct yaffs_dev *dev);
int yflash2_MarkNANDBlockBad(struct yaffs_dev *dev, int block_no);
int yflash2_QueryNANDBlock(struct yaffs_dev *dev, int block_no,
enum yaffs_block_state *state, u32 *seq_number);

and interesting defines:

/* Constants for YAFFS1 mode /
#define YAFFS_BYTES_PER_CHUNK 512
#define YAFFS_CHUNK_SIZE_SHIFT 9
#define YAFFS_CHUNKS_PER_BLOCK 32
#define YAFFS_BYTES_PER_BLOCK (YAFFS_CHUNKS_PER_BLOCKYAFFS_BYTES_PER_CHUNK)

Observations for the yaffs API:

the erase method is exposed
the blocks are 512bytes, and blocks are 16kB for yaffs v1.
note the facility to read/write extra bytes associated with each chunk. Nand
parts typically have these storage areas for storing out of band data e.g.
for error correction etc.

It will be interesting to compare the other APIs to those above.

So what does this mean for our current BlockDevice API?

Some of the foregoing should be documented in the block device API header e.g.:
- the reasoning behind having a separate program() and erase() operation.
- that the erase() can be a null implementation in the case that
  API block_size = the size of the flash memory "Block"
As its a block API then the read and write methods should read/write blocks i.e.
transactions are multiple of the block size, or rejected. This means:
- addr should be aligned to a multiple of block_size
- size should be a multiple of block_size
- the read size should be reported as the block size (e.g. 256 bytes, rather than 1 byte)
- the program size should be reported as the block size (e.g. 256 bytes, rather than 1 byte)

@geky @sg- Let me know what you think.

0xc0170 · 2017-02-20T12:44:40Z

platform/retarget.h

+#ifndef RETARGET_H
+#define RETARGET_H
+
+#if defined TOOLCHAIN_ARM_STD || defined TOOLCHAIN_IAR


why this file is named retarget ? I wonder if more specific name would not be better - It is mainly about errno.h definitions, not something like mbed_errno/errno_codes or any suggestions.

why it does not include errno.h if it redefines some symbols?

I currently has errno redefinitions and stat definitions, but it could be a resonable place for other redefitions. I think retarget.h is reasonable unless we want many small files for specific purposes (should be break apart retarget.cpp as well in that case?).

You're right, retarget.h should probably include errno.h 👍

OK, agreed with gatekeepers that retarget.h is acceptable name.

The comment reads about ARMC5 differences but the inclusion is for IAR and ARMC5. Needs some clarification and use compiler emitted macros.

And just so I understand, the intent is to unify the errno values to match POSIX definitions across the 3 toolchains?

Yes, the intent is to unify errno values across toolchains, and supply values where missing. I've updated comments and changed to use compiler emitted macros.

0xc0170 · 2017-02-20T13:01:54Z

features/filesystem/fat/FATMisc.h

+
+#include "ff.h"
+
+void fat_filesystem_set_errno(FRESULT res);


Missing docs for this function

0xc0170 · 2017-02-20T13:02:14Z

features/filesystem/fat/FATMisc.h

@@ -0,0 +1,27 @@
+/*
+ * mbed Microcontroller Library
+ * Copyright (c) 2006-2016 ARM Limited


be aware of years, this is a new file - 2017

0xc0170 · 2017-02-20T13:02:37Z

features/filesystem/fat/FATMisc.cpp

+#include "platform/retarget.h"
+
+
+/* @brief   Set errno based on the error code returned from underlying filesystem


Place this in the declaration header file as I commented below

@0xc0170
@geky requested changing the original file name to retarget.h (its included in retarget.cpp). Have discussed with you and you're happy with this filename now. Thanks.

0xc0170 · 2017-02-20T13:04:59Z

features/filesystem/fat/FATFileSystem.cpp

+
+
+// FAT driver functions
+DWORD get_fattime(void) {


please fix formatting { new line

Done. Astyle tool run on FATXxx files to correct multiple instances of this formatting problem.

0xc0170 · 2017-02-20T13:07:01Z

features/filesystem/fat/FATFileSystem.h

@@ -35,13 +36,46 @@ using namespace mbed;
 */
 class FATFileSystem : public FileSystemLike {


This header file could contain informatin about thread safety as our API do (I noticed it is as there are lock/unlock methods)

Documentation added.

0xc0170 · 2017-02-20T13:09:25Z

features/filesystem/bd/HeapBlockDevice.h

+     *
+     *  @return         Size of a eraseable block in bytes
+     */
+    virtual bd_size_t get_erase_size();


should this be declared with const as they are getters (read-only) ? This would apply to all get methods in this patch if yes.

They could be, I originally did not since it may require implementors learn to use mutable for cases where non-const SPI transaction may occur.

If we're pushing for const (and more adoption of const+mutable where simple hardware transaction are required) I don't see a reason to not slap const on these guys.

get_xxx_size() const added for get_write_size(), get_read_size(), get_program_size(), get_erase_size()

0xc0170 · 2017-02-20T13:13:55Z

features/TESTS/filesystem/heap_block_device/main.cpp

+ * stack tracking statistics are enabled. If this is the case, build dummy
+ * tests.
+ */
+#if ! defined(TOOLCHAIN_IAR) && ! defined(TARGET_KL25Z) && ! defined(MBED_STACK_STATS_ENABLED)


Is this just KL25Z specific or because target does not have enough memory (this might lead to skip this test for many targets, the list will grow here) ?

I cant spot here a reason why it fails to build.

@0xc0170 This only skips the test for IAR building for KL25Z target with MBED_STACK_STACK_ENABLED enabled as the binary is too big. One of the CI builds some mbed_micro jobs and this fails.

@bridadan may want to have a word.

So far we have simply been splitting up tests when they get too big. Not sure if that is appropriate here.

In the past we have split up tests due to their size, so I'd say this is an acceptable solution if there is a reasonable way to split this up.

A test definitely should not change its behavior due to the target or the toolchain. So the way it is currently implemented should change.

Could we not simply reduce the size of the HeapBlockDevice? Does it have to be 16*BLOCK_SIZE? That's fairly large (8k if I'm doing my math right). The KL25Z only has 16K of RAM.

My proposal for this would be: would be good to split now because obviously our tools do not support this use case. But is that a long term solution ? What size requirement should be set for a test? Or is there any other way to handle this?

If there's a test that does not fit all targets (we will have definitely basic tests that should exercise API and fit to any target) and then tests that do lot of things. Should our tools handle this as not supported (not a failure, a target cant support this test thus wont be reported as failure), but will be shown in the result. Thus a user would know x tests were not run due to a size failure (not enough RAM or FLASH).

Might be worth creating an issue for this to continue discussion there.

Most tests should mimic real-world use cases. If a target can't fit a real-world use case of a feature or API in it's FLASH or RAM, then it sounds like that target shouldn't support that feature! Or the API needs to do some optimizations!

If the feature is mission critical for mbed OS, then I would suggest the following options:

Move the API and tests behind a FEATURE_ directory and enable it for all relevant platforms.

Remove the target from the supported list.

I believe none of the current tests coming in need to be split. The large filesystem tests now live over here:
https://github.com/ARMmbed/sd-driver/tree/master/features/TESTS/filesystem

We should be able to just remove this compile time conditions

0xc0170 · 2017-02-20T13:52:51Z

Just some addition to the the message above about sector size vs page size, that might help.

We had similar problem in flash api - we dont want to mix these two worlds, the message above just reminded me some discussions we had with @c1728p9, thus I'll add some notes here that could help:

A sector size might not be the same as a page size (I use this terminology as it comes from flash API). Thus erase() operates on different boundaries than program_page(). It might not be ideal to provide write() that does operate on two different things, explanation below.

The block API doesnt expose an erase operation. This is because of the xxx_WriteSector() will
perform the erase operation prior to the write internally.

Be aware that sector size might be big, and might not fit in RAM. Therefore it might be better to provide erase() and program_page vs only write_sector(). Lets say there's a device with 128kB sector only. write() method would fail - a user can't allocate the buffer required for this operation. But it would be fine if they do it in small chunks (multiple pages after sector_erase()) - flow would be erase_sector(), program_page() * multiple times to be able to fill an entire sector or just partially.

I already highlighted a need for get_sector_size with an address (sectors might differ based on the address) for devices with various sector sizes.

cc @c1728p9

simonqhughes · 2017-02-21T15:17:33Z

@geky

This post summarises my requested changes. Full explanation in the attached file block_api_notes_for_chris_20170221_for_pr3762.txt, and email.

I think the changes should be done after 5.4 as a patch release so as not to delay this PR.


Summary of changes requested for BlockDevice:

- BlockDevice API should have functions with block_id, block_count (i.e. 
  without bd_addr_t addr, bd_size_t size): 

    virtual bd_error_t read(void *buffer, uint32_t block_id, uint32_t block_count) = 0;
    virtual bd_error_t write(const void *buffer, uint32_t block_id, uint32_t block_count);
    virtual bd_error_t program(const void *buffer, uint32_t block_id, uint32_t block_count) = 0;
    virtual bd_error_t erase(uint32_t block_id, uint32_t block_count) = 0;
    
    virtual bd_size_t get_program_size() = 0;  
    virtual bd_size_t get_erase_size() = 0;

- get_program_size() reports the maximum size for the SPI NOR Program Page operation.
- get_erase_size() reports the size for the SPI NOR Sector Erase operation.
 
- I think these functions should be removed as they're made redundant by the 
  simplification of using fixed size blocks: 
    virtual bd_size_t get_read_size() = 0;
    virtual bd_size_t get_write_size();
    bool is_valid_read(bd_addr_t addr, bd_size_t size);
    bool is_valid_write(bd_addr_t addr, bd_size_t size);
    bool is_valid_program(bd_addr_t addr, bd_size_t size);
    bool is_valid_erase(bd_addr_t addr, bd_size_t size);
    
- The SST26VF016 SPIFBlockDevice and test case should be updated to reflect the above.
  Similarly for other affected code and tests.

block_api_notes_for_chris_20170221_for_pr3762.txt

sg-

Few nits here and there but in general nice one.

sg- · 2017-02-22T11:12:53Z

features/TESTS/filesystem/heap_block_device/main.cpp

+ * stack tracking statistics are enabled. If this is the case, build dummy
+ * tests.
+ */
+#if ! defined(TOOLCHAIN_IAR) && ! defined(TARGET_KL25Z) && ! defined(MBED_STACK_STATS_ENABLED)


TOOLCHAIN_XXX should be replaced by compiler emitted macros.

@simonqhughes, actually this check should be removed

sg- · 2017-02-22T11:15:59Z

features/filesystem/bd/HeapBlockDevice.cpp

+        return BD_ERROR_PARAMETER;
+    }
+
+#ifndef NDEBUG


Was this left over instrumentation during development?

No. The heap block device is primarily used for testing (and backs the inbound storage tests).

When in debug mode, erased blocks are clobbered to help catch errors with unintentionally erasing the wrong blocks. Otherwise, erase is a nop.

sg- · 2017-02-22T11:19:04Z

features/filesystem/fat/FATFileSystem.cpp

+    }
+
+    /* ARMCC doesnt support stat(), and these symbols are not defined by the toolchain. */
+#ifdef TOOLCHAIN_GCC


Should use compiler emitted macro rather than labels

sg- · 2017-02-22T11:22:20Z

platform/retarget.cpp

        st->st_mode = S_IFCHR;
        return  0;
    }
-
+    /* todo: 20170120 this should now be made to work as _stat() is implemented */


is this todo completed?

No this todo is still valid, fstat != stat

sg- · 2017-02-22T11:25:30Z

platform/retarget.h

+#ifndef RETARGET_H
+#define RETARGET_H
+
+#if defined TOOLCHAIN_ARM_STD || defined TOOLCHAIN_IAR


The comment reads about ARMC5 differences but the inclusion is for IAR and ARMC5. Needs some clarification and use compiler emitted macros.

And just so I understand, the intent is to unify the errno values to match POSIX definitions across the 3 toolchains?

sg- · 2017-02-22T11:28:23Z

tools/paths.py

@@ -24,7 +24,9 @@
 BUILD_DIR = getenv("MBED_BUILD_DIR") or BUILD_DIR

 # Embedded Libraries Sources
-LIB_DIR = join(ROOT, "features/unsupported")
+FEATURES_DIR = join(ROOT, "features")  


Looks like mbed 2 specific testing was removed so this should be "features/unsupported" as it was

sg- · 2017-02-22T23:46:24Z

One more set of updates needed:

Remove write from API
remove unused error codes

c1728p9 · 2017-02-23T00:39:51Z

Since only failure and success will be returned, lets get rid of the error code type all together for now and use an integer like the other APIs.

geky · 2017-02-23T00:52:39Z

I'm not proposing any changes to the block api for 5.4 but I think it will be important to review the API in light of the other filesystem work we're going to be doing.

👍 👍 Sorry for not responding in detail to concerns, currently focused on getting this branch merged.

@c1728p9, @sg- I should have pushed a commit that adds the last minute changes from our offline discussion (related to block device api):

Remove write set of functions

Caused confusion with small benefit

Trivial to add later

Remove unused error codes

Initial expirementation indicates most of these may not be useful

Trivial to add later

Removed bd_error_t

Carries to additional type information, int already carries
sufficient connotation

Trivial to add later

@simonqhughes, sorry for pushing to your branch, you should be able to merge into any local copies you have with git pull.

Very random comment:

I already highlighted a need for get_sector_size with an address (sectors might differ based on the address) for devices with various sector sizes.

Correct me if I'm wrong, but this can be introduced with an overload in a backwards compatible manner

0xc0170 · 2017-02-23T09:11:39Z

tools/tests.py

@@ -853,7 +817,7 @@
    {
        "id": "RTOS_9", "description": "SD File write-read",
        "source_dir": join(TEST_DIR, "rtos", "mbed", "file"),
-        "dependencies": [MBED_LIBRARIES, RTOS_LIBRARIES, TEST_MBED_LIB, FS_LIBRARY],
+        "dependencies": [MBED_LIBRARIES, RTOS_LIBRARIES, TEST_MBED_LIB],


is this test functional without fs library dependency? should not be removed? same for 2 more test below

0xc0170 · 2017-02-23T09:13:10Z

tools/paths.py

-FS_PATH = join(LIB_DIR, "fs")
-FAT_FS = join(FS_PATH, "fat")
-SD_FS = join(FS_PATH, "sd")
-FS_LIBRARY = join(BUILD_DIR, "fat")


@sg- Just to confirm, fs library moves out of unsupported folder, gets all this updates, thus these 4 lines shall be removed and any dependencies on these (there are some mbed 2 tests that shall be removed then).

Yes. I discussed this with @sg- and @bridadan yesterday and this was their recommendation.

0xc0170 · 2017-02-23T11:21:32Z

@simonqhughes Please look at jenkins CI failure. From what I found, there's at least one [Error] main.cpp@51,14: 'class HeapBlockDevice' has no member named 'write' error.

adbridge · 2017-02-23T11:24:51Z

pr_head shows this:

K64F ARM] Build failures:
[K64F ARM]   * K64F::ARM::FEATURES-TESTS-FILESYSTEM-HEAP_BLOCK_DEVICE
[K64F ARM]         Building project heap_block_device (K64F, ARM)
[K64F ARM]         Scan: ARM
[K64F ARM]         Scan: FEATURE_LWIP
[K64F ARM]         Scan: FEATURE_STORAGE
[K64F ARM]         Scan: heap_block_device
[K64F ARM]         Compile [100.0%]: main.cpp
[K64F ARM]         [Error] main.cpp@51,0:  #135: class "HeapBlockDevice" has no member "write"
[K64F ARM]         
[K64F ARM]   * K64F::ARM::FEATURES-TESTS-FILESYSTEM-UTIL_BLOCK_DEVICE
[K64F ARM]         Building project util_block_device (K64F, ARM)
[K64F ARM]         Scan: ARM
[K64F ARM]         Scan: FEATURE_LWIP
[K64F ARM]         Scan: FEATURE_STORAGE
[K64F ARM]         Scan: util_block_device
[K64F ARM]         Compile [100.0%]: main.cpp
[K64F ARM]         [Error] main.cpp@52,0:  #135: class "SlicingBlockDevice" has no member "get_write_size"
[K64F ARM]         [Error] main.cpp@62,0:  #135: class "SlicingBlockDevice" has no member "write"
[K64F ARM]         [Warning] main.cpp@89,0:  #68-D: integer conversion resulted in a change of sign
[K64F ARM]         [Error] main.cpp@94,0:  #135: class "SlicingBlockDevice" has no member "get_write_size"
[K64F ARM]         [Error] main.cpp@104,0:  #135: class "SlicingBlockDevice" has no member "write"
[K64F ARM]         [Error] main.cpp@142,0:  #135: class "ChainingBlockDevice" has no member "get_write_size"
[K64F ARM]         [Error] main.cpp@152,0:  #135: class "ChainingBlockDevice" has no member "write"
[K64F ARM]         [Error] main.cpp@165,0:  #135: class "ChainingBlockDevice" has no member "write"

@simonqhughes

geky · 2017-02-23T15:41:39Z

@simonqhughes thanks for fixing the changes I missed 👍
/morph test-nightly

mbed-bot · 2017-02-23T16:03:37Z

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test-nightly

bridadan · 2017-02-23T16:04:21Z

Public test result server was full again, restarting.

/morph test-nightly

sg- · 2017-02-23T16:20:24Z

@geky @simonqhughes looks like we have merge conflicts

mbed-bot · 2017-02-24T02:12:50Z

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1697

Test failed!

…device

geky · 2017-02-24T02:44:36Z

Looks like some shuffling around of the block devices revealed an invalid write to unallocated memory. The write was only for debugging purposes so it has been removed.
/morph test-nightly

geky · 2017-02-24T03:02:02Z

Hmmmm

java.io.IOException: remote file operation failed: c:\jsbld\ws\mbed-os\mbed-os-pr-uvisor-test-pipeline at hudson.remoting.Channel@6081280f:e104819_builds: java.nio.file.FileSystemException: c:\jsbld\ws\mbed-os\mbed-os-pr-uvisor-test-pipeline\autogen\0@tmp\durable-e550bb7f\jenkins-log.txt: The process cannot access the file because it is being used by another process.

@bridadan, if you get a chance, could you be a dear and restart the uvisor CI? I'd rather not distract morph test by force pushing.

bridadan · 2017-02-24T03:04:28Z

retest uvisor

bridadan · 2017-02-24T03:58:40Z

Retest uvisor

bridadan · 2017-02-24T07:30:03Z

/morph test-nightly

bridadan · 2017-02-24T07:50:44Z

retest uvisor

0xc0170 · 2017-02-24T09:22:45Z

retest uvisor

mbed-bot · 2017-02-24T10:38:19Z

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1701

Test failed!

0xc0170 · 2017-02-24T10:40:50Z

the latest results: seems like few platforms fail with features-tests-filesystem-fat_file_system

…s an SDCard dependent test.

adbridge · 2017-02-24T11:05:15Z

/morph test-nightly

adbridge · 2017-02-24T12:30:02Z

pr_head failing with:
[wlan-8022] 11:18:07.522 | TC MainThread: Test Case fails because of: dut1 cmd: 'ifconfig wlan0 --ap systest --pwd RaaSysT35T --security WPA/WPA2 up',retcode: -1

@marhil01 @SeppoTakalo these look unrelated to the actual PR under test ?? Potentially blocking 5.4 release...Is there a device failure?

adbridge · 2017-02-24T13:15:20Z

I've kicked off a rebuild on pr-head to see if that fixes the issue

bridadan · 2017-02-24T14:52:30Z

/morph test-nightly

mbed-bot · 2017-02-24T17:31:46Z

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 1589

All builds and test passed!

geky · 2017-02-24T17:32:49Z

@sg-, @simonqhughes

LLLLLLLLLLL                    GGGGGGGGGGGGGTTTTTTTTTTTTTTTTTTTTTTTMMMMMMMM               MMMMMMMM
L:::::::::L                 GGG::::::::::::GT:::::::::::::::::::::TM:::::::M             M:::::::M
L:::::::::L               GG:::::::::::::::GT:::::::::::::::::::::TM::::::::M           M::::::::M
LL:::::::LL              G:::::GGGGGGGG::::GT:::::TT:::::::TT:::::TM:::::::::M         M:::::::::M
  L:::::L               G:::::G       GGGGGGTTTTTT  T:::::T  TTTTTTM::::::::::M       M::::::::::M
  L:::::L              G:::::G                      T:::::T        M:::::::::::M     M:::::::::::M
  L:::::L              G:::::G                      T:::::T        M:::::::M::::M   M::::M:::::::M
  L:::::L              G:::::G    GGGGGGGGGG        T:::::T        M::::::M M::::M M::::M M::::::M
  L:::::L              G:::::G    G::::::::G        T:::::T        M::::::M  M::::M::::M  M::::::M
  L:::::L              G:::::G    GGGGG::::G        T:::::T        M::::::M   M:::::::M   M::::::M
  L:::::L              G:::::G        G::::G        T:::::T        M::::::M    M:::::M    M::::::M
  L:::::L         LLLLLLG:::::G       G::::G        T:::::T        M::::::M     MMMMM     M::::::M
LL:::::::LLLLLLLLL:::::L G:::::GGGGGGGG::::G      TT:::::::TT      M::::::M               M::::::M
L::::::::::::::::::::::L  GG:::::::::::::::G      T:::::::::T      M::::::M               M::::::M
L::::::::::::::::::::::L    GGG::::::GGG:::G      T:::::::::T      M::::::M               M::::::M
LLLLLLLLLLLLLLLLLLLLLLLL       GGGGGG   GGGG      TTTTTTTTTTT      MMMMMMMM               MMMMMMMM

LMESTM · 2017-03-06T16:35:01Z

Hi

after merge of this PR, the ci-test-shield tests for SPI FIle System can't build anymore as the sympbols are multiple defined. When resolving the duplication locally and removing the file system that was used primarily in ci-test-shield, then the test-api-spi tests that were passing before are now FAILED.

Maybe I missed something ... so has this been tested or is there any plan to also update ci-test-shield repo following this PR update ?
@sg- @0xc0170 @bridadan @simonqhughes

sg- · 2017-03-06T18:16:24Z

@geky can you take a note to update the test here https://github.com/ARMmbed/ci-test-shield

geky · 2017-03-06T23:21:02Z

Can do. There is additional work to support the filesystem tests there as well.

LMESTM · 2017-03-07T08:45:04Z

@bcostm

0xc0170 · 2017-03-07T10:53:23Z

@LMESTM This was expected, we will update the tests (the current supported mbed lib there is older). It will be updated with fixes. Feel free to capture this into a tracking issue to ci test shield repo.

Can do. There is additional work to support the filesystem tests there as well.

OK

simonqhughes added component: filesystem needs: CI labels Feb 13, 2017

simonqhughes self-assigned this Feb 13, 2017

geky approved these changes Feb 14, 2017

View reviewed changes

simonqhughes requested review from sg- and 0xc0170 February 14, 2017 17:27

simonqhughes removed the needs: CI label Feb 16, 2017

0xc0170 requested changes Feb 20, 2017

View reviewed changes

0xc0170 added needs: review release-version: 5.4.0 labels Feb 20, 2017

This was referenced Feb 20, 2017

bd: Add randomness to block device test and more debug friendly output #3747

Merged

Filesystem: Restructure the filesystem api to be consistent with mbed OS #3773

Merged

sg- suggested changes Feb 22, 2017

View reviewed changes

0xc0170 approved these changes Feb 23, 2017

View reviewed changes

0xc0170 reviewed Feb 23, 2017

View reviewed changes

sg- approved these changes Feb 23, 2017

View reviewed changes

Filesystem: Remove invalid write to unallocated memory in heap block …

2cf6773

…device

STORAGE: move fat_file_system test into external repository as this i…

794c6f8

…s an SDCard dependent test.

bridadan added ready for merge and removed needs: work labels Feb 24, 2017

sg- merged commit 9844a39 into ARMmbed:master Feb 24, 2017

sg- removed the ready for merge label Feb 24, 2017

simonqhughes mentioned this pull request Feb 27, 2017

STORAGE: removal of unsupported tests having ported to sd-driver repository #3846

Merged

geky mentioned this pull request Mar 1, 2017

bd: Fix missing const attributes on functions #3866

Merged

		#include "platform/retarget.h"


		/* @brief Set errno based on the error code returned from underlying filesystem

		@@ -35,13 +36,46 @@ using namespace mbed;
		*/
		class FATFileSystem : public FileSystemLike {

STORAGE: Merging feature-storage branch commits to master #3762

STORAGE: Merging feature-storage branch commits to master #3762

Conversation

simonqhughes commented Feb 13, 2017 • edited Loading

Description

Background Information

Status

simonqhughes commented Feb 13, 2017

geky commented Feb 14, 2017 • edited Loading

simonqhughes commented Feb 17, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xc0170 commented Feb 20, 2017 • edited Loading

simonqhughes commented Feb 21, 2017 • edited Loading

sg- left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sg- commented Feb 22, 2017

c1728p9 commented Feb 23, 2017

geky commented Feb 23, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xc0170 commented Feb 23, 2017

adbridge commented Feb 23, 2017

geky commented Feb 23, 2017

mbed-bot commented Feb 23, 2017

bridadan commented Feb 23, 2017

sg- commented Feb 23, 2017

mbed-bot commented Feb 24, 2017

Output

geky commented Feb 24, 2017

geky commented Feb 24, 2017

bridadan commented Feb 24, 2017

bridadan commented Feb 24, 2017

bridadan commented Feb 24, 2017

bridadan commented Feb 24, 2017

0xc0170 commented Feb 24, 2017

mbed-bot commented Feb 24, 2017

Output

0xc0170 commented Feb 24, 2017

adbridge commented Feb 24, 2017

adbridge commented Feb 24, 2017

adbridge commented Feb 24, 2017

bridadan commented Feb 24, 2017

mbed-bot commented Feb 24, 2017

Output

geky commented Feb 24, 2017

LMESTM commented Mar 6, 2017

simonqhughes commented Feb 13, 2017 •

edited

Loading

geky commented Feb 14, 2017 •

edited

Loading

simonqhughes commented Feb 17, 2017 •

edited

Loading

0xc0170 commented Feb 20, 2017 •

edited

Loading

simonqhughes commented Feb 21, 2017 •

edited

Loading

geky commented Feb 23, 2017 •

edited

Loading