From owner-freebsd-arm@freebsd.org Sat Jan 6 22:26:07 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A6F4DF6459 for ; Sat, 6 Jan 2018 22:26:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-113.reflexion.net [208.70.210.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4976C21E8 for ; Sat, 6 Jan 2018 22:26:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21928 invoked from network); 6 Jan 2018 22:26:00 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Jan 2018 22:26:00 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.4) with SMTP; Sat, 06 Jan 2018 17:26:00 -0500 (EST) Received: (qmail 4185 invoked from network); 6 Jan 2018 22:25:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 Jan 2018 22:25:59 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 58655EC8BF3; Sat, 6 Jan 2018 14:25:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: I now have access to a Rock64-4GB (Rock64_V2.0 board); I hope to put FreeBSD on it someday From: Mark Millard In-Reply-To: <201801062158.w06LwbY1013783@pdx.rh.CN85.dnsmgr.net> Date: Sat, 6 Jan 2018 14:25:58 -0800 Cc: Freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <201801062158.w06LwbY1013783@pdx.rh.CN85.dnsmgr.net> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 22:26:07 -0000 [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 wrote: >> On 2018-Jan-6, at 8:45 AM, Emmanuel Vadot = 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