This fix causes the script to exit if `--config` was selected.
You will need to run
`python3 -m pip install --upgrade precursorupdater`
to pull in the fix. It should be live now.
Thanks for reporting this bug.
This patch set goes across all the toolchains and brings
in the support for split SVD descriptions of SoCs.
This is helpful for dealing with designs that have multiple
"top" files for the same core IP set. For exmaple, you may have
a SoC that you are developing that targets silicon, but
you have a version that wraps this in additional peripherals
available only in an FPGA emulator that are used for debugging.
In this case, you can have one SVD file be the description of
the SoC itself, and another SVD file describe just the "delta"
introduced by the FPGA wrapper that emulates/controls the SoC.
- make the "base" field no longer public. It is accessible, but only
through an `unsafe` method, because, it is unsafe.
- add accessors to offest/mask fields. Because, it's not at all
unsafe to access these, and it can be useful for bit-ops that are
not part of the generic set of UTRA.
- add Arc to AtomicCSR, and require `std` for AtomicCSR types.
This should not break anything, I checked inside @foundation-devices
keyOS and they don't seem to be using AtomicCSR anywhere.
The Arc makes it a bit safer to clone the AtomicCSR base pointer
and share it between threads, but it will have an impact on performance.
The USB stack (which requires AtomicCSR) was regression testing and the
impact seems minimal.
Recall that the main purpose of AtomicCSR is to provide a CSR accessor
that does not require a mutable reference to the base object. This
can make certain Rust idioms a bit cleaner. We wrap the base accessor
in Arc+Atomic to try and improve the safety of throwing the borrow
checker under the bus, but it's still not perfect because hardware
mutable state can have side-effects within hardware itself that cannot
be modeled or checked by Rust's borrow checker.
this somehow causes the build to break, and I just checked and
I don't see warnings on our build. There must be some config
differences on hosts, but I'm not sure what it is...
quick-xml 0.19.0, a dependency of svd2utra, uses features
that Rust will deprecate.
Unfortunately, the only versions of quick-xml that do not
use the deprecated language features also break a portion
of the API. In particular, quick-xml will no longer take
a `File` as an input: it will only take a `Path`.
This means that the API for svd2utra is also broken, because
originally it was designed to take a `File`
This patch refactors svd2utra to work with the latest quick-xml,
but also breaks any code that calls svd2utra's generate
APIs.
Fortunately this is fairly easy to fix, the calling code
will typically already have the Path somewhere in it, so
instead of opening the Path and passing it into the function,
one may simply pass in the Path.
this commit adds the facilities to extract eh_frame[_header]
sections and pass it to each process.
A bump is required to `std` to extract the passed parameters.
Sections of the MiniElf are now aligned as required by the
source ELF requirements. This is required for direct-mapping
with XIP.
the overhead is just a few bytes every couple of programs, so it's
a small price to pay for XIP.
figured out a way to modify the trait so that alignments
are 0 by default, and only set/reported for IniF,
on a per-process basis so if for some reason the alignments
change we should be OK.
Turns out, the pointing end of the stick for ELF sections don't start
at a page boundary. For example:
5 IniF: entrypoint @ 0001e42e, loaded from 000440f4. Sections:
Loaded from 000440f4 - Section .rodata 16924 bytes loading into 000100f4..00014310 flags: NONE
Loaded from 00048310 - Section .eh_frame_hdr 1772 bytes loading into 00014310..000149fc flags: NONE
Loaded from 000489fc - Section .eh_frame 6004 bytes loading into 000149fc..00016170 flags: NONE
Loaded from 0004a170 - Section .text 59876 bytes loading into 00017170..00025b54 flags: EXECUTE
Loaded from 00058b54 - Section .sdata 48 bytes loading into 00026b54..00026b84 flags: WRITE
Loaded from 00058b84 - Section .sbss 48 bytes loading into 00026b84..00026bb4 flags: WRITE | NOCOPY
Loaded from 00058bb4 - Section .bss 516 bytes loading into 00026bb8..00026dbc flags: WRITE | NOCOPY
Here you can see, the data is "loading into" 0x100f4, not
0x10000. The original PR would align things to a page, which means
you'd still have an offset mismatch if you tried to map these directly
over.
This patch causes IniF to insert extra padding to target
the offset necessary for the MiniElf to map 1:1.
An important assumption is the offset is constant across all
programs being linked. This seems to be the case, but, if this
assumption breaks, then the padding will also break.
