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> 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> > 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>> wrote: >> > >> > On Sun, Dec 22, 2019 at 8:44 PM Christian Mauderer >> > <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> >> > http://lists.rtems.org/mailman/listinfo/devel >> > >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
