[PING][PATCH] LPC176x: Add CAN, PWM, ADC and UART1/2/3 support to the BSP.

This patch adds support for the following devices to the LPC176x BSP: * CAN * PWM * ADC It also adds the probe routines for UART1/2/3 to the console_device_table in console-config.c, and enables UART1 in configure.ac. --- c/src/lib/libbsp/arm/lpc176x/Makefile.am | 16 + c/src/lib/lib

[PATCH] TMS570: Add board reset code to bsp_reset

- * Czech Technical University in Prague - * Zikova 1903/4 - * 166 36 Praha 6 - * Czech Republic - * - * Based on LPC24xx and LPC1768 BSP + * @author Martin Galvan * * The license and distribution terms for this file may be * found in the file LICENSE in this distribution or at @@ -25,4 +19,13

[PATCH] TMS570: Enable FPU in makefile.

--- c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk.cfg b/c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk.cfg index e90414a..869cf71 100644 --- a/c/sr

Re: [PATCH] TMS570: Enable FPU in makefile.

gisters, which is needed by the TMS570's CCM. > > On Thursday 26 of March 2015 21:21:26 Martin Galvan wrote: >> --- >> c/src/lib/libbsp/arm/tms570/make/custom/tms570ls3137_hdk.cfg | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/

Re: [PATCH] TMS570: Add board reset code to bsp_reset

On Thu, Mar 26, 2015 at 10:08 PM, Gedare Bloom wrote: > On Thu, Mar 26, 2015 at 5:07 PM, Daniel Gutson > wrote: >> On Thu, Mar 26, 2015 at 5:16 PM, Martin Galvan >> wrote: >>> --- >>> c/src/lib/libbsp/arm/tms570/include/tms570.h | 19 +++-- >

[PATCH v2] Change the assert in _Thread_Dispatch_decrement_disable_level

While cpu_self->thread_dispatch_disable_level shouldn't ever be zero, it would be better to check it before doing the decrement. --- cpukit/score/src/threaddispatchdisablelevel.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/cpukit/score/src/threaddispatchdisablelevel.c

Re: TMS570 BSP: RTEMS license compatible TMS570LS3137 header files progress

On Wed, Apr 1, 2015 at 8:01 AM, Pavel Pisa wrote: > To Martin Galvan: What is your opinion? Would you join the work in > this direction? So if I understood correctly, what you did was converting the datasheet PDF to some parseable format, then you parsed that file to extract the registe

Re: TMS570 BSP: RTEMS license compatible TMS570LS3137 header files progress

On Wed, Apr 1, 2015 at 7:35 PM, Pavel Pisa wrote: > Hello Martin, Hi, sorry for the late answer. > On Wednesday 01 of April 2015 21:08:19 Martin Galvan wrote: >> On Wed, Apr 1, 2015 at 8:01 AM, Pavel Pisa wrote: >> > To Martin Galvan: What is your opinion? Would you join

[PING][PATCH v2] Change the assert in _Thread_Dispatch_decrement_disable_level

While cpu_self->thread_dispatch_disable_level shouldn't ever be zero, it would be better to check it before doing the decrement. Changes in v2: * Modified the asserts as requested in https://lists.rtems.org/pipermail/devel/2015-February/009821.html. --- cpukit/score/src/threaddispatchdisablele

Re: [PING][PATCH v2] Change the assert in _Thread_Dispatch_decrement_disable_level

Thanks a lot! On Fri, Apr 17, 2015 at 7:18 AM, Sebastian Huber wrote: > I checked in a slightly modified version. > > > On 16/04/15 16:27, Martin Galvan wrote: >> >> While cpu_self->thread_dispatch_disable_level shouldn't ever be zero, it >> would be better

Re: TMS570 headers ready for review

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

Re: USB Host and MMC/SD Card Stack

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

Re: USB Host and MMC/SD Card Stack

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/

Re: USB Host and MMC/SD Card Stack

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

FAT32 filesystem on an USB flash drive

, 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

Re: FAT32 filesystem on an USB flash drive

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

Interrupt server on BBB

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

Interrupt server on BBB

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

Re: Interrupt server on BBB

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

Re: [PATCH] bsp/tms570: fix get time resolution after infrastructure change to timecounter.

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

Re: [PATCH] bsp/tms570: fix get time resolution after infrastructure change to timecounter.

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

