Raspberrypi3: Mini UART driver
Niteesh
gsnb.gn at gmail.com
Mon Dec 23 18:46:50 UTC 2019
I would like to clarify my doubts regarding the console driver. I went
through the documentation
for the console driver
https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction.
But it is quite different from how some BSPs initialize.
Correct me if I am wrong
The console_tbl contains the various entries of serial ports.
The console_fns is a struct of function pointers, which point to the BSP
uart functions.
The BSP_output_char_function_type is what will be called for printing a
char on to the console.
How does RTEMS initialize the uart? It's seems not to be same for all BSPs.
The doc says that the driver's initialization function is called once
during the rtems initialization process.
The console init function install the serial driver using
rtems_termios_device_install but there seems to be
no such function in the raspberry pi? But there is a entry in console_fns
for init function, but then how does it
gets called?
And for BSP's with multiple serial's, the output function chooses the right
serial using console_port_minor,
Is it during initialization?
What is the need for get and set register functions?
On Mon, Dec 23, 2019 at 1:04 AM Christian Mauderer <list at c-mauderer.de>
wrote:
> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191224/90f89c43/attachment.html>
More information about the devel
mailing list