Skip to content

M2351: Override wait_ns to provide more accurate implementation #10741

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

Merged
merged 1 commit into from
Jun 19, 2019

Conversation

ccli8
Copy link
Contributor

@ccli8 ccli8 commented Jun 3, 2019

Description

At high HCLK rate, M2351 cannot provide zero-wait-state flash performance. Besides, its cache is forcibly turned off for non-secure land for internal reason. To pass mbed-os-tests-mbed_platform-wait_ns test, we locate delay_loop_code code from flash to SRAM to achieve zero-wait-state performance.

Pull request type

[X] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Related PR

Dependent on #10683

At high HCLK rate, M2351 cannot provide zero-wait-state flash performance. Besides,
cache is forcibly turned off for non-secure land for internal reason. We locate
'delay_loop_code' from flash to SRAM to achieve zero-wait-state performance.
@ciarmcom ciarmcom requested review from Ronny-Liu and a team June 3, 2019 11:00
@ciarmcom
Copy link
Member

ciarmcom commented Jun 3, 2019

@ccli8, thank you for your changes.
@Ronny-Liu @ARMmbed/mbed-os-maintainers please review.

};

/* Take the address of the code, set LSB to indicate Thumb, and cast to void() function pointer */
#define delay_loop ((void(*)()) ((uintptr_t) delay_loop_code | 1))
Copy link
Contributor

Choose a reason for hiding this comment

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

I had a change for the main implementation that micro-optimises (nano-optimises?) this - not sure if it didn't land or you're based on old code.

If you use + 1 instead of | 1 that can be done at link time, rather than run-time. (The linker can offset symbols, but not bit-manipulate them). Saves 1 instruction and cycle.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not see the change on master. Still go with | 1.

@kjbracey
Copy link
Contributor

kjbracey commented Jun 4, 2019

I guess it isn't possible to come up with a scaling factor that lets you still use ROM and not mess with the MPU?

Another thought - should this be conditional on being non-secure (DOMAIN_NS == 1)? Is the secure side getting cached at the minute? Also a non-TrustZone image (which is now possible) should presumably also be able to have the cache on.

@ccli8
Copy link
Contributor Author

ccli8 commented Jun 5, 2019

Another thought - should this be conditional on being non-secure (DOMAIN_NS == 1)? Is the secure side getting cached at the minute? Also a non-TrustZone image (which is now possible) should presumably also be able to have the cache on.

On M2351, cache is on for secure land but off for non-secure land. The wait_ns.c file is placed under TARGET_M23_NS directory, which is scanned only in non-secure build. M2351 non-TrustZone code can be seen as secure-only code, so it doesn't need the wait_ns override.

@kjbracey
Copy link
Contributor

kjbracey commented Jun 5, 2019

Thanks, missed that this was in TARGET_M23_NS.

@ccli8
Copy link
Contributor Author

ccli8 commented Jun 11, 2019

@kjbracey-arm Any update?

@adbridge
Copy link
Contributor

#10683 is merged so this can go into CI.

@adbridge
Copy link
Contributor

CI started.

@mbed-ci
Copy link

mbed-ci commented Jun 19, 2019

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts

@ccli8
Copy link
Contributor Author

ccli8 commented Jun 20, 2019

One thing to note. This PR depends on #10683. #10683 is to release in mbed-os-5.14.0, but this PR is to release in mbed-os-5.13.1. Correct it?

@evedon
Copy link
Contributor

evedon commented Jul 14, 2019

This PR should have been targeted for mbed-os-5.14.0 as noted in the comment above.
This is causing build failures of mbed-os-5.13.1 release candidate

@ccli8 ccli8 deleted the nuvoton_m2351_wait-ns branch July 15, 2019 01:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants