Raspberrypi3: AUX Uart driver

Sun Jan 12 20:26:06 UTC 2020

On Sun, Jan 12, 2020 at 11:42 PM Christian Mauderer <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.

> >
> > 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?

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.

> >
> > 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>> 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.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200113/fc020f6d/attachment.html>