Choose between Raspberry Pi 4B 4GB and ROCKPro64

[Bernd Walter]

On Wed, Nov 13, 2019 at 10:37:22AM -0800, John-Mark Gurney wrote:
> Bernd Walter wrote this message on Wed, Nov 13, 2019 at 17:48 +0100:
> > On Wed, Nov 13, 2019 at 08:53:43AM +0100, Bernd Walter wrote:
> > > On Tue, Nov 12, 2019 at 02:52:51PM -0800, John-Mark Gurney wrote:
> > > > Bernd Walter wrote this message on Tue, Nov 12, 2019 at 23:16 +0100:
> > > > > On Tue, Nov 12, 2019 at 08:09:38AM -0700, Klaus Küchemann via freebsd-arm wrote:
> > > > > > <<The u-boot has to go into the SPI-Flash or on the card? >>
> > > > > > 
> > > > > > onto the uSD :
> > > > > > https://www.freshports.org/sysutils/u-boot-rockpro64/
> > > > > > Regards 
> > > > > > Klaus
> > > > > 
> > > > > Thank you.
> > > > > 
> > > > > Do you know the bps rate used by u-boot and later components?
> > > > > I do see some output at the usual 115200 bps, but it is messed up.
> > > > > Also tried other typical bps rates, including 1.5Mbps as mentioned
> > > > > on the RockPro Wiki, but none worked.
> > > > > I wouldn't rule out that it is the USB uart failing at 1.5M though,
> > > > > but I've tried a PL2303, CP2102 (which refused 1.5Mbps) and
> > > > > a CH340.
> > > > > Unfortunately I don't have an FTDI based TTL one at hands.
> > > > > It also fails with reading the uartt output when booting an Armbian
> > > > > image, which as such is booting fine according to the HDMI output.
> > > > 
> > > > It's 1.5Mbps, aka 1500000.  I'm using the CH340G that they sell:
> > > > https://store.pine64.org/?product=padi-serial-console
> > > > 
> > > > And it works, but it will occasionally drop characters.
> > > 
> > > Sigh - IMO 1.5M is an insane idea for that and so needless.
> > 
> > I assume that our driver only allocated one packet per frame.
> > This will max out at 64000 Bytes, or with 8n1 at 640kbps.
> > If that is the case then maybe the driver should increase the number
> > of packets per frame for bps rates over 600kbps.
> 
> Don't know USB, but looking at uchcom.c, it looks like it defaults
> to a 1k buffer size and 1 frame for transfers.  It also looks like
> this is setup at attach time, so we can't (easily) change is based
> upon speed.

My knowledge about USB is old, basicly USB1.1 aera, but the CH340G are
full speed devices, so it still should make some sense.
And my knowledge is limited to the old USB stack.
Full speed devices are allowed to have bulk packet sizes of up to
64 Byte.
I havn't checked, but I strongly assume that the CH340G announces 64 Bytes.
There there are 1000 frames per second.
When you want to receive data from such a device you put a receive packet
of 64 Bytes inside a frame.
When the device has anything to send it puts up to 64 Bytes payload into
the packet and acks the packet.
The transmission time required is always the full 64 Bytes, not matter
if anything has been send at all.
Therefor you usually want to sparsely do read requests.
Traditionally you can't schedule another packet until the next frame,
but I think HPS mentioned that some controllers are more clever than
that and you can schedule a new packet inside a frame, which already
started - on the other hand we rarely have full speed controllers these
days and almost always use transaction translators inside USB hubs to
convert speed between high speed host to low/full speed device for us.
Generally this means, unless we do multiple 64 bytes requests inside a
single frame, we are limited to 1000 frames/s with up to 64 bytes each.

> Would increasing the number of frames do what you're talking about?
> Say, to 3?  Would we also need to increase the bufsize to 64k, or
> leaving it at 1k is fine?

Don't know - frames doesn't make sense in the USB style of wording
I'm used to.
Maybe the new stack automatically increases the number of receive packets
depending on previous packets.
It surely does for umass, otherwise reading speed would be massively
limited, although on an umass device you know how much read data to
expect.
Maybe it is static and number of frames is what we need.
The allocated 1k buffer should be enough though.
Considering the flag "short_frames_ok", I think frame in the FreeBSD
source is what I know as packets.

What puzzles me is that usb/net/if_axe.c also does the same logic.
Maybe the new USB stack does some autoscaling.
Since the CH340G datasheet doesn't mention it's buffer size, it is
unknown how many USB-frames (miliseconds) we have time for the
autoscaling to kick in.

> > I just remembered that I own an FTDI FT4232H module.
> > This one is capable of 12Mbps with 2k Buffers and high speed USB.
> > I have it at a different location - guess I will have to drive and
> > pick it up.

High speed USB allows bigger packet sizes and the FT4232H should announce
512 Bytes, which means we do bigger packets.

> > > > None of my other serial adapters could do the speed necessary.
> > > 
> > > I just retried with the CH340 - again no success, but noticed that the
> > > chip on my adapter is unlabeled.
> > > So probably it isn't a genuine.
> > > I should have some others, but not at home, and I also have some
> > > loose CH340G chips.
> 
> -- 
>   John-Mark Gurney				Voice: +1 415 225 5579
> 
>      "All that I will do, has been done, All that I have, has not."

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.