add set_vector_table_offset()

[xiongyihui]

when using a bootloader, tock os may need to relocate interrupt
vector table, then use this function to do that.

See the discussion at google/OpenSK#3

Pull Request Overview

This pull request adds add set_vector_table_offset function to relocate interrupt vector table.

Testing Strategy

TODO

TODO or Help Wanted

N/A

Documentation Updated

• Updated the relevant files in /docs, or no updates are required.

Formatting

• Ran make formatall.

[bradjc]

offset is really an address, correct? Should the argument be a pointer?

[xiongyihui]

VTOR is Vector Table Offset Register

Not sure if the offset is an address or not

[bradjc]

ARM specifies it as an offset, but that offset appears to always be from 0. I think it is more clear of an API if we take a pointer as an argument, which is the location the vector table is now at.

[xiongyihui]

Still new to Rust, not sure what pointer type should be used? *const c_void or *const u32?

[alevy]

probably *const ().

[bradjc]

Thanks, and this is a useful function. I checked how the tock bootloader works and it just uses assembly to set the new vector table, so it would not compile for non cortex-m boards currently. Along those lines, we eventually need some mechanism to expose this functionality outside of the arch/ crate so that a generic bootloader could use.

And then just as a side note, I ask that you do not truncate the PR template because sometimes there are documentation needs that are not immediately obvious. In this case we do not need to update documentation, however.

[ppannuto]

One thing we'll need to think about at some point is that cortex-m0 does not have a VTOR -- or really more generally that the SCB surface among the M0 and M3/M4 varies:

Right now we just don't export the SCB to the m0 crate, but this is really the same problem that we're running into with nrf variants as well...

[xiongyihui]

I thought Tock can not be run on a cortex-m0 microcontroller which doesn't have a MPU. Is this right?

[rajivr]

I thought Tock can not be run on a cortex-m0 microcontroller which doesn't have a MPU. Is this right?

I have Tock running on M0 mostly for testing and experimentation purposes.

Yes, there is no MPU, so you won't get hardware memory protection for user processes. All that is needed is to do the following in chip.rs

    fn mpu(&self) -> &Self::MPU {
        &()
    }

The other (annoying) issue with M0 is the lack of atomics. I am glad to see OpenTitan including atomic support into its core.

[bradjc]

Yeah I don't think we need to base any Tock design decisions on cortex-m0, it is just too constrained.

[bradjc]

I think a pointer API makes more sense and is clearer for users. Let me know if you think it is better to expose the ARM interface.

[alevy]

I agree with @bradjc that the parameter should be a pointer. Otherwise, I think this is an easy merge once that's fixed.

[xiongyihui]

as @alevy suggested, changed it to *const ()

An example to use it:

extern "C" {
    // _estack is the start of interrupt vector table
    fn _estack();
}

scb::set_vector_table_offset(_estack as *const ());

[alevy]

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push