Date: Sat, 6 Jan 2018 14:25:58 -0800 From: Mark Millard <markmi@dsl-only.net> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> Cc: Freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: I now have access to a Rock64-4GB (Rock64_V2.0 board); I hope to put FreeBSD on it someday Message-ID: <C593482E-7949-4D1B-B34E-3944387EECDD@dsl-only.net> In-Reply-To: <201801062158.w06LwbY1013783@pdx.rh.CN85.dnsmgr.net> References: <201801062158.w06LwbY1013783@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[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: >>=20 >>> 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. >>>=20 >>> Also my PL2303XA adapter works on linux using minicom but only for = RX, that might be a driver issue. >>=20 >> I've been using Serial on an old MacOS X laptop. >> I've done more experiments. Here is what I've >> observed. . . >>=20 >> 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.) >=20 > 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=20 > 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. >>=20 >> [The CH340G is from the type of serial console >> for the ROCK64 that is sold at pine64.org .] >>=20 >> 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. >>=20 >> I've not tried a FT232R with Serial (AppleUSBFTDI >> driver for USB ID 0403:6001:0600) but could have >> access to do so. >>=20 >> 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. >>=20 >> (The device identifications are as reported by >> Serial, both USB ID and "Chip" name.) >>=20 >>=20 >>=20 >> 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. >>=20 >> But most lines for the CP2102 and Serial >> combination look good for each update so far. >>=20 >> 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. >>=20 =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C593482E-7949-4D1B-B34E-3944387EECDD>