Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release candidate for mbed-os-5.15.1 #12372

Merged
merged 72 commits into from
Feb 7, 2020
Merged

Release candidate for mbed-os-5.15.1 #12372

merged 72 commits into from
Feb 7, 2020

Conversation

adbridge
Copy link
Contributor

@adbridge adbridge commented Feb 5, 2020

Summary of changes

Release candidate

Impact of changes

Migration actions required

Documentation

None


Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[x] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers


jeromecoutant and others added 30 commits February 5, 2020 14:40
Update the CMSIS-pack info to `index.json` in arm_pack_manager -folder.
The update happens via python project.py --update-packs and a modified
version of the cmsis-pack-manager tool, which allows the download of
(most) CMSIS-pack files. The changes for this family ONLY are then updated
to the `index.json` -file.

Mbed OS PR #12093 need this change, as they refer to a target (device_name)
from the updated CMSIS-packs.

Ref: #12093
Rather than wait 10ms before breaking the other thread, and expecting at
least one event to have been run, wait for one event to be run, then
break.

Should avoid some spurious failures that have been seen.
Replaced a hardcoded timeout in CyH4TransportDriver.cpp with a cypress
hal function. The cypress PUTC hal API only blocks until data has been
send into the HW buffer, not until all data has been out of the HW
buffer. Modified an API to block untill all tx transmit is complete.
This allows the removal of a hardcoded timeout in
CyH4TransportDriver.cpp that waits for data int the HW buffer to be
sent.
…evelopment kit using [Samsung Exynos i S111](https://www.samsung.com/semiconductor/minisite/exynos/products/iot/exynos-i-s111/) module to Mbed-OS. This will widen the HW choices of Mbed-OS enabled NB-IoT, GNSS and Security (eFuse, AES, SHA-2, PKA, Secure Storage, Security Sub-System, [PUF](https://en.wikipedia.org/wiki/Physical_unclonable_function)) modules. Target Name: S5JS100

Co-authored-by: Ivan Galkin <ivan.galkin@samsung.com>
Co-authored-by: Seokwon Lee <swon.lee@samsung.com>
Co-authored-by: Zhizhe Zhu <zhizhe.zhu@samsung.com>
Co-authored-by: Xinyi Zhao <xinyi.zhao@samsung.com>
Signed-off-by: PARKJIHOON <jh6186.park@samsung.com>
Signed-off-by: PARKJIHOON <jh6186.park@samsung.com>
Signed-off-by: PARKJIHOON <jh6186.park@samsung.com>
Signed-off-by: PARKJIHOON <jh6186.park@samsung.com>
Signed-off-by: PARKJIHOON <jh6186.park@samsung.com>
0xc0170
0xc0170 previously approved these changes Feb 6, 2020
Copy link
Contributor

@0xc0170 0xc0170 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new 2 commits LGTM

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 6, 2020

CI started, but realized right after we dont have psa bins yet updated (might not need an update). If needed, lets abort and restart

@mergify mergify bot added needs: work and removed needs: CI labels Feb 6, 2020
@mbed-ci
Copy link

mbed-ci commented Feb 6, 2020

Test run: FAILED

Summary: 3 of 4 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_build-ARM
  • jenkins-ci/mbed-os-ci_build-GCC_ARM
  • jenkins-ci/mbed-os-ci_build-IAR

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 7, 2020

I am investigating 2 failures there, both new targets.

return ret;
}

<<<<<<< cd37b0cf8e0be356705b7c17c0871c8f3acc03fa
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this fails in the build for Samsung target

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 7, 2020

Second failure, NUCLEO_L552ZE_Q fails to build:

[DEBUG] Output: ./mbed-os/targets/TARGET_STM/mbed_rtx.h:140:2: error: "INITIAL_SP is not defined for this target in the mbed_rtx.h file"

#12140 - this clean up for 6.0.0 might be needed for 5.15 or the target be fixed. As the PR is simple fix, I'll try locally and we should move it to 5.15.1

cc @ARMmbed/team-st-mcd

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 7, 2020

cherry-picking PR 12140 - build problem fixed.

Also removing conflict resolution from Samsung, fixed the build issue.

I'll push these 2 here.

@mergify mergify bot dismissed 0xc0170’s stale review February 7, 2020 10:30

Pull request has been modified.

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 7, 2020

@adbridge PR 12140 moved to 5.15.1. Its now on this branch and also Samsung sha fixed. I restarted CI

@mbed-ci
Copy link

mbed-ci commented Feb 7, 2020

Test run: FAILED

Summary: 1 of 11 test jobs failed
Build number : 2
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_greentea-test

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 7, 2020

test restarted, RTC accuracy error for LPC. There is no change for this error, will monitor master (haven't yet seen it there recently).

[1581074556.32][CONN][RXD] >>> Running case #5: 'RTC - accuracy'...
[1581074556.42][CONN][INF] found KV pair in stream: {{__testcase_start;RTC - accuracy}}, queued...
mbedgt: :193::FAIL: Values Not Within Delta 1000000 Expected 10000000 Was 8998833
[1581074565.49][CONN][RXD] :193::FAIL: Values Not Within Delta 1000000 Expected 10000000 Was 8998833

@0xc0170 0xc0170 merged commit e642a7d into mbed-os-5.15 Feb 7, 2020
@mergify mergify bot added the release version missing When PR does not contain release version, bot should label it and we fix it afterwards label Feb 7, 2020
@mergify
Copy link

mergify bot commented Feb 7, 2020

This PR does not contain release version label after merging.

@0xc0170 0xc0170 removed the release version missing When PR does not contain release version, bot should label it and we fix it afterwards label Feb 7, 2020
@0xc0170 0xc0170 deleted the release-candidate branch October 5, 2021 08:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.