subject:"Zynq BSP"

Re: [PATCH] user: Add xilinx-zynq BSP details

2020-09-10 Thread Joel Sherrill

Looks good to me other than Gedare's comments. Glad to see it.

I don't think it goes in the Zynq section but when using networking
with qemu, you tend to need to forward ports. Is there a logical
location for general BSP independent information on using Qemu
with RTEMS?



On Thu, Sep 10, 2020 at 10:30 AM Gedare Bloom  wrote:

> Thanks for the doco. Just a few comments.
>
> On Mon, Sep 7, 2020 at 9:30 PM  wrote:
> >
> > From: Chris Johns 
> >
> > ---
> >  user/bsps/arm/xilinx-zynq.rst | 114 +-
> >  1 file changed, 112 insertions(+), 2 deletions(-)
> >
> > diff --git a/user/bsps/arm/xilinx-zynq.rst
> b/user/bsps/arm/xilinx-zynq.rst
> > index 909b23e..365c336 100644
> > --- a/user/bsps/arm/xilinx-zynq.rst
> > +++ b/user/bsps/arm/xilinx-zynq.rst
> > @@ -1,8 +1,118 @@
> >  .. SPDX-License-Identifier: CC-BY-SA-4.0
> >
> > -.. Copyright (C) 2019 TBD
> > +.. Copyright (C) 2020 Chris Johns (chr...@rtems.org)
> >
> >  xilinx-zynq
> >  ===
> >
> > -TODO.
> > +This BSP supports the Xilinx Zynq range of devices. This family of
> > +devices contain the same ARM hard IP and the different parts have
> > +different sizes of programable logic.
> programmable?
> (Might be a UK/AU English thing, if so let me know :).)
>
> > +
> > +The BSP defaults may need to be adjusted using ``configure`` BSP
> > +options to match the size of memory your board may have.
> > +
> > +Bootloader
> > +--
> > +
> > +The bootloader initialises the Zynq device. The Xilinx tool provide an
> "tools provide" or "tool provides"
>
> > +interface to configure the hardware. This is includes the buses,
> delete 'is'
>
> > +clocks, memory and UART board rate. The output of this is called
> > +``ps7_init`` and it a C file. The Xilinx SDK builds a first stage boot
> "it is a"
>
> > +loader (FSBL) using this file.
> > +
> > +The U-Boot boot loader has it's own FSBL called ``MLO`` to initialise
> no apostrophe: its
>
> > +the hardware.
> > +
> > +Clocks
> > +--
> > +
> > +An application can provide a function called:
> > +
> > +.. code-block:: none
> > +
> > +uint32_t a9mpcore_clock_periphclk(void);
> > +
> > +to return the peripheral clock. Normally this is half the CPU
> > +clock. This function is declared ``weak`` so you can override the
> > +default behaviour by providing it in your application.
> > +
> > +Debugging with xilinx_zynq_a9_qemu
> > +--
> > +
> > +To debug an application add the QEMU options ``-s``. If you need to
> > +debug an initialisation issue also add ``-S``. For example to debug a
> > +networking application you could use:
> > +
> > +.. code-block:: none
> > +
> > +qemu-system-arm -M xilinx-zynq-a9 -m 256M -no-reboot -serial \
> > +null -serial mon:stdio -nographic \
> > +   -net nic,model=cadence_gem -net vde,id=vde0,sock=/tmp/vde1 \
> > +   -kernel myapp.exe \
> > +   -s -S
> > +
> > +Start GDB with the same executable QEMU is running and connect to the
> > +QEMU GDB server:
> > +
> > +.. code-block:: none
> > +
> > +(gdb) target remote :1234
> > +
> > +If your application is crashing set a breakpoint on the fatal error
> > +handler:
> > +
> > +.. code-block:: none
> > +
> > +(gdb) b bsp_fatal_extension
> > +
> > +Enter continue to run the application. Running QEMU loads the
> > +executable and initialises the CPU. If the ``-S`` option is provided
> > +the CPU is held in reset. Without the option the CPU runs starting
> > +RTEMS. Either way you are connecting to set up target and all you need
> "set up the"
>
> > +to do is continue:
> > +
> > +.. code-block:: none
> > +
> > +(gdb) c
> > +
> > +If you have a crash and the breakpoint on ``bsp_fatal_extension`` is
> > +hit, load the following a GDB script:
> delete 'a'
>
> > +
> > +.. code-block:: none
> > +
> > +define arm-crash
> > + set $code = $arg0
> > + set $r0 = ((const rtems_exception_frame *) $code)->register_r0
> > + set $r1 = ((const rtems_exception_frame *) $code)->register_r1
> > + set $r2 = ((const rtems_exception_frame *) $code)->register_r2
> > + set $r3 = ((const rtems_exception_frame *) $code)->register_r3
> > + set $r4 = ((const rtems_exception_frame *) $code)->register_r4
> > + set $r5 = ((const rtems_exception_frame *) $code)->register_r5
> > + set $r6 = ((const rtems_exception_frame *) $code)->register_r6
> > + set $r7 = ((const rtems_exception_frame *) $code)->register_r7
> > + set $r8 = ((const rtems_exception_frame *) $code)->register_r8
> > + set $r9 = ((const rtems_exception_frame *) $code)->register_r9
> > + set $r10 = ((const rtems_exception_frame *) $code)->register_r10
> > + set $r11 = ((const rtems_exception_frame *) $code)->register_r11
> > + set $r12 = ((const rtems_exception_frame *) $code)->register_r12
> > + set $sp = ((const rtems_exception_frame *) $code)->register_sp
> > + set $lr = ((const rtems_exception_frame *) $code)->register_lr
> > + set $pc =

Re: [PATCH] user: Add xilinx-zynq BSP details

2020-09-10 Thread Gedare Bloom

Thanks for the doco. Just a few comments.

On Mon, Sep 7, 2020 at 9:30 PM  wrote:
>
> From: Chris Johns 
>
> ---
>  user/bsps/arm/xilinx-zynq.rst | 114 +-
>  1 file changed, 112 insertions(+), 2 deletions(-)
>
> diff --git a/user/bsps/arm/xilinx-zynq.rst b/user/bsps/arm/xilinx-zynq.rst
> index 909b23e..365c336 100644
> --- a/user/bsps/arm/xilinx-zynq.rst
> +++ b/user/bsps/arm/xilinx-zynq.rst
> @@ -1,8 +1,118 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>
> -.. Copyright (C) 2019 TBD
> +.. Copyright (C) 2020 Chris Johns (chr...@rtems.org)
>
>  xilinx-zynq
>  ===
>
> -TODO.
> +This BSP supports the Xilinx Zynq range of devices. This family of
> +devices contain the same ARM hard IP and the different parts have
> +different sizes of programable logic.
programmable?
(Might be a UK/AU English thing, if so let me know :).)

> +
> +The BSP defaults may need to be adjusted using ``configure`` BSP
> +options to match the size of memory your board may have.
> +
> +Bootloader
> +--
> +
> +The bootloader initialises the Zynq device. The Xilinx tool provide an
"tools provide" or "tool provides"

> +interface to configure the hardware. This is includes the buses,
delete 'is'

> +clocks, memory and UART board rate. The output of this is called
> +``ps7_init`` and it a C file. The Xilinx SDK builds a first stage boot
"it is a"

> +loader (FSBL) using this file.
> +
> +The U-Boot boot loader has it's own FSBL called ``MLO`` to initialise
no apostrophe: its

> +the hardware.
> +
> +Clocks
> +--
> +
> +An application can provide a function called:
> +
> +.. code-block:: none
> +
> +uint32_t a9mpcore_clock_periphclk(void);
> +
> +to return the peripheral clock. Normally this is half the CPU
> +clock. This function is declared ``weak`` so you can override the
> +default behaviour by providing it in your application.
> +
> +Debugging with xilinx_zynq_a9_qemu
> +--
> +
> +To debug an application add the QEMU options ``-s``. If you need to
> +debug an initialisation issue also add ``-S``. For example to debug a
> +networking application you could use:
> +
> +.. code-block:: none
> +
> +qemu-system-arm -M xilinx-zynq-a9 -m 256M -no-reboot -serial \
> +null -serial mon:stdio -nographic \
> +   -net nic,model=cadence_gem -net vde,id=vde0,sock=/tmp/vde1 \
> +   -kernel myapp.exe \
> +   -s -S
> +
> +Start GDB with the same executable QEMU is running and connect to the
> +QEMU GDB server:
> +
> +.. code-block:: none
> +
> +(gdb) target remote :1234
> +
> +If your application is crashing set a breakpoint on the fatal error
> +handler:
> +
> +.. code-block:: none
> +
> +(gdb) b bsp_fatal_extension
> +
> +Enter continue to run the application. Running QEMU loads the
> +executable and initialises the CPU. If the ``-S`` option is provided
> +the CPU is held in reset. Without the option the CPU runs starting
> +RTEMS. Either way you are connecting to set up target and all you need
"set up the"

