Raspberrypi3: Mini UART driver

Niteesh gsnb.gn at gmail.com
Mon Dec 23 18:50:15 UTC 2019


And finally, how does printf work? It is a macro? In that case, how does
any write to
a console work?

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

> 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/fc83a007/attachment.html>


More information about the devel mailing list