Re: CentOS 8 - no python
On Mon, Jan 8, 2024 at 9:13 AM Frank Kühndel wrote: > > Hi Joel, > > have a great 2024! > > On 12/24/23 22:16, Joel Sherrill wrote: > > Hi > > > > Trying to bring up Coverity builds on a Centos 8 machine, I ran into > this: > > > > + ../source-builder/sb-set-builder --log=l-sparc.txt > > --prefix=/home/joel/rtems-cron-coverity/tools/6 --mail --mail-to= > > bu...@rtems.org --mail-from=j...@rtems.org 6/rtems-sparc > > > > /usr/bin/env: ‘python’: No such file or directory > > > > There is, in fact, no python executable -- there is python2 and python3. > > > > Suggestions other than adding a symlink? > > In RHEL 9.3 there exists the package python-unversioned-command which > creates a "python" command for "python3". I do not know whether it > 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
Re: BSP for pico and microzed
On Fri, Jul 31, 2020 at 11:43 AM Joel Sherrill wrote: > Hi > > Do any of the existing Zynq variants work on those? I recall posts about > using them but not which variant was used. > The zedboard BSP works as-is on the microzed. However, you almost certainly want to set BSP_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: Cacheable OCM support for the Zynq BSP
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
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
Cacheable OCM support for the Zynq BSP
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: 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 Brandmeyer wrote: > > >>> Instead of treating weak references as a single level of > > >>> indirection, I think you have to treat them as a single overridable > > >>> interface. In a dynamically-linked application, we might try to > > >>> perform an override using the LD_PRELOAD feature. But in a > > >>> statically-linked application we have to do it differently. The > > >>> overriding archive must be named in full, and it must be named as an > > >>> object to be linked instead of a library to be searched. > > >>> Furthermore, an interface can have only one override that ends up in > > >>> the linked application. > > >> Yes, you can only have one strong implementation, otherwise you get > > >> multiple definition errors. > > > > > > I have only ever considered weak references as an overridable > > > interface within a user's application and not layered within RTEMS > > > itself. I am not sure about automatic indirection within an archive. > > Yes, this is one use case. You could use also a normal function in a > > separate file to get something similar. > > > > > > In the case of different heap allocators why not have confdefs.h > > > select the one we want and manage the indirection with a const table > > > of pointers? > > > > Yes it can be done with new configuration options, however, this would > > be my least favorite choice. I created an example how I would like to > > use weak functions: > > > > https://lists.rtems.org/pipermail/devel/2020-April/059196.html > > > Thanks for the code example it was helpful to me. What I understood is > that: > 1) An internal interface may be declared weakly aliased in RTEMS. > 2) Implementations each need to go to a different file. > * Not clear to me if there can be more than 2: 1 weak, 1 strong? > In the linked application, there will be exactly one implementation. You can provide objects with as many strong implementations as you like, as long as there is a clear way to distinguish between them at link time. In this specific example, Mr. Huber lead off with the use of a trivial heap definition: Malloc bumps pointers in a pool, and free does nothing. The other extreme might be a port of jemalloc to RTEMS. You could implement this with the following layout: librtemsbsp.a provides the default RTEMS heap. IIRC it's a single-threaded first-fit search with deferred coalescing. It provides weak references for all of the heap functions: malloc, calloc, posix_memalign, and so on. Some of them can be defined in terms of the more general versions. Instead of hiding that fact as implementation details, they are explicitly documented as such. That way if someone wants to provide an override for the heap, they know exactly which portions must be replaced, and which portions may be left as their defaults. librtems-heap-trivial.a is scoped to provide overrides of the particular functions that it wishes to make strong, and no others. It can probably get away with using the default implementations of calloc and posix_memalign. librtems-heap-jemalloc.a does the same thing. IIRC, it has some special paths set aside for aligned allocation requests, so it would also override the default definition of posix_memalign. All of the heap overriders provide pkg-config files that name the full path to their archives explicitly. Ie, `pkg-config --libs rtems-heap-trivial` would emit "/rtems_root/target_pair/lib/librtems-heap-trivial.a" instead of "-lrtems-heap-trivial". Users are explicitly told about this override point, and that --libs should really be treated more like --objs if such an option exists. Luxury improvement: Teach pkg-config about an --objs flag. > 3) A strong implementation may be pulled in by invoking a different, > non-aliased function implemented in the same file as (one of) the > strong implementations. > A strong implementation may be pulled in by linking one explicitly. The source of the reference is irrelevant. There can be as many strong implementations as you like, but mixing both strong and weak implementations in the same archive is not allowed. > > Am I understanding this? I tried to map this to something in OOP but > the abstraction failed somewhere in my cortex. It is almost like an > interface class where you can instantiate objects of only one of the > implementations. > The closest
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 > > that the object files are listed on the command-line. If the weak one > > is seen first, then the linker will resolve the symbol against the > > weak definition and it won't even search into subsequent archives for > > the strong one. It will merely suppress multiple-definition errors at > > link time. > > > > We ran into this issue in our project when we over-rode some RTEMS > > weak symbols in one of our static archives. Since the dependency > > graph seen by the linker was from one object in librtems.a to another > > object in librtems.a, the only way we could reliably pull in our > > override was by listing our archive as an object to be linked instead > > of as an archive to be searched (ie, named as libour_runtime.a instead > > of -lour_runtime on the link step command). > > For the linker weak functions are like ordinary functions during the > symbol resolving phase. If the linker finds the weak one first, then it > is happy and stops searching. Correct, that's why it behaves this way. > If you encounter problems like this, then > weak functions are used for the wrong thing. > Exhibit A: zynq_setup_mmu_and_cache. It is referred to only by the BSP's startup sequence. So it is a reference from librtemsbsp to librtemsbsp by default. I don't think it's being used for the wrong thing. > > I would like to use weak functions with one level of indirection. For > example an application can use two features A and B. Both use an > interface C. If only A is used, then C can be implemented via D or E. If > B is used, then C must be implemented via E. For this you can use a weak > implementation D of interface C in module of A and a strong > implementation E in module of B. > In the proposed case of using weak references for the heap, which implementation gets pulled in depends on whether or not the object files listed on the command line reference the heap or not. If the only references are within static archives, then the application will have difficulty choosing exactly which implementation of the heap gets pulled in. librtemsbsp both depends-on and provides implementations of malloc and free. It's pretty easy to provide a definition of Init() or POSIX_Init() that doesn't directly call malloc or free, for example. Instead of treating weak references as a single level of indirection, I think you have to treat them as a single overridable interface. In a dynamically-linked application, we might try to perform an override using the LD_PRELOAD feature. But in a statically-linked application we have to do it differently. The overriding archive must be named in full, and it must be named as an object to be linked instead of a library to be searched. Furthermore, an interface can have only one override that ends up in the linked application. -- Jonathan Brandmeyer PlanetiQ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Use weak functions in the RTEMS core?
There are a couple more disadvantages.
Which definition is pulled into the final link depends on the order that
the object files are listed on the command-line. If the weak one is seen
first, then the linker will resolve the symbol against the weak definition
and it won't even search into subsequent archives for the strong one. It
will merely suppress multiple-definition errors at link time.
We ran into this issue in our project when we over-rode some RTEMS weak
symbols in one of our static archives. Since the dependency graph seen by
the linker was from one object in librtems.a to another object in
librtems.a, the only way we could reliably pull in our override was by
listing our archive as an object to be linked instead of as an archive to
be searched (ie, named as libour_runtime.a instead of -lour_runtime on the
link step command).
Additionally, it is not trivial to verify which implementation was actually
pulled into the linked object. Tools like `nm` and `objdump` just list the
symbol name that ends up in the final ELF. You have to generate a map file
and then examine it to establish which object file provided the resolved
symbol. Maybe this difficulty can be reduced a little with symbol
versioning.
On Wed, Apr 8, 2020 at 9:28 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello,
>
> another use case for a weak function could be the heap. If you only
> allocate memory and never free it, then the implementation can be very
> simple:
>
> https://git.rtems.org/rtems/tree/cpukit/score/src/memoryallocate.c#n49
>
> We could use something like this in heapallocate.c:
>
> RTEMS_WEAK void *_Heap_Allocate_impl(size) { /* Very simple */ }
>
> void *_Heap_Allocate(size)
>
> {
>
>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
--
Jonathan Brandmeyer
PlanetiQ
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: sqlite build failure on BSP bsets
Try this.
I changed the logic which avoids building the sqlite3 shell. Something
about the way it uses libtool made the old `touch`-based method fail.
There's also a bunch of configuration notes that really ought to be more
visible.
On Thu, Apr 2, 2020 at 2:26 PM Joel Sherrill wrote:
>
>
> 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 detailed feedback.
>> >>
>> >> I am torn between:
>> >>
>> >> + deleting sqlite from the BSP bset's
>> >> + requiring tclsh to be installed
>> >> + updating the RSB recipe for sqlite.
>> >>
>> >> Given the desire to get a release out the door. I am prone to the first
>> >> option with a ticket for 5.2 to update sqlite and re-add it to the BSP
>> >> bsets.
>> >
>> >
>> > I can see where you're coming from. That said, even having an obsolete
>> bset in the RSB served as a helpful hint that it worked for someone once
>> upon a time.
>> >
>> >>
>> >>
>> >> Since you obviously use sqlite, if you could tackle updating the RSB
>> >> recipe, that would be great and avoid having to do something expedient
>> >> to get the release out the door.
>> >
>> >
>> > I can make a pass at it. What's the quickest way to iterate on a
>> BSET's rules? I'd rather not have to wait on GCC and crew to rebuild when
>> I get it wrong the first time.
>> >
>> Use --dry-run option
>>
>
> This is good to watch the commands quickly. But you can just explicitly
> build the one package.
>
> $ cd rtems
> $ ../source-builder/sb-set-builder \
> --log=l-sqlite.txt \
> --prefix= \
> databases/sqlite
>
> Should be very close to working. I hacked my command for dtc so there may
> be a typo.
>
> This should take seconds.
>
> It is interesting that you didn't know you can build a single package
> or --dry-run. No foul to you. Just points out that we aren't letting the
> community know the cool things the RSB can do.
>
> I use the source download only option to get people to download things
> for the tools before they come to the Kick Start class. If they have
> network
> issues, can't fetch git, no admin, etc. then they can deal with those with
> their IT. I can't help with someone's draconian policies. :)
>
>
>>
>> >>
>> >> 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
>>
>
--
Jonathan Brandmeyer
Vice President of Software Engineering
PlanetiQ
From 45c727a780a3f52815ba3fc2c7d82fdf0eed273c Mon Sep 17 00:00:00 2001
From: Jonathan Brandmeyer
Date: Thu, 2 Apr 2020 16:35:15 -0600
Subject: [PATCH] databases/sqlite: Update to 3.31.1
---
rtems/config/databases/sqlite-3.31.1-1.cfg | 23 +++
rtems/config/databases/sqlite-3.8.8.1-1.cfg | 27 -
rtems/config/databases/sqlite.bset | 2 +-
source-builder/config/sqlite-3-1.cfg| 44 -
4 files changed, 49 insertions(+), 47 deletions(-)
create mode 100644 rtems/config/databases/sqlite-3.31.1-1.cfg
delete mode 100644 rtems/config/databases/sqlite-3.8.8.1-1.cfg
diff --git a/rtems/config/databases/sqlite-3.31.1-1.cfg b/rtems/config/databases/sqlite-3.31.1-1.cfg
new file mode 100644
index 000..cd2b5ef
--- /dev/null
+++ b/rtems/config/databases/sqlite-3.31.1-1.cfg
@@ -0,0 +1,23 @@
+#
+# Sqlite 3.31.1
+#
+
+%if %{release} == %{nil}
+ %define release 1
+%endif
+
+%include %{_configdir}/rtems-bsp.cfg
+
+#
+# Sqlite Version.
+#
+%define sqlite_version 3.31.1
+%define sqlite_src_version 3310100
+%define sqlite_src_year2020
+
+%hash sha512 sqlite-autoconf-%{sqlite_src_version}.tar.gz d85250ba5f78f0c918880f663741709aba662192f04888b2324a0df17affdf5b8540e8428c6c7315119806e7adad758ea281c9b403c0ad94ac6a9bd1b93fd617
+
+#
+# Sqlite configuration
+#
+%include %{_configdir}/sqlite-3-1.cfg
diff --git a/rtems/config/databases/sqlite-3.8.8.1-1.cfg b/rtems/config/databases/sqlite-3.8.8.1-1.cfg
deleted file mode 100644
index aac06be..000
--- a/rtems/config/databases/sqlite-3.8.8.1-1.cfg
+++ /dev/null
@@ -1,27 +0,0 @@
-#
-# Sqlite 3.8.8.1
-#
-
-%if %{release} == %{nil}
- %define release 1
-%endif
-
-%include %{_configdir}/rtems-bsp.cfg
-
-#
-# Sqlite Version.
-#
-# Sqlite use
Re: sqlite build failure on BSP bsets
On Thu, Apr 2, 2020 at 1:43 PM Joel Sherrill wrote: > Thank you for the detailed feedback. > > I am torn between: > > + deleting sqlite from the BSP bset's > + requiring tclsh to be installed > + updating the RSB recipe for sqlite. > > Given the desire to get a release out the door. I am prone to the first > option with a ticket for 5.2 to update sqlite and re-add it to the BSP > bsets. > I can see where you're coming from. That said, even having an obsolete bset in the RSB served as a helpful hint that it worked for someone once upon a time. > > Since you obviously use sqlite, if you could tackle updating the RSB > recipe, that would be great and avoid having to do something expedient > to get the release out the door. > I can make a pass at it. What's the quickest way to iterate on a BSET's rules? I'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
We just copied the amalgamation's single .c and .h file into our repository and built it as a single object into our application. So the following recommendations come only from an amateur reading of the sources on current rtems-source-builder master. 3.8.8 is pretty old. I'd just jump straight to 3.30.1, the current release. Instead of downloading the sqlite-src zip, download sqlite-amalgamation or sqlite-autoconf and use that as a base. I think the bset's configuration invocation is OK, except that I would set different CFLAGS as described in the next couple of paragraphs. See also https://sqlite.org/amalgamation.html By default, the SQLite write-ahead-log relies on mmap to share some of its index structures between multiple processes. It looks like the current RTEMS bset disables the WAL entirely. Using the WAL gives much better performance than the rollback journal for write-intensive use cases. We used SQLite to reliably buffer up and stitch together segments of our field software update process, which fits the WAL very well. We set `-DSQLITE_MAX_MMAP_SIZE=0 -DSQLITE_DEFAULT_LOCKING_MODE=1` at compile time to avoid mmap's use since RTEMS has neither a VMM nor multiple address spaces. It is still up to the application to choose either the WAL or the rollback journal. See also https://sqlite.org/wal.html#noshm We also added -DSQLITE_ENABLE_MEMSYS5 to our build, and used it to give SQLite its own memory spaces to operate on distinct from the rest of our application. We explicitly provided it with its own MEMSYS5 heap, page cache, and lookaside pools. RTEMS just needs to add the correct compile-time option to support this functionality. It is still up to the application to configure and monitor those memory pools at runtime. 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't >> running the test suite, and you aren't building any of the other >> command-line tools that ship with sqlite, then I don't think you have to >> have TCL. >> > > If the configuration command needs to change in the bset, could you > suggest the command? It would be appreciated. > > --joel > > >> On Thu, Apr 2, 2020 at 11:01 AM Joel Sherrill wrote: >> >>> Hi >>> >>> It looks like tclsh is required to build sqlite. I filed this as a >>> ticket since it is a bit of a broad issue. Added host dependency (docs, >>> sb-check), no BSP bset builds without it installed, etc. >>> >>> + make -j 8 sqlite3.h libsqlite3.la >>> tclsh >>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mksqlite3h.tcl >>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801 >>> >sqlite3.h >>> gcc -g -o mkkeywordhash -DSQLITE_OMIT_WAL=1 >>> -DSQLITE_ENABLE_COLUMN_METADATA=1 >>> >>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mkkeywordhash.c >>> gcc -g -o lemon >>> /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-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/listinfo/devel >> >> >> >> -- >> Jonathan Brandmeyer >> Vice President of Software Engineering >> PlanetiQ >> > -- Jonathan Brandmeyer Vice President of Software Engineering PlanetiQ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: sqlite build failure on BSP bsets
It depends on how you build it. If you use the amalgamation, you aren't running the test suite, and you aren't building any of the other command-line tools that ship with sqlite, then I don't think you have to have TCL. On Thu, Apr 2, 2020 at 11:01 AM Joel Sherrill wrote: > Hi > > It looks like tclsh is required to build sqlite. I filed this as a ticket > since it is a bit of a broad issue. Added host dependency (docs, sb-check), > no BSP bset builds without it installed, etc. > > + make -j 8 sqlite3.h libsqlite3.la > tclsh > /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mksqlite3h.tcl > /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801 > >sqlite3.h > gcc -g -o mkkeywordhash -DSQLITE_OMIT_WAL=1 > -DSQLITE_ENABLE_COLUMN_METADATA=1 > > /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-3.8.8.1-powerpc-rtems5-1/build-xc/../sqlite-src-3080801/tool/mkkeywordhash.c > gcc -g -o lemon > /home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sqlite-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/listinfo/devel -- Jonathan Brandmeyer Vice President of Software Engineering PlanetiQ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Builtin memcpy() requirements
Small improvements inline:
On Fri, Dec 20, 2019 at 1:25 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello,
>
> while working on a test case for
>
> https://devel.rtems.org/ticket/3767
>
> I tried to find the right test suite for it. At first I thought that
> this is a unit test
> (testsuites/unit/compiler/tc-misaligned-builtin-memcpy.c). However, I
> now think that we should have a requirement for this function. The test
> case is more or less clear:
>
> T_TEST_CASE(MisalignedBuiltinMemcpy)
> {
> double a;
> double b;
> char buf[2 * sizeof(double)];
>
buf has the alignment of char. Although it is likely to be aligned to
sizeof(int), it very well could be less than that. In C11 and newer, you
can use alignas() to force buf to have the alignment of double.
> void *p;
>
> p = [0];
p = (void *)((uintptr_t)p | 1);
>
IMO, this reads a bit clearer if p is just a char*. Then you would
initialize it to the address of buf[1] to force the misalignment.
> RTEMS_OBFUSCATE_VARIABLE(p);
> a = 123e4;
> RTEMS_OBFUSCATE_VARIABLE(a);
> a *= a;
> memcpy(p, , sizeof(a));
> RTEMS_OBFUSCATE_VARIABLE(p);
> memcpy(, p, sizeof(b));
> T_eq(a, b, "%f == %f", a, b);
> }
>
> It is obvious that such a memcpy() operation should work. In general, we
> assume in RTEMS that the compiler does the right job. However, on some
> architectures we have to select the right compiler options and this is
> clearly under full control of the RTEMS BSP. I think we should add
> something like this to the RTEMS requirements:
>
> A call of memcpy() in C from a pointer to a double value to a misaligned
> destination buffer shall store the double value in the destination buffer.
>
> The formulation is quite specific, but I was not able to formulate it
> more generic and keep it testable.
I've worked on at least one system where double's were silently equivalent
to float. Maybe a sized integer type such as int64_t would be a better
candidate for the test case?
> We have to keep in mind here that we
> are not interested in the memcpy() C library function, but rather the
> compiler 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: dl06
On Tue, Nov 19, 2019 at 5:13 PM Chris Johns wrote: > On 19/11/19 5:36 pm, Sebastian Huber wrote: > > On 19/11/2019 01:59, Chris Johns wrote: > >> On 18/11/19 7:12 pm, Sebastian Huber wrote: > > >> I am fine with tar being used if configure magic is used to select it. > This may > >> expose RTEMS tar support bugs, I cannot remember now. > > > > Is tar supported by RTEMS? The last time I tried to use didn't work as > far as I > > remember. Maybe it is related to our two independent untar solutions > > ( and rtems_tarfs_load()). > > I am using it in some applications but I cannot remember how so I suppose > the > answer is yes. Joel reminded me yesterday it was ustar or something like > that > which has caused us problems. > Since you mentioned it, https://devel.rtems.org/ticket/3823 RTEMS 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: 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_linfile(). > We stopped using rtems-bin2c in our project, because the performance was so poor for larger files. Both bin2c and gcc were very slow. We've replaced that workflow with something based on GNU AS `.incbin` instead, which is fast enough to be unnoticeable. ___ 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 4MByte RAM mapped to the 4MByte boundary. I don't know what the actual rationale is, but this definitely isn't it. The DDR physical address mapping is fixed. The lower 256k can be mapped to DRAM or on-chip SRAM depending on system settings. The range from 256k - 1M is either inaccessible or mapped to DRAM. The range from 1M - 4M is always mapped to DRAM. Its an application-profile processor, which is why the typical sizes are 512M or 1024M (SoC maximum) for DRAM. See also Xilinx UG585, section 4.1. The chip's reset defaults are for 192 kB of OCM to be mapped low, and 64 kB to be mapped high with address filtering disabled. HTH, Jonathan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: C++ Guide for RTEMS Tools?
On Tue, Aug 27, 2019 at 12:08 PM Sebastian Huber wrote: > > Hello, > > since C++ and Python seems to be the preferred languages for RTEMS Tools I > think we need also a C++ guide. I would not re-invent the wheel and just pick > up something existing. The Google C++ Style doesn't seem to be completely > stupid and it is supported out of the box by clang-format. So, my proposal is > to just use it along with: > > clang-format -style=Google -i some-file.cc If RTEMS is going to adopt clang-format, I suggest that you provide a .clang-format file in the source root that captures your preferences. That way, if you choose to use Google style + deviations its straightforward to do so. The command becomes `clang-format -style=file -i some-file.cc` which is the most common way that third-party tools use it anyway. > > The Google C++ Style leaves some white space choices undefined. If we choose > this style, these gaps should be closed for RTEMS. Using a .clang-format file makes it easier to express exactly where RTEMS falls on some of those choices. For example, the Google base style uses majority-vote-in-this-file to align pointer and 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: [PATCH] RTEMS BSP Buildset
On Mon, Aug 12, 2019 at 12:10 AM Chris Johns wrote: > >>> If it boots via a device tree, then the RTEMS BSP should do this as well. Current generation petalinux generates a device tree for Linux. > >> > >> How would you integrate the Xilinx tools to handle this, ie ps7_init and > >> friends? IMO, RTEMS doesn't need to incorporate the functionality of the Xilinx bootloaders. It just needs to cooperate with them. Clock init, I/O init and FPGA fabric init are all in the scope of the bootloader. Some things can be scoped into user application code (such as fabric re-initialization). But I don't really expect RTEMS to manage SDRAM initialization. RTEMS should just deal with the memory map and system clock frequencies that it is given. It would be nice to have some additional driver support for the things that RTEMS already has hardware abstractions for. But it isn't outrageously difficult to use Xilinx bare-metal drivers as a base for application code in the RTEMS environment. Xilinx' licenses are liberal enough to allow it. > > I don't know the Xilinx Zynq good enough. How do yo get the device > > capabilities > > and memory map if you don't have a device tree? The device tree is an open > > format for this purpose. > > Yeah good question. The Xilinx SDK is designed to pick up a range of defined > values from generated header files, this is the bare metal 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 provides fixed base addresses for the minimal set of peripherals needed to boot RTEMS, and that's about it. -- Jonathan Brandmeyer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] RTEMS BSP Buildset
On Wed, Aug 7, 2019 at 7:07 PM Chris Johns wrote:
> I dislike BSP_OPTS for a few reason; I will not expand on that topic here. I
> can
>
>
> 1. Add option support to the RSB. I am not exactly sure how this could be made
> to work but something like ...
>
> --enable-bspopt-bsp-zynq-ram-length=256
A variation on this, is that you could provide an option prefix that
is used to forward options to a particular configuration stage, using
GCC's `-Wa,` and `-Wl,` (aka -Xassembler and -Xlinker) as a model.
That way you don't have to decide at the RSB level by hand which
options are worth supporting natively and which ones aren't - all of
them are supported uniformly. Reasonable prefixes might be `-Xbsp`
and `-Xlibbsd`, for example.
> 2. Add support for RTEMS configure options. This can be done in a similar way
> to
> the languages for gcc as there is only a few valid ones left.
With an option-forwarding prefix, then its easy to decide that the
options which should be supported natively are only the ones that are
common to all of the BSP's. For example, --enable-cxx and
--enable-fortran should definitely be covered by the top-level driver,
for example.
>
> 3. Add generic support to the BSP or ARM default workspace initialise code to
> call something like `bsp_workspace_begin()` and `bsp_workspace_end()` that are
> weak functions in RTEMS returning the linkcmd values. A user can add these
> functions to their BSP support code to override. This type of support would
> let
> the RPi use the generic support.
>
> 4. Do all the above and ban any new BSP_OPTS being added to a BSP in
> preference
> of weak symbol runtime calls. I feel a number of existing BSP_OPTS could be
> removed this way.
I'm also keenly interested in seeing how far the device tree support
gets. At least for the Zynq family, passing some options to RTEMS
from the bootloader via device tree could be a convenient workflow.
My project is leveraging the existing weak symbol support for
overriding some of the default clock speeds. It mostly works.
However, the nature of weak symbol support in the linker makes this
fragile. Its easy to make a subtle change in the link command line
that silently pulls in RTEMS incorrect (for my board) definition of
the symbol instead of the one I intended 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] RTEMS BSP Buildset
On Sun, Jul 21, 2019 at 6:13 PM wrote: > > This series of patches adds BSP buildset support to the RSB. A top level > BSP buildset can be added that can include the tools, kernel and 3rd party > packages, such as libbsd. A single buildset command will build and install > a complete BSP development environment: > > $ ../source-builder/sb-buildset --prefix=$HOME/development/bbb \ > --log=bbb.txt \ > 5/bsps/beagleboneblack What is the correct way to pass additional configuration options to the different configuration stages? My team is using the xilinx_zynq_zedboard BSP, except that we use a number of different customizations. We enable fortran support when building the toolchain. We use a few --enable and --disable options to RTEMS configure, as well as pass BSP_ZYNQ_RAM_LENGTH and BSP_CONSOLE_MINOR as arguments to RTEMS' configure. Thanks, Jonathan Brandmeyer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Attempt to get rid of -qrtems
Closely related, the .pc files installed for each bsp under lib/pkgconfig also add the -qrtems argument to cflags. On Thu, Jun 27, 2019 at 5:35 PM Chris Johns wrote: > > On 27/6/19 10:08 pm, Sebastian Huber wrote: > > I would like to get rid of the -qrtems command for 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.rtems.org/mailman/listinfo/devel -- Jonathan Brandmeyer Vice President of Software Engineering PlanetiQ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Adding support for new Ethernet PHY
I ran into some device tree support for this phy in sys/gnu/dts/include/dt-bindings/net/ti-dp83867.h It looks like configuration information that would be fed to the generic mii_fdt driver somehow. Thanks for the tip re: ukphy. What exactly does "basic support without any extras" entail? 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 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 Brandmeyer > > > > Hello Jonathan, > > if there is already a PHY driver for that PHY, you basically just follow > the steps from "How to Import Code from FreeBSD" in the libbsd > CONTRIBUTING.md. PHYs should be quite simple so it would be about: > > - Add the files to libbsd.py > - Run ./freebsd-to-rtems.py -R and ./freebsd-to-rtems.py > - Commit the _unchanged_ imported files. > - Commit libbsd.py and (if necessary) changes. > - Add the driver reference to nexus-devices (if it is a officially > supported BSP) or to your application. > > If it is supported, it should be most likely one of the files in > freebsd-org/sys/dev/mii. But to be honest: I didn't find it on a quick > look. Where did you find the support? > > On the other hand: The DP83867E seems to have the default registers. If > you only need basic support without any extras, the generic ukphy (short > for UnKnown PHY) driver should work. > > Best regards > > Christian Mauderer -- Jonathan Brandmeyer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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 Brandmeyer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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 Brandmeyer wrote: > > 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 > --- a/cpukit/libmisc/shell/main_mfill.c > +++ b/cpukit/libmisc/shell/main_mfill.c > @@ -60,7 +60,7 @@ static int rtems_shell_main_mfill( >/* > * Now fill the memory. > */ > - memset(addr, size, value); > + memset(addr, value, size); > >return 0; > } > -- > 2.11.0 > -- Jonathan Brandmeyer Engineering Director PlanetiQ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[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 --- a/cpukit/libmisc/shell/main_mfill.c +++ b/cpukit/libmisc/shell/main_mfill.c @@ -60,7 +60,7 @@ static int rtems_shell_main_mfill( /* * Now fill the memory. */ - memset(addr, size, value); + memset(addr, value, size); return 0; } -- 2.11.0 ___ 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 --- a/cpukit/libmisc/shell/main_mfill.c +++ b/cpukit/libmisc/shell/main_mfill.c @@ -62,7 +62,7 @@ int rtems_shell_main_mfill( /* * Now fill the memory. */ - memset(addr, size, value); + memset(addr, value, size); return 0; } -- 2.11.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Patch progress
I sent in a couple of patches to rtems-devel last week, and nothing happened. They were both simple one- or two-liners that fixed bugs I happened to run into. Both were small enough that they didn't seem worth the trouble of a trac ticket. What needs to be done to move them forward? 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] 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 off with D set at reset, the clock divider will not be disabled by using RTEMS' definition of the D bit. Tested by using the counter on Xilinx Zynq 7020 to measure some atomic accesses and cache flushing operations. --- cpukit/score/cpu/arm/include/libcpu/arm-cp15.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h b/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h index a7e7542bcb..b3a61d2fe1 100644 --- a/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h +++ b/cpukit/score/cpu/arm/include/libcpu/arm-cp15.h @@ -1604,8 +1604,8 @@ arm_cp15_set_performance_monitors_count_enable_set(uint32_t val) #define ARM_CP15_PMCR_IDCODE(x) ((x) << 16) #define ARM_CP15_PMCR_N(x) ((x) << 11) #define ARM_CP15_PMCR_DP (1U << 5) -#define ARM_CP15_PMCR_X (1U << 3) -#define ARM_CP15_PMCR_D (1U << 4) +#define ARM_CP15_PMCR_X (1U << 4) +#define ARM_CP15_PMCR_D (1U << 3) #define ARM_CP15_PMCR_C (1U << 2) #define ARM_CP15_PMCR_P (1U << 1) #define ARM_CP15_PMCR_E (1U << 0) -- 2.11.0 ___ 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 @@ -60,7 +60,7 @@ static int rtems_shell_main_mfill( /* * Now fill the memory. */ - memset(addr, size, value); + memset(addr, value, size); return 0; } -- 2.11.0 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
