Author Topic: BOOT_MAIL_BOX location  (Read 2242 times)

Offline Caleb

  • Newbie
  • *
  • Posts: 7
    • View Profile
BOOT_MAIL_BOX location
« on: March 22, 2022, 09:01:44 PM »
 Hi there,
   In the i.MX RT series, the BOOT_MAIL_BOX and other persistent memory locations are up at the top of memory, above the stack.  This poses a bit of a problem in that the bootloader and the applications need to have the same memory configuration.  For example, on the 1062, it's up at 0x20077ffe by default, which requires the DTC be set differently from the chip default.

Is there any reason I can't change the fnGetPersistentMemory fucntion to get it from one of the lowest areas in memory, that's not already taken?  This would mean it's independent of how DTC and ITC are configured?

Thanks
 -Caleb

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: BOOT_MAIL_BOX location
« Reply #1 on: March 22, 2022, 09:32:19 PM »
Hi Caleb

In fact the boot loader and application can have different memory bank layouts as long as the persistent memory (mail box) is always located at the top of the DTC or the FlexRAM layout is left unchanged.
For this to work (with reconfigured banks) the only requirement is the ordering of the banks - see section RAM and Cache in https://www.utasker.com/docs/iMX/i.MX_RT_1060_uTasker.pdf (although I think that the OCRAM addresses may be incorrect in the image since OCR in the 1062 starts at 0x20280000)

From the diagrams there it is seen that as long as the banks are used in the order IIIIDDD (however many banks are allocated to I) the persistent memory is located at the top of the last D bank.
The absolute address changes of course but the relative address (referenced to the top of D bank memory) remains the same.

fnGetPersistentMemory() returns the memory content relative to the top of memory (it simply assumes that the present stack is there, which would normally be the case).

The boot loader uses the chip's default memory layout and the application can also use it too, as long as its stack pointer is set to the same.

Beware that as banks are reconfigured their absolute addresses change, meaning that if a different strategy were used the absolute address of the boot loader's banks would move around as the application uses different layout and this is the reason for choosing this strategy so that it is (irrespective of how the application configures its bank usage - which can change as a project develops [but respecting the order the banks so that D is always the last]) in fact already solved.

Regards

Mark