How to implement ucontext.h in rtems?
Dear all, I checked the file in rtems, and it is empty. Does rtems support ucontext? Best wishes, xuelin.t...@qkmtech.com ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
About SA_RESTART undeclared in my application
Dear all, I am trying to compile some applications that need POSIX signal support, however, some error come up. When using SA_RESTART, it says "error 'SA_RESTART' undeclared". But I check the function "signal" in /cpukit/posix/src/signal_2.c, this macro is being used in rtems. How can I use such these macros? Best wishes, xuelin.t...@qkmtech.com ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
'signal/sigaction' functions in RTEMS
Dear all, I sent an email asking SA_RESTART macro yesterday. Sorry that I have to send again. During porting Mono to RTEMS, the 'signal/sigaction' function set is still a bit problem to me. When compiling Mono, some macros like SA_RESTART that are not defined in RTEMS are needed, and more instereting thing is that these macros are already used in RTEMS kernel. And also, 'struct sigaction' is also needed, I cannot find its definition in RTEMS either. So, can I just add these into RTEMS kernel and re-compile it, or is there any other options that I can deal with these? Thanks a lot. Best wishes, xuelin.t...@qkmtech.com ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
No 'si_addr' member in 'siginfo_t'
Dear all, When I compile my applications, there is an error saying that "error: 'siginfo_t' has no member named 'si_addr'". And the "POSIX API User's Guide" introduces the prototype of the siginfo_t structure which has the 'si_addr' member. So, is there something wrong with the newlib I compiled with? Or RTEMS just does not support this? Best wishes, xuelin.t...@qkmtech.com ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
pthread_getattr_np does not work
Dear all, I tried to use pthread_getattr_np function to extract attrributes of thread in rtems, but it does not work. Has anyone used this function before? Best wishes, xuelin.t...@qkmtech.com ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Re: pthread_getattr_np does not work
I need to get thread attributes through this function.
**
#define __GNU_VISIBLE
#include
void
test_thread (guint8 **staddr, size_t *stsize)
{
pthread_attr_t attr;
uint8_t **staddr = NULL;
size_t *stsize = 0;
int res = 0;
res = pthread_getattr_np (pthread_self(), &attr);
pthread_attr_getstack (&attr, (void**)staddr, stsize);
pthread_attr_destroy (&attr);
}
I check the return value is 0 which means pthread_getattr_np goes well. But all
values in attr structure are either 0 or 1. And I can not get staddr and stsize
value either.
So, I think there may be something wrong with this function.
Best wishes,
xuelin.t...@qkmtech.com
From: Sebastian Huber
Date: 2017-09-20 13:00
To: xuelin.t...@qkmtech.com; users@rtems.org
Subject: Re: pthread_getattr_np does not work
On 20/09/17 05:43, xuelin.t...@qkmtech.com wrote:
> Dear all,
> I tried to use pthread_getattr_np function to extract attrributes of
> thread in rtems, but it does not work. Has anyone used this function
> before?
What do you mean with doesn't work?
--
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.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Re: pthread_getattr_np does not work
I can not reply to rtems-devel mail list, so I have to send again.
Sorry for the rush reply eariler.
I do know this is a bug or I just use it in a wrong way. I need to make sure
that no one has encountered this problem like me before, then I will report a
bug.
Best wishes,
xuelin.t...@qkmtech.com
From: Sebastian Huber
Date: 2017-09-20 14:30
To:
CC: xuelin.t...@qkmtech.com; RTEMS
Subject: Re: pthread_getattr_np does not work
Hello Xuelin,
please answer to the mailing list.
On 20/09/17 08:20, xuelin.t...@qkmtech.com wrote:
> I need to get thread attributes through this function.
>
> **
> #define __GNU_VISIBLE
> #include
>
> void
> test_thread (guint8 **staddr, size_t *stsize)
> {
> pthread_attr_t attr;
> uint8_t **staddr = NULL;
> size_t *stsize = 0;
> int res = 0;
>
> res = pthread_getattr_np (pthread_self(), &attr);
> pthread_attr_getstack (&attr, (void**)staddr, stsize);
> pthread_attr_destroy (&attr);
> }
>
>
> I check the return value is 0 which means pthread_getattr_np goes
> well. But all values in attr structure are either 0 or 1. And I can
> not get staddr and stsize value either.
>
> So, I think there may be something wrong with this function.
Maybe the stack related parts are not returned by pthread_getattr_np().
Please add a ticket for this. You may also implement the missing feature
and add a test case to testsuites/psxtests/psxgetattrnp01.
--
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.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Re: pthread_getattr_np does not work
I found out that there is a test in 4.12-master about pthread_getattr_np, so I
compiled that one and ran it.
The result shows that this function works well, like this
*
*** BEGIN OF TEST PSXGETATTRNP 1 ***
Init - pthread_getattr_np - attr NULL - EINVAL
Init - pthread_getattr_np - invalid id - ESRCH
Init - pthread_attr_init
Init - pthread_attr_setinheritsched - PTHREAD_EXPLICIT_SCHED
Init - pthread_attr_setschedpolicy to SCHED_RR
Init - pthread_attr_setschedparam to minimum priority + 2
Init - pthread_attr_getstack
Init - pthread_attr_setstack double the stacksize
Init - pthread_attr_getguardsize
Init - pthread_attr_setguardsize double the guardsizecreate
Init - Lower pri
Init - raise priority to max
Init - pthread_ority
Thread - pthread_getattr_np - Verify value
Thread - pthread_setschedparam: Setting highest priority SCHED_FIFO
Thread - Detach
Thread - pthread_getattr_np
Thread - Verify SCHED_FIFO policy
Thread - Verify max priority
Thread - Verify detached
*** END OF
*
But, this test just checks the return value, not the value of elements in
pthread_attr_t structure. When I tried to print out these values, the same
result as before appeared, all 0...
So, how can I modify the source code in rtems to let this function work? Thanks
a lot.
Best wishes,
xuelin.t...@qkmtech.com
From: xuelin.t...@qkmtech.com
Date: 2017-09-20 14:45
To: Sebastian Huber; users@rtems.org
Subject: Re: Re: pthread_getattr_np does not work
I need to get thread attributes through this function.
**
#define __GNU_VISIBLE
#include
void
test_thread (guint8 **staddr, size_t *stsize)
{
pthread_attr_t attr;
uint8_t **staddr = NULL;
size_t *stsize = 0;
int res = 0;
res = pthread_getattr_np (pthread_self(), &attr);
pthread_attr_getstack (&attr, (void**)staddr, stsize);
pthread_attr_destroy (&attr);
}
I check the return value is 0 which means pthread_getattr_np goes well. But all
values in attr structure are either 0 or 1. And I can not get staddr and stsize
value either.
So, I think there may be something wrong with this function.
Best wishes,
xuelin.t...@qkmtech.com
From: Sebastian Huber
Date: 2017-09-20 13:00
To: xuelin.t...@qkmtech.com; users@rtems.org
Subject: Re: pthread_getattr_np does not work
On 20/09/17 05:43, xuelin.t...@qkmtech.com wrote:
> Dear all,
> I tried to use pthread_getattr_np function to extract attrributes of
> thread in rtems, but it does not work. Has anyone used this function
> before?
What do you mean with doesn't work?
--
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.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Re: pthread_getattr_np does not work
>> But, this test just checks the return value, not the value of elements >> in pthread_attr_t structure. When I tried to print out these values, >> the same result as before appeared, all 0... > It would be good to check the expected values with test assertions. The return value of pthread_getattr_np is correct, I double checked it. But the values of element in attr structure are not correct, like stack_addr and stack_size. >> >> So, how can I modify the source code in rtems to let this function >> work? Thanks a lot. > You have to edit: > cpukit/posix/src/pthreadgetattrnp.c Yes, I know this. I just do not know how to do this. The implementation of pthread_getattr_np of 4.11 and 4.12 are different, I just do not know where do I start from... Best wishes, xuelin.t...@qkmtech.com From: Sebastian Huber Date: 2017-09-22 16:33 To: xuelin.t...@qkmtech.com; users@rtems.org Subject: Re: pthread_getattr_np does not work On 22/09/17 10:24, xuelin.t...@qkmtech.com wrote: > I found out that there is a test in 4.12-master about > pthread_getattr_np, so I compiled that one and ran it. > > The result shows that this function works well, like this > * > *** BEGIN OF TEST PSXGETATTRNP 1 *** > Init - pthread_getattr_np - attr NULL - EINVAL > Init - pthread_getattr_np - invalid id - ESRCH > Init - pthread_attr_init > Init - pthread_attr_setinheritsched - PTHREAD_EXPLICIT_SCHED > Init - pthread_attr_setschedpolicy to SCHED_RR > Init - pthread_attr_setschedparam to minimum priority + 2 > Init - pthread_attr_getstack > Init - pthread_attr_setstack double the stacksize > Init - pthread_attr_getguardsize > Init - pthread_attr_setguardsize double the guardsizecreate > Init - Lower pri > Init - raise priority to max > Init - pthread_ority > Thread - pthread_getattr_np - Verify value > Thread - pthread_setschedparam: Setting highest priority SCHED_FIFO > Thread - Detach > Thread - pthread_getattr_np > Thread - Verify SCHED_FIFO policy > Thread - Verify max priority > Thread - Verify detached > *** END OF > * > > But, this test just checks the return value, not the value of elements > in pthread_attr_t structure. When I tried to print out these values, > the same result as before appeared, all 0... It would be good to check the expected values with test assertions. > > So, how can I modify the source code in rtems to let this function > work? Thanks a lot. You have to edit: cpukit/posix/src/pthreadgetattrnp.c -- 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. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Re: pthread_getattr_np does not work
OK, I will try to do some fix on this function. And if Sherrill and you have time, please take some time on this. Thanks a lot. Best wishes, xuelin.t...@qkmtech.com From: Sebastian Huber Date: 2017-09-22 16:48 To: xuelin.t...@qkmtech.com; users@rtems.org Subject: Re: pthread_getattr_np does not work On 22/09/17 10:43, xuelin.t...@qkmtech.com wrote: > >> > >> So, how can I modify the source code in rtems to let this function > >> work? Thanks a lot. > > You have to edit: > > cpukit/posix/src/pthreadgetattrnp.c > > Yes, I know this. I just do not know how to do this. The > implementation of pthread_getattr_np of 4.11 and 4.12 are different, I > just do not know where do I start from... It should be fixed on the master first, then you can back port a fix. -- 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. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Re: pthread_getattr_np does not work
OK, no problem, thanks anyway. Best wishes, xuelin.t...@qkmtech.com From: Sebastian Huber Date: 2017-09-22 16:58 To: xuelin.t...@qkmtech.com; users@rtems.org Subject: Re: pthread_getattr_np does not work On 22/09/17 10:55, xuelin.t...@qkmtech.com wrote: > OK, I will try to do some fix on this function. And if Sherrill and > you have time, please take some time on this. Thanks a lot. No, sorry. I have no time to fix this. -- 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. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Re: pthread_getattr_np does not work
OK, I will try to do this.
Best wishes,
xuelin.t...@qkmtech.com
From: Joel Sherrill
Date: 2017-09-24 21:32
To: xuelin.tian
CC: rtems-us...@rtems.org; Sebastian Huber
Subject: Re: Re: pthread_getattr_np does not work
No. But you are welcome to submit patches so the behavior matches Linux.
On Sep 24, 2017 1:09 AM, "xuelin.tian" wrote:
So, is there a substitute function for this in RTEMS, without modifying the
source code?
-- Original --
From: "Joel Sherrill";
Date: Sun, Sep 24, 2017 00:15 AM
To: "xuelin.tian";
Cc: "Sebastian Huber";
"users@rtems.org";
Subject: Re: Re: pthread_getattr_np does not work
On Fri, Sep 22, 2017 at 9:26 PM, xuelin.tian wrote:
Thanks so much for your test.
No problem. Just trying to help.
The parts of this structure I care about most are the stackaddr and stacksize
(and guardsize maybe), where stackaddr always returns 0. The value of stacksize
is either 8192 or 0, based on the fact that this attribute structure is
retrieved from POSIX_Init or other pthreads in my system (maybe I use
pthread_create in a wrong way...).
Without looking at the code, 8192 is almost certainly the port specific default
stack size since it is normally a value like that. A stack size request of
anything
less than the recommended minimum will always get you an allocation of the
minimum. So 0 or 8192 might simply indicate whether the structure is explicitly
initialized via pthread_attr_init() or filled in explicitly by the application
with
the minimum stack size constant.
So, from the result you post, the stackaddr is 0 too, which means this element
is not supported in rtems, or there is something wrong with this function?
This means the user application didn't specify the stack area in RTEMS. Since
this method is "NP", there is no standard specifying the behavior.
This method doesn't exist on FreeBSD and appears to only exist in Linux and
RTEMS. If there is consensus that it should behave the same on Linux and
RTEMS, then there should be a ticket filed with (hopefully) patches.
It isn't a complicated method and all if should take is filling in the attribute
structure with different fields in the TCB. I think it primarily parrots back
the attribute structure passed to pthread_create().
Also writing the man page for the RTEMS POSIX manual would be appreciated.
Nothing like wandering into something that is even beyond unspecified in
POSIX to a method that is explicitly non-portable for fun. :)
--joel
--joel
-- Original --
From: "Joel Sherrill";
Date: Fri, Sep 22, 2017 10:15 PM
To: "xuelin.t...@qkmtech.com";
Cc: "Sebastian Huber";
"users@rtems.org";
Subject: Re: Re: pthread_getattr_np does not work
The test does verify the values. I don't see a specific case of creating a
thread
with a non-standard stack value and verifying that value in the task but the
test creates a thread which retrieves its values and verifies many (most, all?)
of them:
(gdb)
Thread - pthread_getattr_np - Verify value
46sc = pthread_getattr_np( Thread_id, &attr );
(gdb)
47rtems_test_assert( sc == 0 );
(gdb)
52puts( "Thread - pthread_setschedparam: Setting highest priority
SCHED_FIFO" );
(gdb) p attr
$1 = {is_initialized = 1, stackaddr = 0x0, stacksize = 8192,
contentionscope = 0, inheritsched = 2, schedpolicy = 2, schedparam = {
sched_priority = 3, sched_ss_low_priority = 285216961,
sched_ss_repl_period = {tv_sec = 0, tv_nsec = 16},
sched_ss_init_budget = {tv_sec = 0, tv_nsec = 1}, sched_ss_max_repl = 0},
guardsize = 0, cputime_clock_allowed = 1, detachstate = 1,
affinitysetsize = 0, affinityset = 0x0, affinitysetpreallocated = {
__bits = {0}}}
Clearly the attribute structure returned is not all zero.
I am not sure what you are seeing but it doesn't match what I see in
this test on the erc32.
--joel
On Fri, Sep 22, 2017 at 4:04 AM, xuelin.t...@qkmtech.com
wrote:
OK, no problem, thanks anyway.
Best wishes,
xuelin.t...@qkmtech.com
From: Sebastian Huber
Date: 2017-09-22 16:58
To: xuelin.t...@qkmtech.com; users@rtems.org
Subject: Re: pthread_getattr_np does not work
On 22/09/17 10:55, xuelin.t...@qkmtech.com wrote:
> OK, I will try to do some fix on this function. And if Sherrill and
> you have time, please take some time on this. Thanks a lot.
No, sorry. I have no time to fix this.
--
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.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailm
Re: Re: pthread_getattr_np does not work
You mean, I allocate an array of some size in another thread, and set the
pointer of this array as the stack address using pthread_attr_setstackaddr?
Best wishes,
xuelin.t...@qkmtech.com
From: Joel Sherrill
Date: 2017-09-26 00:29
To: xuelin.t...@qkmtech.com
CC: users@rtems.org; Sebastian Huber
Subject: Re: Re: pthread_getattr_np does not work
I would suggest adding a test of another thread with a user provided stack
space that is properly aligned (e.g. array of double of minimum stack size
divided by sizeof(double)). This would give you known address range and
size for that thread.
For the case of RTEMS allocating the stack, the pointer returned to you
will vary based on the BSP and will essentially be random to the application.
If the application allocates it, then it knows the starting address.
You should be able to add that to the existing test without much trouble.
--joel
On Sun, Sep 24, 2017 at 9:45 PM, xuelin.t...@qkmtech.com
wrote:
OK, I will try to do this.
Best wishes,
xuelin.t...@qkmtech.com
From: Joel Sherrill
Date: 2017-09-24 21:32
To: xuelin.tian
CC: rtems-us...@rtems.org; Sebastian Huber
Subject: Re: Re: pthread_getattr_np does not work
No. But you are welcome to submit patches so the behavior matches Linux.
On Sep 24, 2017 1:09 AM, "xuelin.tian" wrote:
So, is there a substitute function for this in RTEMS, without modifying the
source code?
-- Original --
From: "Joel Sherrill";
Date: Sun, Sep 24, 2017 00:15 AM
To: "xuelin.tian";
Cc: "Sebastian Huber";
"users@rtems.org";
Subject: Re: Re: pthread_getattr_np does not work
On Fri, Sep 22, 2017 at 9:26 PM, xuelin.tian wrote:
Thanks so much for your test.
No problem. Just trying to help.
The parts of this structure I care about most are the stackaddr and stacksize
(and guardsize maybe), where stackaddr always returns 0. The value of stacksize
is either 8192 or 0, based on the fact that this attribute structure is
retrieved from POSIX_Init or other pthreads in my system (maybe I use
pthread_create in a wrong way...).
Without looking at the code, 8192 is almost certainly the port specific default
stack size since it is normally a value like that. A stack size request of
anything
less than the recommended minimum will always get you an allocation of the
minimum. So 0 or 8192 might simply indicate whether the structure is explicitly
initialized via pthread_attr_init() or filled in explicitly by the application
with
the minimum stack size constant.
So, from the result you post, the stackaddr is 0 too, which means this element
is not supported in rtems, or there is something wrong with this function?
This means the user application didn't specify the stack area in RTEMS. Since
this method is "NP", there is no standard specifying the behavior.
This method doesn't exist on FreeBSD and appears to only exist in Linux and
RTEMS. If there is consensus that it should behave the same on Linux and
RTEMS, then there should be a ticket filed with (hopefully) patches.
It isn't a complicated method and all if should take is filling in the attribute
structure with different fields in the TCB. I think it primarily parrots back
the attribute structure passed to pthread_create().
Also writing the man page for the RTEMS POSIX manual would be appreciated.
Nothing like wandering into something that is even beyond unspecified in
POSIX to a method that is explicitly non-portable for fun. :)
--joel
--joel
-- Original --
From: "Joel Sherrill";
Date: Fri, Sep 22, 2017 10:15 PM
To: "xuelin.t...@qkmtech.com";
Cc: "Sebastian Huber";
"users@rtems.org";
Subject: Re: Re: pthread_getattr_np does not work
The test does verify the values. I don't see a specific case of creating a
thread
with a non-standard stack value and verifying that value in the task but the
test creates a thread which retrieves its values and verifies many (most, all?)
of them:
(gdb)
Thread - pthread_getattr_np - Verify value
46sc = pthread_getattr_np( Thread_id, &attr );
(gdb)
47rtems_test_assert( sc == 0 );
(gdb)
52puts( "Thread - pthread_setschedparam: Setting highest priority
SCHED_FIFO" );
(gdb) p attr
$1 = {is_initialized = 1, stackaddr = 0x0, stacksize = 8192,
contentionscope = 0, inheritsched = 2, schedpolicy = 2, schedparam = {
sched_priority = 3, sched_ss_low_priority = 285216961,
sched_ss_repl_period = {tv_sec = 0, tv_nsec = 16},
sched_ss_init_budget = {tv_sec = 0, tv_nsec = 1}, sched_ss_max_repl = 0},
guardsize = 0, cputime_clock_allowed = 1, detachstate = 1,
affinitysetsize = 0, affinityset = 0x0, affinitysetpreallocated = {
__bits = {0}}}
Clearly the attribute structure returned is not all zero.
I am not sure what you are seeing but it doesn't match what I see i
Re: Re: pthread_getattr_np does not work
I tried it, and it worked. But, there is another problem that I need to free this array (or buffer) by my self. This bunch of buffer can not be freed by calling pthread_attr_destroy. Maybe this is a little inconvenient. Any suggestion on this? Best wishes, xuelin.t...@qkmtech.com From: Joel Sherrill Date: 2017-09-26 23:16 To: xuelin.t...@qkmtech.com CC: users@rtems.org; Sebastian Huber Subject: Re: Re: pthread_getattr_np does not work Yes. Then pthread_create a thread to use that stack, let it run, and make sure pthread_getattr_np reports things correctly. On Tue, Sep 26, 2017 at 6:52 AM, xuelin.t...@qkmtech.com wrote: You mean, I allocate an array of some size in another thread, and set the pointer of this array as the stack address using pthread_attr_setstackaddr? Best wishes, xuelin.t...@qkmtech.com From: Joel Sherrill Date: 2017-09-26 00:29 To: xuelin.t...@qkmtech.com CC: users@rtems.org; Sebastian Huber Subject: Re: Re: pthread_getattr_np does not work I would suggest adding a test of another thread with a user provided stack space that is properly aligned (e.g. array of double of minimum stack size divided by sizeof(double)). This would give you known address range and size for that thread. For the case of RTEMS allocating the stack, the pointer returned to you will vary based on the BSP and will essentially be random to the application. If the application allocates it, then it knows the starting address. You should be able to add that to the existing test without much trouble. --joel On Sun, Sep 24, 2017 at 9:45 PM, xuelin.t...@qkmtech.com wrote: OK, I will try to do this. Best wishes, xuelin.t...@qkmtech.com From: Joel Sherrill Date: 2017-09-24 21:32 To: xuelin.tian CC: rtems-us...@rtems.org; Sebastian Huber Subject: Re: Re: pthread_getattr_np does not work No. But you are welcome to submit patches so the behavior matches Linux. On Sep 24, 2017 1:09 AM, "xuelin.tian" wrote: So, is there a substitute function for this in RTEMS, without modifying the source code? -- Original -- From: "Joel Sherrill"; Date: Sun, Sep 24, 2017 00:15 AM To: "xuelin.tian"; Cc: "Sebastian Huber"; "users@rtems.org"; Subject: Re: Re: pthread_getattr_np does not work On Fri, Sep 22, 2017 at 9:26 PM, xuelin.tian wrote: Thanks so much for your test. No problem. Just trying to help. The parts of this structure I care about most are the stackaddr and stacksize (and guardsize maybe), where stackaddr always returns 0. The value of stacksize is either 8192 or 0, based on the fact that this attribute structure is retrieved from POSIX_Init or other pthreads in my system (maybe I use pthread_create in a wrong way...). Without looking at the code, 8192 is almost certainly the port specific default stack size since it is normally a value like that. A stack size request of anything less than the recommended minimum will always get you an allocation of the minimum. So 0 or 8192 might simply indicate whether the structure is explicitly initialized via pthread_attr_init() or filled in explicitly by the application with the minimum stack size constant. So, from the result you post, the stackaddr is 0 too, which means this element is not supported in rtems, or there is something wrong with this function? This means the user application didn't specify the stack area in RTEMS. Since this method is "NP", there is no standard specifying the behavior. This method doesn't exist on FreeBSD and appears to only exist in Linux and RTEMS. If there is consensus that it should behave the same on Linux and RTEMS, then there should be a ticket filed with (hopefully) patches. It isn't a complicated method and all if should take is filling in the attribute structure with different fields in the TCB. I think it primarily parrots back the attribute structure passed to pthread_create(). Also writing the man page for the RTEMS POSIX manual would be appreciated. Nothing like wandering into something that is even beyond unspecified in POSIX to a method that is explicitly non-portable for fun. :) --joel --joel -- Original -- From: "Joel Sherrill"; Date: Fri, Sep 22, 2017 10:15 PM To: "xuelin.t...@qkmtech.com"; Cc: "Sebastian Huber"; "users@rtems.org"; Subject: Re: Re: pthread_getattr_np does not work The test does verify the values. I don't see a specific case of creating a thread with a non-standard stack value and verifying that value in the task but the test creates a thread which retrieves its values and verifies many (most, all?) of them: (gdb) Thread - pthread_getattr_np - Verify value 46sc = pthread_getattr_np( Thread_id, &attr ); (gdb) 47rtems_test_assert( sc == 0 ); (gdb) 52puts( "Thread - pthread_setschedparam: Setting highest priority
Filesystem in RTEMS
Dear all, I got a little confused about the file system in rtems. The root file system is IMFS in rtems, obviously. And what is the devfs and rfs? They can be both configured for peripheral devices, I think. So, what is the difference between them? For example, if I want to mount a flash to IMFS, which is the best choice for it?(JFFS2 may be too complicated...) Best wishes, xuelin.t...@qkmtech.com ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Re: Filesystem in RTEMS
So, what is the RFS for, basically? Best wishes, xuelin.t...@qkmtech.com From: Sebastian Huber Date: 2017-10-19 16:14 To: xuelin.t...@qkmtech.com; users@rtems.org Subject: Re: Filesystem in RTEMS On 19/10/17 10:09, xuelin.t...@qkmtech.com wrote: > Dear all, > I got a little confused about the file system in rtems. > > The root file system is IMFS in rtems, obviously. And what is the > devfs and rfs? They can be both configured for peripheral devices, I > think. So, what is the difference between them? devfs and RFS should not be used for device files. I would like to remove devfs in the future. > For example, if I want to mount a flash to IMFS, which is the best > choice for it?(JFFS2 may be too complicated...) JFFS2 is the right file system for NOR flashes. -- 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. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Re: Filesystem in RTEMS
Does RTEMS have the FTL(Flash Translation Layer) as Linux, that can map flash
device into block device?
How can I define the blocks used in JFFS2, according to NOR flash?
I define the segments in my flash, but have no idea how this is related to the
blocks defined in the JFFS2.
const rtems_fdisk_segment_desc myflash_segments[2] = {
{
.count = 32,
.segment = 0,
.offset = 0x,
.size = RTEMS_FDISK_KBYTES(4)
},
{
.count = 510,
.segment = 32,
.offset = 0x0002,
.size = RTEMS_FDISK_KBYTES(64)
}
};
Best wishes,
xuelin.t...@qkmtech.com
From: Sebastian Huber
Date: 2017-10-19 16:14
To: xuelin.t...@qkmtech.com; users@rtems.org
Subject: Re: Filesystem in RTEMS
On 19/10/17 10:09, xuelin.t...@qkmtech.com wrote:
> Dear all,
> I got a little confused about the file system in rtems.
>
> The root file system is IMFS in rtems, obviously. And what is the
> devfs and rfs? They can be both configured for peripheral devices, I
> think. So, what is the difference between them?
devfs and RFS should not be used for device files. I would like to
remove devfs in the future.
> For example, if I want to mount a flash to IMFS, which is the best
> choice for it?(JFFS2 may be too complicated...)
JFFS2 is the right file system for NOR flashes.
--
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.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Re: Filesystem in RTEMS
Oh, I see. I just need to treat my flash as an array, not a block device. Thanks a lot. Best wishes, xuelin.t...@qkmtech.com From: Sebastian Huber Date: 2017-10-19 19:56 To: xuelin.t...@qkmtech.com; users@rtems.org Subject: Re: Filesystem in RTEMS On 19/10/17 13:49, xuelin.t...@qkmtech.com wrote: > Does RTEMS have the FTL(Flash Translation Layer) as Linux, that can > map flash device into block device? No. > How can I define the blocks used in JFFS2, according to NOR flash? See testsuites/fstests/jffs2_support/fs_support.c for an example. We have no direct support for the flash block device driver. -- 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. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Re: Filesystem in RTEMS
Thanks for your explaination : ) Best wishes, xuelin.t...@qkmtech.com From: Chris Johns Date: 2017-10-20 05:15 To: xuelin.t...@qkmtech.com; Sebastian Huber; users@rtems.org Subject: Re: Filesystem in RTEMS On 19/10/2017 19:30, xuelin.t...@qkmtech.com wrote: > So, what is the RFS for, basically? It is a general purpose file system for block devices. It is in use on NASA's MMS project. I often use it as a RAM disk file system to hold web pages and files uploaded and downloaded via the web server. I create a RAM disk block device, format it as RFS and then copy the web pages from a flash disk to the RAM disk. Chris ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Re: Filesystem in RTEMS
I followed the example (testsuites/fstests/jffs2_support/fs_support.c), and some error came up, like "undefined reference to rtems_jffs2_initialize", "undefined reference to rtems_jffs2_compressor_zlib_compress", and "undefined reference to rtems_jffs2_compressor_zlib_decompress" I have no clue here. Do I have to give my own implementation of these functions here? I can exploit the default functions for jffs2 entry table and compress, I think. And I have a little confused about the model of device driver in rtems, since I get stuck for a few days. First, a deivce descriptor (rtems_fdisk_device_desc) should be given, including some handlers defined in rtems_fdisk_driver_handlers, and device configuration (rtems_flashdisk_config). Then, I need to register (or initialize) my flash device into rtems dynamically or statically, with my own initialize, open, close functions. Last, the JFFS2 should be set up based on the registered device driver. The block size need to be equal to the page size of flash, and the read, write, erase operations should invoke the corresponding functions defined in rtems_fdisk_driver_handlers. Am I correct in this whoe process? Best wishes, xuelin.t...@qkmtech.com From: Sebastian Huber Date: 2017-10-19 19:56 To: xuelin.t...@qkmtech.com; users@rtems.org Subject: Re: Filesystem in RTEMS On 19/10/17 13:49, xuelin.t...@qkmtech.com wrote: > Does RTEMS have the FTL(Flash Translation Layer) as Linux, that can > map flash device into block device? No. > How can I define the blocks used in JFFS2, according to NOR flash? See testsuites/fstests/jffs2_support/fs_support.c for an example. We have no direct support for the flash block device driver. -- 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. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Re: Filesystem in RTEMS
Yeah, my code is mostly like yours.
I have a handle of flash device, which can access flash hardware directly via
QSPI. So, this means, my flash can work with jffs2 without being registered
into rtems?
And, I still get these error...
[1136/1145] Linking build/arm-rtems4.11-xilinx_zynq_zedboard/bkv01.elf
main.c.38.o: In function `.LANCHOR1':
main.c:(.rodata+0x2f4): undefined reference to `rtems_jffs2_initialize'
Kernel/driver_module/flash/flash_driver.c.38.o:(.data+0x58): undefined
reference to `rtems_jffs2_compressor_zlib_compress'
Kernel/driver_module/flash/flash_driver.c.38.o:(.data+0x5c): undefined
reference to `rtems_jffs2_compressor_zlib_decompress'
collect2: error: ld returned 1 exit status
Best wishes,
xuelin.t...@qkmtech.com
From: Chris Johns
Date: 2017-10-21 08:56
To: xuelin.t...@qkmtech.com; Sebastian Huber; users@rtems.org
Subject: Re: Filesystem in RTEMS
On 21/10/2017 11:17, xuelin.t...@qkmtech.com wrote:
> I followed the example (testsuites/fstests/jffs2_support/fs_support.c), and
> some
> error came up, like
> "undefined reference to rtems_jffs2_initialize",
> "undefined reference to rtems_jffs2_compressor_zlib_compress", and
> "undefined reference to rtems_jffs2_compressor_zlib_decompress"
> I have no clue here. Do I have to give my own implementation of these
> functions
> here? I can exploit the default functions for jffs2 entry table and compress,
> I
> think.
>
> And I have a little confused about the model of device driver in rtems, since
> I
> get stuck for a few days.
> First, a deivce descriptor (rtems_fdisk_device_desc) should be given,
> including
> some handlers defined in rtems_fdisk_driver_handlers, and device
> configuration
> (rtems_flashdisk_config).
> Then, I need to register (or initialize) my flash device into rtems
> dynamically
> or statically, with my own initialize, open, close functions.
> Last, the JFFS2 should be set up based on the registered device driver. The
> block size need to be equal to the page size of flash, and the read, write,
> erase operations should invoke the corresponding functions defined
> in rtems_fdisk_driver_handlers.
>
> Am I correct in this whoe process?
I have something like the following piece of code in a file in my application:
typedef struct
{
rtems_jffs2_flash_control super;
/* private data for my flash driver such as stats */
} ffs_control;
static ffs_control*
flash_get_control(rtems_jffs2_flash_control* super)
{
return (ffs_control *) super;
}
static int
flash_read(rtems_jffs2_flash_control* super,
uint32_t offset,
unsigned char* buffer,
size_t length)
{
ffs_control* self = flash_get_control(super);
int r;
.
.
.
return r;
}
static int
flash_write(rtems_jffs2_flash_control* super,
uint32_t offset,
const unsigned char* buffer,
size_t length)
{
ffs_control* self = flash_get_control(super);
int r;
.
.
.
return r;
}
static int
flash_erase(rtems_jffs2_flash_control* super,
uint32_t offset)
{
ffs_control* self = flash_get_control(super);
int r;
.
.
.
return r;
}
static void
flash_destroy(rtems_jffs2_flash_control* super)
{
ffs_control* self = flash_get_control(super);
int r;
.
.
.
return r;
}
static ffs_control ffs_data = {
.super = {
.read = flash_read,
.write = flash_write,
.erase = flash_erase,
.destroy = flash_destroy
}
};
static rtems_jffs2_compressor_zlib_control compressor_instance = {
.super = {
.compress = rtems_jffs2_compressor_zlib_compress,
.decompress = rtems_jffs2_compressor_zlib_decompress
}
};
static const rtems_jffs2_mount_data ffs_mount_data = {
.flash_control = &ffs_data.super,
.compressor_control = &compressor_instance.super
};
bool
ffs_mount(const char* path)
{
int r;
r = flash_open();
if (r != 0)
{
/* print something */
return false;
}
ffs_data.super.block_size = HYDRA_FLASH_BLOCK_SIZE;
ffs_data.super.flash_size = HYDRA_FLASH_FILESYSTEM_SIZE;
r = mount_and_make_target_path(NULL,
path,
RTEMS_FILESYSTEM_TYPE_JFFS2,
RTEMS_FILESYSTEM_READ_WRITE,
&ffs_mount_data);
if (r != 0)
{
/* print something */
return false;
}
return true;
}
You need to provide the open, close, read, write, erase and destroy code that
accesses your flash device. This can be calls to something that directly
accesses the flash device or you can build a driver registered in the device
tree to handle the flash via ioctls.
Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Re: Filesystem in RTEMS
All these three functions should be defined in libjffs2.a, right?
I also add this library -
"additional_flags +=
['-L/opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib
-ljffs2']" -
to my program, but same result...
Best wishes,
xuelin.t...@qkmtech.com
From: xuelin.t...@qkmtech.com
Date: 2017-10-21 09:34
To: Chris Johns; Sebastian Huber; users@rtems.org
Subject: Re: Re: Filesystem in RTEMS
Yeah, my code is mostly like yours.
I have a handle of flash device, which can access flash hardware directly via
QSPI. So, this means, my flash can work with jffs2 without being registered
into rtems?
And, I still get these error...
[1136/1145] Linking build/arm-rtems4.11-xilinx_zynq_zedboard/bkv01.elf
main.c.38.o: In function `.LANCHOR1':
main.c:(.rodata+0x2f4): undefined reference to `rtems_jffs2_initialize'
Kernel/driver_module/flash/flash_driver.c.38.o:(.data+0x58): undefined
reference to `rtems_jffs2_compressor_zlib_compress'
Kernel/driver_module/flash/flash_driver.c.38.o:(.data+0x5c): undefined
reference to `rtems_jffs2_compressor_zlib_decompress'
collect2: error: ld returned 1 exit status
Best wishes,
xuelin.t...@qkmtech.com
From: Chris Johns
Date: 2017-10-21 08:56
To: xuelin.t...@qkmtech.com; Sebastian Huber; users@rtems.org
Subject: Re: Filesystem in RTEMS
On 21/10/2017 11:17, xuelin.t...@qkmtech.com wrote:
> I followed the example (testsuites/fstests/jffs2_support/fs_support.c), and
> some
> error came up, like
> "undefined reference to rtems_jffs2_initialize",
> "undefined reference to rtems_jffs2_compressor_zlib_compress", and
> "undefined reference to rtems_jffs2_compressor_zlib_decompress"
> I have no clue here. Do I have to give my own implementation of these
> functions
> here? I can exploit the default functions for jffs2 entry table and compress,
> I
> think.
>
> And I have a little confused about the model of device driver in rtems, since
> I
> get stuck for a few days.
> First, a deivce descriptor (rtems_fdisk_device_desc) should be given,
> including
> some handlers defined in rtems_fdisk_driver_handlers, and device
> configuration
> (rtems_flashdisk_config).
> Then, I need to register (or initialize) my flash device into rtems
> dynamically
> or statically, with my own initialize, open, close functions.
> Last, the JFFS2 should be set up based on the registered device driver. The
> block size need to be equal to the page size of flash, and the read, write,
> erase operations should invoke the corresponding functions defined
> in rtems_fdisk_driver_handlers.
>
> Am I correct in this whoe process?
I have something like the following piece of code in a file in my application:
typedef struct
{
rtems_jffs2_flash_control super;
/* private data for my flash driver such as stats */
} ffs_control;
static ffs_control*
flash_get_control(rtems_jffs2_flash_control* super)
{
return (ffs_control *) super;
}
static int
flash_read(rtems_jffs2_flash_control* super,
uint32_t offset,
unsigned char* buffer,
size_t length)
{
ffs_control* self = flash_get_control(super);
int r;
.
.
.
return r;
}
static int
flash_write(rtems_jffs2_flash_control* super,
uint32_t offset,
const unsigned char* buffer,
size_t length)
{
ffs_control* self = flash_get_control(super);
int r;
.
.
.
return r;
}
static int
flash_erase(rtems_jffs2_flash_control* super,
uint32_t offset)
{
ffs_control* self = flash_get_control(super);
int r;
.
.
.
return r;
}
static void
flash_destroy(rtems_jffs2_flash_control* super)
{
ffs_control* self = flash_get_control(super);
int r;
.
.
.
return r;
}
static ffs_control ffs_data = {
.super = {
.read = flash_read,
.write = flash_write,
.erase = flash_erase,
.destroy = flash_destroy
}
};
static rtems_jffs2_compressor_zlib_control compressor_instance = {
.super = {
.compress = rtems_jffs2_compressor_zlib_compress,
.decompress = rtems_jffs2_compressor_zlib_decompress
}
};
static const rtems_jffs2_mount_data ffs_mount_data = {
.flash_control = &ffs_data.super,
.compressor_control = &compressor_instance.super
};
bool
ffs_mount(const char* path)
{
int r;
r = flash_open();
if (r != 0)
{
/* print something */
return false;
}
ffs_data.super.block_size = HYDRA_FLASH_BLOCK_SIZE;
ffs_data.super.flash_size = HYDRA_FLASH_FILESYSTEM_SIZE;
r = mount_and_make_target_path(NULL,
path,
RTEMS_FILESYSTEM_TYPE_JFFS2,
RTEMS_FILESY
Re: Re: Filesystem in RTEMS
> $ arm-rtems4.12-nm \ > /opt/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/libjffs2.a | \ > grep rtems_jffs2_compressor_zlib_compress > T rtems_jffs2_compressor_zlib_compress I checked the symbols, same result as yours. >> I also add this library - >> "additional_flags += >> ['-L/opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib >> -ljffs2']" >Link order? Yeah, I google it, and it says that this kind of error is related to linking order. But I use waf, and have no idea how to change the order... bld.program(target = "bkv01.elf", features = "cprogram", cflags = system_flags, includes = system_includes, source = system_src, use = ["bsd"], lib = ["m", "z"], install_path = None ) So I just delete the compressor & decompressor part, and run it. In the function "mount_and_make_target_path", the "rtems_mkdir" part works well, but the "mount" process takes a long time, and no return... I can not debug the mount process, since it is a system call. Best wishes, xuelin.t...@qkmtech.com From: Chris Johns Date: 2017-10-21 11:40 To: xuelin.t...@qkmtech.com; Sebastian Huber; users@rtems.org Subject: Re: Filesystem in RTEMS On 21/10/2017 13:13, xuelin.t...@qkmtech.com wrote: > All these three functions should be defined in libjffs2.a, right? Yeap ... $ arm-rtems4.12-nm \ /opt/rtems/4.12/arm-rtems4.12/xilinx_zynq_zc706/lib/libjffs2.a | \ grep rtems_jffs2_compressor_zlib_compress T rtems_jffs2_compressor_zlib_compress > I also add this library - > "additional_flags += > ['-L/opt/rtems-4.11.1-release/4.11-bsp/arm-rtems4.11/xilinx_zynq_zedboard/lib > -ljffs2']" Link order? Chris ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Re: Filesystem in RTEMS
I have mounted JFFS2 successfully, according to the return value. Yes, it takes some time to do the mounting work. But, when I downloaded a file like "test.txt" into flash via FTP and restarted the system, error came up. <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01FC0028: 0xE5DF instead <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01FC002C: 0xE5DF instead <5>JFFS2: Further such events for this erase block will not be printed <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01FD: 0x000C instead <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01FD0004: 0xB0B1 instead <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01FD0008: 0x0054 instead <5>JFFS2: Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes <5>JFFS2: empty_blocks 0, bad_blocks 0, c->nr_blocks 510 mount failed. Everything worked well, after erasing the whole flash. But errors came up without erasing it. Best wishes, xuelin.t...@qkmtech.com From: xuelin.tian Date: 2017-10-21 22:07 To: Sebastian Huber CC: users Subject: Re: Filesystem in RTEMS > There is no general purpose flash framework in RTEMS (like MTD on Linux). The > JFFS2 uses therefore a framework independent interface. You have to provide > functions for the basic flash operations read, program and erase > yourself. > You should test these operations separately. > > The first mount of JFFS2 on a completely erased flash may take a while since > it is erased block by block and then the clean markers are programmed. > > http://www.linux-mtd.infradead.org/faq/jffs2.html#L_clmarker I have already tested my flash operations, they all worked well. Now, I use the same handle (an instance based on Xilinx BSP) to access to the hardware. And I just have one little question here, what is the appropriate block size for the JFFS2? The size of page is 256B, and size of segment is either 4KB or 64KB. > We have a filesystem guide: > > https://docs.rtems.org/branches/master/filesystem/index.html > > Unfortunately it is out dated and incomplete. Maybe you can help to improve > it. Sure, I am willing to do that, after fully understanding the file system in RTEMS. -- Original -- From: "Sebastian Huber"; Date: Sat, Oct 21, 2017 06:52 PM To: "xuelin tian"; Cc: "users"; Subject: Re: Filesystem in RTEMS - Am 21. Okt 2017 um 2:17 schrieb xuelin tian xuelin.t...@qkmtech.com: > I followed the example (testsuites/fstests/jffs2_support/fs_support.c), and > some > error came up, like > "undefined reference to rtems_jffs2_initialize", > "undefined reference to rtems_jffs2_compressor_zlib_compress", and > "undefined reference to rtems_jffs2_compressor_zlib_decompress" > I have no clue here. Do I have to give my own implementation of these > functions > here? I can exploit the default functions for jffs2 entry table and compress, > I > think. In order to use JFFS2 with compression you have to add "-ljffs2 -lz" to your linker command line. > > And I have a little confused about the model of device driver in rtems, since > I > get stuck for a few days. > First, a deivce descriptor (rtems_fdisk_device_desc) should be given, > including > some handlers defined in rtems_fdisk_driver_handlers, and device > configuration > (rtems_flashdisk_config). > Then, I need to register (or initialize) my flash device into rtems > dynamically > or statically, with my own initialize, open, close functions. > Last, the JFFS2 should be set up based on the registered device driver. The > block size need to be equal to the page size of flash, and the read, write, > erase operations should invoke the corresponding functions defined in > rtems_fdisk_driver_handlers. > > Am I correct in this whoe process? There is no general purpose flash framework in RTEMS (like MTD on Linux). The JFFS2 uses therefore a framework independent interface. You have to provide functions for the basic flash operations read, program and erase yourself. You should test these operations separately. The first mount of JFFS2 on a completely erased flash may take a while since it is erased block by block and then the clean markers are programmed. http://www.linux-mtd.infradead.org/faq/jffs2.html#L_clmarker We have a filesystem guide: https://docs.rtems.org/branches/master/filesystem/index.html Unfortunately it is out dated and incomplete. Maybe you can help to improve it. 自动判断 中文中文(简体)中文(香港)中文(繁体)英语日语朝鲜语德语法语俄语泰语南非语阿拉伯语阿塞拜疆语比利时语保加利亚语加泰隆语捷克语威尔士语丹麦语第维埃语希腊语世界语西班牙语爱沙尼亚语巴士克语法斯语芬兰语法罗语加里西亚语古吉拉特语希伯来语印地语克罗地亚语匈牙利语亚美尼亚语印度尼西亚语冰岛语意大利语格鲁吉亚语哈萨克语卡纳拉语孔卡尼语吉尔吉斯语立陶宛语拉脱维亚语毛利语马其顿语蒙古语马拉地
Re: Re: Filesystem in RTEMS
Yes, Everything is going well, if I erase the flash before use. But, I need to store some files into flash, and reuse them when I restart my system. I can not erase the flash every time. Best wishes, xuelin.t...@qkmtech.com From: Chris Johns Date: 2017-10-23 07:01 To: xuelin.t...@qkmtech.com; Sebastian Huber CC: users@rtems.org Subject: Re: Filesystem in RTEMS On 22/10/2017 21:00, xuelin.t...@qkmtech.com wrote: > Everything worked well, after erasing the whole flash. But errors came up > without erasing it. You need to erase the flash before use. JFFS2 cannot tell the flash was unused and available for use so it has to assume it has become corrupted and reports this. Chris ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Re: Filesystem in RTEMS
I use JFFS2 on Xilinx Zedboard, QSPI. The flash I use has a hybrid combination of 4KB and 64KB sectors. I just ignored the 4KB sectors, and use 64KB sectors only. So, the size of block is 64KB same the size of sector in my case. I think it may be related to my device drivers... but, I am not sure about this. What is your device driver in your case? Using QSPI handlers from Xilinx BSP directly? Best wishes, xuelin.t...@qkmtech.com From: jameszxj Date: 2017-10-23 15:13 To: rtems-us...@rtems.org Subject: Re: Filesystem in RTEMS I have encountered a problem like this. I set wrong block size. Maybe you can try to change the block size. I use jffs2 on xilinx zc7020 board, QSPI -- Original -- From: "Sebastian Huber";; Date: Mon, Oct 23, 2017 01:07 PM To: "xuelin.t...@qkmtech.com"; Cc: "users@rtems.org"; Subject: Re: Filesystem in RTEMS On 22/10/17 12:00, xuelin.t...@qkmtech.com wrote: > I have mounted JFFS2 successfully, according to the return value. > Yes, it takes some time to do the mounting work. > > But, when I downloaded a file like "test.txt" into flash via FTP and > restarted the system, error came up. Unmount the file system before you restart the system. > > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at > 0x01FC0028: 0xE5DF instead > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at > 0x01FC002C: 0xE5DF instead > <5>JFFS2: Further such events for this erase block will not be printed > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at > 0x01FD: 0x000C instead > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at > 0x01FD0004: 0xB0B1 instead > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at > 0x01FD0008: 0x0054 instead > <5>JFFS2: Cowardly refusing to erase blocks on filesystem with no valid JFFS2 > nodes > <5>JFFS2: empty_blocks 0, bad_blocks 0, c->nr_blocks 510 > mount failed. > > Everything worked well, after erasing the whole flash. But errors came > up without erasing it. Make sure your flash driver works correctly. It must support bytewise programming. -- 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. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Re: Filesystem in RTEMS
Could you please share your flash driver with me?
In my code, my flash is accessed via a handler defined in Xilinx BSP.
typedef struct {
rtems_jffs2_flash_control super;
XQspiPs *flash_instance;
} flash_control;
static flash_control *get_flash_control(rtems_jffs2_flash_control *super) {
return (flash_control *)super;
}
static int flash_read(
rtems_jffs2_flash_control *super,
uint32_t offset,
unsigned char *buffer,
size_t length) {
flash_control *self = get_flash_control(super);
XQspiPs *flash_handle = self->flash_instance;
FlashRead(flash_handle, offset, length, QUAD_READ_CMD, temp_buffer, buffer);
return S25FL256S_SUCCESS;
}
static int flash_write(
rtems_jffs2_flash_control *super,
uint32_t offset,
unsigned char *buffer,
size_t length) {
flash_control *self = get_flash_control(super);
XQspiPs *flash_handle = self->flash_instance;
uint32_t num = length / S25FL256S_PAGE_SIZE;
uint32_t remaining = length % S25FL256S_PAGE_SIZE;
uint32_t written;
for (written = 0; written < num; written++) {
FlashWrite(flash_handle, beginning + written*S25FL256S_PAGE_SIZE, \
S25FL256S_PAGE_SIZE, WRITE_CMD, \
buffer + written*S25FL256S_PAGE_SIZE);
}
if (remaining) {
FlashWrite(flash_handle, beginning + num*S25FL256S_PAGE_SIZE, \
remaining, WRITE_CMD, buffer + num*S25FL256S_PAGE_SIZE);
}
return S25FL256S_SUCCESS;
}
where, my FlashRead and FlashWrite functions will invoke the functions defined
in Xilinx BSP to transfer data from/into flash.
I do not know where the problem is...
Best wishes,
xuelin.t...@qkmtech.com
From: Chris Johns
Date: 2017-10-23 12:19
To: xuelin.t...@qkmtech.com; Sebastian Huber
CC: users@rtems.org
Subject: Re: Filesystem in RTEMS
On 23/10/2017 12:53, xuelin.t...@qkmtech.com wrote:
> Yes, Everything is going well, if I erase the flash before use.
>
> But, I need to store some files into flash, and reuse them when I restart my
> system. I can not erase the flash every time.
Oh I see what you are saying.
I am using the JFFS2 on a Zynq with a 64M byte SPI flash and seeing no issues. I
suggest you check your flash driver and make sure you are writing to the flash
correctly.
Chris
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: Re: Filesystem in RTEMS
Wow, that is so cool. I may not have enough time to do the porting :-) Best wishes, xuelin.t...@qkmtech.com From: jameszxj Date: 2017-10-23 17:26 To: xuelin.t...@qkmtech.com CC: rtems-us...@rtems.org Subject: Re: Re: Filesystem in RTEMS -- Original -- From: "xuelin.t...@qkmtech.com";; Date: Mon, Oct 23, 2017 03:30 PM To: "jameszxj";"users@rtems.org"; Subject: Re: Re: Filesystem in RTEMS > I use JFFS2 on Xilinx Zedboard, QSPI. > The flash I use has a hybrid combination of 4KB and 64KB sectors. I just > ignored the 4KB sectors, and use 64KB sectors only. > So, the size of block is 64KB same the size of sector in my case. > I think it may be related to my device drivers... but, I am not sure about > this. > What is your device driver in your case? Using QSPI handlers from Xilinx BSP > directly? we port QSPI Controller driver and spi nor flash driver from linux. Best wishes, xuelin.t...@qkmtech.com From: jameszxj Date: 2017-10-23 15:13 To: rtems-us...@rtems.org Subject: Re: Filesystem in RTEMS I have encountered a problem like this. I set wrong block size. Maybe you can try to change the block size. I use jffs2 on xilinx zc7020 board, QSPI -- Original -- From: "Sebastian Huber";; Date: Mon, Oct 23, 2017 01:07 PM To: "xuelin.t...@qkmtech.com"; Cc: "users@rtems.org"; Subject: Re: Filesystem in RTEMS On 22/10/17 12:00, xuelin.t...@qkmtech.com wrote: > I have mounted JFFS2 successfully, according to the return value. > Yes, it takes some time to do the mounting work. > > But, when I downloaded a file like "test.txt" into flash via FTP and > restarted the system, error came up. Unmount the file system before you restart the system. > > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at > 0x01FC0028: 0xE5DF instead > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at > 0x01FC002C: 0xE5DF instead > <5>JFFS2: Further such events for this erase block will not be printed > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at > 0x01FD: 0x000C instead > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at > 0x01FD0004: 0xB0B1 instead > <5>JFFS2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at > 0x01FD0008: 0x0054 instead > <5>JFFS2: Cowardly refusing to erase blocks on filesystem with no valid JFFS2 > nodes > <5>JFFS2: empty_blocks 0, bad_blocks 0, c->nr_blocks 510 > mount failed. > > Everything worked well, after erasing the whole flash. But errors came > up without erasing it. Make sure your flash driver works correctly. It must support bytewise programming. -- 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. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: Re: Filesystem in RTEMS
Sorry, I delete some parts of my code.
The sectors of S25FL256S flash chip has a combination of 4KB and 64KB. Only the
64KB sectors will be used, for simplicity, and the beginning address of them is
0x0002.
The "beginning" variable I use here is equal to offset plus 0x0002
(S25FL256S_BOTTOM_GAP_ADDRESS).
The page size of flash is 256B, BTW.
/***/
static int flash_write(
rtems_jffs2_flash_control *super,
uint32_t offset,
unsigned char *buffer,
size_t length) {
flash_control *self = get_flash_control(super);
XQspiPs *flash_handle = self->flash_instance;
uint32_t beginning = offset + S25FL256S_BOTTOM_GAP_ADDRESS;
uint32_t num = length / S25FL256S_PAGE_SIZE;
uint32_t remaining = length % S25FL256S_PAGE_SIZE;
uint32_t written;
for (written = 0; written < num; written++) {
FlashWrite(flash_handle, beginning + written*S25FL256S_PAGE_SIZE, \
S25FL256S_PAGE_SIZE, WRITE_CMD, \
buffer + written*S25FL256S_PAGE_SIZE);
}
if (remaining) {
FlashWrite(flash_handle, beginning + num*S25FL256S_PAGE_SIZE, \
remaining, WRITE_CMD, buffer + num*S25FL256S_PAGE_SIZE);
}
return S25FL256S_SUCCESS;
}
/*/
Best wishes,
xuelin.t...@qkmtech.com
From: Sebastian Huber
Date: 2017-10-23 17:44
To: xuelin.t...@qkmtech.com; Chris Johns
CC: users@rtems.org
Subject: Re: Filesystem in RTEMS
On 23/10/17 11:40, Sebastian Huber wrote:
>
>
> On 23/10/17 11:33, xuelin.t...@qkmtech.com wrote:
>> static int flash_write(
>> rtems_jffs2_flash_control *super,
>> uint32_t offset,
>> unsigned char *buffer,
>> size_t length) {
>>
>> flash_control *self = get_flash_control(super);
>> XQspiPs *flash_handle = self->flash_instance;
>> uint32_t num = length / S25FL256S_PAGE_SIZE;
>> uint32_t remaining = length % S25FL256S_PAGE_SIZE;
>> uint32_t written;
>>
>> for (written = 0; written < num; written++) {
>> FlashWrite(flash_handle, beginning + written*S25FL256S_PAGE_SIZE, \
>>
>> S25FL256S_PAGE_SIZE, WRITE_CMD, \
>> buffer + written*S25FL256S_PAGE_SIZE);
>> }
>> if (remaining) {
>> FlashWrite(flash_handle, beginning + num*S25FL256S_PAGE_SIZE, \
>> remaining, WRITE_CMD, buffer + num*S25FL256S_PAGE_SIZE);
>> }
>> return S25FL256S_SUCCESS;
>> }
>>
>> where, my FlashRead and FlashWrite functions will invoke the
>> functions defined in Xilinx BSP to transfer data from/into flash.
>>
>> I do not know where the problem is...
>
> You assume length % S25FL256S_PAGE_SIZE == 0.
Sorry, I should have read the code more carefully.
What is "beginning"? Why don't you use "offset" in this function?
--
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.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
C99 "restrict" key word in RTEMS
Dear all, I used the "restrict" key word in my application to delcare some pointers, and unfortunately an error came up, like "error: expected ';', ',' or ')' before 'src' const void *restrict src, int len);" As I know, "restrict" is a key word in C99 standard, so does rtems support this feature? Best wishes, xuelin.t...@qkmtech.com ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
'UNEXPECTED_SECTIONS' error
Dear all, When I tried to compile and link my application, an error came up, saying, ../../../../arm-rtems4.11/bin/ld: myapp.elf section `.unexpected_sections' will not fit in region `UNEXPECTED_SECTIONS' makefile:50: recipe for target 'myapp.elf' failed ../../../../arm-rtems4.11/bin/ld: region `UNEXPECTED_SECTIONS' overflowed by 1048577 bytes collect2: error: ld returned 1 exit status make: *** [myapp.elf] Error 1 I didnot define any new sections, so any help here? Thanks. Best wishes, xuelin.t...@qkmtech.com ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
OpenAMP using Linux and RTEMS
Dear, all: I am trying to build up my system using OpenAMP framework, Linux on CPU0, and RTEMS on CPU1. Has anyone done this before? The communication between two cores is based on shared memory in this framework. So, the memory I allocate for RTEMS is about 64MB, for example, from 0x1000_ to 0x1400_, and the other is for Linux. If the shared memory locates in RTEMS workspace, everything might work, but unstable. But if it locates outside the RTEMS like the demo shows, it would go wrong during initialization. So, my question is that, how can RTEMS access memory outside its workspace? In my example, is it possible to access the memory like 0x1600_? And what is the nocache for? Best wishes, xuelin.t...@qkmtech.com ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
What is NOCACHE memory for?
Dear all, In linkcmds, I find out that there is a block of memory called NOCACHE, with the length of 1MB. What is this memory for in RTEMS? Best wishes, xuelin.t...@qkmtech.com ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