> +to do is continue:
> +
> +.. code-block:: none
> +
> +(gdb) c
> +
> +If you have a crash and the breakpoint on ``bsp_fatal_extension`` is
> +hit, load the following a GDB script:
delete 'a'

> +
> +.. code-block:: none
> +
> +define arm-crash
> + set $code = $arg0
> + set $r0 = ((const rtems_exception_frame *) $code)->register_r0
> + set $r1 = ((const rtems_exception_frame *) $code)->register_r1
> + set $r2 = ((const rtems_exception_frame *) $code)->register_r2
> + set $r3 = ((const rtems_exception_frame *) $code)->register_r3
> + set $r4 = ((const rtems_exception_frame *) $code)->register_r4
> + set $r5 = ((const rtems_exception_frame *) $code)->register_r5
> + set $r6 = ((const rtems_exception_frame *) $code)->register_r6
> + set $r7 = ((const rtems_exception_frame *) $code)->register_r7
> + set $r8 = ((const rtems_exception_frame *) $code)->register_r8
> + set $r9 = ((const rtems_exception_frame *) $code)->register_r9
> + set $r10 = ((const rtems_exception_frame *) $code)->register_r10
> + set $r11 = ((const rtems_exception_frame *) $code)->register_r11
> + set $r12 = ((const rtems_exception_frame *) $code)->register_r12
> + set $sp = ((const rtems_exception_frame *) $code)->register_sp
> + set $lr = ((const rtems_exception_frame *) $code)->register_lr
> + set $pc = ((const rtems_exception_frame *) $code)->register_pc
> + set $cpsr = ((const rtems_exception_frame *) $code)->register_cpsr
> +   end
> +
> +Enter the command:
> +
> +.. code-block:: none
> +
> +(gdb) arm-crash code
> +
> +
> +Enter ``bt`` to see the stack back trace.
> +
> +The script moves the context back to the crash location. You should be
> +able to view variables and inspect the stack.
> +
> +The fatal error handler runs inside an exception context that is not
> +the one than generated the exception.
s/than/that

> --
> 2.24.1
>
>

[PATCH] user: Add xilinx-zynq BSP details

2020-09-07 Thread chrisj

From: Chris Johns 

---
 user/bsps/arm/xilinx-zynq.rst | 114 +-
 1 file changed, 112 insertions(+), 2 deletions(-)

diff --git a/user/bsps/arm/xilinx-zynq.rst b/user/bsps/arm/xilinx-zynq.rst
index 909b23e..365c336 100644
--- a/user/bsps/arm/xilinx-zynq.rst
+++ b/user/bsps/arm/xilinx-zynq.rst
@@ -1,8 +1,118 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
-.. Copyright (C) 2019 TBD
+.. Copyright (C) 2020 Chris Johns (chr...@rtems.org)
 
 xilinx-zynq
 ===
 
-TODO.
+This BSP supports the Xilinx Zynq range of devices. This family of
+devices contain the same ARM hard IP and the different parts have
+different sizes of programable logic.
+
+The BSP defaults may need to be adjusted using ``configure`` BSP
+options to match the size of memory your board may have.
+
+Bootloader
+--
+
+The bootloader initialises the Zynq device. The Xilinx tool provide an
+interface to configure the hardware. This is includes the buses,
+clocks, memory and UART board rate. The output of this is called
+``ps7_init`` and it a C file. The Xilinx SDK builds a first stage boot
+loader (FSBL) using this file.
+
+The U-Boot boot loader has it's own FSBL called ``MLO`` to initialise
+the hardware.
+
+Clocks
+--
+
+An application can provide a function called:
+
+.. code-block:: none
+
+uint32_t a9mpcore_clock_periphclk(void);
+
+to return the peripheral clock. Normally this is half the CPU
+clock. This function is declared ``weak`` so you can override the
+default behaviour by providing it in your application.
+
+Debugging with xilinx_zynq_a9_qemu
+--
+
+To debug an application add the QEMU options ``-s``. If you need to
+debug an initialisation issue also add ``-S``. For example to debug a
+networking application you could use:
+
+.. code-block:: none
+
+qemu-system-arm -M xilinx-zynq-a9 -m 256M -no-reboot -serial \
+null -serial mon:stdio -nographic \
+   -net nic,model=cadence_gem -net vde,id=vde0,sock=/tmp/vde1 \
+   -kernel myapp.exe \
+   -s -S
+
+Start GDB with the same executable QEMU is running and connect to the
+QEMU GDB server:
+
+.. code-block:: none
+
+(gdb) target remote :1234
+
+If your application is crashing set a breakpoint on the fatal error
+handler:
+
+.. code-block:: none
+
+(gdb) b bsp_fatal_extension
+
+Enter continue to run the application. Running QEMU loads the
+executable and initialises the CPU. If the ``-S`` option is provided
+the CPU is held in reset. Without the option the CPU runs starting
+RTEMS. Either way you are connecting to set up target and all you need
+to do is continue:
+
+.. code-block:: none
+
+(gdb) c
+
+If you have a crash and the breakpoint on ``bsp_fatal_extension`` is
+hit, load the following a GDB script:
+
+.. code-block:: none
+
+define arm-crash
+ set $code = $arg0
+ set $r0 = ((const rtems_exception_frame *) $code)->register_r0
+ set $r1 = ((const rtems_exception_frame *) $code)->register_r1
+ set $r2 = ((const rtems_exception_frame *) $code)->register_r2
+ set $r3 = ((const rtems_exception_frame *) $code)->register_r3
+ set $r4 = ((const rtems_exception_frame *) $code)->register_r4
+ set $r5 = ((const rtems_exception_frame *) $code)->register_r5
+ set $r6 = ((const rtems_exception_frame *) $code)->register_r6
+ set $r7 = ((const rtems_exception_frame *) $code)->register_r7
+ set $r8 = ((const rtems_exception_frame *) $code)->register_r8
+ set $r9 = ((const rtems_exception_frame *) $code)->register_r9
+ set $r10 = ((const rtems_exception_frame *) $code)->register_r10
+ set $r11 = ((const rtems_exception_frame *) $code)->register_r11
+ set $r12 = ((const rtems_exception_frame *) $code)->register_r12
+ set $sp = ((const rtems_exception_frame *) $code)->register_sp
+ set $lr = ((const rtems_exception_frame *) $code)->register_lr
+ set $pc = ((const rtems_exception_frame *) $code)->register_pc
+ set $cpsr = ((const rtems_exception_frame *) $code)->register_cpsr
+   end
+
+Enter the command:
+
+.. code-block:: none
+
+(gdb) arm-crash code
+
+
+Enter ``bt`` to see the stack back trace.
+
+The script moves the context back to the crash location. You should be
+able to view variables and inspect the stack.
+
+The fatal error handler runs inside an exception context that is not
+the one than generated the exception.
-- 
2.24.1

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

Xilinx Zynq BSP and SD/eMMC

2020-08-07 Thread Christian Mauderer

Hello,

is someone using the Xilinx Zynq BSP (xilinx_zynq_zedboard to be exact)
with a SD driver? I didn't find one in libbsd for that BSP.

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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 
> for that
> milestone can be created once we have the change merged onto master.
> 
> 
> https://devel.rtems.org/attachment/ticket/4003

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

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.
>
>
https://devel.rtems.org/attachment/ticket/4003

-- 
Jonathan Brandmeyer
PlanetiQ
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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 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 wait-for-event loop until 
> a
> > special value has been written to a specific address in OCM.  In that
> state, the
> > MMU has not yet been initialized and core 1 is treating OCM as Device 
> memory.
> >
> > By the time the RTEMS boot gets to _CPU_SMP_Start_processor, core 0's 
> MMU has
> > already been initialized with the application-defined memory map.  I'd 
> like to
> > use the on-chip memory as inner cacheable memory in my application.  In
> order to
> > ensure that the kick address write actually becomes visible to core 1, 
> a cache
> > line flush of the affected line is necessary prior to sending the event 
> that
> > wakes up the other core.
> 
> Have the patches been tested with the OCM in the default state?
> 
> Yes.  Performing a cache flush by virtual address to a line which has Device
> memory attributes appears to be harmless.
>  

