Two CST versions calculate different hashes for same key

[nenadradulovic]

Hello,

I have been using 17.06 LayerScape SDK successfully on LS1021A-TWR board and enabled Secure Boot with Confidentiality. The CPU was burned with OTPMK and SRK and everything works as expected.

Now I need to test the 17.09 SDK. The first thing I noticed during building is that CST utilities now print different hashes although the same keys were used (srk.pub and srk.pri), copied from previous project version. The board doesn't boot now, perhaps due to wrong key values being used.

What has changed? I've copied the two files (mentioned above) to CST build directory, am I missing something?

The commit from 17.09 (non-working) is 1afb40c13097fc9e8a641aa5d0420498fea01c65

The commit from 17.06 (working) is 6424157985568df3f42a46e24222e38671455ddb

[nenadradulovic]

Hello, I did overcome this by disregarding the last commit in cst apps:

flex-builder -i repo-fetch

flex-builder -i repo-tag

cd packages/apps/cst

git checkout HEAD~1

cd -

continue with usual command sequence...

Best regards,

Nenad

[nenadradulovic]

Hello, I've found that the last commit in LSDK-17.09 branch has changed the behavior of CST. The commit is:

1afb40c13097fc9e8a641aa5d0420498fea01c65

Make SRK table default option

Since in ls1088ardb and 2088ardb, by default srk table is assumed, even if single key is present, making it common for all platforms

case FIELD_KEY_SELECT:
474	474		if (file_field.count == 1) {
475	475		gd.srk_sel = STR_TO_UL(file_field.value[0], 16);
476		-	gd.srk_flag = 1;
477	476		} else {
478	477		gd.srk_sel = 1;
479	478		}
	479	+	gd.srk_flag = 1;
480	480
481	481		break;

Why is this relevant to how the hash is calculated?