Raspberrypi3: Mini UART driver
Niteesh
gsnb.gn at gmail.com
Fri Dec 27 09:45:57 UTC 2019
The changes I have made so far
diff --git a/bsps/arm/raspberrypi/console/console-config.c
b/bsps/arm/raspberrypi/console/console-config.c
index d2186c918b..d982b2c9c2 100644
--- a/bsps/arm/raspberrypi/console/console-config.c
+++ b/bsps/arm/raspberrypi/console/console-config.c
@@ -22,45 +22,53 @@
#include <libchip/serial.h>
-#include <bspopts.h>
#include <bsp/irq.h>
#include <bsp/usart.h>
#include <bsp/raspberrypi.h>
+#include <bsp/arm-pl011.h>
#include <bsp/fbcons.h>
-console_tbl Console_Configuration_Ports [] = {
- {
- .sDeviceName = "/dev/ttyS0",
- .deviceType = SERIAL_CUSTOM,
- .pDeviceFns = &bcm2835_usart_fns,
- .deviceProbe = NULL,
- .pDeviceFlow = NULL,
- .ulCtrlPort1 = BCM2835_UART0_BASE,
- .ulCtrlPort2 = 0,
- .ulClock = USART0_DEFAULT_BAUD,
- .ulIntVector = BCM2835_IRQ_ID_UART
- },
- {
- .sDeviceName ="/dev/fbcons",
- .deviceType = SERIAL_CUSTOM,
- .pDeviceFns = &fbcons_fns,
- .deviceProbe = fbcons_probe,
- .pDeviceFlow = NULL,
- },
+#include <bspopts.h>
+
+arm_pl011_context pl011_context = {
+ .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("PL011"),
+ .regs = (volatile pl011 *) BCM2835_PL011_BASE,
+ .initial_baud = PL011_DEFAULT_BAUD
};
-#define PORT_COUNT \
- (sizeof(Console_Configuration_Ports) \
- / sizeof(Console_Configuration_Ports [0]))
+rpi_fb_context fb_context = {
+ .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("FB")
+};
-unsigned long Console_Configuration_Count = PORT_COUNT;
+const console_device console_device_table[] = {
+ {
+ .device_file = "/dev/ttyS0",
+ .probe = console_device_probe_default,
+ .handler = &arm_pl011_fns,
+ .context = &pl011_context.base
+ },
+ {
+ .device_file = "/dev/fb0",
+ // Should be changed to fbcons_probe (but it still use old interface)
+ .probe = fbcons_probe,
+ .handler = &fbcons_fns,
+ .context = &fb_context.base
+ }
+}
+
+const size_t console_device_count = RTEMS_ARRAY_SIZE(console_device_table);
static void output_char(char c)
{
- const console_fns *con =
- Console_Configuration_Ports [Console_Port_Minor].pDeviceFns;
-
- con->deviceWritePolled((int) Console_Port_Minor, c);
+ switch(SERIAL){
+ case FB:
+ fbcons_write_polled(&fb_context.base, c);
+ break;
+ case PL011:
+ arm_pl011_write_polled(&pl011_context.base, c);
+ break;
+ }
+
}
BSP_output_char_function_type BSP_output_char = output_char;
diff --git a/bsps/arm/raspberrypi/console/console_select.c
b/bsps/arm/raspberrypi/console/console_select.c
index bd246ca868..dbca5c324f 100644
--- a/bsps/arm/raspberrypi/console/console_select.c
+++ b/bsps/arm/raspberrypi/console/console_select.c
@@ -15,7 +15,7 @@
* http://www.rtems.org/license/LICENSE
*
*/
-
+#include <bsp/raspberrypi.h>
#include <bsp.h>
#include <bsp/fatal.h>
#include <rtems/libio.h>
@@ -30,53 +30,7 @@
#include <bsp/rpi-fb.h>
rtems_device_minor_number BSPPrintkPort = 0;
-
-/*
- * Method to return true if the device associated with the
- * minor number probs available.
- */
-static bool bsp_Is_Available( rtems_device_minor_number minor )
-{
- console_tbl *cptr = Console_Port_Tbl[ minor ];
-
- /*
- * First perform the configuration dependent probe, then the
- * device dependent probe
- */
- if ( ( !cptr->deviceProbe || cptr->deviceProbe( minor ) ) &&
- cptr->pDeviceFns->deviceProbe( minor ) ) {
- return true;
- }
-
- return false;
-}
-
-/*
- * Method to return the first available device.
- */
-static rtems_device_minor_number bsp_First_Available_Device( void )
-{
- rtems_device_minor_number minor;
-
- for ( minor = 0; minor < Console_Port_Count; minor++ ) {
- console_tbl *cptr = Console_Port_Tbl[ minor ];
-
- /*
- * First perform the configuration dependent probe, then the
- * device dependent probe
- */
-
- if ( ( !cptr->deviceProbe || cptr->deviceProbe( minor ) ) &&
- cptr->pDeviceFns->deviceProbe( minor ) ) {
- return minor;
- }
- }
-
- /*
- * Error No devices were found. We will want to bail here.
- */
- bsp_fatal( BSP_FATAL_CONSOLE_NO_DEV );
-}
+CURRENT_SERIAL SERIAL = PL011;
void bsp_console_select( void )
{
@@ -90,25 +44,13 @@ void bsp_console_select( void )
*/
const char *opt;
- Console_Port_Minor = BSP_CONSOLE_UART0;
- BSPPrintkPort = BSP_CONSOLE_UART0;
-
opt = rpi_cmdline_get_arg( "--console=" );
if ( opt ) {
if ( strncmp( opt, "fbcons", sizeof( "fbcons" ) - 1 ) == 0 ) {
if ( rpi_video_is_initialized() > 0 ) {
- Console_Port_Minor = BSP_CONSOLE_FB;
- BSPPrintkPort = BSP_CONSOLE_FB;
+ SERIAL = FB;
}
}
}
-
- /*
- * If the device that was selected isn't available then
- * let the user know and select the first available device.
- */
- if ( !bsp_Is_Available( Console_Port_Minor ) ) {
- Console_Port_Minor = bsp_First_Available_Device();
- }
}
diff --git a/bsps/arm/raspberrypi/console/fbcons.c
b/bsps/arm/raspberrypi/console/fbcons.c
index 3669ba458d..26a694ac9f 100644
--- a/bsps/arm/raspberrypi/console/fbcons.c
+++ b/bsps/arm/raspberrypi/console/fbcons.c
@@ -18,6 +18,7 @@
#include <rtems.h>
#include <rtems/libio.h>
+#include <rtems/termiostypes.h>
#include <stdlib.h>
@@ -46,9 +47,10 @@ static void fbcons_init( int minor )
* Default state is 9600 baud, 8 bits, No parity, and 1 stop bit.
*/
static int fbcons_open(
- int major,
- int minor,
- void *arg
+ struct rtems_termios_tty *tty,
+ rtems_termios_device_context *base,
+ struct termios *term,
+ rtems_libio_open_close_args_t *args
)
{
return RTEMS_SUCCESSFUL;
@@ -60,9 +62,9 @@ static int fbcons_open(
* This function shuts down the requested port.
*/
static int fbcons_close(
- int major,
- int minor,
- void *arg
+ struct rtems_termios_tty *tty,
+ rtems_termios_device_context *base,
+ rtems_libio_open_close_args_t *args
)
{
return ( RTEMS_SUCCESSFUL );
@@ -73,8 +75,8 @@ static int fbcons_close(
*
* This routine polls out the requested character.
*/
-static void fbcons_write_polled(
- int minor,
+void fbcons_write_polled(
+ rtems_termios_device_context *base,
char c
)
{
@@ -91,7 +93,7 @@ static void fbcons_write_polled(
*
*/
static ssize_t fbcons_write_support_polled(
- int minor,
+ rtems_termios_device_context *base,
const char *buf,
size_t len
)
@@ -102,7 +104,7 @@ static ssize_t fbcons_write_support_polled(
* poll each byte in the string out of the port.
*/
while ( nwrite < len ) {
- fbcons_write_polled( minor, *buf++ );
+ fbcons_write_polled( base, *buf++ );
nwrite++;
}
@@ -117,7 +119,9 @@ static ssize_t fbcons_write_support_polled(
*
* Console Termios polling input entry point.
*/
-static int fbcons_inbyte_nonblocking_polled( int minor )
+static int fbcons_inbyte_nonblocking_polled(
+ rtems_termios_device_context *base,
+)
{
// if( rtems_kbpoll() ) {
// int c = getch();
@@ -134,14 +138,16 @@ static int fbcons_inbyte_nonblocking_polled( int
minor )
* port settings.
*/
static int fbcons_set_attributes(
- int minor,
+ rtems_termios_device_context *base,
const struct termios *t
)
{
return 0;
}
-bool fbcons_probe( int minor )
+bool fbcons_probe(
+ rtems_termios_device_context *base,
+)
{
// rtems_status_code status;
static bool firstTime = true;
@@ -163,15 +169,11 @@ bool fbcons_probe( int minor )
return ret;
}
-const console_fns fbcons_fns =
+const rtems_termios_device_handler fbcons_fns =
{
- .deviceProbe = libchip_serial_default_probe, /* deviceProbe */
- .deviceFirstOpen = fbcons_open, /* deviceFirstOpen */
- .deviceLastClose = fbcons_close, /* deviceLastClose */
- .deviceRead = fbcons_inbyte_nonblocking_polled, /* deviceRead */
- .deviceWrite = fbcons_write_support_polled, /* deviceWrite */
- .deviceInitialize = fbcons_init, /* deviceInitialize */
- .deviceWritePolled = fbcons_write_polled, /* deviceWritePolled */
- .deviceSetAttributes = fbcons_set_attributes, /* deviceSetAttributes */
- .deviceOutputUsesInterrupts = FALSE, /*
deviceOutputUsesInterrupts*/
-};
+ .first_open = fbcons_open,
+ .last_close = fbcons_close,
+ .poll_read = fbcons_inbyte_nonblocking_polled,
+ .write = fbcons_write_support_polled,
+ .mode = TERMIOS_POLLED
+};
\ No newline at end of file
diff --git a/bsps/arm/raspberrypi/console/usart.c
b/bsps/arm/raspberrypi/console/usart.c
index 25fb523621..471d0c553f 100644
--- a/bsps/arm/raspberrypi/console/usart.c
+++ b/bsps/arm/raspberrypi/console/usart.c
@@ -23,145 +23,3 @@
#include <bsp/usart.h>
#include <bsp/raspberrypi.h>
#include <rtems/bspIo.h>
-
-static void usart_delay(uint32_t n)
-{
- volatile uint32_t i = 0;
-
- for(i = 0; i < n; i++)
- ;
-}
-
-#if 0
-/*
- * These will be useful when the driver supports interrupt driven IO.
- */
-static rtems_vector_number usart_get_irq_number(const console_tbl *ct)
-{
- return ct->ulIntVector;
-}
-
-static uint32_t usart_get_baud(const console_tbl *ct)
-{
- return ct->ulClock;
-}
-#endif
-
-static void usart_set_baud(int minor, int baud)
-{
- /*
- * Nothing for now
- */
- return;
-}
-
-static void usart_initialize(int minor)
-{
- unsigned int gpio_reg;
-
- /*
- ** Program GPIO pins for UART 0
- */
- gpio_reg = BCM2835_REG(BCM2835_GPIO_GPFSEL1);
- gpio_reg &= ~(7<<12); /* gpio14 */
- gpio_reg |= (4<<12); /* alt0 */
- gpio_reg &= ~(7<<15); /* gpio15 */
- gpio_reg |= (4<<15); /* alt0 */
- BCM2835_REG(BCM2835_GPIO_GPFSEL1) = gpio_reg;
-
- BCM2835_REG(BCM2835_GPIO_GPPUD) = 0;
- usart_delay(150);
- BCM2835_REG(BCM2835_GPIO_GPPUDCLK0) = (1<<14)|(1<<15);
- usart_delay(150);
- BCM2835_REG(BCM2835_GPIO_GPPUDCLK0) = 0;
-
- /*
- ** Init the PL011 UART
- */
- BCM2835_REG(BCM2835_UART0_CR) = 0;
- BCM2835_REG(BCM2835_UART0_ICR) = 0x7FF;
- BCM2835_REG(BCM2835_UART0_IMSC) = 0;
- BCM2835_REG(BCM2835_UART0_IBRD) = 1;
- BCM2835_REG(BCM2835_UART0_FBRD) = 40;
- BCM2835_REG(BCM2835_UART0_LCRH) = 0x70;
- BCM2835_REG(BCM2835_UART0_RSRECR) = 0;
-
- BCM2835_REG(BCM2835_UART0_CR) = 0x301;
-
- BCM2835_REG(BCM2835_UART0_IMSC) = BCM2835_UART0_IMSC_RX;
-
- usart_set_baud(minor, 115000);
-}
-
-static int usart_first_open(int major, int minor, void *arg)
-{
- rtems_libio_open_close_args_t *oc = (rtems_libio_open_close_args_t *)
arg;
- struct rtems_termios_tty *tty = (struct rtems_termios_tty *)
oc->iop->data1;
- const console_tbl *ct = Console_Port_Tbl [minor];
- console_data *cd = &Console_Port_Data [minor];
-
- cd->termios_data = tty;
- rtems_termios_set_initial_baud(tty, ct->ulClock);
-
- return 0;
-}
-
-static int usart_last_close(int major, int minor, void *arg)
-{
- return 0;
-}
-
-static int usart_read_polled(int minor)
-{
- if (minor == 0) {
- if (((BCM2835_REG(BCM2835_UART0_FR)) & BCM2835_UART0_FR_RXFE) == 0) {
- return((BCM2835_REG(BCM2835_UART0_DR)) & 0xFF );
- } else {
- return -1;
- }
- } else {
- printk("Unknown console minor number: %d\n", minor);
- return -1;
- }
-}
-
-static void usart_write_polled(int minor, char c)
-{
- while (1) {
- if ((BCM2835_REG(BCM2835_UART0_FR) & BCM2835_UART0_FR_TXFF) == 0)
- break;
- }
- BCM2835_REG(BCM2835_UART0_DR) = c;
-}
-
-static ssize_t usart_write_support_polled(
- int minor,
- const char *s,
- size_t n
-)
-{
- ssize_t i = 0;
-
- for (i = 0; i < n; ++i) {
- usart_write_polled(minor, s [i]);
- }
-
- return n;
-}
-
-static int usart_set_attributes(int minor, const struct termios *term)
-{
- return -1;
-}
-
-const console_fns bcm2835_usart_fns = {
- .deviceProbe = libchip_serial_default_probe,
- .deviceFirstOpen = usart_first_open,
- .deviceLastClose = usart_last_close,
- .deviceRead = usart_read_polled,
- .deviceWrite = usart_write_support_polled,
- .deviceInitialize = usart_initialize,
- .deviceWritePolled = usart_write_polled,
- .deviceSetAttributes = usart_set_attributes,
- .deviceOutputUsesInterrupts = false
-};
diff --git a/bsps/arm/raspberrypi/include/bsp/fbcons.h
b/bsps/arm/raspberrypi/include/bsp/fbcons.h
index d0e126699a..f2ff25dc63 100644
--- a/bsps/arm/raspberrypi/include/bsp/fbcons.h
+++ b/bsps/arm/raspberrypi/include/bsp/fbcons.h
@@ -33,12 +33,23 @@ extern "C" {
#define FB_CONSOLE 0x50492835
-bool fbcons_probe( int minor );
+bool fbcons_probe(
+ rtems_termios_device_context *base,
+ );
+
+void fbcons_write_polled(
+ rtems_termios_device_context *base,
+ char c
+);
+
+typedef struct {
+ rtems_termios_device_context base;
+} rpi_fb_context ;
/*
* Driver function table
*/
-extern const console_fns fbcons_fns;
+extern const rtems_termios_device_handler fbcons_fns;
#ifdef __cplusplus
}
diff --git a/bsps/arm/raspberrypi/include/bsp/raspberrypi.h
b/bsps/arm/raspberrypi/include/bsp/raspberrypi.h
index 40c80cf408..4e5c84c741 100644
--- a/bsps/arm/raspberrypi/include/bsp/raspberrypi.h
+++ b/bsps/arm/raspberrypi/include/bsp/raspberrypi.h
@@ -60,6 +60,22 @@
#define RPI_PERIPHERAL_SIZE 0x01000000
+/**
+ * @name Current Serial Device
+ *
+ * @{
+ */
+
+typedef enum {
+ PL011 = 0,
+ AUX_UART,
+ FB
+}CURRENT_SERIAL;
+
+extern CURRENT_SERIAL SERIAL;
+
+/** @} */
+
/**
* @name Internal ARM Timer Registers
*
@@ -184,42 +200,6 @@
/** @} */
-/**
- * @name UART 0 (PL011) Registers
- *
- * @{
- */
-
-#define BCM2835_UART0_BASE (RPI_PERIPHERAL_BASE + 0x201000)
-
-#define BCM2835_UART0_DR (BCM2835_UART0_BASE + 0x00)
-#define BCM2835_UART0_RSRECR (BCM2835_UART0_BASE + 0x04)
-#define BCM2835_UART0_FR (BCM2835_UART0_BASE + 0x18)
-#define BCM2835_UART0_ILPR (BCM2835_UART0_BASE + 0x20)
-#define BCM2835_UART0_IBRD (BCM2835_UART0_BASE + 0x24)
-#define BCM2835_UART0_FBRD (BCM2835_UART0_BASE + 0x28)
-#define BCM2835_UART0_LCRH (BCM2835_UART0_BASE + 0x2C)
-#define BCM2835_UART0_CR (BCM2835_UART0_BASE + 0x30)
-#define BCM2835_UART0_IFLS (BCM2835_UART0_BASE + 0x34)
-#define BCM2835_UART0_IMSC (BCM2835_UART0_BASE + 0x38)
-#define BCM2835_UART0_RIS (BCM2835_UART0_BASE + 0x3C)
-#define BCM2835_UART0_MIS (BCM2835_UART0_BASE + 0x40)
-#define BCM2835_UART0_ICR (BCM2835_UART0_BASE + 0x44)
-#define BCM2835_UART0_DMACR (BCM2835_UART0_BASE + 0x48)
-#define BCM2835_UART0_ITCR (BCM2835_UART0_BASE + 0x80)
-#define BCM2835_UART0_ITIP (BCM2835_UART0_BASE + 0x84)
-#define BCM2835_UART0_ITOP (BCM2835_UART0_BASE + 0x88)
-#define BCM2835_UART0_TDR (BCM2835_UART0_BASE + 0x8C)
-
-#define BCM2835_UART0_MIS_RX 0x10
-#define BCM2835_UART0_MIS_TX 0x20
-#define BCM2835_UART0_IMSC_RX 0x10
-#define BCM2835_UART0_IMSC_TX 0x20
-#define BCM2835_UART0_FR_RXFE 0x10
-#define BCM2835_UART0_FR_TXFF 0x20
-#define BCM2835_UART0_ICR_RX 0x10
-#define BCM2835_UART0_ICR_TX 0x20
-
/** @} */
/**
diff --git a/bsps/arm/raspberrypi/include/bsp/usart.h
b/bsps/arm/raspberrypi/include/bsp/usart.h
index d3e710c5e9..abbf53626c 100644
--- a/bsps/arm/raspberrypi/include/bsp/usart.h
+++ b/bsps/arm/raspberrypi/include/bsp/usart.h
@@ -32,9 +32,8 @@
extern "C" {
#endif /* __cplusplus */
-#define USART0_DEFAULT_BAUD 115000
-
-extern const console_fns bcm2835_usart_fns;
+#define PL011_DEFAULT_BAUD 115000
+#define BCM2835_PL011_BASE (RPI_PERIPHERAL_BASE + 0x201000)
#ifdef __cplusplus
}
On Fri, Dec 27, 2019 at 3:12 PM Niteesh <gsnb.gn at gmail.com> wrote:
> On Fri, Dec 27, 2019 at 2:53 PM Christian Mauderer <list at c-mauderer.de>
> wrote:
>
>> Hello Niteesh,
>>
>> let me repeat two important questions:
>>
>> - How do you plan to test the changes? Simulator is OK for me but
>> untested is not OK.
>>
> Since I don't have the older pi's, the simulator will be my only option.
> And did you
> take a look at the exception?
>
>>
>> - Isn't it possible to just use the driver from
>> bsps/arm/shared/serial/arm-pl011.c and remove the BSP specific completely?
>>
> Yes, I have done this. I usart.c file is now completely empty. All we have
> to define was
> the start address for the PL011 peripheral in usart.h.
>
>>
>> On 27/12/2019 06:29, Niteesh wrote:
>> > On Fri, Dec 27, 2019 at 1:58 AM Christian Mauderer <list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>> wrote:
>> >
>> > Hello Niteesh,
>> >
>> > sorry for not answering earlier. During this time of the year you
>> have
>> > to expect some delays on the mailing list due to public holydays and
>> > vacations.
>> >
>> > That's okay, I understand.
>> >
>> >
>> >
>> > On 25/12/2019 10:50, Niteesh wrote:
>> > > Just to make sure I am going in the right track.
>> > > I moved the uart register definitions to bsp/usart.h into a
>> struct of
>> > > uint32_t called usart0_regs
>> > > here is git diff of usart.c after changing it to the latest
>> console
>> > > interface.
>> >
>> > Do you have a plan how you want to test these changes?
>> >
>> > The direction looks OK. Some notes below.
>> >
>> > By the way: Maybe it would be a better idea to just remove it
>> completely
>> > and use the bsps/arm/shared/serial/arm-pl011.c driver instead? That
>> > reduces the ammount of code and therefore ammount of bugs we have in
>> > this BSP.
>> >
>> >
>> >
>> > >
>> > > diff --git a/bsps/arm/raspberrypi/console/usart.c
>> > > b/bsps/arm/raspberrypi/console/usart.c
>> > > index 25fb523621..b12f375a1c 100644
>> > > --- a/bsps/arm/raspberrypi/console/usart.c
>> > > +++ b/bsps/arm/raspberrypi/console/usart.c
>> > > @@ -47,6 +47,12 @@ static uint32_t usart_get_baud(const
>> > console_tbl *ct)
>> > > }
>> > > #endif
>> > >
>> > > +typedef struct {
>> > > + rtems_termios_device_context base;
>> > > + const char *device_name;
>> > > + volatile usart0_regs *regs;
>> > > +}uart0_context;
>> >
>> > Why uart0_context and not usart_context? All other names in this
>> file
>> > are called usart_...
>> >
>> > Sorry, for the inconsistent naming, should I rename it as pl011_context
>> > since we will be adding
>> > mini uart for rpi3, IMHO it would be better.
>>
>> If you touch nearly all locations where the name is used: Yes. But
>> again: There is already a generic pl011 driver. Use that driver if
>> possible.
>>
>> >
>> > > +
>> > > static void usart_set_baud(int minor, int baud)
>> > > {
>> > > /*
>> > > @@ -55,10 +61,17 @@ static void usart_set_baud(int minor, int
>> baud)
>> > > return;
>> > > }
>> > >
>> > > -static void usart_initialize(int minor)
>> > > +static volatile usart0_regs
>> > > *rpi_uart_get_regs(rtems_termios_device_context *base)
>> > > {
>> > > - unsigned int gpio_reg;
>> > > + uart0_context *ctx;
>> > > +
>> > > + ctx = (usart0_regs *) base;
>> > > + return ctx->regs;
>> > > +}
>> > >
>> > > +static void usart_initialize(rtems_termios_device_context *base)
>> > > +{
>> > > + unsigned int gpio_reg;
>> > > /*
>> > > ** Program GPIO pins for UART 0
>> > > */
>> > > @@ -75,67 +88,81 @@ static void usart_initialize(int minor)
>> > > usart_delay(150);
>> > > BCM2835_REG(BCM2835_GPIO_GPPUDCLK0) = 0;
>> > >
>> > > + volatile uint32_t *uart_regs = rpi_uart_get_regs(base);
>> > > +
>> > > /*
>> > > ** Init the PL011 UART
>> > > */
>> > > - BCM2835_REG(BCM2835_UART0_CR) = 0;
>> > > - BCM2835_REG(BCM2835_UART0_ICR) = 0x7FF;
>> > > - BCM2835_REG(BCM2835_UART0_IMSC) = 0;
>> > > - BCM2835_REG(BCM2835_UART0_IBRD) = 1;
>> > > - BCM2835_REG(BCM2835_UART0_FBRD) = 40;
>> > > - BCM2835_REG(BCM2835_UART0_LCRH) = 0x70;
>> > > - BCM2835_REG(BCM2835_UART0_RSRECR) = 0;
>> > > -
>> > > - BCM2835_REG(BCM2835_UART0_CR) = 0x301;
>> > > -
>> > > - BCM2835_REG(BCM2835_UART0_IMSC) = BCM2835_UART0_IMSC_RX;
>> > > -
>> > > - usart_set_baud(minor, 115000);
>> > > + uart_regs->cr = 0;
>> > > + uart_regs->icr = 0x7ff;
>> > > + uart_regs->imsc = 0;
>> > > + uart_regs->ibrd = 1;
>> > > + uart_regs->fbrd= 40;
>> > > + uart_regs->lcrh= 0x70;
>> > > + uart_regs->rsrecr= 0;
>> > > + uart_regs->cr = 0x301;
>> > > + uart_regs->imsc = BCM2835_UART0_IMSC_RX;
>> > > + // usart_set_baud(minor, 115000);
>> >
>> > Why is this line commented now?
>> >
>> > It actually does nothing. The function body was empty. The current baud
>> > rate is set directly
>> > in the initialization function. I was planning to update it once, I was
>> > finished with the interface.
>> >
>>
>> If it is empty: Is it necessary? There is a
>> rtems_termios_set_initial_baud(...) which should do the same.
>>
>> >
>> > > }
>> > >
>> > > -static int usart_first_open(int major, int minor, void *arg)
>> > > +static bool usart_first_open(
>> > > + rtems_termios_tty *tty,
>> > > + rtems_termios_device_context *base,
>> > > + struct termios *term,
>> > > + rtems_libio_open_close_args_t *args
>> > > +)
>> > > {
>> > > - rtems_libio_open_close_args_t *oc =
>> > (rtems_libio_open_close_args_t *)
>> > > arg;
>> > > - struct rtems_termios_tty *tty = (struct rtems_termios_tty *)
>> > > oc->iop->data1;
>> > > - const console_tbl *ct = Console_Port_Tbl [minor];
>> > > - console_data *cd = &Console_Port_Data [minor];
>> > > + rtems_status_code sc;
>> > > + uart0_context *ctx;
>> > > + bool ok;
>> > >
>> > > - cd->termios_data = tty;
>> > > - rtems_termios_set_initial_baud(tty, ct->ulClock);
>> > > + ctx = (uart0_context *) base;
>> > >
>> > > - return 0;
>> > > + usart_initialize(base);
>> > > +
>> > > + sc = rtems_termios_set_initial_baud(tty, USART0_DEFAULT_BAUD);
>> > > + if ( sc != RTEMS_SUCCESSFUL ){
>> > > + printk("Error setting the baud for termios\n");
>> > > + return false;
>> > > + }
>> >
>> > There is a return missing here. Did you compile the code? The
>> compiler
>> > should give you a warning about that.
>> >
>> > > }
>> > >
>> > > -static int usart_last_close(int major, int minor, void *arg)
>> > > +static int usart_last_close(
>> >
>> > The first_open returns a bool but last_close returns still an int?
>> Is
>> > this correct? I don't have the interface memorized.
>> >
>> > last_close return type is void.
>>
>> Then you should fix that here.
>>
>> >
>> >
>> > > + rtems_termios_tty *tty,
>> > > + rtems_termios_device_context *base,
>> > > + rtems_termios_open_close_args_t *arg)
>> > > {
>> > > return 0;
>> > > }
>> > >
>> > > -static int usart_read_polled(int minor)
>> > > +static int usart_read_polled(rtems_termios_device_context *base)
>> > > {
>> > > - if (minor == 0) {
>> > > - if (((BCM2835_REG(BCM2835_UART0_FR)) & BCM2835_UART0_FR_RXFE)
>> > == 0) {
>> > > - return((BCM2835_REG(BCM2835_UART0_DR)) & 0xFF );
>> > > - } else {
>> > > - return -1;
>> > > - }
>> > > - } else {
>> > > - printk("Unknown console minor number: %d\n", minor);
>> > > - return -1;
>> > > + volatile usart0_regs *regs;
>> > > +
>> > > + regs = rpi_uart_get_regs(base);
>> >
>> > Just noted that here: Why rpi_uart_get_regs and not usart_get_regs?
>> > Please use a consitent naming scheme.
>> >
>> > > +
>> > > + if ((regs->fr & BCM2835_UART0_FR_RXFE) == 0) {
>> > > + return (regs->dr & 0xFF);
>> > > }
>> > > +
>> > > + return -1;
>> > > }
>> > >
>> > > -static void usart_write_polled(int minor, char c)
>> > > +static void usart_write_polled(rtems_termios_device_context
>> > *base, char c)
>> > > {
>> > > - while (1) {
>> > > - if ((BCM2835_REG(BCM2835_UART0_FR) & BCM2835_UART0_FR_TXFF)
>> > == 0)
>> > > - break;
>> > > - }
>> > > - BCM2835_REG(BCM2835_UART0_DR) = c;
>> > > + volatile usart0_regs *regs;
>> > > +
>> > > + regs = rpi_uart_get_regs(base);
>> > > +
>> > > + while (1) {
>> > > + if (((regs->fr) & BCM2835_UART0_FR_TXFF) == 0)
>> > > + break;
>> > > + }
>> > > + regs->dr = c;
>> > > }
>> > >
>> > > static ssize_t usart_write_support_polled(
>> > > - int minor,
>> > > + rtems_termios_device_context *base,
>> > > const char *s,
>> > > size_t n
>> > > )
>> > > @@ -143,7 +170,7 @@ static ssize_t usart_write_support_polled(
>> > > ssize_t i = 0;
>> > >
>> > > for (i = 0; i < n; ++i) {
>> > > - usart_write_polled(minor, s [i]);
>> > > + usart_write_polled(base, s[i]);
>> > > }
>> > >
>> > > return n;
>> > > @@ -154,14 +181,11 @@ static int usart_set_attributes(int minor,
>> const
>> > > struct termios *term)
>> > > return -1;
>> > > }
>> > >
>> > > -const console_fns bcm2835_usart_fns = {
>> > > - .deviceProbe = libchip_serial_default_probe,
>> > > - .deviceFirstOpen = usart_first_open,
>> > > - .deviceLastClose = usart_last_close,
>> > > - .deviceRead = usart_read_polled,
>> > > - .deviceWrite = usart_write_support_polled,
>> > > - .deviceInitialize = usart_initialize,
>> > > - .deviceWritePolled = usart_write_polled,
>> > > - .deviceSetAttributes = usart_set_attributes,
>> > > - .deviceOutputUsesInterrupts = false
>> > > -};
>> > > +const rtems_termios_device_handler bcm2835_uart0_handler_polled
>> = {
>> > > + .first_open = usart_first_open,
>> > > + .last_close = usart_last_close,
>> > > + .poll_read = usart_read_polled,
>> > > + .set_attributes = usart_set_attributes,
>> > > + .write = usart_write_support_polled,
>> > > + .mode = TERMIOS_POLLED
>> > > +}
>> > > \ No newline at end of file
>> > >
>> > > On Wed, Dec 25, 2019 at 12:36 AM Joel Sherrill <joel at rtems.org
>> > <mailto:joel at rtems.org>
>> > > <mailto:joel at rtems.org <mailto:joel at rtems.org>>> wrote:
>> > >
>> > >
>> > >
>> > > On Tue, Dec 24, 2019, 12:19 PM Niteesh <gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com <mailto:gsnb.gn at gmail.com>>> wrote:
>> > >
>> > > And also the register definitions are in raspberrpi.h file
>> > > should I move them to usart.h.
>> > >
>> > >
>> > > Sounds right if you mean bsp/usart.h
>> > >
>> > > I have a doubt we have a register field in device_context
>> > > typedef struct {
>> > >
>> > > rtems_termios_device_context base;
>> > >
>> > > const char *device_name;
>> > >
>> > > volatile some_chip_registers *regs;
>> > >
>> > > } my_driver_context;
>> > >
>> > > How does the reg field point to the correct
>> > memory location? for
>> > > instance in IMX BSP,
>> > > there is a struct with register field's but none of the
>> > define a
>> > > memory location?
>> > >
>> > >
>> > > Make sure the structure has volatiles and proper alignment. :)
>> > >
>> > >
>> > > On Tue, Dec 24, 2019 at 11:37 PM Niteesh
>> > <gsnb.gn at gmail.com <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com <mailto:gsnb.gn at gmail.com>>>
>> wrote:
>> > >
>> > > How to handle different serial devices? In other BSPs
>> the
>> > > uart devices are the same, so
>> > > they were able to put it under a single array? But
>> here we
>> > > have 2 uarts and a FB?
>> > >
>> > >
>> > > On Tue, Dec 24, 2019 at 8:18 PM Christian Mauderer
>> > > <list at c-mauderer.de <mailto:list at c-mauderer.de>
>> > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>> wrote:
>> > >
>> > > On 24/12/2019 12:06, Niteesh wrote:
>> > > > The current raspi console section is like this:
>> > > > The bsp_console_select in console_select.c is
>> > > responsible for selecting
>> > > > between uart and the framebuffer. It does so
>> > > > by setting the Console_port_minor.
>> > > > The console_config is responsible for
>> output_char
>> > > function.
>> > > > And other files are driver code.
>> > > > If rewriting, this would be my approach,
>> > > > Rewrite the bsp_console_select to set some kind
>> of a
>> > > variable like in
>> > > > IMX, then in console_initialize function
>> > > > link the right driver to /dev/console.
>> > > > Replace the console_tbl with the device_context
>> and
>> > > console_fns with
>> > > > termios_device_handlers and
>> > > > finally add in the console_initialization
>> function.
>> > >
>> > > I agree that this would be a clean solution. So
>> if you
>> > > want you can do
>> > > that. But there might is a hurdle: As far as I
>> > > understood you you only
>> > > have a Pi3? So you might have a hard time testing
>> the
>> > > changes. Maybe the
>> > > simulator could work.
>> > >
>> > > Another possibility could be to set the
>> > > "Console_port_minor" to
>> > > something unused (for example -1). In that case
>> > you can
>> > > define another
>> > > /dev/console.
>> > >
>> > > Best regards and merry Christmas (in case you
>> > celebrate)
>> > >
>> > > Christian
>> > >
>> > > >
>> > > > On Tue, Dec 24, 2019 at 2:13 PM Niteesh
>> > > <gsnb.gn at gmail.com <mailto:gsnb.gn at gmail.com>
>> > <mailto:gsnb.gn at gmail.com <mailto:gsnb.gn at gmail.com>>
>> > > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com> <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>>>
>> > > wrote:
>> > > >
>> > > > Thank you so much, for such a detailed
>> > answer. Now
>> > > things make
>> > > > really good sense to me,
>> > > > going through the code now is just a breeze.
>> > But I
>> > > still have one
>> > > > question
>> > > > for the newer driver interface is
>> > > console_initialize the function
>> > > > which RTEMS calls while initializing
>> > > > the console? Which means I can't mess with
>> the
>> > > name right? It is
>> > > > similar to the main function, right?
>> > > >
>> > > > The current driver is a legacy one, how do
>> you
>> > > want me to proceed,
>> > > > shall I rewrite the legacy to a
>> > > > the new one, this is will be a great
>> > > learning experience for me also
>> > > > and we also get the BSP updated to the
>> latest
>> > > interface.
>> > > >
>> > > >
>> > > > On Tue, Dec 24, 2019 at 3:20 AM Christian
>> > Mauderer
>> > > > <list at c-mauderer.de
>> > <mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de> <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>>>
>> > > wrote:
>> > > >
>> > > > Hello Niteesh,
>> > > >
>> > > > quite a lot of questions. I'll try to
>> answer
>> > > them. Note that it
>> > > > has been
>> > > > some time since I had a detailed look at
>> > that
>> > > code so if something I
>> > > > tell seems odd please don't hesitate to
>> > > question it.
>> > > >
>> > > > Please note that in RTEMS their are
>> more or
>> > > less two "levels" of
>> > > > support
>> > > > for a serial console:
>> > > >
>> > > > 1. A very basic polled system console
>> (also
>> > > known as
>> > > > "debug-console" in
>> > > > some BSPs). This one is used for printk
>> and
>> > > should work in basically
>> > > > every case. It is used for critical
>> system
>> > > messages like
>> > > > printing the
>> > > > exception frame. For that a BSP has to
>> > provide a
>> > > > "BSP_output_char" function.
>> > > >
>> > > > 2. A full featured UART driver
>> > integrated into
>> > > Termios. That one
>> > > > will be
>> > > > used for all normal I/O on the UARTs.
>> > > >
>> > > > As far as I know the "console_tbl
>> > > Console_Configuration_Ports"
>> > > > belongs
>> > > > to a table based legacy interface. It is
>> > > handled in the file
>> > > >
>> bsps/shared/dev/serial/legacy-console.c. I'm
>> > > not sure whether it is
>> > > > documented in the BSP guide because it
>> > > shouldn't be used for new
>> > > > BSPs.
>> > > > Same is true for the "major" and "minor"
>> > > stuff: It's not really
>> > > > used for
>> > > > new drivers.
>> > > >
>> > > > Newer drivers use the initialization
>> that is
>> > > described in the manual
>> > > > that you have already found. Basically
>> > they use
>> > > > "rtems_termios_device_install" to
>> register a
>> > > new UART as
>> > > > "/dev/ttySomething". Some recent (ARM)
>> BSPs
>> > > that do that are the
>> > > > imx or
>> > > > the atsam.
>> > > >
>> > > > The console that is used for stdin,
>> > stdout and
>> > > stderr (printf,
>> > > > scanf,
>> > > > ...) is the one called "/dev/console"
>> > (defined in
>> > > > CONSOLE_DEVICE_NAME).
>> > > > For the legacy table based interface
>> > it's the
>> > > one with the index of
>> > > > "Console_Port_Minor".
>> > > >
>> > > >
>> > > > If you want to access any UART other
>> > than the
>> > > one for stdin and
>> > > > stdout
>> > > > you do that the same way like on Linux:
>> Just
>> > > use the "open"
>> > > > function on
>> > > > the "/dev/ttySomething" and use "read",
>> > > "write" and simmilar or use
>> > > > "fopen" together with "fread", "fwrite",
>> > > "fprintf", ...
>> > > >
>> > > >
>> > > > "printf" (and family) is a function
>> > belonging
>> > > to the C library.
>> > > > In our
>> > > > case that's newlib. It will format your
>> > > message and after some other
>> > > > preprocessing will call the "write"
>> function
>> > > of the file that is
>> > > > opened
>> > > > as stdout (which is "/dev/console" in
>> the
>> > > default case).
>> > > >
>> > > >
>> > > > I hope that I helped you with that
>> > > explanation. Please feel free
>> > > > to ask
>> > > > anything if it isn't clear.
>> > > >
>> > > > Best regards
>> > > >
>> > > > Christian
>> > > >
>> > > > On 23/12/2019 19:50, Niteesh wrote:
>> > > > > And finally, how does printf work? It
>> is a
>> > > macro? In that
>> > > > case, how does
>> > > > > any write to
>> > > > > a console work?
>> > > > >
>> > > > > On Tue, Dec 24, 2019 at 12:18 AM
>> Niteesh
>> > > <gsnb.gn at gmail.com <mailto:gsnb.gn at gmail.com>
>> > <mailto:gsnb.gn at gmail.com <mailto:gsnb.gn at gmail.com>>
>> > > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com <mailto:
>> gsnb.gn at gmail.com>>>
>> > > > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>> <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>>>> wrote:
>> > > > >
>> > > > > Is the correct port minor number
>> set
>> > > during the
>> > > > initialization? What
>> > > > > is the application want's to
>> > > > > access some other port?
>> > > > >
>> > > > > On Tue, Dec 24, 2019 at 12:16 AM
>> > Niteesh
>> > > > <gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com> <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>
>> > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com> <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>>
>> > > > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>> <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>>>> wrote:
>> > > > >
>> > > > > I would like to clarify my
>> doubts
>> > > regarding the
>> > > > console driver.
>> > > > > I went through the
>> documentation
>> > > > > for the console
>> > > > >
>> > > >
>> > >
>> > driver
>> https://docs.rtems.org/branches/master/bsp-howto/console.html#introduction
>> .
>> > > > > But it is quite different
>> from how
>> > > some BSPs initialize.
>> > > > > Correct me if I am wrong
>> > > > > The console_tbl contains the
>> > various
>> > > entries of serial
>> > > > ports.
>> > > > > The console_fns is a struct of
>> > > function pointers,
>> > > > which point to
>> > > > > the BSP uart functions.
>> > > > > The
>> > BSP_output_char_function_type is
>> > > what will be
>> > > > called for
>> > > > > printing a char on to the
>> console.
>> > > > > How does RTEMS initialize the
>> > uart?
>> > > It's seems not to
>> > > > be same
>> > > > > for all BSPs.
>> > > > > The doc says that the driver's
>> > > initialization function
>> > > > is called
>> > > > > once during the rtems
>> > initialization
>> > > process.
>> > > > > The console init function
>> install
>> > > the serial driver using
>> > > > > rtems_termios_device_install
>> but
>> > > there seems to be
>> > > > > no such function in the
>> raspberry
>> > > pi? But there is a
>> > > > entry in
>> > > > > console_fns for init
>> function, but
>> > > then how does it
>> > > > > gets called?
>> > > > > And for BSP's with multiple
>> > > serial's, the output function
>> > > > > chooses the right serial using
>> > > console_port_minor,
>> > > > > Is it during initialization?
>> > > > > What is the need for get and
>> set
>> > > register functions?
>> > > > >
>> > > > > On Mon, Dec 23, 2019 at 1:04
>> AM
>> > > Christian Mauderer
>> > > > > <list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>> <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>>
>> > > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>> <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>>>> wrote:
>> > > > >
>> > > > > On 22/12/2019 19:45, Joel
>> > > Sherrill wrote:
>> > > > > >
>> > > > > >
>> > > > > > On Sun, Dec 22, 2019,
>> > 12:29 PM
>> > > Niteesh
>> > > > <gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com> <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>
>> > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com> <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>>
>> > > > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>> <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>>>
>> > > > > >
>> > <mailto:gsnb.gn at gmail.com <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com <mailto:
>> gsnb.gn at gmail.com>>
>> > > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>> <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com <mailto:
>> gsnb.gn at gmail.com>>
>> > > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>
>> > > <mailto:gsnb.gn at gmail.com
>> > <mailto:gsnb.gn at gmail.com>>>>>> wrote:
>> > > > > >
>> > > > > > On Sun, Dec 22,
>> 2019 at
>> > > 8:44 PM Christian
>> > > > Mauderer
>> > > > > > <list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>
>> > > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>> <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>
>> > > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>>>
>> > > > > <mailto:
>> list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>
>> > > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>> <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>
>> > > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>
>> > > <mailto:list at c-mauderer.de
>> > <mailto:list at c-mauderer.de>>>>>> wrote:
>> > > > > >
>> > > > > > Hello Niteesh,
>> > > > > >
>> > > > > > thanks for doing
>> > that
>> > > work.
>> > > > > >
>> > > > > > On 22/12/2019
>> 12:10,
>> > > Niteesh wrote:
>> > > > > > > The rpi1 and
>> rpi2
>> > > use the PL011 UART,
>> > > > whereas,
>> > > > > with RPI's
>> > > > > > equipped with
>> > > > > > >
>> wireless/Bluetooth
>> > > module, the PL011 is
>> > > > > connected to the Bluetooth
>> > > > > > > module, and
>> > the mini
>> > > UART is used as
>> > > > the primary
>> > > > > UART.
>> > > > > >
>> > > > > > In my opinion it
>> > would
>> > > be great if you
>> > > > could use
>> > > > > the FDT to
>> > > > > > distinguish
>> > > > > > between the
>> boards.
>> > > That should allow to add
>> > > > > raspberry 3 (and
>> > > > > > maybe 4)
>> > > > > > support without
>> > adding
>> > > another BSP. More
>> > > > BSPs mean
>> > > > > a bigger
>> > > > > > maintenance
>> > > > > > effort for the
>> RTEMS
>> > > community.
>> > > > > >
>> > > > > > Learning more about
>> > FDT is
>> > > on my list for a long
>> > > > > time. I would love
>> > > > > > to work on that
>> > > > > > but I have almost
>> no exp
>> > > with FDT's.
>> > > > > > But another thing
>> could
>> > > also be done, in
>> > > > > >
>> > > raspberrypi/start/bspstart.c we get the
>> > > > revision and
>> > > > > > model of the board
>> using
>> > > the mailbox. Every
>> > > > board has
>> > > > > a unique id,
>> > > > > > which we could use
>> to
>> > > initialize
>> > > > > > the BSP. But using
>> FDT
>> > > seems to be a more
>> > > > elegant
>> > > > > option, it is a
>> > > > > > lot of work I
>> think, but
>> > > we could take
>> > > > > > help from libbsd and
>> > linux
>> > > I suppose. What
>> > > > do you think?
>> > > > > >
>> > > > > >
>> > > > > > I think there are almost
>> > > always two steps to a
>> > > > project
>> > > > > like this: get it
>> > > > > > to work and make it
>> nice. :)
>> > > > > >
>> > > > > > If you fix the startup
>> > code to
>> > > read the board
>> > > > revision and
>> > > > > memory size,
>> > > > > > you can get a working
>> > BSP that
>> > > dynamically
>> > > > adapts to the
>> > > > > models and
>> > > > > > memory variations with
>> > minimal
>> > > modifications. If
>> > > > you want
>> > > > > to then
>> > > > > > convert the BSP to FDT,
>> it
>> > > will be a LOT easier
>> > > > to debug
>> > > > > with a working BSP.
>> > > > > >
>> > > > > > Plus you may be able to
>> > > identify every variation
>> > > > point
>> > > > > based on just the
>> > > > > > model info. Then FDT is
>> > just a
>> > > matter of
>> > > > switching the
>> > > > > source of
>> > > > > > some/all of the info.
>> > > > > >
>> > > > > > That would be my work
>> > plan anyway.
>> > > > >
>> > > > > I agree with Joel that a
>> > secure
>> > > development basis
>> > > > (also
>> > > > > known as "hack")
>> > > > > as a first step is a good
>> > idea.
>> > > You maybe even
>> > > > just make the
>> > > > > mini UART
>> > > > > the default driver while
>> > you are
>> > > developing. Then
>> > > > you can be
>> > > > > sure that
>> > > > > you have the right driver.
>> > > > >
>> > > > > As soon as that works you
>> can
>> > > either change to the
>> > > > revision
>> > > > > method or
>> > > > > (better) to the FDT one
>> and
>> > > after that the patches
>> > > > can be
>> > > > > merged. Using
>> > > > > the FDT isn't that
>> > complicated.
>> > > Basically you
>> > > > search for a
>> > > > > node based on
>> > > > > different parameters. For
>> an
>> > > example you can take
>> > > > a look at
>> > > > > the imx BSP.
>> > > > > In imx_uart_probe
>> > > > (bsps/arm/imx/console/console-config.c)
>> a
>> > > > > fdt node is
>> > > > > searched and based on
>> that a
>> > > UART driver is used.
>> > > > But again:
>> > > > > Follow
>> > > > > Joels suggestion to start
>> > simple
>> > > and secure.
>> > > > >
>> > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
>> > > > > > > But from the
>> above
>> > > doc (PAGE 10), the
>> > > > mini uart
>> > > > > has 16550 like
>> > > > > > registers
>> > > > > > > and RTEMS
>> already
>> > > has the driver for it
>> > > > > > >
>> > > bsps/shared/dev/serial/ns16550.c. But
>> > > > I am not
>> > > > > sure how
>> > > > > > compatible they
>> > > > > > > are? Should a
>> new
>> > > driver be
>> > > > implemented from
>> > > > > scratch or use
>> > > > > > ns16550 if
>> > > > > > > possible?
>> > > > > >
>> > > > > > In general it's
>> > better
>> > > to re-use
>> > > > existing code.
>> > > > > That has multiple
>> > > > > > advantages:
>> > > > > >
>> > > > > > - It reduces the
>> > > maintenance effort.
>> > > > Fewer code
>> > > > > means fewer work.
>> > > > > > - If you have
>> > multiple
>> > > driver for the
>> > > > same or
>> > > > > similar hardware
>> > > > > > it can
>> > > > > > happen that a
>> bug is
>> > > fixed in one but
>> > > > not the other.
>> > > > > > - It's simpler
>> > to find
>> > > a hardware to
>> > > > test changes.
>> > > > > > - The driver
>> becomes
>> > > more universal with
>> > > > every new
>> > > > > supported
>> > > > > > hardware.
>> > > > > > That increases
>> the
>> > > chance that it fits
>> > > > the next
>> > > > > new hardware.
>> > > > > >
>> > > > > > I'm sure there
>> are
>> > > some more if you ask
>> > > > someone else.
>> > > > > >
>> > > > > > I do understand the
>> > > issues, I just spent
>> > > > some time
>> > > > > reading the
>> > > > > > driver code.
>> > > > > > I think we could
>> most
>> > > probably use it. I
>> > > > will take a
>> > > > > closer look and
>> > > > > > will update.
>> > > > > >
>> > > > >
>> > > > > Great.
>> > > > >
>> > > > > >
>> > > > > >
>> > > > > > >
>> > > > > > > Also, the core
>> > clock
>> > > on which the
>> > > > PL011 is based
>> > > > > on is changed
>> > > > > > in rpi3.
>> > > > > > > Rpi1 and 2 use
>> > > 250Mhz as the default
>> > > > clock but
>> > > > > it was changed
>> > > > > > to 400Mhz
>> > > > > > > in Rpi3 and
>> newer
>> > > > > >
>> > > > > > Again: Would be
>> > great
>> > > if that could be
>> > > > adapted
>> > > > > based on FDT or by
>> > > > > > reading the
>> right
>> > > registers.
>> > > > > >
>> > > > > > >
>> > > > > > > Few
>> differences
>> > > between PL011 and Mini
>> > > > uart
>> > > > > > > The mini UART
>> has
>> > > smaller FIFOs.
>> > > > Combined with
>> > > > > the lack of
>> > > > > > flow control,
>> > > > > > > this makes it
>> more
>> > > prone to losing
>> > > > characters at
>> > > > > higher baud
>> > > > > > rates. It
>> > > > > > > is also
>> generally
>> > > less capable than
>> > > > the PL011,
>> > > > > mainly due to
>> > > > > > its baud
>> > > > > > > rate link to
>> > the VPU
>> > > clock speed.
>> > > > > >
>> > > > > > That shouldn't
>> > really
>> > > be a problem for
>> > > > the system
>> > > > > console.
>> > > > > >
>> > > > > > >
>> > > > > > > The particular
>> > > deficiencies of the
>> > > > mini UART
>> > > > > compared to the
>> > > > > > PL011 are :
>> > > > > > >
>> > > > > > > No break
>> detection
>> > > > > > > No framing
>> errors
>> > > detection
>> > > > > > > No parity bit
>> > > > > > > No receive
>> timeout
>> > > interrupt
>> > > > > > > No DCD, DSR,
>> > DTR or
>> > > RI signals
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > _______________________________________________
>> > > > > > devel mailing list
>> > > > > > devel at rtems.org
>> > <mailto:devel at rtems.org>
>> > > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
>> > <mailto:devel at rtems.org <mailto:devel at rtems.org>
>> > > <mailto:devel at rtems.org <mailto:devel at rtems.org
>> >>>
>> > > > <mailto:devel at rtems.org
>> > <mailto:devel at rtems.org>
>> > > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
>> > <mailto:devel at rtems.org <mailto:devel at rtems.org>
>> > > <mailto:devel at rtems.org <mailto:devel at rtems.org
>> >>>>
>> > > > > <mailto:devel at rtems.org
>> > <mailto:devel at rtems.org>
>> > > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
>> > <mailto:devel at rtems.org <mailto:devel at rtems.org>
>> > > <mailto:devel at rtems.org <mailto:devel at rtems.org
>> >>>
>> > > > <mailto:devel at rtems.org
>> > <mailto:devel at rtems.org>
>> > > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
>> > <mailto:devel at rtems.org <mailto:devel at rtems.org>
>> > > <mailto:devel at rtems.org <mailto:devel at rtems.org
>> >>>>>
>> > > > > >
>> > > http://lists.rtems.org/mailman/listinfo/devel
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20191227/9e2bd326/attachment-0001.html>
More information about the devel
mailing list