Skip to content

support for ubirch boards #4183

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

Closed
wants to merge 0 commits into from
Closed

support for ubirch boards #4183

wants to merge 0 commits into from

Conversation

thinkberg
Copy link
Contributor

Description

Add support for our ubirch boards. UBRIDGE is a board with a K82F, GSM modem and some other parts that is programmed via USB (using an adapter board based on a K20DX). USENSE is a small form factor low-power sensor module with a KL82z MCU and sub-1GHz RF.

The changes include a fix in the debug uart settings, allowing for boards without external oscillator. It also enables the TRNG in the K_82 MCU for mbed.

Status

IN DEVELOPMENT

Migrations

NO

Todos

  • Tests
  • Documentation

@0xc0170
Copy link
Contributor

0xc0170 commented Apr 18, 2017

@thinkberg Can you please sign https://developer.mbed.org/contributor_agreement/ ?

Please rebase (remove the merge commits to update this patch), to be on top of the current master.

@thinkberg
Copy link
Contributor Author

I hope the modifications are now as expected.

@0xc0170
Copy link
Contributor

0xc0170 commented Apr 24, 2017

retest uvisor

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.

Just minor things, but what we would like to see : test results. How these 2 new boards were tested

@@ -0,0 +1,113 @@
/* mbed Microcontroller Library
* Copyright (c) 2006-2013 ARM Limited
Copy link
Contributor

Choose a reason for hiding this comment

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

be careful when copying this, year should be 2017 as it's new file

"UBRIDGE": {
"core": "Cortex-M4F",
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "K82F", "UBRIDGE"],
Copy link
Contributor

Choose a reason for hiding this comment

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

UBRIDGE should not be needed

"USENSE": {
"core": "Cortex-M0+",
"supported_toolchains": ["ARM", "GCC_ARM", "IAR"],
"extra_labels": ["Freescale", "MCUXpresso_MCUS", "KL82Z", "USENSE"],
Copy link
Contributor

Choose a reason for hiding this comment

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

USENSE here should not be needed

@0xc0170
Copy link
Contributor

0xc0170 commented Apr 24, 2017

/morph test

@mbed-bot
Copy link

Result: FAILURE

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

/morph test

Output

mbed Build Number: 79

Build failed!

@0xc0170
Copy link
Contributor

0xc0170 commented Apr 25, 2017

@thinkberg Please look at failures (the link provided in the test result above), there are failures for usense and k82 platform

@theotherjimmy
Copy link
Contributor

@thinkberg Have you had a chance to look at these failures?

@thinkberg
Copy link
Contributor Author

An issue is that if the RTC feature is not enabled, the problems occur. I have enabled rtc as the current version of usense does have an rtc.

@theotherjimmy
Copy link
Contributor

@thinkberg This PR contains commits that are currently on master. Could you rebase to resolve this?

@thinkberg
Copy link
Contributor Author

I did a rebase, I hope this is resolved now.

@theotherjimmy
Copy link
Contributor

It still looks like things went wrong. It looks like you started at 4c0ccf0, but you have a tonne of commits before then. I wonder what went wrong. Did you do git rebase origin/master?

@thinkberg
Copy link
Contributor Author

Strange, how about I fork a fresh copy and add my changes fresh?

@theotherjimmy
Copy link
Contributor

If you'll let me, I can fix the current PR. Would you like me to do that for you?

@thinkberg
Copy link
Contributor Author

thinkberg commented May 12, 2017 via email

@theotherjimmy
Copy link
Contributor

@thinkberg I have been digging through the history now for a few minutes. Here's what I think happened:

  1. you correctly rebased onto master (yeah!)
  2. you tried to push to github
  3. it complained, telling you to pull first (you should not do this after a rebase)
  4. you pulled, and merged the new series with the old (duplicating the commits, with different hashes)
  5. you pushed this duplicated history to github.

I think that process happened 8(!) times.

@thinkberg
Copy link
Contributor Author

thinkberg commented May 12, 2017 via email

@theotherjimmy
Copy link
Contributor

Instead, the process you should go through is:

  1. rebase
  2. force push to github

That's it :)

@thinkberg
Copy link
Contributor Author

thinkberg commented May 12, 2017 via email

@theotherjimmy
Copy link
Contributor

Just a moment, wrong branch

@theotherjimmy
Copy link
Contributor

Dang, now I can't push because this PR is closed.

@theotherjimmy
Copy link
Contributor

Re-opened at #4315

@thinkberg
Copy link
Contributor Author

thinkberg commented May 12, 2017 via email

@theotherjimmy
Copy link
Contributor

I re-opened the PR, with the new history. I hope it's correct.

@theotherjimmy
Copy link
Contributor

You should still have a copy of the old history on your machine. That was a terrible mistake on my part.

I did git push -u ubridge master when I should have done git push -u ubridge ubridge-master:master

@thinkberg
Copy link
Contributor Author

Should I do something?

@theotherjimmy
Copy link
Contributor

Could you take a look at #4315 And tell me if I missed anything?

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.

5 participants