Raspberrypi3: AUX Uart driver
Christian Mauderer
christian.mauderer at embedded-brains.de
Tue Jan 14 08:27:46 UTC 2020
On 13/01/2020 19:04, Niteesh wrote:
> The ns16550_context already has a field named baud_divisor, so if the
> user passes
> value for it, then we can skip the GetBaudDivisor function and use that
> value instead.
>
> Is this approach okay?
Is the driver still able to handle different baud rates with this? Does
the ioctl call for setting the baudrate work?
Best regards
Christian
>
> On Mon, Jan 13, 2020 at 3:46 PM Niteesh <gsnb.gn at gmail.com
> <mailto:gsnb.gn at gmail.com>> wrote:
>
> On Mon, Jan 13, 2020 at 1:38 PM Christian Mauderer
> <christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>> wrote:
>
> On 12/01/2020 21:26, Niteesh wrote:
> > On Sun, Jan 12, 2020 at 11:42 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,
> >
> > On 12/01/2020 16:06, Niteesh wrote:
> > > The only issue, I faced while using this driver is the
> baud divisor is
> > > calculated
> > > by CLOCK_FREQ/(BAUD_RATE * 16) (*ns16550-context.c:68)*
> > > but it should BAUD_DIV = (CLOCK_FREQ/(8 * BAUD_RATE)) -
> 1, for Rpi3.
> > > For testing, I assigned the baud divisor to 270 (115200
> bits/s) in
> > > ns16550-context.c,
> > > and everything works fine.
> >
> > Sounds great. In NS16550_GetBaudDivisor there is already a
> case where
> > the baudDivisor is calculated differently (depending on
> > ctx->has_precision_clock_synthesizer and
> > ctx->has_fractional_divider_register). If none of the two
> cases are ok
> > for the controller you could just add another one.
> >
> > Can we pass in a function, which gets called, won't this be more
> > flexible? because
> > in the future if we have some other board that has a different
> > calculation for the baud rate
> > the function will take care of it.
>
> It's possible. Please make sure to be compatible with the
> current API.
> For example if the pointer is NULL you should call the legacy
> function
> instead.
>
>
> I will be adding an extra field, a function pointer to ns16550_context,
> the prototype of the function would be *uint32_t
> calculate_baud_divisor( ns16550_context * )*
> This is will calculate the baud divisor using its own formula and
> the initial baud.
> If this function is not NULL then it would be called inside
> *NS16550_GetBaudDivisor* function,
> *
> *
>
> >
> > >
> > > For console selection, my plan is to search for the aux
> node using
> > > compatible
> > > property and if its status is enabled, then initialize
> the AUX
> > uart and
> > > set the BSP_output_char
> > > to aux_output_char, else pl011_output_char. All this
> will be done
> > inside
> > > the uart_probe function,
> > > except for the initialization of AUX which will be done in
> > init_ctx_aux.
> > > And finally, call the output char
> > > function using *BSP_output_char. Do you have any neat
> way to do this?
> >
> > I don't have an example for a similar case at hand. So:
> No, no neat way
> > that I can tell you.
> >
> > Before you start to write code: Please take a look at the
> different
> > beagle variants what is possible. Is there a variant where
> AUX uart
> > would be there but shouldn't be used as a console (one of
> the Zeros
> > maybe or the compute module?). How does Raspbian or
> FreeBSD decide which
> > port should be used? Maybe they decide based on the
> commandline.txt? In
> > such a case it would be better to just initialize all
> active (in the
> > fdt) serial ports and decide based on the commandline too.
> >
> >
> > The Documentation says the following:
> > *By default, on Raspberry Pis equipped with the
> wireless/Bluetooth*
> > *module (Raspberry Pi 3 and Raspberry Pi Zero W), **the PL011
> UART is*
> > *connected to the Bluetooth module, while the mini UART is
> used as the
> > primary UART and*
> > *will have a Linux console on it. On all other models, the
> PL011 is used
> > as the primary UART.
> >
> > *
> > *In Linux device terms, by default, /dev/ttyS0 refers to the
> mini UART,
> > and /dev/ttyAMA0 refers*
> > *to the PL011. The primary UART is the one assigned to the Linux
> > console, which depends on*
> > *the Raspberry Pi model as described above. There are also
> symlinks:
> > /dev/serial0, which always*
> > *refers to the primary UART (if enabled), and /dev/serial1, which
> > similarly always refers to the secondary UART (if enabled).*
> > *
> > *
> > I checked in all the DTB files, by decompiling them (files are
> > from https://github.com/raspberrypi/firmware/tree/master/boot).
> > In all board with support for wireless and bluetooth, the AuX
> is enabled
> > and serial0 points to it. So we could use serial0
> > to find the correct UART port. I think this is solid enough.
> So, should
> > I use this approach?
>
> Sounds OK. If possible please initialize the other UART too if it is
> enabled in the FDT. Although we don't support bluetooth yet
> maybe there
> will be support in the future or someone wants to do it in the
> application.
>
> I will go with this method then.
>
> >
> > Or if using the command line, then we need to move the link to
> > CONSOLE_DEVICE to console_initialize, and parse the
> > command line twice. If this is no problem, then we could use this
> > approach also.
>
> Would be possible too.
>
> >
> > >
> > > And why don't we have a function similar
> to *of_device_is_available*,
> > > since there will be more and more
> > > FDT based boards, this will be really helpful.
> >
> > I agree that it would be helpful. Seems that you just
> found a function
> > that should be in a FDT framework.
> >
> > RTEMS currently only has the basic libfdt functions and
> some RTEMS
> > specific ones. The of_... functions belong to the FreeBSD
> "Open Firmware
> > Bus" which is an abstraction layer on top of FDT. It would
> be great to
> > identify useful ones and port them or provide an RTEMS
> implementation.
> > Like already discussed this could be part of a GSoC project.
> >
> > Best regards
> >
> > Christian
> >
> > >
> > > On Sun, Jan 5, 2020 at 12:57 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>>
> > > <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:
> > >
> > > On 04/01/2020 09:32, Niteesh wrote:
> > > > We could now run RTEMS on Rpi3. I tried examples
> from the
> > samples
> > > > section and they run
> > > > fine. But still, a lot of functionality has to
> tested since it
> > > uses the
> > > > RPI2 BSP. To test these examples
> > > > I used a simple driver for the AUX.
> > > > The documentation from BCM link
> > > >
> > >
> >
> <https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf> (pg
> > > > no 10) states that
> > > >
> > > >
> > > > *The implemented UART is not a 16650
> compatible UART However
> > > as far
> > > > as possible the first 8 control and status
> registers are
> > laid out
> > > > like a 16550 UART.*
> > >
> > > It also tells
> > >
> > > "Al 16550 register bits which are not supported
> can be
> > written but
> > > will be ignored and read back as 0. All control bits for
> > simple UART
> > > receive/transmit operations are available."
> > >
> > > So I would expect that not everything works like
> expected (for
> > example
> > > setting DCD, DSR, DTR, RI - they are not there for
> the mini
> > UART) but
> > > the basic stuff should work.
> > >
> > > >
> > > >
> > > > My question is can we use the existing ns16550
> driver or
> > should I
> > > create
> > > > a new one? I also checked the address of the
> registers the
> > offsets
> > > don't
> > > > seem right to me, but someone should check and
> correct me if
> > I am
> > > wrong.
> > >
> > > If you compare the registers in the existing driver
> > > (NS16550_RECEIVE_BUFFER, ... in ns16550_p.h) and the
> one in
> > the BCM
> > > datasheet the registers look very similar (at least
> from the
> > position /
> > > function). I haven't done a bit by bit comparison
> yet. Please
> > note that
> > > you have to do a conversion between the defines and
> register
> > addresses.
> > > The define gives you a register index for a 32bit
> register. So
> > you have
> > > to multiply by 4 to get an address. The driver is
> designed
> > that you
> > > provide a setRegister and getRegister function that
> can do this
> > > conversion.
> > >
> > > Where did you find differences?
> > >
> > > I would suggest to just try the driver.
> > >
> >
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org <mailto:devel at rtems.org>
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.mauderer at embedded-brains.de
> <mailto:christian.mauderer at embedded-brains.de>
> Phone: +49-89-18 94 741 - 18
> Fax: +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des
> EHUG.
>
--
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel
mailing list