• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 534 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RTOS: Sysbios boot

Guy Mardiks
Genius 4135 points
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hello,

I am working on the TDA2xx and i need to have networking capabilities on one of the M4 cores.

In order to do that we  are using NDK which requires sysBios.

I would like to replace the ducatiBoot process with my own modified implementation but i have no idea how to get read of the ducatiBoot.

What i could do so far is add my modified boot but i still had to allocating the .ductiBoot section - i could not find a way to get rid of it.

I could override most of the automatic XDC linker command file settings by setting a different setting to the same sections on my linker command file, and my command file seems to get the "upper hand".

The only problem i having is that i was not able to replace the entry-point. from some reason the entry point set by the XDC linker file is not overwritten by any setting i make either on my linker file or as passing a linker command file parameter.

It would be best if there is a way to completely get rid of the ducatiBoot, but if there isn't, is there a way to change the entry point set by the XDC linker file ( every rebuild we rebuild the XDC also i cannot just modify the created XDC linker file as is is being recreated and i would like to keep this like this).

Another question, can you please explain in some detail what is the ducatiGates - what is it for and how/when/where it is being used?

Thanks

Guy

  • 0
    TI__Mastermind 26780 points
    Guy,

    Can you please clarify what you intend to run on each of the two M4 cores? I think you are planning to port NDK to run on one of the cores. Will you be using the other core at all?

    If you remove ducatiBoot and change the entry point you will be removing the infrastructure that enables synchronized booting and cooperation between the two cores.

    Regarding where “.ducatiBoot” is coming from, this section is specified in the “Core.xs” file.

    For where the entry point is being defined, this is in the file “Core_link.xdt”. The entry point symbol is selected based on the application configuration.

    And the .ducatiGates section comes from the GateDualCore module. This module provides a gate to allow exclusive access to resources shared between the two cores.

    Regards,
    Scott
  • 0 in reply to ScottG
    Genius 4135 points
    Hi, Thanks.
    I am using both IPU cores -- one core will be baremetal and the second with NDK --> sysBios.
    That is why i prefer to have the boot as the baremetal boot i have for both cores and i dont need the .ductiboot section at all.
    If there is a way in the .cfg file to make it drop the .ductaiBoot or at least not use the "Core_link.xdt" file it will be great.
    otherwise - is there a way in the .cfg file to make it add some custom code to the generated linker file at its end?
    It appears that when having several cmd files with multiple MEMORY and SECTIONS blocks - is there is a redefinition of the same section/memory -- the first one "wins" but from some reason for the entry_point it behave the opposite -- the last one "wins" - no idea why this opposite behavior - i would expect all to behave in the same manner but since it seems not to be the case i need to add another --entry_point line at the end of the generated linker file to override the core xdt file setting.
    can you help?

    As for the ductiGates - if i make sure only one core is configuring the AMMU and cache what else is there that needs the Gates and what is the difference between this and an access between one IPU core and another non IPU core of the SOC?

    Thanks
    Guy
  • 0 in reply to Guy Mardiks
    TI__Mastermind 26780 points

    Hi Guy,

    I experimented with removing components and changing entry points, and then talked with the original developer of the dual-core/SMP implementations.  

    The Core module is used in many places, both for synchronizing behavior between the cores, and for partitioning resources (e.g., vector tables, CTM timer IDs, interrupts).   And the common entry point (in the .ducatiBoot sections defined in the Core* assembly files) efficiently starts both cores from the common reset vector, branching each to the appropriate core-specific entry point in the appropriate vector table (placed at precise locations in  shared memory).  And GateDualCore provides the primary mechanism to arbitrate access from both cores to common shared memory, AMMU, and for unicache operations.  GateDualCore is also used for implementing power management of the cores, synchronizing re-boot/resume after the power-gated suspend state.

    There really isn’t a clean way to remove only portions of Core, or to change the primary entry point without other very significant modifications and loss of functionality.  This is not something we’d recommend.  It might be best to ‘start over’ for your specific dual-core use case rather than take that approach.

    All that said, I’m wondering why you need to make such significant modifications.  If you continue to use Core and the pre-defined entry point, you will also be able to continue to use the available Timer and Timestamping services in your NDK app on Core 0.  And your other app on Core 1 can be “mostly” bare metal, with the exception of the minimal startup code in the Core* asm files to launch the core to the appropriate entry point for that application.

    Is there some reason you can’t use the existing dual-core infrastructure to run your larger NDK-based app on Core 0, and your other app (that doesn’t interact with Core 0) can run independently after startup on Core 1?

    Thanks,
    Scott

  • 0 in reply to ScottG
    Genius 4135 points
    Hi Thanks.
    I basically managed to replace the .ductiboot with my custom boot and it seems to be working (still needs further checking).
    i see no reason why i cant do this as the ductiBoot only holds the very first startup code which is what i am replacing - this will enable me more control and also make sure that both cores (baremetal and sysbios has the same startup code - as it must be the same since both start from the same location). i still kept the Core module and the Gates (even though i am not sure it is really necessary) so everything else i suppose should be functioning the same.
    Also for our application,even though it is not a must, it makes more sense for example that the first core is core1 (NDK also runs on core1) (this is due "historic reasons" (before "my time") and reversing it now is not really an option).

    I was hoping there is a better/simpler way to achieve what is have done since i assumed that this XDC design is supposed to be fully customized, but i still encountered some things i had to leave as is but make them ignored.
    i.e. from some reason, even though i was able to add a function to the Startup First and Last Functions list i was not able to modify replace an automatically inserted function - once i tried it i seems to cause it to remove everything else from both lists also and i am not sure what other impact i may have (no idea why it behaves like this). for example i wanted to remove the function that for example clears the ducati core1 wait flag since it is no longer needed but could not accomplish this so i had to keep it (and as a result keep that flag too ).

    As for the entry point, since i could not find a way yet to add something to the created linker file (Can you help with this) so in the meanwhile i found that there is an option to replace the linker template being used, which allowed me to add the new entry point.

    i also wanted to try to avoid having the reset vectors hard coded as fixed addresses (0x800 , 0x400) so i changed it to be linker dependent.

    the custom file (the one that replaces the ducatiBoot asm file) is basically based and very similar to the original file but with a few minor modifications.

    Do you see any problem with the way i described above (i.e. something you said probably wont function correctly when trying to change that should check)?

    If you still think and point out the reason that it will cause something to be really wrong, I can try and make it work with current .ductiboot - but i really rather not (again i mainly replaced only the initial asm file which is also very similar and the rest should be pretty much the same)

    Thanks
    Guy
  • 0 in reply to Guy Mardiks
    TI__Mastermind 26780 points

    If you keep Core, and replace the assembly boot code with similar (but more flexible) booting of the two cores, then no, I don’t see a specific problem with this.  You’ll end up with some dead code/data linked in, but I don’t see any specific functional problem.

    For specifying the entry point during the application build, the usual way I’ve seen this done is with a linker template file.  You can change the entry point(s) in Core_link.xdt, or use a different file as you are.  Another option should be to specify the entry point during build via the command line, but I think if you are going to always be using the same entry point it is simpler to just specify it in the .xdt file.

    Regards,
    Scott

  • 0 in reply to ScottG
    Genius 4135 points

    Hi,
    Thanks a lot for the confirmation.

    About the entry_point - using the linker command file (this is what i tried first and could not work for me) turns to be a bit cumbersome since i need both to override section definitions done by the automatic linker script and the entry point. and as i mentioned before it appears that for sections and memory definition the first definition takes place while for the entry-point the last (not sure why this opposite behavior -- do you have any insight on this?). The default order is that first it links all local files and lastly the automatic generated script. this order is good for the sections and memory override by my linker script but does not help with the entry-point, so it seems to accomplish both i will need to linker command files one of them only has the new entry point definition and also i will need to specifically change the link order (this i saw can somewhat be done in the project setting but this setting does not only refers to linker command files but i will need also to add all libraries and objects otherwise the order will be wrong and creates conflicts)

    Thanks
    Guy