Raspberrypi3: Mini UART driver

Niteesh gsnb.gn at gmail.com
Sun Dec 22 18:29:45 UTC 2019


On Sun, Dec 22, 2019 at 8:44 PM Christian Mauderer <list at c-mauderer.de>
wrote:

> Hello Niteesh,
>
> thanks for doing that work.
>
> On 22/12/2019 12:10, Niteesh wrote:
> > The rpi1 and rpi2 use the PL011 UART, whereas, with RPI's equipped with
> > wireless/Bluetooth module, the PL011 is connected to the Bluetooth
> > module, and the mini UART is used as the primary UART.
>
> In my opinion it would be great if you could use the FDT to distinguish
> between the boards. That should allow to add raspberry 3 (and maybe 4)
> support without adding another BSP. More BSPs mean a bigger maintenance
> effort for the RTEMS community.

Learning more about FDT is on my list for a long time.  I would love to
work on that
but I have almost no exp with FDT's.
But another thing could also be done, in raspberrypi/start/bspstart.c we
get the revision and
model of the board using the mailbox. Every board has a unique id, which we
could use to initialize
the BSP. But using FDT seems to be a more elegant option, it is a lot of
work I think, but we could take
help from libbsd and linux I suppose. What do you think?

> >
> >
> https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
> > But from the above doc (PAGE 10), the mini uart has 16550 like registers
> > and RTEMS already has the driver for it
> > bsps/shared/dev/serial/ns16550.c. But I am not sure how compatible they
> > are? Should a new driver be implemented from scratch or use ns16550 if
> > possible?
>
> In general it's better to re-use existing code. That has multiple
> advantages:
>
> - It reduces the maintenance effort. Fewer code means fewer work.
> - If you have multiple driver for the same or similar hardware it can
> happen that a bug is fixed in one but not the other.
> - It's simpler to find a hardware to test changes.
> - The driver becomes more universal with every new supported hardware.
> That increases the chance that it fits the next new hardware.
>
> I'm sure there are some more if you ask someone else.

I do understand the issues, I just spent some time reading the driver code.
I think we could most probably use it. I will take a closer look and will
update.

>
>
>
> > Also, the core clock on which the PL011 is based on is changed in rpi3.
> > Rpi1 and 2 use 250Mhz as the default clock but it was changed to 400Mhz
> > in Rpi3 and newer
>
> Again: Would be great if that could be adapted based on FDT or by
> reading the right registers.
>
> >
> > Few differences between PL011 and Mini uart
> > The mini UART has smaller FIFOs. Combined with the lack of flow control,
> > this makes it more prone to losing characters at higher baud rates. It
> > is also generally less capable than the PL011, mainly due to its baud
> > rate link to the VPU clock speed.
>
> That shouldn't really be a problem for the system console.
>
> >
> > The particular deficiencies of the mini UART compared to the PL011 are :
> >
> > No break detection
> > No framing errors detection
> > No parity bit
> > No receive timeout interrupt
> > No DCD, DSR, DTR or RI signals
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191222/4335c421/attachment.html>


More information about the devel mailing list