And also the register definitions are in raspberrpi.h file should I move them to usart.h. I have a doubt we have a register field in device_context typedef struct {
rtems_termios_device_context base; const char *device_name; volatile some_chip_registers *regs; } my_driver_context; How does the reg field point to the correct memory location? for instance in IMX BSP, there is a struct with register field's but none of the define a memory location? On Tue, Dec 24, 2019 at 11:37 PM Niteesh <gsnb...@gmail.com> wrote: > 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