as you point out the linker variables are of no use to you - the bootrom is an independently linked program in it's own right. Four possible solutions spring to mind, each with their own merits and drawbacks:
1) Have your application scan the OTP flash memory, from the end of that region back towards the beginning, looking for the first location that is not 0xFFFFFFFF.
2) When you build your application, have your "make" script get the size of the rom image binary file in your file system, and use that value.
3) Add a "maigic" sequence of bytes at the end of the bootrom code (we supply the source code, you can make your own changes) and have your application scan the OTP flash memory for that sequence.
4) Modify the bootrom code to pass the end address to the application when it transfers control at the end of startup. You can see this code in the file
inside the rom_startup() function.
Step 4) would be trickier but the more elegant solution to my mind, as it will be faster and less prone to error.
first, many thanks for all the creative ideas! Although all your suggestions seem feasible to implement, I guess you understood that I would want to get access to the end address of the ROM from firmware. Indeed, it is the other way around: I would like to get access to the end address of the FW's text segment within the ROM. I guess I will go with the approach of adding a sequence of magic bytes to the end of the FW and have the ROM code scan for it.
No problem, it's an interesting question. The 'magic number' sequence is one I have used several times in recent years, even on a very large project. We used a 128 bit sequence, and just checked that it wasn't a valid sequence of CPU instructions. I got my initials in there, and it even past a design review