AM2434: TMDS243EVM: Confusion about security-information printed on Sitara and read out from register

Hello,

If your use case is identifying the device type, it is better to read the device type from the SECMGR MMR. The SECURITY bit in the JTAG ID register can differentiate between the GP and HS device but cannot differentiate between the HSFS and HSSE device.

As for the inconsistency about the SECURITY bit in the JTAG ID register, I will have to loop in the concerned teams.

I will do that once we have aligned on the method you want to go with for identifying the device type if that is your use case.

Regards,

Prashant

This is a super good hint, thank you!
Currently we only use hs-fs, but this will change and we need to take this into account. 

So the first post had some topics mixed with each other. But you get the point:
We started pretty early with those Am64 and Am243-SoCs when there were only Prototype-versions available, so for us the "GP"-versions. As soon as TI released the non-gp-versions we had only hs-fs-devices. Also the support in the sdk for the gp-devices, and thus the SysFw, was discontinued. 
Still we needed to update older devices, and need to do that in the future as well. 
So we took out the SysFw.bin from the sdk.
Also we have our own bootloader-application which is loosely based on the ospi-bootloader. We use our own platform and update-mechanisms with three slots for different firmwares (A/B and a backup-firmware-slot).
The SBL-image usually also contains the SysFw and the boardcfg, which is activated by the RBL. 
This means we need to build two different Bootloader-applications, one for gp and one for hs-fs, since the SysFw.bin of the GP won't work with hs-fs and the other way round. 

Our update-mechanism also allows to add bootloader-images to the update-file, which then will be installed as well. We even added two Bootloader-images to our update-file, since we had one product with different SoC-revisions in field. This means the device needs to differentiate between those two bootloaders. 

For that we needed a register to read out from the Sitara for identification. based on those values the gp- or hs-fs-bootloader will be installed.

The register you mention is also something we accidentially found out via reverse engineering. But we didn't find any further information about that in the TRM (maybe we just didn't find it). That's why we chose the JTAG_UDER_ID-register. 

Currently it did not produce any problems, or I would assume we did not receive any of the revisions soldered onto the evm. So our products were still updateable and for the batches we received the read out from the JTAG_USER_ID-register was good enough. 

So if we can get more info on the SECMGR and its register-values and you say it's more reliable, we could change to that. 

With this knowledge we can also prepare firmware-updates without any bootloaders, which will just change the application-image and thus the check for the SEC MGR registers.

Now you gave a good hint, since we probably need to adapt this as well for the hs-se, which shouldn't be a big problem, but needs to be taken into account. 

Hello,

Felix Heil said:

But we didn't find any further information about that in the TRM (maybe we just didn't find it).

The register information is not available in the TRM. It is part of the SECMGR MMRs which are available in the Security TRM. You would need to request access to the secure resources.

For the time being, you may refer the following APIs and see how the device type is identified.

• mcupsdk-core/source/drivers/bootloader/soc/am64x_am243x/bootloader_soc.c at next · TexasInstruments/mcupsdk-core - This only differentiates between the GP and HS devices.
• common.c « mach-k3 « arm « arch - ti-u-boot/ti-u-boot - This project will contain all publicly available source code for TI’s U-Boot offering. The contents of this project must be shareable and redistributable. - This differentiates between all the device types.

Let me know if any further clarifications are needed.