Firmware bring-up status

[Spacefalcon the Outlaw]

Das Signal <das.signal at freecalypso.org> wrote:

> At this point, I don't know yet how GSM bring-up works in the firmware,

Me neither: getting TI's code to compile and link in our own framework
is one thing, actually understanding how it is supposed to work is
quite another story...

> but it might be a good idea to compare the RVTMUX output of the normal
> firmware vs. the one that you compiled.

By default the only component that emits traces on RVTMUX is L1 (all
G23M components have their traces disabled by default), but yes, we'll
need to look at each protocol stack component (including L1), enable
its traces if necessary, and compare what the traces show between the
working and non-working versions.

There is one other thing I would really like to try, although it will
be difficult.  As we all know by now, the GSM protocol stack code we've
got came from TI's LoCosto program, not Calypso.  As we wrestle with
making it work on our Calypso targets, it would be nice to have one
additional reference: seeing it work on its original LoCosto target
hw, and I mean actually *seeing* it work there, rather than just
rationalizing "well, it must have worked on the platform for which TI
officially released it".

I know of one person in Florida (opposite side of the USA-occupied
continent from where I live) who has one of TI's I-Sample development
boards for the LoCosto chipset - in fact, what he has is not just a
bare I-Sample board (we could recreate that one, as we have the PCB
design file: just export gerbers from it and send them to fab), but a
complete kit with the case and test handset - it looks just like the
D-Sample and E-Sample ones depicted on pages 12 and 15 of TI's
presentation:

ftp://ftp.ifctf.org/pub/GSM/Calypso/chipsets+refdesigns.pdf

And this fellow also worked long enough with that darned LoCosto
chipset to where he may still remember how to use TI's nasty Windows-
based tools to load fw images into LoCosto targets - LoCosto's boot
ROM is quite different from Calypso, hence our loadtools won't work,
unless we spend oodles of time and effort to RE LoCosto's boot ROM and
its new code loading protocols. :(

I would like to visit this gentleman in Florida, sit down with him,
bring up TI's LoCosto tools, flash the "reference" TCS3.2 firmware
image (the TCS3.2_N5.24_M18_V1.11_M23BTH_PSL1_src.zip drop from which
we took our L1 and G23M sources also contains a fully linked image
built from these sources with the original "official" toolchain) into
his I-Sample board, and see it run there.  There is a chance I might
be able to convince him to lend his I-Sample kit to me for the
duration of our fw bring-up effort, so I could take it with me to
California, but I would still need to visit him in Florida first so we
could sit down together and get the image loading and trace display
etc tools working - I would much rather get the know-how from a real
person who has done it successfully before than try to figure it out
blindly on my own.

But of course it would cost money for me to travel to Florida and stay
there for a few days - more money than I can afford to spend, even
with all of the donations we got through the Indiegogo campaign (a big
heart-felt thank-you for those, it means a lot to me and Shannon!) -
so this idea of traveling to Florida to see our starting-point GSM
protocol stack code run on its original target will probably have to
wait until we find a richer sponsor for our project.

> Of course I imagine in the case
> of the leo2moko patching one or more binary object may be necessary to
> enable more debug output.

Actually it isn't necessary to patch anything, neither source nor
binary: one can enable trace output from any given G23M PS component
by sending it a TRACECLASS GPF "system primitive".  The procedure is
described in this TI document:

http://scottn.us/downloads/peek/SW%20doc/frame_users_guide.pdf

With our FreeCalypso rvinterf tools, the tool for sending these GPF
"system primitives" to a running fw is g23sh.

> Also I can give you a hand with JTAG, although first I'll have to compile
                                                                    ^^^^^^^
> and run freecalypso on the C118. I hope to be able to do so later this
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> week.

If you are really brave enough to attempt the highlighted part, it
would be awesome!  Here are the issues I can think of which will need
to be fixed or kludged around:

* TI's development boards for Calypso and earlier chipsets had a DCD
  (V.24 modem control line) output on GPIO 2.  This twiddling of GPIO2
  output to reflect DCD state is still there in the firmware that runs
  on Openmoko's modem - it's an unconnected GPIO pin, so making it an
  output is good (avoids floating) and twiddling it as DCD is useless
  but also harmless.  I don't know off the top of my head what GPIO2
  is connected to on Compal targets, if anything - if it's an input or
  an output that controls something else that shouldn't be messed
  with, the DCD output "feature" will need to be conditioned out.

* Take a _good_ look at gsm-fw/L1/tpudrv/tpudrv12.c - you'll see that
  in my re-C-fication of that code (reconstruction of lost C source
  from disassembly of the compiled object) so far I've only done the
  absolute minimum work necessary to produce a C module that can
  compile with gcc to produce an equivalent to the original COFF
  object.  In other words, this current tpudrv12.c is only correct (or
  more precisely, stands a chance of being correct - we don't know yet
  whether it is or not) for Leonardo and gtamodem targets.  The RFFE
  control signals on Compal targets are different: compare the compal
  and gta0x RFFE code in OsmocomBB to see for yourself.  In order to
  make our tpudrv12.c code work on targets that aren't Openmoko or
  Leonardo, we'll need to go through all those 0xblah magic constants
  (lifted directly from tpudrv12.obj w/o attempt at understanding)
  with a fine-toothed comb and figure out what they need to be changed
  to.

* If the goal is to run on C11x/123 or C139/140, as opposed to C155/156,
  the intermediate flash boot stage to be placed at 0x2000 still
  remains to be written (see gsm-fw/sysglue/flashboot.S).  Or
  alternatively, since you've got JTAG working and can presumably
  unbrick fully bricked flash, you can just build the firmware with
  FLASH_BOOT_VIA_BOOTROM enabled instead of going through the
  contortions I have planned for non-JTAG-enabled C1xx users...

Happy hacking,
Mychaela aka Space Falcon