[Prism54-devel] X2 firmware file format

[Sebastien B]

Hello,

> about this driver : given that i didn't need it up to now for reverse
> engeneering, i'm thinking about "bringing it down" (removing it from
> public disctibution, leaving it available privately). It seems it'll be
> used by few people anyways, and we have no right, according to the
> license, to redistribute modified versions of it, and i don't want to be
> tainted for redistributing it illegally.

F* it. That's abusive copyright in my opinion. I'll keep distributing it on my 
website unless I get in real big trouble with Conexant.

> 0/ I completely agree with you about the nature of the firmware. This is
> not what we want, only for 3886. I'm very upset about the possibility
> that the softmac we have may not be able to parse the bra for the 3887
> firmware (the different API in the usb driver points to another, more
> recent, softmac library).

At last resort, I'll try retreiving the sm_data from a successful call to 
prism_softmac_parse_bra() with 3886lmac_2.7.0.0.arm and then injecting it as 
a static buffer in the driver, although the device will be running an USB 
2.5.8.0 firmware. Maybe there is a chance for some parts of the driver to 
keep working after this hack, if the communication protocols are not too 
different between the two firmwares...
What API for USB firmware parsing are you talking about ? I can't figure this 
out in the code...

> 1/ Did you try to extract the firmware from the USB logs ?

I have only checked the build string in the USB log, and then used the 
corresponding firmware from the Windows driver.

> Then use
> this precise firmware to carry out your tests. Or maybe i missed
> something and this firmware has an incompatible bra ? -- in this case
> i'm really pessimistic (see above).

Probably the bra is incompatible... The 2.7.0.0 firmware is very similar to 
the others (ARM NOP at the very beginning, string "PACKPACKPACK", build 
string).
By the way, the error message when failing to parse the bra is about a 
"LMAC-UMAC incompatibility" ; I thought perhaps this would be because of a 
different version number so I took the 2.5.8.0 firmware and modified it 
version number to fool the UMAC into thinking it's 2.7.0.0, but it didn't 
work. So the "bra" seems to be a much more complicated mechanism introduced 
in more recent firmwares.
That's why I'm looking for 3887 Windows drivers using a very recent firmware 
(> 2.5.11) so that I can try them with prism_softmac_parse_bra()

> 2/ The protocol in those devices seems to be text-based. 

Yes, I've noticed. I've written an usermode program which acts as a dumb 
terminal on endpoint 1 to allow easier experimentation, but I have trouble 
with writing and reading at the same time ; I first used threads with a poor 
result : indeed, libusb doesn't support threads at all (I was said this later 
by a developer ; I hadn't found anywhere that threads wouldn't work), even if 
the threads don't try to perform operations on the same resource at the same 
time.
I'm still looking for a portable usermode USB library, which less limitations 
than libusb 0.1. Perhaps libusb CVS, I haven't tried yet.

> 3/ As you may have seen, the protocol expected in the XH driver and the
> one embodied in the USB logs is not the same. Just for a quick
> difference, the USB logs show a packet sent that is "<<<<" for
> reinitialization, where the driver only sends one "<". There are many
> other discrepencied. You may need to adjust this in the driver; having
> no device, i didn't care to do it.

Indeed, the firmware upload didn't work, it either timed out or the device 
replied "ERROR" (PCI firmware detected ?). I haven't tried a lot yet, I'd 
prefer doing this in usermode in a first time, and make the modifications in 
the kernel later.
Also, I hope the XH8196's UMAC library is not "SoftMAC version 2", again 
different from what we have seen so far, as the "softmac2.h" filename 
suggests.

> Now, as far as protocol reverse-engeneering is concerned : what i'd
> really like now is a driver able to provide logs for HostAP mode... Is
> the TIVO driver able to handler this ?

I don't know. The Tivo driver is only for the very same CPU which those 
devices are equipped with, and all the computers I have are x86-based. 
Perhaps I could emulate it...

> Is there any source code available ?

No. Obviously, Conexant keeps it confidential.

Regards,
Sebastien