Cacheable OCM support for the Zynq BSP

cause 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: [

Re: Cacheable OCM support for the Zynq BSP

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 >

Re: Cacheable OCM support for the Zynq BSP

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: BSP for pico and microzed

ZYNQ_RAM_LENGTH=1024M to get access to all of the DRAM. The BSP also works as-is on the 7020 and 7030 Zynq family members as well. -- Jonathan Brandmeyer PlanetiQ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: dl06

On Mon, Nov 18, 2019 at 1:12 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 18/11/2019 08:59, Chris Johns wrote: > > > > > > > Converting to C is a broken path IMO. it does not scale. > > I would convert the individual object files with bin2c and load them > with IMFS_make_li

Re: dl06

S untar doesn't properly handle nested directories. foo/bar.txt unpacks just fine, but foo/bar/baz.txt doesn't, unless foo/ exists first. -- Jonathan Brandmeyer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: Builtin memcpy() requirements

er optimized code for the memcpy() builtin function. > This is going to be difficult to verify without examining the generated assembly code. -mstrict-align would be overkill for some systems. At least on ARMv7 and ARMv8, many instructions do support unaligned accesses, while some other instructions don't. HTH, -- Jonathan Brandmeyer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: sqlite build failure on BSP bsets

-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/lemon.c > /bin/sh: tclsh: command not found > > --joel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman

Re: sqlite build failure on BSP bsets

ime. See also https://sqlite.org/malloc.html HTH, On Thu, Apr 2, 2020 at 11:16 AM Joel Sherrill wrote: > > > On Thu, Apr 2, 2020, 12:09 PM Jonathan Brandmeyer < > jbrandme...@planetiq.com> wrote: > >> It depends on how you build it. If you use the amalgamation, you aren'

Re: sqlite build failure on BSP bsets

x27;d rather not have to wait on GCC and crew to rebuild when I get it wrong the first time. > Chris will eventually wake up in Sydney and chime in. :) > > -- Jonathan Brandmeyer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: sqlite build failure on BSP bsets

; > > On Thu, Apr 2, 2020 at 3:00 PM Gedare Bloom wrote: > >> On Thu, Apr 2, 2020 at 1:57 PM Jonathan Brandmeyer >> wrote: >> > >> > >> > On Thu, Apr 2, 2020 at 1:43 PM Joel Sherrill wrote: >> >> >> >> Thank you for the deta

Re: Use weak functions in the RTEMS core?

t;return _Heap_Allocate_impl(size) > > } > > In heapfree.c: > > void *_Heap_Allocate_impl(size) { /* Complex */ } > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- Jonath

Re: Use weak functions in the RTEMS core?

On Wed, Apr 8, 2020 at 10:30 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 08/04/2020 17:57, Jonathan Brandmeyer wrote: > > > There are a couple more disadvantages. > > > > Which definition is pulled into the final link depends on the order

Re: Use weak functions in the RTEMS core?

On Thu, Apr 9, 2020 at 9:25 AM Gedare Bloom wrote: > On Wed, Apr 8, 2020 at 10:53 PM Sebastian Huber > wrote: > > > > On 09/04/2020 03:32, Chris Johns wrote: > > > > > On 2020-04-09 03:43, Sebastian Huber wrote: > > >> On 08/04/2020 19:34, Jonathan

Adding support for new Ethernet PHY

What does it take to support a new Ethernet PHY in rtems-libbsd? We've got a board with a TI DP83867 family member on it, which appears to have some support in FreeBSD. How can that get pulled into a particular rtems-libbsd BSP? Thanks, -Jonathan Brand

Re: Adding support for new Ethernet PHY

tail? The test environment uses standard gigabit workgroup switches. So as long as it comes up in a full-duplex gigabit mode, we're happy. On Mon, Jun 17, 2019 at 12:09 PM Christian Mauderer wrote: > > On 17/06/2019 18:16, Jonathan Brandmeyer wrote: > > What does it take to su

Re: Attempt to get rid of -qrtems

