Raspberrypi3: AUX Uart driver
Christian Mauderer
christian.mauderer at embedded-brains.de
Wed Jan 15 11:44:50 UTC 2020
On 15/01/2020 12:13, Niteesh wrote:
> 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?
Yes that sounds like two patches.
>
> On Wed, Jan 15, 2020 at 1:25 PM Christian Mauderer
> <christian.mauderer at embedded-brains.de
> <mailto: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>
> > <mailto: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>
> > <mailto: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>
> > <mailto: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>>
> > > <mailto: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>>
> > > <mailto: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>>>
> > > > <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:
> > > >
> > > > 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>>>>
> > > > > <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
> <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>>
> > <mailto: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>>
> > >
> <mailto: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>
> > <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.
More information about the devel
mailing list