J721S2XSOMXEVM: TDA4VE: Target takes about 20 seconds to boot QNX; and most of the time seems to be due to the network setup/initialization

Hi,

Is SBL Boot being used?  If yes, please be aware of below FAQ, which should be addressed:

• (99+) [FAQ] TDA4VL-Q1: Change GTC Clock frequency to 200MHz for SBL boot flow - Processors forum - Processors - TI E2E support forums

 Regards,

kb

Hi KB,

I am using SPL + U-Boot to start QNX.

Thanks.

Hi,

From the log, it looks like you are using NFS to boot QNX. Can you try sharing the logs when loading the qnx-ifs directly from SDCard?

Moses Christopher Bollavarapu said:

Once the .build file is updated such that the devnp-cpsw2g.so and corresponding dependencies are present, then the boot-time rose to 20+ seconds.

Can you share the updated .build file for us to review?

Thanks.

Hi Praveen,

If I remember correctly, when I prepare SD-Card as per the instructions provided, U-Boot doesn't boot QNX directly. It waits in the Hush shell (could be bootdelay set to -1 or something else, I didn't quite look into it) I had to manually issue boot command.

I think the NFS part could be ignored; it was due to some failed conditions/bad env.
I am loading qnx-ifs to DDR and starting from DDR(I suppose this is independent of boot-media used to download qnx-ifs to DDR), the rest of the dependent files are located in the SD-Card (ti_fs and so on). And with the exact same setup, by just not using the devnp-cpsw2g.so and its dependencies(original .build file), the boot-time seems to be okish(~3Seconds)

I have attached the updated build file(needed to change extension to be able to upload here).
j721s2_evm_ti.build.txt

P.S: I was told that; this issue is also present on a similar target(DRA829) with PSDK9.1, whereas on PSDK8.2 it seemed to work fine.
It could be observed by triggering if up or with (ifconfig am0 xxxxxxx up)

Thanks.

We looked into the j784s4 QNX BSP a few month ago (9.0 maybe?), and noticed an issue in the ENET porting layer for QNX that caused lots of unnecessary delays in the MDIO layer IIRC.

The MDIO manual mode requires "small" delays, but uses a QNX blocking delay that sleeps for a millisecond.

That could be what you're seeing here. 

Regards, Dominic

Moses Christopher Bollavarapu said:

If I remember correctly, when I prepare SD-Card as per the instructions provided, U-Boot doesn't boot QNX directly.

Not sure you are copying all the necessary files into the SDcard - specifically uenv.txt file  Please check the files to copy here. This must solve auto loading of qnx-ifs and startig QNX directly.

Moses Christopher Bollavarapu said:

I have attached the updated build file(needed to change extension to be able to upload here).

Please note that in the TI provided build file (j721s2-evm-ti.build), we do not support loading ethernet driver. This is not a path we have verified, hence commented in the release we do.

Please note that ifconfig has a blocking functionality and hence till it completes its run, it would not allow rest of the boot to proceeded, hence you see the delay. In the build file you shared, our suggest is to add "&" to the end of the command "ifconfig am0 192.168.2.2"  to  "ifconfig am0 192.168.2.2 &" .

Hope this fixed the boot time.

Thanks.

Hello, Dominic Rath,

We are not sure your comment above is related. 

If you think otherwise, please share more details on the code patch/line number so that Moses Christopher Bollavarapu can give it a try.

Thanks.

Hello Praveen,

if you look at the code in ti-processor-sdk-rtos-j784s4-evm-09_00_01_01/pdk_j784s4_09_00_01_04/packages/ti/drv/enet starting at src/mod/mdio.c:Mdio_manualModeToggleMdclk you'll see that it calls EnetUtils_delay after setting the clock pin high/low.

If you then look at src/core/enet_utils.c you see EnetUtils_delay calls EnteOsal_delay which calls gEnetOsalObj.delay which is set to EnetOsal_Cfg->delay in EnetOsal_init.

There's a default implementation in src/common/enet_osal_dflt.c that spins based on a cycle counter, but I don't think that's being used. Instead in the Processor SDK QNX in ti-processor-sdk-qnx_j784s4_09_01_00_06/psdkqa/qnx/devnp/src/enetlld_if.c:EnetIf_openCpsw it is being set to EnetIf_delay, which calls nanosleep. That is a blocking sleep that waits for (at least) the next tick.

I'm at Embedded World, so I can't test this out, and the above is solely based on memory and following the calls in the code. I'll ask the colleague who ran into this issue if/how he worked around this.

Moses Christopher Bollavarapu: in the meantime you could try replacing that nanosleep with a nanospin_ns, but I haven't checked if this has any negative consequences, i.e. if the EnetOsal_delay is ever used for any "longer" delays where you don't want to spin.

Regards,

Dominic

Hi Praveen,

It is interesting that you don't support loading ethernet, is there any short-term plan to add proper support for that?

Making it run as a background process, doesn't really solve the underlying issue. I would like to get the underlying issue resolved.

Thanks.

Hi Dominic,

I will take a look at it and try it out.

Thanks,
Moses

Hi Moses,

Moses Christopher Bollavarapu said:

It is interesting that you don't support loading ethernet, is there any short-term plan to add proper support for that?

There is no plan to start an ethernet driver in the build file. How to do it is already known, and you are enabling it.

Moses Christopher Bollavarapu said:

Making it run as a background process, doesn't really solve the underlying issue. I would like to get the underlying issue resolved.

The complete SDK code is available as part of the release for you to explore and update per your requirements.

Thanks.

Hi Dominic,

Thanks for the hint, but this didn't seem to have any noticeable impact.

Thanks.

Hi Moses,

One option that we can provide is as follows:

-1- Revert to the original build file provided as part of the TI QNX SDK. (This does not load any TI components in the build file.) This way, we do not load TI SDK binaries into the qnx-ifs, which would keep the images smaller by around 700KB. Thus, we save on qnx-ifs load time.

-2- Add the entry below to the user.sh, found in the qnxfs partition of the SDcard in the /scripts folder.

echo "Starting cpsw2g ethernet driver"
mount -T io-pkt /ti_fs/tilib/devnp-cpsw2g.so
if_up -p am0
ifconfig am0 192.168.2.2 &
echo "Starting cpsw2g ethernet driver... done"

Please note: With the above, we will get back to the QNX console prompt faster. However, initializing the ethernet driver will continue in the background task. The time is spent mainly on the ethernet phy initialization and ensuring LINK is established.

Thanks.

Hi Praveen,

Getting quickly to the QNX console isn't important for us, the first application is dependent on the network interface, therefore this will still have the same impact on the first application.

I realised that I should have framed the question a bit differently, i.e. leaving out the boot-time part and focusing solely on the network setup part.
I could create a new query explicitly for the phy init part, if you want.

Thanks.

Hi Moses,

We understand your requirements. At present, the speed at which the ethernet PHY can be initialized and the link can be up is limited. 

Thanks.