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? Best regards Christian > > On Mon, Jan 13, 2020 at 3:46 PM Niteesh <gsnb...@gmail.com > <mailto:gsnb...@gmail.com>> wrote: > > On Mon, Jan 13, 2020 at 1:38 PM Christian Mauderer > <christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de>> wrote: > > On 12/01/2020 21:26, Niteesh wrote: > > On Sun, Jan 12, 2020 at 11:42 PM Christian Mauderer > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > > <mailto:l...@c-mauderer.de <mailto:l...@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 > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de>> > > > <mailto:l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@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@rtems.org <mailto:devel@rtems.org> > > http://lists.rtems.org/mailman/listinfo/devel > > > > -- > -------------------------------------------- > embedded brains GmbH > Herr Christian Mauderer > Dornierstr. 4 > D-82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > <mailto:christian.maude...@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.maude...@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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
