RTOS/PROCESSOR-SDK-AM335X: Hooks structure customization

The RTOS team have been notified. They will respond here.

Todd,

Thanks, but that's not solving it.

When I look at a simple RTOS project, that structure was defined as empty.

When I look at an NDK project, Debug/configPkg/[ackaghe/cfg/blah_blah_pa8fg.c file...  that structure has TWO entries.  

const __T1_ti_sysbios_knl_Task_hooks ti_sysbios_knl_Task_hooks__A[2] = {
    {
       /************   
             First One 
        *************/
    },
    {   /*  Second One */
        ((xdc_Void(*)(xdc_Int))((xdc_Fxn)ti_sysbios_rts_gnu_ReentSupport_taskRegHook__I)),  /* registerFxn */
        ((xdc_Void(*)(ti_sysbios_knl_Task_Handle,xdc_runtime_Error_Block*))0),  /* createFxn */
        ((xdc_Void(*)(ti_sysbios_knl_Task_Handle))0),  /* readyFxn */
        ((xdc_Void(*)(ti_sysbios_knl_Task_Handle,ti_sysbios_knl_Task_Handle))0),  /* switchFxn */
        ((xdc_Void(*)(ti_sysbios_knl_Task_Handle))0),  /* exitFxn */
        ((xdc_Void(*)(ti_sysbios_knl_Task_Handle))((xdc_Fxn)ti_sysbios_rts_gnu_ReentSupport_taskDeleteHook__I)),  /* deleteFxn */
    },
};

So I put two entries in the CFG file:

Task.addHookSet({
registerFxn: '&NDK_hookInit',
createFxn: '&NDK_hookCreate',
exitFxn: '&NDK_hookExit'
})

Task.addHookSet({
registerFxn: '&ti_sysbios_rts_gnu_ReentSupport_taskRegHook__I',
deleteFxn: '&ti_sysbios_rts_gnu_ReentSupport_taskDeleteHook__I'
})

So, where are those functions ti_sysbios_rts_gnu_ReentSupport_taskRegHook__I  and ti_sysbios_rts_gnu_ReentSupport_taskDeleteHook__I?  And why did the example project know to toss them into the Debug/configPkg/[ackaghe/cfg/blah_blah_pa8fg.c source file, when there is no mention of it in the CFG file?

And what are these functions, there is no documentation about them anywhere.  Obviously they have something to do the re-entrancy, but nothing is explained.

Because when I included them, I get a linker error "undefined reference".  Just great...

Interestingly enough, in the example NDK project, the XDC thing also tossed in a prototypes for "NDK_hookInit()"  into Debug/configPkg/[ackaghe/cfg/blah_blah_pa8fg.c   but it didn't add one for "ti_sysbios_rts_gnu_ReentSupport_taskDeleteHook__I"

More importantly...  what is going on??

What is the "hookset ID"  How does it get set?  How do you know which "hookset ID" you are dealing with?  The NDK is apparently getting it's hands on the hookset ID, and because it's needed to do Task_setHookContext and Task_getHookContext.  But how do you get the ID without having to register create functions?  How many are they, and where are they stored?  Is it ONLY to allow more that one context value per function hooks?

This all started because I'm trying to get a NDK to build and run, so I can modify it...  And it has to have a hookset ID.... which came from the hook structure...  which is static and can't be added programatically...

None of this is explained.  Anywhere I've searched.  And searching was how I spend my Christmas vacation.

-CSW

Are you configuring* the NDK in the .cfg file? If you are, it automatically adds in the required hook functions.

* for example
var Ndk = xdc.loadPackage('ti.ndk.config');
var Global = xdc.useModule('ti.ndk.config.Global');
...

I was able to add the lines I gave above (myExitHook, etc.) into a GCC Networking example and my hook functions showed up in the generated file. The networking example was using the .cfg to configure the NDK stack. So I ended up with 3 entries.

Let's get this resolved before talking about hookset Id.

Todd

Todd,

Thanks for the dialog.  You've helped me before and I appreciate it.  It seems I get assistance about 25% of the time I post. It's frustrating.

It's also frustrating when I spend a week to try to reverse engineer from code and unravel stuff because I can't find a simple paragraph of doc for whatever it is I'm struggling with.

(This has been going on for a year.  GPIO, USB, Ethernet, etc...)

Anyway, I do NOT want to use the CFG file for the NDK.  CFG is only being used for the basic RTOS. Here's why:

I am on a mission to modify the NDK in order to meet some custom requirements.  The NDK doc talks about the API from the outside, looking in, and almost exclusively as being implemented with the CFG file. But the doc doesn't explain everything. The AM335x reference manual (SPRU 73) talks about the 3PSW, and port configuration, nothing about the TCP/IP stack.

The AM335x manual also refers to the CPSW, without defining it... But I think I am beginning to understand it, whatever it stands for.

To reverse engineer it, I want to be able to troubleshoot and step through code, to see where I can alter it to handle the data stream directly.  I can't do that when linked with the pre-compiled libs.  Nor do any of the "jump-to" functions work in CCS, slowing things down horribly when using "grep".

The XGCONF/CFG utility forces it to link with the libs.  So I don't want to use that, as it will alter all the include paths, add libraries, etc... I simply include all the source modules.  That means I can't use the "loadpackage(NDK)".  And I'm getting exposed to stuff that XDC is doing that is not explained anywhere. 

So, yes, I would expect the XDC to generate those lines, but I'm trying to do an end-run around the XDC-NDK.  And in this case, XDC tossed in functions that are not described anywhere. (in this case i_sysbios_rts_gnu_ReentSupport_taskDeleteHook__I)   That means the NDK needed something which I don't know what it is, and is not documented, and the XDC knew that it is needed, and put it in.  And when I tried to put it in myself, the linker couldn't find it.  But it's in the Sys/Bios libs, because those functions are not in the massive C file created by XDC.  They are only referenced.

I removed that second "Task.addHookSet" of those functions, and got a build and link with only the NDK_Init, NDK_Create, etc..  But will it crash as soon as things can't be "re-entered" because of those missing functions?  There will be more tasks in the long run, will that have any effect?   Right now it builds and loads and runs, but I'm not even seeing the basic ICMP DHCP request.  I don't know if it's related to those re-entry functions, or just something else that isn't set right (that I'm still trying to learn).

I can and will dig into NDK internal functionality to solve something like that, such as how the DHCPC task is supposed to run.  But this XDC stuff isn't internal to the NDK, it's doing things to/for the NDK which I can't find documentation for or understand.

I hope this explains the path I'm trying to take.  I dig and dig, and can't find documentation, nor have I even been able to find anyone I can pay for training and tutoring.  (Eric Wilbur tells me he doesn't work with the NDK, and doesn't have experience with the Sitara devices).

Thanks.

-CSW

The ti_sysbios_rts_gnu_ReentSupport_taskDeleteHook__I and ti_sysbios_rts_gnu_ReentSupport_taskRegHook__I hook functions are not added by the NDK. The kernel adds those as needed, so you should not worry about those.

Regarding the other hooks that the NDK need, you need to add those (namely the NDK_hookInit, NDK_hookCreate and NDK_hookExit) via the Task.addHookSet in the .cfg file.

Have you looked at the "Configuring the NDK with C Code (without XGCONF)" section in the NDK User Guide?

Christopher Weber said:

But will it crash as soon as things can't be "re-entered" because of those missing functions?

Can you give more details on the crash.

Todd

ToddMullanix said:

The ti_sysbios_rts_gnu_ReentSupport_taskDeleteHook__I and ti_sysbios_rts_gnu_ReentSupport_taskRegHook__I hook functions are not added by the NDK. The kernel adds those as needed, so you should not worry about those.

Yes, I figured that it's added by the XDC...  how did it decide?  Why did it decide?  If I'm doing an "end-run" around XGCONF, then it may not know if it's needed.

ToddMullanix said:

Regarding the other hooks that the NDK need, you need to add those (namely the NDK_hookInit, NDK_hookCreate and NDK_hookExit) via the Task.addHookSet in the .cfg file.

Yup.  Done that, it builds and doesn't crash now.

ToddMullanix said:

Have you looked at the "Configuring the NDK with C Code (without XGCONF)" section in the NDK User Guide?

I have the "Developers Kit Users Guide"  spru523, Section 3.2.and used it as the model.  But from the start, it was lacking.  Section 3.2.1: "A hook module must be created to call the OS hook functions NDK_hookInit() and NDK_hookCreate()."  which I had no idea how to do...  Nothing telling a user how to do that.  Resulting in this post.

But apparently, it DOES require XGCONF in order to install the hooks, as you have explained.  So the title mislead me that I still need to do stuff in the CFG file.

Furthermore, things like the CfgAddEntry function doesn't define how to use it. There are a bunch of #define CFGITEM_IP_xxx  constants, but no spec on using them (some pass ints, some pass structs....)

And...  Apparently the interface number in the CI_SERVICE_DHCPC structure starts counting at 0x01...  which was also not explained.  What C index counting system starts with 1 instead of 0 ??

ToddMullanix said:

Christopher Weber

But will it crash as soon as things can't be "re-entered" because of those missing functions?

Can you give more details on the crash.

Todd

That was a question:  Will it crash later because those "reentrant" functions didn't set something up?

Right now it is not crashing.  I have systematically corrected for the my own bugs and typos, the MMU, getting task context values, hookset ID, etc...  and now the hook functions.  So now it's to the point that it's not yet working, but not crashing.  Could be a config setting, or something else.

Getting back to the "hookset" stuff, which you said we can cover afterwards... I seem to determine it's related to the fdOpenSession api...   which is another component I'm not clear about.

Thanks so far...

-CSW

Hi Christopher,

First, can you confirm that the GNU reentrant hooks are there without you adding them. They should be added automatically unless there are certain situations (e.g. Tasking is disabled, zero size heap, you explicitly disable the reentrancy in the .cfg file). If they are not automatically being added, please let me know what version of SYS/BIOS, XDCtools, NDK and compiler you are using.

Second, the section in the UG section "Configuring the NDK with C Code (without XGCONF)" means you are not using the XDC configuration capabilities of the NDK. You still need the .cfg file since you are using TI-RTOS. I do agree that this could be clarified more.

Third, I'm not following your logic on not wanting to use the configuration options in the NDK. Without it, you are still using the NDK libraries (I'm assuming you are not pulling in all the NDK source into your application).

Todd

Todd, Taking it in reverse order., as there seems to be a disconnect..

ToddMullanix said:

Third, I'm not following your logic on not wanting to use the configuration options in the NDK. Without it, you are still using the NDK libraries (I'm assuming you are not pulling in all the NDK source into your application).

