Alan .. can you confirm what I am interpreting?
On 08/15/2015 02:56 PM, Rohini Kulkarni wrote:
On Sun, Aug 16, 2015 at 1:13 AM, Joel Sherrill
mailto:joel.sherr...@oarcorp.com>> wrote:
On 08/15/2015 02:35 PM, Rohini Kulkarni wrote:
Hi
I need some help with this
1.
Can't call method "message" on an undefined value at
/usr/libexec/git-core/git-send-email line 1211.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS
Reminding everyone that we are wrapping up GSOC and evaluations are due
next week.
-- Forwarded message --
From: "'Carol Smith' via Google Summer of Code Mentors List" <
google-summer-of-code-mentors-l...@googlegroups.com>
Date: Aug 10, 2015 10:42 AM
Subject: [GSoC Mentors] GSoC 201
t the RSB
recipe isn't accounting for. Help requested
Joel Sherrill (6):
libjpeg: Fix comments
Add libavl-1.4.0: Eliminates need to be in rtems-addon-packages
Add GSL 1.16: Removes need to be in rtems-addon-packages
Add ncurses 5.9: Not building yet
Add readline: Not building
---
rtems/config/graphics/libjpeg-9a-1.cfg |2 +-
source-builder/config/libjpeg-1.cfg|2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/rtems/config/graphics/libjpeg-9a-1.cfg
b/rtems/config/graphics/libjpeg-9a-1.cfg
index a366da9..303d67c 100644
--- a/rtems/config/g
---
rtems/config/4.11/devel/libtecla.bset | 20
rtems/config/devel/libtecla-1.6.3-1.cfg | 21
source-builder/config/libtecla-1.cfg| 78 +++
3 files changed, 119 insertions(+), 0 deletions(-)
create mode 100644 rtems/config/4.11/devel/libte
---
rtems/config/4.11/devel/readline.bset | 20
rtems/config/devel/readline-6.3-1.cfg | 21 +
source-builder/config/readline-1.cfg | 78 +
3 files changed, 119 insertions(+), 0 deletions(-)
create mode 100644 rtems/config/4.11/devel/readline
---
rtems/config/4.11/devel/ncurses.bset | 20
rtems/config/devel/ncurses-5.9-1.cfg | 21
source-builder/config/ncurses-1.cfg | 89 ++
3 files changed, 130 insertions(+), 0 deletions(-)
create mode 100644 rtems/config/4.11/devel/ncurses.bse
---
rtems/config/4.11/devel/libavl.bset | 20 +
rtems/config/devel/libavl-1.4.0-1.cfg | 21 ++
source-builder/config/libavl-1.cfg| 71 +
3 files changed, 112 insertions(+), 0 deletions(-)
create mode 100644 rtems/config/4.11/devel/libavl
---
rtems/config/4.11/devel/gsl.bset | 20 ++
rtems/config/devel/gsl-1.16-1.cfg | 21 +++
source-builder/config/gsl-1.cfg | 70 +
3 files changed, 111 insertions(+), 0 deletions(-)
create mode 100644 rtems/config/4.11/devel/gsl.bset
cr
his without FPU support too?
Daniel .. when you are happy, we can push it.
Should this go on the 4.11 branch and master? If so, it needs a ticket.
Thanks and Regards,
Sudarshan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/li
On 8/13/2015 10:52 AM, Daniel Gutson wrote:
El 13/8/2015 12:49, "Gedare Bloom" mailto:ged...@gwu.edu>>
escribió:
>
> Daniel,
>
> Unknown deadline right now. Probably whenever Joel can get around to
> it! Realistically, we can create a bugfix "dot r
On 8/27/2015 4:10 PM, Daniel Gutson wrote:
On Thu, Aug 27, 2015 at 6:06 PM, Joel Sherrill
wrote:
On 8/13/2015 10:52 AM, Daniel Gutson wrote:
El 13/8/2015 12:49, "Gedare Bloom" mailto:ged...@gwu.edu>> escribió:
>
> Daniel,
>
> Unknown deadline right
CodeSonar in these
last year.
[tools/cpu/nios2/memory.c:99]: (error) Uninitialized variable: memory
[tools/cpu/nios2/ptf.c:542]: (error) fprintf format string has 1
parameters but only 0 are given.
[tools/cpu/nios2/ptf.c:580]: (error) Memory leak: new_prefix
Those worth a look. But again a host-s
that situation.
The h8sx and h8s are the only viable parts of the family left.
I wanted to start deprecation discussions now that we are past
branching 4.11. :)
My intention would be to announce ports and BSPs as deprecated in
4.11 and remove them from the master to reduce our work going
forward.
--
being sold and we should support it?
Again, mark it as deprecated in the 4.11 notes and remove it
on master if no one objects.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS
Updates #2405.
---
c/src/lib/libbsp/shared/umon/umon.h | 4
cpukit/posix/include/rtems/posix/ptimer.h| 4
cpukit/rtems/include/rtems/rtems/dpmemimpl.h | 4
3 files changed, 12 insertions(+)
diff --git a/c/src/lib/libbsp/shared/umon/umon.h
b/c/src/lib/libbsp/shared/umo
Updates #2405.
---
cpukit/libmisc/dumpbuf/dumpbuf.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/cpukit/libmisc/dumpbuf/dumpbuf.c b/cpukit/libmisc/dumpbuf/dumpbuf.c
index 9d34d42..36a8656 100644
--- a/cpukit/libmisc/dumpbuf/dumpbuf.c
+++ b/cpukit/libmisc/dumpbuf/dumpbu
Updates #2405.
---
tools/cpu/nios2/ptf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/cpu/nios2/ptf.c b/tools/cpu/nios2/ptf.c
index 7a31c11..2b9448c 100644
--- a/tools/cpu/nios2/ptf.c
+++ b/tools/cpu/nios2/ptf.c
@@ -578,6 +578,7 @@ void ptf_printf(FILE *s, struct ptf *tree, char *pref
Updates #2405.
---
tools/cpu/nios2/memory.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/cpu/nios2/memory.c b/tools/cpu/nios2/memory.c
index cd88b8b..9b56d64 100644
--- a/tools/cpu/nios2/memory.c
+++ b/tools/cpu/nios2/memory.c
@@ -20,6 +20,8 @@ memory_desc *find_me
been fixed already.
Some of the error reports remain, though. I opened a ticket for that
and will send a patch that fixes the issues Joel mentioned as worth
looking at. I'll open separate tickets for issues reported as
"warning" and "portability" (such as the void * thing)
o
make a rule to ban use of the non-n versions of the string methods.
>El 1/9/2015 18:41, "Joel Sherrill"
>escribió:
>
>Updates #2405.
>---
> cpukit/libmisc/dumpbuf/dumpbuf.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
>diff --git a/cpuk
-intuitive things and it is safer to implicitly make all tasks
FP rather than letting people trip over implicit uses of the FPU.
--joel
Thanks,
Alan
On 8/31/15, 2:40 AM, "Sebastian Huber"
wrote:
Hello Alan,
I am not sure how Gaisler manages this in their RCC, but I think for
standar
On 9/2/2015 8:43 AM, Martin Galvan wrote:
On Wed, Sep 2, 2015 at 10:39 AM, Gedare Bloom wrote:
Joel,
Coordinate your patch/fixes with this patch. (I do prefer the separate
patches that Joel gave. Small atomic commits are better.)
Gedare
I thought he'd seen this e-mail :)
I agree
", s);
+ ptf_printf(s, leaf->sub, new_prefix);
+ free(new_prefix);
+}
break;
};
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS
+ *
+ * @param buffer The buffer we'll print.
+ * @param length Amount of bytes from \p buffer we'll print.
+ */
+static void Dump_Line(const unsigned char *buffer, const unsigned int length)
{
-
- int i;
- char line_buffer[120];
-
- line_buffer[0] = '\0';
-
- for( i
uot;C" {
+#endif
+
/**
* @defgroup ClassicDPMEMImpl Dual Ported Memory Manager Implementation
*
@@ -104,5 +108,5 @@ RTEMS_INLINE_ROUTINE Dual_ported_memory_Control
*_Dual_ported_memory_Get (
}
#endif
-#endif
+#endif /* _RTEMS_RTEMS_DPMEM_INL */
/* end of include file */
--
Joel Sher
On 9/3/2015 12:18 PM, Daniel Gutson wrote:
On Thu, Sep 3, 2015 at 1:21 PM, Joel Sherrill wrote:
On 9/2/2015 4:54 PM, Martin Galvan wrote:
I also used the 'n' versions of the string functions, #define'd magic
numbers
and added a few comments.
Great on the 'n
Should be committed now.
I guess one of us should have compiled it. :)
--joel
On 9/3/2015 3:25 PM, Martin Galvan wrote:
Apparently 'free' is defined as a macro which takes two arguments and calls
rtems_bsdnet_free. When fixing #2405 I added a missing 'free' but didn
ly beyond the scope of the tool.
This was not intended to be idiot proof as much as automate the
tedious and fragile build/testing process of the tools.
It can email the results if you like.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.co
inters to objects
on the stack into paths where they will be used by another task.
But in general terms, once we look at the various types of logical
memory objects, we can decide what protection makes sense, alignment
impacts, page table limitations, etc.
--joel
Thanks,
Daniel.
> >
On September 10, 2015 2:37:35 AM CDT, Peter Dufault wrote:
>
>> On Sep 9, 2015, at 19:02 , Joel Sherrill
>wrote:
>>
>> As Sebastian mentioned if you make the task stack accessible by only
>> a single stack, you have to be careful not to pass pointers to
>o
Marco,
This looks fine and I will apply it but I want to put it on 4.11
and master. Can you file a quick ticket on it?
Thanks.
--joel
On 9/10/2015 10:20 AM, Marcos Diaz wrote:
flush_data_cache uses R0 directly but doesn't list it as a clobbered register.
Compiling with -O3 made this
down to one release per year, the numbers
won't grow terribly fast.
One release per year would be nice.
We may need more flexibility.
I just wanted to say, that the four years or so it took to release
RTEMS 4.11 was a bit long.
Yes I agree. I think Joel wants a 4.12 which is close to 4.1
:32:4: error: #error
"Invalid BSP_GPIO_PIN_COUNT or BSP_GPIO_PINS_PER_BANK."
#error "Invalid BSP_GPIO_PIN_COUNT or BSP_GPIO_PINS_PER_BANK."
^
../../../../../.././lpc1768_mbed_ahb_ram_eth/lib/include/bsp/gpio.h:41:5:
error: division by zero in #if
#if GPIO_LAST_BANK_PINS >
from
../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/cpu.c:16:
../../../../cpukit/../../../generic_or1k/lib/include/rtems/score/rbtree.h:21:22:
fatal error: sys/tree.h: No such file or directory
#include
^
compilation terminated.
--
Joel Sherrill, Ph.D.
Thanks. Should be committed now to 4.11 and master.
On 9/10/2015 1:08 PM, Marcos Díaz wrote:
Ticket #2416
https://devel.rtems.org/ticket/2416
Please let me know if this is ok and if I need to submit something else.
Greetings
On Thu, Sep 10, 2015 at 12:48 PM, Joel Sherrill mailto:joel.sherr
.. any ideas other than an oddity due to a simulator?
Thanks in advance
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcor
revision related issue, is there a way programmatically to
know which revision the board is? That way the BSP could auto-detect the right
thing to do. Otherwise, we may be looking at a BSP variant or a build option.
I would rather avoid those if we can auto-detect.
--joel
Thanks,
Ragunath
On Mon
>
>This is in my version.
>
>Please tell me so I can check if is the revision, or perhaps is
>something else in u-boot initialization.
>
>
>For the question Joel asked there is a way:
>
>http://dumb-looks-free.blogspot.com.ar/2014/05/beaglebone-black-bbb-revision-se
On 9/17/2015 8:43 AM, Marcos Díaz wrote:
Yes, in my case the older (that doesn't work) revision is a
XAM3359AZCZ100
And the rev C (that works well with cache) is
AM3358BZCZ100
Can we determine that in software?
On Thu, Sep 17, 2015 at 10:32 AM, Joel Sherrill mailto:joel.
se it is a simulator.
The numbers not ending in "5" is a bit unusual. The test consists of
four tasks:
+ one runs every 5 seconds
+ one every 10
+ one every 15
+ IDLE
It exits when one notices it has gone over 30 seconds.
Thank you Joel! I have another question if y
etter World (TM)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free
Hi
As LWIP drivers show up and we likely need documentation for
LWIP on RTEMS, I am thinking we need a new repo for this.
Even for a case like the Beagle, we could have instructions
and a pointer.
For more open licensed drivers, we could directly include them.
Any thoughts, comments?
--
Joel
ually have an answer.
--joel
On 9/17/2015 2:05 PM, Marcos Díaz wrote:
Ragu,
I would like you to confirm which revision you have, for this I printed the
following registers in the BBB:
0x44E10600 and 0x44E10604
The first will print something like:
1b94402e for BBB rev A5C (XAM3359AZCZ100) ( 1b
t;> Adhering to the style rules will help alleviate some common reasons
>> for iterating on patches. We are most concerned in locations of
>shared
>> code, but now we are also less lenient about custom BSP code, since
>> that code often gets copied into new BSPs and propagates the
>
r. That's about the
>>time the test was initially written.
>>
>>It is likely running faster than "real time" because it is a
>simulator.
>>The numbers not ending in "5" is a bit unusual. The test consists of
>>four tasks:
>>
>&
_
>>> users mailing list
>>> us...@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>Peter
>-
>Peter Dufault
>HD Associates, Inc. Software and System Engineering
>
>This email, like most email, is delivered unencrypted via internet
>email protocols subject to interception and tampering. Contact HDA to
>discuss methods we can use that ensure secure communication.
>
>___
>devel mailing list
>devel@rtems.org
>http://lists.rtems.org/mailman/listinfo/devel
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
universally supported or nearly so. So no problem to use.
Just a warning to keep squirrelled away. I don't think we should change
anything.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
this really will get many hands to
accomplish.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
== "sparc":
-source += ['freebsd/sys/mips/mips/in_cksum.c',
- 'freebsd/sys/sparc/sparc/in_cksum.c']
+source += ['freebsd/sys/mips/mips/in_cksum.c']
if bld.get_env()["RTEMS_ARCH"] == "sparc64":
On 10/1/2015 3:34 PM, Chris Johns wrote:
On 2/10/2015 9:15 am, Joel Sherrill wrote:
On 10/1/2015 2:38 PM, Chris Johns wrote:
On 2/10/2015 8:33 am, Sebastian Huber wrote:
Why do you think it is wrong?
Because the check is for 'arm' and the file is 'mips'.
If I r
tasks to print to an
>
>application log instead on the shell. This is all completely doable
>now, as as far as I know newlib provides a per task stdin, etc.
>
>Just start your task and point them where you want them to go.
I think there is a s
.
If I understated or overstated, I am sure Sebastian will correct me but
things are looking good for C11 and C++11 and RTEMS.
--joel
-- Jeff J.
- Original Message -
Import from latest FreeBSD. Move types and defines to
so that it can be customized per target.
newlib/ChangeLog
2015
s.h rather than a silent limiting to 512 at
run-time. Thoughts?
+ I don't see any documentation on this. If I am
correct, this needs to be added. Please confirm me
on this?
Thanks in advance.
--joel
___
devel mailing list
devel@rtems.
on't work from RTEMS are intentionally disabled.
They are marked with RTEMS_REMOVED rather than deleted because it
makes getting updates from the original location easier. The changes
when you diff are more contained and well defined this way.
Don't remove i
complete, and ensure the results are merged as appropriate.
It is a blast but we need mentors to make it happen. :)
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 3
is user documentation, lists of supported architectures,
tool targets, GCC master test list, etc.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
are no longer in use, etc.
Help reduce the maintenance!
Thanks.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On October 13, 2015 8:24:32 PM CDT, Chris Johns wrote:
>On 14/10/2015 11:06 am, Joel Sherrill wrote:
>> I am looking for suggestions on BSPs to remove. If you
>> have used a BSP in the past but no longer use it, please
>> speak up. BSPs with no users are baggage to the p
com
Better Technology, Better World (TM)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/
Hi
psxcancel and spcontext01 fail on the master.
I thought all tests were passing on sparc/erc32.
Any thoughts?
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
his ideas on tiers before.
On 14/10/15 02:06, Joel Sherrill wrote:
Hi
I am looking for suggestions on BSPs to remove. If you
have used a BSP in the past but no longer use it, please
speak up. BSPs with no users are baggage to the project.
If you have suggestions for other reasons, please speak
closes #2431.
---
cpukit/sapi/include/confdefs.h | 14
doc/user/conf.t | 55 ++
testsuites/psxtests/psximfs02/init.c |4 +-
3 files changed, 71 insertions(+), 2 deletions(-)
diff --git a/cpukit/sapi/include/confdefs.h b/c
Hi
I bumped binutils to 2.25 and can build a moxie toolset. This
is the first time in a while.
Should the other targets be bumped to 2.25 for RTEMS 4.11?
Or just the moxie?
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman
Thank you.
I have made these changes. Did the explanation make enough sense
where you would know what it did? :)
On 10/20/2015 5:41 PM, Nick Withers wrote:
A couple of doco typos...
On Tue, 2015-10-20 at 14:47 -0500, Joel Sherrill wrote:
closes #2431.
---
cpukit/sapi/include/confdefs.h
On 10/20/2015 6:13 PM, Chris Johns wrote:
On 21/10/2015 9:30 am, Joel Sherrill wrote:
I bumped binutils to 2.25 and can build a moxie toolset. This
is the first time in a while.
Excellent. This is ok for 4.11.
And I found a typo in moxiesim/configure.ac and have now built
that BSP.
I
omething decided to trigger a
context switch and left a dispatch disable critical but was
never in a dispatch disable critical section. So when it
left/decremented it, there was no corresponding enter/increment.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
01:24 schrieb Chris Johns:
On 21/10/2015 12:56 am, Joel Sherrill wrote:
On 10/20/2015 6:15 AM, Sebastian Huber wrote:
Maybe we should build a list of BSP directories and find maintainers for
each directory in some time frame. Then remove all BSPs without a
maintainer.
That is one approach. Anot
ags, max_held_buffers, &fs);
if (rc)
{
+rtems_rfs_mutex_unlock (&rtems->access);
+rtems_rfs_mutex_destroy (&rtems->access);
free (rtems);
return rtems_rfs_rtems_error ("initialise: open", errno);
}
--
Joel Sherrill, Ph.D. Dir
On 10/21/2015 9:09 AM, Isaac Gutekunst wrote:
On 10/21/2015 09:58 AM, Joel Sherrill wrote:
On 10/21/2015 8:35 AM, Sebastian Huber wrote:
On 21/10/15 15:08, Isaac Gutekunst wrote:
On 10/21/2015 09:00 AM, Sebastian Huber wrote:
On 21/10/15 14:56, Isaac Gutekunst wrote:
On 10/21
dir01
jffs2_fssymlink
jffs2_fstime
devfs01
devfs02
devfs03
devfs04
termios02
termios03
termios04
stringto01
math
mathf
tar03
mathl
complex
sptimecounter01
spfatal26
spinternalerror01
fsnofs01
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com
Hi
lm32, moxie, and nios2 all have generic issues with C++ applications
which indicate C++ is not really supported by gcc for these targets.
Would it be OK to disable C++ for those targets?
--joel
___
devel mailing list
devel@rtems.org
http
Hi
I think the or1k tools are out of sync with RTEMS now.
or1k-rtems4.11-gcc -B../../../../../generic_or1k/lib/ -specs bsp_specs -qrtems
-O2 -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration
-Wstrict-prototypes -Wnested-externs-O2 -o hello.exe init.o
/data/home/joel
Please file a ticket on the off set of tests installing. It
definitely is clearly something that needs a decision so
we can make them consistent.
I am guessing that we not install any except maybe the samples.
On 10/21/2015 2:48 PM, Isaac Gutekunst wrote:
Thanks Joel, that pushed me in the
work space.
After that, you will need to figure out how many objects each driver
really uses and consider that the base set which an application
configuration must account for. There isn't really any system for
this built in.
--joel
___
devel mailing list
On 10/21/2015 3:52 PM, Daniel Gutson wrote:
On Wed, Oct 21, 2015 at 3:41 PM, Joel Sherrill
wrote:
Hi
lm32, moxie, and nios2 all have generic issues with C++ applications
which indicate C++ is not really supported by gcc for these targets.
Could you please provide more information/details
or1k-rtems4.11-gcc -B../../../../../generic_or1k/lib/ -specs bsp_specs -qrtems
-O2 -O0 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration
-Wstrict-prototypes -Wnested-externs-O2 -o hello.exe init.o
/data/home/joel/rtems-4.11-work/tools/bin/../lib/gcc/or1k-rtems4.11/4.8.3
On October 22, 2015 12:28:31 AM CDT, Sebastian Huber
wrote:
>
>
>On 21/10/15 23:02, Joel Sherrill wrote:
>>
>> ==
>> NIOS2
>> ==
>>
>> Missing ne
e FSF paper work, and
hopefully the or1k-gcc will be upstream soon.
This is great news! This will massively improve our ability to
support this target long term.
--joel
On Wed, Oct 21, 2015 at 7:42 PM, Joel Sherrill
wrote:
Hi
I think the or1k tools are out of sync with RTEMS now.
or1k-rtem
r: I admit this is a quick hack. Continue discussing long-term
solutions.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
buffering internally and confdefs.h accounts for them.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On 10/22/2015 9:42 AM, Isaac Gutekunst wrote:
On 10/22/2015 10:30 AM, Joel Sherrill wrote:
On 10/22/2015 8:55 AM, Isaac Gutekunst wrote:
On 10/22/2015 01:33 AM, Sebastian Huber wrote:
On 21/10/15 21:53, Isaac Gutekunst wrote:
Hi Devel,
I looked for a while, but couldn't find
gt;> executing = 0xc01585c8,
>>>>>>>> heir = 0xc0154038,
>>>>>>>> dispatch_necessary = true,
>>>>>>>> time_of_last_context_switch = {
>>>>>>>> sec = 2992,
>>>>>>>> frac = 10737447432380511034
>>>>>>>> },
>>>>>>>> Stats = {}
>>>>>>>> }
>>>>>>>
>>>>>>> No, this doesn't look good. According to the stack trace you are
>in
>>>>>>> thread context. However, we
>>>>>>> have executing != heir and dispatch_necessary == true. This is a
>>>>>>> broken state itself. I guess,
>>>>>>> something is wrong with the interrupt level so that a context
>>>>>>> switch is blocked. On ARMv7-M
>>>>>>> this is done via the system call exception.
>>>>>>>
>>>>>> This is a bit beyond my RTEMS knowledge. What would you advise
>>>>>> looking into?
>>>>>
>>>>> I would try to instrument the code to figure out where the thread
>>>>> dispatch disable level goes negative.
>>>>>
>>>>
>>>> We just did. I added a check in _ARMV7M_Interrupt_service_leave to
>>>> see if the _Thread_Dispatch_disable_level is positive before the
>>>> decrementing it and this eventually fails.
>>>>
>>>> I'm not sure if this tells us much because I think the call itself
>>>> correct. In this particular case it is processing an I2C
>interrupt.
>>>> I will try to see if we can capture information about the sequence
>of
>>>> changes to the _Thread_Dispatch_disable_level just before the point
>in
>>>> which we know something is clearly wrong (i.e., decreasing it below
>>>> zero.)
>>>
>>> Since the isr_nest_level is 0, I don't think its a problem with the
>spots that use
>>> _ARMV7M_Interrupt_service_leave(). Did you check the interrupt
>priorities? See also
>>>
>>> https://lists.rtems.org/pipermail/users/2015-June/029155.html
>>>
>> Thanks for the pointer to this posting. It seems like a very similar
>situation to what we are
>> experiencing -- especially considering that we invoke an RTEMS call
>in our ethernet isr.
>> Unfortunately, all our interrupts use the default interrupt priority
>level set in the bsp
>> header file as:
>>
>> #define BSP_ARMV7M_IRQ_PRIORITY_DEFAULT (13 << 4)
>>
>> which should be mean that they are all non-NMIs unless we explicitly
>set their interrupt level
>> lower.
>>
>>
>>
>>
>> ___
>> 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
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On October 23, 2015 7:02:34 AM CDT, Joel Sherrill
wrote:
>
>
>On October 22, 2015 1:37:18 PM CDT, Isaac Gutekunst
> wrote:
>>I think I may have some information that's actually useful.
>>
>>I've managed to actually execute some tests and lots of the
On 10/23/2015 8:01 AM, Isaac Gutekunst wrote:
On 10/23/2015 08:50 AM, Joel Sherrill wrote:
On October 23, 2015 7:02:34 AM CDT, Joel Sherrill
wrote:
On October 22, 2015 1:37:18 PM CDT, Isaac Gutekunst
wrote:
I think I may have some information that's actually useful.
I've
ince level is equal to 0x80 this sets basepri to 0x80
>rtems_interrupt_enable( level )
>.
>.
>.
>function exits with basepri still set to 0x80 instead of 0x0
>
>___
>devel mailing list
>devel@rtems.org
>http://lists.rtems.org/mail
else uses it so should not be impacted.
Plus newlib doesn't know anything about our Ada glue layer.
Best to keep it that way.
Best regards,
Jan
--
Joel Sherrill, Ph.D.
Check out RTEMS at https://www.rtems.org
Truly free real-time operating s
On 10/29/2015 9:20 AM, Jan Sommer wrote:
Am Thursday 29 October 2015, 08:45:57 schrieb Joel Sherrill:
On 10/29/2015 8:14 AM, Jan Sommer wrote:
Hi,
This patch will make the define _NCPUWORDS accessible for the ada runtime. It
is necessary to model the pthread_attr_t implementation for
to mentor.
Thanks.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
esn't look like a horizontal sweep in 2013 and another
by Eric Norum in 2004. Not sure about this one.
Any others?
--
Joel Sherrill, Ph.D.
Check out RTEMS at https://www.rtems.org
Truly free real-time operating system
___
devel mailing list
devel@rtem
On Nov 4, 2015 1:57 PM, "Gedare Bloom" wrote:
>
> Did you bootstrap -c and then bootstrap? I think I saw this error
> earlier today too, with a new sparc toolchain, but then it went away
> after i rm-rf'd my build tree and tried over.
Hmm.. I thought I did that but am not sure. Maybe Martin can c
On Nov 4, 2015 1:39 PM, "Martin Galvan" <
martin.gal...@tallertechnologies.com> wrote:
>
> Hi everyone! I'm currently having some trouble when building RTEMS
> from the git mainline. I'm using a toolchain built using (a fairly
> recent) RSB. My configure is:
>
> ../source/configure --target=arm-rte
On Nov 10, 2015 6:56 AM, "Sebastian Huber" <
sebastian.hu...@embedded-brains.de> wrote:
>
>
>
> On 08/11/15 01:05, Chris Johns wrote:
>>
>> Are there any architecture regressions with gcc-6?
>
>
> m32c, moxie, v850 don't work with GCC 6.
Are there gcc PRs filed for all of these?
> epiphany and or
. :)
Please pitch in. Many hands make light work. Plus there is a cool t-shirt in
it for you. :)
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
I don't see any obvious issues with importing these. I was mainly
looking to make sure nothing disappeared that we might have
added over the years. I didn't spot anything.
--joel
On Tue, Nov 17, 2015 at 8:29 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
&
with 4.11 tools, this bump forces
a distinction.
Usually the forced bump for tools is a newlib or gcc incompatibility.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
or I will timeout soon and start cutting the release.
Thanks.
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
I got this pull request from github and wanted to pass it along.
Chris..?
--joel
Forwarded Message
Subject:[rtems-source-builder] Various bugfixes for building rtems
4.9,4.10,4.11 and 4.12 (#5)
Date: Fri, 20 Nov 2015 08:38:20 -0600
From: Goetz Pfeiffer
Reply-To
On Sun, Nov 22, 2015 at 4:14 PM, Chris Johns wrote:
> On 21/11/2015 1:40 AM, Joel Sherrill wrote:
> > I got this pull request from github and wanted to pass it along.
>
> This is a great patch with some small issues. I will respond in the
> ticket (https://devel.rtems.org/tic
401 - 500 of 6233 matches
Mail list logo
