Skip to content

Conversation

danielRep
Copy link
Member

@danielRep danielRep commented Oct 3, 2025

This PR addresses issues introduced on linker symbols when MEM_NON_UNIFIED and .datanocopy were added.

  • Add _data_(vma/lma)_end symbol to get the address of the data end address used during the data copy routine of non-unified platforms
  • Move _image_load_end to the original location right before the vm_images, allowing .datanocopy to be correctly mapped in bao's first continuous region
  • Force _dmem_phys_beg calculation to be related to the type of memory protection (mpu/mmu) of the platform and not the memory type (unified/non-unified)

Before accepting this PR, take notice on the below table, were I will be testing these changes on the below platforms that exercise those symbols for different architectures, memory protection mechanisms, and memory infrastructures to ensure the correctness of the new linkerscript file.

Plat Tested
Tricore DONE
fvp-a DONE
fvp-r DONE
fvp-a-aarch32 DONE
fvp-r-aarch32 DONE
S32Z270 DONE
RH850 DONE
qemu-aarch64-virt DONE
qemu-riscv32-virt DONE
qemu-riscv64-virt DONE

@malejo97
Copy link
Contributor

malejo97 commented Oct 7, 2025

Tested on Renesas RH850/U2A16. Working ✅

@danielRep
Copy link
Member Author

Tested on Renesas RH850/U2A16. Working ✅

Thanks @malejo97 for testing!!

This commit addresses issues introduced on linker symbols when
MEM_NON_UNIFIED and .datanocopy were added.

- Add _data_(vma/lma)_end symbol to get the address of the data
end address used during the data copy routine of non-unified
platforms
- Move _image_load_end to the original location right before the
vm_images, allowing .datanocopy to be correctly mapped in bao's
first continuous region
- Force _dmem_phys_beg calculation to be related to the type of
memory protection (mpu/mmu) of the platform and not the memory
type (unified/non-unified)

Signed-off-by: Daniel Oliveira <[email protected]>
@danielRep
Copy link
Member Author

@josecm @miguelafsilva5 This has been tested across plats and archs on bao-demos (baremetal). No issue has detected. Regarding qemu-riscv32-virt we had issues with the toolchain, and therefore we still didn't have tested correctly.

@miguelafsilva5 miguelafsilva5 self-assigned this Oct 8, 2025
@miguelafsilva5
Copy link
Member

Just tested qemu-riscv32-virt using the toolchain available here https://github.com/bao-project/bao-riscv-toolchain/releases/tag/gc891d8dc23e
It is working.

@danielRep
Copy link
Member Author

Just tested qemu-riscv32-virt using the toolchain available here https://github.com/bao-project/bao-riscv-toolchain/releases/tag/gc891d8dc23e It is working.

Thanks @miguelafsilva5 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants