<div dir="ltr"><div>The current raspi console section is like this:</div><div>The bsp_console_select in console_select.c is responsible for selecting between uart and the framebuffer. It does so</div><div>by setting the Console_port_minor.</div><div>The console_config is responsible for output_char function.<br></div><div>And other files are driver code.</div><div>If rewriting, this would be my approach,<div></div></div><div>Rewrite the bsp_console_select to set some kind of a variable like in IMX, then in console_initialize function</div><div>link the right driver to /dev/console.</div><div>Replace the console_tbl with the device_context and console_fns with termios_device_handlers and</div><div>finally add in the console_initialization function.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 24, 2019 at 2:13 PM Niteesh <<a href="mailto:gsnb.gn@gmail.com">gsnb.gn@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thank you so much, for such a detailed answer. Now things make really good sense to me, <div>going through the code now is just a breeze. But I still have one question<div>for the newer driver interface is console_initialize the function which RTEMS calls while initializing</div><div>the console? Which means I can't mess with the name right? It is similar to the main function, right?</div><div><br></div><div>The current driver is a legacy one, how do you want me to proceed, shall I rewrite the legacy to a</div><div>the new one, this is will be a great learning experience for me also and we also get the BSP updated to the latest interface.</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 24, 2019 at 3:20 AM Christian Mauderer <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>> wrote:<br></div><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>
quite a lot of questions. I'll try to answer them. Note that it has been<br>
some time since I had a detailed look at that code so if something I<br>
tell seems odd please don't hesitate to question it.<br>
<br>
Please note that in RTEMS their are more or less two "levels" of support<br>
for a serial console:<br>
<br>
1. A very basic polled system console (also known as "debug-console" in<br>
some BSPs). This one is used for printk and should work in basically<br>
every case. It is used for critical system messages like printing the<br>
exception frame. For that a BSP has to provide a "BSP_output_char" function.<br>
<br>
2. A full featured UART driver integrated into Termios. That one will be<br>
used for all normal I/O on the UARTs.<br>
<br>
As far as I know the "console_tbl Console_Configuration_Ports" belongs<br>
to a table based legacy interface. It is handled in the file<br>
bsps/shared/dev/serial/legacy-console.c. I'm not sure whether it is<br>
documented in the BSP guide because it shouldn't be used for new BSPs.<br>
Same is true for the "major" and "minor" stuff: It's not really used for<br>
new drivers.<br>
<br>
Newer drivers use the initialization that is described in the manual<br>
that you have already found. Basically they use<br>
"rtems_termios_device_install" to register a new UART as<br>
"/dev/ttySomething". Some recent (ARM) BSPs that do that are the imx or<br>
the atsam.<br>
<br>
The console that is used for stdin, stdout and stderr (printf, scanf,<br>
...) is the one called "/dev/console" (defined in CONSOLE_DEVICE_NAME).<br>
For the legacy table based interface it's the one with the index of<br>
"Console_Port_Minor".<br>
<br>
<br>
If you want to access any UART other than the one for stdin and stdout<br>
you do that the same way like on Linux: Just use the "open" function on<br>
the "/dev/ttySomething" and use "read", "write" and simmilar or use<br>
"fopen" together with "fread", "fwrite", "fprintf", ...<br>
<br>
<br>
"printf" (and family) is a function belonging to the C library. In our<br>
case that's newlib. It will format your message and after some other<br>
preprocessing will call the "write" function of the file that is opened<br>
as stdout (which is "/dev/console" in the default case).<br>
<br>
<br>
I hope that I helped you with that explanation. Please feel free to ask<br>
anything if it isn't clear.<br>
<br>
Best regards<br>
<br>
Christian<br>
<br>
On 23/12/2019 19:50, Niteesh wrote:<br>
> And finally, how does printf work? It is a macro? In that case, how does<br>
> any write to<br>
> a console work?<br>
> <br>
> On Tue, Dec 24, 2019 at 12:18 AM Niteesh <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>> wrote:<br>
> <br>
>     Is the correct port minor number set during the initialization? What<br>
>     is the application want's to<br>
>     access some other port?<br>
> <br>
>     On Tue, Dec 24, 2019 at 12:16 AM Niteesh <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>> wrote:<br>
> <br>
>         I would like to clarify my doubts regarding the console driver.<br>
>         I went through the documentation<br>
>         for the console<br>
>         driver <a href="https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction</a>.<br>
>         But it is quite different from how some BSPs initialize.<br>
>         Correct me if I am wrong<br>
>         The console_tbl contains the various entries of serial ports.<br>
>         The console_fns is a struct of function pointers, which point to<br>
>         the BSP uart functions.<br>
>         The BSP_output_char_function_type is what will be called for<br>
>         printing a char on to the console.<br>
>         How does RTEMS initialize the uart? It's seems not to be same<br>
>         for all BSPs.<br>
>         The doc says that the driver's initialization function is called<br>
>         once during the rtems initialization process.<br>
>         The console init function install the serial driver using<br>
>         rtems_termios_device_install but there seems to be<br>
>         no such function in the raspberry pi? But there is a entry in<br>
>         console_fns for init function, but then how does it<br>
>         gets called?<br>
>         And for BSP's with multiple serial's, the output function<br>
>         chooses the right serial using console_port_minor,<br>
>         Is it during initialization?<br>
>         What is the need for get and set register functions? <br>
> <br>
>         On Mon, Dec 23, 2019 at 1:04 AM Christian Mauderer<br>
>         <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>> wrote:<br>
> <br>
>             On 22/12/2019 19:45, Joel Sherrill wrote:<br>
>             ><br>
>             ><br>
>             > On Sun, Dec 22, 2019, 12:29 PM Niteesh <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>             <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>><br>
>             > <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>>> wrote:<br>
>             ><br>
>             >     On Sun, Dec 22, 2019 at 8:44 PM Christian Mauderer<br>
>             >     <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
>             <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>> wrote:<br>
>             ><br>
>             >         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,<br>
>             with RPI's<br>
>             >         equipped with<br>
>             >         > wireless/Bluetooth module, the PL011 is<br>
>             connected to the Bluetooth<br>
>             >         > module, and the mini UART is used as the primary<br>
>             UART.<br>
>             ><br>
>             >         In my opinion it would be great if you could use<br>
>             the FDT to<br>
>             >         distinguish<br>
>             >         between the boards. That should allow to add<br>
>             raspberry 3 (and<br>
>             >         maybe 4)<br>
>             >         support without adding another BSP. More BSPs mean<br>
>             a bigger<br>
>             >         maintenance<br>
>             >         effort for the RTEMS community.<br>
>             ><br>
>             >     Learning more about FDT is on my list for a long<br>
>             time.  I would love<br>
>             >     to work on that<br>
>             >     but I have almost no exp with FDT's.<br>
>             >     But another thing could also be done, in<br>
>             >     raspberrypi/start/bspstart.c we get the revision and<br>
>             >     model of the board using the mailbox. Every board has<br>
>             a unique id,<br>
>             >     which we could use to initialize<br>
>             >     the BSP. But using FDT seems to be a more elegant<br>
>             option, it is a<br>
>             >     lot of work I think, but we could take<br>
>             >     help from libbsd and linux I suppose. What do you think?<br>
>             ><br>
>             ><br>
>             > I think there are almost always two steps to a project<br>
>             like this: get it<br>
>             > to work and make it nice. :)<br>
>             ><br>
>             > If you fix the startup code to read the board revision and<br>
>             memory size,<br>
>             > you can get a working BSP that dynamically adapts to the<br>
>             models and<br>
>             > memory variations with minimal modifications. If you want<br>
>             to then<br>
>             > convert the BSP to FDT, it will be a LOT easier to debug<br>
>             with a working BSP.<br>
>             ><br>
>             > Plus you may be able to identify every variation point<br>
>             based on just the<br>
>             > model info. Then FDT is just a matter of switching the<br>
>             source of<br>
>             > some/all of the info.<br>
>             ><br>
>             > That would be my work plan anyway.<br>
> <br>
>             I agree with Joel that a secure development basis (also<br>
>             known as "hack")<br>
>             as a first step is a good idea. You maybe even just make the<br>
>             mini UART<br>
>             the default driver while you are developing. Then you can be<br>
>             sure that<br>
>             you have the right driver.<br>
> <br>
>             As soon as that works you can either change to the revision<br>
>             method or<br>
>             (better) to the FDT one and after that the patches can be<br>
>             merged. Using<br>
>             the FDT isn't that complicated. Basically you search for a<br>
>             node based on<br>
>             different parameters. For an example you can take a look at<br>
>             the imx BSP.<br>
>             In imx_uart_probe (bsps/arm/imx/console/console-config.c) a<br>
>             fdt node is<br>
>             searched and based on that a UART driver is used. But again:<br>
>             Follow<br>
>             Joels suggestion to start simple and secure.<br>
> <br>
>             ><br>
>             >         ><br>
>             >         ><br>
>             >       <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<br>
>             has 16550 like<br>
>             >         registers<br>
>             >         > and RTEMS already has the driver for it<br>
>             >         > bsps/shared/dev/serial/ns16550.c. But I am not<br>
>             sure how<br>
>             >         compatible they<br>
>             >         > are? Should a new driver be implemented from<br>
>             scratch or use<br>
>             >         ns16550 if<br>
>             >         > possible?<br>
>             ><br>
>             >         In general it's better to re-use existing code.<br>
>             That has multiple<br>
>             >         advantages:<br>
>             ><br>
>             >         - It reduces the maintenance effort. Fewer code<br>
>             means fewer work.<br>
>             >         - If you have multiple driver for the same or<br>
>             similar hardware<br>
>             >         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<br>
>             supported<br>
>             >         hardware.<br>
>             >         That increases the chance that it fits the next<br>
>             new hardware.<br>
>             ><br>
>             >         I'm sure there are some more if you ask someone else.<br>
>             ><br>
>             >     I do understand the issues, I just spent some time<br>
>             reading the<br>
>             >     driver code.<br>
>             >     I think we could most probably use it. I will take a<br>
>             closer look and<br>
>             >     will update.<br>
>             ><br>
> <br>
>             Great.<br>
> <br>
>             >          <br>
>             ><br>
>             >         ><br>
>             >         > Also, the core clock on which the PL011 is based<br>
>             on is changed<br>
>             >         in rpi3.<br>
>             >         > Rpi1 and 2 use 250Mhz as the default clock but<br>
>             it was changed<br>
>             >         to 400Mhz<br>
>             >         > in Rpi3 and newer<br>
>             ><br>
>             >         Again: Would be great if that could be adapted<br>
>             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<br>
>             the lack of<br>
>             >         flow control,<br>
>             >         > this makes it more prone to losing characters at<br>
>             higher baud<br>
>             >         rates. It<br>
>             >         > is also generally less capable than the PL011,<br>
>             mainly due to<br>
>             >         its baud<br>
>             >         > rate link to the VPU clock speed.<br>
>             ><br>
>             >         That shouldn't really be a problem for the system<br>
>             console.<br>
>             ><br>
>             >         ><br>
>             >         > The particular deficiencies of the mini UART<br>
>             compared to the<br>
>             >         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>
>             ><br>
>             >     _______________________________________________<br>
>             >     devel mailing list<br>
>             >     <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
>             <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>>><br>
>             >     <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>             ><br>
> <br>
</blockquote></div>
</blockquote></div>