Raspberrypi3: AUX Uart driver
Niteesh
gsnb.gn at gmail.com
Wed Jan 15 05:27:46 UTC 2020
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
On Tue, Jan 14, 2020 at 9:40 PM Niteesh <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> 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/20200115/33498e7c/attachment-0001.html>
More information about the devel
mailing list