BenQ M32 modem modules

[Mychaela Falconia]

Hi DS!

> The amount of traces, by default, is quite small. Here is the output:
>
> [all GPF ASC or GPF UNK]

Wow, so there were no RV or L1 output lines at all?  BenQ must have
hacked their fw very thoroughly to remove all of those goodies from
TI, just like they must have gone through a major effort to not use
TI's FFS, without any apparent good reason.

Explanation about GPF ASC/UNK: when I first powered up the D-Sample
board I scored in 2015, that came with an ancient fw image dated
20020917 (but this one is from TI themselves, not some other company
that hacked TI's code to pieces), I saw that this ancient fw has the
familiar binary packet encapsulation on the IrDA UART, so our rvinterf
tools can talk to it at least on the low level, and that fw version
also emits some familiar RV and L1 traces (unlike BenQ's, apparently),
and that it also has GPF - but the GPF trace format was different from
what I was used to.

It appears that TI had changed the packet format for their GPF traces,
system primitives and PS primitives at some point between that ancient
20020917 fw and the Openmoko-era firmwares we work with.  The only GPF
packet format we know in detail is the one implemented by the TCS211
fw version all of our FC firmwares are based on, and also by Pirelli's
and Compal's firmwares.  In the case of our TCS211 reference fw we got
lucky in that we have the source for that part of GPF, thus
understanding the packet format for GPF traces and sysprims and so
forth was simply a matter of reading and understanding that source.

But the few GPF traces which the ancient 20020917 fw on the D-Sample
emits on its own are in a different format, and those happen to be all
ASCII.  That was when I added the GPF ASC decoding to rvtdump/rvinterf:
if a received GPF packet does not follow the structure expected with
our TCS211-based fw, it gets reported as a GPF UNK raw hex dump, but
if it also happens to be all ASCII, it gets printed as GPF ASC instead.

Because we only have a few examples of these old-stype GPF packets and
no source code from which to learn their structure rules, our knowledge
is very incomplete.  In the case of BenQ's traces you have shared, the
str2ind version and "All tasks entered main loop" traces are exactly
the same as what I got from that 20020917 D-Sample fw, so they got
printed as GPF ASC, but the exception log traces have a 00 byte after
SYSTPCO instead of the ASCII space, so they got printed in GPF UNK raw
hex dump form.

Given that BenQ's proprietary fw has no TIFFS, emits no RV or L1
traces and has an older GPF version which we don't know how to talk
to, the value of using these BenQ modem modules in their as-is form is
down to near zero: just another proprietary modem, and a very old and
obscure one at that.

> The AT command line interface appears to work fine although I haven't
> really tried to exercise it.

If we are going to be making our own FC modem module in the physical
form factor copied from BenQ M32 (at this point it is a very big if,
as no sponsors have been forthcoming to fund that venture), we would
need to make a special production test fixture: a board with a custom-
designed and custom-made (hence very non-trivial cost) spring socket
into which a freshly made M32-form-factor module can be inserted
without soldering, providing all of the interfaces (power, RF, SIM,
both UARTs and so forth) so that this newly made module can be fully
tested.

A production test fixture as I just described would be an absolute
requirement if my FC modem module idea is ever to become reality,
hence the need for non-trivial financial sponsorship.  And if we ever
do get the needed sponsorship and proceed with the idea, it would make
the most sense to build the production test fixture *before* we make
the first batch of the actual modem modules.  If we make the actual
modem modules first, we would have them just sitting there as eye
candy with no way to test them, and if we make both the modules and
the test fixture at the same time, debugging would be hell as we won't
know if any given problem is in the modules or in the test fixture.

But if our physical form factor is going to be strictly identical to
BenQ M32 and we build the production test fixture first, we could
prove the test fixture working with the existing historical BenQ
modules (including thorough RF testing on the CMU200 through that
fixture!), and then proceed to make our own modules with a known good
fixture to test them.  This is the reason why I secured 15 of those
historical M32 modules in my hands, to cover both the destructive
reverse eng needs and later exercising our production test fixture.

M~