trezor-firmware icon indicating copy to clipboard operation
trezor-firmware copied to clipboard

Alter distribution of code into .flash and .flash2 sections

Open grdddj opened this issue 3 years ago • 2 comments

Currently, with both the TT redesign and model R development, we are transferring UI code (and potentially other things) from micropython into Rust.

Rust code resides in .flash and micropython code in .flash2 regions/sections. As we make the transition, .flash is overflowing while .flash2 has (will have) a lot of free space (even more after implementing https://github.com/trezor/trezor-firmware/issues/15).

We might want/need to take some stuff from .flash and put them into .flash2 to level it out (or most importantly avoid .flash overflowing).

grdddj avatar Jul 28 '22 08:07 grdddj

Please note that .flash is in in rx segment while .flash2 is in r, so we can't move executable code there.

I think there's a gap between these two segments so we can't adjust the sizes by moving a boundary. However it seems to me that we could swap them entirely:

  • .flash 768K -> 896K (+128K)
  • .flash2 896K -> 768K (-128K)

mmilata avatar Sep 09 '22 11:09 mmilata

We can change MPU to have .flash2 set to rx.

hiviah avatar Sep 12 '22 17:09 hiviah

seems to me that both .flash and .flash2 are already executable or am i missing something?

TychoVrahe avatar Sep 29 '22 20:09 TychoVrahe

You're right, .flash2 doesn't have NX flag.

hiviah avatar Sep 29 '22 21:09 hiviah

Ah, so the beginning of memory_T.ld does not actually correspond to the memory controller configuration?

MEMORY {
  FLASH  (rx)  : ORIGIN = 0x08040000, LENGTH = 768K
  FLASH2 (r)   : ORIGIN = 0x08120000, LENGTH = 896K
  CCMRAM (wal) : ORIGIN = 0x10000000, LENGTH = 64K
  SRAM   (wal) : ORIGIN = 0x20000000, LENGTH = 192K
}

mmilata avatar Sep 30 '22 15:09 mmilata

found some explanation here: http://web.mit.edu/rhel-doc/3/rhel-ld-en-3/memory.html

tldr: this instructs the linker to place sections which are not explicitly mapped into regions into the regions defined here according to the attributes.

since we are mapping all the sections explicitly later in SECTION, with >FLASH etc, this should not have impact.

once the binary is loaded to the device, executability is controlled by MPU, where it is allowed for both regions.

we could define the FLASH2 as (rx) to make it clearer though.

TychoVrahe avatar Sep 30 '22 20:09 TychoVrahe