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.
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.
-Jeff
