Raspberrypi3: Mini UART driver

Niteesh gsnb.gn at gmail.com
Tue Dec 24 08:43:57 UTC 2019


Thank you so much, for such a detailed answer. Now things make really good
sense to me,
going through the code now is just a breeze. But I still have one question
for the newer driver interface is console_initialize the function which
RTEMS calls while initializing
the console? Which means I can't mess with the name right? It is similar to
the main function, right?

The current driver is a legacy one, how do you want me to proceed, shall I
rewrite the legacy to a
the new one, this is will be a great learning experience for me also and we
also get the BSP updated to the latest interface.


On Tue, Dec 24, 2019 at 3:20 AM Christian Mauderer <list at c-mauderer.de>
wrote:

> Hello Niteesh,
>
> quite a lot of questions. I'll try to answer them. Note that it has been
> some time since I had a detailed look at that code so if something I
> tell seems odd please don't hesitate to question it.
>
> Please note that in RTEMS their are more or less two "levels" of support
> for a serial console:
>
> 1. A very basic polled system console (also known as "debug-console" in
> some BSPs). This one is used for printk and should work in basically
> every case. It is used for critical system messages like printing the
> exception frame. For that a BSP has to provide a "BSP_output_char"
> function.
>
> 2. A full featured UART driver integrated into Termios. That one will be
> used for all normal I/O on the UARTs.
>
> As far as I know the "console_tbl Console_Configuration_Ports" belongs
> to a table based legacy interface. It is handled in the file
> bsps/shared/dev/serial/legacy-console.c. I'm not sure whether it is
> documented in the BSP guide because it shouldn't be used for new BSPs.
> Same is true for the "major" and "minor" stuff: It's not really used for
> new drivers.
>
> Newer drivers use the initialization that is described in the manual
> that you have already found. Basically they use
> "rtems_termios_device_install" to register a new UART as
> "/dev/ttySomething". Some recent (ARM) BSPs that do that are the imx or
> the atsam.
>
> The console that is used for stdin, stdout and stderr (printf, scanf,
> ...) is the one called "/dev/console" (defined in CONSOLE_DEVICE_NAME).
> For the legacy table based interface it's the one with the index of
> "Console_Port_Minor".
>
>
> If you want to access any UART other than the one for stdin and stdout
> you do that the same way like on Linux: Just use the "open" function on
> the "/dev/ttySomething" and use "read", "write" and simmilar or use
> "fopen" together with "fread", "fwrite", "fprintf", ...
>
>
> "printf" (and family) is a function belonging to the C library. In our
> case that's newlib. It will format your message and after some other
> preprocessing will call the "write" function of the file that is opened
> as stdout (which is "/dev/console" in the default case).
>
>
> I hope that I helped you with that explanation. Please feel free to ask
> anything if it isn't clear.
>
> Best regards
>
> Christian
>
> On 23/12/2019 19:50, Niteesh wrote:
> > And finally, how does printf work? It is a macro? In that case, how does
> > any write to
> > a console work?
> >
> > On Tue, Dec 24, 2019 at 12:18 AM Niteesh <gsnb.gn at gmail.com
> > <mailto:gsnb.gn at gmail.com>> wrote:
> >
> >     Is the correct port minor number set during the initialization? What
> >     is the application want's to
> >     access some other port?
> >
> >     On Tue, Dec 24, 2019 at 12:16 AM Niteesh <gsnb.gn at gmail.com
> >     <mailto:gsnb.gn at gmail.com>> wrote:
> >
> >         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 <mailto: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>
> >             > <mailto: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>
> >             <mailto: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>
> >             <mailto: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/2069ede4/attachment-0001.html>


More information about the devel mailing list