Re: [PATCH v1 0/9] Enable SMP for pc386 based bsps

2020-06-16 Thread Chris Johns 
On 11/6/20 12:21 pm, Chris Johns wrote:
> On 1/6/20 12:22 am, Jan Sommer wrote:
>> Hello,
>>
>> Here is a patch set which should enable SMP again for the pc386-based BSPs 
>> (mainly tested with pc686).
> 
> Many thanks for these patches and your efforts.
> 
>> So far I only tested it with qemu. Tests on real hardware are pending.
> 
> It would be good to test results for hardware with SMP disabled. If the test
> results do not show any regressions then I am fine with these patches for 
> RTEMS
> 5.2 with SMP documented as experimental. I will take a look at doing this.

I have finally managed to get my test PC to load a iPXE loader and with that I
can boot RTEMS. Without the changes I can run hello.exe and it prints the right
stuff on the monitor however the iPXE boot command line that use to work ...

chain tftp://10.10.5.2/rtems.exe --console=/dev/com1,115200
--printk=/dev/com1,115200

... does not generate any serial output. The output is being redirected and the
serial port because nothing appears on the monitor and I tested the cable is
working with a loop-back jumper.

Is the PC serial port driver broken?

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

RE: [PATCH v1 0/9] Enable SMP for pc386 based bsps

2020-06-16 Thread Jan.Sommer 



> -Original Message-
> From: Chris Johns [mailto:chr...@rtems.org]
> Sent: Tuesday, June 16, 2020 10:18 AM
> To: Sommer, Jan; devel@rtems.org
> Subject: Re: [PATCH v1 0/9] Enable SMP for pc386 based bsps
> 
> On 11/6/20 12:21 pm, Chris Johns wrote:
> > On 1/6/20 12:22 am, Jan Sommer wrote:
> >> Hello,
> >>
> >> Here is a patch set which should enable SMP again for the pc386-based
> BSPs (mainly tested with pc686).
> >
> > Many thanks for these patches and your efforts.
> >
> >> So far I only tested it with qemu. Tests on real hardware are pending.
> >
> > It would be good to test results for hardware with SMP disabled. If the test
> > results do not show any regressions then I am fine with these patches for
> RTEMS
> > 5.2 with SMP documented as experimental. I will take a look at doing this.
> 
> I have finally managed to get my test PC to load a iPXE loader and with that I
> can boot RTEMS. Without the changes I can run hello.exe and it prints the
> right
> stuff on the monitor however the iPXE boot command line that use to work
> ...
> 
> chain tftp://10.10.5.2/rtems.exe --console=/dev/com1,115200
> --printk=/dev/com1,115200
> 
> ... does not generate any serial output. The output is being redirected and
> the
> serial port because nothing appears on the monitor and I tested the cable is
> working with a loop-back jumper.
> 

Sorry for the delay, we had some problems in our lab setup as well.
It is working now again and I could receive the output of ticker via the serial 
line.
I hope I can run the testsuites in the coming nights. Then I can respond to 
your other comments.

Do you have a chance to check the pins of you serial port with an Oscilloscope?
Our board allows in the BIOS to configure the serial port for different 
protocols (RS232 and RS422) maybe some pin mappings are not correct?

Maybe it is of any help to you. Our ipxe script looks like this:

echo Trying to receive IP-address...
dhcp || goto dhcp_failed
echo Received the following IP settings:
route
chain tftp://${net0/next-server}/ticker.exe --console=/dev/com1,115200

:dhcp_failed
echo Failed to acquire configuration via dhcp.
echo Opening shell...
shell

Best regards,

   Jan

> Is the PC serial port driver broken?
> 
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 0/9] Enable SMP for pc386 based bsps

2020-06-16 Thread Joel Sherrill 
On Tue, Jun 16, 2020 at 7:08 AM  wrote:

