On Tue, Dec 24, 2019, 12:19 PM Niteesh <gsnb...@gmail.com> wrote:
> And also the register definitions are in raspberrpi.h file should I move
> them to usart.h.
>
Sounds right if you mean bsp/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?
>
Make sure the structure has volatiles and proper alignment. :)
>
> 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