Great.

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.

A ticket means the change is not lost as a post to this list.

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

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: During normal startup, the ROM bootloader performs
> vendor-specific
> > initialization of  core 1, and then sits in a wait-for-event loop until a
> > special value has been written to a specific address in OCM.  In that
> state, the
> > MMU has not yet been initialized and core 1 is treating OCM as Device
> memory.
> >
> > By the time the RTEMS boot gets to _CPU_SMP_Start_processor, core 0's
> MMU has
> > already been initialized with the application-defined memory map.  I'd
> like to
> > use the on-chip memory as inner cacheable memory in my application.  In
> order to
> > ensure that the kick address write actually becomes visible to core 1, a
> cache
> > line flush of the affected line is necessary prior to sending the event
> that
> > wakes up the other core.
>
> Have the patches been tested with the OCM in the default state?
>

Yes.  Performing a cache flush by virtual address to a line which has
Device memory attributes appears to be harmless.

-- 
Jonathan Brandmeyer
PlanetiQ
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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
> initialization of  core 1, and then sits in a wait-for-event loop until a
> special value has been written to a specific address in OCM.  In that state, 
> the
> MMU has not yet been initialized and core 1 is treating OCM as Device memory.
> 
> By the time the RTEMS boot gets to _CPU_SMP_Start_processor, core 0's MMU has
> already been initialized with the application-defined memory map.  I'd like to
> use the on-chip memory as inner cacheable memory in my application.  In order 
> to
> ensure that the kick address write actually becomes visible to core 1, a cache
> line flush of the affected line is necessary prior to sending the event that
> wakes up the other core.

Have the patches been tested with the OCM in the default state?

Chris

> 
> I also added an invalidation prior to the kick-address write out of an 
> abundance
> of caution.  it shouldn't be necessary, but I had a hard time proving it
> definitively.
> 
> There are a plethora of cache maintenance functions available for the job in
> RTEMS.  I picked an inline helper that operates directly on CP15.  The code's
> commentary suggests that the L2 hasn't been initialized yet, and the
> higher-level `rtems_cache_*_multiple_data_lines` API affects both L1D and L2. 
> Also, I'm using inner-cacheable/outer-shareable memory attributes for OCM
> specifically because of where it sits in the SOC's busswork, so it turns out
> that we *never* need to flush L2 for that memory anyway.
> 
> -- 
> Jonathan Brandmeyer
> PlanetiQ
> 
> ___
> 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

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
wait-for-event loop until a special value has been written to a specific
address in OCM.  In that state, the MMU has not yet been initialized and
core 1 is treating OCM as Device memory.

By the time the RTEMS boot gets to _CPU_SMP_Start_processor, core 0's MMU
has already been initialized with the application-defined memory map.  I'd
like to use the on-chip memory as inner cacheable memory in my
application.  In order to ensure that the kick address write actually
becomes visible to core 1, a cache line flush of the affected line is
necessary prior to sending the event that wakes up the other core.

I also added an invalidation prior to the kick-address write out of an
abundance of caution.  it shouldn't be necessary, but I had a hard time
proving it definitively.

There are a plethora of cache maintenance functions available for the job
in RTEMS.  I picked an inline helper that operates directly on CP15.  The
code's commentary suggests that the L2 hasn't been initialized yet, and the
higher-level `rtems_cache_*_multiple_data_lines` API affects both L1D and
L2.  Also, I'm using inner-cacheable/outer-shareable memory attributes for
OCM specifically because of where it sits in the SOC's busswork, so it
turns out that we *never* need to flush L2 for that memory anyway.

-- 
Jonathan Brandmeyer
PlanetiQ
From 56b57b8e6933316827ebd75990bdc96b189c2adf Mon Sep 17 00:00:00 2001
From: Jonathan Brandmeyer 
Date: Wed, 10 Jun 2020 17:09:57 -0600
Subject: [PATCH] bsp: Support cacheable OCM on the Zynq

... by issuing L1D-specific cache invalidation and flushing instructions
around the kick address.
---
 bsps/arm/xilinx-zynq/start/bspsmp.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/bsps/arm/xilinx-zynq/start/bspsmp.c b/bsps/arm/xilinx-zynq/start/bspsmp.c
index fdb7f85ba6..d6e8759b95 100644
--- a/bsps/arm/xilinx-zynq/start/bspsmp.c
+++ b/bsps/arm/xilinx-zynq/start/bspsmp.c
@@ -28,6 +28,7 @@
 #include 
 
 #include 
