<div dir="ltr"><div dir="ltr">On Fri, Dec 27, 2019 at 1:58 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">Hello Niteesh,<br>
<br>
sorry for not answering earlier. During this time of the year you have<br>
to expect some delays on the mailing list due to public holydays and<br>
vacations.</blockquote><div>That's okay, I understand. </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">
On 25/12/2019 10:50, Niteesh wrote:<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 of<br>
> uint32_t called usart0_regs<br>
> here is git diff of usart.c after changing it to the latest console<br>
> interface.<br>
<br>
Do you have a plan how you want to test these changes?<br>
<br>
The direction looks OK. Some notes below.<br>
<br>
By the way: Maybe it would be a better idea to just remove it completely<br>
and use the bsps/arm/shared/serial/arm-pl011.c driver instead? That<br>
reduces the ammount of code and therefore ammount of bugs we have in<br>
this BSP. </blockquote><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>
> 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>
Why uart0_context and not usart_context? All other names in this file<br>
are called usart_...<br>
<br></blockquote><div>Sorry, for the inconsistent naming, should I rename it as pl011_context since we will be adding</div><div>mini uart for rpi3, IMHO it would be better.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> +<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>
Why is this line commented now?<br></blockquote><div>It actually does nothing. The function body was empty. The current baud rate is set directly</div><div>in the initialization function. I was planning to update it once, I was finished with the interface. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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 = (rtems_libio_open_close_args_t *)<br>
> 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>
There is a return missing here. Did you compile the code? The compiler<br>
should give you a warning about that. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> }<br>
> <br>
> -static int usart_last_close(int major, int minor, void *arg)<br>
> +static int usart_last_close(<br>
<br>
The first_open returns a bool but last_close returns still an int? Is<br>
this correct? I don't have the interface memorized.<br></blockquote><div>last_close return type is void. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> + 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) == 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>
Just noted that here: Why rpi_uart_get_regs and not usart_get_regs?<br>
Please use a consitent naming scheme.<br>
<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, 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, const<br>
> 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? for<br>
> instance in IMX BSP,<br>
> there is a struct with register field's but none of the define a<br>
> 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 the<br>
> uart devices are the same, so<br>
> they were able to put it under a single array? But here we<br>
> 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 a<br>
> 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 and<br>
> 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 you<br>
> 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 the<br>
> 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 can<br>
> 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> <mailto:<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>>>><br>
> wrote:<br>
> ><br>
> > Thank you so much, for such a detailed answer. Now<br>
> things make<br>
> > really good sense to me, <br>
> > going through the code now is just a breeze. But I<br>
> 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> <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>
> wrote:<br>
> ><br>
> > Hello Niteesh,<br>
> ><br>
> > quite a lot of questions. I'll try to answer<br>
> them. Note that it<br>
> > has been<br>
> > some time since I had a detailed look at that<br>
> 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 or<br>
> less two "levels" of<br>
> > support<br>
> > for a serial console:<br>
> ><br>
> > 1. A very basic polled system console (also<br>
> known as<br>
> > "debug-console" in<br>
> > some BSPs). This one is used for printk and<br>
> 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 provide a<br>
> > "BSP_output_char" function.<br>
> ><br>
> > 2. A full featured UART driver integrated into<br>
> 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. I'm<br>
> 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 is<br>
> described in the manual<br>
> > that you have already found. Basically they use<br>
> > "rtems_termios_device_install" to register a<br>
> new UART as<br>
> > "/dev/ttySomething". Some recent (ARM) BSPs<br>
> that do that are the<br>
> > imx or<br>
> > the atsam.<br>
> ><br>
> > The console that is used for stdin, stdout and<br>
> stderr (printf,<br>
> > scanf,<br>
> > ...) is the one called "/dev/console" (defined in<br>
> > CONSOLE_DEVICE_NAME).<br>
> > For the legacy table based interface it's the<br>
> one with the index of<br>
> > "Console_Port_Minor".<br>
> ><br>
> ><br>
> > If you want to access any UART other than the<br>
> one for stdin and<br>
> > stdout<br>
> > you do that the same way like on Linux: Just<br>
> 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 belonging<br>
> 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" function<br>
> 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 a<br>
> 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> <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>> <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 doubts<br>
> 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 how<br>
> some BSPs initialize.<br>
> > > Correct me if I am wrong<br>
> > > The console_tbl contains the various<br>
> 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 BSP_output_char_function_type is<br>
> what will be<br>
> > called for<br>
> > > printing a char on to the console.<br>
> > > How does RTEMS initialize the uart?<br>
> 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 initialization<br>
> process.<br>
> > > The console init function install<br>
> the serial driver using<br>
> > > rtems_termios_device_install but<br>
> there seems to be<br>
> > > no such function in the raspberry<br>
> pi? But there is a<br>
> > entry in<br>
> > > console_fns for init function, but<br>
> 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>> <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>>>>> wrote:<br>
> > ><br>
> > > On 22/12/2019 19:45, Joel<br>
> Sherrill wrote:<br>
> > > ><br>
> > > ><br>
> > > > On Sun, Dec 22, 2019, 12:29 PM<br>
> 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> <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>>> <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>>>>>> wrote:<br>
> > > ><br>
> > > > On Sun, Dec 22, 2019 at<br>
> 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>>> <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><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 that<br>
> work.<br>
> > > ><br>
> > > > On 22/12/2019 12:10,<br>
> Niteesh wrote:<br>
> > > > > The rpi1 and rpi2<br>
> use the PL011 UART,<br>
> > whereas,<br>
> > > with RPI's<br>
> > > > equipped with<br>
> > > > > wireless/Bluetooth<br>
> module, the PL011 is<br>
> > > connected to the Bluetooth<br>
> > > > > module, and the mini<br>
> UART is used as<br>
> > the primary<br>
> > > UART.<br>
> > > ><br>
> > > > In my opinion it would<br>
> be great if you<br>
> > could use<br>
> > > the FDT to<br>
> > > > distinguish<br>
> > > > between the boards.<br>
> That should allow to add<br>
> > > raspberry 3 (and<br>
> > > > maybe 4)<br>
> > > > support without adding<br>
> another BSP. More<br>
> > BSPs mean<br>
> > > a bigger<br>
> > > > maintenance<br>
> > > > effort for the RTEMS<br>
> community.<br>
> > > ><br>
> > > > Learning more about FDT is<br>
> on my list for a long<br>
> > > time. I would love<br>
> > > > to work on that<br>
> > > > but I have almost no exp<br>
> with FDT's.<br>
> > > > But another thing could<br>
> also be done, in<br>
> > > > <br>
> raspberrypi/start/bspstart.c we get the<br>
> > revision and<br>
> > > > model of the board using<br>
> 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, but<br>
> we could take<br>
> > > > help from libbsd and linux<br>
> 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 code to<br>
> read the board<br>
> > revision and<br>
> > > memory size,<br>
> > > > you can get a working BSP that<br>
> dynamically<br>
> > adapts to the<br>
> > > models and<br>
> > > > memory variations with minimal<br>
> 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 just a<br>
> matter of<br>
> > switching the<br>
> > > source of<br>
> > > > some/all of the info.<br>
> > > ><br>
> > > > That would be my work plan anyway.<br>
> > ><br>
> > > I agree with Joel that a secure<br>
> development basis<br>
> > (also<br>
> > > known as "hack")<br>
> > > as a first step is a good idea.<br>
> You maybe even<br>
> > just make the<br>
> > > mini UART<br>
> > > the default driver while you are<br>
> developing. Then<br>
> > you can be<br>
> > > sure that<br>
> > > you have the right driver.<br>
> > ><br>
> > > As soon as that works you can<br>
> 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 complicated.<br>
> 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 simple<br>
> 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 above<br>
> doc (PAGE 10), the<br>
> > mini uart<br>
> > > has 16550 like<br>
> > > > registers<br>
> > > > > and RTEMS already<br>
> 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 new<br>
> driver be<br>
> > implemented from<br>
> > > scratch or use<br>
> > > > ns16550 if<br>
> > > > > possible?<br>
> > > ><br>
> > > > In general it's better<br>
> 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 multiple<br>
> driver for the<br>
> > same or<br>
> > > similar hardware<br>
> > > > it can<br>
> > > > happen that a bug is<br>
> fixed in one but<br>
> > not the other.<br>
> > > > - It's simpler to find<br>
> a hardware to<br>
> > test changes.<br>
> > > > - The driver becomes<br>
> 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 clock<br>
> 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 great<br>
> 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 has<br>
> smaller FIFOs.<br>
> > Combined with<br>
> > > the lack of<br>
> > > > flow control,<br>
> > > > > this makes it more<br>
> prone to losing<br>
> > characters at<br>
> > > higher baud<br>
> > > > rates. It<br>
> > > > > is also generally<br>
> less capable than<br>
> > the PL011,<br>
> > > mainly due to<br>
> > > > its baud<br>
> > > > > rate link to the VPU<br>
> clock speed.<br>
> > > ><br>
> > > > That shouldn't really<br>
> 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 errors<br>
> detection<br>
> > > > > No parity bit<br>
> > > > > No receive timeout<br>
> interrupt<br>
> > > > > No DCD, DSR, DTR or<br>
> 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>