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.maude...@embedded-brains.de > <mailto:christian.maude...@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...@gmail.com > <mailto:gsnb...@gmail.com> > > <mailto:gsnb...@gmail.com <mailto:gsnb...@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...@gmail.com > <mailto:gsnb...@gmail.com> > > <mailto:gsnb...@gmail.com <mailto:gsnb...@gmail.com>>> wrote: > > > > On Tue, Jan 14, 2020 at 1:57 PM Christian Mauderer > > <christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de> > > <mailto:christian.maude...@embedded-brains.de > <mailto: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> > > <mailto:gsnb...@gmail.com <mailto:gsnb...@gmail.com>> > > > <mailto:gsnb...@gmail.com <mailto:gsnb...@gmail.com> > <mailto: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> > > <mailto:christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de>> > > > <mailto:christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de> > > <mailto: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>> > > <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 > <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: > > > > > > > > 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>>> > > > <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 <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> > > <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 > <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> > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > <mailto:devel@rtems.org <mailto:devel@rtems.org> > <mailto: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> > > <mailto:christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de>> > > > > <mailto:christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de> > > <mailto: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 > <mailto:christian.maude...@embedded-brains.de> > > <mailto: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 > <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
