Re: Build Linux: FAILED 6/rtems-riscv on x86_64-linux-gnu (riscv-rtems6-gdb-771dd3a-x86_64-linux-gnu-1)

2020-03-23 Thread Sebastian Huber 

Hello Joel,

On 18/03/2020 07:09, Sebastian Huber wrote:

On 18/03/2020 05:53, j...@rtems.org wrote:

libtool: compile:  gcc -O2 -g -pipe 
-I/home/joel/rtems-cron-6/rtems-source-builder/rtems/build/tmp/sb-1001/6/rtems-riscv/home/joel/rtems-cron-6/tools/6/include 
-DHAVE_CONFIG_H -I. 
-I../../sourceware-mirror-binutils-gdb-771dd3a/bfd 
-DBINDIR=\"/home/joel/rtems-cron-6/tools/6/bin\" 
-DLIBDIR=\"/home/joel/rtems-cron-6/tools/6/lib\" -I. 
-I../../sourceware-mirror-binutils-gdb-771dd3a/bfd 
-I../../sourceware-mirror-binutils-gdb-771dd3a/bfd/../include 
-DHAVE_riscv_elf32_vec -DHAVE_riscv_elf64_vec -DHAVE_elf64_le_vec 
-DHAVE_elf64_be_vec -DHAVE_elf32_le_vec -DHAVE_elf32_be_vec -W -Wall 
-Wstrict-prototypes -Wmissing-prototypes -Wshadow 
-I../../sourceware-mirror-binutils-gdb-771dd3a/bfd/../zlib -g -O2 -MT 
elflink.lo -MD -MP -MF .deps/elflink.Tpo -c 
../../sourceware-mirror-binutils-gdb-771dd3a/bfd/elflink.c -o elflink.o

no
configure: WARNING: libipt is missing or unusable; some features may 
be unavailable.
../../sourceware-mirror-binutils-gdb-771dd3a/bfd/elfxx-riscv.c: In 
function 'riscv_parse_subset':
../../sourceware-mirror-binutils-gdb-771dd3a/bfd/elfxx-riscv.c:1493:3: 
error: 'for' loop initial declarations are only allowed in C99 mode

    for (size_t i = 0; i < ARRAY_SIZE (parse_config); ++i) {
    ^
../../sourceware-mirror-binutils-gdb-771dd3a/bfd/elfxx-riscv.c:1493:3: 
note: use option -std=c99 or -std=gnu99 to compile your code


I sent a patch for this one:

https://sourceware.org/pipermail/binutils/2020-March/110265.html
could you please test the RTEMS 6 tool chain build again. It should be 
fixed now.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v3 3/3] i386: Port to RTEMS

2020-03-23 Thread Jan Sommer 
- Update imported files to compile rtems-libbsd for i386 based BSPs
---
 freebsd-org  |2 +-
 freebsd/sbin/sysctl/sysctl.c |8 +
 freebsd/sys/dev/pci/pci_pci.c|2 +
 freebsd/sys/i386/i386/legacy.c   |  381 -
 freebsd/sys/i386/include/machine/cpufunc.h   |2 +
 freebsd/sys/i386/include/machine/legacyvar.h |   63 --
 freebsd/sys/net/iflib.c  |9 +
 freebsd/sys/sys/callout.h|6 +
 rtemsbsd/i386/include/machine/clock.h|2 +
 rtemsbsd/include/rtems/bsd/local/opt_acpi.h  |0
 rtemsbsd/include/x86/legacyvar.h |1 +
 rtemsbsd/include/x86/specialreg.h| 1074 ++
 rtemsbsd/include/x86/x86_var.h   |  156 
 13 files changed, 1261 insertions(+), 445 deletions(-)
 delete mode 100644 freebsd/sys/i386/i386/legacy.c
 delete mode 100644 freebsd/sys/i386/include/machine/legacyvar.h
 create mode 100644 rtemsbsd/i386/include/machine/clock.h
 create mode 100644 rtemsbsd/include/rtems/bsd/local/opt_acpi.h
 create mode 100644 rtemsbsd/include/x86/legacyvar.h
 create mode 100644 rtemsbsd/include/x86/specialreg.h
 create mode 100644 rtemsbsd/include/x86/x86_var.h

diff --git a/freebsd-org b/freebsd-org
index 0d1c3913..7e8d1444 16
--- a/freebsd-org
+++ b/freebsd-org
@@ -1 +1 @@
-Subproject commit 0d1c391321b34b3025cf0e72f2231d836ff76da8
+Subproject commit 7e8d1444023128d34fb9aa4e4515928a4f794d1b
diff --git a/freebsd/sbin/sysctl/sysctl.c b/freebsd/sbin/sysctl/sysctl.c
index 30ebe5fd..035c1db2 100644
--- a/freebsd/sbin/sysctl/sysctl.c
+++ b/freebsd/sbin/sysctl/sysctl.c
@@ -69,7 +69,9 @@ static const char rcsid[] =
 #endif
 
 #if defined(__amd64__) || defined(__i386__)
+#ifndef __rtems__
 #include 
+#endif /* __rtems__ */
 #endif
 
 #include 
@@ -832,6 +834,7 @@ S_efi_map(size_t l2, void *p)
 #endif
 
 #if defined(__amd64__) || defined(__i386__)
+#ifndef __rtems__
 static int
 S_bios_smap_xattr(size_t l2, void *p)
 {
@@ -850,6 +853,7 @@ S_bios_smap_xattr(size_t l2, void *p)
(uintmax_t)smap->length);
return (0);
 }
+#endif /* __rtems__ */
 #endif
 
 static int
@@ -1061,7 +1065,11 @@ show_var(int *oid, int nlen)
 #endif
 #if defined(__amd64__) || defined(__i386__)
else if (strcmp(fmt, "S,bios_smap_xattr") == 0)
+#ifndef __rtems__
func = S_bios_smap_xattr;
+#else /* __rtems__ */
+   func = NULL;
+#endif /* __rtems__ */
 #endif
