Hi Neha,
On Fri, 24 Mar 2023 at 22:28, Neha Malcom Francis n-francis@ti.com wrote:
Hi Simon,
Before I roll out the entire series that works for packaging K3 bootloader images, wanted to get some reviews and comments regarding the implementation of the signing etype [1] . I believe I've taken into consideration what we've discussed earlier [2].
Let me know your thoughts. The tree is also WIP, and was mainly designed for testing the signing etype on two of the devices. I will add the remaining and refine the series based on the next comments.
Yes this looks reasonable to me. For the openssl method, can you create a new 'real' method and put the cert stuff in there instead of using a 'custom' one? It seems to have a lot in common with what is there. We should really have an internal cert-generator method in that class, with other functions in that class doing appropriate things. I am looking for code reuse here, as well as clear indication of what the cert is for or does. If most of the cert is the same, you could pass a dict for the CN stuff, perhaps?
What is the taml for? It is hard to tell, from the example provided.
Do you have a .dts which shows the full image for a board? I think the cert stuff looks right, but it's a bit hard to tell.
When sending the patches please do do follow the function-commenting style and make sure that it is clear what each arg means. E.g. I saw a hash integer which I assume is used to pass 256 or 384 or 512 for sha hashing. It should indicate the possible values / meaning in the arg. In fact, in that case, it might be better to pass a string like 'sha256'.
Anyway, apart from my questions it seems good.
Regards, Simon
[1] https://github.com/nehamalcom/u-boot/commit/ea7413ed5864340bd6f01e704e8bdcc0...
[2] https://patchwork.ozlabs.org/project/uboot/patch/20230224120340.587786-1-n-f...
-- Thanking You Neha Malcom Francis