Tested and built successfully, so I pushed both patches:
https://git.rtems.org/rtems/commit/?id=6dc5c03fad3ddd51423d21b5d60d24b62bb653e9
https://git.rtems.org/rtems/commit/?id=5e3096db5a1d766ece4068fbfe625c8a3db31b23
Congratulations PV!
On Mon, Jul 4, 2016 at 8:16 AM, punit vara wrote:
>> (Qui
Also, I think git send-email has an option to send all the patches in
the same series as replies to a single thread. See if you can use it
in the future.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On Fri, Jul 1, 2016 at 6:12 PM, Martin Galvan
wrote:
> const uint32_t is_idle = AM335X_CM_PER_EPWMSS0_CLKCTRL_IDLEST_FUNC <<
> AM335X_CM_PER_EPWMSS0_CLKCTRL_IDLEST_SHIFT;
My bad: this actually signals that the module is *not* idle. Maybe it
could be called i
Hi Punit, thanks for the patch. As we spoke in the group chat with the other
mentors, this seems to
be good for a first version. I'll be pointing out the required changes for the
next version, but
unless somebody sees anything blocking this should be good to merge.
Besides improving the code its
Thanks for re-sending. FYI the "v2" goes for all the patches in the
thread, not just the one you actually changed. If you want to be
extra-clear you could add a "Changes in v2:" header to each patch.
On Thu, Jun 30, 2016 at 6:04 PM, Punit Vara wrote:
> + if((pwm_id <3) && (pwm_id >=0)) {
> + sw
Thanks for the patch. FYI we usually tag patches as [PATCH v2], [PATCH
v3] and so on for patch versions greater than 1.
One thing I've noticed (and that I missed for v1) is that in many
places you have things like if((pwmid<3) & (pwmid >=0)), using bitwise
& instead of logical &&. Your tests must'
h.
- Reworking EPWMPinMuxSetup so that it will reconfigure only a
requested pin, thus not breaking any existing user configurations.
The rest we can leave for after the midterm evaluation.
> On Wed, Jun 22, 2016 at 1:07 AM, Martin Galvan
> wrote:
>> Hi Punit, thanks for sending this.
Hi Punit, thanks for sending this. If I understood correctly this is the BBBIO
code
plus some changes of your own, right? If so, I think it would be best to send a
patch
with the BBBIO code as is, and then another with your changes on top of it. I
think
that was what we were going for with Start
On Fri, May 27, 2016 at 12:01 PM, Olufowobi, Habeeb
wrote:
> Hi Martin,
>
> I am able to run HelloWorld with what you provided. I also noticed that the
> process does not terminate by itself and I have to manually kill it. I
> noticed that for the HelloWorld and ticker. Does it behave like that wh
On Fri, May 27, 2016 at 11:15 AM, Olufowobi, Habeeb
wrote:
> Can you please also specify the command line argument used to run hello.exe.
> Let me try that to see if I have some parameters in my command line that was
> not supposed to be there.
Certainly. I'm running the following:
./bin/qemu-sy
On Thu, May 26, 2016 at 5:55 PM, Martin Galvan
wrote:
> On Thu, May 26, 2016 at 5:42 PM, Olufowobi, Habeeb
> wrote:
>> Hi Martin,
>>
>> I am using the Qemu version defined in the RSB which is
>> 42d58e7c6760cb9c55627c28ae538e27dcf2f144.
>
> That seems to b
On Thu, May 26, 2016 at 5:42 PM, Olufowobi, Habeeb
wrote:
> Hi Martin,
>
> I am using the Qemu version defined in the RSB which is
> 42d58e7c6760cb9c55627c28ae538e27dcf2f144.
That seems to be fairly recent; I'll give it a shot myself and get back to you.
__
That's odd, I've used that BSP many times before and it always worked fine.
The BSP README (and patches) are quite old, and IIRC their purpose was to
actually make Qemu
emulate the board properly. Any fairly recent version of Qemu shouldn't need
any additional
patching; I was running RTEMS on it
That's odd, I've used that BSP many times before and it always worked fine.
The BSP README (and patches) are quite old, and IIRC their purpose was to
actually make Qemu
emulate the board properly. Any fairly recent version of Qemu shouldn't need
any additional
patching; I was running RTEMS on it
Hi Punit! Sorry I didn't answer, I was off sick for a couple days. Marcos
and I are a bit crowded so we can't review every bit of your patch right
now (plus we don't have our BBB anymore). Could you make the RGB test work
using SW code only?
___
devel mai
Thanks. Here's what I committed:
https://git.rtems.org/rtems/commit/?id=b4d7d5d52e6459ed4fe490ca272fb6cb83e512aa
However, I got an error when I did the push. Here's the output:
$ git push
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (7/7), done.
W
Pinging this again. Is it ok to commit? I think the patch should still
apply since the file hasn't changed in a while.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Hi Punit! Sorry for the delay; I finally got to review your code.
First and foremost, it'd be great if you could tell us which
StarterWare version/git commit are you using, so that we can keep it
handy when reviewing your code. Sorry if you already mentioned it, my
memory is a bit sketchy these day
CCing Andre.
On Mon, Apr 25, 2016 at 10:23 AM, Martin Galvan
wrote:
> Hi everyone! Just wanted to check on the status for this project. I
> saw it was accepted for the GSoC 2016 (congratulations Mudit!), and
> would like to know what our workflow will be like. I offered to
> co-m
Hi everyone! Just wanted to check on the status for this project. I
saw it was accepted for the GSoC 2016 (congratulations Mudit!), and
would like to know what our workflow will be like. I offered to
co-mentor it and help with code/documentation reviews, especially for
the SD card parts since I did
On Thu, Apr 14, 2016 at 1:34 PM, punit vara wrote:
> Hi all !
>
> I had successfully merged the TI Starter Ware Code with RTEMS.
That's great. Could you show us the resulting directory structure
(perhaps with a diffstat), as well as the changes to Makefile.am?
> Then I tried
> to test it with sa
Hi again, are there any news on this? I haven't heard back from Amar yet.
On Tue, Mar 29, 2016 at 11:25 AM, Martin Galvan
wrote:
> Hi again, I'm attaching the patch for review. It compiles fine for erc32,
> though I couldn't test the samples (I don't have any sparc boar
I'm interested in this too. What's broken, and how could we go about fixing it?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Hi again, I'm attaching the patch for review. It compiles fine for erc32,
though I couldn't test the samples (I don't have any sparc boards, and QEMU only
has leon3 and sun-4m).
I wrote to Amar about my write access but I didn't hear back from him.
Is there a way to check if my account exists usin
On Tue, Mar 22, 2016 at 12:30 PM, Joel Sherrill wrote:
> If you want to submit a patch and reference this email thread URL so
> future generations know what was discussed, feel free. :)
Will do. I'll ask Amar if I have write access.
Thanks!
___
devel m
On Sat, Mar 19, 2016 at 15:59, Joel Sherrill wrote:
> Hi
>
> GCC 6.0 previews give the indentation warning below
>
> ../../../../../rtems/c/src/libchip/network/sonic.c:837:11: warning:
> statement is indented as if it were guarded by... [-Wmisleading-indentation]
>
> on this code from sonic.c.
>
>
Btw, should this fix go to 4.11 as well?
On Sun, Feb 28, 2016 at 5:28 PM, Martin Galvan
wrote:
> Thanks a lot!
>
> On Sat, Feb 27, 2016 at 8:28 PM, Ben Gras wrote:
>> All,
>>
>> I tested this on current HEAD and verified it fixes a case I'd ran
>> into trou
inal email,
> Martin. I hope you like it.
>
> Thank you!
>
>
> On Sat, Feb 27, 2016 at 10:16 PM, Ben Gras wrote:
>> I'm doing a rebase & build right now, thanks for the reminder.
>>
>> On Fri, Feb 26, 2016 at 10:32 PM, Martin Galvan
>> wrote:
&
Hi Ben! Sorry to bother, were you able to test my changes to the BBB
interrupt handler?
On Fri, Feb 12, 2016 at 11:09 AM, Martin Galvan
wrote:
> Thanks Ben! Indeed, any further testing is more than welcome :)
>
> On Thu, Feb 11, 2016 at 7:55 PM, Ben Gras wrote:
>> This looks
On Sun, Feb 21, 2016 at 3:23 AM, punit vara wrote:
> Thank you Martin. I started looking previous year work of BBB as well
> as Rpi work for I2c and SPI . May I know whether are you going to
> mentor for beagle bone black bsp this year ?
You're welcome. I'm not mentoring for the GSoC this year, a
CAN, USB and I2C still need to be developed. We're currently using the AM335x
StarterWare code and it works fine; you may want to base your work on it.
Keep an eye open for licensing issues, though.
___
devel mailing list
devel@rtems.org
http://lists.rtem
Also add a comment explaining why we use that value.
---
cpukit/score/cpu/arm/rtems/score/armv7m.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cpukit/score/cpu/arm/rtems/score/armv7m.h
b/cpukit/score/cpu/arm/rtems/score/armv7m.h
index 251ecdc..0a69363 100644
--- a/cpukit
Cheers,
> Ben
>
>
> On Thu, Feb 11, 2016 at 3:27 PM, Martin Galvan
> wrote:
>> This patch makes the following changes to the Beaglebone IRQ handling code:
>>
>> - Disable support for nested interrupts.
>> - Detect spurious IRQs using the SPURIOUSIRQ field of t
This patch makes the following changes to the Beaglebone IRQ handling code:
- Disable support for nested interrupts.
- Detect spurious IRQs using the SPURIOUSIRQ field of the INTC_SIR_IRQ register.
- Acknowledge spurious IRQs by setting the NewIRQAgr bit of the INTC_CONTROL
register. This cleans
Thanks a lot for this patch. We've tested it and so far it's working fine.
However we have a couple of questions:
1) Is there a reason why you're using the ARMV7M_Timecounter struct instead of
simply having a global boolean like we did in our patch? That pointer casting
trick seems a bit unsafe.
On Mon, Dec 28, 2015 at 4:11 PM, Martin Galvan
wrote:
> On Mon, Dec 28, 2015 at 3:26 PM, Joel Sherrill wrote:
>> A couple of odd guesses. If there are non-RTEMS interrupts, they must
>> be the highest priority.
>
> Precisely, I'd like to know why the ticker interrupt
On Mon, Dec 28, 2015 at 3:26 PM, Joel Sherrill wrote:
> A couple of odd guesses. If there are non-RTEMS interrupts, they must
> be the highest priority.
Precisely, I'd like to know why the ticker interrupt must always have
a lower priority.
> My other guess would be that the interrupt vectoring
Hi everyone! We're still looking into the issue Marcos described here:
https://lists.rtems.org/pipermail/devel/2015-December/013216.html
We noticed the problem seems to go away if we set the ticker interrupt
priority to be the same as for the other interrupts. While that's not
a definitive fix, I
Currently, rtems_gpio_bsp_disable_interrupt disables the interrupts for all the
pins, not just the one that actually caused the interrupt. This patch
fixes that issue.
Closes #2497.
---
c/src/lib/libbsp/arm/beagle/gpio/bbb-gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
On Fri, Dec 4, 2015 at 4:39 PM, Joel Sherrill wrote:
>
> RTEMS has the concept of user/groups. :)
>
> FWIW you should look at the fstests. A subset of them are designed to be
> instanced for different file systems. They have been instanced for RFS,
> DOSFS, and JFFS2.
Got it.
> What's the licens
Hi everyone! While looking at the JFFS2 struct _inode I noticed it has
attributes such as i_uid and i_gid. Are these a leftover from the eCos
port, or does RTEMS have the concept of users/groups?
The reason I'm asking this is because I'm planning on bringing the
F2FS code from Linux, and I'll prob
ons_table {
> rtems_filesystem_mt_entry_lock_t lock_h;
> rtems_filesystem_mt_entry_unlock_t unlock_h;
> ...
> };
>
>
> On 03/12/15 15:30, Martin Galvan wrote:
>>
>> Oh, I see. Do you happen to remember where that lock is
>> acquired/released? I saw the up/dow
that there's a bit of fine-grained locking
there.
On Thu, Dec 3, 2015 at 3:19 AM, Sebastian Huber
wrote:
> Hello,
>
> I used the eCos port of JFFS2 as a base for the RTEMS port. Like in eCos, a
> global lock for a JFFS2 file system instance is used.
>
> - Martin Galvan
Hi everyone! I'm working on porting F2FS from Linux based on the JFFS2
port Sebastian did. When inspecting the code I found that
libfs/jffs2/include/linux/mutex defines struct mutex to be empty, and
all the mutex-related functions to do nothing.
This seems to imply that there's no concurrency mana
On Tue, Nov 24, 2015 at 11:35 AM, Martin Galvan
wrote:
> I tested this both with and without the VFP, and in both cases I can't
> even make it to bsp_start. Even worse, Uniflash will almost fail to
Sorry, I meant to type "almost always".
anything with the FP registers
before you get to bsp_start_init_registers_vfp.
On Mon, Nov 23, 2015 at 5:50 PM, Pavel Pisa wrote:
> Hello Martin,
>
> On Monday 23 of November 2015 21:31:46 Martin Galvan wrote:
>> I'm about to test this on our setup. Just to be sure, does your
&
23 of November 2015 15:19:40 Martin Galvan wrote:
>> Hi Pavel, I'll give it a look. What issues are you having? Did you see
>> this problem on the RTEMS samples (e.g. HelloWorld, Ticker) as well?
>
> we have checked functionality with ticker and our complete LwIP application.
&
Hi everybody, I'm reviving this thread because we've found some more issues
related to the BBB bsp_interrupt_dispatch. I'm CCing Ben Gras since he may know
a bit more about this than we do.
On Thu, May 28, 2015 at 8:01 AM, Sebastian Huber wrote:
> It depends on the capabilities of the interrupt c
ave used soft-float mostly for our previous tests but
> default Flash target BSP build has been switched to hard-float
> in March by Martin Galvan.
>
> --- a/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk.cfg
> +++ b/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk
On Wed, Nov 11, 2015 at 11:49 AM, Pavel Pisa wrote:
> Hello Gedare
> I understand. TMS570 BSP has been allowed to go in a last minute
> on maintainers willingness and it is still considered a work in
> progress state. But Martin Galvan and may it be others use it
> already as a bas
Hi Joel, I'm interested in being a mentor. Let me know if I can be of any help!
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On Mon, Nov 9, 2015 at 8:30 PM, Pavel Pisa wrote:
> Hello Martin,
>> + TMS570_POM.GLBCTRL = 0 | (TMS570_POM_GLBCTRL_OTADDR(~0) &
>> +pom_global_overlay_target_address_start);
>>
>> I don't see the point of doing (0 | something).
>
> This is to highlight that register v
On Sun, Nov 8, 2015 at 11:11 AM, Pavel Pisa wrote:
> Hello Martin and others,
Hi Pavel. I'll comment on the POM and GPIO-related things, since we're
not currently using Ethernet (nor are we familiar with how the TMS
handles it).
>The complete GPIO API or at least xx_gpio_set(), xx_gpio_clear
The LPC1768 variants have a gpio.h file whose name clashes with the gpio.h from
the new GPIO API. This results on the BSPs failing to compile.
This patch renames the LPC1768 gpio.* files to lpc-gpio.*, as it's done on other
BSPs (e.g. Beaglebone).
Closes #2441.
---
c/src/lib/libbsp/arm/lpc176x/M
On Wed, Nov 4, 2015 at 7:33 PM, Pavel Pisa wrote:
> So it is important what are intended use cases.
> The one where RTEMS image starts from address 0
> is simple and should no use POM nor VIM interrupt bypassing.
> But it requires integration with HAL startup for now.
This should probably go on a
On Wed, Nov 4, 2015 at 6: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.
Yeah, I did this several times and I'm still seeing it.
__
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-rtems4.11
--enable-rtemsbsp=beagleboneblack --enable-posix --enable-cxx
--disable-networking --enable
On Wed, Oct 14, 2015 at 4:59 AM, Sebastian Huber
wrote:
> Since NET_RT_IFLIST is defined in socket.h, the else block is essentially
> dead code. How did you find this problem? Does it make sense to use the
> latest FreeBSD version?
It was one of the errors reported by CppCheck a while ago. I
orig
The 'buf' variable in the getifaddrs function may be defined either as a pointer
or as an array, depending on whether NET_RT_IFLIST is defined. However, we end
up doing a free(buf) in both cases. This patch fixes that issue.
Closes #2427.
---
cpukit/libnetworking/libc/getifaddrs.c | 20 +
ixing them, but it seems that the code enclosed inside the #if
RTEMS_REMOVED directives is obsolete.
Should I fix the compilation errors, or just remove the dead code?
--
Martin Galvan
Software Engineer
Taller Technologies Argentina
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
This patch adds a brief description of how context state is saved into the
SP on exception entry, and makes a few changes to _ARMV7M_Exception_default
in order to make it a bit more efficient. I also removed the unused 'v7mfsz'
input parameter.
This should apply over Sudarshan's patch.
---
cpukit
Hi everyone! Just checking in, was Sudarshan's patch commited?
On Mon, Aug 31, 2015 at 4:49 PM, Gedare Bloom wrote:
> Martin's ticket works, and his commit can #close it.
>
> On Mon, Aug 31, 2015 at 3:22 PM, sudarshan.rajagopalan
> wrote:
>> On 2015-08-31 13:39, Daniel Gutson wrote:
>>>
>>> On
Hi there! We were looking at the RTEMS SMP support, and wondered what
would it take for the system to support some form of memory protection
(say, an MPU). Is it possible, and if so, how hard would it be?
We also saw this:
https://devel.rtems.org/wiki/Projects/MMU_Support
What's the status of th
Thanks a lot for the detailed answer! We'll give it a try.
Btw:
On Fri, Sep 4, 2015 at 11:40 AM, Joel Sherrill
wrote:
> It can email the results if you like.
Was that an 'it' or an 'I'? If you have the output of the failed
25_algorithms/random_shuffle/moveable.cc test handy it would
definitely
Compiling dumpbuf.c causes the following warning to be issued:
warning: pointer targets in passing argument 1 of 'snprintf' differ in
signedness [-Wpointer-sign]
This happens because line_buffer is declared as unsigned.
Closes #2411.
---
cpukit/libmisc/dumpbuf/dumpbuf.c | 2 +-
1 file changed,
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't notice
it was non-standard.
Closes #2410.
---
cpukit/libnetworking/rtems/rtems_dhcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
On Thu, Sep 3, 2015 at 1:21 PM, Joel Sherrill wrote:
> One comment. Why is the output buffer now static? I know it
> moves it off the stack but what's the consensus on an 80
> byte array on a stack?
I'm not sure what the consensus is. I briefly discussed this with
Daniel and it's ok with us, but
On Thu, Sep 3, 2015 at 1:20 PM, Joel Sherrill wrote:
> Am I misreading this or did the formatting change?
>
> It looks like the indentation on the "+" lines is different
Indeed :) Now the '+' lines are executed only if new_prefix != NULL
(new_prefix being the result of malloc). The resulting code
Hi Sebastian! Thanks for your answer. There are a couple of things I
still don't get :)
On Thu, Sep 3, 2015 at 2:48 AM, Sebastian Huber
wrote:
> I updated the rtems-testing repository.
>
> 1. You have to adjust the VERSIONS file.
Is this file meant to help the scripts download the tool sources
a
Updates #2405.
---
tools/cpu/nios2/memory.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tools/cpu/nios2/memory.c b/tools/cpu/nios2/memory.c
index cd88b8b..cb1ea7f 100644
--- a/tools/cpu/nios2/memory.c
+++ b/tools/cpu/nios2/memory.c
@@ -18,7 +18,8 @@ memory_desc *find_m
Updates #2405.
---
c/src/lib/libbsp/shared/umon/umon.h | 4
cpukit/posix/include/rtems/posix/ptimer.h| 5 -
cpukit/rtems/include/rtems/rtems/dpmemimpl.h | 6 +-
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/c/src/lib/libbsp/shared/umon/umon.h
b/c/src/li
Updates #2405.
---
tools/cpu/nios2/ptf.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/tools/cpu/nios2/ptf.c b/tools/cpu/nios2/ptf.c
index 7a31c11..07d6183 100644
--- a/tools/cpu/nios2/ptf.c
+++ b/tools/cpu/nios2/ptf.c
@@ -567,17 +567,21 @@ void ptf
I also used the 'n' versions of the string functions, #define'd magic numbers
and added a few comments.
Updates #2405.
---
cpukit/libmisc/dumpbuf/dumpbuf.c | 121 ---
1 file changed, 75 insertions(+), 46 deletions(-)
diff --git a/cpukit/libmisc/dumpbuf/dumpbuf
Closes #2405.
---
cpukit/libnetworking/rtems/rtems_dhcp.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/cpukit/libnetworking/rtems/rtems_dhcp.c
b/cpukit/libnetworking/rtems/rtems_dhcp.c
index c938ee0..87be238 100644
--- a/cpukit/libnetworking/rtems/rtems_
On Wed, Sep 2, 2015 at 12:01 PM, Daniel Gutson
wrote:
>
> El 2/9/2015 11:58, "Martin Galvan"
> escribió:
>>
>> On 02/09/2015 15:00, Sebastian Huber wrote:
>> > I deleted the test tree. It will take a couple of days before I create a
>> > new one.
On 02/09/2015 15:00, Sebastian Huber wrote:
> I deleted the test tree. It will take a couple of days before I create a
> new one. I think it makes more sense if you run the tests yourself, so
> that you can debug them. I use the realview_pbx_a9_qemu BSP for this,
> since it is very easy to debug
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 that small atomic commits are better. However, the
Hi everyone!
I just ran CppCheck again on a fresh clone of the git repo and saw the
number of error reports was quite smaller than what I reported before.
That's because my previous run was on a (quite older) version; most of
those must've been fixed already.
Some of the error reports remain, tho
This patch fixes the following CppCheck errors found throughout the code:
[c/src/lib/libbsp/shared/umon/umon.h:21]: (error) Invalid number of character
({) when these macros are defined: '__cplusplus'.
[cpukit/libmisc/dumpbuf/dumpbuf.c:69]: (error) Undefined behavior: Variable
'line_buffer' is u
On Mon, Aug 31, 2015 at 2:34 PM, Gedare Bloom wrote:
> I'd approve 2 patches in case you want to give credit. First patch
> with Sudarshan's fix, and Martin's improvement second.
Agreed. Sudarshan sent his patch a couple days ago; I'll generate a
new one with the new instructions and the comments
On exception entry, _ARMV7M_Exception_default stores the previous Stack Pointer
in a CPU_Exception_frame. The SP can be MSP or PSP, depending on the mode
in which the exception was taken. To know this, we must check the value of LR.
Right now the code checks whether it should store MSP or PSP by c
By the way, I noticed there wasn't a ticket yet for this bug, so I
created one (#2401). You can view it here:
https://devel.rtems.org/ticket/2401
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On exception entry, _ARMV7M_Exception_default stores the previous Stack Pointer
in a CPU_Exception_frame. The SP can be MSP or PSP, depending on the mode
in which the exception was taken. To know this we must check the value of LR.
Right now the code checks whether it should store MSP or PSP by co
On Thu, Aug 27, 2015 at 3:53 PM, sudarshan.rajagopalan
wrote:
> The instruction "cmn r2, #3\n" in line 31 basically compares the Link
> Register(lr) to value 0xFFFD (negative #3, because CMN negates the RHS
> and compares with LHS) and chooses MSP or PSP in the following IT block.
> This is pr
On Thu, Aug 27, 2015 at 6:19 PM, Daniel Gutson
wrote:
> Please note too that there are some false positives, like the realloc one.
Actually, we ruled out most false positives. IIRC that one is an actual bug.
Btw, sorry for the Spanish comment there. It means that if we don't
initialize _ccr we j
On Thu, Aug 27, 2015 at 6:10 PM, Daniel Gutson
wrote:
> Maybe we can just provide the list until we provide the fixes? Martín?
Gladly. Keep in mind we ran cppcheck only on the modules we use
(though some things may've slipped in, like nios):
[c/src/lib/libbsp/shared/umon/umon.h:21]: (error) Inva
Oh, and one more thing: before commiting, please fix a typo
('prescaller' should be 'prescaler') and the const issue Daniel
pointed out :)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On Wed, Jul 15, 2015 at 3:33 PM, Pavel Pisa wrote:
> Hello Martin,
> Try to help us when we try to do TMS570 RTEMS work based
> on my belief that it worth to be done for RTEMS but
> without any actual or directly foreseen project/funding
> backup. Try the code it would ease and shorten this
> dis
On Wed, Jul 15, 2015 at 12:22 PM, Pavel Pisa wrote:
> Patch provides way to the previous working state at least.
> I would suggest to apply this patch because current mainline is broken
> in actual state - time read goes totally unrelated to the delay functions.
Could you elaborate a bit more on
On Wed, Jul 15, 2015 at 11:41 AM, Pavel Pisa wrote:
> the code has been tested for internal RAM now.
> We have more cleanups in the mind but headers are critical
> for now. Premek is working on that, time for feedback
> form previous e-mail passed without input so he plans
> to send prepared chang
Hello Premysl! Thanks for this patch.
Could you tell us why is this patch needed, and where does the new
formula come from? From what I saw, HALCoGen generates a macro called
RTI_FREQ which has the value from the previous version of the formula
(i.e. if BSP_PLL_OUT_CLOCK == 180 MHz, RTI_FREQ == 90
USB1HostIntHandler function? What does it do?
>
> -Gedare
>
> On Fri, Jul 10, 2015 at 5:33 PM, Martin Galvan
> wrote:
>> Hi everyone! I'm currently trying to use an interrupt server task for
>> handling USB interrupts on the Beaglebone Black. Here's the co
Hi everyone! I'm currently trying to use an interrupt server task for
handling USB interrupts on the Beaglebone Black. Here's the code I'm
using:
rtems_interrupt_server_initialize(1, 1500, RTEMS_TIMESLICE | RTEMS_PREEMPT,
RTEMS_DEFAULT_ATTRIBUTES, NULL);
rtems_interrupt_server_handler_install
printk for debugging purposes.
Right now what happens is that the printk thread runs about 10-15
times and then the system hangs in the middle of the print. Am I doing
something wrong?
Thanks a lot!
--
Martin Galvan
Software Engineer
Taller Technologies Argentina
San Lorenzo 47, 3rd Floor
My mistake: the application is meant to use JFFS2 instead of FAT32.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
, and where
should I place the USB stack primitives. Any concrete examples (other
than testsuites/samples/fileio, which doesn't use flash disks) would
be more than welcome.
I've already read the RTEMS wiki, the filesystem design guide and the
comments in flashdisk.h, and still didn
On Wed, Jun 17, 2015 at 9:49 AM, Sebastian Huber
wrote:
>>
>> Is there an easy way to port these to RTEMS? I'm not sure how much the
>> BSD driver infrastructure has changed since 8.2.
> It is actually FreeBSD 9.3, but I don't know how the USB stack evolved.
Is the USB stack also 9.3? I seem to r
ew=markup
http://svnweb.freebsd.org/base/head/sys/arm/ti/am335x/am335x_musb.c?revision=283276&view=markup
Is there an easy way to port these to RTEMS? I'm not sure how much the
BSD driver infrastructure has changed since 8.2.
On Wed, Jun 17, 2015 at 8:07 AM, Sebastian Huber
wrote:
>
>
> On 16/
Sebastian Huber wrote:
> Which USB and MMC/SD card hardware modules has this chip? Are they standard
> modules, e.g. EHCI, SDHC or something like this?
>From what I saw, the USB module on the Beaglebone Black is built
around the Mentor musbmhdrc USB OTG controller, which is not EHCI or
OHCI com
On Fri, Jun 5, 2015 at 1:18 PM, Gedare Bloom wrote:
> I'll be curious to see what tms570 users think of the generated headers.
We've been quite busy lately, but I'll take a look as soon as I can.
--
Martin Galvan
Software Engineer
Taller Technologies Argentina
San Lor
1 - 100 of 132 matches
Mail list logo