Actually, I am doing exactly that. I pulled almost the entire NDK tree into my project. A separate copy, not linked. Eventually, I need to make some customizations at the lowest level. And I did not want to have to rebuild an entire TCP/IP stack above the customizations. So I'm trying to get to the level of understanding where I can modify this one.

And the internals of it are not documented anywhere at all. So I'm reading source, and stepping with the debugger...

ToddMullanix said:

First, can you confirm that the GNU reentrant hooks are there without you adding them. They should be added automatically unless there are certain situations (e.g. Tasking is disabled, zero size heap, you explicitly disable the reentrancy in the .cfg file). If they are not automatically being added, please let me know what version of SYS/BIOS, XDCtools, NDK and compiler you are using.

I don't know how to confirm them except that I saw them in a simple "example "project source file, auto-generated by XDC when it rebuilt Sys/Bios.

I don't see how this is a GNU issue, since XDC generated the source file.

The TWO projects I compared:

• The "example" named NIMU_BasicExample_bbbAM335x_armExampleproject right out of the Sitara PDK. No changes made. This has the reentrant hooks in the XDC generated file.
• My own basic project, built with the CCS 7.2 "New Project" option, as a "Typical" Sys/Bios. Then I imported the NDK source into. Then, as you instructed me how it works, I manually added the "NDK" hooks. And the reentrant hooks are not there... If I add them, they are undefined.

