Question: Richer memory region metadata

[aq1018]

I've been working on a Rust bootloader for CH32 MCUs and ran into what seems like a metadata gap in ch32-data: some flash-related regions and address distinctions are difficult to represent cleanly with the current Memory model.

In particular, CH32 user flash has both:

• an execution view (CPU-visible alias, typically 0x0000_0000)
• a programming view (flash controller address, typically 0x0800_0000)

There are also other regions that would be useful to describe more explicitly in metadata, such as:

• system flash / bootloader region
• option bytes
• vendor bytes

Right now, downstream tools tend to reconstruct this with internal offsets, special cases, or incomplete target descriptions. That works, but it makes it harder to build consistent support across HALs, linker scripts, probe-rs flash algorithms, and bootloaders.

What I'm asking

I'd like to ask whether the community agrees that this is a real gap worth addressing in ch32-data, and if so, what the least invasive solution would be? I came up with a possible solution, but I feel it's too invasive, and there should be better solutions. Thus I'm asking the question here.

To get the discussion started, here is my invasive solution:

My Solution

One idea I explored was extending Memory so it can describe both execution and programming views more explicitly. For example:

• redefine address as the programming address
• add optional fields such as exec_address and exec_primary

That would allow concepts like:

• address: real flash programming address
• exec_address: execution alias
• exec_primary: marks the main executable flash region

However, I don't want to over-prescribe this approach. It seems workable, but also fairly invasive, and it would likely require coordinated compatibility work in downstream code generation and tooling.

So I am treating this more as an example direction than a concrete proposal.

Questions

• does the community think ch32-data should represent these distinctions more explicitly?
• if yes, what would be the simplest / cheapest way to do it? Another structure? Something completely different?
• is schema extension the right direction, or is there a less invasive approach?

I've already done a much deeper analysis of the downstream implications and possible migration strategies for this solution, and I'm happy to write that up if you guys are curious, but I have to warn you, it's not pretty...

Lastly, I'd be happy to help implement and maintain whichever approach the community prefers since I'm working on a few CH32 related open source projects.

[ExplodingWaffle]

In general I agree. The main thing I would try first to contain the "blast radius" to just ch32 build + flashing stuff would be to try and see if LMA/VMA (1, 2) can be made to work, so no special casing etc would be required.

[aq1018]

@ExplodingWaffle I've already tried to tackle the LMA/VMA differences by modifying both memory.x and link.x, and I was able to get it compile and run without problems using embassy / ch32-hal

TL;DR

• Modify FLASH address to 0x08000000 in memory.x.
• Add CODE : ORIGIN = 0x00000000, LENGTH = 16K to MEMORY section in memory.x.
• Modify >FLASH AT>FLASH to >CODE AT>FLASH in link.x
• Modify .vector_table ORIGIN(FLASH) to .vector_table ORIGIN(CODE) in link.x.

Full working demo here: https://github.com/OpenServoCore/memory-layout-ch32

Notes

• I used defmt-rtt, and there was a separate issue due to .uninit section not being ignored, hence the objcopy --only-section workaround. See README.md in the demo report for more details, as well as a proper fix ( require adding NOLOAD for .uninit in link.x file.
• probe-rs won't flash due to internal address translations and is expected, but wlink works fine. I would love to contribute and maintain ch32-rs/flash-algorithms and integrate it with ch32-metapac if that's the direction you guys like to go, btw.
• This demonstrates that LMA/VMA is possible, but I know to pull this off, we still need coordinated updates to ch32-data, kingke-rt, as well as flash-algorithms to minimize the blast radius.

[aq1018]

@andelf @ExplodingWaffle any feedback would be greatly appreciated!