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