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...@gmail.com> wrote: > On Tue, Jan 14, 2020 at 1:57 PM Christian Mauderer < > christian.maude...@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...@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
