Hello Niteesh, quite a lot of questions. I'll try to answer them. Note that it has been some time since I had a detailed look at that code so if something I tell seems odd please don't hesitate to question it.
Please note that in RTEMS their are more or less two "levels" of support for a serial console: 1. A very basic polled system console (also known as "debug-console" in some BSPs). This one is used for printk and should work in basically every case. It is used for critical system messages like printing the exception frame. For that a BSP has to provide a "BSP_output_char" function. 2. A full featured UART driver integrated into Termios. That one will be used for all normal I/O on the UARTs. As far as I know the "console_tbl Console_Configuration_Ports" belongs to a table based legacy interface. It is handled in the file bsps/shared/dev/serial/legacy-console.c. I'm not sure whether it is documented in the BSP guide because it shouldn't be used for new BSPs. Same is true for the "major" and "minor" stuff: It's not really used for new drivers. Newer drivers use the initialization that is described in the manual that you have already found. Basically they use "rtems_termios_device_install" to register a new UART as "/dev/ttySomething". Some recent (ARM) BSPs that do that are the imx or the atsam. The console that is used for stdin, stdout and stderr (printf, scanf, ...) is the one called "/dev/console" (defined in CONSOLE_DEVICE_NAME). For the legacy table based interface it's the one with the index of "Console_Port_Minor". If you want to access any UART other than the one for stdin and stdout you do that the same way like on Linux: Just use the "open" function on the "/dev/ttySomething" and use "read", "write" and simmilar or use "fopen" together with "fread", "fwrite", "fprintf", ... "printf" (and family) is a function belonging to the C library. In our case that's newlib. It will format your message and after some other preprocessing will call the "write" function of the file that is opened as stdout (which is "/dev/console" in the default case). I hope that I helped you with that explanation. Please feel free to ask anything if it isn't clear. Best regards Christian On 23/12/2019 19:50, Niteesh wrote: > 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...@gmail.com > <mailto:gsnb...@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...@gmail.com > <mailto:gsnb...@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 > <l...@c-mauderer.de <mailto:l...@c-mauderer.de>> wrote: > > On 22/12/2019 19:45, Joel Sherrill wrote: > > > > > > On Sun, Dec 22, 2019, 12:29 PM Niteesh <gsnb...@gmail.com > <mailto:gsnb...@gmail.com> > > <mailto:gsnb...@gmail.com <mailto:gsnb...@gmail.com>>> wrote: > > > > On Sun, Dec 22, 2019 at 8:44 PM Christian Mauderer > > <l...@c-mauderer.de <mailto:l...@c-mauderer.de> > <mailto:l...@c-mauderer.de <mailto:l...@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@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > http://lists.rtems.org/mailman/listinfo/devel > > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
