Raspberrypi3: AUX Uart driver
Niteesh
gsnb.gn at gmail.com
Tue Jan 14 16:10:27 UTC 2020
I am finished with code, I tested it in QEMU emulator raspi2but it doesn't
work
when testing on real rpi3. I don't know if the problem is with loading the
FDT
or with my code?
How do I send the code, so that you can take a look at it?
On Tue, Jan 14, 2020 at 8:04 PM Niteesh <gsnb.gn at gmail.com> wrote:
> On Tue, Jan 14, 2020 at 1:57 PM Christian Mauderer <
> christian.mauderer at embedded-brains.de> wrote:
>
>> On 13/01/2020 19:04, Niteesh wrote:
>> > 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?
>>
>> Is the driver still able to handle different baud rates with this? Does
>> the ioctl call for setting the baudrate work?
>
> I didn't think about this, it won't work if we are using this method.
> ns16550_set_attributes
> calls ns16550_GetBaudDivisor, then I think we will have to stick with the
> old method.
>
>>
>>
> Best regards
>>
>> Christian
>>
>> >
>> > On Mon, Jan 13, 2020 at 3:46 PM Niteesh <gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>> wrote:
>> >
>> > On Mon, Jan 13, 2020 at 1:38 PM Christian Mauderer
>> > <christian.mauderer at embedded-brains.de
>> > <mailto: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>
>> > > <mailto: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>>
>> > > > <mailto: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 <mailto: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
>> > <mailto: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.
>> >
>>
>> --
>> --------------------------------------------
>> 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/20200114/a444cd89/attachment-0001.html>
More information about the devel
mailing list