FCDEV3B bring-up status

Tue Apr 18 03:05:24 UTC 2017

I see following unit http://www.ebay.com/itm/142228183988 for sale right
now. It has GSM and GPRS options installed. Seems like decent alternative
to CMU200. Not sure how accurate it is now, but it has external reference
input and 10MHz GPS modules are pretty cheap these days. Any opinions?

On Mon, Apr 17, 2017 at 2:04 PM, Mychaela Falconia <
mychaela.falconia at gmail.com> wrote:

> 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~
> _______________________________________________
> Community mailing list
> Community at freecalypso.org
> https://www.freecalypso.org/mailman/listinfo/community
>