Re: Re: Is rtems available on a 4-cores cortex A72 (ARM-v8a) bsp?

2020-07-24 Thread small...@aliyun.com
xilinx-zynqmp BSP has a ARM cortex A53 processor. Is it a ARMv8-A architeture?



small...@aliyun.com
 
From: Sebastian Huber
Date: 2020-07-24 12:49
To: small...@aliyun.com; joel
CC: devel
Subject: Re: Is rtems available on a 4-cores cortex A72 (ARM-v8a) bsp?
On 24/07/2020 03:09, small...@aliyun.com wrote:
 
> 32-bit mode is OK.
> Does it fully support SMP and MMU in this bsp?
RTEMS supports SMP on ARMv7-A and in particular the xilinx-zynqmp BSP. 
The MMU is statically set up. RTEMS doesn't support processes with 
virtual memory.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[GSoC 2020]: Doubts in building RSB Recipe for EPICS for multiple architectures

2020-07-24 Thread Mritunjay Sharma
Hello all,

To update you all, I have sent the first version of PATCHES that
implement an RSB recipe for EPICS7 building with RTEMS5 for pc-386.

While the build was successful for pc-386, I have doubts and need
suggestions on how to make it work across different BSP targets.
I will request Chris to show me the path and if possible then also review
the patches.

Gedare has suggested using sed but it will be really nice if I can get a
a more clear idea on how to implement it.

The existing changes in the file can be seen here:


https://github.com/RTEMS/rtems-source-builder/compare/master...mritunjaysharma394:epics-support

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

Re: Strong APA Scheduler : First Draft

2020-07-24 Thread Richi Dubey
Hi,

With Dr. Butterfield's help, I've made the changes to implement the FIFO
Queue using chain. I am not accustomed to coding for embedded systems, so I
am not completely sure if I should be using malloc

or not.

Someone, please review the following changes:

FIFO Implementaion and Queue traversal:
https://richidubey.github.io/Strong-APA-Documentation/html/schedulerstrongapa_8c_source.html#l00159

The structure I have defined to be used with Chain_Control:
https://richidubey.github.io/Strong-APA-Documentation/html/structCPU.html

Thank you,
Richi.

On Fri, Jul 24, 2020 at 11:28 AM Richi Dubey  wrote:

> Hi Andrew,
>
> Your suggestion helps and I am going to work on it today. Thank you.
>
> On Thu, Jul 23, 2020 at 8:14 PM Andrew Butterfield <
> andrew.butterfi...@cs.tcd.ie> wrote:
>
>> Hi Richi,
>>
>>  a quick answer to 1 below
>>
>> On 23 Jul 2020, at 15:20, Richi Dubey  wrote:
>> 1)Both the algorithms require the use of a FIFO Queue to support the
>> insert and dequeue operations.
>>
>> I believe we can use chains and use the chain_append() and combination of
>> _Chain_Extract  and _Chain_First or just _Chain_First and node->next to
>> achieve the FIFO requirements.
>>
>>
>>
>> You might want to look at chain_get() - it removes the first element, so
>> does a FIFO protocol in tandem with chain_append()
>>
>> Regards,
>>   Andrew
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>> 
>> Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
>> Lero@TCD, Head of Software Foundations & Verification Research Group
>> School of Computer Science and Statistics,
>> Room G.39, O'Reilly Institute, Trinity College, University of Dublin
>>  http://www.scss.tcd.ie/Andrew.Butterfield/
>> 
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Small doubt in how chain works in RTEMS

2020-07-24 Thread Richi Dubey
Hi,

I have a doubt regarding this.

We do
  rtems_chain_append( &chain1, &node1.Node );

And get the node pointer when we use:
  rtems_chain_node*p= rtems_chain_first(&chain1),

After this, Do we really need to use the CONTAINER_OF and other such
methods?

Can we not simply do:
  test_node node1=(test_node*) p;


Since our structure test_node has the  rtems_chain_node Node; as its first
variable, it should work, right?

References:
https://stackoverflow.com/q/3766229
https://git.rtems.org/rtems/tree/cpukit/score/src/scheduleredfsmp.c#n178

