<div dir="ltr"><div>Just to make sure I am going in the right track.</div><div>I moved the uart register definitions to bsp/usart.h into a struct of uint32_t called usart0_regs</div><div>here is git diff of usart.c after changing it to the latest console interface.</div><div><br></div><div>diff --git a/bsps/arm/raspberrypi/console/usart.c 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 *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 = (rtems_libio_open_close_args_t *) arg;<br>- struct rtems_termios_tty *tty = (struct rtems_termios_tty *) 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) == 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, 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 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></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 25, 2019 at 12:36 AM Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 24, 2019, 12:19 PM Niteesh <<a href="mailto:gsnb.gn@gmail.com" target="_blank">gsnb.gn@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">And also the register definitions are in raspberrpi.h file should I move them to usart.h.</div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Sounds right if you mean bsp/usart.h</div><div dir="auto"><br></div><div dir="auto"><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"><div dir="ltr"><div>I have a doubt we have a register field in device_contex<font face="arial, sans-serif">t</font></div><div>typedef struct { </div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>rtems_termios_device_context base; </div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>const char *device_name; </div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>volatile some_chip_registers *regs;</div></blockquote><div>} my_driver_context;<font face="arial, sans-serif"><br></font></div><div><br></div><div>How does the reg field point to the correct memory location? for instance in IMX BSP,</div><div>there is a struct with register field's but none of the define a memory location?</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Make sure the structure has volatiles and proper alignment. :)</div><div dir="auto"><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"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 24, 2019 at 11:37 PM Niteesh <<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">How to handle different serial devices? In other BSPs the uart devices are the same, so<div>they were able to put it under a single array? But here we have 2 uarts and a FB?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 24, 2019 at 8:18 PM Christian Mauderer <<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 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 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 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 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 want you can do<br>
that. But there might is a hurdle: As far as I understood you you only<br>
have a Pi3? So you might have a hard time testing the changes. Maybe the<br>
simulator could work.<br>
<br>
Another possibility could be to set the "Console_port_minor" to<br>
something unused (for example -1). In that case you 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 <<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a><br>
> <mailto:<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a>>> wrote:<br>
> <br>
> Thank you so much, for such a detailed answer. Now things make<br>
> really good sense to me, <br>
> going through the code now is just a breeze. But I still have one<br>
> question<br>
> for the newer driver interface is console_initialize the function<br>
> which RTEMS calls while initializing<br>
> the console? Which means I can't mess with the name right? It is<br>
> similar to the main function, right?<br>
> <br>
> The current driver is a legacy one, how do you want me to proceed,<br>
> shall I rewrite the legacy to a<br>
> the new one, this is will be a great learning experience for me also<br>
> and we also get the BSP updated to the latest interface.<br>
> <br>
> <br>
> On Tue, Dec 24, 2019 at 3:20 AM Christian Mauderer<br>
> <<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a>>> wrote:<br>
> <br>
> Hello Niteesh,<br>
> <br>
> quite a lot of questions. I'll try to answer them. Note that it<br>
> has been<br>
> some time since I had a detailed look at that code so if something I<br>
> tell seems odd please don't hesitate to question it.<br>
> <br>
> Please note that in RTEMS their are more or less two "levels" of<br>
> support<br>
> for a serial console:<br>
> <br>
> 1. A very basic polled system console (also known as<br>
> "debug-console" in<br>
> some BSPs). This one is used for printk and should work in basically<br>
> every case. It is used for critical system 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 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 Console_Configuration_Ports"<br>
> belongs<br>
> to a table based legacy interface. It is handled in the file<br>
> bsps/shared/dev/serial/legacy-console.c. I'm not sure whether it is<br>
> documented in the BSP guide because it shouldn't be used for new<br>
> BSPs.<br>
> Same is true for the "major" and "minor" stuff: It's not really<br>
> used for<br>
> new drivers.<br>
> <br>
> Newer drivers use the initialization that is described in the manual<br>
> that you have already found. Basically they use<br>
> "rtems_termios_device_install" to register a new UART as<br>
> "/dev/ttySomething". Some recent (ARM) BSPs that do that are the<br>
> imx or<br>
> the atsam.<br>
> <br>
> The console that is used for stdin, stdout and 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 one with the index of<br>
> "Console_Port_Minor".<br>
> <br>
> <br>
> If you want to access any UART other than the one for stdin and<br>
> stdout<br>
> you do that the same way like on Linux: Just use the "open"<br>
> function on<br>
> the "/dev/ttySomething" and use "read", "write" and simmilar or use<br>
> "fopen" together with "fread", "fwrite", "fprintf", ...<br>
> <br>
> <br>
> "printf" (and family) is a function belonging to the C library.<br>
> In our<br>
> case that's newlib. It will format your message and after some other<br>
> preprocessing will call the "write" function of the file that is<br>
> opened<br>
> as stdout (which is "/dev/console" in the default case).<br>
> <br>
> <br>
> I hope that I helped you with that 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 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 <<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a><br>
> <mailto:<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a>><br>
> > <mailto:<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a> <mailto:<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a>>>> wrote:<br>
> ><br>
> > Is the correct port minor number set 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" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a> <mailto:<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a>><br>
> > <mailto:<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a> <mailto:<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a>>>> wrote:<br>
> ><br>
> > I would like to clarify my doubts regarding the<br>
> console driver.<br>
> > I went through the documentation<br>
> > for the console<br>
> > <br>
> driver <a href="https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction" rel="noreferrer noreferrer" target="_blank">https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction</a>.<br>
> > But it is quite different from how some BSPs initialize.<br>
> > Correct me if I am wrong<br>
> > The console_tbl contains the various entries of serial<br>
> ports.<br>
> > The console_fns is a struct of function pointers,<br>
> which point to<br>
> > the BSP uart functions.<br>
> > The 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 uart? It's seems not to<br>
> be same<br>
> > for all BSPs.<br>
> > The doc says that the driver's initialization function<br>
> is called<br>
> > once during the rtems initialization process.<br>
> > The console init function install the serial driver using<br>
> > rtems_termios_device_install but there seems to be<br>
> > no such function in the raspberry pi? But there is a<br>
> entry in<br>
> > console_fns for init function, but then how does it<br>
> > gets called?<br>
> > And for BSP's with multiple serial's, the output function<br>
> > chooses the right serial using console_port_minor,<br>
> > Is it during initialization?<br>
> > What is the need for get and set register functions? <br>
> ><br>
> > On Mon, Dec 23, 2019 at 1:04 AM Christian Mauderer<br>
> > <<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a>><br>
> <mailto:<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a> <mailto:<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a>>>> wrote:<br>
> ><br>
> > On 22/12/2019 19:45, Joel Sherrill wrote:<br>
> > ><br>
> > ><br>
> > > On Sun, Dec 22, 2019, 12:29 PM Niteesh<br>
> <<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a> <mailto:<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a>><br>
> > <mailto:<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a> <mailto:<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a>>><br>
> > > <mailto:<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a><br>
> <mailto:<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a>> <mailto:<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a><br>
> <mailto:<a href="mailto:gsnb.gn@gmail.com" rel="noreferrer" target="_blank">gsnb.gn@gmail.com</a>>>>> wrote:<br>
> > ><br>
> > > On Sun, Dec 22, 2019 at 8:44 PM Christian<br>
> Mauderer<br>
> > > <<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a><br>
> <mailto:<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a>> <mailto:<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a><br>
> <mailto:<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a>>><br>
> > <mailto:<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a><br>
> <mailto:<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a>> <mailto:<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a><br>
> <mailto:<a href="mailto:list@c-mauderer.de" rel="noreferrer" target="_blank">list@c-mauderer.de</a>>>>> wrote:<br>
> > ><br>
> > > Hello Niteesh,<br>
> > ><br>
> > > thanks for doing that work.<br>
> > ><br>
> > > On 22/12/2019 12:10, Niteesh wrote:<br>
> > > > The rpi1 and rpi2 use the PL011 UART,<br>
> whereas,<br>
> > with RPI's<br>
> > > equipped with<br>
> > > > wireless/Bluetooth module, the PL011 is<br>
> > connected to the Bluetooth<br>
> > > > module, and the mini UART is used as<br>
> the primary<br>
> > UART.<br>
> > ><br>
> > > In my opinion it would be great if you<br>
> could use<br>
> > the FDT to<br>
> > > distinguish<br>
> > > between the boards. That should allow to add<br>
> > raspberry 3 (and<br>
> > > maybe 4)<br>
> > > support without adding another BSP. More<br>
> BSPs mean<br>
> > a bigger<br>
> > > maintenance<br>
> > > effort for the RTEMS community.<br>
> > ><br>
> > > Learning more about FDT is on my list for a long<br>
> > time. I would love<br>
> > > to work on that<br>
> > > but I have almost no exp with FDT's.<br>
> > > But another thing could also be done, in<br>
> > > raspberrypi/start/bspstart.c we get the<br>
> revision and<br>
> > > model of the board using the mailbox. Every<br>
> board has<br>
> > a unique id,<br>
> > > which we could use to initialize<br>
> > > the BSP. But using FDT seems to be a more<br>
> elegant<br>
> > option, it is a<br>
> > > lot of work I think, but we could take<br>
> > > help from libbsd and linux I suppose. What<br>
> do you think?<br>
> > ><br>
> > ><br>
> > > I think there are almost 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 read the board<br>
> revision and<br>
> > memory size,<br>
> > > you can get a working BSP that dynamically<br>
> adapts to the<br>
> > models and<br>
> > > memory variations with minimal modifications. If<br>
> you want<br>
> > to then<br>
> > > convert the BSP to FDT, it will be a LOT easier<br>
> to debug<br>
> > with a working BSP.<br>
> > ><br>
> > > Plus you may be able to identify every variation<br>
> point<br>
> > based on just the<br>
> > > model info. Then FDT is just a 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 development basis<br>
> (also<br>
> > known as "hack")<br>
> > as a first step is a good idea. You maybe even<br>
> just make the<br>
> > mini UART<br>
> > the default driver while you are developing. Then<br>
> you can be<br>
> > sure that<br>
> > you have the right driver.<br>
> ><br>
> > As soon as that works you can either change to the<br>
> revision<br>
> > method or<br>
> > (better) to the FDT one and after that the patches<br>
> can be<br>
> > merged. Using<br>
> > the FDT isn't that complicated. Basically you<br>
> search for a<br>
> > node based on<br>
> > different parameters. For an 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 UART driver is used.<br>
> But again:<br>
> > Follow<br>
> > Joels suggestion to start simple and secure.<br>
> ><br>
> > ><br>
> > > ><br>
> > > ><br>
> > > <br>
> > <br>
> <a href="https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf" rel="noreferrer noreferrer" target="_blank">https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf</a><br>
> > > > But from the above doc (PAGE 10), the<br>
> mini uart<br>
> > has 16550 like<br>
> > > registers<br>
> > > > and RTEMS already has the driver for it<br>
> > > > bsps/shared/dev/serial/ns16550.c. But<br>
> I am not<br>
> > sure how<br>
> > > compatible they<br>
> > > > are? Should a new driver be<br>
> implemented from<br>
> > scratch or use<br>
> > > ns16550 if<br>
> > > > possible?<br>
> > ><br>
> > > In general it's better to re-use<br>
> existing code.<br>
> > That has multiple<br>
> > > advantages:<br>
> > ><br>
> > > - It reduces the maintenance effort.<br>
> Fewer code<br>
> > means fewer work.<br>
> > > - If you have multiple driver for the<br>
> same or<br>
> > similar hardware<br>
> > > it can<br>
> > > happen that a bug is fixed in one but<br>
> not the other.<br>
> > > - It's simpler to find a hardware to<br>
> test changes.<br>
> > > - The driver becomes more universal with<br>
> every new<br>
> > supported<br>
> > > hardware.<br>
> > > That increases the chance that it fits<br>
> the next<br>
> > new hardware.<br>
> > ><br>
> > > I'm sure there are some more if you ask<br>
> someone else.<br>
> > ><br>
> > > I do understand the issues, I just spent<br>
> some time<br>
> > reading the<br>
> > > driver code.<br>
> > > I think we could most 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 on which the<br>
> PL011 is based<br>
> > on is changed<br>
> > > in rpi3.<br>
> > > > Rpi1 and 2 use 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 if that could be<br>
> adapted<br>
> > based on FDT or by<br>
> > > reading the right registers.<br>
> > ><br>
> > > ><br>
> > > > Few differences between PL011 and Mini<br>
> uart<br>
> > > > The mini UART has smaller FIFOs.<br>
> Combined with<br>
> > the lack of<br>
> > > flow control,<br>
> > > > this makes it more prone to losing<br>
> characters at<br>
> > higher baud<br>
> > > rates. It<br>
> > > > is also generally less capable than<br>
> the PL011,<br>
> > mainly due to<br>
> > > its baud<br>
> > > > rate link to the VPU clock speed.<br>
> > ><br>
> > > That shouldn't really be a problem for<br>
> the system<br>
> > console.<br>
> > ><br>
> > > ><br>
> > > > The particular deficiencies of the<br>
> mini UART<br>
> > compared to the<br>
> > > PL011 are :<br>
> > > ><br>
> > > > No break detection<br>
> > > > No framing errors detection<br>
> > > > No parity bit<br>
> > > > No receive timeout interrupt<br>
> > > > No DCD, DSR, DTR or RI signals<br>
> > > ><br>
> > ><br>
> > > _______________________________________________<br>
> > > devel mailing list<br>
> > > <a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a>><br>
> <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a>>><br>
> > <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a>><br>
> <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" rel="noreferrer" target="_blank">devel@rtems.org</a>>>><br>
> > > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> > ><br>
> ><br>
> <br>
</blockquote></div>
</blockquote></div>
</blockquote></div></div></div>
</blockquote></div></div>