Re: [PATCH 0/2] Source Builder: Fix UnicodeDecodeError build hang

On 8/5/20 4:22 pm, Anders Montonen wrote: On 8 May 2020, at 9:12, Chris Johns > wrote: On 8/5/20 3:50 pm, Anders Montonen wrote: On a not completely unrelated note, have there been any thoughts about setting a timetable for deprecating Python 2 support now that it is E

Re: [PATCH 0/2] Source Builder: Fix UnicodeDecodeError build hang

On 8 May 2020, at 9:12, Chris Johns wrote: > On 8/5/20 3:50 pm, Anders Montonen wrote: > >> On a not completely unrelated note, have there been any thoughts about >> setting a timetable for deprecating Python 2 support now that it is EOL, eg. >> in RTEMS6? Are there any specific host platforms

Re: GSoC 2020: Implementation of OFW functions

On 07/05/2020 17:19, Niteesh G. S. wrote: > On Thu, May 7, 2020 at 4:07 PM Sebastian Huber > > wrote: > > On 07/05/2020 12:28, Niteesh G. S. wrote: > > > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber > >

Re: [PATCH 0/2] Source Builder: Fix UnicodeDecodeError build hang

On 8/5/20 3:50 pm, Anders Montonen wrote: On 8 May 2020, at 7:36, Chris Johns wrote: On 8/5/20 2:27 pm, Anders Montonen wrote: Hi, On 7 May 2020, at 5:10, Chris Johns wrote: On 7/5/20 9:37 am, Anders Montonen wrote: This patch fixes the UnicodeDecodeError that randomly caused source builde

Re: [PATCH 0/2] Source Builder: Fix UnicodeDecodeError build hang

> On 8 May 2020, at 7:36, Chris Johns wrote: > > On 8/5/20 2:27 pm, Anders Montonen wrote: >> Hi, >>> On 7 May 2020, at 5:10, Chris Johns wrote: >>> >>> On 7/5/20 9:37 am, Anders Montonen wrote: This patch fixes the UnicodeDecodeError that randomly caused source builder to hang. >>>

Re: [PATCH] networking: Increase _SYS_MBUF_LEGACY_MSIZE to 256 to match FreeBSD

I am not gonna push this patch. I have only tried to run loopback and telnetd on rv64. Even though loopback doesn't make RTEMS exit with a failure, but the scn output doesn't look right (compared to riscv32). telnetd scn is identical and succeed on both, but I guess that's just luck. I am not plann

Re: [PATCH] networking: Increase _SYS_MBUF_LEGACY_MSIZE to 256 to match FreeBSD

