On Thu, Feb 27, 2025 at 07:11:14PM +0800, Bard Liao wrote: > + (2) A CRC on the data block (header excluded). This CRC is > + transmitted as the last-but-one byte in the packet, prior to the penultimate byte? > + footer response. > + > +The header response can be one of "one of:" > + (a) Ack > + (b) Nak > + (c) Not Ready > + > +The footer response can be one of Ditto. > + (1) Ack > + (2) Nak (CRC failure) > + (3) Good (operation completed) > + (4) Bad (operation failed) > + > ... > + :: > + > + +---+--------------------------------------------+ > + + | | > + + | BRA HEADER | > + + | | Nit: this line is indented with spaces instead of tabs, but the table still renders perfectly in htmldocs output (no warnings). > + + +--------------------------------------------+ > + + C | HEADER CRC | > + + O +--------------------------------------------+ > + + M | HEADER RESPONSE | > + + M +--------------------------------------------+ > + + A | | > + + N | | > + + D | DATA | > + + | | > + + | | > + + | | > + + +--------------------------------------------+ > + + | DATA CRC | > + + +--------------------------------------------+ > + + | FOOTER RESPONSE | > + +---+--------------------------------------------+ > + > ... > +Each packet will typically have "have:" > +One possible strategy to speed-up all initialization tasks would be to > +start a BRA transfer for firmware download, then deal with all the > +"regular" read/writes in parallel with the command channel, and last > +to wait for the BRA transfers to complete. This would allow for a > +degree of overlap instead of a purely sequential solution. As a > +results, the BRA API must support async transfers and expose a "As such, ..." > +separate wait function. > ... > +The bus interface for BPT/BRA is made of two functions "two functions:" Thanks. -- An old man doll... just what I always wanted! - Clara