Raspberrypi3: AUX Uart driver
Niteesh
gsnb.gn at gmail.com
Wed Jan 15 11:13:11 UTC 2020
Thank you, it works now :)
I have tested in on a real rpi3 and on rpi2 using QEMU, it works on both of
them.
Shall I send it as two patches, because the first one adds the facility to
pass
user define functions to calculate baud divisor and the 2nd is the driver
patch?
On Wed, Jan 15, 2020 at 1:25 PM Christian Mauderer <
christian.mauderer at embedded-brains.de> wrote:
> On 15/01/2020 06:27, Niteesh wrote:
> > I commented out all FDT queries and everything works using ns16550
> driver.
> > How do I load FDT blob using uboot, I tried using the default
> > bootloader, but
> > it doesn't work. I tried the following command but they don't work
> > fatload mmc 0 0x200000 kernel7.img
> > fatload mmc 0 0x1000 bcm2710-rpi-3-b.dtb
> > fdt addr 0x1000
> > fdt boardsetup
> > go 0x200080
>
> Instead of "go 0x200080" try it with bootm with the syntax for linux:
>
> https://www.denx.de/wiki/view/DULG/UBootCmdGroupExec#Section_5.9.4.2.
>
> With the commands you used it should be a
>
> bootm 0x200000 - 0x1000
>
> Best regards
>
> Christian
>
> >
> > On Tue, Jan 14, 2020 at 9:40 PM Niteesh <gsnb.gn at gmail.com
> > <mailto:gsnb.gn at gmail.com>> wrote:
> >
> > 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
> > <mailto:gsnb.gn at gmail.com>> wrote:
> >
> > On Tue, Jan 14, 2020 at 1:57 PM Christian Mauderer
> > <christian.mauderer at embedded-brains.de
> > <mailto: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>
> > > <mailto: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>
> > > <mailto: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>>
> > > > <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:
> > > >
> > > > 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>>>
> > > > > <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
> > <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>
> > <mailto: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>
> > > <mailto: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
> > <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/20200115/3b240671/attachment-0001.html>
More information about the devel
mailing list