Re: [PATCH 7/7] score: Hide SMP lock profiling impl if disabled

[Sebastian Huber]

On 26/06/15 01:45, Chris Johns wrote:

On 25/06/2015 11:17 pm, Sebastian Huber wrote:

The problem is that empty structures have a different size in C and C++.
---
  cpukit/score/include/rtems/score/percpu.h  |  17 ++-
  cpukit/score/include/rtems/score/smplock.h | 167 +
  cpukit/score/src/profilingsmplock.c|  18 ++--
  cpukit/score/src/smp.c |   5 +-
  4 files changed, 127 insertions(+), 80 deletions(-)

diff --git a/cpukit/score/include/rtems/score/percpu.h 
b/cpukit/score/include/rtems/score/percpu.h
index a6f7a25..088c31f 100644
--- a/cpukit/score/include/rtems/score/percpu.h
+++ b/cpukit/score/include/rtems/score/percpu.h
@@ -319,10 +319,17 @@ typedef struct Per_CPU_Control {
   */
  SMP_ticket_lock_Control Lock;
  
-/**

- * @brief Lock statistics context for the per-CPU lock.
- */
-SMP_lock_Stats_context Lock_stats_context;
+#if defined( RTEMS_PROFILING )
+  /**
+   * @brief Lock statistics for the per-CPU lock.
+   */
+  SMP_lock_Stats Lock_stats;
+
+  /**
+   * @brief Lock statistics context for the per-CPU lock.
+   */
+  SMP_lock_Stats_context Lock_stats_context;
+#endif
  

My only comment is the ability to get any SMP status is difficult. It is
either all on or you get nothing. Moving all stats related defines
inside #ifdefs and into the global RTEMS_PROFILING define make this
harder to do. This is not specifically addressing this lock stats change
but on a more general level and this change reminded me.


This patch changes nothing in terms of functionality.  It just avoids 
zero size structures which unfortunately are implementation-defined in C 
(size is zero with GCC) and C++ (size must be non-zero and is 1 in GCC).




I looked into adding some SMP stats to top not long ago I found there
was nothing I report on unless profiling was on and if I turned on
profiling I got too much such as timing and other nice features.

I could not see how to show how many context switches each core had, how
many interrupts each core serviced.


We can enable such things individually.



I understand the desire to push the limits and not waste a single cycle
if we can help it but I actually found it difficult to know if I had SMP
built correctly and if it was working from a shell command line. I feel
we need some standard stats users can depend on that help us know things
are basically working.

Chris


Is this not something that can be done with the linker based tracing?

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

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

Re: [PATCH 7/7] score: Hide SMP lock profiling impl if disabled

[Chris Johns]

On 26/06/2015 5:01 pm, Sebastian Huber wrote:
> 
> 
> On 26/06/15 01:45, Chris Johns wrote:
>> On 25/06/2015 11:17 pm, Sebastian Huber wrote:
>>> The problem is that empty structures have a different size in C and C++.
>>> ---
>>>   cpukit/score/include/rtems/score/percpu.h  |  17 ++-
>>>   cpukit/score/include/rtems/score/smplock.h | 167
>>> +
>>>   cpukit/score/src/profilingsmplock.c|  18 ++--
>>>   cpukit/score/src/smp.c |   5 +-
>>>   4 files changed, 127 insertions(+), 80 deletions(-)
>>>
>>> diff --git a/cpukit/score/include/rtems/score/percpu.h
>>> b/cpukit/score/include/rtems/score/percpu.h
>>> index a6f7a25..088c31f 100644
>>> --- a/cpukit/score/include/rtems/score/percpu.h
>>> +++ b/cpukit/score/include/rtems/score/percpu.h
>>> @@ -319,10 +319,17 @@ typedef struct Per_CPU_Control {
>>>*/
>>>   SMP_ticket_lock_Control Lock;
>>>   -/**
>>> - * @brief Lock statistics context for the per-CPU lock.
>>> - */
>>> -SMP_lock_Stats_context Lock_stats_context;
>>> +#if defined( RTEMS_PROFILING )
>>> +  /**
>>> +   * @brief Lock statistics for the per-CPU lock.
>>> +   */
>>> +  SMP_lock_Stats Lock_stats;
>>> +
>>> +  /**
>>> +   * @brief Lock statistics context for the per-CPU lock.
>>> +   */
>>> +  SMP_lock_Stats_context Lock_stats_context;
>>> +#endif
>>>   
>> My only comment is the ability to get any SMP status is difficult. It is
>> either all on or you get nothing. Moving all stats related defines
>> inside #ifdefs and into the global RTEMS_PROFILING define make this
>> harder to do. This is not specifically addressing this lock stats change
>> but on a more general level and this change reminded me.
> 
> This patch changes nothing in terms of functionality.  It just avoids
> zero size structures which unfortunately are implementation-defined in C
> (size is zero with GCC) and C++ (size must be non-zero and is 1 in GCC).

I understand the purpose of the patch and it is fine.

> 
>>
>> I looked into adding some SMP stats to top not long ago I found there
>> was nothing I report on unless profiling was on and if I turned on
>> profiling I got too much such as timing and other nice features.
>>
>> I could not see how to show how many context switches each core had, how
>> many interrupts each core serviced.
> 
> We can enable such things individually.
> 

Then may I suggest we default them to always so code that references
these values can avoid the condition compile options to get at them.

>>
>> I understand the desire to push the limits and not waste a single cycle
>> if we can help it but I actually found it difficult to know if I had SMP
>> built correctly and if it was working from a shell command line. I feel
>> we need some standard stats users can depend on that help us know things
>> are basically working.
>>
>> Chris
> 
> Is this not something that can be done with the linker based tracing?
> 

It is about working production system with an issue. Being able to run
top and see things are happy is a real bonus.

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

Re: configuring libbsd for em NIC driver

[Sebastian Huber]

The currently supported platforms of libbsd Ethernet are:

o Altera Cyclone V
o Xilinx Zynq
o Freescale P1020
o Freescale MCF548x

Everything else needs some extra work. Depending on your prior knowledge 
of the system this is more or less time consuming.


On 26/06/15 01:42, Wu, Mark H. wrote:

I've been trying to follow this direction and get it working, but I've run into 
a few hurdles.

I've added a line into rtemsbsd/include/bsp/nexus-devices.h to include a line:

SYSINIT_DRIVER_REFERENCE(em, pci);

I'm not sure if this is the complete solution, since I haven't actually added 
the PCI bus as a child device to the nexus device. I'm also not sure if this 
should be included here, since not all pc386 devices will have an em device. A 
little clarification on this would be appreciated. Maybe I should just include 
that line in my application code (where I configure RTEMS)?

Trying to rebuild the library using waf returned a lot of errors.

The first set of errors was due to the fact that the e1000_i210.c file wasn't in the 
freebsd directory (but it was in the freebsd-org directory). So I moved it over, 
added the #include  line that was common to 
all of the other files in the directory. I then added the file to wscript (where all 
of the other e1000 files were) to get it to compile.

The next set of errors are undefined references to 'inl' and 'outl.' I'm not 
sure what to do about these. I see the functions declared in machine/cpufunc.h 
(in the freebsd directory), but I don't see any definitions of them anywhere. 
(There are inlined versions of them in machine/cpufunc.h, but it doesn't appear 
to be usinf those because of a #if.) I'm not sure where those functions are 
supposed to be defined, so I'm a bit stuck. I'm wondering if that's the reason 
that the e1000_i210.c file wasn't originally included?

Any help would be appreciated.

Mark.



-Original Message-
From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
Sent: Wednesday, June 24, 2015 21:39
To: Joel Sherrill
Cc: devel@rtems.org; Wu, Mark H.
Subject: Re: configuring libbsd for em NIC driver


- Joel Sherrill  schrieb:

Hi

As I posted, I have the pc386 up to the point where I can
run the non-network tests with one intermittent failure.

I am pretty sure Mark wants the em driver found in
freebsd/sys/dev/e1000/ (em driver).

FWIW it looks like qemu simulates a handful of useful
NICs. I would like to also be able to exercise them.

qemu: Supported NIC models: 
ne2k_pci,i82551,i82557b,i82559er,rtl8139,e1000,pcnet,virtio

This covers the em, fxp, rtl, and AMD PCNET Lance. That's
would cover a lot of the PC territory.

So how does one configure this in the stack? And bring
it up enough to see that the NIC is found.

You have to add a "pci" child device to the "nexus" device and make sure that 
the desired driver is referenced.  See also

rtemsbsd/include/bsp/nexus-devices.h



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

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

Re: [PATCH 7/7] score: Hide SMP lock profiling impl if disabled

[Sebastian Huber]

On 26/06/15 09:07, Chris Johns wrote:

>

>>
>>I looked into adding some SMP stats to top not long ago I found there
>>was nothing I report on unless profiling was on and if I turned on
>>profiling I got too much such as timing and other nice features.
>>
>>I could not see how to show how many context switches each core had, how
>>many interrupts each core serviced.

>
>We can enable such things individually.
>

Then may I suggest we default them to always so code that references
these values can avoid the condition compile options to get at them.



There is no conditional stuff in the user API . You 
just get zero values or nothing at all.


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

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

Re: PowerPC gwlcfm and mpc5566evb build failure

[Sebastian Huber]

On 16/12/14 10:39, Sebastian Huber wrote:


On 15/12/14 19:33, Joel Sherrill wrote:

Both fail with this.

powerpc-rtems4.11-gcc --pipe -B../../../../.././lib/
-B../../../../.././gwlcfm/lib/  -specs bsp_specs -qrtems
-DPACKAGE_NAME=\"rtems-c-src-lib-libcpu-powerpc\"
-DPACKAGE_TARNAME=\"rtems-c-src-lib-libcpu-powerpc\"
-DPACKAGE_VERSION=\"4.10.99.0\"
-DPACKAGE_STRING=\"rtems-c-src-lib-libcpu-powerpc\ 4.10.99.0\"
-DPACKAGE_BUGREPORT=\"https://devel.rtems.org/newticket\";
-DPACKAGE_URL=\"\" -I.
-I../../../../../../../rtems/c/src/lib/libcpu/powerpc  -isystem
../../../../.././gwlcfm/lib/include   -mcpu=8540 -meabi -msdata=sysv
-fno-common -msoft-float -mno-spe -D__ppc_generic -mstrict-align -O2 -g
-fno-keep-inline-functions -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT
mpc55xx/fec/fec.o -MD -MP -MF $depbase.Tpo -c -o mpc55xx/fec/fec.o
../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc55xx/fec/fec.c 
&&\

mv -f $depbase.Tpo $depbase.Po
In file included from
../../../../../../../rtems/c/src/lib/libcpu/powerpc/mpc55xx/irq/irq.c:23:0: 


../../../../.././gwlcfm/lib/include/mpc55xx/regs.h:83:4: error: #error
"unsupported chip type"
#error "unsupported chip type"


This is some mysterious feature of our build system.  If you configure 
it a second time, then it works.  I noticed this only for this BSP and 
I have absolutely no idea why it is so.




I fixed this eventually:

https://git.rtems.org/rtems/commit/?id=32005a72844f2090f269f6e327c65934905f273e

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

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

Jan Dolezal bachelor thesis available - RTEMS VESA BIOS graphics on Current PC Graphics Cards

[Pavel Pisa]

Hello everybody,

I would like to inform that full text of the bachelor
thesis

Drivers and Libraries Enabling RTEMS OS GUI on Current PC Graphics Cards

has been defended and is available online

https://dspace.cvut.cz/handle/10467/61467

https://dspace.cvut.cz/bitstream/handle/10467/61467/F3-BP-2015-Dolezal-Jan-Drivers-and-Libraries-Enabling-RTEMS-OS-GUI-on-Current-PC-Graphics-Cards.pdf

It provides some generic overview and the documents
actual implementation.

The VESA BIOS based support is chosen to be a default graphic option
for x86 based systems for upcoming RTEMS 4.11 release. Long story short

pc386 family (pc386 .. pc686) VESA BIOS Extension (VBE) based frame buffer 
configuration selected by default

the switch to graphic mode is controlled by multiboot option 
--video=auto|off|1024x768-32 etc.
application can override default none by exporting variable const char * 
const rtems_fb_default_mode="auto"; 

Possible followup tasks:

  - provide RTEMS text console/kernel messages output to framebuffer
in graphic mode - can be based on Qiao Yang character output for RPi console
  
https://github.com/yangqiao/rtems/blob/framebuffer/c/src/lib/libbsp/arm/raspberrypi/console/outch.c
  - use some x86 instructions emulator/executor to allow use PCI/PCIe
VBE equipped graphic cards on non-x86 systems

It would worth to add link to thesis to the list of RTEMS references,
but there is a problem/question where. The complete list of all
references maintained on original Wiki is now moved to the section TBR

  https://devel.rtems.org/wiki/TBR/Website/RTEMSReferences

Best wishes,

 Pavel


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

Re: Results

[Gedare Bloom]

Since this thread got migrated to devel a bit prematurely, I'll
back-stop some of the details and how I understand the state of this
project.

Saurabh is working toward solving https://devel.rtems.org/ticket/2124
(so yes there is a ticket already, and it  should be referenced by
patches accordingly). As a first step he has proposed a modified way
to step-down inherited priorities when multiple mutexes are acquired
simultaneously by one thread and contended by others, i.e. nested
mutex access. We wanted assurance the proposal is sound, so we had him
implement a model of the current thread synchronization of RTEMS
within a Java-based model-checking framework, called Java Path Finder,
or JPF. His model shows the existing error with the current
STRICT_ORDER option, and then does not show a problem using his
proposed method for solving nested mutex acquisition.

However, validating the proposed method apparently required adding a
global lock around the two linked lists that are used in Saurabh's
proposed solution. My intuition is that the global lock to protect
these lists is not a big problem for uniprocessor, and for SMP we
should prefer to find other solutions at any rate. The lists should
not be long, and we should be able to find their bounds. One list is
bounded by the number of mutexes a thread may hold, and the other by
the number of threads that may contend a specific mutex.

Saurabh et al, please correct me if I got the above wrong!
-Gedare

On Fri, Jun 26, 2015 at 2:33 AM, Sebastian Huber
 wrote:
>
>
> On 26/06/15 02:33, Saurabh Gadia wrote:
>>
>> @joel: It essentially means finding out the highest priority thread (or
>> ceiling) of any remaining mutex held, right?
>> If you are talking this in context of nested mutex problem --->
>> We never go and find the highest priority thread waiting on held mutex.
>> Inversely highest priority thread will recursively make changes to top of
>> stack of held mutexes by the holder. We don't search.
>>
>> Thanks,
>>
>> Saurabh Gadia
>>
>> On Thu, Jun 25, 2015 at 5:27 PM, Joel Sherrill > > wrote:
>>
>>
>>
>> On June 25, 2015 7:23:06 PM CDT, Cyrille Artho
>> mailto:cyrille.ar...@gmail.com>> wrote:
>>
> [...]
>>
>>
>> >(2) Is a fix using a global lock acceptable? Correctness-wise
>> it's the
>> >safest thing, but of course performance-wise it's a bottleneck.
>>
> [...]
>
> If you use the global lock for the uncontested mutex case, then this is not
> acceptable. If you use a global lock once you must block, then it might be
> acceptable, but this solution is not scalable. I am not sure what you are
> actually working on, it would be nice to discuss and present more on this
> mailing list. Maybe even open a ticket, e.g. something similar to
> https://devel.rtems.org/ticket/2271. This way it is possible to relate
> commits to a general concept discussion.
>
> For SMP there is a ready to use locking protocol capable to replace the
> priority inheritance mutexes:
>
> @inproceedings{OMIP,
>   author="Brandenburg, Björn B.",
>   title="A Fully Preemptive Multiprocessor Semaphore Protocol for
> Latency-Sensitive Real-Time Applications",
>   booktitle="Proceedings of the 25th Euromicro Conference on Real-Time
> Systems (ECRTS 2013)",
>   pages="292-302",
>   year="2013",
>   url="http://www.mpi-sws.org/~bbb/papers/pdf/ecrts13b.pdf";,
> }
>
> Implementing support for nested resources is very complex if you don't
> simplify like it was done for the current priority inheritance protocol in
> RTEMS. If you want it more general, then you have to pay for this in terms
> of additional memory space and time. The big issue is that you have to merge
> and split dependency trees. A tree merge can be done in O(log(n)) with a
> binomial heap, but the split operation will be probably not better than
> O(n). On SMP with partitioned/clustered scheduling you have to keep in mind
> that priority values of different partitions are not comparable.
>
> --
> 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.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Jan Dolezal bachelor thesis available - RTEMS VESA BIOS graphics on Current PC Graphics Cards

[Gedare Bloom]

Congrats Jan, great work!
Gedare

On Fri, Jun 26, 2015 at 8:45 AM, Pavel Pisa  wrote:
> Hello everybody,
>
> I would like to inform that full text of the bachelor
> thesis
>
> Drivers and Libraries Enabling RTEMS OS GUI on Current PC Graphics Cards
>
> has been defended and is available online
>
> https://dspace.cvut.cz/handle/10467/61467
>
> https://dspace.cvut.cz/bitstream/handle/10467/61467/F3-BP-2015-Dolezal-Jan-Drivers-and-Libraries-Enabling-RTEMS-OS-GUI-on-Current-PC-Graphics-Cards.pdf
>
> It provides some generic overview and the documents
> actual implementation.
>
> The VESA BIOS based support is chosen to be a default graphic option
> for x86 based systems for upcoming RTEMS 4.11 release. Long story short
>
> pc386 family (pc386 .. pc686) VESA BIOS Extension (VBE) based frame buffer 
> configuration selected by default
>
> the switch to graphic mode is controlled by multiboot option 
> --video=auto|off|1024x768-32 etc.
> application can override default none by exporting variable const char * 
> const rtems_fb_default_mode="auto";
>
> Possible followup tasks:
>
>   - provide RTEMS text console/kernel messages output to framebuffer
> in graphic mode - can be based on Qiao Yang character output for RPi 
> console
>   
> https://github.com/yangqiao/rtems/blob/framebuffer/c/src/lib/libbsp/arm/raspberrypi/console/outch.c
>   - use some x86 instructions emulator/executor to allow use PCI/PCIe
> VBE equipped graphic cards on non-x86 systems
>
> It would worth to add link to thesis to the list of RTEMS references,
> but there is a problem/question where. The complete list of all
> references maintained on original Wiki is now moved to the section TBR
>
>   https://devel.rtems.org/wiki/TBR/Website/RTEMSReferences
>
> Best wishes,
>
>  Pavel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Jan Dolezal bachelor thesis available - RTEMS VESA BIOS graphics on Current PC Graphics Cards

[Gedare Bloom]

On Fri, Jun 26, 2015 at 9:35 AM, Gedare Bloom  wrote:
> Congrats Jan, great work!
> Gedare
>
> On Fri, Jun 26, 2015 at 8:45 AM, Pavel Pisa  wrote:
>> Hello everybody,
>>
>> I would like to inform that full text of the bachelor
>> thesis
>>
>> Drivers and Libraries Enabling RTEMS OS GUI on Current PC Graphics Cards
>>
>> has been defended and is available online
>>
>> https://dspace.cvut.cz/handle/10467/61467
>>
>> https://dspace.cvut.cz/bitstream/handle/10467/61467/F3-BP-2015-Dolezal-Jan-Drivers-and-Libraries-Enabling-RTEMS-OS-GUI-on-Current-PC-Graphics-Cards.pdf
>>
>> It provides some generic overview and the documents
>> actual implementation.
>>
>> The VESA BIOS based support is chosen to be a default graphic option
>> for x86 based systems for upcoming RTEMS 4.11 release. Long story short
>>
>> pc386 family (pc386 .. pc686) VESA BIOS Extension (VBE) based frame buffer 
>> configuration selected by default
>>
>> the switch to graphic mode is controlled by multiboot option 
>> --video=auto|off|1024x768-32 etc.
>> application can override default none by exporting variable const char * 
>> const rtems_fb_default_mode="auto";
>>
>> Possible followup tasks:
>>
>>   - provide RTEMS text console/kernel messages output to framebuffer
>> in graphic mode - can be based on Qiao Yang character output for RPi 
>> console
>>   
>> https://github.com/yangqiao/rtems/blob/framebuffer/c/src/lib/libbsp/arm/raspberrypi/console/outch.c
>>   - use some x86 instructions emulator/executor to allow use PCI/PCIe
>> VBE equipped graphic cards on non-x86 systems
>>
>> It would worth to add link to thesis to the list of RTEMS references,
>> but there is a problem/question where. The complete list of all
>> references maintained on original Wiki is now moved to the section TBR
>>
>>   https://devel.rtems.org/wiki/TBR/Website/RTEMSReferences
>>
Feel free to put it there. Ignore that TBR for now...

>> Best wishes,
>>
>>  Pavel
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Results

[Sebastian Huber]

On 26/06/15 15:28, Gedare Bloom wrote:

Since this thread got migrated to devel a bit prematurely, I'll
back-stop some of the details and how I understand the state of this
project.

Saurabh is working toward solving https://devel.rtems.org/ticket/2124
(so yes there is a ticket already, and it  should be referenced by
patches accordingly). As a first step he has proposed a modified way
to step-down inherited priorities when multiple mutexes are acquired
simultaneously by one thread and contended by others, i.e. nested
mutex access. We wanted assurance the proposal is sound, so we had him
implement a model of the current thread synchronization of RTEMS
within a Java-based model-checking framework, called Java Path Finder,
or JPF. His model shows the existing error with the current
STRICT_ORDER option, and then does not show a problem using his
proposed method for solving nested mutex acquisition.

However, validating the proposed method apparently required adding a
global lock around the two linked lists that are used in Saurabh's
proposed solution. My intuition is that the global lock to protect
these lists is not a big problem for uniprocessor, and for SMP we
should prefer to find other solutions at any rate. The lists should
not be long, and we should be able to find their bounds. One list is
bounded by the number of mutexes a thread may hold, and the other by
the number of threads that may contend a specific mutex.


Does this new approach address the problem here:

https://git.rtems.org/rtems/tree/testsuites/sptests/spsem03/init.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.

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

Re: Results

[Gedare Bloom]

On Fri, Jun 26, 2015 at 9:42 AM, Sebastian Huber
 wrote:
> On 26/06/15 15:28, Gedare Bloom wrote:
>>
>> Since this thread got migrated to devel a bit prematurely, I'll
>> back-stop some of the details and how I understand the state of this
>> project.
>>
>> Saurabh is working toward solving https://devel.rtems.org/ticket/2124
>> (so yes there is a ticket already, and it  should be referenced by
>> patches accordingly). As a first step he has proposed a modified way
>> to step-down inherited priorities when multiple mutexes are acquired
>> simultaneously by one thread and contended by others, i.e. nested
>> mutex access. We wanted assurance the proposal is sound, so we had him
>> implement a model of the current thread synchronization of RTEMS
>> within a Java-based model-checking framework, called Java Path Finder,
>> or JPF. His model shows the existing error with the current
>> STRICT_ORDER option, and then does not show a problem using his
>> proposed method for solving nested mutex acquisition.
>>
>> However, validating the proposed method apparently required adding a
>> global lock around the two linked lists that are used in Saurabh's
>> proposed solution. My intuition is that the global lock to protect
>> these lists is not a big problem for uniprocessor, and for SMP we
>> should prefer to find other solutions at any rate. The lists should
>> not be long, and we should be able to find their bounds. One list is
>> bounded by the number of mutexes a thread may hold, and the other by
>> the number of threads that may contend a specific mutex.
>
>
> Does this new approach address the problem here:
>
> https://git.rtems.org/rtems/tree/testsuites/sptests/spsem03/init.c
>
Perhaps Saurabh can comment and model this problem too, and then we
can see. As I understood the test, a low-priority task holding
semaphore A blocks a mid-priority task holding semaphore B (contending
A), and then a high-priority task blocks on semaphore B, elevating the
priority of mid, but not low => a priority inversion occurs.

If Saurabh's solution iterates the mutexes held by mid when elevating
its priority, then this inversion also should be fixed.

Gedare

>
> --
> 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.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Results

[Saurabh Gadia]

I will try to model this test case environment soon and get back to you.
@gedare - you are absolutely correct about the description of project

On Friday, June 26, 2015, Gedare Bloom  wrote:

> On Fri, Jun 26, 2015 at 9:42 AM, Sebastian Huber
> > wrote:
> > On 26/06/15 15:28, Gedare Bloom wrote:
> >>
> >> Since this thread got migrated to devel a bit prematurely, I'll
> >> back-stop some of the details and how I understand the state of this
> >> project.
> >>
> >> Saurabh is working toward solving https://devel.rtems.org/ticket/2124
> >> (so yes there is a ticket already, and it  should be referenced by
> >> patches accordingly). As a first step he has proposed a modified way
> >> to step-down inherited priorities when multiple mutexes are acquired
> >> simultaneously by one thread and contended by others, i.e. nested
> >> mutex access. We wanted assurance the proposal is sound, so we had him
> >> implement a model of the current thread synchronization of RTEMS
> >> within a Java-based model-checking framework, called Java Path Finder,
> >> or JPF. His model shows the existing error with the current
> >> STRICT_ORDER option, and then does not show a problem using his
> >> proposed method for solving nested mutex acquisition.
> >>
> >> However, validating the proposed method apparently required adding a
> >> global lock around the two linked lists that are used in Saurabh's
> >> proposed solution. My intuition is that the global lock to protect
> >> these lists is not a big problem for uniprocessor, and for SMP we
> >> should prefer to find other solutions at any rate. The lists should
> >> not be long, and we should be able to find their bounds. One list is
> >> bounded by the number of mutexes a thread may hold, and the other by
> >> the number of threads that may contend a specific mutex.
> >
> >
> > Does this new approach address the problem here:
> >
> > https://git.rtems.org/rtems/tree/testsuites/sptests/spsem03/init.c
> >
> Perhaps Saurabh can comment and model this problem too, and then we
> can see. As I understood the test, a low-priority task holding
> semaphore A blocks a mid-priority task holding semaphore B (contending
> A), and then a high-priority task blocks on semaphore B, elevating the
> priority of mid, but not low => a priority inversion occurs.
>
> If Saurabh's solution iterates the mutexes held by mid when elevating
> its priority, then this inversion also should be fixed.
>
> Gedare
>
> >
> > --
> > 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.
> >
> > ___
> > 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



-- 
Thanks,

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

Re: GSoC 2015 RPi USB Support

[Yurii Shevtsov]

2015-06-25 16:00 GMT+03:00 Sebastian Huber :
> I would set a break point to nexus_probe(). In this loop
>
> SET_FOREACH(nd, nexus) {
> device_add_child(dev, nd->name, nd->unit);
> }
>
> your device must get added. I would also set break points to the probe and
> attach functions of your device.

Added printfs()

printf("before setforeach\n");

SET_FOREACH(nd, nexus) {
printf("setforeach: %s\n", nd->name);
device_add_child(dev, nd->name, nd->unit);
}

Got only 'before setforeach' in console. So it doesn't step into loop.
Any ideas? Also I already had printfs in my driver's probe and attach,
also got no output.

> On 25/06/15 14:50, Yurii Shevtsov wrote:
>>
>> This is ping message, with small update: the problem is not on the
>> linking stage, driver is linked to testsuite (checked with objdump)
>>
>> 2015-06-21 17:57 GMT+03:00 Yurii Shevtsov :
>>>
>>> Hello)
>>> Now I have apps from libbsd testsuite running. But DWC OTG driver doesn't
>>> loads.
>>> I added this lines to init01/test_main.c:
>>>
>>> +SYSINIT_NEED_USB_CORE;
>>> +SYSINIT_DRIVER_REFERENCE(bcm283x_dwcotg, nexus);
>>>
>>> (I know it's bad hardcode)
>>>
>>> If I run it. I get only this:
>>>nexus0: 
>>>devctl: +nexus0 at   on root0
>>>devctl: !system=IFNET subsystem=lo0 type=ATTACH
>>>
>>> Of course, I modified rtemsbsd/include/machine/rtems-bsd-sysinit.h and
>>> rtemsbsd/include/bsp/nexus-devices.h (took vlues from working DTS) and
>>> did other nexus-related changes to drivers. You can find changes in my
>>> repo https://github.com/gtament/rtems-libbsd/
>>> So I need some kind of code review, please.
>>> P.S. All testsuites (netshell01, usb01) with shell hangs without any
>>> output.
>>>
>>> Thanks in advance!
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
> --
> 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.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Fwd: [GSoC Mentors] [GSoC 2015] Mentor Midterm Evaluations 26 June - 3 July

[Joel Sherrill]

All students and mentors will need to start doing their midterm evaluations
as soon as possible.

But notice the time. The evaluation forms are not live for a few hours.

Please make this easy and let's get this behind us. :)

-- Forwarded message -
From: 'Carol Smith' via Google Summer of Code Mentors List <
google-summer-of-code-mentors-l...@googlegroups.com>
Date: Wed, Jun 17, 2015, 12:43 PM
Subject: [GSoC Mentors] [GSoC 2015] Mentor Midterm Evaluations 26 June - 3
July
To: Google Summer of Code Mentors List <
google-summer-of-code-mentors-l...@googlegroups.com>


Hi GSoC 2015 Mentors and Org Admins,

Per the program timeline
, starting next
Friday, 26 June you will will be able to submit an evaluation of your
student(s)' progress on their projects thus far.


Here's some important info on midterm evaluations for those not familiar:

Midterm evaluations are done via Melange
. Starting at
19:00 UTC on Friday, 26 June you will be able to submit an evaluation for
your student(s).You can find the evaluation links on your dashboard under
'Evaluations', one for each student you are a mentor for. If you are
curious about who can see evaluations after they are submitted, please
check out the FAQ on Evaluations
.
I have also pre-published the evaluation questions below in this email so
you can prepare. The deadline to submit your evaluation is 19:00 UTC on
Friday, 3 July. For those of you who have participated in evaluations in
previous years, please note that this evaluation window is extended by
three days to include a weekend and gives you more time to submit.

You may not submit your evaluation before or after the evaluation window.
Please ask your org admin to submit your evaluation for you if you
absolutely cannot submit yours on time. There really is no excuse for
missing the submission of a student's evaluation.

You must submit an evaluation for every student you are a mentor for this
year. You may submit, modify, and resubmit an evaluation as many times as
you choose up until the deadline. You must answer all required questions on
the evaluation in order to save submit it.

Please note that failing a student at the midterm evaluation means *this
student is immediately removed from the program.* There is no way to fail a
student at the midterm and have the student continue with the program to
try to "make it up" at the final. If your student fails, your student is
out.

You might find the FLOSS manual on GSoC evaluations
 helpful as well.
There's some excellent wisdom in there from your fellow mentors and org
admins on the evaluation process.

Students must have an evaluation on file from both themselves *and* a
passing evaluation from their mentor(s) in order to receive their midterm
payments.

Finally, a reminder: This year we will not allow any mentor who misses an
evaluation deadline to attend the mentor summit (assuming no one else
submits the evaluation on the mentor's behalf before the deadline either).
Also, any org that misses 2 or more evaluation deadlines (for the midterm,
final, or midterm and final combined) will not be allowed to attend the
mentor summit this year.

Please let me know directly if you have questions or concerns.

Cheers,

Carol

-

   1.

   How many years have you been a mentor for Google Summer of Code (Total -
   this doesn’t have to be consecutive)?
   1.

  This is my first year
  2.

  2-3 years
  3.

  More than 3 years
  2.

   If you answered “2-3 years” or “more than 3 years” as a mentor, what
   years did you participate?
   3.

   How many years have you been a student in Google Summer of Code?
   1.

  I have never been a student
  2.

  1 year
  3.

  2 years
  4.

  3+ years
  4.

   If you answered 2 years or 3+ years, what years did you participate as a
   student?
   5.

   At what point did you first make contact with your student?
   1.

  Before the program was announced
  2.

  After my organization was selected to participate in Google Summer of
  Code
  3.

  During the student application/acceptance phase of the program
  4.

  During the community bonding period
  5.

  After the start of coding
  6.

   How often do you and your student interact?
   1.

  Daily
  2.

  Every few days
  3.

  Weekly
  4.

  Every few weeks
  5.

  Monthly
  6.

  Less than once a month
  7.

   How do you communicate with your student? (Check all that apply)
   1.

  Google+ Hangout
  2.

  Voice (phone, Skype, etc.)
  3.

  IM/IRC
  4.

  Private emails
  5.

  Mailing Lists

Re: [PATCH] modified: waf_generator.py Fix incorrect encoding of NET_CFG_GATEWAY_IP and change _IP_IP ending to _IP. Remove _IP_IP ending from NET_TAP_INTERFACE.

[Gene Smith]

On 06/26/2015 12:13 AM, Chris Johns wrote:


Pushed.

Thanks.
Chris


Thanks. Sorry about the long subject/summary line.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] Import cpsw driver and smscphy driver from FreeBSD

[ragunath]

---
 Makefile |2 +
 freebsd/sys/arm/ti/cpsw/if_cpsw.c| 2198 ++
 freebsd/sys/arm/ti/cpsw/if_cpswreg.h |  137 +++
 freebsd/sys/arm/ti/cpsw/if_cpswvar.h |  124 ++
 freebsd/sys/dev/mii/smscphy.c|  227 
 libbsd.py|4 +
 wscript  |4 +-
 7 files changed, 2695 insertions(+), 1 deletion(-)
 create mode 100644 freebsd/sys/arm/ti/cpsw/if_cpsw.c
 create mode 100644 freebsd/sys/arm/ti/cpsw/if_cpswreg.h
 create mode 100644 freebsd/sys/arm/ti/cpsw/if_cpswvar.h
 create mode 100644 freebsd/sys/dev/mii/smscphy.c

diff --git a/Makefile b/Makefile
index da2a5ef..4b9f2c7 100644
--- a/Makefile
+++ b/Makefile
@@ -182,10 +182,12 @@ LIB_C_FILES += freebsd/sys/dev/mii/brgphy.c
 LIB_C_FILES += freebsd/sys/dev/mii/micphy.c
 LIB_C_FILES += freebsd/sys/dev/mii/ukphy.c
 LIB_C_FILES += freebsd/sys/dev/mii/ukphy_subr.c
+LIB_C_FILES += freebsd/sys/dev/mii/smscphy.c
 LIB_C_FILES += freebsd/sys/dev/tsec/if_tsec.c
 LIB_C_FILES += freebsd/sys/dev/cadence/if_cgem.c
 LIB_C_FILES += freebsd/sys/dev/dwc/if_dwc.c
 LIB_C_FILES += freebsd/sys/arm/xilinx/zy7_slcr.c
+LIB_C_FILES += freebsd/sys/arm/ti/cpsw/if_cpsw.c
 LIB_C_FILES += freebsd/sys/dev/random/harvest.c
 LIB_C_FILES += freebsd/sys/netinet/tcp_hostcache.c
 LIB_C_FILES += freebsd/sys/dev/led/led.c
diff --git a/freebsd/sys/arm/ti/cpsw/if_cpsw.c 
b/freebsd/sys/arm/ti/cpsw/if_cpsw.c
new file mode 100644
index 000..c3ba0c8
--- /dev/null
+++ b/freebsd/sys/arm/ti/cpsw/if_cpsw.c
@@ -0,0 +1,2198 @@
+#include 
+
+/*-
+ * Copyright (c) 2012 Damjan Marion 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * TI Common Platform Ethernet Switch (CPSW) Driver
+ * Found in TI8148 "DaVinci" and AM335x "Sitara" SoCs.
+ *
+ * This controller is documented in the AM335x Technical Reference
+ * Manual, in the TMS320DM814x DaVinci Digital Video Processors TRM
+ * and in the TMS320C6452 3 Port Switch Ethernet Subsystem TRM.
+ *
+ * It is basically a single Ethernet port (port 0) wired internally to
+ * a 3-port store-and-forward switch connected to two independent
+ * "sliver" controllers (port 1 and port 2).  You can operate the
+ * controller in a variety of different ways by suitably configuring
+ * the slivers and the Address Lookup Engine (ALE) that routes packets
+ * between the ports.
+ *
+ * This code was developed and tested on a BeagleBone with
+ * an AM335x SoC.
+ */
+
+#include 
+__FBSDID("$FreeBSD$");
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "if_cpswreg.h"
+#include "if_cpswvar.h"
+
+#include 
+
+#include "miibus_if.h"
+
+/* Device probe/attach/detach. */
+static int cpsw_probe(device_t);
+static void cpsw_init_slots(struct cpsw_softc *);
+static int cpsw_attach(device_t);
+static void cpsw_free_slot(struct cpsw_softc *, struct cpsw_slot *);
+static int cpsw_detach(device_t);
+
+/* Device Init/shutdown. */
+static void cpsw_init(void *);
+static void cpsw_init_locked(void *);
+static int cpsw_shutdown(device_t);
+static void cpsw_shutdown_locked(struct cpsw_softc *);
+
+/* Device Suspend/Resume. */
+static int cpsw_suspend(device_t);
+static int cpsw_resume(device_t);
+
+/* Ioctl. */
+static int cpsw_ioctl(struct ifnet *, u_long command, caddr_t data);
+
+static int cpsw_miibus_readreg(device_t, int phy, int reg);
+static int cpsw_miibus_writereg(device_t, int 

[PATCH] RTEMS related changes for cpsw ethernet driver

[ragunath]

---
 Makefile   |  1 +
 freebsd/sys/arm/ti/cpsw/if_cpsw.c  | 56 --
 freebsd/sys/arm/ti/cpsw/if_cpswreg.h   |  1 +
 freebsd/sys/arm/ti/cpsw/if_cpswvar.h   |  2 +
 rtemsbsd/include/bsp/nexus-devices.h   | 34 +
 rtemsbsd/include/machine/rtems-bsd-cache.h |  2 +-
 .../include/rtems/bsd/test/network-config.h.in |  2 +
 7 files changed, 93 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index 4b9f2c7..8b46db7 100644
--- a/Makefile
+++ b/Makefile
@@ -23,6 +23,7 @@ COMMON_FLAGS += -Ifreebsd/lib/libkvm
 COMMON_FLAGS += -Ifreebsd/lib/libmemstat
 COMMON_FLAGS += -Ifreebsd/lib/libipsec
 COMMON_FLAGS += -Irtemsbsd/sys
+COMMON_FLAGS += -Irtemsbsd/include/rtems/bsd/local
 COMMON_FLAGS += -ImDNSResponder/mDNSCore
 COMMON_FLAGS += -ImDNSResponder/mDNSShared
 COMMON_FLAGS += -ImDNSResponder/mDNSPosix
diff --git a/freebsd/sys/arm/ti/cpsw/if_cpsw.c 
b/freebsd/sys/arm/ti/cpsw/if_cpsw.c
index c3ba0c8..7fda577 100644
--- a/freebsd/sys/arm/ti/cpsw/if_cpsw.c
+++ b/freebsd/sys/arm/ti/cpsw/if_cpsw.c
@@ -52,7 +52,11 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 #include 
+#ifndef __rtems__
 #include 
+#else
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -82,14 +86,18 @@ __FBSDID("$FreeBSD$");
 #include 
 #include 
 
+#ifndef __rtems__
 #include 
 #include 
 #include 
+#endif
 
 #include "if_cpswreg.h"
 #include "if_cpswvar.h"
 
+#ifndef __rtems__
 #include 
+#endif
 
 #include "miibus_if.h"
 
@@ -140,9 +148,11 @@ static int cpsw_ale_update_addresses(struct cpsw_softc *, 
int purge);
 static void cpsw_ale_dump_table(struct cpsw_softc *);
 
 /* Statistics and sysctls. */
+#ifndef __rtems__
 static void cpsw_add_sysctls(struct cpsw_softc *);
 static void cpsw_stats_collect(struct cpsw_softc *);
 static int cpsw_stats_sysctl(SYSCTL_HANDLER_ARGS);
+#endif
 
 /*
  * Arbitrary limit on number of segments in an mbuf to be transmitted.
@@ -192,7 +202,11 @@ static driver_t cpsw_driver = {
 
 static devclass_t cpsw_devclass;
 
+#ifndef __rtems__
 DRIVER_MODULE(cpsw, simplebus, cpsw_driver, cpsw_devclass, 0, 0);
+#else
+DRIVER_MODULE(cpsw, nexus, cpsw_driver, cpsw_devclass, 0, 0);
+#endif
 DRIVER_MODULE(miibus, cpsw, miibus_driver, miibus_devclass, 0, 0);
 MODULE_DEPEND(cpsw, ether, 1, 1, 1);
 MODULE_DEPEND(cpsw, miibus, 1, 1, 1);
@@ -206,6 +220,7 @@ static struct resource_spec res_spec[] = {
{ -1, 0 }
 };
 
+#ifndef __rtems__
 /* Number of entries here must match size of stats
  * array in struct cpsw_softc. */
 static struct cpsw_stat {
@@ -247,6 +262,7 @@ static struct cpsw_stat {
{0x88, "RxMiddleOfFrameOverruns"},
{0x8c, "RxDmaOverruns"}
 };
+#endif
 
 /*
  * Basic debug support.
@@ -326,6 +342,11 @@ cpsw_debugf(const char *fmt, ...)
  */
 #definecpsw_read_4(sc, reg)bus_read_4(sc->res[0], reg)
 #definecpsw_write_4(sc, reg, val)  bus_write_4(sc->res[0], reg, 
val)
+#define BUS_SPACE_PHYSADDR(res, offs) \
+((u_int)(rman_get_start(res)+(offs)))
+#define cm_read(a)(*(volatile uint32_t *)(a))
+#define cm_write(a,v) (*(volatile uint32_t *)(a) = (v))
+
 
 #definecpsw_cpdma_bd_offset(i) (CPSW_CPPI_RAM_OFFSET + ((i)*16))
 
@@ -447,11 +468,13 @@ static int
 cpsw_probe(device_t dev)
 {
 
+#ifndef __rtems__
if (!ofw_bus_status_okay(dev))
return (ENXIO);
 
if (!ofw_bus_is_compatible(dev, "ti,cpsw"))
return (ENXIO);
+#endif
 
device_set_desc(dev, "3-port Switch Ethernet Subsystem");
return (BUS_PROBE_DEFAULT);
@@ -551,14 +574,18 @@ cpsw_attach(device_t dev)
struct cpsw_softc *sc = device_get_softc(dev);
struct mii_softc *miisc;
struct ifnet *ifp;
+#ifndef __rtems__
void *phy_sc;
-   int error, phy, nsegs;
+   int phy;
+#endif
+   int error, nsegs;
uint32_t reg;
 
CPSW_DEBUGF((""));
 
getbinuptime(&sc->attach_uptime);
sc->dev = dev;
+#ifndef __rtems__
sc->node = ofw_bus_get_node(dev);
 
/* Get phy address from fdt */
@@ -566,6 +593,7 @@ cpsw_attach(device_t dev)
device_printf(dev, "failed to get PHY address from FDT\n");
return (ENXIO);
}
+#endif
/* Initialize mutexes */
mtx_init(&sc->tx.lock, device_get_nameunit(dev),
"cpsw TX lock", MTX_DEF);
@@ -584,7 +612,9 @@ cpsw_attach(device_t dev)
device_printf(dev, "CPSW SS Version %d.%d (%d)\n", (reg >> 8 & 0x7),
reg & 0xFF, (reg >> 11) & 0x1F);
 
+#ifndef __rtems__
cpsw_add_sysctls(sc);
+#endif
 
/* Allocate a busdma tag and DMA safe memory for mbufs. */
error = bus_dma_tag_create(
@@ -657,14 +687,22 @@ cpsw_attach(device_t dev)
 
/* Get high part of MAC address from control module (mac_id0_hi) */
/* TODO: Get MAC ID1 as well as MAC ID0. */
+#ifndef __rtems__
ti_scm_reg_read_4(0x634, ®)

Re: [PATCH] RTEMS related changes for cpsw ethernet driver

[Gedare Bloom]

On Fri, Jun 26, 2015 at 4:41 PM, ragunath  wrote:
> ---
>  Makefile   |  1 +
>  freebsd/sys/arm/ti/cpsw/if_cpsw.c  | 56 
> --
>  freebsd/sys/arm/ti/cpsw/if_cpswreg.h   |  1 +
>  freebsd/sys/arm/ti/cpsw/if_cpswvar.h   |  2 +
>  rtemsbsd/include/bsp/nexus-devices.h   | 34 +
>  rtemsbsd/include/machine/rtems-bsd-cache.h |  2 +-
>  .../include/rtems/bsd/test/network-config.h.in |  2 +
>  7 files changed, 93 insertions(+), 5 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 4b9f2c7..8b46db7 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -23,6 +23,7 @@ COMMON_FLAGS += -Ifreebsd/lib/libkvm
>  COMMON_FLAGS += -Ifreebsd/lib/libmemstat
>  COMMON_FLAGS += -Ifreebsd/lib/libipsec
>  COMMON_FLAGS += -Irtemsbsd/sys
> +COMMON_FLAGS += -Irtemsbsd/include/rtems/bsd/local
>  COMMON_FLAGS += -ImDNSResponder/mDNSCore
>  COMMON_FLAGS += -ImDNSResponder/mDNSShared
>  COMMON_FLAGS += -ImDNSResponder/mDNSPosix
> diff --git a/freebsd/sys/arm/ti/cpsw/if_cpsw.c 
> b/freebsd/sys/arm/ti/cpsw/if_cpsw.c
> index c3ba0c8..7fda577 100644
> --- a/freebsd/sys/arm/ti/cpsw/if_cpsw.c
> +++ b/freebsd/sys/arm/ti/cpsw/if_cpsw.c
> @@ -52,7 +52,11 @@ __FBSDID("$FreeBSD$");
>  #include 
>  #include 
>  #include 
> +#ifndef __rtems__
>  #include 
> +#else
> +#include 
> +#endif
I think something like /* __rtems__ */ is supposed to go after the endifs.

>  #include 
>  #include 
>  #include 
> @@ -82,14 +86,18 @@ __FBSDID("$FreeBSD$");
>  #include 
>  #include 
>
> +#ifndef __rtems__
>  #include 
>  #include 
>  #include 
> +#endif
>
>  #include "if_cpswreg.h"
>  #include "if_cpswvar.h"
>
> +#ifndef __rtems__
>  #include 
> +#endif
>
>  #include "miibus_if.h"
>
> @@ -140,9 +148,11 @@ static int cpsw_ale_update_addresses(struct cpsw_softc 
> *, int purge);
>  static void cpsw_ale_dump_table(struct cpsw_softc *);
>
>  /* Statistics and sysctls. */
> +#ifndef __rtems__
>  static void cpsw_add_sysctls(struct cpsw_softc *);
>  static void cpsw_stats_collect(struct cpsw_softc *);
>  static int cpsw_stats_sysctl(SYSCTL_HANDLER_ARGS);
> +#endif
>
>  /*
>   * Arbitrary limit on number of segments in an mbuf to be transmitted.
> @@ -192,7 +202,11 @@ static driver_t cpsw_driver = {
>
>  static devclass_t cpsw_devclass;
>
> +#ifndef __rtems__
>  DRIVER_MODULE(cpsw, simplebus, cpsw_driver, cpsw_devclass, 0, 0);
> +#else
> +DRIVER_MODULE(cpsw, nexus, cpsw_driver, cpsw_devclass, 0, 0);
> +#endif
>  DRIVER_MODULE(miibus, cpsw, miibus_driver, miibus_devclass, 0, 0);
>  MODULE_DEPEND(cpsw, ether, 1, 1, 1);
>  MODULE_DEPEND(cpsw, miibus, 1, 1, 1);
> @@ -206,6 +220,7 @@ static struct resource_spec res_spec[] = {
> { -1, 0 }
>  };
>
> +#ifndef __rtems__
>  /* Number of entries here must match size of stats
>   * array in struct cpsw_softc. */
>  static struct cpsw_stat {
> @@ -247,6 +262,7 @@ static struct cpsw_stat {
> {0x88, "RxMiddleOfFrameOverruns"},
> {0x8c, "RxDmaOverruns"}
>  };
> +#endif
>
>  /*
>   * Basic debug support.
> @@ -326,6 +342,11 @@ cpsw_debugf(const char *fmt, ...)
>   */
>  #definecpsw_read_4(sc, reg)bus_read_4(sc->res[0], reg)
>  #definecpsw_write_4(sc, reg, val)  bus_write_4(sc->res[0], reg, 
> val)
> +#define BUS_SPACE_PHYSADDR(res, offs) \
> +((u_int)(rman_get_start(res)+(offs)))
> +#define cm_read(a)(*(volatile uint32_t *)(a))
> +#define cm_write(a,v) (*(volatile uint32_t *)(a) = (v))
> +
Make sure everything added has the __rtems__ guards.

>
>  #definecpsw_cpdma_bd_offset(i) (CPSW_CPPI_RAM_OFFSET + ((i)*16))
>
> @@ -447,11 +468,13 @@ static int
>  cpsw_probe(device_t dev)
>  {
>
> +#ifndef __rtems__
> if (!ofw_bus_status_okay(dev))
> return (ENXIO);
>
> if (!ofw_bus_is_compatible(dev, "ti,cpsw"))
> return (ENXIO);
> +#endif
>
> device_set_desc(dev, "3-port Switch Ethernet Subsystem");
> return (BUS_PROBE_DEFAULT);
> @@ -551,14 +574,18 @@ cpsw_attach(device_t dev)
> struct cpsw_softc *sc = device_get_softc(dev);
> struct mii_softc *miisc;
> struct ifnet *ifp;
> +#ifndef __rtems__
> void *phy_sc;
> -   int error, phy, nsegs;
> +   int phy;
> +#endif
> +   int error, nsegs;
> uint32_t reg;
>
> CPSW_DEBUGF((""));
>
> getbinuptime(&sc->attach_uptime);
> sc->dev = dev;
> +#ifndef __rtems__
> sc->node = ofw_bus_get_node(dev);
>
> /* Get phy address from fdt */
> @@ -566,6 +593,7 @@ cpsw_attach(device_t dev)
> device_printf(dev, "failed to get PHY address from FDT\n");
> return (ENXIO);
> }
> +#endif
> /* Initialize mutexes */
> mtx_init(&sc->tx.lock, device_get_nameunit(dev),
> "cpsw TX lock", MTX_DEF);
> @@ -584,7 +612,9 @@ cpsw_attach(device_t dev)
> device_printf(dev, "CPSW SS Version %d.%d (%d)\n", (reg >>

Re: GSOC 2015: Configuration GUI

[Anand Krishnan]

Hi,

The GUI is partially done. The set up for Boolean and Integer options is
done.

Find the files here: https://github.com/anandkp92/waf/tree/waf/gui
[Run gui.py].

Please let me know if you are facing any issue while running this file or
any changes I have to make.

Thanks,
Anand

On Thu, Jun 18, 2015 at 12:07 PM, Anand Krishnan 
wrote:

> Hi,
>
>
> On Thu, Jun 18, 2015 at 10:45 AM, Anand Krishnan 
> wrote:
>
>>
>>
>> On Thu, Jun 18, 2015 at 6:18 AM, Amar Takhar  wrote:
>>
>>> On 2015-06-18 05:57 +0530, Anand Krishnan wrote:
>>> > Hi all,
>>> >
>>> > I've almost prepared the basic layout for the GUI. Also added some
>>> dummy event
>>> > handlers for File Menu.
>>> >
>>> > Any more suggestions before fetching the options?
>>>
>>> This is a great start!
>>>
>>> Have you thought about how you are going to lay out the tabs for
>>> multiple BSP
>>> configs + the tag headings?
>>>
>>> One option is to do multi-layered tabs along the top.  Another is tabs
>>> on the
>>> top and vertically (left side).
>>>
>>> I'll check it out now and post it when I get some good  results
>>
>
> I've added the multilayered tabs. I tried both the ways that you mentioned
> -> along the top and left. And I felt this was better. But I can revert to
> the other one in no time.
>
> link: https://github.com/anandkp92/waf/tree/waf/gui
>
>>
>>> Amar.
>>>
>>
>> Thanks,
>> Anand
>>
>
> Anand.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel