Raspberrypi3: AUX Uart driver

Niteesh gsnb.gn at gmail.com
Mon Jan 13 18:04:28 UTC 2020 

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?

On Mon, Jan 13, 2020 at 3:46 PM Niteesh <gsnb.gn at gmail.com> wrote:

> On Mon, Jan 13, 2020 at 1:38 PM Christian Mauderer <
> 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>> 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>>> 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200113/706d1680/attachment-0001.html>

More information about the devel mailing list