Raspberrypi3: Mini UART driver
Niteesh
gsnb.gn at gmail.com
Fri Dec 27 08:35:26 UTC 2019
Does the device's initialization happen in the first_open function for the
new interface? Because the old legacy driver
call's the initialization function directly.
On Fri, Dec 27, 2019 at 2:00 PM Niteesh <gsnb.gn at gmail.com> wrote:
> On Fri, Dec 27, 2019 at 1:59 AM Christian Mauderer <list at c-mauderer.de>
> wrote:
>
>> On 25/12/2019 15:32, Niteesh wrote:
>> > What about the framebuffer it still uses minor and major's?
>>
>> I'm not entirely sure but I don't think that it is a problem to mix
>> legacy and new style drivers.
>
> I want to create rtems_termios_device_handler for the framebuffer, the
> current driver uses console_fns and
> the functions have the old signatures, which uses major and minor numbers,
> but the device handler uses the newer interface
>
> static bool my_driver_first_open(
>
> rtems_termios_tty *tty,
> rtems_termios_device_context *base,
> struct termios *term,
> rtems_libio_open_close_args_t *args)
>
> as mentioned in the doc will it cause any trouble? If it does then will
> also have to rewrite the fb right?
>
>>
>>
> >
>> > On Wed, Dec 25, 2019 at 3:20 PM Niteesh <gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>> wrote:
>> >
>> > Just to make sure I am going in the right track.
>> > I moved the uart register definitions to bsp/usart.h into a struct
>> > of uint32_t called usart0_regs
>> > here is git diff of usart.c after changing it to the latest console
>> > interface.
>> >
>> > diff --git a/bsps/arm/raspberrypi/console/usart.c
>> > b/bsps/arm/raspberrypi/console/usart.c
>> > index 25fb523621..b12f375a1c 100644
>> > --- a/bsps/arm/raspberrypi/console/usart.c
>> > +++ b/bsps/arm/raspberrypi/console/usart.c
>> > @@ -47,6 +47,12 @@ static uint32_t usart_get_baud(const console_tbl
>> *ct)
>> > }
>> > #endif
>> >
>> > +typedef struct {
>> > + rtems_termios_device_context base;
>> > + const char *device_name;
>> > + volatile usart0_regs *regs;
>> > +}uart0_context;
>> > +
>> > static void usart_set_baud(int minor, int baud)
>> > {
>> > /*
>> > @@ -55,10 +61,17 @@ static void usart_set_baud(int minor, int baud)
>> > return;
>> > }
>> >
>> > -static void usart_initialize(int minor)
>> > +static volatile usart0_regs
>> > *rpi_uart_get_regs(rtems_termios_device_context *base)
>> > {
>> > - unsigned int gpio_reg;
>> > + uart0_context *ctx;
>> > +
>> > + ctx = (usart0_regs *) base;
>> > + return ctx->regs;
>> > +}
>> >
>> > +static void usart_initialize(rtems_termios_device_context *base)
>> > +{
>> > + unsigned int gpio_reg;
>> > /*
>> > ** Program GPIO pins for UART 0
>> > */
>> > @@ -75,67 +88,81 @@ static void usart_initialize(int minor)
>> > usart_delay(150);
>> > BCM2835_REG(BCM2835_GPIO_GPPUDCLK0) = 0;
>> >
>> > + volatile uint32_t *uart_regs = rpi_uart_get_regs(base);
>> > +
>> > /*
>> > ** Init the PL011 UART
>> > */
>> > - BCM2835_REG(BCM2835_UART0_CR) = 0;
>> > - BCM2835_REG(BCM2835_UART0_ICR) = 0x7FF;
>> > - BCM2835_REG(BCM2835_UART0_IMSC) = 0;
>> > - BCM2835_REG(BCM2835_UART0_IBRD) = 1;
>> > - BCM2835_REG(BCM2835_UART0_FBRD) = 40;
>> > - BCM2835_REG(BCM2835_UART0_LCRH) = 0x70;
>> > - BCM2835_REG(BCM2835_UART0_RSRECR) = 0;
>> > -
>> > - BCM2835_REG(BCM2835_UART0_CR) = 0x301;
>> > -
>> > - BCM2835_REG(BCM2835_UART0_IMSC) = BCM2835_UART0_IMSC_RX;
>> > -
>> > - usart_set_baud(minor, 115000);
>> > + uart_regs->cr = 0;
>> > + uart_regs->icr = 0x7ff;
>> > + uart_regs->imsc = 0;
>> > + uart_regs->ibrd = 1;
>> > + uart_regs->fbrd= 40;
>> > + uart_regs->lcrh= 0x70;
>> > + uart_regs->rsrecr= 0;
>> > + uart_regs->cr = 0x301;
>> > + uart_regs->imsc = BCM2835_UART0_IMSC_RX;
>> > + // usart_set_baud(minor, 115000);
>> > }
>> >
>> > -static int usart_first_open(int major, int minor, void *arg)
>> > +static bool usart_first_open(
>> > + rtems_termios_tty *tty,
>> > + rtems_termios_device_context *base,
>> > + struct termios *term,
>> > + rtems_libio_open_close_args_t *args
>> > +)
>> > {
>> > - rtems_libio_open_close_args_t *oc =
>> > (rtems_libio_open_close_args_t *) arg;
>> > - struct rtems_termios_tty *tty = (struct rtems_termios_tty *)
>> > oc->iop->data1;
>> > - const console_tbl *ct = Console_Port_Tbl [minor];
>> > - console_data *cd = &Console_Port_Data [minor];
>> > + rtems_status_code sc;
>> > + uart0_context *ctx;
>> > + bool ok;
>> >
>> > - cd->termios_data = tty;
>> > - rtems_termios_set_initial_baud(tty, ct->ulClock);
>> > + ctx = (uart0_context *) base;
>> >
>> > - return 0;
>> > + usart_initialize(base);
>> > +
>> > + sc = rtems_termios_set_initial_baud(tty, USART0_DEFAULT_BAUD);
>> > + if ( sc != RTEMS_SUCCESSFUL ){
>> > + printk("Error setting the baud for termios\n");
>> > + return false;
>> > + }
>> > }
>> >
>> > -static int usart_last_close(int major, int minor, void *arg)
>> > +static int usart_last_close(
>> > + rtems_termios_tty *tty,
>> > + rtems_termios_device_context *base,
>> > + rtems_termios_open_close_args_t *arg)
>> > {
>> > return 0;
>> > }
>> >
>> > -static int usart_read_polled(int minor)
>> > +static int usart_read_polled(rtems_termios_device_context *base)
>> > {
>> > - if (minor == 0) {
>> > - if (((BCM2835_REG(BCM2835_UART0_FR)) & BCM2835_UART0_FR_RXFE)
>> > == 0) {
>> > - return((BCM2835_REG(BCM2835_UART0_DR)) & 0xFF );
>> > - } else {
>> > - return -1;
>> > - }
>> > - } else {
>> > - printk("Unknown console minor number: %d\n", minor);
>> > - return -1;
>> > + volatile usart0_regs *regs;
>> > +
>> > + regs = rpi_uart_get_regs(base);
>> > +
>> > + if ((regs->fr & BCM2835_UART0_FR_RXFE) == 0) {
>> > + return (regs->dr & 0xFF);
>> > }
>> > +
>> > + return -1;
>> > }
>> >
>> > -static void usart_write_polled(int minor, char c)
>> > +static void usart_write_polled(rtems_termios_device_context *base,
>> > char c)
>> > {
>> > - while (1) {
>> > - if ((BCM2835_REG(BCM2835_UART0_FR) & BCM2835_UART0_FR_TXFF)
>> == 0)
>> > - break;
>> > - }
>> > - BCM2835_REG(BCM2835_UART0_DR) = c;
>> > + volatile usart0_regs *regs;
>> > +
>> > + regs = rpi_uart_get_regs(base);
>> > +
>> > + while (1) {
>> > + if (((regs->fr) & BCM2835_UART0_FR_TXFF) == 0)
>> > + break;
>> > + }
>> > + regs->dr = c;
>> > }
>> >
>> > static ssize_t usart_write_support_polled(
>> > - int minor,
>> > + rtems_termios_device_context *base,
>> > const char *s,
>> > size_t n
>> > )
>> > @@ -143,7 +170,7 @@ static ssize_t usart_write_support_polled(
>> > ssize_t i = 0;
>> >
>> > for (i = 0; i < n; ++i) {
>> > - usart_write_polled(minor, s [i]);
>> > + usart_write_polled(base, s[i]);
>> > }
>> >
>> > return n;
>> > @@ -154,14 +181,11 @@ static int usart_set_attributes(int minor,
>> > const struct termios *term)
>> > return -1;
>> > }
>> >
>> > -const console_fns bcm2835_usart_fns = {
>> > - .deviceProbe = libchip_serial_default_probe,
>> > - .deviceFirstOpen = usart_first_open,
>> > - .deviceLastClose = usart_last_close,
>> > - .deviceRead = usart_read_polled,
>> > - .deviceWrite = usart_write_support_polled,
>> > - .deviceInitialize = usart_initialize,
>> > - .deviceWritePolled = usart_write_polled,
>> > - .deviceSetAttributes = usart_set_attributes,
>> > - .deviceOutputUsesInterrupts = false
>> > -};
>> > +const rtems_termios_device_handler bcm2835_uart0_handler_polled = {
>> > + .first_open = usart_first_open,
>> > + .last_close = usart_last_close,
>> > + .poll_read = usart_read_polled,
>> > + .set_attributes = usart_set_attributes,
>> > + .write = usart_write_support_polled,
>> > + .mode = TERMIOS_POLLED
>> > +}
>> > \ No newline at end of file
>> >
>> > On Wed, Dec 25, 2019 at 12:36 AM Joel Sherrill <joel at rtems.org
>> > <mailto:joel at rtems.org>> wrote:
>> >
>> >
>> >
>> > On Tue, Dec 24, 2019, 12:19 PM Niteesh <gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at 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.gn at gmail.com
>> > <mailto:gsnb.gn at 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
>> > <list at c-mauderer.de <mailto:list at 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.gn at gmail.com <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at 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
>> > > <list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > <mailto:list at c-mauderer.de
>> > <mailto:list at 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.gn at gmail.com <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>
>> > > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com> <mailto:
>> gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at 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.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com> <mailto:
>> gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>
>> > > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com> <mailto:
>> gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at 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
>> > > > <list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > <mailto:list at c-mauderer.de <mailto:
>> list at c-mauderer.de>>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>>> wrote:
>> > > >
>> > > > On 22/12/2019 19:45, Joel
>> > Sherrill wrote:
>> > > > >
>> > > > >
>> > > > > On Sun, Dec 22, 2019,
>> > 12:29 PM Niteesh
>> > > <gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com> <mailto:
>> gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>
>> > > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com> <mailto:
>> gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>>
>> > > > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>
>> > <mailto:gsnb.gn at gmail.com <mailto:gsnb.gn at gmail.com
>> >
>> > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>>>> wrote:
>> > > > >
>> > > > > On Sun, Dec 22, 2019
>> > at 8:44 PM Christian
>> > > Mauderer
>> > > > > <list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>
>> > <mailto:list at c-mauderer.de <mailto:
>> list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>>
>> > > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>
>> > <mailto:list at c-mauderer.de <mailto:
>> list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at 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 at rtems.org
>> > <mailto:devel at rtems.org> <mailto:devel at rtems.org
>> > <mailto:devel at rtems.org>>
>> > > <mailto:devel at rtems.org
>> > <mailto:devel at rtems.org> <mailto:devel at rtems.org
>> > <mailto:devel at rtems.org>>>
>> > > > <mailto:devel at rtems.org
>> > <mailto:devel at rtems.org> <mailto:devel at rtems.org
>> > <mailto:devel at rtems.org>>
>> > > <mailto:devel at rtems.org
>> > <mailto:devel at rtems.org> <mailto:devel at rtems.org
>> > <mailto:devel at rtems.org>>>>
>> > > > >
>> > http://lists.rtems.org/mailman/listinfo/devel
>> > > > >
>> > > >
>> > >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191227/631c8260/attachment-0001.html>
More information about the devel
mailing list