On Wed, 2025-11-19 at 11:51 +0900, Alexandre Courbot wrote: > I'd prefer if we could reason in terms of functionality instead of > specific chipset versions.
If you can figure it out, I'd be happy to change the code. I wasn't being lazy when I made this comment: // There are two versions of Booter, one for Turing/GA100, and another for // GA102+. The extraction of the IMEM sections differs between the two // versions. Unfortunately, the file names are the same, and the headers // don't indicate the versions. The only way to differentiate is by the Chipset. > IIUC the relevant factor is that Turing/GA100 have some non-secure > bootloader code as the entry point of booter, which GA102+ doesn't > feature as it is capable of starting in secure mode directly (please > correct me as my understanding is probably incomplete if not outright > wrong). That sounds about right. There are secure and non-secure sections in the firmware image. > What is the HW or SW fact that requires this on Turing? I don't know how to answer that question. That's just how it's done on Turing/GA100. I would need to start an internal Slack thread to get a better answer, and I don't really see what it would gain us. > Is it linked > to the fact we need to use PIO for it? What I would like to achieve is > removing or at least reducing these chipset checks into one single > point, which in the worst case could be a method of `Chipset` telling us > which loading method to use. But if we can find a distinguishing factor > in the parsed by this method, that would be even better. Both OpenRM and Nouveau use the chipset to gate on how to parse the headers.
