Re: Cacheable OCM support for the Zynq BSP

2020-06-10 Thread Chris Johns
On 11/6/20 12:22 pm, Jonathan Brandmeyer wrote: > On Wed, Jun 10, 2020 at 8:08 PM Chris Johns > wrote: > > Could you please create a ticket for this change and attach the patch? > Please > set the milestone to 6. The change might be OK for 5.2 so a new ticket >

Re: Cacheable OCM support for the Zynq BSP

2020-06-10 Thread Jonathan Brandmeyer
On Wed, Jun 10, 2020 at 8:08 PM Chris Johns wrote: > > Could you please create a ticket for this change and attach the patch? > Please > set the milestone to 6. The change might be OK for 5.2 so a new ticket for > that > milestone can be created once we have the change merged onto master. > >

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

2020-06-10 Thread Chris Johns
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

Re: Cacheable OCM support for the Zynq BSP

2020-06-10 Thread Chris Johns
On 11/6/20 10:10 am, Jonathan Brandmeyer wrote: > On Wed, Jun 10, 2020 at 5:57 PM Chris Johns > wrote: > > On 11/6/20 9:30 am, Jonathan Brandmeyer wrote: > > We've patched the RTEMS kernel in order to support using the Zynq > on-chip > memory > > as

Help in figuring out score objects in RTEMS and ticket #3131

2020-06-10 Thread Utkarsh Rai
Hello, For my GSoC project, user-configurable thread stack protection, I need to track, allocate, and manipulate attributes of shared as well as protected stacks. Dr.Gedare suggested that tracking them with score objects would be a good idea. He also indicated a good place to start and understand

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-10 Thread Chris Johns
On 5/6/20 6:03 pm, jan.som...@dlr.de wrote: > We came across the PPSi library for PTP support some time ago: > https://ohwr.org/project/ppsi > In their documentation its says they started with ptpd and then made an > overhaul of the source code. Interesting. Did you check the licenses and

Re: Cacheable OCM support for the Zynq BSP

2020-06-10 Thread Jonathan Brandmeyer
On Wed, Jun 10, 2020 at 5:57 PM Chris Johns wrote: > On 11/6/20 9:30 am, Jonathan Brandmeyer wrote: > > We've patched the RTEMS kernel in order to support using the Zynq > on-chip memory > > as inner-cacheable memory. The enclosed patch should apply cleanly to > master. > > > > Background:

Re: Cacheable OCM support for the Zynq BSP

2020-06-10 Thread Chris Johns
On 11/6/20 9:30 am, Jonathan Brandmeyer wrote: > We've patched the RTEMS kernel in order to support using the Zynq on-chip > memory > as inner-cacheable memory.  The enclosed patch should apply cleanly to master. > > Background: During normal startup, the ROM bootloader performs vendor-specific

Cacheable OCM support for the Zynq BSP

2020-06-10 Thread Jonathan Brandmeyer
We've patched the RTEMS kernel in order to support using the Zynq on-chip memory as inner-cacheable memory. The enclosed patch should apply cleanly to master. Background: During normal startup, the ROM bootloader performs vendor-specific initialization of core 1, and then sits in a

Re: [PATCH 4/5] libfreebsd: Port OFW to RTEMS

2020-06-10 Thread Christian Mauderer
On 10/06/2020 17:11, Niteesh G. S. wrote: > On Sat, Jun 6, 2020 at 5:40 PM Christian Mauderer > wrote: > > On 04/06/2020 19:43, G S Niteesh Babu wrote: > > The following files have been ported to RTEMS > > 1) openfirm.h > > 2) openfirm.c > > 3)

Re: [PATCH 3/5] libfreebsd: FreeBSD porting helper header

2020-06-10 Thread Christian Mauderer
On 10/06/2020 15:56, Niteesh G. S. wrote: > > On Sat, Jun 6, 2020 at 5:27 PM Christian Mauderer > wrote: > > On 04/06/2020 19:43, G S Niteesh Babu wrote: > > This file serve the purpose as rtems-bsd-kernel-space.h in the > > rtems-libbsd. > > This

Re: [PATCH 2/2] Adding strong and weak definitions

2020-06-10 Thread Sebastian Huber
On 10/06/2020 16:41, Richi Dubey wrote: Hi, Please mark the following required changes: 1) Add: cd rtems-qual/ After git clone and before git submodule init. 2) I am getting the following error on running git submodule update: richi@YouAreAmazing:~/rtems-qual$ git submodule update Cloning

Re: [PATCH 4/5] libfreebsd: Port OFW to RTEMS

2020-06-10 Thread Niteesh G. S.
On Sat, Jun 6, 2020 at 5:40 PM Christian Mauderer wrote: > On 04/06/2020 19:43, G S Niteesh Babu wrote: > > The following files have been ported to RTEMS > > 1) openfirm.h > > 2) openfirm.c > > 3) ofw_fdt.c > > --- > > cpukit/libfreebsd/dev/ofw/ofw_fdt.c | 117 ++- > >

Re: [PATCH 2/2] Adding strong and weak definitions

2020-06-10 Thread Richi Dubey
Hi, Please mark the following required changes: 1) Add: cd rtems-qual/ After git clone and before git submodule init. 2) I am getting the following error on running git submodule update: richi@YouAreAmazing:~/rtems-qual$ git submodule update Cloning into

Re: [PATCH 3/5] libfreebsd: FreeBSD porting helper header

2020-06-10 Thread Niteesh G. S.
On Sat, Jun 6, 2020 at 5:27 PM Christian Mauderer wrote: > On 04/06/2020 19:43, G S Niteesh Babu wrote: > > This file serve the purpose as rtems-bsd-kernel-space.h in the > > rtems-libbsd. > > This file is intended to be included in every source file that > > is to imported from FreeBSD. This is

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

2020-06-10 Thread Sebastian Huber
On 31/05/2020 16:22, Jan Sommer wrote: [...] Some details on the missing tests: --- smpfatal09: This test actually does pass, but because the fatal error handler is executed before the console is initialized, no output is produced. smpclock01.exe: Here CPU0

Re: [PATCH v1 8/9] smpsignal01: Change state before sending the signal

2020-06-10 Thread Sebastian Huber
On 31/05/2020 16:22, Jan Sommer wrote: The signal handler of the consumer might start executing before rtems_signal_send of the producer returns. Therefore change the state to SIG_1_SENT before sending the signal. Sorry, for the delay. This patch is fine. I didn't look at the i386