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...@gmail.com> wrote: > On Fri, Dec 27, 2019 at 1:59 AM Christian Mauderer <l...@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...@gmail.com >> > <mailto:gsnb...@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 <j...@rtems.org >> > <mailto:j...@rtems.org>> wrote: >> > >> > >> > >> > On Tue, Dec 24, 2019, 12:19 PM Niteesh <gsnb...@gmail.com >> > <mailto: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 >> > <mailto: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 <mailto: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> >> > > <mailto: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> >> > <mailto: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>> >> > > > <mailto: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>> >> > > > <mailto: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>> >> > > <mailto: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>>> >> > > > > <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 >> > <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>>> >> > > > <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 >> > <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>>> >> > > > <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 >> > <mailto:devel@rtems.org>>>> >> > > > > >> > http://lists.rtems.org/mailman/listinfo/devel >> > > > > >> > > > >> > > >> > >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
