| Age | Commit message (Collapse) | Author |
|---|
|
The vector tables exported by imxrt-ral are smaller than the default
cortex-m-rt vector table. The tests fail once we enable the rt / device
features. With this change, we expect the MCU-dependent vector table sizes.
|
|
The layout, or assignment of FlexRAM banks to memory regions, is more
precise than the count. When a user specifies the count, we still apply
the same layout as we always have. But now, by default, we prefer the
fuse layout for users who have made no choice.
This commit supports RAM loading with probe-rs. After probe-rs resets
the MCU and uses the fuse FlexRAM layout, firmware can perfectly match
that layout without disrupting the data already copied into RAM by the
debugger.
|
|
|
|
Just a proof-of-concept. The new inspect_elf test seems to show that
we're building the correct image. We need another commit in order to
help the program run in FlexRAM.
|
|
|
|
The runtime previously allowed function placement at address 0 in ITCM.
However, if you ever formed a pointer to the function placed there, it
would look like a null pointer. And you would never be able to call that
function if you relied on null pointer optimization. Also, most MCU
reference manuals (RM) recommend against this placement.
This commit reduces the total capacity of ITCM by 32 bytes, the smallest
possible size of a MPU region. Note that this is greater than the RM's
recommendation of a four byte reservation. It affects all supported
MCUs, except the 1180. If you're so inclined, your MPU could disallow
loads, stores, and execution from this reservation.
Revised unit tests should cover this change. Additionally, you can
manually verify that the ITCM region lengths are reduced by 32 bytes by
opening the linker scripts generated by the ELF test suite.
|
|
|
|
Applications linked through this builder can be placed in a flash
reservation. You'll need some other software to launch these programs,
since they lack the boot header required by the NXP boot ROM.
|
|
We added the `.xip` section to ensure that the reset handler and
pre-init functions would be placed in flash. This commit lets users
place other content into that section.
`.xip` is intended for instructions. The runtime builder will place
these instructions into the same load region as `.text`. However,
there's no pre-`main` relocation.
Aligning the `.xip` and the `.text` section produces more predictable
behavior between GNU's ld and LLVM's lld.
|
|
There's no requirement for 16 byte-aligned read-only data, and this is
the only assertion expecting that requirement. Reducing the requirement
lets the test pass when the image is built with a Rust 1.82 toolchain.
|
|
If you define a runtime, you can call `stack_size_env_override` to
define an optional environment variable checked by the runtime builder.
Same goes for the heap. A user can set these environment variables to
override the runtime's stack / heap size. You can use this package's
examples to try it out; see the updated build script.
There's no default environment variable for either memory region. The
package that defines the runtime needs to opt-in to this feature.
|
|
Haven't fully dug into this one, but GNU ld and LLVM lld have slightly
different section positions when we cross from text to data. We can
relax the asserts to show ordering without strictly requiring an offset.
|
|
Depending on the ordering and contents of program headers, the previous
predicate for "is this the program header for this section?" could
select the wrong header. GNU's ld and LLVM's lld produce that different
header ordering and contents, causing select asserts to fail when using
GNU's linker.
This commit changes how we select the program header, approximating the
way GNU objdump figures the value. This new approach needs more
information from the section header, so I'm changing the API to make it
easier to call the section_header method.
The previous approach was influenced by LLVM objdump. Turns out that
LLVM objdump will also compute the wrong LMA for these binaries when
they're linked with GNU ld. GNU objdump always produces the correct
section LMA, no matter the LLVM or GNU linker.
|
|
Users can define their device configuration data (DCD), and place the
data in the .dcd section. If the .dcd section has content, the entry in
the IVT points at the user's DCD. This plays well with imxrt-dcd.
|
|
|
