Raspberrypi3: Mini UART driver
Niteesh
gsnb.gn at gmail.com
Fri Dec 27 10:03:14 UTC 2019
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?
On Fri, Dec 27, 2019 at 3:15 PM Niteesh <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> 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/c9f7c146/attachment-0001.html>
More information about the devel
mailing list