normal RTEMS > > applications. > > I do not think you can remove -qrtems as it will break all existing configure > scripts. The default needs to be stubs. > > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rte

Re: [PATCH] RTEMS BSP Buildset

NSOLE_MINOR as arguments to RTEMS' configure. Thanks, Jonathan Brandmeyer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] RTEMS BSP Buildset

to provide from my sources. The situation with the Zynq also begs the question, what exactly justifies a new BSP? As near as I can tell, xilinx_zynq_{zc702,zc706,zedboard} only exist as separate BSP's to provide different default values for the various BSP_OPTs. -- Jonathan Brandmeyer __

Re: [PATCH] RTEMS BSP Buildset

l approach Right now, this is the approach I'm using for handing clock information off to RTEMS. I'm overriding the weak symbols `zynq_uart_input_clock`, `a9mpcore_clock_periphclk` and `zynq_setup_mmu_and_cache` to pass information from Xilinx generated headers to RTEMS. RTEMS' Zynq BSP prov

Re: C++ Guide for RTEMS Tools?

reference types' *, &, and &&. If RTEMS has a stronger opinion, then just flip the appropriate switch in your .clang-format file. HTH, -- Jonathan Brandmeyer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: xilinx_zynq_zc702 vs. xilinx_zynq_zc706 memory map

On Wed, Oct 23, 2019 at 6:04 AM Thomas Doerfler wrote: > > Hi, > > most likely the RAM areas have been mapped to the lowest-possible > non-NULL address, and they can be mapped to an address boundary matching > the RAM size. zc702 has a 1MByte ram, mapped to the 1MByte boundary, > zc706 has a 4MByt

Re: CentOS 8 - no python

exists in CentOS 8. Similarly, Debian 11 and Ubuntu 20.04 LTS dropped /usr/bin/python as well. Debian 12 introduced the following workaround package, which we are using to support RSB successfully today. https://packages.debian.org/bookworm/python-is-python3 HTH, -- Jonathan Brandmeyer PlanetiQ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

[PATCH] shell: Correct argument order of `mfill`

--- cpukit/libmisc/shell/main_mfill.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpukit/libmisc/shell/main_mfill.c b/cpukit/libmisc/shell/main_mfill.c index d8e2fcf74c..47a55d3a2f 100644 --- a/cpukit/libmisc/shell/main_mfill.c +++ b/cpukit/libmisc/shell/main_mfill.c @@ -6

[PATCH] cpukit/arm: Correct register definition

The register definition for the CP15 PMCR (performance monitor control register) has the bits for X (export enable) and D (clock divider enable) backwards. Correct them according to ARMv7-A/R Architecture Reference Manual, Rev C, Section B4.1.117. Consequences: On an implementation that starts of

Patch progress

https://lists.rtems.org/pipermail/devel/2019-March/025013.html https://lists.rtems.org/pipermail/devel/2019-March/025014.html Thanks, Jonathan Brandmeyer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

[PATCH] shell: Correct argument order of `mfill`

Close #3723. (cherry picked from commit 2e8a66d13f04015c0024a084578f720ceb15ea00) --- cpukit/libmisc/shell/main_mfill.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpukit/libmisc/shell/main_mfill.c b/cpukit/libmisc/shell/main_mfill.c index ecbaec4878..c86e2b6a25 100644 --

[PATCH] shell: Correct argument order of `mfill`

Close #3722. (cherry picked from commit 2e8a66d13f04015c0024a084578f720ceb15ea00) --- cpukit/libmisc/shell/main_mfill.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpukit/libmisc/shell/main_mfill.c b/cpukit/libmisc/shell/main_mfill.c index d8e2fcf74c..47a55d3a2f 100644 --

Re: [PATCH] shell: Correct argument order of `mfill`

I apologize for the vagueness - It isn't clear which one is supposed to go against which branch. The only distinguishing feature is the affected ticket number. ticket 3723 is against the 4.10 branch, while 3722 is against the 4.11 branch. On Tue, Mar 12, 2019 at 9:04 PM Jonathan Brand