On 10/22/25 6:28 PM, Jeff Hugo wrote: > On 10/22/2025 10:03 AM, Konrad Dybcio wrote: >> On 10/8/25 12:40 AM, Youssef Samir wrote: >>> From: Jeff Hugo <[email protected]> >>> >>> AIC200 uses the newer "XBL" firmware implementation which changes the >>> expectations of how READ_DATA is performed. Larger data requests are >>> supported via streaming the data over the transport instead of requiring >>> a single transport transfer for everything. >> >> tldr just like reading/writing images in 'raw_mode' up until now? > > I'm not sure I understand what you are asking here.
Sorry I confused sahara with firehose here.. The former doesn't have a notion of what I referred to > > AIC100 is the "old" SBL architecture. When the "current" XBL architecture > came about, quite a bit of the components were rewritten. It seems like a > different interpretation of the Sahara spec was taken for the XBL > implementation. > > In both cases, the boot component that is driving the Sahara component in FW > will want segment X of the elf for the next step of processing. > > In SBL, the Sahara component would have a specific MTU and break up the > request (segment X of the elf) into MTU sized read requests for the host. The > MTU is negotiated with the transport (MHI). The Sahara component expects the > entire read request to be satisfied in a single return from the transport - > anything less is an error. > > In XBL, the Sahara component would make a single read request to the host for > the entire request from the boot component (segment X of the elf), and > expects the underlying transport to shove up data until the entire read > request is satisfied (Sahara will sit in a loop until it gets all of the > data). > > There is a bit of oddity because the Sahara spec says that the host can > indicate an error by sending a packet that is anything other than the > requested read size, but "packet" is not defined. The SBL interpretation is > that a "packet" is the transport packet - aka the MHI transfer. The XBL > interpretation is that the packet is a "Sahara packet" which is decoupled > from the transport. > > In the end, we have two different Sahara implementations in FW with different > expectations, and both need to be supported. Thanks Konrad
