Raspberrypi3: Mini UART driver

Mon Dec 23 18:48:54 UTC 2019

Is the correct port minor number set during the initialization? What is the
application want's to
access some other port?

On Tue, Dec 24, 2019 at 12:16 AM Niteesh <gsnb.gn at gmail.com> wrote:

> I would like to clarify my doubts regarding the console driver. I went
> through the documentation
> for the console driver
> https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction
> .
> But it is quite different from how some BSPs initialize.
> Correct me if I am wrong
> The console_tbl contains the various entries of serial ports.
> The console_fns is a struct of function pointers, which point to the BSP
> uart functions.
> The BSP_output_char_function_type is what will be called for printing a
> char on to the console.
> How does RTEMS initialize the uart? It's seems not to be same for all BSPs.
> The doc says that the driver's initialization function is called once
> during the rtems initialization process.
> The console init function install the serial driver using
> rtems_termios_device_install but there seems to be
> no such function in the raspberry pi? But there is a entry in console_fns
> for init function, but then how does it
> gets called?
> And for BSP's with multiple serial's, the output function chooses the
> right serial using console_port_minor,
> Is it during initialization?
> What is the need for get and set register functions?
>
> On Mon, Dec 23, 2019 at 1:04 AM Christian Mauderer <list at c-mauderer.de>
> wrote:
>
>> On 22/12/2019 19:45, Joel Sherrill wrote:
>> >
>> >
>> > On Sun, Dec 22, 2019, 12:29 PM Niteesh <gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>> wrote:
>> >
>> >     On Sun, Dec 22, 2019 at 8:44 PM Christian Mauderer
>> >     <list at c-mauderer.de <mailto: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.
>>
>> I agree with Joel that a secure development basis (also known as "hack")
>> as a first step is a good idea. You maybe even just make the mini UART
>> the default driver while you are developing. Then you can be sure that
>> you have the right driver.
>>
>> As soon as that works you can either change to the revision method or
>> (better) to the FDT one and after that the patches can be merged. Using
>> the FDT isn't that complicated. Basically you search for a node based on
>> different parameters. For an example you can take a look at the imx BSP.
>> In imx_uart_probe (bsps/arm/imx/console/console-config.c) a fdt node is
>> searched and based on that a UART driver is used. But again: Follow
>> Joels suggestion to start simple and secure.
>>
>> >
>> >         >
>> >         >
>> >
>> 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.
>> >
>>
>> Great.
>>
>> >
>> >
>> >         >
>> >         > 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 <mailto: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/20191224/51abcc6e/attachment-0001.html>