I now have access to a Rock64-4GB (Rock64_V2.0 board); I hope to put FreeBSD on it someday

[Mark Millard]

[I wish I had control of the rate to allow it to
be slowed down.]

On 2018-Jan-6, at 1:58 PM, Rodney W. Grimes <freebsd-rwg at pdx.rh.CN85.dnsmgr.net> wrote:

>> On 2018-Jan-6, at 8:45 AM, Emmanuel Vadot <manu at bidouilliste.com> wrote:
>> 
>>> On 2018-01-06 17:43, Emmanuel Vadot wrote:
>>>> On 2018-01-05 15:45, Mark Linimon wrote:
>>>>> On Fri, Jan 05, 2018 at 06:27:41AM -0800, Mark Millard wrote:
>>>>>> the early boot baudrate for the console is apparently 1.5Mbit/s
>>>>> I've had to use minicom.  That's the only thing that I'm sure supports it.
>>>>> mcl
>>>> Works fine with tip(1) here using an FDTI usb<->serial, using a
>>>> PL2303XA doesn't work (but should based on the datasheet), and my
>>>> CP2108 should work but I haven't tested yet.
>>> 
>>> Also my PL2303XA adapter works on linux using minicom but only for RX, that might be a driver issue.
>> 
>> I've been using Serial on an old MacOS X laptop.
>> I've done more experiments. Here is what I've
>> observed. . .
>> 
>> For a CH340G, Serial did not allow 1500000
>> (built-in driver for USB ID 1a86:7523:0254)
>> but Serial is being updated to allow it. (I
>> have a preliminary release now, so I have
>> 1500000 support now.)
> 
> I have to seriously laugh at the idea of doing
> TTL serial ports at 1.5MHz down unbalanced,
> unterminated single end wires.  Just not a
> reliable way to communicate.

The ROCK64 simply starts out at this rate
before anything else has control, or at
least that is my understanding.

So as a console for the early boot sequence
I'm stuck with the fast rate as far as I
know.

> Hopefully your doing this at 5V, at least
> then you have a good noise margin, at 3.3V
> you lose another 33% of that.

Again, not under my control. But as I
understand it is 5V.

> Also most of these USB/232 adapters have no
> way to do flow control, so you better have
> a darn big fifo or your host usb stack better
> be darn fast at getting data off the chip.

Early boot code likely does not deal with
genearl flow control either, not being
willing to wait/suspend for long --or so
would be my guess.

The normal instructions are to disable XON/XOFF,
RTS/CTS, and DTR/DSR (if it is even possible).
(The context is normally 3 wire.)

I would not expect general flow control until
far more software infrastructure is around.

> Would be interesting to do a quick Zo calculation
> for the setup and put a proper set of termination
> resistors on the receive end of the signals to
> see how it cleans it up.  Or even look at it with
> a good DSO to see how bad and long it rings.

I do not have the equipment or other context
for such. But, yea, it would be nice.

> I know that 1.5Mhz is kinda slow, but it is the
> edge rate that matters, and TTL drivers have
> pretty fast edge rates, 1nS to 3nS is common,
> so effectivly your trying to send a 300Mhz 
> to 1Ghz signal down a wire, its gona be ugly
> at the other end!

I have a general awareness of this, though I'm
no electrical engineer. I've helped expose the
signal structures that logic analyzers get via
interposer and probing systems, both for
processors and for memory.

>> However, there was extensive dropped text from
>> sustained output in my limited testing of this
>> combination.
>> 
>> [The CH340G is from the type of serial console
>> for the ROCK64 that is sold at pine64.org .]
>> 
>> I got access to a CP2102 and tried it with Serial
>> (again a built-in driver, but for USB ID
>> 10c4:ea60:0100). There is far less dropped text,
>> although it does happen on occasion for sustained
>> serial output.
>> 
>> I've not tried a FT232R with Serial (AppleUSBFTDI
>> driver for USB ID 0403:6001:0600) but could have
>> access to do so.
>> 
>> I've not tried a LP2303X/HX/TA with Serial
>> (built-in driver for USB ID 067b:2303:0300) but
>> could have access to do so.
>> 
>> (The device identifications are as reported by
>> Serial, both USB ID and "Chip" name.)
>> 
>> 
>> 
>> As stands for ubuntu 16.04's top on the ROCK64,
>> running via a 70 line window in Serial, I've
>> yet to see a screen update that looked completely
>> good.
>> 
>> But most lines for the CP2102 and Serial
>> combination look good for each update so far.
>> 
>> By contrast, the CH340G with Serial had text
>> all over the place with few lines ever looking
>> good. The bad lines were hard to interpret.
>> 


===
Mark Millard
markmi at dsl-only.net