+#include 
 
 bool _CPU_SMP_Start_processor(uint32_t cpu_index)
 {
@@ -36,11 +37,14 @@ bool _CPU_SMP_Start_processor(uint32_t cpu_index)
*/
   if (cpu_index != 0) {
 volatile uint32_t* const kick_address = (uint32_t*) 0xfff0UL;
+arm_cp15_data_cache_invalidate_line((void *)kick_address);
 _ARM_Data_synchronization_barrier();
 _ARM_Instruction_synchronization_barrier();
 *kick_address = (uint32_t) _start;
 _ARM_Data_synchronization_barrier();
 _ARM_Instruction_synchronization_barrier();
+arm_cp15_data_cache_clean_and_invalidate_line((const void *)kick_address);
+_ARM_Data_synchronization_barrier();
 _ARM_Send_event();
   }
 
-- 
2.20.1

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

Re: Link RAP file error on zynq BSP

2018-11-11 Thread Chris Johns

On 12/10/2018 15:45, jameszxj wrote:
> HI,
>     I run RTEMS on my xilinx z7k board and dynamic load application(RAP 
> format)
> from shell.
> In recent update, i encount a link error when link the RAP file.
> Here is the command and output message:
>                 rtems-ld -n -e PT_Init --base rtems-nsa.elf 
> wsp/build/nssys.elf
> -o wsp/build/nssys.out
>                 error: rap::object: Section index '65522' not found:
> wsp/build/nssys.elf

I have tracked the section number 65522 to being an uninitialised variable in a
module being loaded. For ELF this means:

 int sym1;

creates a symbol record in ELF in libdl of:

rtl: sym:elf:24 name:70:sym1 bind:1  type:1  sect:65522 size:4

The readelf version is:

   24: 0004 4 OBJECT  GLOBAL DEFAULT  COM sym1

I have finally managed to find what out where these sections are defined ...

https://git.rtems.org/rtems/tree/cpukit/include/sys/exec_elf.h#n538

Peng Fan came across this issue in GSoC 2013 (2012?) on the sparc but we could
not find anything in the standards or supporting code to tell what it was and
why it existed. We seem to have just missed this detail.

The `rtems-ld` linker has support for this section hard coded into it but it is
restricted to the sparc architecture. Now I have something in the standard
headers to work with I should be able to handle this case cleanly and on all
supported archs.

James, there is no need for a test case.

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

Re: Link RAP file error on zynq BSP

2018-11-10 Thread Chris Johns

On 15/10/18 9:39 pm, jameszxj wrote:
>>It should be fixed with this commit:
> 
>> https://git.rtems.org/rtems/commit/?id=186a0b1dc017b1e2e44620f8d6274dc1c6ba09d1
> 
> thanks, compile is ok. but rtems-ld still has a error
> 
> outputter:application: wsp/build/nssys.out
> image::close: removing wsp/build/nssys.out
> error: rap::object: Section index '65522' not found: wsp/build/nssys.elf
> make: *** [Makefile:103: nssys.elf] Error 10
> 
> should  rtems-ld be patch too?
> 

James, you do have a test case I can use to look into this?

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

Re: Link RAP file error on zynq BSP

2018-10-15 Thread jameszxj

>It should be fixed with this commit:

> https://git.rtems.org/rtems/commit/?id=186a0b1dc017b1e2e44620f8d6274dc1c6ba09d1

thanks, compile is ok. but rtems-ld still has a error


outputter:application: wsp/build/nssys.out
image::close: removing wsp/build/nssys.out
error: rap::object: Section index '65522' not found: wsp/build/nssys.elf
make: *** [Makefile:103: nssys.elf] Error 10


should  rtems-ld be patch too?

>-- 
>Sebastian Huber, embedded brains GmbH

>Address : Dornierstr. 4, D-82178 Puchheim, Germany
>Phone   : +49 89 189 47 41-16
>Fax : +49 89 189 47 41-09
>E-Mail  : sebastian.hu...@embedded-brains.de
>PGP : Public key available on request.

>Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Link RAP file error on zynq BSP

2018-10-15 Thread Sebastian Huber


On 15/10/2018 10:16, jameszxj wrote:


*From: * "Sebastian Huber";
*Date: * Mon, Oct 15, 2018 02:43 PM
*To: * "devel";
*Cc: * "jameszxj";
*Subject: * Re: Link RAP file error on zynq BSP

On 15/10/2018 08:16, jameszxj wrote:
>> 
d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/../../../../arm-rtems5/bin/ld.exe: 


>> wsp/build/nssys.elf section `.unexpected_sections' will not fit in
>> region `UNEXPECTED_SECTIONS'
>> collect2.exe: error: ld returned 1 exit status

>Please have a look at the linker map file to figure out what these
>sections are.


.unexpected_sections
                0x0001        0x0
 *(*)
 .tm_clone_table
                0x0001        0x0 
d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/thumb/armv7-a/neon/hard/crtbegin.o

 .tm_clone_table
                0x0001        0x0 
d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/thumb/armv7-a/neon/hard/crtend.o

                0x0001 __TMC_END__
END GROUP
LOAD 
d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/thumb/armv7-a/neon/hard/crtend.o
LOAD 
d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/thumb/armv7-a/neon/hard/crtn.o

OUTPUT(wsp/build/nssys.elf elf32-littlearm)



It should be fixed with this commit:

https://git.rtems.org/rtems/commit/?id=186a0b1dc017b1e2e44620f8d6274dc1c6ba09d1

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: Link RAP file error on zynq BSP

2018-10-15 Thread Sebastian Huber


On 15/10/2018 08:16, jameszxj wrote:
d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/../../../../arm-rtems5/bin/ld.exe: 
wsp/build/nssys.elf section `.unexpected_sections' will not fit in 
region `UNEXPECTED_SECTIONS'

collect2.exe: error: ld returned 1 exit status


Please have a look at the linker map file to figure out what these 
sections are.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: Link RAP file error on zynq BSP

2018-10-15 Thread jameszxj

>


>On 12/10/18 10:05 am, Joel Sherrill wrote:
>>>
>>>
>>> On Thu, Oct 11, 2018 at 11:45 PM jameszxj >> > wrote:
>>>
>>> HI,
>>> I run RTEMS on my xilinx z7k board and dynamic load application(RAP
>>> format) from shell.
>>> In recent update, i encount a link error when link the RAP file.
>>> Here is the command and output message:
>>> rtems-ld -n -e PT_Init --base rtems-nsa.elf
>>> wsp/build/nssys.elf -o wsp/build/nssys.out
>>> error: rap::object: Section index '65522' not found:
>>> wsp/build/nssys.elf
>>>
>>> At last I found the bsp_spec file has been modified,  
>>> "*link:%{!qrtems:
>>> %(old_link)} %{qrtems: -dc -dp -N}" was removed
>>> from the bsp_spec file.  Add this line to the file, ld is OK.
>>>Why removed these lines?
>>>
>>>
>>> The long-term goal is to remove the bsp_specs. I made a sweep making them 
>>> more
>>> consistent and have a set of patches against gcc master which eliminates 
>>> them on
>>> many architectures. Working so the details are implied by GCC.
>>>
>>> So let's look at the options and see which one has an impact which mattered 
>>> that
>>> I didn't catch. This is the description of these options from ld's man page:
>>>
>>>   -N
>>>--omagic
>>>Set the text and data sections to be readable and writable.  
>>> Also,
>>>do not page-align the data segment, and disable linking against
>>>shared libraries.  If the output format supports Unix style magic
>>>numbers, mark the output as "OMAGIC". Note: Although a writable
>>>text section is allowed for PE-COFF targets, it does not conform 
>>> to
>>>the format specification published by Microsoft.
>>>
>>>   -d
>>>   -dc
>>>-dp These three options are equivalent; multiple forms are supported
>>>for compatibility with other linkers.  They assign space to 
>>> common
>>>symbols even if a relocatable output file is specified (with -r).
>>>The script command "FORCE_COMMON_ALLOCATION" has the same effect.
>>>
>>> I'm going to guess that it is -dc/-dp but have no idea how this would 
>>> impact RAP
>>> except to confuse the code.
>>>
>>> Can you try adding adding the options one at a time until you make it work? 
>>> Then
>>> Chris can figure out why it breaks RAP.>>


>I have tried this,just add -dc/-dp do not make it work.>


>>I suspect there is a section that is present which is needed that is not being
>>handled in the RAP toolkit code. That RAP format merges some sections in 
>>rtems-ld.>>


>Probably like this, and I just test it use just one simple source file, 
>uninitialized variable



uninitialized global variable
>cause this error. If I initialize the variable, link is fine.>
>


>>James, if you can make a test file that generates the error then create a 
>>ticket
>>and attach the code I can take a look.>>


>>>
>>>Does the newest RTEMS support the loading of incrementally linked ELF
>>> files? RAP format runs OK, but the link needs BSP image, this
>>> make BSP's development and APP's development not so independent. a 
>>> little
>>> pity, :)
>>>
>>> This is a Chris question.
>>>
>>James, if you do not provide a base image, ie no --base option, what 
>>happens?>>


>I am trying to figure out the problem, it maybe has sth. to do with the 
>--nostdlib option,
>I need to do more tests. I shall describe the problem more clear later on.>


I compile APP with --nostdlib option, link process need to resolve the symbols 
through base iamge, so BSP image is needed.
And if I remove --nostdlib and add -lc -lm ... , I got a error message:


d:/msys64/opt/rtems/5.1/bin/../lib/gcc/arm-rtems5/7.3.0/../../../../arm-rtems5/bin/ld.exe:
 wsp/build/nssys.elf section `.unexpected_sections' will not fit in region 
`UNEXPECTED_SECTIONS'
collect2.exe: error: ld returned 1 exit status




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

Re: Link RAP file error on zynq BSP

2018-10-14 Thread jameszxj

On 12/10/18 10:05 am, Joel Sherrill wrote:
>> 
>> 
>> On Thu, Oct 11, 2018 at 11:45 PM jameszxj > > wrote:
>> 
>> HI,
>> I run RTEMS on my xilinx z7k board and dynamic load application(RAP
>> format) from shell.
>> In recent update, i encount a link error when link the RAP file.
>> Here is the command and output message:
>> rtems-ld -n -e PT_Init --base rtems-nsa.elf
>> wsp/build/nssys.elf -o wsp/build/nssys.out
>> error: rap::object: Section index '65522' not found:
>> wsp/build/nssys.elf
>> 
>> At last I found the bsp_spec file has been modified,  
>> "*link:%{!qrtems:
>> %(old_link)} %{qrtems: -dc -dp -N}" was removed
>> from the bsp_spec file.  Add this line to the file, ld is OK.
>>Why removed these lines?
>> 
>> 
>> The long-term goal is to remove the bsp_specs. I made a sweep making them 
>> more
>> consistent and have a set of patches against gcc master which eliminates 
>> them on
>> many architectures. Working so the details are implied by GCC.
>> 
>> So let's look at the options and see which one has an impact which mattered 
>> that
>> I didn't catch. This is the description of these options from ld's man page:
>> 
>>   -N
>>--omagic
>>Set the text and data sections to be readable and writable.  Also,
>>do not page-align the data segment, and disable linking against
>>shared libraries.  If the output format supports Unix style magic
>>numbers, mark the output as "OMAGIC". Note: Although a writable
>>text section is allowed for PE-COFF targets, it does not conform 
>> to
>>the format specification published by Microsoft.
>> 
>>   -d
>>   -dc
>>-dp These three options are equivalent; multiple forms are supported
>>for compatibility with other linkers.  They assign space to common
>>symbols even if a relocatable output file is specified (with -r).
>>The script command "FORCE_COMMON_ALLOCATION" has the same effect.
>> 
>> I'm going to guess that it is -dc/-dp but have no idea how this would impact 
>> RAP
>> except to confuse the code. 
>> 
>> Can you try adding adding the options one at a time until you make it work? 
>> Then
>> Chris can figure out why it breaks RAP.>


I have tried this,just add -dc/-dp do not make it work.