Please let me know.
Thanks.

On Fri, Jun 12, 2020 at 7:28 PM Gedare Bloom  wrote:

> On Fri, Jun 12, 2020 at 7:50 AM Richi Dubey  wrote:
> >
> > Hi everyone,
> >
> > While going through testsuites/sptests/spchain/init.c, I noticed the
> following code:
> >
> > ---
> > rtems_task Init(
> >   rtems_task_argument ignored
> > )
> > {
> >   rtems_chain_control  chain1;
> >   rtems_chain_node*p;
> >   test_nodenode1, node2;
> >   int  id;
> >
> >   TEST_BEGIN();
> >
> >   puts( "Init - Initialize chain empty" );
> >   rtems_chain_initialize_empty( &chain1 );
> >   rtems_chain_initialize_node( &node1.Node );
> >   rtems_chain_initialize_node( &node2.Node );
> >
> >   /* verify that the chain append and insert work */
> >   puts( "INIT - Verify rtems_chain_insert" );
> >   node1.id = 1;
> >   node2.id = 2;
> >   rtems_chain_append( &chain1, &node1.Node );
> >   rtems_chain_insert( &node1.Node, &node2.Node );
> >
> >   for ( p = rtems_chain_first(&chain1), id = 1 ;
> > !rtems_chain_is_tail(&chain1, p) ;
> > p = p->next , id++ ) {
> >  test_node *t = (test_node *)p;
> >  if ( id > 2 ) {
> >puts( "INIT - TOO MANY NODES ON CHAIN" );
> >rtems_test_exit(0);
> >  }
> >  if ( t->id != id ) {
> >puts( "INIT - ERROR ON CHAIN ID MISMATCH" );
> >rtems_test_exit(0);
> >  }
> >   }
> >
> > -
> > Where test_node is defined as:
> >
> > typedef struct {
> >   rtems_chain_node Node;
> >   int  id;
> > } test_node;
> >
> > --
> >
> >
> > Now when we are inserting or appending our structure into the chain, we
> are only inserting the part of strucuture correspoing to rtems_chain_node,
> i.e.:
> >   rtems_chain_append( &chain1, &node1.Node );
> >   rtems_chain_insert( &node1.Node, &node2.Node );
> >
> > So, how do we ever get our node1.id ? How can we (or how do we ever)
> access our data from the structure when we are only adding some part of the
> structure into the node?
> >
> > I hope my doubt is not too vague.
> >
> Hi Richi,
>
> This is an old C programming trick.
>
> This looks like a reasonable explanation:
>
> https://medium.com/@414apache/kernel-data-structures-linkedlist-b13e4f8de4bf
>
> Feel free to write something for rtems ;)
>
> > Thanks,
> > Richi.
> >
> >
> > ___
> > 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

[PATCH rtems_waf v2 2/2] rtems: Add function to test waf uninstall

2020-07-24 Thread Vijay Kumar Banerjee
---
 rtems.py | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/rtems.py b/rtems.py
index 067a213..7ee3653 100644
--- a/rtems.py
+++ b/rtems.py
@@ -897,6 +897,52 @@ def _strip_cflags(cflags):
 def _log_header(conf):
 conf.to_log('-')
 
+def _get_dir_hash(bld):
+from waflib import ConfigSet, Options
+import hashlib
+
+env = ConfigSet.ConfigSet()
+env.load(Options.lockfile)
+prefix = env.options['prefix']
+shahash = hashlib.sha1()
+
+for root, dirs, files in os.walk(prefix):
+for names in files:
+filepath = os.path.join(root, names)
+try:
+f1 = open(filepath, 'rb')
+except:
+f1.close()
+continue
+
+while 1:
+buf = f1.read(4096)
+if not buf:
+break
+shahash.update(hashlib.sha1(buf).hexdigest())
+f1.close()
+return shahash.hexdigest()
+
+def test_uninstall(bld):
+from os import sys
+
+print('Test: uninstall')
+initial_hash = _get_dir_hash(bld)
+print('Preinstall hash: %s' % (initial_hash))
+try:
+subprocess.call(['waf', 'install'])
+subprocess.call(['waf', 'uninstall'])
+except:
+subprocess.call(['./waf', 'install'])
+subprocess.call(['./waf', 'uninstall'])
+final_hash = _get_dir_hash(bld)
+print('Post install hash: %s' % (final_hash))
+
+if (initial_hash == final_hash):
+print("Test successful")
+else:
+print("Test failed")
+
 from waflib import Task
 from waflib import TaskGen
 from waflib import Utils
