<div dir="ltr"><div dir="ltr">On Sun, Dec 22, 2019 at 8:44 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank">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>
thanks for doing that work.<br>
<br>
On 22/12/2019 12:10, Niteesh wrote:<br>
> The rpi1 and rpi2 use the PL011 UART, whereas, with RPI's equipped with<br>
> wireless/Bluetooth module, the PL011 is connected to the Bluetooth<br>
> module, and the mini UART is used as the primary UART.<br>
<br>
In my opinion it would be great if you could use the FDT to distinguish<br>
between the boards. That should allow to add raspberry 3 (and maybe 4)<br>
support without adding another BSP. More BSPs mean a bigger maintenance<br>
effort for the RTEMS community.</blockquote><div>Learning more about FDT is on my list for a long time.  I would love to work on that</div><div>but I have almost no exp with FDT's.</div><div>But another thing could also be done, in raspberrypi/start/bspstart.c we get the revision and</div><div>model of the board using the mailbox. Every board has a unique id, which we could use to initialize</div><div>the BSP. But using FDT seems to be a more elegant option, it is a lot of work I think, but we could take</div><div>help from libbsd and linux I suppose. What do you think?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <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><br>
> But from the above doc (PAGE 10), the mini uart has 16550 like registers<br>
> and RTEMS already has the driver for it<br>
> bsps/shared/dev/serial/ns16550.c. But I am not sure how compatible they<br>
> are? Should a new driver be implemented from scratch or use ns16550 if<br>
> possible?<br>
<br>
In general it's better to re-use existing code. That has multiple<br>
advantages:<br>
<br>
- It reduces the maintenance effort. Fewer code means fewer work.<br>
- If you have multiple driver for the same or similar hardware it can<br>
happen that a bug is fixed in one but not the other.<br>
- It's simpler to find a hardware to test changes.<br>
- The driver becomes more universal with every new supported hardware.<br>
That increases the chance that it fits the next new hardware.<br>
<br>
I'm sure there are some more if you ask someone else.</blockquote><div>I do understand the issues, I just spent some time reading the driver code.</div><div>I think we could most probably use it. I will take a closer look and will update.</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">
> <br>
> Also, the core clock on which the PL011 is based on is changed in rpi3.<br>
> Rpi1 and 2 use 250Mhz as the default clock but it was changed to 400Mhz<br>
> in Rpi3 and newer<br>
<br>
Again: Would be great if that could be adapted based on FDT or by<br>
reading the right registers.<br>
<br>
> <br>
> Few differences between PL011 and Mini uart<br>
> The mini UART has smaller FIFOs. Combined with the lack of flow control,<br>
> this makes it more prone to losing characters at higher baud rates. It<br>
> is also generally less capable than the PL011, mainly due to its baud<br>
> rate link to the VPU clock speed.<br>
<br>
That shouldn't really be a problem for the system console.<br>
<br>
> <br>
> The particular deficiencies of the mini UART compared to the PL011 are :<br>
> <br>
> No break detection<br>
> No framing errors detection<br>
> No parity bit<br>
> No receive timeout interrupt<br>
> No DCD, DSR, DTR or RI signals<br>
><br>
</blockquote></div></div>