How to handle different serial devices? In other BSPs the uart devices are the same, so they were able to put it under a single array? But here we have 2 uarts and a FB?
On Tue, Dec 24, 2019 at 8:18 PM Christian Mauderer <l...@c-mauderer.de> wrote: > On 24/12/2019 12:06, Niteesh wrote: > > 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. > > I agree that this would be a clean solution. So if you want you can do > that. But there might is a hurdle: As far as I understood you you only > have a Pi3? So you might have a hard time testing the changes. Maybe the > simulator could work. > > Another possibility could be to set the "Console_port_minor" to > something unused (for example -1). In that case you can define another > /dev/console. > > Best regards and merry Christmas (in case you celebrate) > > Christian > > > > > On Tue, Dec 24, 2019 at 2:13 PM Niteesh <gsnb...@gmail.com > > <mailto: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 <mailto: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> > > > <mailto: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> > > > <mailto: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> > > <mailto: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>> > > > > <mailto: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>> > > > <mailto: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>> > > > <mailto: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