-- 
2.21.1

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


[PATCH rtems_waf v2 1/2] rtems: Add uninstall option to the list of commands

2020-07-24 Thread Vijay Kumar Banerjee
---
 rtems.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtems.py b/rtems.py
index ceabcd9..067a213 100644
--- a/rtems.py
+++ b/rtems.py
@@ -131,7 +131,7 @@ def init(ctx, filters = None, version = None, long_commands 
= False, bsp_init =
 #
 commands = []
 for cmd in waflib.Options.commands:
-if cmd in ['build', 'clean', 'install']:
+if cmd in ['build', 'clean', 'install', 'uninstall']:
 for x in arch_bsps:
 commands += [cmd + '-' + x]
 else:
-- 
2.21.1

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


Re: [PATCH] eng: Add recommendations for attributes

2020-07-24 Thread Gedare Bloom
looks good, thanks

On Thu, Jul 23, 2020 at 11:11 PM Sebastian Huber
 wrote:
>
> Fix formatting.
> ---
>  eng/coding-conventions.rst | 34 ++
>  1 file changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/eng/coding-conventions.rst b/eng/coding-conventions.rst
> index 10034df..b85d8fc 100644
> --- a/eng/coding-conventions.rst
> +++ b/eng/coding-conventions.rst
> @@ -21,7 +21,7 @@ Source Documentation
>  * Use Doxygen according to our `Doxygen Recommendations 
> `_..
>  * Start each file with a brief description followed by a license.
>See `Boilerplate File Header 
> `_..
> -* Use /* */ comments.
> +* Use ``/* */`` comments.
>  * Use comments wisely within function bodies, to explain
>or draw attention without being verbose.
>  * Use English prose and strive for good grammar,
> @@ -48,54 +48,80 @@ Language and Compiler
>  -
>
>  * Use C99.
> +
>  * Treat warnings as errors: eliminate them.
> +
>  * Favor C, but when assembly language is required use inline
>assembly if possible.
> +
>  * Do not use compiler extensions.
> -* Use the RTEMS_macros defined in score/basedefs.h for abstracting
> -  compiler-specific features.
> +
> +* Use the RTEMS macros defined in  for abstracting
> +  compiler-specific features.  For using attributes see the
> +  `GCC attribute syntax 
> `_.
> +  Prefer to place attributes in front of the declarator.  Try to be in line
> +  with
> +  `C++11 attributes `_
> +  and C11 keywords such as
> +  `_Noreturn `_.
> +
>  * Use NULL for the null pointer, and prefer to use explicit
>checks against NULL, e.g.,
>
>.. code-block:: c
>
>if ( ptr != NULL )
> +
>instead of
>
>.. code-block:: c
>
>if ( !ptr )
> +
>  * Use explicit checks for bits in variables.
> +
> * Example 1: Use
> +
>.. code-block:: c
>
> if ( XBITS == (var & XBITS) )
> +
>   to check for a set of defined bits.
> +
> * Example 2: Use
> +
>.. code-block:: c
>
>if ( (var & X_FLAGS) != 0) )
> +
>   instead of
> +
>.. code-block:: c
>
>if ( !!(var & X_FLAGS) )
> +
>   to check for at least 1 defined bit in a set.
> -* Use '(void) unused;' to mark unused parameters and set-but-unused
> +
> +* Use ``(void) unused;`` to mark unused parameters and set-but-unused
>variables immediately after being set.
> +
>  * Do not put function prototypes in C source files, any global functions
>should have a prototype in a header file and any private function
>should be declared static.
> +
>  * Declare global variables in exactly one header file.
>Define global variables in at most one source file.
>Include the header file declaring the global variable as
>the first include file if possible to make sure that the
>compiler checks the declaration and definition and that
>the header file is self-contained.
> +
>  * Do not cast arguments to any printf() or printk() variant.
>Use  PRI constants for the types supported there.
>Use  for the other POSIX and RTEMS types that
>have PRI constants defined there. This increases the portability
>of the printf() format.
> +
>  * Do not use the register keyword. It is deprecated since C++14.
>
>  Formatting
> --
> 2.26.2
>
> ___
> 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: Re: Is rtems available on a 4-cores cortex A72 (ARM-v8a) bsp?

