Raspberrypi3: Mini UART driver
Niteesh
gsnb.gn at gmail.com
Tue Dec 24 18:19:10 UTC 2019
And also the register definitions are in raspberrpi.h file should I move
them to usart.h.
I have a doubt we have a register field in device_context
typedef struct {
rtems_termios_device_context base;
const char *device_name;
volatile some_chip_registers *regs;
} my_driver_context;
How does the reg field point to the correct memory location? for instance
in IMX BSP,
there is a struct with register field's but none of the define a memory
location?
On Tue, Dec 24, 2019 at 11:37 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?
>
>
> 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/1e410c7b/attachment-0001.html>
More information about the devel
mailing list