FCDEV3B bring-up status

[Mychaela Falconia]

Das Signal wrote:

> As Mychaela has mentioned, the CP2102 works well. However if you prefer to
> use a FT232 and cannot easily patch your kernel, you will find attached a
> patch to fc-tools that adds the option -f, enabling the ftdi workaround that
> uses FTDI's proprietary ASYNC_SPD_CUST (if you don't pass -f, the tools do
> work as before).

I considered implementing something like what you did when I first
learned about FTDI adapters and their "official" way of selecting
non-standard baud rates, but then decided against it when I studied
the in-kernel driver code and saw what it actually does.  When you set
that ASYNC_SPD_CUST bit, the number you put in the custom_divisor
struct member from userspace does NOT get used directly as the actual
divisor sent to the chip, instead the in-kernel driver does a double
conversion: first from the userspace divisor to baud rate value in bps,
and then calculates the actual divisor from the latter following the
regular code path.  Because of rounding, the resulting actual divisor
may not be what you set from userspace.  As I wrote in my
High-speed-serial article, I consider this design to be fundamentally
broken.  My ugly patch to the in-kernel driver avoids the double
conversion by setting the desired bps value directly, and then fixing
the divisor calculation to work more properly.

As another alternative to dirtying your kernel with a non-upstreamable
patch that breaks things for other people who use 230400, 460800 or
921600 baud, I just thought of the following idea:

* Reprogram the EEPROM on your FreeCalypso FT2232D adapter to give it
  some VID:PID which the standard ftdi_sio driver won't recognize and
  won't attach to.  The EEPROM is off-chip and optional with FT2232D,
  but the adapter boards from pldkit.com which I use and recommend do
  have it.

* Make a copy of the ftdi_sio driver and build it outside of the Linux
  kernel tree (i.e., make it an out-of-tree module) under a different
  name.  Make it bind to the FreeCalypso FT2232D VID:PID you have
  picked, and have this special out-of-tree driver version remap baud
  rates like my current patch does.

* Voila - your actual kernel is now completely pristine, and I would
  think that loading a custom out-of-tree USB driver module that has
  proper GPL status (no taint in that regard) and does not touch
  anything except the special USB VID:PID you have made up for
  FreeCalypso use should not count as tainting your system.

[ARM7 gcc toolchain]
> I agree that it would be nice for the project to provide
> those binaries, like what we already do for the wine development environment
> at ftp://ftp.freecalypso.org/GSM/TI_src/wine/

Perhaps you could build such binaries and put them up in your member
directory?

> Apparently the attachment was scrubbed. Please find the patch here:
> https://www.freecalypso.org/members/ds/ftdi.patch

Email attachments are evil, especially on mailing lists.  Using member
directories like DS just did is the proper alternative.  For anyone
else who does not have a member directory and would like one, please
send your ssh public key and your preferred username to me or to DS,
and we'll create an account for you.

Serg wrote:

> You mentioned running Slackware. Personally I have no specific preference,
> so if you would share dev host details,like distro version, kernel version
> and etc. I can just follow known good configuration. At this stage I'm not
> into reinventing the wheel.

I use Slackware version 13.37, 32-bit only - my total physical RAM is
2 or 3 GiB (don't remember which), I have no need for large RAM, and
thus no need for x86_64.  The kernel version is 2.6.37.6, which is the
default with this rather dated version of Slackware.  Slackware has no
updates, which is what I like - I like long-lasting software, I believe
that the software a person uses should last as long as her or his
natural biological lifespan, with no need for "upgrades" ever.

> I also like FT2232D option as it supports SPI on the port A, something I
> will definitely explore later on.

I assume you are talking about MCSI, right?  Before you commit too
much to the FT2232D-to-MCSI idea, please realize that FTDI's MPSSE can
only operate as a sync serial master, not slave, thus the MCSI would
need to be in slave mode for this idea to work.  And we still have not
determined which mode (master or slave) TI's DSP ROM (or the DSP ROM
plus the patches applied by TCS211 fw) puts the MCSI into when
commanded into "Bluetooth headset" operation, or at least I have not
made any such determination.  If you are ready to experiment in this
direction, you could try the following:

* Rebuild FC Magnetite with MCSI enabled in the pin multiplexing setup
  - see src/cs/drivers/drv_core/armio/armio.c line 188, put an #if 1
  there.

* Issue an auw 0 2 command through fc-tmsh to enable the "Bluetooth
  headset" audio routing mode.

* Put an oscilloscope probe on the MCSI_CLK line (J311 pin 1) and see
  if there is a clock there.  If there is a clock being put out,
  please tell us what clock frequency you see there, and also what do
  you see on the MCSI_FSYNCH line (J311 pin 4).

M~