>
>
> > -Original Message-
> > From: Chris Johns [mailto:chr...@rtems.org]
> > Sent: Tuesday, June 16, 2020 10:18 AM
> > To: Sommer, Jan; devel@rtems.org
> > Subject: Re: [PATCH v1 0/9] Enable SMP for pc386 based bsps
> >
> > On 11/6/20 12:21 pm, Chris Johns wrote:
> > > On 1/6/20 12:22 am, Jan Sommer wrote:
> > >> Hello,
> > >>
> > >> Here is a patch set which should enable SMP again for the pc386-based
> > BSPs (mainly tested with pc686).
> > >
> > > Many thanks for these patches and your efforts.
> > >
> > >> So far I only tested it with qemu. Tests on real hardware are pending.
> > >
> > > It would be good to test results for hardware with SMP disabled. If
> the test
> > > results do not show any regressions then I am fine with these patches
> for
> > RTEMS
> > > 5.2 with SMP documented as experimental. I will take a look at doing
> this.
> >
> > I have finally managed to get my test PC to load a iPXE loader and with
> that I
> > can boot RTEMS. Without the changes I can run hello.exe and it prints the
> > right
> > stuff on the monitor however the iPXE boot command line that use to work
> > ...
> >
> > chain tftp://10.10.5.2/rtems.exe --console=/dev/com1,115200
> > --printk=/dev/com1,115200
> >
> > ... does not generate any serial output. The output is being redirected
> and
> > the
> > serial port because nothing appears on the monitor and I tested the
> cable is
> > working with a loop-back jumper.
> >
>
> Sorry for the delay, we had some problems in our lab setup as well.
> It is working now again and I could receive the output of ticker via the
> serial line.
> I hope I can run the testsuites in the coming nights. Then I can respond
> to your other comments.
>
> Do you have a chance to check the pins of you serial port with an
> Oscilloscope?
> Our board allows in the BIOS to configure the serial port for different
> protocols (RS232 and RS422) maybe some pin mappings are not correct?
>
> Maybe it is of any help to you. Our ipxe script looks like this:
>
> echo Trying to receive IP-address...
> dhcp || goto dhcp_failed
> echo Received the following IP settings:
> route
> chain tftp://${net0/next-server}/ticker.exe --console=/dev/com1,115200
>
> :dhcp_failed
> echo Failed to acquire configuration via dhcp.
> echo Opening shell...
> shell
>

We had this problem trying to set up the embedded PC we use for testing in
the new lab.
When we tried the same hardware with FreeDOS, it worked. When we tried an
old Dell
desktop as the RTEMS PC, the serial port didn't work.

We tried various combinations of computers running RTEMS and the comms
program.
The only common denominator was the one running RTEMS wouldn't give serial
output.

I have these patches ready to push. Chris.. should I push them?

--joel


>
> Best regards,
>
>Jan
>
> > Is the PC serial port driver broken?
> >
> > Chris
> ___
> 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

[PATCH] fenv aarch64 support

2020-06-16 Thread Eshan dhawan 
Signed-off-by: Eshan dhawan 
---
 newlib/libc/machine/aarch64/machine/fenv-fp.h | 156 ++
 newlib/libc/machine/aarch64/sys/fenv.h| 120 ++
 newlib/libm/machine/aarch64/Makefile.am   |  14 +-
 newlib/libm/machine/aarch64/feclearexcept.c   |   7 +
 newlib/libm/machine/aarch64/fegetenv.c|   7 +
 newlib/libm/machine/aarch64/fegetexceptflag.c |   7 +
 newlib/libm/machine/aarch64/fegetround.c  |   7 +
 newlib/libm/machine/aarch64/feholdexcept.c|   7 +
 newlib/libm/machine/aarch64/fenv.c|  57 +++
 newlib/libm/machine/aarch64/feraiseexcept.c   |   7 +
 newlib/libm/machine/aarch64/fesetenv.c|   7 +
 newlib/libm/machine/aarch64/fesetexceptflag.c |   7 +
 newlib/libm/machine/aarch64/fesetround.c  |   7 +
 newlib/libm/machine/aarch64/fetestexcept.c|   7 +
 newlib/libm/machine/aarch64/feupdateenv.c |   7 +
 15 files changed, 423 insertions(+), 1 deletion(-)
 create mode 100644 newlib/libc/machine/aarch64/machine/fenv-fp.h
 create mode 100644 newlib/libc/machine/aarch64/sys/fenv.h
 create mode 100644 newlib/libm/machine/aarch64/feclearexcept.c
 create mode 100644 newlib/libm/machine/aarch64/fegetenv.c
 create mode 100644 newlib/libm/machine/aarch64/fegetexceptflag.c
 create mode 100644 newlib/libm/machine/aarch64/fegetround.c
 create mode 100644 newlib/libm/machine/aarch64/feholdexcept.c
 create mode 100644 newlib/libm/machine/aarch64/fenv.c
 create mode 100644 newlib/libm/machine/aarch64/feraiseexcept.c
 create mode 100644 newlib/libm/machine/aarch64/fesetenv.c
 create mode 100644 newlib/libm/machine/aarch64/fesetexceptflag.c
 create mode 100644 newlib/libm/machine/aarch64/fesetround.c
 create mode 100644 newlib/libm/machine/aarch64/fetestexcept.c
 create mode 100644 newlib/libm/machine/aarch64/feupdateenv.c

