Raspberrypi3: Mini UART driver
Niteesh
gsnb.gn at gmail.com
Fri Dec 27 10:12:11 UTC 2019
On Fri, Dec 27, 2019 at 3:38 PM Christian Mauderer <list at c-mauderer.de>
wrote:
> On 27/12/2019 11:03, Niteesh wrote:
> > I tried building it. I basically ran make in previously create rpi2 BSP
> > folder.
> > I did get some compile-time error, but I have fixed them. Now I get
> > an*undefined reference to `arm_pl011_write_polled'*
> > How to include the arm_pl011.c file?
>
> You have to add the file here:
>
> c/src/lib/libbsp/arm/raspberrypi/Makefile.am
>
Did you mean the header.am file? Or should I make a Makefile.am?
>
> Note that you will have to execute a bootstrap again as soon as you
> change anything there.
>
> These files still follow an old folder structure. But they will be
> replaced soon by Sebastians work on the new build system.
>
> >
> > On Fri, Dec 27, 2019 at 3:15 PM Niteesh <gsnb.gn at gmail.com
> > <mailto:gsnb.gn at gmail.com>> wrote:
> >
> > 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
> > <mailto:gsnb.gn at gmail.com>> wrote:
> >
> > On Fri, Dec 27, 2019 at 2:53 PM Christian Mauderer
> > <list at c-mauderer.de <mailto: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>
> > > <mailto: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>>
> > > > <mailto: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>>
> > > > <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:
> > > >
> > > > 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>>
> > > > <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:
> > > >
> > > > 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>>
> > > <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 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>>>
> > > > > <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:
> > > > >
> > > > > 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
> >>>
> > > > <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,
> > > > >
> > > > > 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>>>>
> > > > > >
> > <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:
> > > > > >
> > > > > > 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
> >>>>
> > > > > >
> > <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:
> > > > > >
> > > > > > 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
> >>>>
> > > > > <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:
> > > > > >
> > > > > > 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
> >>>>>
> > > > > > >
> > > <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
> > <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
> >>>>>
> > > > > >
> > <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
> > <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>>>>>
> > > > > >
> > <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
> > <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/b6ccf46a/attachment-0001.html>
More information about the devel
mailing list