Raspberrypi3: Mini UART driver
Christian Mauderer
list at c-mauderer.de
Mon Dec 23 21:50:00 UTC 2019
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
> >
>
More information about the devel
mailing list