Raspberrypi3: AUX Uart driver

[Niteesh]

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.

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?

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.

On Sun, Jan 5, 2020 at 12:57 AM Christian Mauderer <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/20200112/f9512a17/attachment.html>