Re: [PATCH] bsp/tms570: fix get time resolution after infrastructure change to timecounter.

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

Re: [PATCH] bsp/tms570: fix get time resolution after infrastructure change to timecounter.

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

Re: [PATCH] bsp/tms570: fix get time resolution after infrastructure change to timecounter.

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

Re: cppcheck errors

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

Re: cppcheck errors

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

Re: [PATCH] Fix exception handler for supporting FPU

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

[PATCH v2] ARMv7M: Fix exception handler for supporting FPU

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

Re: [PATCH v2] ARMv7M: Fix exception handler for supporting FPU

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

[PATCH v3] ARMv7M: Fix exception handler for supporting FPU

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

Re: [PATCH v3] ARMv7M: Fix exception handler for supporting FPU

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

[PATCH] Fix CppCheck errors

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

Re: cppcheck errors

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

Re: [PATCH] Fix CppCheck errors

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

Re: [PATCH] [RTEMS] Update RTEMS thread model

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

Re: [PATCH] [RTEMS] Update RTEMS thread model

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.

[PATCH v2 5/5] cpukit/libnetworking/rtems/rtems_dhcp.c: Fix leak on realloc failure for dhcp_hostname.

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_

[PATCH v2 1/5] various .h files: Add missing C++ extern wrappers

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

[PATCH v2 3/5] tools/cpu/nios2/ptf.c: Fix leak of memory pointed to by new_prefix

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

[PATCH v2 2/5] tools/cpu/nios2/memory.c: Fix uninitialized use of variable memory

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

[PATCH v2 4/5] cpukit/libmisc/dumpbuf/dumpbuf.c: Fix undefined behavior for sprintf()

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

Re: [PATCH] [RTEMS] Update RTEMS thread model

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

Re: [PATCH v2 3/5] tools/cpu/nios2/ptf.c: Fix leak of memory pointed to by new_prefix

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

Re: [PATCH v2 4/5] cpukit/libmisc/dumpbuf/dumpbuf.c: Fix undefined behavior for sprintf()

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

[PATCH] cpukit/libnetworking/rtems/rtems_dhcp.c: Fix compilation error

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 --

[PATCH] cpukit/libmisc/dumpbuf/dumpbuf.c: Fix compilation warnings

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,

Re: [PATCH] [RTEMS] Update RTEMS thread model

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

Memory protection on RTEMS?

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

Re: [PATCH v3] ARMv7M: Fix exception handler for supporting FPU

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

[PATCH v4] ARMv7M: Improve exception handler routine and add comments on SP selection

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

What's the purpose of RTEMS_REMOVED?

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

[PATCH] cpukit/libnetworking/libc/getifaddrs.c: Fix undefined behavior on freeing auto variable if NET_RT_IFLIST isn't defined.

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 +

Re: [PATCH] cpukit/libnetworking/libc/getifaddrs.c: Fix undefined behavior on freeing auto variable if NET_RT_IFLIST isn't defined.

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

Trouble building RTEMS from master

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

Re: Trouble building RTEMS from master

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. __

Re: Trouble building RTEMS from master (TMS570 and LPC1768)

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

[PATCH] LPC1768: Fix compilation error

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

Re: TMS570 BSP updates and LwIP support

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

Re: TMS570 BSP updates and LwIP support

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

Mentors Wanted for Google Code In (High School Students)

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

Re: TMS570 BSP updates and LwIP support

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

Re: TMS570 BSP testing and problem with VFP enabled build

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

Beaglebone Black interrupt dispatch (was: Porting ethernet driver from FREEBSD to rtems-libbsd)

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

Re: TMS570 BSP testing and problem with VFP enabled build

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. &

Re: TMS570 BSP testing and problem with VFP enabled build

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 &

Re: TMS570 BSP testing and problem with VFP enabled build

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".

Concurrency in JFFS2?

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

Re: Concurrency in JFFS2?

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

Re: Concurrency in JFFS2?

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

libfs: are we actually using User/Group IDs?

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

Re: libfs: are we actually using User/Group IDs?

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

[PATCH] Beaglebone Black: Fix rtems_gpio_bsp_disable_interrupt disabling all the GPIO interrupts

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

Ticker interrupt priority

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

Re: Ticker interrupt priority

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

Re: Ticker interrupt priority

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

