Firmware bring-up status

Spacefalcon the Outlaw falcon at ivan.Harhan.ORG
Fri May 1 22:15:48 CEST 2015


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

> Regarding the weird crash, I've encountered a similar issue when
> resetting the C118, it appears that the SRAM or internal CPU
> registers take a while to properly reset to their initial state.

Yes, very possible indeed.  Of course it raises the question of how
come TI's official firmware boots just fine every time no matter how I
power-cycle it - but perhaps they do some extra (seemingly redundant)
register initialization which I neglected to replicate.  To be
investigated...

> As of now I'm using a controllable relay to properly disconnect the
> battery for a couple seconds between CPU reset, this seems to take
> care of the issue.

In my experiments I had to insert a 20 s delay (echo 0 > power_on;
sleep 20; echo 1 > power_on) to make the boot *almost* reliable - and
even then it would still crash on boot sometimes!

> Although the battery is controller through the JTAG
> SRST, the same could be achieved with a teensy's GPIO for instance.

On the Openmoko GTA02 (Neo Freerunner) there is an RT9702A MOSFET
power switch between the actual battery and the VBAT input to the
modem (to the Iota and Rita chips more specifically), controlled by a
GPIO line of the same device's Linux AP (application processor).  This
is the mechanism I use to power the modem on and off.

> If you think this might solve your issue, let me know and I can walk
> you through the setup. It's unfortunate that there are no Motorola
> 850/1900 Calypso-based phones that have, to my knowledge, JTAG exposed -
> this could be very useful for your testing.

The real problem is that in the present phase of the firmware bring-up,
the only target device I can use is the GTA02 modem.  On this target
device we have a working reference in the form of TCS211/leo2moko
semi-src firmware, and we can debug problems in our own fw by comparing
the behavior of the two firmwares and finding the offending difference.
That is how I found and fixed the UART problem, for example.  (And it's
important to keep in mind that because our TCS211 reference is a semi-
src and not a total black box, we have some ability to add debug probes
to it, enable and decode traces etc.)

Now a good question to ask would be: can we still do this comparison
between our own fw and the TCS211 reference if the two run on different
target devices?  Could we not compare the behavior of our fw running
on Mot/Pirelli against that of TCS211 running on the GTA02 modem?  I
think we can probably do it in many cases, and it may be useful.

But then we get to another problem: just like TCS211 and all other
standard TI firmwares, our current fw uses separate UART channels for
the AT command interface and for RVTMUX.  My medium-term plan is to
implement a way to pass AT commands over RVTMUX, so we can make do
with just one UART - there is only one UART conveniently accessible on
our non-Openmoko targets.  But it will be a non-trivial feature to
implement, and will probably involve a lot of quite invasive digging
in the guts of TI's ACI code.  Right now we have code that is almost
certainly broken in several places, and it seems much saner to me to
make it work the same as TCS211 first (two UARTs), and *then* do the
surgery for AT-over-RVTMUX.  Doing it the other way around seems
insane to me: when we've got broken code, we need to fix it first, not
break it further!

Now you got me thinking: the Pirelli DP-L10 has an unpopulated
footprint for an FPC connector that brings out JTAG *and* the 2nd
UART.  Something to think about...

SF


More information about the Community mailing list