On Sun, Jul 17, 2016 at 6:48 PM, wrote:
> From: Pavel Pisa
>
> Memory content changes caused by relocation has to be
> propagated to memory/cache level which is used/snooped
> during instruction cache fill.
> ---
> cpukit/libdl/rtl-elf.c | 3 +++
> cpukit/libdl/rtl-obj.c | 67
> ++
On Sun, Jul 17, 2016 at 6:48 PM, wrote:
> From: Pavel Pisa
>
> Next cache operations should work on most of cores now
>
> rtems_cache_flush_entire_data()
> rtems_cache_invalidate_entire_data()
> rtems_cache_invalidate_entire_instruction()
>
> Instruction cache invalidate works on the first
Hello Sebastian,
thanks for the comments
On Tuesday 19 of July 2016 11:48:07 Sebastian Huber wrote:
> Hello Pavel,
>
> On 14/07/16 15:04, Pavel Pisa wrote:
> > The overflow of 64-bit ticks and 34 bit for seconds packed timespec
> > format is not probable but I would like to see support for infini
Hello Saeed,
libdl had been merged to RTEMS mainline.
https://git.rtems.org/rtems/tree/cpukit/libdl
There is even example how to use it in mainline
and shell functions for test from commandline
int shell_dlopen (int argc, char* argv[]);
int shell_dlclose (int argc, char* argv[]);
int shell_dlsy
Hi,
For the slingshot (RTEMS fault-injection tool) I need to dynamically link
test cases into the test suite(s) and execute them on-the-fly.
With a google search on "rtems libdl", I found two pointers for libdl:
1. https://git.rtems.org/chrisj/rtl.git/
https://git.rtems.org/chrisj/rtl-host.git/
Hello Pavel,
On 14/07/16 15:04, Pavel Pisa wrote:
The overflow of 64-bit ticks and 34 bit for seconds packed timespec
format is not probable but I would like to see support for infinite
operation there even if it cost halving range of the most distant
timeouts.
with the 34-bits for seconds, we
Hello all,
I'm Vivek Kukreja and i'm working on Capture Engine for GSoC this year. I'm
running rtems 4.12 and I came across an error on running the capture.exe
example to trace user extensions.
The 'ctrace' command is giving an error RTEMS_UNSATISFIED.
I think this error is due to a faulty if co
Hello everyone,
As per the conversation at IRC I booted the testsuit with turning USB and
ethernet on. Also I ran FreeBSD on my Pi and got the bootup log as suggested by
Alan and Chris. Here are some observations.
1. After turning on USB in u-boot, I was getting power on USB devices atached.
(One o