Re: [PATCH v3] score: Fix simple timecounter support

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.

RTEMS_DECONST - Should it be removed?

Hi everyone! We're currently working on improving the TMS570 BSP, and in the process we discovered an important bug caused by a misuse of the RTEMS_DECONST macro. Said macro seems to be used in a few other places throughout the code to bypass const restrictions. What's the purpose of having someth

Re: RTEMS_DECONST - Should it be removed? - TMS570

Sorry for the late answer. On Wed, Jan 14, 2015 at 6:50 PM, Pavel Pisa wrote: > Hello Martin, > > On Wednesday 14 of January 2015 18:27:41 Martin Galvan wrote: >> Hi everyone! We're currently working on improving the TMS570 BSP, and >> in the process we discovered an

Re: RTEMS_DECONST - Should it be removed? - TMS570

One more thing: you may notice we have two forms of the prescaler formula. The one that's commented out is the (incorrect) one that HALCogen generates; using that one gives us a prescaler of 48 while using the (supposedly correct) one yields 47. The bug we're currently facing seems to happen more o

Re: RTEMS_DECONST - Should it be removed? - TMS570

Also regarding the bug we're working on: sprintf seems to be working fine, so the problem may be related to dynamic memory allocation being done somewhere inside printf. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS_DECONST - Should it be removed? - TMS570

Thanks a lot for your answer. On Wed, Jan 21, 2015 at 4:27 PM, Gedare Bloom wrote: > Martin, > > printf can be quite sensitive to register problems. You should isolate > the bug e.g. by modifying hello world which does not have ISRs to do > printf of a 2-digit int. If printf works there, the prob

Re: RTEMS_DECONST - Should it be removed? - TMS570

On Wed, Jan 21, 2015 at 5:35 PM, Pavel Pisa wrote: > On Wednesday 21 of January 2015 19:44:21 Martin Galvan wrote: >> What happened was that, in the SCI driver, driver_context_table was >> declared as const and it included a variable called tx_chars_in_hw which is >> used by

[PATCH] Change the assert in _Thread_Dispatch_decrement_disable_level

While cpu_self->thread_dispatch_disable_level shouldn't ever be zero, it would be better to check it before doing the decrement. diff --git a/cpukit/score/src/threaddispatchdisablelevel.c b/cpukit/score/src/threaddispatchdisablelevel.c index 3b7837c..ce33db9 100644 --- a/cpukit/score/src/threaddis

Re: [PATCH] arm/tms570: sci context has to be writable because it holds state variable.

n code breaks when RTEMS > is build for Flash area. > > The problem found and analyzed by Martin Galvan from tallertechnologies. Thanks for the patch. In addition, we've developed a refactored version of the driver which, besides being const-correct, addresses a number of other issu

Re: [PATCH] arm/tms570: sci context has to be writable because it holds state variable.

On Wed, Feb 4, 2015 at 3:49 PM, Martin Galvan wrote: > On Wed, Feb 4, 2015 at 2:20 PM, Pavel Pisa wrote: >> The structure tms570_sci_context holds state variable >> tx_chars_in_hw which holds if and how many characters >> (in the optional FIFO support for some Ti SCIs)

[PATCH] ARM: Support VFP-D16