else {
func = NULL;
diff --git a/freebsd/sys/dev/pci/pci_pci.c b/freebsd/sys/dev/pci/pci_pci.c
index 43c71461..5ba3e9a0 100644
--- a/freebsd/sys/dev/pci/pci_pci.c
+++ b/freebsd/sys/dev/pci/pci_pci.c
@@ -1593,6 +1593,7 @@ pcib_attach_common(device_t dev)
sc->flags |= PCIB_SUBTRACTIVE;
break;
 
+#ifndef __rtems__
 #if !(defined(NEW_PCIB) && defined(PCI_RES_BUS))
 /* Compaq R3000 BIOS sets wrong subordinate bus number. */
 case 0x00dd10de:
@@ -1620,6 +1621,7 @@ pcib_attach_common(device_t dev)
break;
}
 #endif
+#endif /* __rtems__ */
 }
 
 if (pci_msi_device_blacklisted(dev))
diff --git a/freebsd/sys/i386/i386/legacy.c b/freebsd/sys/i386/i386/legacy.c
deleted file mode 100644
index 50fa9aa2..
--- a/freebsd/sys/i386/i386/legacy.c
+++ /dev/null
@@ -1,381 +0,0 @@
-#include 
-
-/*-
- * Copyright 1998 Massachusetts Institute of Technology
- *
- * Permission to use, copy, modify, and distribute this software and
- * its documentation for any purpose and without fee is hereby
- * granted, provided that both the above copyright notice and this
- * permission notice appear in all copies, that both the above
- * copyright notice and this permission notice appear in all
- * supporting documentation, and that the name of M.I.T. not be used
- * in advertising or publicity pertaining to distribution of the
- * software without specific, written prior permission.  M.I.T. makes
- * no representations about the suitability of this software for any
- * purpose.  It is provided "as is" without express or implied
- * warranty.
- * 
- * THIS SOFTWARE IS PROVIDED BY M.I.T. ``AS IS''.  M.I.T. DISCLAIMS
- * ALL EXPRESS OR IMPLIED WARRANTIES WITH REGARD TO THIS SOFTWARE,
- * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT
- * SHALL M.I.T. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
- * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
- * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include 
-__FBSDID("$FreeBSD$");
-

[PATCH v3 0/3] [5-freebsd-12] Fix compilation for i386

2020-03-23 Thread Jan Sommer 
This is the  backport for the 5-freebsd-12 branch to make rtems-libbsd compile 
for i386 again:
- It also introduces path-mappings to waf_libbsd.py as introduced here:
https://lists.rtems.org/pipermail/devel/2020-February/057457.html

Changes compared to v2:
- callout.h: Change the callout_reset_on macro
- iflib.c: Do not use different callout* macro, but use the changed one

Best regards,

   Jan


Jan Sommer (3):
  i386: Add missing files from FreeBSD
  i386: Update build system
  i386: Port to RTEMS

 freebsd-org|2 +-
 freebsd/sbin/sysctl/sysctl.c   |8 +
 freebsd/sys/dev/pci/pci_pci.c  |2 +
 freebsd/sys/i386/include/machine/cpufunc.h |2 +
 freebsd/sys/net/iflib.c| 6756 
 freebsd/sys/net/iflib_private.h|   76 +
 freebsd/sys/net/mp_ring.c  |  554 ++
 freebsd/sys/net/mp_ring.h  |   75 +
 freebsd/sys/sys/callout.h  |6 +
 freebsd/sys/x86/include/machine/intr_machdep.h |  180 +
 .../sys/{i386 => x86}/include/machine/legacyvar.h  |   26 +-
 freebsd/sys/{i386/i386 => x86/x86}/legacy.c|   77 +-
 libbsd.py  |   17 +-
 rtemsbsd/i386/include/machine/clock.h  |2 +
 rtemsbsd/include/rtems/bsd/local/opt_acpi.h|0
 rtemsbsd/include/x86/legacyvar.h   |1 +
 rtemsbsd/include/x86/specialreg.h  | 1074 
 rtemsbsd/include/x86/x86_var.h |  156 +
 waf_libbsd.py  |   13 +-
 19 files changed, 8987 insertions(+), 40 deletions(-)
 create mode 100644 freebsd/sys/net/iflib.c
 create mode 100644 freebsd/sys/net/iflib_private.h
 create mode 100644 freebsd/sys/net/mp_ring.c
 create mode 100644 freebsd/sys/net/mp_ring.h
 create mode 100644 freebsd/sys/x86/include/machine/intr_machdep.h
 rename freebsd/sys/{i386 => x86}/include/machine/legacyvar.h (76%)
 rename freebsd/sys/{i386/i386 => x86/x86}/legacy.c (89%)
 create mode 100644 rtemsbsd/i386/include/machine/clock.h
 create mode 100644 rtemsbsd/include/rtems/bsd/local/opt_acpi.h
 create mode 100644 rtemsbsd/include/x86/legacyvar.h
 create mode 100644 rtemsbsd/include/x86/specialreg.h
 create mode 100644 rtemsbsd/include/x86/x86_var.h

-- 
2.12.3

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v3 2/3] i386: Update build system

2020-03-23 Thread Jan Sommer 
- Update FreeBSD files in libbsd.py
- Introduce path-mappings in waf_libsd.py and libbsd.py for include path
fixes
---
 libbsd.py | 17 +++--
 waf_libbsd.py | 13 +++--
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/libbsd.py b/libbsd.py
index d791efe4..3c0b7afe 100644
--- a/libbsd.py
+++ b/libbsd.py
@@ -90,6 +90,14 @@ _defaults = {
 'cpu-include-paths': ['rtemsbsd/@CPU@/include',
   'freebsd/sys/@CPU@/include'],
 
+#
+# Map paths based on RTEMS naming to FreeBSD naming.
+#
+'path-mappings': [ # (source, targets)
+# i386
+('freebsd/sys/i386/include', ['freebsd/sys/x86/include', 
'freebsd/sys/i386/include']),
+],
+
 # The path where headers will be copied during build.
 'build-include-path': ['build-include'],
 
@@ -1366,10 +1374,14 @@ class dev_net(builder.Module):
 'sys/net/if_types.h',
 'sys/net/if_var.h',
 'sys/net/vnet.h',
+'sys/net/mp_ring.h',
+'sys/net/iflib_private.h',
 ]
 )
 self.addKernelSpaceSourceFiles(
 [
+'sys/net/iflib.c',
+'sys/net/mp_ring.c',
 'sys/arm/ti/cpsw/if_cpsw.c',
 'sys/dev/ffec/if_ffec.c',
 'sys/dev/mii/mii.c',
@@ -1425,6 +1437,7 @@ class dev_nic(builder.Module):
 'sys/i386/include/specialreg.h',
 'sys/i386/include/md_var.h',
 'sys/i386/include/intr_machdep.h',
+'sys/x86/include/intr_machdep.h',
 'sys/i386/include/cpufunc.h',
 'sys/mips/include/cpufunc.h',
 'sys/mips/include/cpuregs.h',
@@ -2601,7 +2614,7 @@ class pci(builder.Module):
 self.addCPUDependentFreeBSDHeaderFiles(
 [
 'sys/i386/include/_bus.h',
-'sys/i386/include/legacyvar.h',
+'sys/x86/include/legacyvar.h',
 'sys/x86/include/bus.h',
 'sys/x86/include/pci_cfgreg.h',
 ]
@@ -2609,7 +2622,7 @@ class pci(builder.Module):
 self.addCPUDependentFreeBSDSourceFiles(
 [ 'i386' ],
 [
-'sys/i386/i386/legacy.c',
+'sys/x86/x86/legacy.c',
 'sys/x86/pci/pci_bus.c',
 ],
 mm.generator['source']()
diff --git a/waf_libbsd.py b/waf_libbsd.py
index 3a14541a..a98ee3c2 100644
--- a/waf_libbsd.py
+++ b/waf_libbsd.py
@@ -210,8 +210,6 @@ class Builder(builder.ModuleManager):
 buildinclude = 'build-include'
 if 'cpu-include-paths' in config:
 cpu = bld.get_env()['RTEMS_ARCH']
-if cpu == "i386":
-cpu = 'x86'
 for i in config['cpu-include-paths']:
 includes += [i.replace('@CPU@', cpu)]
 if 'include-paths' in config:
@@ -223,6 +221,17 @@ class Builder(builder.ModuleManager):
 includes += [buildinclude]
 
 #
+# Path mappings
+#
+if 'path-mappings' in config:
+for source, target in config['path-mappings']:
+if source in includes:
+target = [target] if isinstance(target, str) else target
+i = includes.index(source)
+includes.remove(source)
+includes[i:i] = target
+
+#
 # Collect the libbsd uses
 #
 libbsd_use = []
-- 
2.12.3

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] user/gsoc: GSoC Getting Started Instructions

2020-03-23 Thread Niteesh G. S. 
On Mon, Mar 23, 2020 at 11:58 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 23/03/2020 06:59, Niteesh G. S. wrote:
>
>  From here on I would prefer references to the existing documentation
>> with any GSoC details list here. I would prefer we avoid duplicating
>> prefix, sources and building anywhere in the documentaion as it will
>> only confuse search engines, normal users and GSoC students. The Quick
>> Start Guide has taken a long time to get to where it is. If there is
>> something in the Quick Start guide that needs fixing please let me know.
>>
> I had this discussion with Gedare. We felt it would be nice to have all the
> instructions in once place instead of referencing them. It would make it
> easier for newcomers and students to follow.
> Maybe I'll use the same prefix as in the Quick Start guide but have all the
> instructions here.
>
> In case the Quick Start section is difficult to follow for newcomers and
> students, then the Quick Start should be fixed. I am also not in favour of
> duplicating content and prefer references. All this duplication makes it
> very hard to maintain the documentation. I am sorry if that this causes
> some extra work for you.
>
By difficult to follow I mean that it is just too much information for a
student who just wants
to set up an initial functioning development environment. But, also having
all that information
is important to get an understanding of the process that happens in the
background.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v3 3/3] i386: Port to RTEMS

2020-03-23 Thread Sebastian Huber 

On 23/03/2020 09:06, Jan Sommer wrote:


@@ -4597,7 +4599,12 @@ iflib_device_register(device_t dev, void *sc, 
if_shared_ctx_t sctx, if_ctx_t *ct
/* Set up cpu set.  If it fails, use the set of all CPUs. */
if (bus_get_cpus(dev, INTR_CPUS, sizeof(ctx->ifc_cpus), &ctx->ifc_cpus) 
!= 0) {
device_printf(dev, "Unable to fetch CPU list\n");
+#ifndef __rtems__
CPU_COPY(&all_cpus, &ctx->ifc_cpus);
+#else /* __rtems__ */
+   cpuset_t cpus = {all_cpus};
+   CPU_COPY(&cpus, &ctx->ifc_cpus);
+#endif /* __rtems__ */
}
MPASS(CPU_COUNT(&ctx->ifc_cpus) > 0);