Both are using Sys/Bios 6.46.5.55, XDC 3.32.1.22, and NDK 2.25.01.11. (my project does NOT specify the NDK, it has the source from the same folder tree)

The difference between the "example" which added the reentrant functions and my project where I pulled in the NDK source tree:

• The "example" is using GNU 4.9.3.
• The project I pulled in the NDK source is using the TI compiler 17.9.0

I am using TI because the group at my employer I am working with uses the TI compiler.

I also see the "example" project uses EDMA and PDK in it's property settings... I have no idea what they bring in... perhaps because the "example" project also uses UART and I2C??

ToddMullanix said:

Second, the section in the UG section "Configuring the NDK with C Code (without XGCONF)" means you are not using the XDC configuration capabilities of the NDK. You still need the .cfg file since you are using RTOS. I do agree that this could be clarified more.

Yes, the clarification that you need to add the hooks to the CFG file.

Modifying the CFG file scares me, because the GUI (XGCONF) could overwrite whatever I'm altered.

Well, my project with the pulled in NDK source complies and runs without and errors, but does not seem to either send out a packet, or doesn't seem to receive a packet... It could be

• Something about the missing "reentrant" calls in the startup hooks. (since I don't know how vital they are)
• Something not set right in the task priorities.
• Who knows....?

I am stepping in and debugging to see what I can learn.

-CSW

Todd,
Yes, I understand that I'm on my own with that. I'm not looking for that kind of assistance.
It's those things like how are the NDK hooks supposed to be installed, or those reentrant functions. This is now solved.

Or what's the architecture design of that hookset id stuff... which I don't have an understanding of (but is not preventing me from moving forward with what I'm working on).

I may post other questions. But questions I would ask would be rather specific. Maybe about the interrupts, buffers, registers, etc...

Thanks.
-CSW