igned-off by: Martin Galvan --- diff --git a/c/src/lib/libbsp/arm/shared/start/start.S b/c/src/lib/libbsp/arm/shared/start/start.S index ff970e1..4341e27 100644 --- a/c/src/lib/libbsp/arm/shared/start/start.S +++ b/c/src/lib/libbsp/arm/shared/start/start.S @@ -187,7 +187,7 @@ _start: /* Stay i

BSP-specific init code in arm/shared/start.S?

Hello everybody! As some of you may already know, we're working on the TMS570 BSP. According to the board's datasheet we need to initialize the CPU's registers at startup: "The TMS570LS series of microcontrollers include dual Cortex-R4F CPUs running in a lock-step operation mode. A Core Compare Mo

Re: BSP-specific init code in arm/shared/start.S?

On Sun, Feb 22, 2015 at 3:38 PM, Sebastian Huber wrote: > The start.S already has a #include . So I would add a BSP option > to define something like BSP_START_DO_LOCKSTEP_INITIALIZATION and use it in > start.S. Thanks for your answer, we'll look into this. >> >> Additionally, when the CCM detec

[PATCH] ARM: Add BSP_NEEDS_REGISTER_INITIALIZATION

** + * @file bsp-init-registers.S + * + * @brief CPU register initialization routines for the TMS570. + */ + +/* + * Copyright (c) 2015 Taller Technologies. All rights reserved. + * + * @author Martin Galvan + * + * The license and distribution terms for this file may be + * found in the file

[PATCH] ARM: Prevent _ARMV4_Exception_fiq_default from re-enabling FIQs.

Follow-up from here: https://lists.rtems.org/pipermail/devel/2015-February/009974.html When talking to Sebastian Huber about the behavior of _ARMV4_Exception_fiq_default, he mentioned that it shouldn't re-enable FIQs again. This patch sets the F bit of the SPSR so that when it gets loaded back

Re: [PATCH] ARM: Add BSP_NEEDS_REGISTER_INITIALIZATION

ferent places, e.g. > hypervisor mode etc. Will do. Thanks for the feedback! > > On 25/02/15 15:52, Martin Galvan wrote: >> >> Follow-up from here: >> >> https://lists.rtems.org/pipermail/devel/2015-February/009974.html >> >> This patch adds the macr

Re: [PATCH] ARM: Prevent _ARMV4_Exception_fiq_default from re-enabling FIQs.

Patch attached. On Thu, Feb 26, 2015 at 5:26 AM, Sebastian Huber wrote: > Looks good, can you please send a patch. > > > On 25/02/15 20:57, Martin Galvan wrote: >> >> Follow-up from here: >> >> https://lists.rtems.org/pipermail/devel/2015-February/009974.

[PATCH v2] ARM: Add BSP_START_NEEDS_REGISTER_INITIALIZATION

rved. + * + * @author Martin Galvan + * + * The license and distribution terms for this file may be + * found in the file LICENSE in this distribution or at + * http://www.rtems.org/license/LICENSE. + */ + +/* + * These routines perform the initialization of the CPU registers of the TMS570. + * This

Re: [PATCH v2] ARM: Add BSP_START_NEEDS_REGISTER_INITIALIZATION

ile, though, if only to keep start.S as short and clean as possible. > You don't have to save and restore the r0 in a function since its a volatile > register. > > On 26/02/15 15:38, Martin Galvan wrote: >> >> Changes from v1: >> * Add bsp_start_* prefix

Re: [PATCH v2] ARM: Add BSP_START_NEEDS_REGISTER_INITIALIZATION

On Thu, Feb 26, 2015 at 12:03 PM, Sebastian Huber wrote: > On 26/02/15 15:54, Martin Galvan wrote: >> >> On Thu, Feb 26, 2015 at 11:47 AM, Sebastian Huber >> wrote: >>> >>> >Hello Martin, >>> > >>> >sorry, I should have look

[PATCH] ARM: Prevent _ARMV4_Exception_fiq_default from re-enabling FIQs.

In _ARMV4_Exception_fiq_default, set the F bit of the SPSR so that when it gets loaded back to the CPSR in save_more_context it won't re-enable the FIQs. Tested on a TMS570LS3137. --- cpukit/score/cpu/arm/armv4-exception-default.S | 8 1 file changed, 8 insertions(+) diff --git a/cpuki

[PATCH v3] ARM: Add BSP_START_NEEDS_REGISTER_INITIALIZATION

08ce --- /dev/null +++ b/c/src/lib/libbsp/arm/shared/startup/bsp-start-init-registers.S @@ -0,0 +1,105 @@ +/** + * @file bsp-start-init-registers.S + * + * @brief ARM register initialization routines. + */ + +/* + * Copyright (c) 2015 Taller Technologies. All rights reserved. + * + * @author

[PATCH] Add CAN, PWM, ADC and UART1/2/3 support to the LPC176x BSP.

This patch adds support for the following devices to the LPC176x BSP: * CAN * PWM * ADC It also adds the probe routines for UART1/2/3 to the console_device_table in console-config.c, and enables UART1 in configure.ac. --- c/src/lib/libbsp/arm/lpc176x/Makefile.am | 16 + c/src/lib/lib

[PATCH] Beaglebone: Fix the IRQ handling code

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

Re: [PATCH] Beaglebone: Fix the IRQ handling code

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

  1   2   >