>I suspect there is a section that is present which is needed that is not being
>handled in the RAP toolkit code. That RAP format merges some sections in 
>rtems-ld.>


Probably like this, and I just test it use just one simple source file, 
uninitialized variable
cause this error. If I initialize the variable, link is fine.


>James, if you can make a test file that generates the error then create a 
>ticket
>and attach the code I can take a look.>


>> 
>>Does the newest RTEMS support the loading of incrementally linked ELF
>> files? RAP format runs OK, but the link needs BSP image, this
>> make BSP's development and APP's development not so independent. a little
>> pity, :)
>> 
>> This is a Chris question.
>> 
>James, if you do not provide a base image, ie no --base option, what happens?>


I am trying to figure out the problem, it maybe has sth. to do with the 
--nostdlib option,
I need to do more tests. I shall describe the problem more clear later on.


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

Re: Link RAP file error on zynq BSP

2018-10-12 Thread Chris Johns



On 12/10/18 10:05 am, Joel Sherrill wrote:
> 
> 
> On Thu, Oct 11, 2018 at 11:45 PM jameszxj  > wrote:
> 
> HI,
>     I run RTEMS on my xilinx z7k board and dynamic load application(RAP
> format) from shell.
> In recent update, i encount a link error when link the RAP file.
> Here is the command and output message:
>                 rtems-ld -n -e PT_Init --base rtems-nsa.elf
> wsp/build/nssys.elf -o wsp/build/nssys.out
>                 error: rap::object: Section index '65522' not found:
> wsp/build/nssys.elf
> 
>     At last I found the bsp_spec file has been modified,  
> "*link:%{!qrtems:
> %(old_link)} %{qrtems: -dc -dp -N}" was removed
> from the bsp_spec file.  Add this line to the file, ld is OK.
>    Why removed these lines?
> 
> 
> The long-term goal is to remove the bsp_specs. I made a sweep making them more
> consistent and have a set of patches against gcc master which eliminates them 
> on
> many architectures. Working so the details are implied by GCC.
> 
> So let's look at the options and see which one has an impact which mattered 
> that
> I didn't catch. This is the description of these options from ld's man page:
> 
>       -N
>        --omagic
>            Set the text and data sections to be readable and writable.  Also,
>            do not page-align the data segment, and disable linking against
>            shared libraries.  If the output format supports Unix style magic
>            numbers, mark the output as "OMAGIC". Note: Although a writable
>            text section is allowed for PE-COFF targets, it does not conform to
>            the format specification published by Microsoft.
> 
>       -d
>       -dc
>        -dp These three options are equivalent; multiple forms are supported
>            for compatibility with other linkers.  They assign space to common
>            symbols even if a relocatable output file is specified (with -r).
>            The script command "FORCE_COMMON_ALLOCATION" has the same effect.
> 
> I'm going to guess that it is -dc/-dp but have no idea how this would impact 
> RAP
> except to confuse the code. 
> 
> Can you try adding adding the options one at a time until you make it work? 
> Then
> Chris can figure out why it breaks RAP.

I suspect there is a section that is present which is needed that is not being
handled in the RAP toolkit code. That RAP format merges some sections in 
rtems-ld.

James, if you can make a test file that generates the error then create a ticket
and attach the code I can take a look.

> 
>    Does the newest RTEMS support the loading of incrementally linked ELF
> files? RAP format runs OK, but the link needs BSP image, this
> make BSP's development and APP's development not so independent. a little
> pity, :)
> 
> This is a Chris question.
> 
James, if you do not provide a base image, ie no --base option, what happens?

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

Re: Link RAP file error on zynq BSP

2018-10-12 Thread Joel Sherrill

On Thu, Oct 11, 2018 at 11:45 PM jameszxj  wrote:

> HI,
> I run RTEMS on my xilinx z7k board and dynamic load application(RAP
> format) from shell.
> In recent update, i encount a link error when link the RAP file.
> Here is the command and output message:
> rtems-ld -n -e PT_Init --base rtems-nsa.elf
> wsp/build/nssys.elf -o wsp/build/nssys.out
> error: rap::object: Section index '65522' not found:
> wsp/build/nssys.elf
>
> At last I found the bsp_spec file has been modified,
> "*link:%{!qrtems: %(old_link)} %{qrtems: -dc -dp -N}" was removed
> from the bsp_spec file.  Add this line to the file, ld is OK.
>Why removed these lines?
>

The long-term goal is to remove the bsp_specs. I made a sweep making them
more consistent and have a set of patches against gcc master which
eliminates them on many architectures. Working so the details are implied
by GCC.

So let's look at the options and see which one has an impact which mattered
that I didn't catch. This is the description of these options from ld's man
page:

  -N
   --omagic
   Set the text and data sections to be readable and writable.
Also,
   do not page-align the data segment, and disable linking against
   shared libraries.  If the output format supports Unix style magic
   numbers, mark the output as "OMAGIC". Note: Although a writable
   text section is allowed for PE-COFF targets, it does not conform
to
   the format specification published by Microsoft.

  -d
  -dc
   -dp These three options are equivalent; multiple forms are supported
   for compatibility with other linkers.  They assign space to
common
   symbols even if a relocatable output file is specified (with -r).
   The script command "FORCE_COMMON_ALLOCATION" has the same effect.

I'm going to guess that it is -dc/-dp but have no idea how this would
impact RAP except to confuse the code.

Can you try adding adding the options one at a time until you make it work?
Then Chris can figure out why it breaks RAP.


>Does the newest RTEMS support the loading of incrementally linked ELF
> files? RAP format runs OK, but the link needs BSP image, this
> make BSP's development and APP's development not so independent. a little
> pity, :)
>

This is a Chris question.
'

> ___
> 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

Link RAP file error on zynq BSP

2018-10-11 Thread jameszxj

HI,I run RTEMS on my xilinx z7k board and dynamic load application(RAP 
format) from shell.
In recent update, i encount a link error when link the RAP file.
Here is the command and output message:
rtems-ld -n -e PT_Init --base rtems-nsa.elf wsp/build/nssys.elf 
-o wsp/build/nssys.out
error: rap::object: Section index '65522' not found: 
wsp/build/nssys.elf



At last I found the bsp_spec file has been modified,  "*link:%{!qrtems: 
%(old_link)} %{qrtems: -dc -dp -N}" was removed
from the bsp_spec file.  Add this line to the file, ld is OK.
   Why removed these lines?


   Does the newest RTEMS support the loading of incrementally linked ELF files? 
RAP format runs OK, but the link needs BSP image, this
make BSP's development and APP's development not so independent. a little pity, 
:)___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

2015-08-24 Thread Pavel Pisa

Hello Chris and Rohini,

I have returned and catching the emails flow.

But please, consider that for some architectures it is critical
to have MMU table runtime alterable.

I.e. on RPi the actual memory division to cacheable
and peripheral area is know only at runtime. It depends
on user provided content of configuration files on SDcard
and actual boot loader and VideoCore firmware located
on the SDcard.

On the other hand there could exist even ARM systems
where linker script defined
  bsp_translation_table_base = ORIGIN (RAM_MMU)
can be precomputed at compile time and reside in Flash.

But for sure, hardcoding of CP15 setup over all platforms
is incorrect way to go.

