Raspberrypi3: Mini UART driver
Niteesh
gsnb.gn at gmail.com
Wed Dec 25 14:32:15 UTC 2019
What about the framebuffer it still uses minor and major's?
On Wed, Dec 25, 2019 at 3:20 PM Niteesh <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> wrote:
>
>>
>>
>> On Tue, Dec 24, 2019, 12:19 PM Niteesh <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> 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>
>>>> 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>> 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>> 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>>>
>>>>> 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>>>
>>>>> 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>>>
>>>>> 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>>>> 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>>>> 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>>>
>>>>> > > >
>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191225/f702fcd1/attachment-0001.html>
More information about the devel
mailing list