<div dir="ltr"><div dir="ltr">On Fri, Dec 27, 2019 at 1:59 AM Christian Mauderer <<a href="mailto:list@c-mauderer.de">list@c-mauderer.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 25/12/2019 15:32, Niteesh wrote:<br>
> What about the framebuffer it still uses minor and major's?<br>
<br>
I'm not entirely sure but I don't think that it is a problem to mix<br>
legacy and new style drivers.</blockquote><div>I want to create rtems_termios_device_handler for the framebuffer, the current driver uses console_fns and</div><div>the functions have the old signatures, which uses major and minor numbers, but the device handler uses the newer interface</div><div><span class="gmail-k" style="color:rgb(64,64,64);font-family:Consolas,"Andale Mono WT","Andale Mono","Lucida Console","Lucida Sans Typewriter","DejaVu Sans Mono","Bitstream Vera Sans Mono","Liberation Mono","Nimbus Mono L",Monaco,"Courier New",Courier,monospace;font-size:12px;box-sizing:border-box;font-weight:bold"><br></span></div><div><span class="gmail-k" style="color:rgb(64,64,64);font-family:Consolas,"Andale Mono WT","Andale Mono","Lucida Console","Lucida Sans Typewriter","DejaVu Sans Mono","Bitstream Vera Sans Mono","Liberation Mono","Nimbus Mono L",Monaco,"Courier New",Courier,monospace;font-size:12px;box-sizing:border-box;font-weight:bold">static</span><span style="color:rgb(64,64,64);font-family:Consolas,"Andale Mono WT","Andale Mono","Lucida Console","Lucida Sans Typewriter","DejaVu Sans Mono","Bitstream Vera Sans Mono","Liberation Mono","Nimbus Mono L",Monaco,"Courier New",Courier,monospace;font-size:12px"> </span><span class="gmail-kt" style="font-family:Consolas,"Andale Mono WT","Andale Mono","Lucida Console","Lucida Sans Typewriter","DejaVu Sans Mono","Bitstream Vera Sans Mono","Liberation Mono","Nimbus Mono L",Monaco,"Courier New",Courier,monospace;font-size:12px;box-sizing:border-box;color:rgb(68,85,136);font-weight:bold">bool</span><span style="color:rgb(64,64,64);font-family:Consolas,"Andale Mono WT","Andale Mono","Lucida Console","Lucida Sans Typewriter","DejaVu Sans Mono","Bitstream Vera Sans Mono","Liberation Mono","Nimbus Mono L",Monaco,"Courier New",Courier,monospace;font-size:12px"> </span><span class="gmail-nf" style="font-family:Consolas,"Andale Mono WT","Andale Mono","Lucida Console","Lucida Sans Typewriter","DejaVu Sans Mono","Bitstream Vera Sans Mono","Liberation Mono","Nimbus Mono L",Monaco,"Courier New",Courier,monospace;font-size:12px;box-sizing:border-box;color:rgb(153,0,0);font-weight:bold">my_driver_first_open</span><span class="gmail-p" style="color:rgb(64,64,64);font-family:Consolas,"Andale Mono WT","Andale Mono","Lucida Console","Lucida Sans Typewriter","DejaVu Sans Mono","Bitstream Vera Sans Mono","Liberation Mono","Nimbus Mono L",Monaco,"Courier New",Courier,monospace;font-size:12px;box-sizing:border-box">(</span></div><pre style="box-sizing:border-box;font-family:Consolas,"Andale Mono WT","Andale Mono","Lucida Console","Lucida Sans Typewriter","DejaVu Sans Mono","Bitstream Vera Sans Mono","Liberation Mono","Nimbus Mono L",Monaco,"Courier New",Courier,monospace;font-size:12px;margin-top:0px;margin-bottom:0px;padding:12px;line-height:1.5;overflow:auto;color:rgb(64,64,64)">  <span class="gmail-n" style="box-sizing:border-box;color:rgb(51,51,51)">rtems_termios_tty</span>             <span class="gmail-o" style="box-sizing:border-box;font-weight:bold">*</span><span class="gmail-n" style="box-sizing:border-box;color:rgb(51,51,51)">tty</span><span class="gmail-p" style="box-sizing:border-box">,</span>
  <span class="gmail-n" style="box-sizing:border-box;color:rgb(51,51,51)">rtems_termios_device_context</span>  <span class="gmail-o" style="box-sizing:border-box;font-weight:bold">*</span><span class="gmail-n" style="box-sizing:border-box;color:rgb(51,51,51)">base</span><span class="gmail-p" style="box-sizing:border-box">,</span>
  <span class="gmail-k" style="box-sizing:border-box;font-weight:bold">struct</span> <span class="gmail-n" style="box-sizing:border-box;color:rgb(51,51,51)">termios</span>                <span class="gmail-o" style="box-sizing:border-box;font-weight:bold">*</span><span class="gmail-n" style="box-sizing:border-box;color:rgb(51,51,51)">term</span><span class="gmail-p" style="box-sizing:border-box">,</span>
  <span class="gmail-n" style="box-sizing:border-box;color:rgb(51,51,51)">rtems_libio_open_close_args_t</span> <span class="gmail-o" style="box-sizing:border-box;font-weight:bold">*</span><span class="gmail-n" style="box-sizing:border-box;color:rgb(51,51,51)">args</span>
<span class="gmail-p" style="box-sizing:border-box">)</span></pre><div>as mentioned in the doc will it cause any trouble? If it does then will also have to rewrite the fb right?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> On Wed, Dec 25, 2019 at 3:20 PM Niteesh <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>> wrote:<br>
> <br>
>     Just to make sure I am going in the right track.<br>
>     I moved the uart register definitions to bsp/usart.h into a struct<br>
>     of uint32_t called usart0_regs<br>
>     here is git diff of usart.c after changing it to the latest console<br>
>     interface.<br>
> <br>
>     diff --git a/bsps/arm/raspberrypi/console/usart.c<br>
>     b/bsps/arm/raspberrypi/console/usart.c<br>
>     index 25fb523621..b12f375a1c 100644<br>
>     --- a/bsps/arm/raspberrypi/console/usart.c<br>
>     +++ b/bsps/arm/raspberrypi/console/usart.c<br>
>     @@ -47,6 +47,12 @@ static uint32_t usart_get_baud(const console_tbl *ct)<br>
>      }<br>
>      #endif<br>
>      <br>
>     +typedef struct {<br>
>     +  rtems_termios_device_context base;<br>
>     +  const char *device_name;<br>
>     +  volatile usart0_regs *regs;<br>
>     +}uart0_context;<br>
>     +<br>
>      static void usart_set_baud(int minor, int baud)<br>
>      {<br>
>       /*<br>
>     @@ -55,10 +61,17 @@ static void usart_set_baud(int minor, int baud)<br>
>       return;<br>
>      }<br>
>      <br>
>     -static void usart_initialize(int minor)<br>
>     +static volatile usart0_regs<br>
>     *rpi_uart_get_regs(rtems_termios_device_context *base)<br>
>      {<br>
>     -  unsigned int gpio_reg;<br>
>     +  uart0_context *ctx;<br>
>     +<br>
>     +  ctx = (usart0_regs *) base;<br>
>     +  return ctx->regs;<br>
>     +}<br>
>      <br>
>     +static void usart_initialize(rtems_termios_device_context *base)<br>
>     +{<br>
>     +  unsigned int gpio_reg;<br>
>        /*<br>
>        ** Program GPIO pins for UART 0<br>
>        */<br>
>     @@ -75,67 +88,81 @@ static void usart_initialize(int minor)<br>
>        usart_delay(150);<br>
>        BCM2835_REG(BCM2835_GPIO_GPPUDCLK0) = 0;<br>
>      <br>
>     +  volatile uint32_t *uart_regs = rpi_uart_get_regs(base);<br>
>     +<br>
>        /*<br>
>        ** Init the PL011 UART<br>
>        */<br>
>     -  BCM2835_REG(BCM2835_UART0_CR)   = 0;<br>
>     -  BCM2835_REG(BCM2835_UART0_ICR)  = 0x7FF;<br>
>     -  BCM2835_REG(BCM2835_UART0_IMSC) = 0;<br>
>     -  BCM2835_REG(BCM2835_UART0_IBRD) = 1;<br>
>     -  BCM2835_REG(BCM2835_UART0_FBRD) = 40;<br>
>     -  BCM2835_REG(BCM2835_UART0_LCRH) = 0x70;<br>
>     -  BCM2835_REG(BCM2835_UART0_RSRECR) =  0;<br>
>     -<br>
>     -  BCM2835_REG(BCM2835_UART0_CR)   = 0x301;<br>
>     -<br>
>     -  BCM2835_REG(BCM2835_UART0_IMSC) = BCM2835_UART0_IMSC_RX;<br>
>     -<br>
>     -  usart_set_baud(minor, 115000);<br>
>     +  uart_regs->cr  = 0;<br>
>     +  uart_regs->icr = 0x7ff;<br>
>     +  uart_regs->imsc = 0;<br>
>     +  uart_regs->ibrd = 1;<br>
>     +  uart_regs->fbrd= 40;<br>
>     +  uart_regs->lcrh= 0x70;<br>
>     +  uart_regs->rsrecr= 0;<br>
>     +  uart_regs->cr = 0x301;<br>
>     +  uart_regs->imsc = BCM2835_UART0_IMSC_RX;<br>
>     +  // usart_set_baud(minor, 115000);<br>
>      }<br>
>      <br>
>     -static int usart_first_open(int major, int minor, void *arg)<br>
>     +static bool usart_first_open(<br>
>     +  rtems_termios_tty *tty,<br>
>     +  rtems_termios_device_context *base,<br>
>     +  struct termios *term,<br>
>     +  rtems_libio_open_close_args_t *args<br>
>     +)<br>
>      {<br>
>     -  rtems_libio_open_close_args_t *oc =<br>
>     (rtems_libio_open_close_args_t *) arg;<br>
>     -  struct rtems_termios_tty *tty = (struct rtems_termios_tty *)<br>
>     oc->iop->data1;<br>
>     -  const console_tbl *ct = Console_Port_Tbl [minor];<br>
>     -  console_data *cd = &Console_Port_Data [minor];<br>
>     +  rtems_status_code sc;<br>
>     +  uart0_context *ctx;<br>
>     +  bool ok;<br>
>      <br>
>     -  cd->termios_data = tty;<br>
>     -  rtems_termios_set_initial_baud(tty, ct->ulClock);<br>
>     +  ctx = (uart0_context *) base;<br>
>      <br>
>     -  return 0;<br>
>     +  usart_initialize(base);<br>
>     +<br>
>     +  sc = rtems_termios_set_initial_baud(tty,  USART0_DEFAULT_BAUD);<br>
>     +  if ( sc != RTEMS_SUCCESSFUL ){<br>
>     +    printk("Error setting the baud for termios\n");<br>
>     +    return false;<br>
>     +  }<br>
>      }<br>
>      <br>
>     -static int usart_last_close(int major, int minor, void *arg)<br>
>     +static int usart_last_close(<br>
>     +  rtems_termios_tty *tty,<br>
>     +  rtems_termios_device_context *base,<br>
>     +  rtems_termios_open_close_args_t *arg)<br>
>      {<br>
>        return 0;<br>
>      }<br>
>      <br>
>     -static int usart_read_polled(int minor)<br>
>     +static int usart_read_polled(rtems_termios_device_context *base)<br>
>      {<br>
>     -  if (minor == 0) {<br>
>     -    if (((BCM2835_REG(BCM2835_UART0_FR)) & BCM2835_UART0_FR_RXFE)<br>
>     == 0) {<br>
>     -       return((BCM2835_REG(BCM2835_UART0_DR)) & 0xFF );<br>
>     -    } else {<br>
>     -      return -1;<br>
>     -    }<br>
>     -  } else {<br>
>     -    printk("Unknown console minor number: %d\n", minor);<br>
>     -    return -1;<br>
>     +  volatile usart0_regs *regs;<br>
>     +<br>
>     +  regs = rpi_uart_get_regs(base);<br>
>     +<br>
>     +  if ((regs->fr & BCM2835_UART0_FR_RXFE) == 0) {<br>
>     +    return (regs->dr & 0xFF);<br>
>        }<br>
>     +<br>
>     +  return -1;<br>
>      }<br>
>      <br>
>     -static void usart_write_polled(int minor, char c)<br>
>     +static void usart_write_polled(rtems_termios_device_context *base,<br>
>     char c)<br>
>      {<br>
>     -   while (1) {<br>
>     -     if ((BCM2835_REG(BCM2835_UART0_FR) & BCM2835_UART0_FR_TXFF) == 0)<br>
>     -       break;<br>
>     -   }<br>
>     -   BCM2835_REG(BCM2835_UART0_DR) = c;<br>
>     +  volatile usart0_regs *regs;<br>
>     +<br>
>     +  regs = rpi_uart_get_regs(base);<br>
>     +<br>
>     +  while (1) {<br>
>     +    if (((regs->fr) & BCM2835_UART0_FR_TXFF) == 0)<br>
>     +      break;<br>
>     +  }<br>
>     +  regs->dr = c;<br>
>      }<br>
>      <br>
>      static ssize_t usart_write_support_polled(<br>
>     -  int minor,<br>
>     +  rtems_termios_device_context *base,<br>
>        const char *s,<br>
>        size_t n<br>
>      )<br>
>     @@ -143,7 +170,7 @@ static ssize_t usart_write_support_polled(<br>
>        ssize_t i = 0;<br>
>      <br>
>        for (i = 0; i < n; ++i) {<br>
>     -    usart_write_polled(minor, s [i]);<br>
>     +    usart_write_polled(base, s[i]);<br>
>        }<br>
>      <br>
>        return n;<br>
>     @@ -154,14 +181,11 @@ static int usart_set_attributes(int minor,<br>
>     const struct termios *term)<br>
>        return -1;<br>
>      }<br>
>      <br>
>     -const console_fns bcm2835_usart_fns = {<br>
>     -  .deviceProbe = libchip_serial_default_probe,<br>
>     -  .deviceFirstOpen = usart_first_open,<br>
>     -  .deviceLastClose = usart_last_close,<br>
>     -  .deviceRead = usart_read_polled,<br>
>     -  .deviceWrite = usart_write_support_polled,<br>
>     -  .deviceInitialize = usart_initialize,<br>
>     -  .deviceWritePolled = usart_write_polled,<br>
>     -  .deviceSetAttributes = usart_set_attributes,<br>
>     -  .deviceOutputUsesInterrupts = false<br>
>     -};<br>
>     +const rtems_termios_device_handler bcm2835_uart0_handler_polled = {<br>
>     +  .first_open = usart_first_open,<br>
>     +  .last_close = usart_last_close,<br>
>     +  .poll_read = usart_read_polled,<br>
>     +  .set_attributes = usart_set_attributes,<br>
>     +  .write = usart_write_support_polled,<br>
>     +  .mode = TERMIOS_POLLED<br>
>     +}<br>
>     \ No newline at end of file<br>
> <br>
>     On Wed, Dec 25, 2019 at 12:36 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a><br>
>     <mailto:<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>>> wrote:<br>
> <br>
> <br>
> <br>
>         On Tue, Dec 24, 2019, 12:19 PM Niteesh <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>         <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>> wrote:<br>
> <br>
>             And also the register definitions are in raspberrpi.h file<br>
>             should I move them to usart.h.<br>
> <br>
> <br>
>         Sounds right if you mean bsp/usart.h<br>
> <br>
>             I have a doubt we have a register field in device_context<br>
>             typedef struct { <br>
> <br>
>                 rtems_termios_device_context base; <br>
> <br>
>                 const char *device_name; <br>
> <br>
>                 volatile some_chip_registers *regs;<br>
> <br>
>             } my_driver_context;<br>
> <br>
>             How does the reg field point to the correct memory location?<br>
>             for instance in IMX BSP,<br>
>             there is a struct with register field's but none of the<br>
>             define a memory location?<br>
> <br>
> <br>
>         Make sure the structure has volatiles and proper alignment. :)<br>
> <br>
> <br>
>             On Tue, Dec 24, 2019 at 11:37 PM Niteesh <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>             <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>> wrote:<br>
> <br>
>                 How to handle different serial devices? In other BSPs<br>
>                 the uart devices are the same, so<br>
>                 they were able to put it under a single array? But here<br>
>                 we have 2 uarts and a FB?<br>
> <br>
> <br>
>                 On Tue, Dec 24, 2019 at 8:18 PM Christian Mauderer<br>
>                 <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>> wrote:<br>
> <br>
>                     On 24/12/2019 12:06, Niteesh wrote:<br>
>                     > The current raspi console section is like this:<br>
>                     > The bsp_console_select in console_select.c is<br>
>                     responsible for selecting<br>
>                     > between uart and the framebuffer. It does so<br>
>                     > by setting the Console_port_minor.<br>
>                     > The console_config is responsible for output_char<br>
>                     function.<br>
>                     > And other files are driver code.<br>
>                     > If rewriting, this would be my approach,<br>
>                     > Rewrite the bsp_console_select to set some kind of<br>
>                     a variable like in<br>
>                     > IMX, then in console_initialize function<br>
>                     > link the right driver to /dev/console.<br>
>                     > Replace the console_tbl with the device_context<br>
>                     and console_fns with<br>
>                     > termios_device_handlers and<br>
>                     > finally add in the console_initialization function.<br>
> <br>
>                     I agree that this would be a clean solution. So if<br>
>                     you want you can do<br>
>                     that. But there might is a hurdle: As far as I<br>
>                     understood you you only<br>
>                     have a Pi3? So you might have a hard time testing<br>
>                     the changes. Maybe the<br>
>                     simulator could work.<br>
> <br>
>                     Another possibility could be to set the<br>
>                     "Console_port_minor" to<br>
>                     something unused (for example -1). In that case you<br>
>                     can define another<br>
>                     /dev/console.<br>
> <br>
>                     Best regards and merry Christmas (in case you celebrate)<br>
> <br>
>                     Christian<br>
> <br>
>                     ><br>
>                     > On Tue, Dec 24, 2019 at 2:13 PM Niteesh<br>
>                     <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>><br>
>                     > <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>>> wrote:<br>
>                     ><br>
>                     >     Thank you so much, for such a detailed answer.<br>
>                     Now things make<br>
>                     >     really good sense to me, <br>
>                     >     going through the code now is just a breeze.<br>
>                     But I still have one<br>
>                     >     question<br>
>                     >     for the newer driver interface is<br>
>                     console_initialize the function<br>
>                     >     which RTEMS calls while initializing<br>
>                     >     the console? Which means I can't mess with the<br>
>                     name right? It is<br>
>                     >     similar to the main function, right?<br>
>                     ><br>
>                     >     The current driver is a legacy one, how do you<br>
>                     want me to proceed,<br>
>                     >     shall I rewrite the legacy to a<br>
>                     >     the new one, this is will be a great<br>
>                     learning experience for me also<br>
>                     >     and we also get the BSP updated to the latest<br>
>                     interface.<br>
>                     ><br>
>                     ><br>
>                     >     On Tue, Dec 24, 2019 at 3:20 AM Christian Mauderer<br>
>                     >     <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>> wrote:<br>
>                     ><br>
>                     >         Hello Niteesh,<br>
>                     ><br>
>                     >         quite a lot of questions. I'll try to<br>
>                     answer them. Note that it<br>
>                     >         has been<br>
>                     >         some time since I had a detailed look at<br>
>                     that code so if something I<br>
>                     >         tell seems odd please don't hesitate to<br>
>                     question it.<br>
>                     ><br>
>                     >         Please note that in RTEMS their are more<br>
>                     or less two "levels" of<br>
>                     >         support<br>
>                     >         for a serial console:<br>
>                     ><br>
>                     >         1. A very basic polled system console<br>
>                     (also known as<br>
>                     >         "debug-console" in<br>
>                     >         some BSPs). This one is used for printk<br>
>                     and should work in basically<br>
>                     >         every case. It is used for critical system<br>
>                     messages like<br>
>                     >         printing the<br>
>                     >         exception frame. For that a BSP has to<br>
>                     provide a<br>
>                     >         "BSP_output_char" function.<br>
>                     ><br>
>                     >         2. A full featured UART driver integrated<br>
>                     into Termios. That one<br>
>                     >         will be<br>
>                     >         used for all normal I/O on the UARTs.<br>
>                     ><br>
>                     >         As far as I know the "console_tbl<br>
>                     Console_Configuration_Ports"<br>
>                     >         belongs<br>
>                     >         to a table based legacy interface. It is<br>
>                     handled in the file<br>
>                     >         bsps/shared/dev/serial/legacy-console.c.<br>
>                     I'm not sure whether it is<br>
>                     >         documented in the BSP guide because it<br>
>                     shouldn't be used for new<br>
>                     >         BSPs.<br>
>                     >         Same is true for the "major" and "minor"<br>
>                     stuff: It's not really<br>
>                     >         used for<br>
>                     >         new drivers.<br>
>                     ><br>
>                     >         Newer drivers use the initialization that<br>
>                     is described in the manual<br>
>                     >         that you have already found. Basically<br>
>                     they use<br>
>                     >         "rtems_termios_device_install" to register<br>
>                     a new UART as<br>
>                     >         "/dev/ttySomething". Some recent (ARM)<br>
>                     BSPs that do that are the<br>
>                     >         imx or<br>
>                     >         the atsam.<br>
>                     ><br>
>                     >         The console that is used for stdin, stdout<br>
>                     and stderr (printf,<br>
>                     >         scanf,<br>
>                     >         ...) is the one called "/dev/console"<br>
>                     (defined in<br>
>                     >         CONSOLE_DEVICE_NAME).<br>
>                     >         For the legacy table based interface it's<br>
>                     the one with the index of<br>
>                     >         "Console_Port_Minor".<br>
>                     ><br>
>                     ><br>
>                     >         If you want to access any UART other than<br>
>                     the one for stdin and<br>
>                     >         stdout<br>
>                     >         you do that the same way like on Linux:<br>
>                     Just use the "open"<br>
>                     >         function on<br>
>                     >         the "/dev/ttySomething" and use "read",<br>
>                     "write" and simmilar or use<br>
>                     >         "fopen" together with "fread", "fwrite",<br>
>                     "fprintf", ...<br>
>                     ><br>
>                     ><br>
>                     >         "printf" (and family) is a function<br>
>                     belonging to the C library.<br>
>                     >         In our<br>
>                     >         case that's newlib. It will format your<br>
>                     message and after some other<br>
>                     >         preprocessing will call the "write"<br>
>                     function of the file that is<br>
>                     >         opened<br>
>                     >         as stdout (which is "/dev/console" in the<br>
>                     default case).<br>
>                     ><br>
>                     ><br>
>                     >         I hope that I helped you with that<br>
>                     explanation. Please feel free<br>
>                     >         to ask<br>
>                     >         anything if it isn't clear.<br>
>                     ><br>
>                     >         Best regards<br>
>                     ><br>
>                     >         Christian<br>
>                     ><br>
>                     >         On 23/12/2019 19:50, Niteesh wrote:<br>
>                     >         > And finally, how does printf work? It is<br>
>                     a macro? In that<br>
>                     >         case, how does<br>
>                     >         > any write to<br>
>                     >         > a console work?<br>
>                     >         ><br>
>                     >         > On Tue, Dec 24, 2019 at 12:18 AM Niteesh<br>
>                     <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>><br>
>                     >         <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>><br>
>                     >         > <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>>>> wrote:<br>
>                     >         ><br>
>                     >         >     Is the correct port minor number set<br>
>                     during the<br>
>                     >         initialization? What<br>
>                     >         >     is the application want's to<br>
>                     >         >     access some other port?<br>
>                     >         ><br>
>                     >         >     On Tue, Dec 24, 2019 at 12:16 AM Niteesh<br>
>                     >         <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>><br>
>                     >         >     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>>>> wrote:<br>
>                     >         ><br>
>                     >         >         I would like to clarify my<br>
>                     doubts regarding the<br>
>                     >         console driver.<br>
>                     >         >         I went through the documentation<br>
>                     >         >         for the console<br>
>                     >         >       <br>
>                     >       <br>
>                       driver <a href="https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction</a>.<br>
>                     >         >         But it is quite different from<br>
>                     how some BSPs initialize.<br>
>                     >         >         Correct me if I am wrong<br>
>                     >         >         The console_tbl contains the<br>
>                     various entries of serial<br>
>                     >         ports.<br>
>                     >         >         The console_fns is a struct of<br>
>                     function pointers,<br>
>                     >         which point to<br>
>                     >         >         the BSP uart functions.<br>
>                     >         >         The<br>
>                     BSP_output_char_function_type is what will be<br>
>                     >         called for<br>
>                     >         >         printing a char on to the console.<br>
>                     >         >         How does RTEMS initialize the<br>
>                     uart? It's seems not to<br>
>                     >         be same<br>
>                     >         >         for all BSPs.<br>
>                     >         >         The doc says that the driver's<br>
>                     initialization function<br>
>                     >         is called<br>
>                     >         >         once during the rtems<br>
>                     initialization process.<br>
>                     >         >         The console init function<br>
>                     install the serial driver using<br>
>                     >         >         rtems_termios_device_install but<br>
>                     there seems to be<br>
>                     >         >         no such function in the<br>
>                     raspberry pi? But there is a<br>
>                     >         entry in<br>
>                     >         >         console_fns for init function,<br>
>                     but then how does it<br>
>                     >         >         gets called?<br>
>                     >         >         And for BSP's with multiple<br>
>                     serial's, the output function<br>
>                     >         >         chooses the right serial using<br>
>                     console_port_minor,<br>
>                     >         >         Is it during initialization?<br>
>                     >         >         What is the need for get and set<br>
>                     register functions? <br>
>                     >         ><br>
>                     >         >         On Mon, Dec 23, 2019 at 1:04 AM<br>
>                     Christian Mauderer<br>
>                     >         >         <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>><br>
>                     >         <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>>> wrote:<br>
>                     >         ><br>
>                     >         >             On 22/12/2019 19:45, Joel<br>
>                     Sherrill wrote:<br>
>                     >         >             ><br>
>                     >         >             ><br>
>                     >         >             > On Sun, Dec 22, 2019,<br>
>                     12:29 PM Niteesh<br>
>                     >         <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>><br>
>                     >         >             <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>>><br>
>                     >         >             > <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>><br>
>                     >         <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>><br>
>                     >         <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a><br>
>                     <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>>>>> wrote:<br>
>                     >         >             ><br>
>                     >         >             >     On Sun, Dec 22, 2019<br>
>                     at 8:44 PM Christian<br>
>                     >         Mauderer<br>
>                     >         >             >     <<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
>                     >         <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
>                     >         <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>><br>
>                     >         >             <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
>                     >         <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>><br>
>                     >         <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a><br>
>                     <mailto:<a href="mailto:list@c-mauderer.de" target="_blank">list@c-mauderer.de</a>>>>>> wrote:<br>
>                     >         >             ><br>
>                     >         >             >         Hello Niteesh,<br>
>                     >         >             ><br>
>                     >         >             >         thanks for doing<br>
>                     that work.<br>
>                     >         >             ><br>
>                     >         >             >         On 22/12/2019<br>
>                     12:10, Niteesh wrote:<br>
>                     >         >             >         > The rpi1 and<br>
>                     rpi2 use the PL011 UART,<br>
>                     >         whereas,<br>
>                     >         >             with RPI's<br>
>                     >         >             >         equipped with<br>
>                     >         >             >         ><br>
>                     wireless/Bluetooth module, the PL011 is<br>
>                     >         >             connected to the Bluetooth<br>
>                     >         >             >         > module, and the<br>
>                     mini UART is used as<br>
>                     >         the primary<br>
>                     >         >             UART.<br>
>                     >         >             ><br>
>                     >         >             >         In my opinion it<br>
>                     would be great if you<br>
>                     >         could use<br>
>                     >         >             the FDT to<br>
>                     >         >             >         distinguish<br>
>                     >         >             >         between the<br>
>                     boards. That should allow to add<br>
>                     >         >             raspberry 3 (and<br>
>                     >         >             >         maybe 4)<br>
>                     >         >             >         support without<br>
>                     adding another BSP. More<br>
>                     >         BSPs mean<br>
>                     >         >             a bigger<br>
>                     >         >             >         maintenance<br>
>                     >         >             >         effort for the<br>
>                     RTEMS community.<br>
>                     >         >             ><br>
>                     >         >             >     Learning more about<br>
>                     FDT is on my list for a long<br>
>                     >         >             time.  I would love<br>
>                     >         >             >     to work on that<br>
>                     >         >             >     but I have almost no<br>
>                     exp with FDT's.<br>
>                     >         >             >     But another thing<br>
>                     could also be done, in<br>
>                     >         >             >   <br>
>                      raspberrypi/start/bspstart.c we get the<br>
>                     >         revision and<br>
>                     >         >             >     model of the board<br>
>                     using the mailbox. Every<br>
>                     >         board has<br>
>                     >         >             a unique id,<br>
>                     >         >             >     which we could use to<br>
>                     initialize<br>
>                     >         >             >     the BSP. But using FDT<br>
>                     seems to be a more<br>
>                     >         elegant<br>
>                     >         >             option, it is a<br>
>                     >         >             >     lot of work I think,<br>
>                     but we could take<br>
>                     >         >             >     help from libbsd and<br>
>                     linux I suppose. What<br>
>                     >         do you think?<br>
>                     >         >             ><br>
>                     >         >             ><br>
>                     >         >             > I think there are almost<br>
>                     always two steps to a<br>
>                     >         project<br>
>                     >         >             like this: get it<br>
>                     >         >             > to work and make it nice. :)<br>
>                     >         >             ><br>
>                     >         >             > If you fix the startup<br>
>                     code to read the board<br>
>                     >         revision and<br>
>                     >         >             memory size,<br>
>                     >         >             > you can get a working BSP<br>
>                     that dynamically<br>
>                     >         adapts to the<br>
>                     >         >             models and<br>
>                     >         >             > memory variations with<br>
>                     minimal modifications. If<br>
>                     >         you want<br>
>                     >         >             to then<br>
>                     >         >             > convert the BSP to FDT, it<br>
>                     will be a LOT easier<br>
>                     >         to debug<br>
>                     >         >             with a working BSP.<br>
>                     >         >             ><br>
>                     >         >             > Plus you may be able to<br>
>                     identify every variation<br>
>                     >         point<br>
>                     >         >             based on just the<br>
>                     >         >             > model info. Then FDT is<br>
>                     just a matter of<br>
>                     >         switching the<br>
>                     >         >             source of<br>
>                     >         >             > some/all of the info.<br>
>                     >         >             ><br>
>                     >         >             > That would be my work plan<br>
>                     anyway.<br>
>                     >         ><br>
>                     >         >             I agree with Joel that a<br>
>                     secure development basis<br>
>                     >         (also<br>
>                     >         >             known as "hack")<br>
>                     >         >             as a first step is a good<br>
>                     idea. You maybe even<br>
>                     >         just make the<br>
>                     >         >             mini UART<br>
>                     >         >             the default driver while you<br>
>                     are developing. Then<br>
>                     >         you can be<br>
>                     >         >             sure that<br>
>                     >         >             you have the right driver.<br>
>                     >         ><br>
>                     >         >             As soon as that works you<br>
>                     can either change to the<br>
>                     >         revision<br>
>                     >         >             method or<br>
>                     >         >             (better) to the FDT one and<br>
>                     after that the patches<br>
>                     >         can be<br>
>                     >         >             merged. Using<br>
>                     >         >             the FDT isn't that<br>
>                     complicated. Basically you<br>
>                     >         search for a<br>
>                     >         >             node based on<br>
>                     >         >             different parameters. For an<br>
>                     example you can take<br>
>                     >         a look at<br>
>                     >         >             the imx BSP.<br>
>                     >         >             In imx_uart_probe<br>
>                     >         (bsps/arm/imx/console/console-config.c) a<br>
>                     >         >             fdt node is<br>
>                     >         >             searched and based on that a<br>
>                     UART driver is used.<br>
>                     >         But again:<br>
>                     >         >             Follow<br>
>                     >         >             Joels suggestion to start<br>
>                     simple and secure.<br>
>                     >         ><br>
>                     >         >             ><br>
>                     >         >             >         ><br>
>                     >         >             >         ><br>
>                     >         >             >       <br>
>                     >         >           <br>
>                     >       <br>
>                        <a href="https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf" rel="noreferrer" target="_blank">https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf</a><br>
>                     >         >             >         > But from the<br>
>                     above doc (PAGE 10), the<br>
>                     >         mini uart<br>
>                     >         >             has 16550 like<br>
>                     >         >             >         registers<br>
>                     >         >             >         > and RTEMS<br>
>                     already has the driver for it<br>
>                     >         >             >         ><br>
>                     bsps/shared/dev/serial/ns16550.c. But<br>
>                     >         I am not<br>
>                     >         >             sure how<br>
>                     >         >             >         compatible they<br>
>                     >         >             >         > are? Should a<br>
>                     new driver be<br>
>                     >         implemented from<br>
>                     >         >             scratch or use<br>
>                     >         >             >         ns16550 if<br>
>                     >         >             >         > possible?<br>
>                     >         >             ><br>
>                     >         >             >         In general it's<br>
>                     better to re-use<br>
>                     >         existing code.<br>
>                     >         >             That has multiple<br>
>                     >         >             >         advantages:<br>
>                     >         >             ><br>
>                     >         >             >         - It reduces the<br>
>                     maintenance effort.<br>
>                     >         Fewer code<br>
>                     >         >             means fewer work.<br>
>                     >         >             >         - If you have<br>
>                     multiple driver for the<br>
>                     >         same or<br>
>                     >         >             similar hardware<br>
>                     >         >             >         it can<br>
>                     >         >             >         happen that a bug<br>
>                     is fixed in one but<br>
>                     >         not the other.<br>
>                     >         >             >         - It's simpler to<br>
>                     find a hardware to<br>
>                     >         test changes.<br>
>                     >         >             >         - The driver<br>
>                     becomes more universal with<br>
>                     >         every new<br>
>                     >         >             supported<br>
>                     >         >             >         hardware.<br>
>                     >         >             >         That increases the<br>
>                     chance that it fits<br>
>                     >         the next<br>
>                     >         >             new hardware.<br>
>                     >         >             ><br>
>                     >         >             >         I'm sure there are<br>
>                     some more if you ask<br>
>                     >         someone else.<br>
>                     >         >             ><br>
>                     >         >             >     I do understand the<br>
>                     issues, I just spent<br>
>                     >         some time<br>
>                     >         >             reading the<br>
>                     >         >             >     driver code.<br>
>                     >         >             >     I think we could most<br>
>                     probably use it. I<br>
>                     >         will take a<br>
>                     >         >             closer look and<br>
>                     >         >             >     will update.<br>
>                     >         >             ><br>
>                     >         ><br>
>                     >         >             Great.<br>
>                     >         ><br>
>                     >         >             >          <br>
>                     >         >             ><br>
>                     >         >             >         ><br>
>                     >         >             >         > Also, the core<br>
>                     clock on which the<br>
>                     >         PL011 is based<br>
>                     >         >             on is changed<br>
>                     >         >             >         in rpi3.<br>
>                     >         >             >         > Rpi1 and 2 use<br>
>                     250Mhz as the default<br>
>                     >         clock but<br>
>                     >         >             it was changed<br>
>                     >         >             >         to 400Mhz<br>
>                     >         >             >         > in Rpi3 and newer<br>
>                     >         >             ><br>
>                     >         >             >         Again: Would be<br>
>                     great if that could be<br>
>                     >         adapted<br>
>                     >         >             based on FDT or by<br>
>                     >         >             >         reading the right<br>
>                     registers.<br>
>                     >         >             ><br>
>                     >         >             >         ><br>
>                     >         >             >         > Few differences<br>
>                     between PL011 and Mini<br>
>                     >         uart<br>
>                     >         >             >         > The mini UART<br>
>                     has smaller FIFOs.<br>
>                     >         Combined with<br>
>                     >         >             the lack of<br>
>                     >         >             >         flow control,<br>
>                     >         >             >         > this makes it<br>
>                     more prone to losing<br>
>                     >         characters at<br>
>                     >         >             higher baud<br>
>                     >         >             >         rates. It<br>
>                     >         >             >         > is also<br>
>                     generally less capable than<br>
>                     >         the PL011,<br>
>                     >         >             mainly due to<br>
>                     >         >             >         its baud<br>
>                     >         >             >         > rate link to the<br>
>                     VPU clock speed.<br>
>                     >         >             ><br>
>                     >         >             >         That shouldn't<br>
>                     really be a problem for<br>
>                     >         the system<br>
>                     >         >             console.<br>
>                     >         >             ><br>
>                     >         >             >         ><br>
>                     >         >             >         > The particular<br>
>                     deficiencies of the<br>
>                     >         mini UART<br>
>                     >         >             compared to the<br>
>                     >         >             >         PL011 are :<br>
>                     >         >             >         ><br>
>                     >         >             >         > No break detection<br>
>                     >         >             >         > No framing<br>
>                     errors detection<br>
>                     >         >             >         > No parity bit<br>
>                     >         >             >         > No receive<br>
>                     timeout interrupt<br>
>                     >         >             >         > No DCD, DSR, DTR<br>
>                     or RI signals<br>
>                     >         >             >         ><br>
>                     >         >             ><br>
>                     >         >             >   <br>
>                      _______________________________________________<br>
>                     >         >             >     devel mailing list<br>
>                     >         >             >     <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>                     <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>                     <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>>><br>
>                     >         <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>                     <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>                     <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>>>><br>
>                     >         >             <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>                     <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>                     <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>>><br>
>                     >         <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>                     <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>                     <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>>>>><br>
>                     >         >             >   <br>
>                      <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>                     >         >             ><br>
>                     >         ><br>
>                     ><br>
> <br>
</blockquote></div></div>