Raspberrypi3: Mini UART driver

[Joel Sherrill]

On Sun, Dec 22, 2019, 12:29 PM Niteesh <gsnb.gn at gmail.com> wrote:

> On Sun, Dec 22, 2019 at 8:44 PM Christian Mauderer <list at c-mauderer.de>
> wrote:
>
>> Hello Niteesh,
>>
>> thanks for doing that work.
>>
>> On 22/12/2019 12:10, Niteesh wrote:
>> > The rpi1 and rpi2 use the PL011 UART, whereas, with RPI's equipped with
>> > wireless/Bluetooth module, the PL011 is connected to the Bluetooth
>> > module, and the mini UART is used as the primary UART.
>>
>> In my opinion it would be great if you could use the FDT to distinguish
>> between the boards. That should allow to add raspberry 3 (and maybe 4)
>> support without adding another BSP. More BSPs mean a bigger maintenance
>> effort for the RTEMS community.
>
> Learning more about FDT is on my list for a long time.  I would love to
> work on that
> but I have almost no exp with FDT's.
> But another thing could also be done, in raspberrypi/start/bspstart.c we
> get the revision and
> model of the board using the mailbox. Every board has a unique id, which
> we could use to initialize
> the BSP. But using FDT seems to be a more elegant option, it is a lot of
> work I think, but we could take
> help from libbsd and linux I suppose. What do you think?
>

I think there are almost always two steps to a project like this: get it to
work and make it nice. :)

If you fix the startup code to read the board revision and memory size, you
can get a working BSP that dynamically adapts to the models and memory
variations with minimal modifications. If you want to then convert the BSP
to FDT, it will be a LOT easier to debug with a working BSP.

Plus you may be able to identify every variation point based on just the
model info. Then FDT is just a matter of switching the source of some/all
of the info.

That would be my work plan anyway.

>
>> >
>> https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
>> > But from the above doc (PAGE 10), the mini uart has 16550 like registers
>> > and RTEMS already has the driver for it
>> > bsps/shared/dev/serial/ns16550.c. But I am not sure how compatible they
>> > are? Should a new driver be implemented from scratch or use ns16550 if
>> > possible?
>>
>> In general it's better to re-use existing code. That has multiple
>> advantages:
>>
>> - It reduces the maintenance effort. Fewer code means fewer work.
>> - If you have multiple driver for the same or similar hardware it can
>> happen that a bug is fixed in one but not the other.
>> - It's simpler to find a hardware to test changes.
>> - The driver becomes more universal with every new supported hardware.
>> That increases the chance that it fits the next new hardware.
>>
>> I'm sure there are some more if you ask someone else.
>
> I do understand the issues, I just spent some time reading the driver code.
> I think we could most probably use it. I will take a closer look and will
> update.
>
>>
>>
> >
>> > Also, the core clock on which the PL011 is based on is changed in rpi3.
>> > Rpi1 and 2 use 250Mhz as the default clock but it was changed to 400Mhz
>> > in Rpi3 and newer
>>
>> Again: Would be great if that could be adapted based on FDT or by
>> reading the right registers.
>>
>> >
>> > Few differences between PL011 and Mini uart
>> > The mini UART has smaller FIFOs. Combined with the lack of flow control,
>> > this makes it more prone to losing characters at higher baud rates. It
>> > is also generally less capable than the PL011, mainly due to its baud
>> > rate link to the VPU clock speed.
>>
>> That shouldn't really be a problem for the system console.
>>
>> >
>> > The particular deficiencies of the mini UART compared to the PL011 are :
>> >
>> > No break detection
>> > No framing errors detection
>> > No parity bit
>> > No receive timeout interrupt
>> > No DCD, DSR, DTR or RI signals
>> >
>>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191222/d2b7eb91/attachment-0001.html>