Skip to content

[Pending mbed-os 5.6] Print peripheral on ACL violation from debug blinky example #54

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 2 commits into from
Oct 23, 2017

Conversation

theamirocohen
Copy link
Contributor

Print the name of a peripheral when faulting on an address belonging
to a perhipheral.
The memory maps of K64F and STM32F4 were added.

@theamirocohen
Copy link
Contributor Author

@danny4478
@romkuz01
please review

#define __MEM_MAP_H__

typedef struct mem_map {
const char *name;
Copy link

@danny4478 danny4478 Sep 10, 2017

Choose a reason for hiding this comment

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

Space after *

uint32_t end;
} MemMap;

const MemMap* memory_map_name(uint32_t addr);
Copy link

@danny4478 danny4478 Sep 10, 2017

Choose a reason for hiding this comment

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

Space before *


/* find system memory region */
map = g_mem_map;
for(i = 0; i < UVISOR_ARRAY_COUNT(g_mem_map); i++)

Choose a reason for hiding this comment

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

I would always use " { ... }", even wen not needed by compiler.
It is safer.

source/main.cpp Outdated

static void example_halt_error(THaltError reason, const THaltInfo *halt_info) {

const MemMap *map;

Choose a reason for hiding this comment

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

Space after *

source/main.cpp Outdated
static void example_halt_error(THaltError reason, const THaltInfo *halt_info) {

const MemMap *map;
map = memory_map_name(halt_info->bfar);

Choose a reason for hiding this comment

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

Are we sure here that bfar is valid?

map = g_mem_map;
for(i = 0; i < UVISOR_ARRAY_COUNT(g_mem_map); i++)
if((addr >= map->base) && (addr <= map->end))
return map;
Copy link
Contributor

Choose a reason for hiding this comment

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

same goes for if statements - braces ARE mandatory for all block statements - also for single line cases

@Patater
Copy link
Contributor

Patater commented Sep 12, 2017

"Print peripheral on ACL violation from debug fault example"

Shouldn't this PR be against the debug fault example?

@theamirocohen
Copy link
Contributor Author

Hi,

@alzix instructed me to use the basic uVisor example from uvisor repo

@Patater
Copy link
Contributor

Patater commented Sep 12, 2017

Please update the commit message to reflect this, then.

Thanks

@theamirocohen theamirocohen changed the title Print peripheral on ACL violation from debug fault example Print peripheral on ACL violation from debug blinky example Sep 13, 2017
@alzix
Copy link
Contributor

alzix commented Sep 13, 2017

Hi @Patater ,
our debug-fault example faults on arbitrary address - thus this addition would not be helpful at all.
On the other hand mbed-os-example-uvisor is mentioned in our porting guide - thus porting engineers most likely will start with it and at first stages run in to some faults.
We are open for suggestions.

@Patater
Copy link
Contributor

Patater commented Sep 13, 2017

@alzix Makes sense to me. Not sure how valuable the separate debug fault example is with this change, though.

@mikisch81
Copy link

@Patater I think the debug fault example is still useful as it's an example which explicitly shows a fault scenario.
The mbed-os-example-uvisor normally should not fault, BUT if it does faults (usually because of missing ACL entry) we need to show what is the expected output.

@Patater
Copy link
Contributor

Patater commented Sep 13, 2017

@mikisch81 @alzix
Our old uVisor example, where pressing the button made the system try to access something it shouldn't and fault, would be a good place for a debug box example. But, the memory map isn't really needed there, as the example touches another box's SRAM and not a peripheral.

It'd probably be best to modify our debug fault example to poke some unowned peripheral instead of 0xFFFFFFFF, that way we could use a memory map like this. The IRQ example could stay simple as well without the memory map, although I agree with the porting benefits of having the memory map here too.

@theamirocohen
Copy link
Contributor Author

pending for mbed-os : mbed-os-5.6.0-rc1
depends on THaltInfo struct

@theamirocohen theamirocohen changed the title Print peripheral on ACL violation from debug blinky example [Pending mbed-os 5.6] Print peripheral on ACL violation from debug blinky example Sep 17, 2017
@alzix
Copy link
Contributor

alzix commented Oct 2, 2017

retest uvisor

@alzix alzix added the run-CI label Oct 16, 2017
@alzix
Copy link
Contributor

alzix commented Oct 22, 2017

/morph uvisor-test

alzix
alzix previously approved these changes Oct 22, 2017
@alzix
Copy link
Contributor

alzix commented Oct 22, 2017

@theamirocohen , please update mbed-os hash to point after ARMmbed/mbed-os#5275 merge

@theamirocohen
Copy link
Contributor Author

@alzix, I've updated mbed-os hash to point after ARMmbed/mbed-os#5275 merge

@theamirocohen theamirocohen force-pushed the print_peri branch 2 times, most recently from e223d20 to 8993dcf Compare October 23, 2017 07:08
@alzix
Copy link
Contributor

alzix commented Oct 23, 2017

/morph uvisor-test

1 similar comment
@alzix
Copy link
Contributor

alzix commented Oct 23, 2017

/morph uvisor-test

Print the name of a peripheral when faulting on an address belonging to a perhipheral.
The memory maps of K64F and STM32F4 were added.
@alzix alzix merged commit 57bdf06 into ARMmbed:master Oct 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants