Raspberrypi3: Mini UART driver

Sun Dec 22 19:34:34 UTC 2019

On 22/12/2019 19:45, Joel Sherrill wrote:
> 
> 
> On Sun, Dec 22, 2019, 12:29 PM Niteesh <gsnb.gn at gmail.com
> <mailto:gsnb.gn at gmail.com>> wrote:
> 
>     On Sun, Dec 22, 2019 at 8:44 PM Christian Mauderer
>     <list at c-mauderer.de <mailto: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?
> 
> 
> I think there are almost always two steps to a project like this: get it
> to work and make it nice. :)
> 
> If you fix the startup code to read the board revision and memory size,
> you can get a working BSP that dynamically adapts to the models and
> memory variations with minimal modifications. If you want to then
> convert the BSP to FDT, it will be a LOT easier to debug with a working BSP.
> 
> Plus you may be able to identify every variation point based on just the
> model info. Then FDT is just a matter of switching the source of
> some/all of the info.
> 
> That would be my work plan anyway.

I agree with Joel that a secure development basis (also known as "hack")
as a first step is a good idea. You maybe even just make the mini UART
the default driver while you are developing. Then you can be sure that
you have the right driver.

As soon as that works you can either change to the revision method or
(better) to the FDT one and after that the patches can be merged. Using
the FDT isn't that complicated. Basically you search for a node based on
different parameters. For an example you can take a look at the imx BSP.
In imx_uart_probe (bsps/arm/imx/console/console-config.c) a fdt node is
searched and based on that a UART driver is used. But again: Follow
Joels suggestion to start simple and secure.

> 
>         >
>         >
>         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.
> 

Great.

>          
> 
>         >
>         > 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
>         >
> 
>     _______________________________________________
>     devel mailing list
>     devel at rtems.org <mailto:devel at rtems.org>
>     http://lists.rtems.org/mailman/listinfo/devel
> 