<div dir="ltr"><div dir="ltr">On Sun, Jan 12, 2020 at 11:42 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de">list@c-mauderer.de</a>> wrote:<br></div><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">Hello Niteesh,<br>
<br>
On 12/01/2020 16:06, Niteesh wrote:<br>
> The only issue, I faced while using this driver is the 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)) - 1, for Rpi3.<br>
> For testing, I assigned the baud divisor to 270 (115200 bits/s) in<br>
> ns16550-context.c,<br>
> and everything works fine.<br>
<br>
Sounds great. In NS16550_GetBaudDivisor there is already a 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 cases are ok<br>
for the controller you could just add another one.<br></blockquote><div>Can we pass in a function, which gets called, won't this be more flexible? because</div><div>in the future if we have some other board that has a different calculation for the baud rate</div><div>the function will take care of it.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> For console selection, my plan is to search for the aux node using<br>
> compatible<br>
> property and if its status is enabled, then initialize the AUX uart and<br>
> set the BSP_output_char<br>
> to aux_output_char, else pl011_output_char. All this will be done inside<br>
> the uart_probe function,<br>
> except for the initialization of AUX which will be done in init_ctx_aux.<br>
> And finally, call the output char<br>
> function using *BSP_output_char. Do you have any neat way to do this?<br>
<br>
I don't have an example for a similar case at hand. So: No, no neat way<br>
that I can tell you.<br>
<br>
Before you start to write code: Please take a look at the different<br>
beagle variants what is possible. Is there a variant where AUX uart<br>
would be there but shouldn't be used as a console (one of the Zeros<br>
maybe or the compute module?). How does Raspbian or FreeBSD decide which<br>
port should be used? Maybe they decide based on the commandline.txt? In<br>
such a case it would be better to just initialize all active (in the<br>
fdt) serial ports and decide based on the commandline too.<br></blockquote><div> </div><div>The Documentation says the following: </div><b>By default, on Raspberry Pis equipped with the wireless/Bluetooth</b></div><div class="gmail_quote"><b>module (Raspberry Pi 3 and Raspberry Pi Zero W), </b><b>the PL011 UART is</b></div><div class="gmail_quote"><b>connected to the Bluetooth module, while the mini UART is used as the primary UART and</b></div><div class="gmail_quote"><b>will have a Linux console on it. On all other models, the PL011 is used as the primary UART.<br><br></b><div><b>In Linux device terms, by default, /dev/ttyS0 refers to the mini UART, and /dev/ttyAMA0 refers</b></div><div><b>to the PL011. The primary UART is the one assigned to the Linux console, which depends on</b></div><div><b>the Raspberry Pi model as described above. There are also symlinks: /dev/serial0, which always</b></div><div><b>refers to the primary UART (if enabled), and /dev/serial1, which similarly always refers to the secondary UART (if enabled).</b></div><div><b><br></b></div><div>I checked in all the DTB files, by decompiling them (files are from <a href="https://github.com/raspberrypi/firmware/tree/master/boot">https://github.com/raspberrypi/firmware/tree/master/boot</a>).<br></div><div>In all board with support for wireless and bluetooth, the AuX is enabled and serial0 points to it. So we could use serial0</div><div>to find the correct UART port. I think this is solid enough. So, should I use this approach?</div><div><br></div><div>Or if using the command line, then we need to move the link to CONSOLE_DEVICE to console_initialize, and parse the</div><div>command line twice. If this is no problem, then we could use this approach also.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> And why don't we have a function similar 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 found a function<br>
that should be in a FDT framework.<br>
<br>
RTEMS currently only has the basic libfdt functions and some RTEMS<br>
specific ones. The of_... functions belong to the FreeBSD "Open Firmware<br>
Bus" which is an abstraction layer on top of FDT. It would be great to<br>
identify useful ones and port them or provide an RTEMS 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 <<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>>> wrote:<br>
> <br>
>     On 04/01/2020 09:32, Niteesh wrote:<br>
>     > We could now run RTEMS on Rpi3. I tried examples from the samples<br>
>     > section and they run<br>
>     > fine. But still, a lot of functionality has to 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>
>     <<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 compatible UART However<br>
>     as far<br>
>     >     as possible the first 8 control and status registers are laid out<br>
>     >     like a 16550 UART.*<br>
> <br>
>     It also tells<br>
> <br>
>         "Al 16550 register bits which are not supported can be written but<br>
>     will be ignored and read back as 0. All control bits for simple UART<br>
>     receive/transmit operations are available."<br>
> <br>
>     So I would expect that not everything works like expected (for example<br>
>     setting DCD, DSR, DTR, RI - they are not there for the mini UART) but<br>
>     the basic stuff should work.<br>
> <br>
>     ><br>
>     ><br>
>     > My question is can we use the existing ns16550 driver or should I<br>
>     create<br>
>     > a new one? I also checked the address of the registers the offsets<br>
>     don't<br>
>     > seem right to me, but someone should check and correct me if 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 one in the BCM<br>
>     datasheet the registers look very similar (at least from the position /<br>
>     function). I haven't done a bit by bit comparison yet. Please note that<br>
>     you have to do a conversion between the defines and register addresses.<br>
>     The define gives you a register index for a 32bit register. So you have<br>
>     to multiply by 4 to get an address. The driver is designed that you<br>
>     provide a setRegister and getRegister function that can do this<br>
>     conversion.<br>
> <br>
>     Where did you find differences?<br>
> <br>
>     I would suggest to just try the driver.<br>
> <br>
</blockquote></div></div>