The current raspi console section is like this: The bsp_console_select in console_select.c is responsible for selecting between uart and the framebuffer. It does so by setting the Console_port_minor. The console_config is responsible for output_char function. And other files are driver code. If rewriting, this would be my approach, Rewrite the bsp_console_select to set some kind of a variable like in IMX, then in console_initialize function link the right driver to /dev/console. Replace the console_tbl with the device_context and console_fns with termios_device_handlers and finally add in the console_initialization function.
On Tue, Dec 24, 2019 at 2:13 PM Niteesh <gsnb...@gmail.com> wrote: > Thank you so much, for such a detailed answer. Now things make really good > sense to me, > going through the code now is just a breeze. But I still have one question > for the newer driver interface is console_initialize the function which > RTEMS calls while initializing > the console? Which means I can't mess with the name right? It is similar > to the main function, right? > > The current driver is a legacy one, how do you want me to proceed, shall I > rewrite the legacy to a > 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. > > > On Tue, Dec 24, 2019 at 3:20 AM Christian Mauderer <l...@c-mauderer.de> > wrote: > >> 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
