Raspberrypi3: AUX Uart driver

[Christian Mauderer]

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.

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

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