What is the reason for this change?

Could you please move the changes in non-x86 specific files to a 
separate commit. Especially the  is an important header 
file used across all architectures.


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v3] bsp/beagle: Update console to new Termios API.

2020-03-23 Thread G S Niteesh Babu 
This patch updates the console driver to new Termios API.

Update #3034
---
 bsps/arm/beagle/console/console-config.c | 117 +--
 c/src/lib/libbsp/arm/beagle/Makefile.am  |   4 +-
 2 files changed, 69 insertions(+), 52 deletions(-)

diff --git a/bsps/arm/beagle/console/console-config.c 
b/bsps/arm/beagle/console/console-config.c
index 78af5f6a93..b2246571f8 100644
--- a/bsps/arm/beagle/console/console-config.c
+++ b/bsps/arm/beagle/console/console-config.c
@@ -21,12 +21,15 @@
  *
  * Modified by Ben Gras  to make
  * interrupt-driven uart i/o work for beagleboards; beaglebone support added.
+ *
+ * Modified by Niteesh Babu G S 
+ * Update console to new termios API.
  */
 
-#include 
 #include 
 
 #include 
+#include 
 
 #include 
 #include 
@@ -41,6 +44,8 @@
 #define TX_FIFO_E (1<<5)
 #define RX_FIFO_E (1<<0)
 