2020-07-24 Thread Gedare Bloom
On Fri, Jul 24, 2020 at 2:28 AM small...@aliyun.com  wrote:
>
> xilinx-zynqmp BSP has a ARM cortex A53 processor. Is it a ARMv8-A architeture?
>
https://developer.arm.com/ip-products/processors/cortex-a/cortex-a53

> 
> small...@aliyun.com
>
>
> From: Sebastian Huber
> Date: 2020-07-24 12:49
> To: small...@aliyun.com; joel
> CC: devel
> Subject: Re: Is rtems available on a 4-cores cortex A72 (ARM-v8a) bsp?
> On 24/07/2020 03:09, small...@aliyun.com wrote:
>
> > 32-bit mode is OK.
> > Does it fully support SMP and MMU in this bsp?
> RTEMS supports SMP on ARMv7-A and in particular the xilinx-zynqmp BSP.
> The MMU is statically set up. RTEMS doesn't support processes with
> virtual memory.
>
> ___
> 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: Strong APA Scheduler : First Draft

2020-07-24 Thread Gedare Bloom
On Fri, Jul 24, 2020 at 8:20 AM Richi Dubey  wrote:
>
> Hi,
>
> With Dr. Butterfield's help, I've made the changes to implement the FIFO 
> Queue using chain. I am not accustomed to coding for embedded systems, so I 
> am not completely sure if I should be using malloc or not.
>
> Someone, please review the following changes:
>
> FIFO Implementaion and Queue traversal: 
> https://richidubey.github.io/Strong-APA-Documentation/html/schedulerstrongapa_8c_source.html#l00159
>
> The structure I have defined to be used with Chain_Control: 
> https://richidubey.github.io/Strong-APA-Documentation/html/structCPU.html
>
I can't fully review yet. You should not be using malloc.

I can review for you on github if you like, if you make a pull request
against the base commit of your rtems fork.

> Thank you,
> Richi.
>
> On Fri, Jul 24, 2020 at 11:28 AM Richi Dubey  wrote:
>>
>> Hi Andrew,
>>
>> Your suggestion helps and I am going to work on it today. Thank you.
>>
>> On Thu, Jul 23, 2020 at 8:14 PM Andrew Butterfield 
>>  wrote:
>>>
>>> Hi Richi,
>>>
>>>  a quick answer to 1 below
>>>
>>> On 23 Jul 2020, at 15:20, Richi Dubey  wrote:
>>> 1)Both the algorithms require the use of a FIFO Queue to support the insert 
>>> and dequeue operations.
>>>
>>> I believe we can use chains and use the chain_append() and combination of 
>>> _Chain_Extract  and _Chain_First or just _Chain_First and node->next to 
>>> achieve the FIFO requirements.
>>>
>>>
>>>
>>> You might want to look at chain_get() - it removes the first element, so 
>>> does a FIFO protocol in tandem with chain_append()
>>>
>>> Regards,
>>>   Andrew
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>>
>>> 
>>> Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
>>> Lero@TCD, Head of Software Foundations & Verification Research Group
>>> School of Computer Science and Statistics,
>>> Room G.39, O'Reilly Institute, Trinity College, University of Dublin
>>>  http://www.scss.tcd.ie/Andrew.Butterfield/
>>> 
>>>
> ___
> 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: Small doubt in how chain works in RTEMS

