<div dir="ltr"><div>The only issue, I faced while using this driver is the baud divisor is calculated </div><div>by CLOCK_FREQ/(BAUD_RATE * 16) (<b>ns16550-context.c:68)</b></div><div>but it should BAUD_DIV = (CLOCK_FREQ/(8 * BAUD_RATE)) - 1, for Rpi3.</div><div>For testing, I assigned the baud divisor to 270 (115200 bits/s) in ns16550-context.c,</div><div>and everything works fine.</div><div><br></div>For console selection, my plan is to search for the aux node using compatible<div>property and if its status is enabled, then initialize the AUX uart and set the BSP_output_char</div><div>to aux_output_char, else pl011_output_char. All this will be done inside the uart_probe function,</div><div>except for the initialization of AUX which will be done in init_ctx_aux. And finally, call the output char</div><div>function using *BSP_output_char. Do you have any neat way to do this?</div><div><br></div><div>And why don't we have a function similar to <b>of_device_is_available</b>, since there will be more and more</div><div>FDT based boards, this will be really helpful.</div><div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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>> 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">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 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>
> <<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 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 create<br>
> a new one? I also checked the address of the registers the offsets don't<br>
> seem right to me, but someone should check and correct me if I am 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 conversion.<br>
<br>
Where did you find differences?<br>
<br>
I would suggest to just try the driver.<br>
</blockquote></div>
</div></div></div>