On 8/5/20 2:52 pm, Sebastian Huber wrote: On 08/05/2020 06:49, Hesham Almatary wrote: On Fri, 8 May 2020 at 05:42, Sebastian Huber wrote: On 07/05/2020 22:12, heshamelmat...@gmail.com wrote: From: Hesham Almatary This commit fixes some run-time errors on 64-bit architectures (e.g., riscv6

Re: [PATCH] networking: Increase _SYS_MBUF_LEGACY_MSIZE to 256 to match FreeBSD

On 08/05/2020 06:48, Hesham Almatary wrote: Hello Chris, Currently sample/loopback.exe fails on risc64 with that error: *** BEGIN OF TEST LOOPBACK *** *** TEST VERSION: 5.0.0.e78c0806cbbf0c9fae5c8c355ea81636b704f908 *** TEST STATE: EXPECTED_PASS *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API

Re: [PATCH] networking: Increase _SYS_MBUF_LEGACY_MSIZE to 256 to match FreeBSD

On 08/05/2020 06:49, Hesham Almatary wrote: On Fri, 8 May 2020 at 05:42, Sebastian Huber wrote: On 07/05/2020 22:12, heshamelmat...@gmail.com wrote: From: Hesham Almatary This commit fixes some run-time errors on 64-bit architectures (e.g., riscv64) in which the tcp header size would overfl

Re: [PATCH] networking: Increase _SYS_MBUF_LEGACY_MSIZE to 256 to match FreeBSD

On Fri, 8 May 2020 at 05:42, Sebastian Huber wrote: > > On 07/05/2020 22:12, heshamelmat...@gmail.com wrote: > > > From: Hesham Almatary > > > > This commit fixes some run-time errors on 64-bit architectures (e.g., > > riscv64) > > in which the tcp header size would overflow 128 bytes. > > I thin

Re: [PATCH] networking: Increase _SYS_MBUF_LEGACY_MSIZE to 256 to match FreeBSD

Hello Chris, Currently sample/loopback.exe fails on risc64 with that error: *** BEGIN OF TEST LOOPBACK *** *** TEST VERSION: 5.0.0.e78c0806cbbf0c9fae5c8c355ea81636b704f908 *** TEST STATE: EXPECTED_PASS *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API *** TEST TOOLS: 9.3.0 20200312 (RTEMS 5, RSB 5

Re: [PATCH] networking: Increase _SYS_MBUF_LEGACY_MSIZE to 256 to match FreeBSD

On 07/05/2020 22:12, heshamelmat...@gmail.com wrote: From: Hesham Almatary This commit fixes some run-time errors on 64-bit architectures (e.g., riscv64) in which the tcp header size would overflow 128 bytes. I think it is a waste of time to use the old network stack with 64-bit architecture

Re: [PATCH 0/2] Source Builder: Fix UnicodeDecodeError build hang

On 8/5/20 2:27 pm, Anders Montonen wrote: Hi, On 7 May 2020, at 5:10, Chris Johns wrote: On 7/5/20 9:37 am, Anders Montonen wrote: This patch fixes the UnicodeDecodeError that randomly caused source builder to hang. In my testing, there was no difference in performance at least under Python

Re: [PATCH 0/2] Source Builder: Fix UnicodeDecodeError build hang

Hi, > On 7 May 2020, at 5:10, Chris Johns wrote: > > On 7/5/20 9:37 am, Anders Montonen wrote: >> This patch fixes the UnicodeDecodeError that randomly caused source >> builder to hang. >> >> In my testing, there was no difference in performance at least under >> Python 3. > > Have you tested

Re: [PATCH] networking: Increase _SYS_MBUF_LEGACY_MSIZE to 256 to match FreeBSD

Hi Hesham, I do not understand the reason here. I thought the TCP header was a fixed size? Chris On 8/5/20 6:12 am, heshamelmat...@gmail.com wrote: From: Hesham Almatary This commit fixes some run-time errors on 64-bit architectures (e.g., riscv64) in which the tcp header size would overfl

Re: Memory Protection project interface details (GSoC 2020)

Hello Utkarsh, I'd suggest you don't spend too much efforts on setting up BBB hardware if you haven't already. Debugging on QEMU with GDB is way easier, and you can consider either qemu-xilinx-zynq-a9 or rpi2 BSPs. Later, you can move your code to BBB if you want, since both are based on ARMv7. O

Re: [PATCH] qemu4.bset: Update to pixman 0.40.0.

Thanks for this. There are other issues with qemu that I am looking into. I will push this patch with me changes once I have something building on FreeBSD. Chris On 8/5/20 8:19 am, Joel Sherrill wrote: --- bare/config/devel/pixman-0.40.0-1.cfg | 19 +++ bare/config/devel/qe

Re: [PATCH rtems_waf] rtems: Add uninstall option to the list of commands

On 8/5/20 4:50 am, Vijay Kumar Banerjee wrote: On Tue, May 5, 2020 at 4:13 PM Chris Johns wrote: Hi Chris, I added support in rtems_waf to test the uninstall function, following the approach that you suggested. I'm attaching the patch here, please have a look. This looks fine. We can work on

[PATCH] qemu4.bset: Update to pixman 0.40.0.

--- bare/config/devel/pixman-0.40.0-1.cfg | 19 +++ bare/config/devel/qemu4.bset | 2 +- 2 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 bare/config/devel/pixman-0.40.0-1.cfg diff --git a/bare/config/devel/pixman-0.40.0-1.cfg b/bare/config/devel/pix

[PATCH] riscv: Mark htif_console_handler in htif.h as extern

From: Hesham Almatary It is defined in htif.c --- bsps/riscv/riscv/include/dev/serial/htif.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bsps/riscv/riscv/include/dev/serial/htif.h b/bsps/riscv/riscv/include/dev/serial/htif.h index b0d83652b..4b16d8746 100644 --- a/bsps/r

[PATCH] riscv: Add an fdt_get_size utility function

From: Hesham Almatary --- bsps/riscv/riscv/start/bspstart.c | 42 +++ 1 file changed, 42 insertions(+) diff --git a/bsps/riscv/riscv/start/bspstart.c b/bsps/riscv/riscv/start/bspstart.c index 888795fca..f6f99c506 100644 --- a/bsps/riscv/riscv/start/bspstart.c +++ b/

[PATCH] networking: Increase _SYS_MBUF_LEGACY_MSIZE to 256 to match FreeBSD

From: Hesham Almatary This commit fixes some run-time errors on 64-bit architectures (e.g., riscv64) in which the tcp header size would overflow 128 bytes. --- cpukit/libnetworking/sys/mbuf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpukit/libnetworking/sys/mbuf.h b/c

Re: [PATCH rtems_waf] rtems: Add uninstall option to the list of commands

On Tue, May 5, 2020 at 4:13 PM Chris Johns wrote: > > > On 5 May 2020, at 5:37 pm, Vijay Kumar Banerjee wrote: > >  > > > On Tue, May 5, 2020 at 9:56 AM Chris Johns wrote: >> >> On 4/5/20 8:16 pm, Vijay Kumar Banerjee wrote: >> > >> > >> > On Mon, May 4, 2020 at 4:39 AM Chris Johns > >

Adding fenv support for ARM

Hello everyone, This the tread to discuss adding fenv support for ARM architecture in newlib. Link to previous thread: https://lists.rtems.org/pipermail/devel/2020-March/058473.html ---FreeBSD Source # https://github.com/freebsd/freebsd/tree/master/lib/msun/arm # https://github.com/freebsd/freebs

Memory Protection project interface details (GSoC 2020)

Hello, This is to ensure that all the interested parties are on the same page before I start my project and can give their invaluable feedback. My GSoC project, providing user-configurable thread stack protection, requires adding architecture-specific low-level support as well as high-level API sup

Re: GSoC 2020: Implementation of OFW functions

On Thu, May 7, 2020 at 4:07 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 07/05/2020 12:28, Niteesh G. S. wrote: > > > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber > > > > wrote: > > > > On 07/05/2020 09:35, Niteesh G. S. wro

Re: [PATCH] termios: Replace rtems_termios_isig_status_code

This looks OK. Everything is still public enough where a user application can register their own -C catching function at that level. Thanks for doing this. --joel On Thu, May 7, 2020 at 1:52 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Merge the rtems_termios_isig_status_co

Re: GSoC 2020: Implementation of OFW functions

On 07/05/2020 12:28, Niteesh G. S. wrote: On Thu, May 7, 2020 at 1:21 PM Sebastian Huber > wrote: On 07/05/2020 09:35, Niteesh G. S. wrote: > This is what I was trying to convey in one of the previous mails. > https://lists.rtems.org/pipe

Re: [PATCH] libtests/tar0[12]: Add tar archive

OK to push to master for 5.1. This is a nice solution. Thanks Chris On 6/5/20 3:36 pm, Sebastian Huber wrote: Do not generate the test tar archive on the host computer since not all file systems support symbolic links. Close #3968. --- testsuites/libtests/Makefile.am | 18 ++

Re: GSoC 2020: Implementation of OFW functions

On Thu, May 7, 2020 at 1:21 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 07/05/2020 09:35, Niteesh G. S. wrote: > > > This is what I was trying to convey in one of the previous mails. > > https://lists.rtems.org/pipermail/devel/2020-May/059717.html > > But in that mail, I w

Re: GSoC 2020: Implementation of OFW functions

On 07/05/2020 09:35, Niteesh G. S. wrote: This is what I was trying to convey in one of the previous mails. https://lists.rtems.org/pipermail/devel/2020-May/059717.html But in that mail, I was planning to replace KOBJLOOKUP. Should I start working on it? From the top of my mind, the following ha

Re: GSoC 2020: Implementation of OFW functions

On Thu, May 7, 2020 at 12:10 PM Christian Mauderer < christian.maude...@embedded-brains.de> wrote: > Hello Niteesh, > > On 07/05/2020 06:58, Niteesh G. S. wrote: > [...] > > Is there any chance that we will be working with the new build system > > for this GSoC project? > > I think there is a good

Re: [PATCH 0/2] Source Builder: Fix UnicodeDecodeError build hang

Hi, > On 7 May 2020, at 5:10, Chris Johns wrote: > > On 7/5/20 9:37 am, Anders Montonen wrote: >> This patch fixes the UnicodeDecodeError that randomly caused source >> builder to hang. >> >> In my testing, there was no difference in performance at least under >> Python 3. > > Have you tested