Raspberrypi3: Mini UART driver
Joel Sherrill
joel at rtems.org
Tue Dec 24 19:04:41 UTC 2019
On Tue, Dec 24, 2019, 12:07 PM Niteesh <gsnb.gn at gmail.com> wrote:
> How to handle different serial devices? In other BSPs the uart devices are
> the same, so
> they were able to put it under a single array? But here we have 2 uarts
> and a FB?
>
The PC has a similar mix. The minor device number should get you into the
device array and to.methods which are device specific.
FWIW the PC can probe the PCI bus and dynamically add devices.
>
>
> On Tue, Dec 24, 2019 at 8:18 PM Christian Mauderer <list at c-mauderer.de>
> wrote:
>
>> 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
>> > > >
>> > >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191224/c69cbec0/attachment-0001.html>
More information about the devel
mailing list