<div dir="ltr">I am finished with code, I tested it in QEMU emulator raspi2but it doesn't work<div>when testing on real rpi3. I don't know if the problem is with loading the FDT</div><div>or with my code?<div>How do I send the code, so that you can take a look at it?</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 14, 2020 at 8:04 PM Niteesh <<a href="mailto:gsnb.gn@gmail.com">gsnb.gn@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Jan 14, 2020 at 1:57 PM Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>> wrote:<br></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 13/01/2020 19:04, Niteesh wrote:<br>
> The ns16550_context already has a field named baud_divisor, so if the<br>
> user passes<br>
> value for it, then we can skip the GetBaudDivisor function and use that<br>
> value instead.<br>
> <br>
> Is this approach okay?<br>
<br>
Is the driver still able to handle different baud rates with this? Does<br>
the ioctl call for setting the baudrate work?</blockquote><div>I didn't think about this, it won't work if we are using this method. ns16550_set_attributes</div><div>calls ns16550_GetBaudDivisor, then I think we will have to stick with the old method.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Best regards<br>
<br>
Christian<br>
<br>
> <br>
> On Mon, Jan 13, 2020 at 3:46 PM Niteesh <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>> wrote:<br>
> <br>
>     On Mon, Jan 13, 2020 at 1:38 PM Christian Mauderer<br>
>     <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
>     <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>>> wrote:<br>
> <br>
>         On 12/01/2020 21:26, Niteesh wrote:<br>
>         > On Sun, Jan 12, 2020 at 11:42 PM Christian Mauderer<br>
>         <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
>         > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>> wrote:<br>
>         ><br>
>         >     Hello Niteesh,<br>
>         ><br>
>         >     On 12/01/2020 16:06, Niteesh wrote:<br>
>         >     > The only issue, I faced while using this driver is the<br>
>         baud divisor is<br>
>         >     > calculated <br>
>         >     > by CLOCK_FREQ/(BAUD_RATE * 16) (*ns16550-context.c:68)*<br>
>         >     > but it should BAUD_DIV = (CLOCK_FREQ/(8 * BAUD_RATE)) -<br>
>         1, for Rpi3.<br>
>         >     > For testing, I assigned the baud divisor to 270 (115200<br>
>         bits/s) in<br>
>         >     > ns16550-context.c,<br>
>         >     > and everything works fine.<br>
>         ><br>
>         >     Sounds great. In NS16550_GetBaudDivisor there is already a<br>
>         case where<br>
>         >     the baudDivisor is calculated differently (depending on<br>
>         >     ctx->has_precision_clock_synthesizer and<br>
>         >     ctx->has_fractional_divider_register). If none of the two<br>
>         cases are ok<br>
>         >     for the controller you could just add another one.<br>
>         ><br>
>         > Can we pass in a function, which gets called, won't this be more<br>
>         > flexible? because<br>
>         > in the future if we have some other board that has a different<br>
>         > calculation for the baud rate<br>
>         > the function will take care of it.<br>
> <br>
>         It's possible. Please make sure to be compatible with the<br>
>         current API.<br>
>         For example if the pointer is NULL you should call the legacy<br>
>         function<br>
>         instead.<br>
> <br>
>      <br>
>     I will be adding an extra field, a function pointer to ns16550_context,<br>
>     the prototype of the function would be *uint32_t<br>
>     calculate_baud_divisor( ns16550_context * )*<br>
>     This is will calculate the baud divisor using its own formula and<br>
>     the initial baud.<br>
>     If this function is not NULL then it would be called inside<br>
>     *NS16550_GetBaudDivisor* function,<br>
>     *<br>
>     *<br>
> <br>
>         ><br>
>         >     ><br>
>         >     > For console selection, my plan is to search for the aux<br>
>         node using<br>
>         >     > compatible<br>
>         >     > property and if its status is enabled, then initialize<br>
>         the AUX<br>
>         >     uart and<br>
>         >     > set the BSP_output_char<br>
>         >     > to aux_output_char, else pl011_output_char. All this<br>
>         will be done<br>
>         >     inside<br>
>         >     > the uart_probe function,<br>
>         >     > except for the initialization of AUX which will be done in<br>
>         >     init_ctx_aux.<br>
>         >     > And finally, call the output char<br>
>         >     > function using *BSP_output_char. Do you have any neat<br>
>         way to do this?<br>
>         ><br>
>         >     I don't have an example for a similar case at hand. So:<br>
>         No, no neat way<br>
>         >     that I can tell you.<br>
>         ><br>
>         >     Before you start to write code: Please take a look at the<br>
>         different<br>
>         >     beagle variants what is possible. Is there a variant where<br>
>         AUX uart<br>
>         >     would be there but shouldn't be used as a console (one of<br>
>         the Zeros<br>
>         >     maybe or the compute module?). How does Raspbian or<br>
>         FreeBSD decide which<br>
>         >     port should be used? Maybe they decide based on the<br>
>         commandline.txt? In<br>
>         >     such a case it would be better to just initialize all<br>
>         active (in the<br>
>         >     fdt) serial ports and decide based on the commandline too.<br>
>         ><br>
>         >  <br>
>         > The Documentation says the following: <br>
>         > *By default, on Raspberry Pis equipped with the<br>
>         wireless/Bluetooth*<br>
>         > *module (Raspberry Pi 3 and Raspberry Pi Zero W), **the PL011<br>
>         UART is*<br>
>         > *connected to the Bluetooth module, while the mini UART is<br>
>         used as the<br>
>         > primary UART and*<br>
>         > *will have a Linux console on it. On all other models, the<br>
>         PL011 is used<br>
>         > as the primary UART.<br>
>         ><br>
>         > *<br>
>         > *In Linux device terms, by default, /dev/ttyS0 refers to the<br>
>         mini UART,<br>
>         > and /dev/ttyAMA0 refers*<br>
>         > *to the PL011. The primary UART is the one assigned to the Linux<br>
>         > console, which depends on*<br>
>         > *the Raspberry Pi model as described above. There are also<br>
>         symlinks:<br>
>         > /dev/serial0, which always*<br>
>         > *refers to the primary UART (if enabled), and /dev/serial1, which<br>
>         > similarly always refers to the secondary UART (if enabled).*<br>
>         > *<br>
>         > *<br>
>         > I checked in all the DTB files, by decompiling them (files are<br>
>         > from <a href="https://github.com/raspberrypi/firmware/tree/master/boot" rel="noreferrer" target="_blank">https://github.com/raspberrypi/firmware/tree/master/boot</a>).<br>
>         > In all board with support for wireless and bluetooth, the AuX<br>
>         is enabled<br>
>         > and serial0 points to it. So we could use serial0<br>
>         > to find the correct UART port. I think this is solid enough.<br>
>         So, should<br>
>         > I use this approach?<br>
> <br>
>         Sounds OK. If possible please initialize the other UART too if it is<br>
>         enabled in the FDT. Although we don't support bluetooth yet<br>
>         maybe there<br>
>         will be support in the future or someone wants to do it in the<br>
>         application.<br>
> <br>
>     I will go with this method then. <br>
> <br>
>         ><br>
>         > Or if using the command line, then we need to move the link to<br>
>         > CONSOLE_DEVICE to console_initialize, and parse the<br>
>         > command line twice. If this is no problem, then we could use this<br>
>         > approach also.<br>
> <br>
>         Would be possible too.<br>
> <br>
>         ><br>
>         >     ><br>
>         >     > And why don't we have a function similar<br>
>         to *of_device_is_available*,<br>
>         >     > since there will be more and more<br>
>         >     > FDT based boards, this will be really helpful.<br>
>         ><br>
>         >     I agree that it would be helpful. Seems that you just<br>
>         found a function<br>
>         >     that should be in a FDT framework.<br>
>         ><br>
>         >     RTEMS currently only has the basic libfdt functions and<br>
>         some RTEMS<br>
>         >     specific ones. The of_... functions belong to the FreeBSD<br>
>         "Open Firmware<br>
>         >     Bus" which is an abstraction layer on top of FDT. It would<br>
>         be great to<br>
>         >     identify useful ones and port them or provide an RTEMS<br>
>         implementation.<br>
>         >     Like already discussed this could be part of a GSoC project.<br>
>         ><br>
>         >     Best regards<br>
>         ><br>
>         >     Christian<br>
>         ><br>
>         >     ><br>
>         >     > On Sun, Jan 5, 2020 at 12:57 AM Christian Mauderer<br>
>         >     <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
>         <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>><br>
>         >     > <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
>         <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>>> wrote:<br>
>         >     ><br>
>         >     >     On 04/01/2020 09:32, Niteesh wrote:<br>
>         >     >     > We could now run RTEMS on Rpi3. I tried examples<br>
>         from the<br>
>         >     samples<br>
>         >     >     > section and they run<br>
>         >     >     > fine. But still, a lot of functionality has to<br>
>         tested since it<br>
>         >     >     uses the<br>
>         >     >     > RPI2 BSP. To test these examples<br>
>         >     >     > I used a simple driver for the AUX.<br>
>         >     >     > The documentation from BCM link<br>
>         >     >     ><br>
>         >     >   <br>
>         >   <br>
>           <<a href="https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf" rel="noreferrer" target="_blank">https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf</a>> (pg<br>
>         >     >     > no 10) states that<br>
>         >     >     >  <br>
>         >     >     ><br>
>         >     >     >     *The implemented UART is not a 16650<br>
>         compatible UART However<br>
>         >     >     as far<br>
>         >     >     >     as possible the first 8 control and status<br>
>         registers are<br>
>         >     laid out<br>
>         >     >     >     like a 16550 UART.*<br>
>         >     ><br>
>         >     >     It also tells<br>
>         >     ><br>
>         >     >         "Al 16550 register bits which are not supported<br>
>         can be<br>
>         >     written but<br>
>         >     >     will be ignored and read back as 0. All control bits for<br>
>         >     simple UART<br>
>         >     >     receive/transmit operations are available."<br>
>         >     ><br>
>         >     >     So I would expect that not everything works like<br>
>         expected (for<br>
>         >     example<br>
>         >     >     setting DCD, DSR, DTR, RI - they are not there for<br>
>         the mini<br>
>         >     UART) but<br>
>         >     >     the basic stuff should work.<br>
>         >     ><br>
>         >     >     ><br>
>         >     >     ><br>
>         >     >     > My question is can we use the existing ns16550<br>
>         driver or<br>
>         >     should I<br>
>         >     >     create<br>
>         >     >     > a new one? I also checked the address of the<br>
>         registers the<br>
>         >     offsets<br>
>         >     >     don't<br>
>         >     >     > seem right to me, but someone should check and<br>
>         correct me if<br>
>         >     I am<br>
>         >     >     wrong. <br>
>         >     ><br>
>         >     >     If you compare the registers in the existing driver<br>
>         >     >     (NS16550_RECEIVE_BUFFER, ... in ns16550_p.h) and the<br>
>         one in<br>
>         >     the BCM<br>
>         >     >     datasheet the registers look very similar (at least<br>
>         from the<br>
>         >     position /<br>
>         >     >     function). I haven't done a bit by bit comparison<br>
>         yet. Please<br>
>         >     note that<br>
>         >     >     you have to do a conversion between the defines and<br>
>         register<br>
>         >     addresses.<br>
>         >     >     The define gives you a register index for a 32bit<br>
>         register. So<br>
>         >     you have<br>
>         >     >     to multiply by 4 to get an address. The driver is<br>
>         designed<br>
>         >     that you<br>
>         >     >     provide a setRegister and getRegister function that<br>
>         can do this<br>
>         >     >     conversion.<br>
>         >     ><br>
>         >     >     Where did you find differences?<br>
>         >     ><br>
>         >     >     I would suggest to just try the driver.<br>
>         >     ><br>
>         ><br>
>         ><br>
>         > _______________________________________________<br>
>         > devel mailing list<br>
>         > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
>         > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>         ><br>
> <br>
>         -- <br>
>         --------------------------------------------<br>
>         embedded brains GmbH<br>
>         Herr Christian Mauderer<br>
>         Dornierstr. 4<br>
>         D-82178 Puchheim<br>
>         Germany<br>
>         email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
>         <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>><br>
>         Phone: +49-89-18 94 741 - 18<br>
>         Fax:   +49-89-18 94 741 - 08<br>
>         PGP: Public key available on request.<br>
> <br>
>         Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des<br>
>         EHUG.<br>
> <br>
<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax:   +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div></div>
</div>
</blockquote></div>