diff --git a/newlib/libc/machine/aarch64/machine/fenv-fp.h 
b/newlib/libc/machine/aarch64/machine/fenv-fp.h
new file mode 100644
index 0..d8ec3fc76
--- /dev/null
+++ b/newlib/libc/machine/aarch64/machine/fenv-fp.h
@@ -0,0 +1,156 @@
+/*-
+ * Copyright (c) 2004-2005 David Schultz 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS 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.
+ *
+ * $FreeBSD$
+ */
+
+
+__fenv_static __inline int
+feclearexcept(int __excepts)
+{
+   fexcept_t __r;
+
+   __mrs_fpsr(__r);
+   __r &= ~__excepts;
+   __msr_fpsr(__r);
+   return (0);
+}
+
+__fenv_static inline int
+fegetexceptflag(fexcept_t *__flagp, int __excepts)
+{
+   fexcept_t __r;
+
+   __mrs_fpsr(__r);
+   *__flagp = __r & __excepts;
+   return (0);
+}
+
+__fenv_static inline int
+fesetexceptflag(const fexcept_t *__flagp, int __excepts)
+{
+   fexcept_t __r;
+
+   __mrs_fpsr(__r);
+   __r &= ~__excepts;
+   __r |= *__flagp & __excepts;
+   __msr_fpsr(__r);
+   return (0);
+}
+
+__fenv_static inline int
+feraiseexcept(int __excepts)
+{
+   fexcept_t __r;
+
+   __mrs_fpsr(__r);
+   __r |= __excepts;
+   __msr_fpsr(__r);
+   return (0);
+}
+
+__fenv_static inline int
+fetestexcept(int __excepts)
+{
+   fexcept_t __r;
+
+   __mrs_fpsr(__r);
+   return (__r & __excepts);
+}
+
+__fenv_static inline int
+fegetround(void)
+{
+   fenv_t __r;
+
+   __mrs_fpcr(__r);
+   return ((__r >> _ROUND_SHIFT) & _ROUND_MASK);
+}
+
+__fenv_static inline int
+fesetround(int __round)
+{
+   fenv_t __r;
+
+   if (__round & ~_ROUND_MASK)
+   return (-1);
+   __mrs_fpcr(__r);
+   __r &= ~(_ROUND_MASK << _ROUND_SHIFT);
+   __r |= __round << _ROUND_SHIFT;
+   __msr_fpcr(__r);
+   return (0);
+}
+
+__fenv_static inline int
+fegetenv(fenv_t *__envp)
+{
+   fenv_t __r;
+
+   __mrs_fpcr(__r);
+   *__env

Re: [PATCH v1 0/9] Enable SMP for pc386 based bsps

2020-06-16 Thread Chris Johns 
On 16/6/20 10:55 pm, Joel Sherrill wrote:
> On Tue, Jun 16, 2020 at 7:08 AM mailto:jan.som...@dlr.de>>
> wrote:
> > -Original Message-
> > From: Chris Johns [mailto:chr...@rtems.org ]
> > Sent: Tuesday, June 16, 2020 10:18 AM
> > To: Sommer, Jan; devel@rtems.org 
> > Subject: Re: [PATCH v1 0/9] Enable SMP for pc386 based bsps
> >
> > On 11/6/20 12:21 pm, Chris Johns wrote:
> > > On 1/6/20 12:22 am, Jan Sommer wrote:
> > >> Hello,
> > >>
> > >> Here is a patch set which should enable SMP again for the pc386-based
> > BSPs (mainly tested with pc686).
> > >
> > > Many thanks for these patches and your efforts.
> > >
> > >> So far I only tested it with qemu. Tests on real hardware are 
> pending.
> > >
> > > It would be good to test results for hardware with SMP disabled. If 
> the test
> > > results do not show any regressions then I am fine with these patches 
> for
> > RTEMS
> > > 5.2 with SMP documented as experimental. I will take a look at doing 
> this.
> >
> > I have finally managed to get my test PC to load a iPXE loader and with 
> that I
> > can boot RTEMS. Without the changes I can run hello.exe and it prints 
> the
> > right
> > stuff on the monitor however the iPXE boot command line that use to work
> > ...
> >
> > chain tftp://10.10.5.2/rtems.exe 
> --console=/dev/com1,115200
> > --printk=/dev/com1,115200
> >
> > ... does not generate any serial output. The output is being redirected 
> and
> > the
> > serial port because nothing appears on the monitor and I tested the 
> cable is
> > working with a loop-back jumper.
> >
> 
> Sorry for the delay, we had some problems in our lab setup as well.
> It is working now again and I could receive the output of ticker via the
> serial line.
> I hope I can run the testsuites in the coming nights. Then I can respond 
> to
> your other comments.
> 
> Do you have a chance to check the pins of you serial port with an 
> Oscilloscope?
> Our board allows in the BIOS to configure the serial port for different
> protocols (RS232 and RS422) maybe some pin mappings are not correct?
> 
> Maybe it is of any help to you. Our ipxe script looks like this:
> 
> echo Trying to receive IP-address...
> dhcp || goto dhcp_failed
> echo Received the following IP settings:
> route
> chain tftp://${net0/next-server}/ticker.exe --console=/dev/com1,115200

Mine is close to this. As posted above I have --printk=/dev/com1,115200.

Note, the tester has a bug where it does not correctly handle TFTP exe file
names when there is no filter configured. I will raise a ticket and push the fix
for this soon.

> 
> :dhcp_failed
> echo Failed to acquire configuration via dhcp.
> echo Opening shell...
> shell
> 
> 
> We had this problem trying to set up the embedded PC we use for testing in the
> new lab. 
> When we tried the same hardware with FreeDOS, it worked. When we tried an old 
> Dell
> desktop as the RTEMS PC, the serial port didn't work.

I have a legacy small form factor ITX computer with a standard COM1 RS232 only 
port.

> We tried various combinations of computers running RTEMS and the comms 
> program. 
> The only common denominator was the one running RTEMS wouldn't give serial 
> output.
> 
> I have these patches ready to push. Chris.. should I push them?

Yes I think they are OK to push. I was hoping to have run all the tests by now.

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

GSoC 2020: Weekly Progress Update

2020-06-16 Thread Mritunjay Sharma 
Hello everyone,

Following up as decided to update the weekly progress report on irc
channel on every Wednesday, I am updating the progress on the mailing list
as well.

==Previous Work==

Trying to fix missing files like "install/sh" error
to make the ptpd build run.

==Progress==

Earlier errors have been resolved but a new one popped up in the morning.

Modified source-builder/config/ptpd-2-1.cfg file again,
after Googling a little and following Heinz advice,

%source setup ptpd -q -n ptpd-%{ptpd_version}
%patch setup ptpd -p1


+autoreconf -vfi
+automake --add-missing

cd ${build_top}

%build

After this I made the local ptpd-master again a tar ball and used it,
which fixed the earlier, but now another error has popped up which I
am trying to fix.

The error is as follows:
"/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build:
155:
/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build:
../ptpd-master/configure: not found
shell cmd failed: /bin/sh -ex
 
/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-master-arm-rtems5-1/do-build
error: building ptpd-master-arm-rtems5-1
  See error report: rsb-report-ptpd-master-arm-rtems5-1.txt
Build Set: Time 0:00:00.191542"

==Blockers==

These configure errors are the main blockers.

==Future options==

Looking forward to raise this with the ptpd community
and trying with the help of mentors to fix the problems
as soon as possible.

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

Weekly Project report

2020-06-16 Thread Eshan Dhawan 
Hello everyone,
This is my weekly project progress report that is discussed on the irc
meeting which couldnt be held today.

DATED : 17/JUN/2020

Current Progress:
> Fenv patch for ARM nerged in Newlib
> Sent Patch to add fenv support for MIPS and AARCH64
> Adding confstr() to libbsd is under progress, I ahve added the initial
files.

Goals for the week:
> adding Confstr()
> adding tests FOR Timer_create using CLOCK_MONOTONIC

Blockers:
> Understanding the structure for psxtimer

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

Release snapshot 5.0.0-m2006-2 available

2020-06-16 Thread Chris Johns 
Hello,

I have made a 5.0.0-m2006-2 release snapshot available. The link is ...

https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2006-2

The snapshot contains the recent PC BSP patches from Jan. I am still working in
the legacy printk initialisation or lack of it issue.

Please test and report what works and what does not.

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

Re: [PATCH v1 0/9] Enable SMP for pc386 based bsps

2020-06-16 Thread Chris Johns 
On 17/6/20 8:34 am, Chris Johns wrote:
> On 16/6/20 10:55 pm, Joel Sherrill wrote:
>> On Tue, Jun 16, 2020 at 7:08 AM > >
>> wrote:
>> We had this problem trying to set up the embedded PC we use for testing in 
>> the
>> new lab. 
>> When we tried the same hardware with FreeDOS, it worked. When we tried an 
>> old Dell
>> desktop as the RTEMS PC, the serial port didn't work.
> 
> I have a legacy small form factor ITX computer with a standard COM1 RS232 
> only port.

I have debugged the problem on my hardware and the issue seems to be no serial
port initialisation during start up. There was no call being made to the legacy
ns16550 intialise call ns16550_init.

I am wondering if the improvements to remove code that is not used and the
removal of the console in tests means nothing is left to make the call and we
have depended on it being there. I have a patch I am testing which I will post
soon to add the initialisation to the BSP printk input and output functions.

I am now wondering how many other BSPs could be suffering from the same problem?
Any BSP where the bootloader or some initialisation process handles the printk
set up will not see a problem. For example the xilinx zynq BSP will not see a
problem because the systemZ ps7init set up intialises the UART.

Chris

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

[PATCH] i386/pc: Initialise the printk serial port on first use

2020-06-16 Thread chrisj 
From: Chris Johns 

---
 bsps/i386/pc386/console/conscfg.c|  7 ++--
 bsps/i386/pc386/console/printk_support.c | 42 +++-
 2 files changed, 37 insertions(+), 12 deletions(-)

diff --git a/bsps/i386/pc386/console/conscfg.c 
b/bsps/i386/pc386/console/conscfg.c
index a4ae88626f..8aa8ab5c2a 100644
--- a/bsps/i386/pc386/console/conscfg.c
+++ b/bsps/i386/pc386/console/conscfg.c
@@ -46,15 +46,14 @@
 
   #define CLOCK_RATE(115200 * 16)
 
-  static uint8_t com_get_register(uint32_t addr, uint8_t i)
+  static uint8_t com_get_register(uintptr_t addr, uint8_t i)
   {
-register uint8_t val;
-
+uint8_t val;
 inport_byte( (addr + i), val );
 return val;
   }
 
-  static void com_set_register(uint32_t addr, uint8_t i, uint8_t val)
+  static void com_set_register(uintptr_t addr, uint8_t i, uint8_t val)
   {
 outport_byte( (addr + i), val );
   }
diff --git a/bsps/i386/pc386/console/printk_support.c 
b/bsps/i386/pc386/console/printk_support.c
index d7bc329868..c9e003dab0 100644
--- a/bsps/i386/pc386/console/printk_support.c
+++ b/bsps/i386/pc386/console/printk_support.c
@@ -29,6 +29,28 @@
 
 rtems_device_minor_number BSPPrintkPort = 0;
 
+static bool serialInit;
+static bool serialOK;
+
+static bool serialValid(console_tbl *port)
+{
+  if (port->pDeviceFns) {
+if (!serialInit) {
+  serialOK = true;
+  if (port->pDeviceFns->deviceProbe != NULL) {
+if (!port->pDeviceFns->deviceProbe( BSPPrintkPort ))
+  serialOK = false;
+else if (port->pDeviceFns->deviceInitialize != NULL)
+  port->pDeviceFns->deviceInitialize( BSPPrintkPort );
+else
+  serialOK = false;
+  }
+  serialInit = true;
+}
+  }
+  return serialOK;
+}
+
 void BSP_outch(char ch);
 int BSP_inch(void);
 
@@ -42,10 +64,12 @@ void BSP_outch(char ch)
 
   if ( !isVga ) {
 console_tbl *port = Console_Port_Tbl[BSPPrintkPort];
-if (port->pDeviceFns && port->pDeviceFns->deviceWritePolled) {
-  port->pDeviceFns->deviceWritePolled( BSPPrintkPort, ch );
+if (serialValid(port)) {
+  if (port->pDeviceFns->deviceWritePolled) {
+port->pDeviceFns->deviceWritePolled( BSPPrintkPort, ch );
+  }
+  return;
 }
-return;
   }
 
   #if BSP_ENABLE_VGA
@@ -65,11 +89,13 @@ int BSP_inch(void)
 
   if ( !isVga ) {
 console_tbl *port = Console_Port_Tbl[BSPPrintkPort];
-if (port->pDeviceFns && port->pDeviceFns->deviceRead) {
-  do {
-result = port->pDeviceFns->deviceRead( BSPPrintkPort );
-  } while (result == -1);
-  return result;
+if (serialValid(port)) {
+  if (port->pDeviceFns->deviceRead) {
+do {
+  result = port->pDeviceFns->deviceRead( BSPPrintkPort );
+} while (result == -1);
+return result;
+  }
 }
   }
 
-- 
2.24.1

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

RE: Release snapshot 5.0.0-m2006-2 available

2020-06-16 Thread Jan.Sommer 
Great.
I ran the testsuites without the SMP-patches on hardware last night to have a 
reference. It takes about 8 h and the results are below.

I am building everything again with the release snapshot and will run the 
testsuite for single core this night.
Then, we should know that the patches didn't break anything for existing 
applications.

Cheers,

   Jan

Passed:564
Failed:  7
User Input:  9
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 6
Invalid: 3
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 592
Failures:
 dl01.exe
 dl05.exe
 dl07.exe
 dl08.exe
 dl09.exe
 tmcontext01.exe
 tmfine01.exe
User Input:
 dl10.exe
 monitor.exe
 termios.exe
 top.exe
 ttest01.exe
 tztest.exe
 uid01.exe
 capture.exe
 cdtest.exe
Benchmark:
 dhrystone.exe
 linpack.exe
 whetstone.exe
Timeouts:
 dl02.exe
 dl04.exe
 dl06.exe
 cxx_iostream.exe
 fileio.exe
 spfatal12.exe
Invalid:
 fsnofs01.exe
 fsrfsbitmap01.exe
 fsrofs01.exe
Average test time: 0:00:47.982294
Testing time : 7:53:25.518093

> -Original Message-
> From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Chris Johns
> Sent: Wednesday, June 17, 2020 7:28 AM
> To: Development
> Subject: Release snapshot 5.0.0-m2006-2 available
> 
> Hello,
> 
> I have made a 5.0.0-m2006-2 release snapshot available. The link is ...
> 
> https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2006-2
> 
> The snapshot contains the recent PC BSP patches from Jan. I am still working
> in
> the legacy printk initialisation or lack of it issue.
> 
> Please test and report what works and what does not.
> 
> Thanks
> Chris
> ___
> 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