2020-07-24 Thread Gedare Bloom
On Fri, Jul 24, 2020 at 8:27 AM Richi Dubey  wrote:
>
> Hi,
>
> I have a doubt regarding this.
>
> We do
>   rtems_chain_append( &chain1, &node1.Node );
>
> And get the node pointer when we use:
>   rtems_chain_node*p= rtems_chain_first(&chain1),
>
> After this, Do we really need to use the CONTAINER_OF and other such methods?
>
> Can we not simply do:
>   test_node node1=(test_node*) p;
>
>
> Since our structure test_node has the  rtems_chain_node Node; as its first 
> variable, it should work, right?
>

If the Node is the first variable, then it just works without
container-of. But then you need to make sure no one will change the
structure definition (at least, make a comment about it).

The RTEMS Object model makes use of this simplification. The base
'Object' includes a chain Node at the start of the struct, so that
when you include an Object at the start of a struct, you automatically
get a Node at the base address of an instantiated struct.

The downsides of this assumption are that you have to make the struct
layout rigid (as mentioned), and you also can't reuse the same code
base with nodes belonging to multiple data structures, e.g., you can't
put a single struct on two chains, if both chains assume they get the
base address of the struct, since only one Node can possibly be at the
base of the structure.

I hope that makes sense.

> References:
> https://stackoverflow.com/q/3766229
> https://git.rtems.org/rtems/tree/cpukit/score/src/scheduleredfsmp.c#n178
>
> Please let me know.
> Thanks.
>
> On Fri, Jun 12, 2020 at 7:28 PM Gedare Bloom  wrote:
>>
>> On Fri, Jun 12, 2020 at 7:50 AM Richi Dubey  wrote:
>> >
>> > Hi everyone,
>> >
>> > While going through testsuites/sptests/spchain/init.c, I noticed the 
>> > following code:
>> >
>> > ---
>> > rtems_task Init(
>> >   rtems_task_argument ignored
>> > )
>> > {
>> >   rtems_chain_control  chain1;
>> >   rtems_chain_node*p;
>> >   test_nodenode1, node2;
>> >   int  id;
>> >
>> >   TEST_BEGIN();
>> >
>> >   puts( "Init - Initialize chain empty" );
>> >   rtems_chain_initialize_empty( &chain1 );
>> >   rtems_chain_initialize_node( &node1.Node );
>> >   rtems_chain_initialize_node( &node2.Node );
>> >
>> >   /* verify that the chain append and insert work */
>> >   puts( "INIT - Verify rtems_chain_insert" );
>> >   node1.id = 1;
>> >   node2.id = 2;
>> >   rtems_chain_append( &chain1, &node1.Node );
>> >   rtems_chain_insert( &node1.Node, &node2.Node );
>> >
>> >   for ( p = rtems_chain_first(&chain1), id = 1 ;
>> > !rtems_chain_is_tail(&chain1, p) ;
>> > p = p->next , id++ ) {
>> >  test_node *t = (test_node *)p;
>> >  if ( id > 2 ) {
>> >puts( "INIT - TOO MANY NODES ON CHAIN" );
>> >rtems_test_exit(0);
>> >  }
>> >  if ( t->id != id ) {
>> >puts( "INIT - ERROR ON CHAIN ID MISMATCH" );
>> >rtems_test_exit(0);
>> >  }
>> >   }
>> >
>> > -
>> > Where test_node is defined as:
>> >
>> > typedef struct {
>> >   rtems_chain_node Node;
>> >   int  id;
>> > } test_node;
>> >
>> > --
>> >
>> >
>> > Now when we are inserting or appending our structure into the chain, we 
>> > are only inserting the part of strucuture correspoing to rtems_chain_node, 
>> > i.e.:
>> >   rtems_chain_append( &chain1, &node1.Node );
>> >   rtems_chain_insert( &node1.Node, &node2.Node );
>> >
>> > So, how do we ever get our node1.id ? How can we (or how do we ever) 
>> > access our data from the structure when we are only adding some part of 
>> > the structure into the node?
>> >
>> > I hope my doubt is not too vague.
>> >
>> Hi Richi,
>>
>> This is an old C programming trick.
>>
>> This looks like a reasonable explanation:
>> https://medium.com/@414apache/kernel-data-structures-linkedlist-b13e4f8de4bf
>>
>> Feel free to write something for rtems ;)
>>
>> > Thanks,
>> > Richi.
>> >
>> >
>> > ___
>> > 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