As for description how to configure fill the translation table,
i.e. 

  const arm_cp15_start_section_config arm_cp15_start_mmu_config_table[] = {

I do not think that it has to be global and it would be even
better if its type is not declared in
  c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h
because then it can be much easier declared as const on
options.

 BSP_START_DATA_SECTION extern const arm_cp15_start_section_config
  arm_cp15_start_mmu_config_table[];

On the other hand it has quite complex attributes and placement
requirements to be available before memory and workspace
setup, so the global define which enforces these is the best
solution.

We need, for sure, to be able to modify entries in the translation
table at runtime at least during startup phase. When PCI/PCIe becomes
more widespread in embedded/ARM systems then it starts to be even
important because then drivers which find a and map device PCI BARs
into memory space have to select right access and cache variants
according to the device and CPU characteristic. On the other hand,
more new SoC from Ti and FreeScale have option to switch busses
not only to be cache coherent between multiple CPU cores but even
for all/some subset of peripherals. Then even many peripheral
regions can be setup as cached on such systems without need
of special flush, invalidate cache operation before DMA/peripheral
coprocessor data passing.

So please, take in consideration these scenarios.

Making definitions as globals and use of these directly
without passing as parameters of initialization functions
make me worry.

May be some other layering and rearrangement could be better
but static and dynamic (BSP code cotrolled) use options needs
to be provided.

Best wishes,

 Pavel


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

Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

2015-08-24 Thread Rohini Kulkarni

OK, thanks all for the views. That gave plenty insight into the details I
had not thought of earlier. Clearly not the way to go.

But then is such refactoring a good idea? These changes even if modified
will apply only to cp15 ARM BSPs.
On 24 Aug 2015 21:20, Pavel Pisa p...@cmp.felk.cvut.cz wrote:

 Hello Chris and Rohini,

 I have returned and catching the emails flow.

 But please, consider that for some architectures it is critical
 to have MMU table runtime alterable.

 I.e. on RPi the actual memory division to cacheable
 and peripheral area is know only at runtime. It depends
 on user provided content of configuration files on SDcard
 and actual boot loader and VideoCore firmware located
 on the SDcard.

 On the other hand there could exist even ARM systems
 where linker script defined
   bsp_translation_table_base = ORIGIN (RAM_MMU)
 can be precomputed at compile time and reside in Flash.

 But for sure, hardcoding of CP15 setup over all platforms
 is incorrect way to go.

 As for description how to configure fill the translation table,
 i.e.

   const arm_cp15_start_section_config arm_cp15_start_mmu_config_table[] = {

 I do not think that it has to be global and it would be even
 better if its type is not declared in
   c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h
 because then it can be much easier declared as const on
 options.

  BSP_START_DATA_SECTION extern const arm_cp15_start_section_config
   arm_cp15_start_mmu_config_table[];

 On the other hand it has quite complex attributes and placement
 requirements to be available before memory and workspace
 setup, so the global define which enforces these is the best
 solution.

 We need, for sure, to be able to modify entries in the translation
 table at runtime at least during startup phase. When PCI/PCIe becomes
 more widespread in embedded/ARM systems then it starts to be even
 important because then drivers which find a and map device PCI BARs
 into memory space have to select right access and cache variants
 according to the device and CPU characteristic. On the other hand,
 more new SoC from Ti and FreeScale have option to switch busses
 not only to be cache coherent between multiple CPU cores but even
 for all/some subset of peripherals. Then even many peripheral
 regions can be setup as cached on such systems without need
 of special flush, invalidate cache operation before DMA/peripheral
 coprocessor data passing.

 So please, take in consideration these scenarios.

 Making definitions as globals and use of these directly
 without passing as parameters of initialization functions
 make me worry.

 May be some other layering and rearrangement could be better
 but static and dynamic (BSP code cotrolled) use options needs
 to be provided.

 Best wishes,

  Pavel



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

Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

2015-08-24 Thread Gedare Bloom

We should consider how to continue making improvements in this area of RTEMS.

On Mon, Aug 24, 2015 at 1:25 PM, Rohini Kulkarni krohini1...@gmail.com wrote:
 OK, thanks all for the views. That gave plenty insight into the details I
 had not thought of earlier. Clearly not the way to go.

 But then is such refactoring a good idea? These changes even if modified
 will apply only to cp15 ARM BSPs.

 On 24 Aug 2015 21:20, Pavel Pisa p...@cmp.felk.cvut.cz wrote:

 Hello Chris and Rohini,

 I have returned and catching the emails flow.

 But please, consider that for some architectures it is critical
 to have MMU table runtime alterable.

 I.e. on RPi the actual memory division to cacheable
 and peripheral area is know only at runtime. It depends
 on user provided content of configuration files on SDcard
 and actual boot loader and VideoCore firmware located
 on the SDcard.

 On the other hand there could exist even ARM systems
 where linker script defined
   bsp_translation_table_base = ORIGIN (RAM_MMU)
 can be precomputed at compile time and reside in Flash.

 But for sure, hardcoding of CP15 setup over all platforms
 is incorrect way to go.

 As for description how to configure fill the translation table,
 i.e.

   const arm_cp15_start_section_config arm_cp15_start_mmu_config_table[] =
 {

 I do not think that it has to be global and it would be even
 better if its type is not declared in
   c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h
 because then it can be much easier declared as const on
 options.

  BSP_START_DATA_SECTION extern const arm_cp15_start_section_config
   arm_cp15_start_mmu_config_table[];

 On the other hand it has quite complex attributes and placement
 requirements to be available before memory and workspace
 setup, so the global define which enforces these is the best
 solution.

 We need, for sure, to be able to modify entries in the translation
 table at runtime at least during startup phase. When PCI/PCIe becomes
 more widespread in embedded/ARM systems then it starts to be even
 important because then drivers which find a and map device PCI BARs
 into memory space have to select right access and cache variants
 according to the device and CPU characteristic. On the other hand,
 more new SoC from Ti and FreeScale have option to switch busses
 not only to be cache coherent between multiple CPU cores but even
 for all/some subset of peripherals. Then even many peripheral
 regions can be setup as cached on such systems without need
 of special flush, invalidate cache operation before DMA/peripheral
 coprocessor data passing.

 So please, take in consideration these scenarios.

 Making definitions as globals and use of these directly
 without passing as parameters of initialization functions
 make me worry.

 May be some other layering and rearrangement could be better
 but static and dynamic (BSP code cotrolled) use options needs
 to be provided.

 Best wishes,

  Pavel



 ___
 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: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

2015-08-15 Thread Chris Johns

On 15/08/2015 8:14 pm, Rohini Kulkarni wrote:
 
 
 On Fri, Aug 14, 2015 at 12:41 PM, Rohini Kulkarni krohini1...@gmail.com
 mailto:krohini1...@gmail.com wrote:
 
 
 
 On Fri, Aug 14, 2015 at 8:33 AM, Chris Johns chr...@rtems.org
 mailto:chr...@rtems.org wrote:
 
 On 14/08/2015 7:44 am, Rohini Kulkarni wrote:
  ---
 
  -BSP_START_DATA_SECTION static const arm_cp15_start_section_config
  -zynq_mmu_config_table[] = {
  +BSP_START_DATA_SECTION const arm_cp15_start_section_config
  +arm_cp15_start_mmu_config_table[] = {
 ARMV7_CP15_START_DEFAULT_SECTIONS,
 {
   .begin = 0xe000U,
 
 Why not pass the table to the bsp_memory_management_initialize
 call and
 avoid making this table global ? Maybe all these tables should
 be static
 and local to their file's in all ARM bsps that do this type MMU
 set up.
 
 This global table and referencing it in the call limits its use
 and I
 think makes things a little more fragile. See below.
 
 I saw Raspberry Pi and altera define
 the arm_cp15_start_mmu_config_table. The table is declared in the
 arm-cp15-start.h and mminit.c uses this as the default table. So I
 didn't really understand why some had static tables while others didn't.
 

This is confusing and we should settling on one specific way that
supports all use cases. Personally I think the table should not be
global and it should be private to the BSP. It is not clear to me what
advantage we get with this table being global.

 Do all ARMs devices with MMUs have cp15 or is this limited to a
 specific
 family ? The only reason I ask is
 bsp_memory_management_initialize is a
 generic name. 
 
 Not all ARM devices have cp15. The existing definition of
 bsp_memory_management_initialize supports only cp15. The definition
 would not be useful to other devices. And this definition was being
 replicated by some cp15 bsps again. So the reason for making these
 changes.

From what I could see the bsp_memory_management_initialize is at the
shared BSP level which implies this is generic. If it is specific to an
architecture and then specific to sub-set of that architecture I wonder
if should stay.

  
 
 If something else exists does this call need to be updated ?
 
 Yes, a different definition will be required.
 

I see this becoming complex quickly. Making all BSPs with an MMU
dependent means a change for one could break the other dependent BSPs
and this increases the testing on all effected BSPs.

 
 I am still a little confused what the changes gives us. Should
 the RPi
 not use the call and it be removed ? I do not know.
 
  @@ -39,17 +40,15 @@ zynq_mmu_config_table[] = {
   BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void) 
 __attribute__ ((weak));
 
 If all this code is going to be touched I feel adding weak
 versions for
 all boards is a good thing.
 
 The Zynq and I suspect the Cyclone need this because the memory
 mapped
 can depend on what is loaded into the programmable logic (PL)
 side of
 these devices. I currently override the weak Zynq call in production
 code based on the PL logic loaded at run time. I wonder if this
 change
 will break code. I am concerned it needs to get a clean link yet
 we now
 have globals and other code referencing those globals. If the
 file is
 not referenced and nothing else depends on it things are more
 robust. 
 
 I still don't have the deeper insight needed so I don't see
 dependencies. But if having static tables is much more robust then
 we should apply that to all.
 

Someone may add another call to bsp_memory_management_initialize for
some reason as it is a BSP level call and that code references the
global tables which also pulls in a weak version of the BSP call. What
happens to a user's application that has code to override the weak BSP
call to provide a custom MMU table ? We would have the weak and the
non-weak version being linked and I am not sure how the linker would
resolve this. I feel this makes the code fragile.

Having weak version of the MMU initialization is a good thing.

 
 
   BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
  -{
  -  uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
  -ARM_CP15_CTRL_A,
  -ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
  -  );
  -
  - 
 arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
  -ctrl,
  -(uint32_t *) bsp_translation_table_base,
  -ARM_MMU_DEFAULT_CLIENT_DOMAIN,
  -zynq_mmu_config_table[0],
  -

Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

2015-08-15 Thread Rohini Kulkarni

On Fri, Aug 14, 2015 at 12:41 PM, Rohini Kulkarni krohini1...@gmail.com
wrote:



 On Fri, Aug 14, 2015 at 8:33 AM, Chris Johns chr...@rtems.org wrote:

 On 14/08/2015 7:44 am, Rohini Kulkarni wrote:
  ---
 
  -BSP_START_DATA_SECTION static const arm_cp15_start_section_config
  -zynq_mmu_config_table[] = {
  +BSP_START_DATA_SECTION const arm_cp15_start_section_config
  +arm_cp15_start_mmu_config_table[] = {
 ARMV7_CP15_START_DEFAULT_SECTIONS,
 {
   .begin = 0xe000U,

 Why not pass the table to the bsp_memory_management_initialize call and
 avoid making this table global ? Maybe all these tables should be static
 and local to their file's in all ARM bsps that do this type MMU set up.

 This global table and referencing it in the call limits its use and I
 think makes things a little more fragile. See below.

 I saw Raspberry Pi and altera define the arm_cp15_start_mmu_config_table.
 The table is declared in the arm-cp15-start.h and mminit.c uses this as the
 default table. So I didn't really understand why some had static tables
 while others didn't.


 Do all ARMs devices with MMUs have cp15 or is this limited to a specific
 family ? The only reason I ask is bsp_memory_management_initialize is a
 generic name.

 Not all ARM devices have cp15. The existing definition of
 bsp_memory_management_initialize supports only cp15. The definition would
 not be useful to other devices. And this definition was being replicated by
 some cp15 bsps again. So the reason for making these changes.


 If something else exists does this call need to be updated ?

 Yes, a different definition will be required.


 I am still a little confused what the changes gives us. Should the RPi
 not use the call and it be removed ? I do not know.

  @@ -39,17 +40,15 @@ zynq_mmu_config_table[] = {
   BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
 __attribute__ ((weak));

 If all this code is going to be touched I feel adding weak versions for
 all boards is a good thing.

 The Zynq and I suspect the Cyclone need this because the memory mapped
 can depend on what is loaded into the programmable logic (PL) side of
 these devices. I currently override the weak Zynq call in production
 code based on the PL logic loaded at run time. I wonder if this change
 will break code. I am concerned it needs to get a clean link yet we now
 have globals and other code referencing those globals. If the file is
 not referenced and nothing else depends on it things are more robust.

 I still don't have the deeper insight needed so I don't see dependencies.
 But if having static tables is much more robust then we should apply that
 to all.


 
   BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
  -{
  -  uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
  -ARM_CP15_CTRL_A,
  -ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
  -  );
  -
  -  arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
  -ctrl,
  -(uint32_t *) bsp_translation_table_base,
  -ARM_MMU_DEFAULT_CLIENT_DOMAIN,
  -zynq_mmu_config_table[0],
  -RTEMS_ARRAY_SIZE(zynq_mmu_config_table)
  +{
  +  uint32_t bsp_initial_mmu_ctrl_set = ARM_CP15_CTRL_AFE |
 ARM_CP15_CTRL_Z;
  +  uint32_t bsp_initial_mmu_ctrl_clear = ARM_CP15_CTRL_A;
  +
  +  bsp_memory_management_initialize(
  +bsp_initial_mmu_ctrl_set,
  +bsp_initial_mmu_ctrl_clear
 );
   }
  +
  +const size_t arm_cp15_start_mmu_config_table_size =
  +  RTEMS_ARRAY_SIZE(arm_cp15_start_mmu_config_table);

 Same here. I think we should avoid globals.

 Then I think raspberry Pi and altera should also follow this if this is
 much more appropriate.


So what is the way out here?


 Chris

  \ No newline at end of file
 




 --
 Rohini Kulkarni




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

Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

2015-08-14 Thread Rohini Kulkarni

On Fri, Aug 14, 2015 at 8:33 AM, Chris Johns chr...@rtems.org wrote:

 On 14/08/2015 7:44 am, Rohini Kulkarni wrote:
  ---
 
  -BSP_START_DATA_SECTION static const arm_cp15_start_section_config
  -zynq_mmu_config_table[] = {
  +BSP_START_DATA_SECTION const arm_cp15_start_section_config
  +arm_cp15_start_mmu_config_table[] = {
 ARMV7_CP15_START_DEFAULT_SECTIONS,
 {
   .begin = 0xe000U,

 Why not pass the table to the bsp_memory_management_initialize call and
 avoid making this table global ? Maybe all these tables should be static
 and local to their file's in all ARM bsps that do this type MMU set up.

 This global table and referencing it in the call limits its use and I
 think makes things a little more fragile. See below.

I saw Raspberry Pi and altera define the arm_cp15_start_mmu_config_table.
The table is declared in the arm-cp15-start.h and mminit.c uses this as the
default table. So I didn't really understand why some had static tables
while others didn't.


 Do all ARMs devices with MMUs have cp15 or is this limited to a specific
 family ? The only reason I ask is bsp_memory_management_initialize is a
 generic name.

Not all ARM devices have cp15. The existing definition of
bsp_memory_management_initialize supports only cp15. The definition would
not be useful to other devices. And this definition was being replicated by
some cp15 bsps again. So the reason for making these changes.


 If something else exists does this call need to be updated ?

Yes, a different definition will be required.


 I am still a little confused what the changes gives us. Should the RPi
 not use the call and it be removed ? I do not know.

  @@ -39,17 +40,15 @@ zynq_mmu_config_table[] = {
   BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
 __attribute__ ((weak));

 If all this code is going to be touched I feel adding weak versions for
 all boards is a good thing.

 The Zynq and I suspect the Cyclone need this because the memory mapped
 can depend on what is loaded into the programmable logic (PL) side of
 these devices. I currently override the weak Zynq call in production
 code based on the PL logic loaded at run time. I wonder if this change
 will break code. I am concerned it needs to get a clean link yet we now
 have globals and other code referencing those globals. If the file is
 not referenced and nothing else depends on it things are more robust.

I still don't have the deeper insight needed so I don't see dependencies.
But if having static tables is much more robust then we should apply that
to all.


 
   BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
  -{
  -  uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
  -ARM_CP15_CTRL_A,
  -ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
  -  );
  -
  -  arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
  -ctrl,
  -(uint32_t *) bsp_translation_table_base,
  -ARM_MMU_DEFAULT_CLIENT_DOMAIN,
  -zynq_mmu_config_table[0],
  -RTEMS_ARRAY_SIZE(zynq_mmu_config_table)
  +{
  +  uint32_t bsp_initial_mmu_ctrl_set = ARM_CP15_CTRL_AFE |
 ARM_CP15_CTRL_Z;
  +  uint32_t bsp_initial_mmu_ctrl_clear = ARM_CP15_CTRL_A;
  +
  +  bsp_memory_management_initialize(
  +bsp_initial_mmu_ctrl_set,
  +bsp_initial_mmu_ctrl_clear
 );
   }
  +
  +const size_t arm_cp15_start_mmu_config_table_size =
  +  RTEMS_ARRAY_SIZE(arm_cp15_start_mmu_config_table);

 Same here. I think we should avoid globals.

Then I think raspberry Pi and altera should also follow this if this is
much more appropriate.


 Chris

  \ No newline at end of file
 




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

[PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

2015-08-13 Thread Rohini Kulkarni

---
 c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am   |4 +++
 .../libbsp/arm/xilinx-zynq/startup/bspstartmmu.c   |   27 ++--
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am 
b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
index df4aa15..f7b23bd 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
@@ -28,6 +28,7 @@ nodist_include_bsp_HEADERS = ../../shared/include/bootcard.h
 
 include_bsp_HEADERS =
 include_bsp_HEADERS += ../../shared/include/utility.h
+include_bsp_HEADERS += ../../../libbsp/shared/include/mm.h
 include_bsp_HEADERS += ../../shared/include/irq-generic.h
 include_bsp_HEADERS += ../../shared/include/irq-info.h
 include_bsp_HEADERS += ../../shared/include/stackalloc.h
@@ -133,6 +134,9 @@ libbsp_a_CPPFLAGS += -I$(srcdir)/../shared/arm-l2c-310
 # Start hooks
 libbsp_a_SOURCES += startup/bspstarthooks.c startup/bspstartmmu.c
 
+# LIBMM
+libbsp_a_SOURCES += ../shared/mminit.c
+
 ###
 #  Special Rules  #
 ###
diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/startup/bspstartmmu.c 
b/c/src/lib/libbsp/arm/xilinx-zynq/startup/bspstartmmu.c
index c7a1089..e33e18b 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/startup/bspstartmmu.c
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/startup/bspstartmmu.c
@@ -15,12 +15,13 @@
 #define ARM_CP15_TEXT_SECTION BSP_START_TEXT_SECTION
 
 #include bsp.h
+#include bsp/mm.h
 #include bsp/start.h
 #include bsp/arm-cp15-start.h
 #include bsp/arm-a9mpcore-start.h
 
-BSP_START_DATA_SECTION static const arm_cp15_start_section_config
-zynq_mmu_config_table[] = {
+BSP_START_DATA_SECTION const arm_cp15_start_section_config
+arm_cp15_start_mmu_config_table[] = {
   ARMV7_CP15_START_DEFAULT_SECTIONS,
   {
 .begin = 0xe000U,
@@ -39,17 +40,15 @@ zynq_mmu_config_table[] = {
 BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void) __attribute__ 
((weak));
 
 BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
-{
-  uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
-ARM_CP15_CTRL_A,
-ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
-  );
-
-  arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
-ctrl,
-(uint32_t *) bsp_translation_table_base,
-ARM_MMU_DEFAULT_CLIENT_DOMAIN,
-zynq_mmu_config_table[0],
-RTEMS_ARRAY_SIZE(zynq_mmu_config_table)
+{  
+  uint32_t bsp_initial_mmu_ctrl_set = ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z;
+  uint32_t bsp_initial_mmu_ctrl_clear = ARM_CP15_CTRL_A;
+  
+  bsp_memory_management_initialize(
+bsp_initial_mmu_ctrl_set,
+bsp_initial_mmu_ctrl_clear
   );
 }
+
+const size_t arm_cp15_start_mmu_config_table_size =
+  RTEMS_ARRAY_SIZE(arm_cp15_start_mmu_config_table);
\ No newline at end of file
-- 
1.7.9.5

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

Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

2015-08-13 Thread Chris Johns

On 14/08/2015 7:44 am, Rohini Kulkarni wrote:
 ---
  
 -BSP_START_DATA_SECTION static const arm_cp15_start_section_config
 -zynq_mmu_config_table[] = {
 +BSP_START_DATA_SECTION const arm_cp15_start_section_config
 +arm_cp15_start_mmu_config_table[] = {
ARMV7_CP15_START_DEFAULT_SECTIONS,
{
  .begin = 0xe000U,

Why not pass the table to the bsp_memory_management_initialize call and
avoid making this table global ? Maybe all these tables should be static
and local to their file's in all ARM bsps that do this type MMU set up.

This global table and referencing it in the call limits its use and I
think makes things a little more fragile. See below.

Do all ARMs devices with MMUs have cp15 or is this limited to a specific
family ? The only reason I ask is bsp_memory_management_initialize is a
generic name. If something else exists does this call need to be updated ?

I am still a little confused what the changes gives us. Should the RPi
not use the call and it be removed ? I do not know.

 @@ -39,17 +40,15 @@ zynq_mmu_config_table[] = {
  BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void) __attribute__ 
 ((weak));

If all this code is going to be touched I feel adding weak versions for
all boards is a good thing.

The Zynq and I suspect the Cyclone need this because the memory mapped
can depend on what is loaded into the programmable logic (PL) side of
these devices. I currently override the weak Zynq call in production
code based on the PL logic loaded at run time. I wonder if this change
will break code. I am concerned it needs to get a clean link yet we now
have globals and other code referencing those globals. If the file is
not referenced and nothing else depends on it things are more robust.

  
  BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
 -{
 -  uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
 -ARM_CP15_CTRL_A,
 -ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
 -  );
 -
 -  arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
 -ctrl,
 -(uint32_t *) bsp_translation_table_base,
 -ARM_MMU_DEFAULT_CLIENT_DOMAIN,
 -zynq_mmu_config_table[0],
 -RTEMS_ARRAY_SIZE(zynq_mmu_config_table)
 +{  
 +  uint32_t bsp_initial_mmu_ctrl_set = ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z;
 +  uint32_t bsp_initial_mmu_ctrl_clear = ARM_CP15_CTRL_A;
 +  
 +  bsp_memory_management_initialize(
 +bsp_initial_mmu_ctrl_set,
 +bsp_initial_mmu_ctrl_clear
);
  }
 +
 +const size_t arm_cp15_start_mmu_config_table_size =
 +  RTEMS_ARRAY_SIZE(arm_cp15_start_mmu_config_table);

Same here. I think we should avoid globals.

Chris

 \ No newline at end of file
 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Zynq BSP

2014-07-25 Thread emanuel stiebler

On 2014-07-24 03:06, Chris Johns wrote: On 22/07/2014 1:00 am, emanuel 
stiebler wrote:

 On 2014-07-18 18:54, Chris Johns wrote:
   We still use the U-Boot to load it?
   I do not use uboot, rather we have a taken the Xilinx FSBL and
 reworked it.

 Could you at least share this part?
 And thanks for this already, I thought that I had to use u-boot.
 (which I don't mind, it just one more layer of work ;-)  )


 The code is based on Xilinx's FSBL and so I need to sort the licensing
 out before I can make it public.
OK.


   I would like to do a write up of the whole process but it is not a
   priority for my unfunded work.

 :(


 Do not be too unhappy, dealing with the licenses is taking my time and
 that is a good thing.

Hello Chris,
thanks for letting us know. I'm glad somebody is working on the license 
issues.


Thanks again

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

Re: Zynq BSP

2014-07-24 Thread Chris Johns


On 22/07/2014 1:00 am, emanuel stiebler wrote:

On 2014-07-18 18:54, Chris Johns wrote:
  We still use the U-Boot to load it?
  I do not use uboot, rather we have a taken the Xilinx FSBL and
reworked it.

Could you at least share this part?
And thanks for this already, I thought that I had to use u-boot.
(which I don't mind, it just one more layer of work ;-)  )



The code is based on Xilinx's FSBL and so I need to sort the licensing 
out before I can make it public.



  I would like to do a write up of the whole process but it is not a
  priority for my unfunded work.

:(



Do not be too unhappy, dealing with the licenses is taking my time and 
that is a good thing.


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

Re: [PATCH] user: Add xilinx-zynq BSP details

Re: [PATCH] user: Add xilinx-zynq BSP details

[PATCH] user: Add xilinx-zynq BSP details

Xilinx Zynq BSP and SD/eMMC

Re: Cacheable OCM support for the Zynq BSP

Re: Cacheable OCM support for the Zynq BSP

Re: Cacheable OCM support for the Zynq BSP

Re: Cacheable OCM support for the Zynq BSP

Re: Cacheable OCM support for the Zynq BSP

Cacheable OCM support for the Zynq BSP

Re: Link RAP file error on zynq BSP

Re: Link RAP file error on zynq BSP

Re: Link RAP file error on zynq BSP

Re: Link RAP file error on zynq BSP

Re: Link RAP file error on zynq BSP

Re: Link RAP file error on zynq BSP

Re: Link RAP file error on zynq BSP

Re: Link RAP file error on zynq BSP

Re: Link RAP file error on zynq BSP

Link RAP file error on zynq BSP

Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

[PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization

Re: Zynq BSP

Re: Zynq BSP

30 matches

Site Navigation

Mail list logo

Footer information