Raspberrypi3: AUX Uart driver

Mon Jan 13 08:08:17 UTC 2020

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

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

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