Adding Openat in RTEMS-Libbsd

2020-07-24 Thread Eshan Dhawan
Hello everyone,
I tried adding openat to libbsd from freebsd. Got error in not defined
_libc_interposing__
Where is that defined or needs to be added from freebsd.

link to github repo :
https://github.com/eshandhawan51/rtems-libbsd/tree/file_tests
added file openat.c in freebsd/lib/libc/sys

log:
 eshan@EDs-pc  ~/development/rtems/kernel/rtems-libbsd   file_tests ● 
./waf
Waf: Entering directory
`/home/eshan/development/rtems/kernel/rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-default'
[ 188/1949] Compiling freebsd/lib/libc/sys/openat.c
[1825/1949] Linking
build/arm-rtems5-xilinx_zynq_a9_qemu-default/at_functions.exe
[1910/1949] Linking
build/arm-rtems5-xilinx_zynq_a9_qemu-default/termios01.exe
[1914/1949] Linking
build/arm-rtems5-xilinx_zynq_a9_qemu-default/termios02.exe
[1918/1949] Linking
build/arm-rtems5-xilinx_zynq_a9_qemu-default/termios03.exe
[1922/1949] Linking
build/arm-rtems5-xilinx_zynq_a9_qemu-default/termios04.exe
[1927/1949] Linking
build/arm-rtems5-xilinx_zynq_a9_qemu-default/termios05.exe
[1931/1949] Linking
build/arm-rtems5-xilinx_zynq_a9_qemu-default/termios06.exe
[1932/1949] Linking
build/arm-rtems5-xilinx_zynq_a9_qemu-default/thread01.exe
[1942/1949] Linking
build/arm-rtems5-xilinx_zynq_a9_qemu-default/timeout01.exe
/home/eshan/development/rtems/5/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
./libbsd.a(openat.c.11.o): in function `openat':
/home/eshan/development/rtems/kernel/rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-default/../../freebsd/lib/libc/sys/openat.c:61:
undefined reference to `__libc_interposing'
/home/eshan/development/rtems/5/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
/home/eshan/development/rtems/kernel/rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-default/../../freebsd/lib/libc/sys/openat.c:61:
undefined reference to `__libc_interposing'
/home/eshan/development/rtems/5/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
/home/eshan/development/rtems/kernel/rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-default/at_functions.exe:
hidden symbol `__libc_interposing' isn't defined
/home/eshan/development/rtems/5/lib/gcc/arm-rtems5/7.5.0/../../../../arm-rtems5/bin/ld:
final link failed: bad value
collect2: error: ld returned 1 exit status

Waf: Leaving directory
`/home/eshan/development/rtems/kernel/rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-default'
Build failed

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

Re: Small doubt in how chain works in RTEMS

2020-07-24 Thread Richi Dubey
Yes, it makes perfect sense.

Thank you for the clarification.

On Fri, Jul 24, 2020 at 11:29 PM Gedare Bloom  wrote:

> On Fri, Jul 24, 2020 at 8:27 AM Richi Dubey  wrote:
> >
> > Hi,
> >
> > I have a doubt regarding this.
> >
> > We do
> >   rtems_chain_append( &chain1, &node1.Node );
> >
> > And get the node pointer when we use:
> >   rtems_chain_node*p= rtems_chain_first(&chain1),
> >
> > After this, Do we really need to use the CONTAINER_OF and other such
> methods?
> >
> > Can we not simply do:
> >   test_node node1=(test_node*) p;
> >
> >
> > Since our structure test_node has the  rtems_chain_node Node; as its
> first variable, it should work, right?
> >
>
> If the Node is the first variable, then it just works without
> container-of. But then you need to make sure no one will change the
> structure definition (at least, make a comment about it).
>
> The RTEMS Object model makes use of this simplification. The base
> 'Object' includes a chain Node at the start of the struct, so that
> when you include an Object at the start of a struct, you automatically
> get a Node at the base address of an instantiated struct.
>
> The downsides of this assumption are that you have to make the struct
> layout rigid (as mentioned), and you also can't reuse the same code
> base with nodes belonging to multiple data structures, e.g., you can't
> put a single struct on two chains, if both chains assume they get the
> base address of the struct, since only one Node can possibly be at the
> base of the structure.
>
> I hope that makes sense.
>
> > References:
> > https://stackoverflow.com/q/3766229
> > https://git.rtems.org/rtems/tree/cpukit/score/src/scheduleredfsmp.c#n178
> >
> > Please let me know.
> > Thanks.
> >
> > On Fri, Jun 12, 2020 at 7:28 PM Gedare Bloom  wrote:
> >>
> >> On Fri, Jun 12, 2020 at 7:50 AM Richi Dubey 
> wrote:
> >> >
> >> > Hi everyone,
> >> >
> >> > While going through testsuites/sptests/spchain/init.c, I noticed the
> following code:
> >> >
> >> > ---
> >> > rtems_task Init(
> >> >   rtems_task_argument ignored
> >> > )
> >> > {
> >> >   rtems_chain_control  chain1;
> >> >   rtems_chain_node*p;
> >> >   test_nodenode1, node2;
> >> >   int  id;
> >> >
> >> >   TEST_BEGIN();
> >> >
> >> >   puts( "Init - Initialize chain empty" );
> >> >   rtems_chain_initialize_empty( &chain1 );
> >> >   rtems_chain_initialize_node( &node1.Node );
> >> >   rtems_chain_initialize_node( &node2.Node );
> >> >
> >> >   /* verify that the chain append and insert work */
> >> >   puts( "INIT - Verify rtems_chain_insert" );
> >> >   node1.id = 1;
> >> >   node2.id = 2;
> >> >   rtems_chain_append( &chain1, &node1.Node );
> >> >   rtems_chain_insert( &node1.Node, &node2.Node );
> >> >
> >> >   for ( p = rtems_chain_first(&chain1), id = 1 ;
> >> > !rtems_chain_is_tail(&chain1, p) ;
> >> > p = p->next , id++ ) {
> >> >  test_node *t = (test_node *)p;
> >> >  if ( id > 2 ) {
> >> >puts( "INIT - TOO MANY NODES ON CHAIN" );
> >> >rtems_test_exit(0);
> >> >  }
> >> >  if ( t->id != id ) {
> >> >puts( "INIT - ERROR ON CHAIN ID MISMATCH" );
> >> >rtems_test_exit(0);
> >> >  }
> >> >   }
> >> >
> >> > -
> >> > Where test_node is defined as:
> >> >
> >> > typedef struct {
> >> >   rtems_chain_node Node;
> >> >   int  id;
> >> > } test_node;
> >> >
> >> > --
> >> >
> >> >
> >> > Now when we are inserting or appending our structure into the chain,
> we are only inserting the part of strucuture correspoing to
> rtems_chain_node, i.e.:
> >> >   rtems_chain_append( &chain1, &node1.Node );
> >> >   rtems_chain_insert( &node1.Node, &node2.Node );
> >> >
> >> > So, how do we ever get our node1.id ? How can we (or how do we ever)
> access our data from the structure when we are only adding some part of the
> structure into the node?
> >> >
> >> > I hope my doubt is not too vague.
> >> >
> >> Hi Richi,
> >>
> >> This is an old C programming trick.
> >>
> >> This looks like a reasonable explanation:
> >>
> https://medium.com/@414apache/kernel-data-structures-linkedlist-b13e4f8de4bf
> >>
> >> Feel free to write something for rtems ;)
> >>
> >> > Thanks,
> >> > Richi.
> >> >
> >> >
> >> > ___
> >> > 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