AM4378: do_rootfs frailer "ti-sgx-ddk-um" after updating the meta-ti SDK to 9.2

Bhavesh Shah said:

Once i am trying to create any image with"ti-sgx-ddk-km ti-sgx-ddk-um" add

Since you mentioned that, we have just released AM437x SDK v9.3, see https://www.ti.com/tool/download/PROCESSOR-SDK-LINUX-AM437X. It has a MUCH improved/fixed graphics stack. I'd highly recommend you switch to this. If you still see build issues we need to compare the known-good SDK build/setup that you should be able to re-create, with your customized port.

Bhavesh Shah said:

In that process i upgraded the TI-SDK to 9.2

Don't use 9.2 tags for building for AM335x/AM437x. There was no SDK release for those devices made at this tag, hence no testing was done and the result is likely invalid.

Regards, Andreas

Hi Andreas, Thank you so much for your reply. 

I am also looking for using same yocto setup for AM437x and AM335x too, Also I am looking for the the AM62xx support too with the same yocto setup.

I see as you suggested SDK v9.3 is also available for AM335x too which I can use. 

No the question is, which latest single SDK version should I use that allows me to build image with Kirkstone yocto for AM335x and AM62xx boards.

Bhavesh Shah said:

No the question is, which latest single SDK version should I use that allows me to build image with Kirkstone yocto for AM335x and AM62xx boards

I would not recommend using v9.x for AM6x devices. There have been many improvements since, some critical, such as MMC/SD driver routines, DM-firmware PLL routines, and many more. It would be quite difficult to identify all changes and backport them from SDK v10.1.

Regards, Andreas

So to conclude it is suggested to use SDK v9.3 for am335x and am437x devices and for am62xx SDKv10.1 is suggested. Is this correct ?

I tried the switching to SDK v9.3 in meta-ti with commit 963140e3b5820d6ebf54a4418946a628e0fea2c6 (HEAD, tag: cicd.kirkstone.202412041235, tag: 09.03.05) and recompile the image. still i am seeing the same error in there. 

I am still looking for the way to compile an image on top of fresh SDK 9.3 and add "ti-sgx-ddk-km ti-sgx-ddk-um" packages into the image and check whether it complete the image build or not.

Bhavesh Shah said:

So to conclude it is suggested to use SDK v9.3 for am335x and am437x devices and for am62xx SDKv10.1 is suggested. Is this correct ?

Correct.

Bhavesh Shah said:

I am still looking for the way to compile an image on top of fresh SDK 9.3 and add "ti-sgx-ddk-km ti-sgx-ddk-um" packages into the image and check whether it complete the image build or not.

I suggest re-creating the SDK build as it is intended, and then inspecting it to see what are significant differences vs. your setup. Often this is an exercise involving a lot of string searches (`grep`).

Also have you looked at the detailed error log files referenced in the console build error message from your original post? It might be that the post-install script is not appropriate for your changed filesystem, so you might want to focus on that and see what needs to be tweaked there.

Regards, Andreas

hi Andreas, As you suggested I crated the TI SDK build for 9.3.5 sdk, In that I tried adding ti-sgx-ddk-km and ti-sgx-ddk-um drivers. It gave the same error in there. After that once I investigated the older recipe of ti-sgx-ddk-um (TI-SDK 08.01.001) I observed that udev is used and if the yocto system is sysvinit then they are includeing update-rc.d class

INITSCRIPT_NAME = "rc.pvr"
INITSCRIPT_PARAMS = "defaults 8"

PACKAGECONFIG ??= "udev"
PACKAGECONFIG[udev] = "UDEV=true,,,udev"

def use_sysvinit(d):
    return d.getVar('VIRTUAL-RUNTIME_init_manager') == 'sysvinit'

inherit ${@oe.utils.ifelse(use_sysvinit(d), 'update-rc.d', '')}

From the errors I was doubting about this error is something to do with the update-rc.d file and that is causing the error at rootfs time.

If I update the PACKAGECONFIG = ""  then we are able to create the final image.

I took the changes and added the into the yocto setup i am using to create my custom image. I am able to create the final image. But if i test the image i am not able to see any graphic on board. ( i am testing on am437x-sk board, in older image with older TI-SDK 8 and dunfell yocto I am using a qt based application which is showing a logo once the board is up) I am getting below errors

Setting environment variables...Starting UI app... UI app started.
root@Node:~# Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8.
Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead.
If this causes problems, reconfigure your locale. See the locale(1) manual
for more information.
MESA: info: Loaded libpvr_dri_support.so
PVR:(Error): PVRDRICreateScreenImpl: Failed to create display device (err=19) [0, ]
MESA: info: Unloaded libpvr_dri_support.so
MESA-LOADER: failed to open zink: /usr/lib/dri/zink_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
failed to load driver: zink
drmModeGetResources failed (Operation not supported)
Cannot create window: no screens available

My questions are

1. What is the need of UDEV in ti-sgx-ddk-um driver. ( my understanding is it might me be needed to add the graphic driver into the kernel image)
2. Is there any documentation i can refer to understand the updated ti sgx drivers.
3. Right now to make the image work i have removed UDEV from PACKAGECONFIG variable. If it is required what should be the proper way to make it work
4. Is there an yocto image/setup which i can use to take reference about how i can use graphics usign QT in updated TI SDK

My end target to make the older QT application work with updated yocto and meta-ti sdk

I am thinking that in the process of upgrading the yocto some of the points are missed from my end which could be causing this issue.

I'm currently on international business travel working at a customer site and not able to look into this further; will comment once I'm back in the office next week.

Regards, Andreas

There has been no activity on this thread, so marking this closed as it might've been resolved offline