<div dir="ltr">I would like to clarify my doubts regarding the console driver. I went through the documentation<div>for the console driver <a href="https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction" target="_blank">https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction</a>.</div><div>But it is quite different from how some BSPs initialize.</div><div>Correct me if I am wrong</div><div>The console_tbl contains the various entries of serial ports.</div><div>The console_fns is a struct of function pointers, which point to the BSP uart functions.</div><div>The BSP_output_char_function_type is what will be called for printing a char on to the console.</div><div>How does RTEMS initialize the uart? It's seems not to be same for all BSPs.</div><div>The doc says that the driver's initialization function is called once during the rtems initialization process.</div><div>The console init function install the serial driver using rtems_termios_device_install but there seems to be</div><div>no such function in the raspberry pi? But there is a entry in console_fns for init function, but then how does it</div><div>gets called?</div><div>And for BSP's with multiple serial's, the output function chooses the right serial using console_port_minor,</div><div>Is it during initialization?</div><div>What is the need for get and set register functions? </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 23, 2019 at 1:04 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">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>>> 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>>> 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, with RPI's<br>
> equipped with<br>
> > wireless/Bluetooth module, the PL011 is connected to the Bluetooth<br>
> > module, and the mini UART is used as the primary UART.<br>
> <br>
> In my opinion it would be great if you could use the FDT to<br>
> distinguish<br>
> between the boards. That should allow to add raspberry 3 (and<br>
> maybe 4)<br>
> support without adding another BSP. More BSPs mean a bigger<br>
> maintenance<br>
> effort for the RTEMS community.<br>
> <br>
> Learning more about FDT is on my list for a long 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 a unique id,<br>
> which we could use to initialize<br>
> the BSP. But using FDT seems to be a more elegant 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 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 memory size,<br>
> you can get a working BSP that dynamically adapts to the models and<br>
> memory variations with minimal modifications. If you want to then<br>
> convert the BSP to FDT, it will be a LOT easier to debug with a working BSP.<br>
> <br>
> Plus you may be able to identify every variation point based on just the<br>
> model info. Then FDT is just a matter of switching the 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 known as "hack")<br>
as a first step is a good idea. You maybe even just make the mini UART<br>
the default driver while you are developing. Then you can be sure that<br>
you have the right driver.<br>
<br>
As soon as that works you can either change to the revision method or<br>
(better) to the FDT one and after that the patches can be merged. Using<br>
the FDT isn't that complicated. Basically you search for a node based on<br>
different parameters. For an example you can take a look at the imx BSP.<br>
In imx_uart_probe (bsps/arm/imx/console/console-config.c) a fdt node is<br>
searched and based on that a UART driver is used. But again: Follow<br>
Joels suggestion to start simple and secure.<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 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 sure how<br>
> compatible they<br>
> > are? Should a new driver be implemented from scratch or use<br>
> ns16550 if<br>
> > possible?<br>
> <br>
> In general it's better to re-use existing code. That has multiple<br>
> advantages:<br>
> <br>
> - It reduces the maintenance effort. Fewer code means fewer work.<br>
> - If you have multiple driver for the same or 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 supported<br>
> hardware.<br>
> That increases the chance that it fits the next 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 reading the<br>
> driver code.<br>
> I think we could most probably use it. I will take a 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 on is changed<br>
> in rpi3.<br>
> > Rpi1 and 2 use 250Mhz as the default clock but it was changed<br>
> to 400Mhz<br>
> > in Rpi3 and newer<br>
> <br>
> Again: Would be great if that could be adapted 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 the lack of<br>
> flow control,<br>
> > this makes it more prone to losing characters at higher baud<br>
> rates. It<br>
> > is also generally less capable than the PL011, 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 console.<br>
> <br>
> ><br>
> > The particular deficiencies of the mini UART 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>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <br>
</blockquote></div>