Raspberrypi3: Mini UART driver

Christian Mauderer list at c-mauderer.de
Tue Dec 24 14:47:59 UTC 2019


On 24/12/2019 12:06, Niteesh wrote:
> The current raspi console section is like this:
> The bsp_console_select in console_select.c is responsible for selecting
> between uart and the framebuffer. It does so
> by setting the Console_port_minor.
> The console_config is responsible for output_char function.
> And other files are driver code.
> If rewriting, this would be my approach,
> Rewrite the bsp_console_select to set some kind of a variable like in
> IMX, then in console_initialize function
> link the right driver to /dev/console.
> Replace the console_tbl with the device_context and console_fns with
> termios_device_handlers and
> finally add in the console_initialization function.

I agree that this would be a clean solution. So if you want you can do
that. But there might is a hurdle: As far as I understood you you only
have a Pi3? So you might have a hard time testing the changes. Maybe the
simulator could work.

Another possibility could be to set the "Console_port_minor" to
something unused (for example -1). In that case you can define another
/dev/console.

Best regards and merry Christmas (in case you celebrate)

Christian

> 
> On Tue, Dec 24, 2019 at 2:13 PM Niteesh <gsnb.gn at gmail.com
> <mailto:gsnb.gn at gmail.com>> wrote:
> 
>     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 <mailto: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>
>         > <mailto: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>
>         >     <mailto: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>
>         <mailto: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>>
>         >             > <mailto: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>>
>         >             <mailto: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>>
>         >             <mailto: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
>         >             >
>         >
> 


More information about the devel mailing list