Fix: change nucleo_u545re_q board memory address to secure region

[genan2003]

Pull Request Overview

This Pull Request changes the flash address of the nucleo_u545re_q board to secure region. The addresses were taken from the memory layout of the board.

TODO or Help Wanted

This pull request still needs review.

[lschuermann]

I see now where the "alias" vs. "mapping" confusion came from in the other PR. Does this chip actually alias the exact same flash at two addresses? I.e., a write to one address will modify the contents at the other as well?

In that case, you want to use "mapping" when talking about the 0 address, but then use "alias" to talk about the actual hardware aliasing.

I don't want to be too pedantic, but it's worth being precise here. Addressing and flash mappings are already complicated enough to understand. :)

[genan2003]

I see now where the "alias" vs. "mapping" confusion came from in the other PR. Does this chip actually alias the exact same flash at two addresses? I.e., a write to one address will modify the contents at the other as well?

In that case, you want to use "mapping" when talking about the 0 address, but then use "alias" to talk about the actual hardware aliasing.

I don't want to be too pedantic, but it's worth being precise here. Addressing and flash mappings are already complicated enough to understand. :)

What is happening here is the following: when we try to flash an application to this board it will work even if we put in the address that was before(non-secure address) or in the address that is now(secure address taken from the layout.ld of the board). I don't think that if we flash to one address will influence the other address, so let me know which one do you think is better to use here.

[lschuermann]

@genan2003 This has me confused. The kernel looks for the TBF chain starting at one particular address, right? So, if you can flash an app at address A, and the kernel is able to pick it up at address B, that sure sounds like there is some hardware flash aliasing going on here?

Another question this raises: what's the benefit of this change? Why prefer one address over another?

[alexandruradovici]

This is related to how stm32 works with secure and non-secure memory. They alias the whole memory sections at two addresses, one secure and one non-secure. As Tock currently runs only in secure mode (this is how the chip starts), it does not matter where you read it from. This change makes the address in sync with Tock's linker script.

https://github.com/tock/tock/blob/2b711261d7dd43da05eab5eb1a14961340144633/boards/nucleo_u545re_q/layout.ld#L12-L17

[lschuermann]

Thanks @alexandruradovici, that matches my understanding. In this case, one small nit, otherwise this looks good!