+#define BEAGLE_UART0 "/dev/ttyS0"
+
 static uint8_t beagle_uart_get_register(uintptr_t addr, uint8_t i)
 {
   uint8_t v;
@@ -65,77 +70,91 @@ static void beagle_uart_set_register(uintptr_t addr, 
uint8_t i, uint8_t val)
   reg [i] = val;
 }
 
-console_tbl Console_Configuration_Ports [] = {
-{
-  .sDeviceName = "/dev/ttyS0",
-  .deviceType = SERIAL_NS16550,
-#if CONSOLE_POLLED /* option to facilitate running the tests */
-  .pDeviceFns = &ns16550_fns_polled,
-#else
-  .pDeviceFns = &ns16550_fns,
-#endif
-  .ulMargin = 16,
-  .ulHysteresis = 8,
-  .pDeviceParams = (void *) CONSOLE_BAUD,
-  .ulCtrlPort1 = BSP_CONSOLE_UART_BASE,
-  .ulDataPort = BSP_CONSOLE_UART_BASE,
-  .ulIntVector = BSP_CONSOLE_UART_IRQ,
-  .getRegister = beagle_uart_get_register,
-  .setRegister = beagle_uart_set_register,
-  .ulClock = UART_CLOCK,  /* 48MHz base clock */
-},
-};
-
-unsigned long Console_Configuration_Count = 1;
-
-static int init_needed = 1; // don't rely on bss being 0
+static ns16550_context uart_context;
+static void uart_write_polled( char c );
 
 static void beagle_console_init(void)
 {
-  if(init_needed) {
-const uint32_t div = UART_CLOCK / 16 / CONSOLE_BAUD;
-CONSOLE_SYSC = 2;
-while ((CONSOLE_SYSS & 1) == 0)
-  ;
-if ((CONSOLE_LSR & (CONSOLE_LSR_THRE | CONSOLE_LSR_TEMT)) == 
CONSOLE_LSR_THRE) {
-  CONSOLE_LCR = 0x83;
-  CONSOLE_DLL = div;
-  CONSOLE_DLM = (div >> 8) & 0xff;
-  CONSOLE_LCR = 0x03;
-  CONSOLE_ACR = 0x00;
-}
+  ns16550_context *ctx;
+  static bool initialized = false;
 
-while ((CONSOLE_LSR & CONSOLE_LSR_TEMT) == 0)
-  ;
+  if ( initialized ) {
+return ;
+  }
 
-CONSOLE_LCR = 0x80 | 0x03;
-CONSOLE_DLL = 0x00;
-CONSOLE_DLM = 0x00;
-CONSOLE_LCR = 0x03;
-CONSOLE_MCR = 0x03;
-CONSOLE_FCR = 0x07;
+  /*
+   * Don't rely on BSS being zeroed
+   */
+  memset(&uart_context, 0, sizeof(uart_context));
+  ctx = &uart_context;
+
+  ctx->port = BSP_CONSOLE_UART_BASE;
+  ctx->irq = BSP_CONSOLE_UART_IRQ;
+  ctx->set_reg = beagle_uart_set_register;
+  ctx->get_reg = beagle_uart_get_register;
+  ctx->initial_baud = CONSOLE_BAUD;
+  ctx->clock = UART_CLOCK;
+
+  const uint32_t div = UART_CLOCK / 16 / CONSOLE_BAUD;
+  CONSOLE_SYSC = 2;
+  while ((CONSOLE_SYSS & 1) == 0)
+;
+  if ((CONSOLE_LSR & (CONSOLE_LSR_THRE | CONSOLE_LSR_TEMT)) == 
CONSOLE_LSR_THRE) {
 CONSOLE_LCR = 0x83;
 CONSOLE_DLL = div;
 CONSOLE_DLM = (div >> 8) & 0xff;
 CONSOLE_LCR = 0x03;
 CONSOLE_ACR = 0x00;
-init_needed = 0;
   }
+  while ((CONSOLE_LSR & CONSOLE_LSR_TEMT) == 0)
+;
+  CONSOLE_LCR = 0x80 | 0x03;
+  CONSOLE_DLL = 0x00;
+  CONSOLE_DLM = 0x00;
+  CONSOLE_LCR = 0x03;
+  CONSOLE_MCR = 0x03;
+  CONSOLE_FCR = 0x07;
+  CONSOLE_LCR = 0x83;
+  CONSOLE_DLL = div;
+  CONSOLE_DLM = (div >> 8) & 0xff;
+  CONSOLE_LCR = 0x03;
+  CONSOLE_ACR = 0x00;
+
+  BSP_output_char = uart_write_polled;
 }
 
 #define CONSOLE_THR8 (*(volatile uint8_t *) (BSP_CONSOLE_UART_BASE + 0x00))
 
 static void uart_write_polled( char c )
 {
-  if(init_needed) beagle_console_init();
-
   while( ( CONSOLE_LSR & TX_FIFO_E ) == 0 )
 ;
   CONSOLE_THR8 = c;
 }
 
+rtems_status_code console_initialize(
+  rtems_device_major_number major,
+  rtems_device_minor_number minor,
+  void *arg
+)
+{
+  rtems_termios_initialize();
+
+  beagle_console_init();
+
+  rtems_termios_device_install(
+BEAGLE_UART0,
+&ns16550_handler_polled,
+NULL,
+&uart_context.base
+  );
+
+  return RTEMS_SUCCESSFUL;
+}
+
 static void _BSP_put_char( char c ) {
-   uart_write_polled( c );
+  beagle_console_init();
+  uart_write_polled( c );
 }
 
 static int _BSP_get_char(void)
diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am 
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index e37472373c..1cd9920b2f 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -62,9 +62,7 @@ librtemsbsp_a_SOURCES += 
../../../../../../bsps/shared/irq/irq-default-handler.c
 librtemsbsp_a_SOURCES += ../../../../../../bsps/arm/beagle/irq/irq.c
 
 # Console
-librtemsbsp_a_SOURCES += 
.

AW: [PATCH v3 3/3] i386: Port to RTEMS

2020-03-23 Thread Jan.Sommer 


> -Ursprüngliche Nachricht-
> Von: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> Gesendet: Montag, 23. März 2020 10:59
> An: Sommer, Jan; devel@rtems.org
> Betreff: Re: [PATCH v3 3/3] i386: Port to RTEMS
> 
> On 23/03/2020 09:06, Jan Sommer wrote:
> 
> > @@ -4597,7 +4599,12 @@ iflib_device_register(device_t dev, void *sc,
> if_shared_ctx_t sctx, if_ctx_t *ct
> > /* Set up cpu set.  If it fails, use the set of all CPUs. */
> > if (bus_get_cpus(dev, INTR_CPUS, sizeof(ctx->ifc_cpus), &ctx-
> >ifc_cpus) != 0) {
> > device_printf(dev, "Unable to fetch CPU list\n");
> > +#ifndef __rtems__
> > CPU_COPY(&all_cpus, &ctx->ifc_cpus);
> > +#else /* __rtems__ */
> > +   cpuset_t cpus = {all_cpus};
> > +   CPU_COPY(&cpus, &ctx->ifc_cpus);
> > +#endif /* __rtems__ */
> > }
> > MPASS(CPU_COUNT(&ctx->ifc_cpus) > 0);
> 
> What is the reason for this change?
> 

For RTEMS the all_cpus variable has been replaced in freebsd/sys/sys/smp.h to " 
#define all_cpus 1U".
The additional variable is there because CPU_COPY requires an address.

> Could you please move the changes in non-x86 specific files to a
> separate commit. Especially the  is an important header
> file used across all architectures.

Ok, will do. Should I then also do a separate commit for iflib.c as well, since 
it is compiled for all archtectures as well (not sure if is also used)?

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: AW: [PATCH v3 3/3] i386: Port to RTEMS

2020-03-23 Thread Sebastian Huber 

On 23/03/2020 13:50, jan.som...@dlr.de wrote:


-Ursprüngliche Nachricht-
Von: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
Gesendet: Montag, 23. März 2020 10:59
An: Sommer, Jan;devel@rtems.org
Betreff: Re: [PATCH v3 3/3] i386: Port to RTEMS

On 23/03/2020 09:06, Jan Sommer wrote:


@@ -4597,7 +4599,12 @@ iflib_device_register(device_t dev, void *sc,

if_shared_ctx_t sctx, if_ctx_t *ct

/* Set up cpu set.  If it fails, use the set of all CPUs. */
if (bus_get_cpus(dev, INTR_CPUS, sizeof(ctx->ifc_cpus), &ctx-
ifc_cpus) != 0) {
device_printf(dev, "Unable to fetch CPU list\n");
+#ifndef __rtems__
CPU_COPY(&all_cpus, &ctx->ifc_cpus);
+#else /* __rtems__ */
+   cpuset_t cpus = {all_cpus};
+   CPU_COPY(&cpus, &ctx->ifc_cpus);
+#endif /* __rtems__ */
}
MPASS(CPU_COUNT(&ctx->ifc_cpus) > 0);

What is the reason for this change?


For RTEMS the all_cpus variable has been replaced in freebsd/sys/sys/smp.h to " 
#define all_cpus 1U".
The additional variable is there because CPU_COPY requires an address.
Ok, problems like this are an indication that you try to use a feature 
which is not really supported. I would first try to understand what the 
purpose of the ifc_cpus is. Maybe this stuff could be disabled completely.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Sources for adding ftw.h

2020-03-23 Thread Eshan Dhawan 
hello everyone,
As @Vaibhav Guptatold the FreeBSD and NetBSD
implemenattio of ftw.h requirs fts.h which inturn requires sys/mount.h
which requirs many other headres that are not yet implemented so creating a
dependencies chain
requiring to add 10-15 more headers just to add ftw.h
So I started searching alternative sources to add ftw.h . So i found musl
also has a implementation for ftw.h as well and it dosent require fts.h to
be implemented

I would request you all to look into it and see it the implementation is
useful for RTEMS
since they have used a different approach to the functions

ftw.h : https://git.musl-libc.org/cgit/musl/tree/include/ftw.h
ftw.c: https://git.musl-libc.org/cgit/musl/tree/src/legacy/ftw.c
nftw.c: https://git.musl-libc.org/cgit/musl/tree/src/misc/nftw.c
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] user/gsoc: GSoC Getting Started Instructions

2020-03-23 Thread Gedare Bloom 
On Mon, Mar 23, 2020 at 3:35 AM Niteesh G. S.  wrote:
>
> On Mon, Mar 23, 2020 at 11:58 AM Sebastian Huber 
>  wrote:
>>
>> On 23/03/2020 06:59, Niteesh G. S. wrote:
>>>
>>>  From here on I would prefer references to the existing documentation
>>> with any GSoC details list here. I would prefer we avoid duplicating
>>> prefix, sources and building anywhere in the documentaion as it will
>>> only confuse search engines, normal users and GSoC students. The Quick
>>> Start Guide has taken a long time to get to where it is. If there is
>>> something in the Quick Start guide that needs fixing please let me know.
>>
>> I had this discussion with Gedare. We felt it would be nice to have all the
>> instructions in once place instead of referencing them. It would make it
>> easier for newcomers and students to follow.
>> Maybe I'll use the same prefix as in the Quick Start guide but have all the
>> instructions here.
>>
>> In case the Quick Start section is difficult to follow for newcomers and 
>> students, then the Quick Start should be fixed. I am also not in favour of 
>> duplicating content and prefer references. All this duplication makes it 
>> very hard to maintain the documentation. I am sorry if that this causes some 
>> extra work for you.
>
> By difficult to follow I mean that it is just too much information for a 
> student who just wants
> to set up an initial functioning development environment. But, also having 
> all that information
> is important to get an understanding of the process that happens in the 
> background.

The original intent of GSoC Getting Started Tutorial was to provide
simplified instructions to get into some baseline development
environment. Over time with the evolution of RSB and recent revamping
of the Quick Start, I think perhaps we do have the opportunity to
merge these instructions somewhat.  However, there are extra details
in Quick Start that are not necessary for getting into a development
environment asap. Perhaps provide a "GSoC Getting Started" as a
subchapter in the Quick Start that points to all the relevant sections
with explicit instructions (use erc32, use master branch, etc.) and
then the "proof" request along with contacting the ML after reviewing
open project. The last part is still only relevant to GSoC students
(or students in general that just want to get started).

Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v8] tests for fenv.h functions

2020-03-23 Thread Gedare Bloom 
On Sun, Mar 22, 2020 at 2:11 PM Eshan dhawan  wrote:
>
> ---
>  testsuites/psxtests/psxfenv01/init.c| 105 +++-
>  testsuites/psxtests/psxfenv01/psxfenv01.doc |   9 +-
>  testsuites/psxtests/psxfenv01/psxfenv01.scn |   4 -
>  3 files changed, 85 insertions(+), 33 deletions(-)
>
> diff --git a/testsuites/psxtests/psxfenv01/init.c 
> b/testsuites/psxtests/psxfenv01/init.c
> index cdb0fa596e..b088209d7f 100644
> --- a/testsuites/psxtests/psxfenv01/init.c
> +++ b/testsuites/psxtests/psxfenv01/init.c
> @@ -46,11 +46,12 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  const char rtems_test_name[] = "PSXFENV 01";
>
>  /* forward declarations to avoid warnings */
> -rtems_task Init(rtems_task_argument ignored);
> +rtems_task Init( rtems_task_argument ignored );
>
>  /* Test Function Begins */
>  rtems_task Init(rtems_task_argument ignored)
> @@ -62,40 +63,90 @@ rtems_task Init(rtems_task_argument ignored)
>
>/*
> * 'FE_ALL_EXCEPT' will be defined only when 'feclearexcept()',
> -   * 'fegetexceptflag()', 'feraiseexcept()', 'fesetexceptflag()' and
> -   * 'fetestexcept()' functions are supported by the architecture.
> +   * fegetexceptflag() , feraiseexcept(), fesetexceptflag() and
> +   * fetestexcept() functions are supported by the architecture.
> * Hence their testcases can be wrapped under #ifdef and #endif.
> */
>#ifdef FE_ALL_EXCEPT /* floating-point exceptions */
> -puts( "fesetenv(FE_DFL_ENV)." );
> -r = fesetenv(FE_DFL_ENV);
> -if (r)
> -  printf("fesetenv ==> %d\n", r);
> -rtems_test_assert( r == 0 );
> -
> -/* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
> -puts( "feclearexcept(FE_ALL_EXCEPT)." );
> -r = feclearexcept(FE_ALL_EXCEPT);
> -if (r)
> -  printf("feclearexcept ==> 0x%x\n", r);
> -rtems_test_assert( r == 0 );
> -
> -r = fetestexcept( FE_ALL_EXCEPT );
> -if (r)
> -  printf("fetestexcept ==> 0x%x\n", r);
> -rtems_test_assert( r == 0 );
> -
> -/* Test 'FE_DIVBYZERO' */
> -puts( "Divide by zero and confirm fetestexcept()" );
> +r = fesetenv ( FE_DFL_ENV );
"No space between a function name or function-like macro and the
opening parens."
I think I saw this said before, but:
  fesetenv(
is correct. This is because macros break when the space is there. Fix
below as well.

> +if ( r ) {
> +  printf( "fesetenv ==> %d\n", r);
> +}
> +rtems_test_assert ( r == 0 );
> +
> +/* Test feclearexcept() and fetestexcept() in one go. */
> +r = feclearexcept ( FE_ALL_EXCEPT );
> +if ( r ) {
> +  printf( "feclearexcept ==> 0x%x\n", r );
> +}
> +rtems_test_assert ( r == 0 );
> +
> +r = fetestexcept ( FE_ALL_EXCEPT );
> +if ( r ) {
> +  printf( "fetestexcept ==> 0x%x\n", r );
> +}
> +rtems_test_assert ( r == 0 );
> +
> +/* Test 'FE_DIVBYZERO'
> + *Divide by zero and confirm fetestexcept() */
>  a = 0.0;
>  b = 1.0;
>  c = b/a;
>  (void) c;
> -
> -fegetexceptflag(&excepts,FE_ALL_EXCEPT);
> -
> +/* Test fegetexceptflag() and fesetexceptflag() */
> +r = fegetexceptflag ( &excepts, FE_ALL_EXCEPT );
> +if ( r ) {
> +  printf( "fegetexceptflag ==> 0x%x\n", r );
> +}
> +rtems_test_assert ( r == 0 );
> +
> +r = fesetexceptflag ( &excepts, FE_ALL_EXCEPT );
> +if ( r ) {
> +  printf( "fesetexceptflag ==> 0x%x\n", r );
> +}
> +rtems_test_assert ( r == 0 );
> +
> +/* Test for fegetround() and fesetround()
> + * They have four main macros to be tested separated by ifdef
> + * Since not all architectures support them
> + * The test case gets and sets the rounding directions */
> +#ifdef FE_TONEAREST
> +rtems_test_assert ( fegetround() == FE_TONEAREST );
> +#endif
> +#ifdef FE_TOWARDZERO
> +  r = fesetround ( FE_TOWARDZERO );
> +  if ( r ) {
> +  printf( "fesetround ==> 0x%x\n", r );
> +}
> +  rtems_test_assert ( r == 0 );
> +  rtems_test_assert ( fegetround() == FE_TOWARDZERO );
> +#endif
> +#ifdef FE_DOWNWARD
> +  r = fesetround ( FE_DOWNWARD );
> +  if ( r ) {
> +  printf( "fesetround ==> 0x%x\n", r );
> +}
> +  rtems_test_assert ( r == 0 );
> +  rtems_test_assert ( fegetround() == FE_DOWNWARD );
> +#endif
> +#ifdef FE_UPWARD
> +  r = fesetround ( FE_UPWARD );
> +  if ( r ) {
> +  printf( "fesetround ==> 0x%x\n", r );
> +}
> +  rtems_test_assert ( r == 0 );
> +  rtems_test_assert ( fegetround() == FE_UPWARD );
> +#endif
> +#ifdef FE_TONEAREST
> +  r = fesetround ( FE_TONEAREST );
> +  if ( r ) {
> +  printf( "fesetround ==> 0x%x\n", r );
> +}
> +  rtems_test_assert ( r == 0 );
> +#endif
> +
>  #ifdef FE_DIVBYZERO
> -r = feraiseexcept(FE_DIVBYZERO);
> +r = feraiseexcept ( FE_DIVBYZERO ) ;
>  rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
>  #endif
>
> diff --git a/testsuites/psxtests/psxfenv01/psxfenv01.doc 
> b/testsuites/psxtests/psxfenv01/psxfenv01.doc
> index 3aa7757496..0238372013 100644
> --- a

fenv implementation for POWERPC

2020-03-23 Thread Eshan Dhawan 
hello everyone,
For porting fenv.h to POWERPC I went to FreeBSD and NetBSD They both have
the same implementation.
But musl has a different implementation following the same structure as in
previous implementations.
Which would be better??

FreeBSD: https://github.com/freebsd/freebsd/tree/master/lib/msun/powerpc
NetBSD:-
-> fenv.c :
https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/powerpc/fenv.c
->fenv.h :
https://github.com/NetBSD/src/blob/trunk/sys/arch/powerpc/include/fenv.h
musl: https://git.musl-libc.org/cgit/musl/tree/src/fenv/powerpc64

thanks
eshan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[rtems-littlevgl PATCH] Add README

2020-03-23 Thread Vijay Kumar Banerjee 
---
 README.md | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 README.md

diff --git a/README.md b/README.md
new file mode 100644
index 000..161e4d9
--- /dev/null
+++ b/README.md
@@ -0,0 +1,34 @@
+RTEMS LittlevGL
+===
+
+Welcome to RTEMS LittlevGL (lvgl). This package builds the lvgl library using
+waf with the required settings for running it with rtems. The lvgl drivers are
+adapted to the BSD framebuffer and hence requires the latest rtems-libbsd 
build.
+
+About LittlevGL
+---
+
+LittlevGL is a lightweight graphics library for embedded GUI applications. It
+can be configured using the `lv_conf.h` and the `lv_drv_conf.h` files that are
+in the top of the rtems-littlevgl directory.
+
+The documentation is available at:
+https://docs.littlevgl.com/en/html/index.html
+
+Building and installing rtems-littlevgl
+---
+
+```
+git clone git://git.rtems.org/packages/rtems-littlevgl.git
+git submodule update
+./waf configure --prefix=/path/to/rtems/5
+./waf build install
+```
+
+Writing embedded GUI app using rtems-littlevgl
+--
+
+The rtems-examples repository has a sample lvgl hello world application that 
can
+be followed for reference on how to write and build an application with lvgl.
+The sample app can be found here:
+https://git.rtems.org/rtems-examples/tree/lvgl/hello/test.c
-- 
2.21.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[rtems-littlevgl PATCH] Update lv_drivers

2020-03-23 Thread Vijay Kumar Banerjee 
---
 lv_drivers | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lv_drivers b/lv_drivers
index 24cedaa..ae69299 16
--- a/lv_drivers
+++ b/lv_drivers
@@ -1 +1 @@
-Subproject commit 24cedaa756b83c50c36f4aa0c625fcdfba89431b
+Subproject commit ae69299c1fadb459d0438575d285f1ccf95bc8e6
-- 
2.21.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: fenv implementation for POWERPC

2020-03-23 Thread Joel Sherrill 
On Mon, Mar 23, 2020 at 12:41 PM Eshan Dhawan 
wrote:

> hello everyone,
> For porting fenv.h to POWERPC I went to FreeBSD and NetBSD They both have
> the same implementation.
> But musl has a different implementation following the same structure as in
> previous implementations.
> Which would be better??
>

I like the FreeBSD implementation. It will be easier to integrate. If newlib
wants the methods to have real bodies (e.g. not inline methods), it will be
easy to convert to one method per file.

But I would merge it unmodified as much as possible.

>
> FreeBSD: https://github.com/freebsd/freebsd/tree/master/lib/msun/powerpc
> NetBSD:-
> -> fenv.c :
> https://github.com/NetBSD/src/blob/trunk/lib/libm/arch/powerpc/fenv.c
> ->fenv.h :
> https://github.com/NetBSD/src/blob/trunk/sys/arch/powerpc/include/fenv.h
> musl: https://git.musl-libc.org/cgit/musl/tree/src/fenv/powerpc64
>
> thanks
> eshan
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Request to provide feedback to the GSoC memory protection proposal draft

2020-03-23 Thread Utkarsh Rai 
Based on feedback from Dr.@Gedare Bloom  and @Peter
Dufault   I have made changes to my proposal draft, it
would be very helpful if the members of the community can provide further
feedback on the same. I would in particular request the community to review
the 'Work Package Flow' and 'GSoC Timeline' section of the proposal.

Regards,
Utkarsh Rai.

 GSOC2020_ Rai_Memory_Protection

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-littlevgl PATCH] Add README

2020-03-23 Thread Gedare Bloom 
Please add the maintainer info for the package, and/or devel@rtems.org
for questions (just in case someone picks this up somehow without
RTEMS!)

On Mon, Mar 23, 2020 at 12:44 PM Vijay Kumar Banerjee
 wrote:
>
> ---
>  README.md | 34 ++
>  1 file changed, 34 insertions(+)
>  create mode 100644 README.md
>
> diff --git a/README.md b/README.md
> new file mode 100644
> index 000..161e4d9
> --- /dev/null
> +++ b/README.md
> @@ -0,0 +1,34 @@
> +RTEMS LittlevGL
> +===
> +
> +Welcome to RTEMS LittlevGL (lvgl). This package builds the lvgl library using
> +waf with the required settings for running it with rtems. The lvgl drivers 
> are
> +adapted to the BSD framebuffer and hence requires the latest rtems-libbsd 
> build.
> +
> +About LittlevGL
> +---
> +
> +LittlevGL is a lightweight graphics library for embedded GUI applications. It
> +can be configured using the `lv_conf.h` and the `lv_drv_conf.h` files that 
> are
> +in the top of the rtems-littlevgl directory.
> +
> +The documentation is available at:
> +https://docs.littlevgl.com/en/html/index.html
> +
> +Building and installing rtems-littlevgl
> +---
> +
> +```
> +git clone git://git.rtems.org/packages/rtems-littlevgl.git
> +git submodule update
> +./waf configure --prefix=/path/to/rtems/5
> +./waf build install
> +```
> +
> +Writing embedded GUI app using rtems-littlevgl
> +--
> +
> +The rtems-examples repository has a sample lvgl hello world application that 
> can
> +be followed for reference on how to write and build an application with lvgl.
> +The sample app can be found here:
> +https://git.rtems.org/rtems-examples/tree/lvgl/hello/test.c
> --
> 2.21.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Sources for adding ftw.h

2020-03-23 Thread Joel Sherrill 
On Mon, Mar 23, 2020 at 9:17 AM Eshan Dhawan 
wrote:

> hello everyone,
> As @Vaibhav Guptatold the FreeBSD and
> NetBSD implemenattio of ftw.h requirs fts.h which inturn requires
> sys/mount.h which requirs many other headres that are not yet implemented
> so creating a dependencies chain
> requiring to add 10-15 more headers just to add ftw.h
> So I started searching alternative sources to add ftw.h . So i found musl
> also has a implementation for ftw.h as well and it dosent require fts.h to
> be implemented
>
> I would request you all to look into it and see it the implementation is
> useful for RTEMS
> since they have used a different approach to the functions
>
> ftw.h : https://git.musl-libc.org/cgit/musl/tree/include/ftw.h
> ftw.c: https://git.musl-libc.org/cgit/musl/tree/src/legacy/ftw.c
> nftw.c: https://git.musl-libc.org/cgit/musl/tree/src/misc/nftw.c
>

This looks like a better implementation option.

At first glance, it has way fewer dependencies but does require pthread.h
around line 122. newlib may need an feature flag (sys/features.h)
added to know if the target supports pthreads.

This looks WAY WAY more appropriate for newlib. Good find!

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Students: Submit Draft Applications

2020-03-23 Thread Gedare Bloom 
Students,

Please make note of the updated timeline. Reflect this in your proposal.
https://summerofcode.withgoogle.com/dashboard/timeline/

The application deadline remains unchanged.

Thanks,
Gedare

On Sun, Mar 22, 2020 at 12:50 AM suyash singh  wrote:
>
> I have submitted the draft proposal and proof of enrollment
>
> On Sat, Mar 21, 2020 at 4:20 PM Eshan Dhawan  wrote:
>>
>> Will do it ASAP..
>>
>> Thanks for the heads up
>> > On 21-Mar-2020, at 3:55 AM, Gedare Bloom  wrote:
>> >
>> > Hello Aspiring Students,
>> >
>> > I wanted to let you know that you can submit and revise your
>> > application including your "Final" proposal as many times as you like
>> > in the Official website, and that you should do so now and update it
>> > periodically until the deadline. If you don't submit it then you can't
>> > get picked. "Final" is not final. :)
>> >
>> > Gedare
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC Students: Submit Draft Applications

2020-03-23 Thread Gedare Bloom 
On Mon, Mar 23, 2020 at 10:13 PM Gedare Bloom  wrote:
>
> Students,
>
> Please make note of the updated timeline. Reflect this in your proposal.
> https://summerofcode.withgoogle.com/dashboard/timeline/
>
> The application deadline remains unchanged.
>
> Thanks,
> Gedare
>
> On Sun, Mar 22, 2020 at 12:50 AM suyash singh  
> wrote:
> >
> > I have submitted the draft proposal and proof of enrollment
> >
> > On Sat, Mar 21, 2020 at 4:20 PM Eshan Dhawan  
> > wrote:
> >>
> >> Will do it ASAP..
> >>
> >> Thanks for the heads up
> >> > On 21-Mar-2020, at 3:55 AM, Gedare Bloom  wrote:
> >> >
> >> > Hello Aspiring Students,
> >> >
> >> > I wanted to let you know that you can submit and revise your
> >> > application including your "Final" proposal as many times as you like
> >> > in the Official website, and that you should do so now and update it
> >> > periodically until the deadline. If you don't submit it then you can't
> >> > get picked. "Final" is not final. :)
> >> >
> >> > Gedare
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel