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> 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> 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
