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