• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 219 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MCU-PLUS-SDK-AM243X: extracting sections with tiarm-tools for manually placing them in RAM

Felix Heil
Expert 1130 points
Part Number: MCU-PLUS-SDK-AM243X

Hello,

as a workaround for this topic: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1215733/mcu-plus-sdk-am243x-boot-from-flash-not-working-with-different-load-and-run-addresses

We thought that it may be possible to extract specified sections which have the same run- but a different load-address in the same memory-layout they would've been put at their respective load-addresses.

We are using the LTS 2.1.3 compiler toolchain.

Via CCS it is working and the sections get loaded first into the load-address and then copied in at the run-address. This does not work with rprc from flash. So the idea was to manually extract these sections beforehand after linking, put them as a separate "package" each into our own firmware-file. After a boot from flash we would be parsing the firmware-file before we would normally copy_in the sections from the load to the run-address. And the parsed "packages" would be manually placed at their respective load-addresses which are already known since the linker-generated copy-tables do exist at that point.

Would that work? I tried to investigate with tiarmreadelf to get some more info but I am not sure how those sections are arranged in the .elf-file and if we can simply extract them in the same memory-layout they would be placed automatically at the load-address.

Best regards

Felix

  • 0
    TI__Mastermind 26005 points

    Hi ,

    Can you try the same with a simple hello_world and share the project based on your expectations (what works for you with CCS) ? Let us internally do more experimentations on this front after I have received the project. If it works for us we will have a call to explain if we found any workarounds for this.

    Felix Heil said:
    After a boot from flash we would be parsing the firmware-file before we would normally copy_in the sections from the load to the run-address. And the parsed "packages" would be manually placed at their respective load-addresses which are already known since the linker-generated copy-tables do exist at that point.

    But I think that might work for you.

    Best Regards,
    Aakash

  • 0 in reply to Aakash Kedia
    Expert 1130 points

    Hey Aakash,

    yesterday I tried just some small first experiments and it worked. I did not even load it into the load-address first but directly from flash to the run-address.

    So in the linker-script we have the unions similar to the examples explained for the table()-operator in 10.8.4.4 in the compiler-documentation: https://software-dl.ti.com/codegen/docs/tiarmclang/compiler_tools_user_guide/compiler_manual/linker_description/08_using_linker_generated_copy_tables/generating-copy-tables-with-the-table-operator-stdz0750716.html#stdz0750717

    the elf-file would be generated as expected. After that I simply extract the sections off the elf-file with tiarmobjcopy like this:

    tiarmobjcopy targetName.elf --dump-section .specialSection=targetName.specialSection.bin -I elf32-littlearm -O binary

    and that's it. We can now pack those sections into our fw-update-package. After an install and new boot-up we can load them from flash and copy them directly at their run-address via the previous created copy-tables when usually the copy_in has taken place.

    I still needed to create a copy of the first created elf-file because it seems tiarmobjcopy deletes the original elf-file? At least that happened for my first try so I just made it to be sure. A next step would be to get rid of those sections in the original elf without breaking the elf. So we can reduce the size of the update-image. Currently the sections are now two times in our update-package (in original elf and the separate ones). But I will figure that out.

    At least it works exactly as expected. Also, since it's that easy to implement, we are not sure if we would still need the extra load-address and the placement of code there when booting from flash. But, when loading via CCS this would still be needed, since a change in code in one of those special sections wouldn't be in Flash at that time. So watching it from this side, the "out-of-the-box"-solution by the compiler/linker would still be the easier-to-handle-solution. But we will also think about this in the future.

    I also came across with the thought of using the DAC for the OSPI and just copying directly via memcpy from the flash-address into the internal SRAM-address since the OSPI_read also seems to use the DAC, also even if DMA is enabled when I get the code-comments correctly.

    So for now, we can live with that workaround and also can still wait until the new elf-parser is released with the december-SDK. Sorry if it may have escalated a bit too fast from us at TI-side, I really didn't think a workaround like this would work that easy. But I am impressed how good the compiler-tools work.

    Best regards
    Felix