[PATCH] confdefs.h: Add SMP enabled field to configuration

2017-05-12 Thread Sebastian Huber 
Do not use the processor count to determine if SMP is enabled.  Instead
use a dedicated configuration option.  Enable SMP by default in SMP
configurations.

Add CONFIGURE_DISABLE_SMP_CONFIGURATION to all test which would fail
otherwise.

Update #3001.
---
 cpukit/sapi/include/confdefs.h   | 7 +++
 cpukit/sapi/include/rtems/config.h   | 6 +-
 testsuites/libtests/cpuuse/system.h  | 2 ++
 testsuites/libtests/rtmonuse/system.h| 2 ++
 testsuites/libtests/termios05/init.c | 2 ++
 testsuites/sptests/sp01/system.h | 2 ++
 testsuites/sptests/sp08/init.c   | 2 ++
 testsuites/sptests/sp14/system.h | 2 ++
 testsuites/sptests/sp20/system.h | 2 ++
 testsuites/sptests/sp37/system.h | 2 ++
 testsuites/sptests/spcbssched01/system.h | 2 ++
 testsuites/sptests/spcbssched02/system.h | 2 ++
 testsuites/sptests/spcbssched03/system.h | 2 ++
 testsuites/sptests/spedfsched01/system.h | 2 ++
 testsuites/sptests/spedfsched02/system.h | 2 ++
 testsuites/sptests/spedfsched03/system.h | 2 ++
 testsuites/sptests/spfifo03/init.c   | 2 +-
 testsuites/sptests/spfifo05/init.c   | 2 +-
 testsuites/tmtests/tm08/system.h | 2 ++
 testsuites/tmtests/tm22/system.h | 2 ++
 20 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h
index 5cba1a8..4ac6700 100755
--- a/cpukit/sapi/include/confdefs.h
+++ b/cpukit/sapi/include/confdefs.h
@@ -3320,6 +3320,13 @@ extern rtems_initialization_tasks_table 
Initialization_tasks[];
 #else
   false,
 #endif
+#ifdef RTEMS_SMP
+  #ifdef _CONFIGURE_SMP_APPLICATION
+true,
+  #else
+false,
+  #endif
+#endif
 _CONFIGURE_NUMBER_OF_INITIAL_EXTENSIONS,   /* number of static extensions 
*/
 CONFIGURE_INITIAL_EXTENSION_TABLE,/* pointer to static extensions 
*/
 #if defined(RTEMS_MULTIPROCESSING)
diff --git a/cpukit/sapi/include/rtems/config.h 
b/cpukit/sapi/include/rtems/config.h
index ddcb77c..2993e70 100644
--- a/cpukit/sapi/include/rtems/config.h
+++ b/cpukit/sapi/include/rtems/config.h
@@ -237,6 +237,10 @@ typedef struct {
*/
   bool   stack_allocator_avoids_work_space;
 
+  #ifdef RTEMS_SMP
+bool smp_enabled;
+  #endif
+
   uint32_t   number_of_initial_extensions;
   const rtems_extensions_table  *User_extension_table;
   #if defined(RTEMS_MULTIPROCESSING)
@@ -360,7 +364,7 @@ extern const rtems_configuration_table Configuration;
  */
 #ifdef RTEMS_SMP
   #define rtems_configuration_is_smp_enabled() \
-(rtems_configuration_get_maximum_processors() > 1)
+(Configuration.smp_enabled)
 #else
   #define rtems_configuration_is_smp_enabled() \
 false
diff --git a/testsuites/libtests/cpuuse/system.h 
b/testsuites/libtests/cpuuse/system.h
index 0501d41..562f2db 100644
--- a/testsuites/libtests/cpuuse/system.h
+++ b/testsuites/libtests/cpuuse/system.h
@@ -50,6 +50,8 @@ void Task_switch(
 
 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
 
+#define CONFIGURE_DISABLE_SMP_CONFIGURATION
+
 #include 
 
 /* global variables */
diff --git a/testsuites/libtests/rtmonuse/system.h 
b/testsuites/libtests/rtmonuse/system.h
index 1544f80..b7bb5f1 100644
--- a/testsuites/libtests/rtmonuse/system.h
+++ b/testsuites/libtests/rtmonuse/system.h
@@ -47,6 +47,8 @@ void Get_all_counters( void );
 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
 
 #define CONFIGURE_EXTRA_TASK_STACKS   (20 * RTEMS_MINIMUM_STACK_SIZE)
+
+#define CONFIGURE_DISABLE_SMP_CONFIGURATION
 #include 
 
 /* global variables */
diff --git a/testsuites/libtests/termios05/init.c 
b/testsuites/libtests/termios05/init.c
index 3cdf969..e9f1531 100644
--- a/testsuites/libtests/termios05/init.c
+++ b/testsuites/libtests/termios05/init.c
@@ -166,6 +166,8 @@ rtems_task Init(
 
 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
 
+#define CONFIGURE_DISABLE_SMP_CONFIGURATION
+
 #define CONFIGURE_INIT
 
 #include 
diff --git a/testsuites/sptests/sp01/system.h b/testsuites/sptests/sp01/system.h
index a317dd9..68f8277 100644
--- a/testsuites/sptests/sp01/system.h
+++ b/testsuites/sptests/sp01/system.h
@@ -31,6 +31,8 @@ rtems_task Task_1_through_3(
 #define CONFIGURE_EXTRA_TASK_STACKS (4 * RTEMS_MINIMUM_STACK_SIZE)
 #define CONFIGURE_MAXIMUM_TASKS 4
 
+#define CONFIGURE_DISABLE_SMP_CONFIGURATION
+
 #include 
 
 /* global variables */
diff --git a/testsuites/sptests/sp08/init.c b/testsuites/sptests/sp08/init.c
index 77e9819..2364c70 100644
--- a/testsuites/sptests/sp08/init.c
+++ b/testsuites/sptests/sp08/init.c
@@ -300,6 +300,8 @@ rtems_task Init(
 
 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
 
+#define CONFIGURE_DISABLE_SMP_CONFIGURATION
+
 #define CONFIGURE_INIT
 #include 
 /* end of file */
diff --git a/testsuites/sptests/sp14/system.h b/testsuites/sptests/sp14/system.h
index 7721366..3a63a8d 100644
--- a/testsuites/sptests/sp14/system.h
+++ b/testsuites/sptes

Re: GCC 7.1 Released

2017-05-12 Thread Chris Johns 

On 12/05/2017 15:56, Sebastian Huber wrote:

On 11/05/17 17:29, Joel Sherrill wrote:

Ok to

On May 11, 2017 5:09 AM, "Sebastian Huber"
mailto:sebastian.hu...@embedded-brains.de>> wrote:

Hello,

if someone wants to use GCC 7.1 for RTEMS 4.12, then the RSB
should be updated accordingly as soon as possible.


Chris posted a patch to bump gcc and binutils. He just needs to push it.


I didn't see the patch. According to



I have not posted anything.


contrib/download_prerequisites

we should use

gmp='gmp-6.1.0.tar.bz2'
mpfr='mpfr-3.1.4.tar.bz2'
mpc='mpc-1.0.3.tar.gz'
isl='isl-0.16.1.tar.bz2'

for GCC 7.



I talked to Joel late his time yesterday and he is reporting increased 
code size and as a result some tests are not fitting into the target. 
Rather than head on into the change we think it is better to step back 
and visit it again after we have a release. What do you think?


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

Re: GCC 7.1 Released

2017-05-12 Thread Sebastian Huber 

On 12/05/17 10:35, Chris Johns wrote:

On 12/05/2017 15:56, Sebastian Huber wrote:

On 11/05/17 17:29, Joel Sherrill wrote:

Ok to

On May 11, 2017 5:09 AM, "Sebastian Huber"
mailto:sebastian.hu...@embedded-brains.de>> wrote:

Hello,

if someone wants to use GCC 7.1 for RTEMS 4.12, then the RSB
should be updated accordingly as soon as possible.


Chris posted a patch to bump gcc and binutils. He just needs to push 
it.


I didn't see the patch. According to



I have not posted anything.


contrib/download_prerequisites

we should use

gmp='gmp-6.1.0.tar.bz2'
mpfr='mpfr-3.1.4.tar.bz2'
mpc='mpc-1.0.3.tar.gz'
isl='isl-0.16.1.tar.bz2'

for GCC 7.



I talked to Joel late his time yesterday and he is reporting increased 
code size and as a result some tests are not fitting into the target. 
Rather than head on into the change we think it is better to step back 
and visit it again after we have a release. What do you think? 


A code size increase would be not an issue for me if its in the range of 
a small percent range. However, we should identify this and create a GCC PR.


Gaisler suggested to use GCC 7.1. Did Gaisler observe some significant 
code size changes on SPARC?


--
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] confdefs.h: Add SMP enabled field to configuration

2017-05-12 Thread Chris Johns 

On 12/05/2017 18:11, Sebastian Huber wrote:

Do not use the processor count to determine if SMP is enabled.  Instead
use a dedicated configuration option.  Enable SMP by default in SMP
configurations.

Add CONFIGURE_DISABLE_SMP_CONFIGURATION to all test which would fail
otherwise.



I think adding a comment to the test explaining the reason would be good 
to have.


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

Re: GCC 7.1 Released

2017-05-12 Thread Chris Johns 

On 12/05/2017 18:39, Sebastian Huber wrote:

On 12/05/17 10:35, Chris Johns wrote:

On 12/05/2017 15:56, Sebastian Huber wrote:

On 11/05/17 17:29, Joel Sherrill wrote:

I talked to Joel late his time yesterday and he is reporting increased
code size and as a result some tests are not fitting into the target.
Rather than head on into the change we think it is better to step back
and visit it again after we have a release. What do you think?


A code size increase would be not an issue for me if its in the range of
a small percent range. However, we should identify this and create a GCC
PR.

Gaisler suggested to use GCC 7.1. Did Gaisler observe some significant
code size changes on SPARC?



Sorry I do not have any detail. I am sure Joel can provide some when he 
is online and has some time.


I think all he did was build all the BSPs with tests and saw some new 
failures.


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

Re: [PATCH] confdefs.h: Add SMP enabled field to configuration

2017-05-12 Thread Sebastian Huber 

On 12/05/17 10:39, Chris Johns wrote:

On 12/05/2017 18:11, Sebastian Huber wrote:

Do not use the processor count to determine if SMP is enabled.  Instead
use a dedicated configuration option.  Enable SMP by default in SMP
configurations.

Add CONFIGURE_DISABLE_SMP_CONFIGURATION to all test which would fail
otherwise.



I think adding a comment to the test explaining the reason would be 
good to have.


This is a new issue and not a 4.12 release blocker from my point of view:

https://devel.rtems.org/ticket/3020

--
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] confdefs.h: Add SMP enabled field to configuration

2017-05-12 Thread Joel Sherrill 
On May 12, 2017 3:44 AM, "Sebastian Huber" <
sebastian.hu...@embedded-brains.de> wrote:

On 12/05/17 10:39, Chris Johns wrote:

> On 12/05/2017 18:11, Sebastian Huber wrote:
>
>> Do not use the processor count to determine if SMP is enabled.  Instead
>> use a dedicated configuration option.  Enable SMP by default in SMP
>> configurations.
>>
>> Add CONFIGURE_DISABLE_SMP_CONFIGURATION to all test which would fail
>> otherwise.
>>
>>
> I think adding a comment to the test explaining the reason would be good
> to have.
>

This is a new issue and not a 4.12 release blocker from my point of view:

https://devel.rtems.org/ticket/3020


This does not address Chris' question. Whether a blocker or not, it needs a
comment for each test. You can't add this patch without the comments before
or after branching.

My first thought was that your answer was comparable to "Ice cream has no
rocks."



-- 
Sebastian Huber, embedde 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: GCC 7.1 Released

2017-05-12 Thread Joel Sherrill 
On May 12, 2017 3:42 AM, "Chris Johns"  wrote:

On 12/05/2017 18:39, Sebastian Huber wrote:

> On 12/05/17 10:35, Chris Johns wrote:
>
>> On 12/05/2017 15:56, Sebastian Huber wrote:
>>
>>> On 11/05/17 17:29, Joel Sherrill wrote:
>>>
>> I talked to Joel late his time yesterday and he is reporting increased
>> code size and as a result some tests are not fitting into the target.
>> Rather than head on into the change we think it is better to step back
>> and visit it again after we have a release. What do you think?
>>
>
> A code size increase would be not an issue for me if its in the range of
> a small percent range. However, we should identify this and create a GCC
> PR.
>
> Gaisler suggested to use GCC 7.1. Did Gaisler observe some significant
> code size changes on SPARC?
>
>
Sorry I do not have any detail. I am sure Joel can provide some when he is
online and has some time.

I think all he did was build all the BSPs with tests and saw some new
failures.


21 BSPs failed to link some.test due to a memory overflow. Mix or at least
arm and 68k

4am here. I will post when i am really awake.b



Chris

___
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: [PATCH] confdefs.h: Add SMP enabled field to configuration

2017-05-12 Thread Sebastian Huber 

On 12/05/17 11:15, Joel Sherrill wrote:



On May 12, 2017 3:44 AM, "Sebastian Huber" 
> wrote:


On 12/05/17 10:39, Chris Johns wrote:

On 12/05/2017 18:11, Sebastian Huber wrote:

Do not use the processor count to determine if SMP is
enabled.  Instead
use a dedicated configuration option.  Enable SMP by
default in SMP
configurations.

Add CONFIGURE_DISABLE_SMP_CONFIGURATION to all test which
would fail
otherwise.


I think adding a comment to the test explaining the reason
would be good to have.


This is a new issue and not a 4.12 release blocker from my point
of view:

https://devel.rtems.org/ticket/3020



This does not address Chris' question. Whether a blocker or not, it 
needs a comment for each test.


Yes, see the new ticket. The question is when you add a comment.


You can't add this patch without the comments before or after branching.


I don't have time to go through 35 tests to look why they don't work in 
an SMP configuration at the moment. If we want to release 4.12 some time 
in the future we should really identify the blocking issues, otherwise 
the release will never happen.


--
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] confdefs.h: Add SMP enabled field to configuration

2017-05-12 Thread Sebastian Huber 



On 12/05/17 11:20, Sebastian Huber wrote:

On 12/05/17 11:15, Joel Sherrill wrote:



On May 12, 2017 3:44 AM, "Sebastian Huber" 
> wrote:


On 12/05/17 10:39, Chris Johns wrote:

On 12/05/2017 18:11, Sebastian Huber wrote:

Do not use the processor count to determine if SMP is
enabled.  Instead
use a dedicated configuration option.  Enable SMP by
default in SMP
configurations.

Add CONFIGURE_DISABLE_SMP_CONFIGURATION to all test which
would fail
otherwise.


I think adding a comment to the test explaining the reason
would be good to have.


This is a new issue and not a 4.12 release blocker from my point
of view:

https://devel.rtems.org/ticket/3020



This does not address Chris' question. Whether a blocker or not, it 
needs a comment for each test.


Yes, see the new ticket. The question is when you add a comment.


You can't add this patch without the comments before or after branching.


I don't have time to go through 35 tests to look why they don't work 
in an SMP configuration at the moment. If we want to release 4.12 some 
time in the future we should really identify the blocking issues, 
otherwise the release will never happen.




Maybe we should do this:

#warning "https://devel.rtems.org/ticket/3020";
#define CONFIGURE_DISABLE_SMP_CONFIGURATION

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

[PATCH] tests: CONFIGURE_DISABLE_SMP_CONFIGURATION

2017-05-12 Thread Sebastian Huber 
Mark tests that require review due to
CONFIGURE_DISABLE_SMP_CONFIGURATION.

Update #3020.
---
 testsuites/libtests/block08/system.h   | 1 +
 testsuites/libtests/cpuuse/system.h| 1 +
 testsuites/libtests/rtmonuse/system.h  | 1 +
 testsuites/libtests/termios05/init.c   | 1 +
 testsuites/psxtests/psx05/system.h | 1 +
 testsuites/sptests/sp01/system.h   | 1 +
 testsuites/sptests/sp04/system.h   | 1 +
 testsuites/sptests/sp07/system.h   | 1 +
 testsuites/sptests/sp08/init.c | 1 +
 testsuites/sptests/sp12/system.h   | 1 +
 testsuites/sptests/sp13/system.h   | 1 +
 testsuites/sptests/sp14/system.h   | 1 +
 testsuites/sptests/sp16/system.h   | 1 +
 testsuites/sptests/sp20/system.h   | 1 +
 testsuites/sptests/sp37/system.h   | 1 +
 testsuites/sptests/sp65/init.c | 1 +
 testsuites/sptests/spcbssched01/system.h   | 1 +
 testsuites/sptests/spcbssched02/system.h   | 1 +
 testsuites/sptests/spcbssched03/system.h   | 1 +
 testsuites/sptests/spedfsched01/system.h   | 1 +
 testsuites/sptests/spedfsched02/system.h   | 1 +
 testsuites/sptests/spedfsched03/system.h   | 1 +
 testsuites/sptests/spfatal29/testcase.h| 1 +
 testsuites/sptests/spfifo03/init.c | 1 +
 testsuites/sptests/spfifo05/init.c | 1 +
 testsuites/sptests/spintrcritical06/init.c | 1 +
 testsuites/sptests/spintrcritical15/init.c | 1 +
 testsuites/sptests/spmrsp01/init.c | 1 +
 testsuites/sptests/spsimplesched02/init.c  | 1 +
 testsuites/tmtests/tm04/system.h   | 1 +
 testsuites/tmtests/tm08/system.h   | 1 +
 testsuites/tmtests/tm15/system.h   | 1 +
 testsuites/tmtests/tm20/system.h   | 1 +
 testsuites/tmtests/tm22/system.h   | 1 +
 testsuites/tmtests/tm24/system.h   | 1 +
 35 files changed, 35 insertions(+)

diff --git a/testsuites/libtests/block08/system.h 
b/testsuites/libtests/block08/system.h
index f2ba2ec..5c734cd 100644
--- a/testsuites/libtests/block08/system.h
+++ b/testsuites/libtests/block08/system.h
@@ -54,6 +54,7 @@ rtems_task Init(
 
 #define CONFIGURE_EXTRA_TASK_STACKS (13 * RTEMS_MINIMUM_STACK_SIZE)
 
+#warning "https://devel.rtems.org/ticket/3020";
 #define CONFIGURE_DISABLE_SMP_CONFIGURATION
 
 #include 
diff --git a/testsuites/libtests/cpuuse/system.h 
b/testsuites/libtests/cpuuse/system.h
index 562f2db..78c2553 100644
--- a/testsuites/libtests/cpuuse/system.h
+++ b/testsuites/libtests/cpuuse/system.h
@@ -50,6 +50,7 @@ void Task_switch(
 
 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
 
+#warning "https://devel.rtems.org/ticket/3020";
 #define CONFIGURE_DISABLE_SMP_CONFIGURATION
 
 #include 
diff --git a/testsuites/libtests/rtmonuse/system.h 
b/testsuites/libtests/rtmonuse/system.h
index b7bb5f1..eb66fb1 100644
--- a/testsuites/libtests/rtmonuse/system.h
+++ b/testsuites/libtests/rtmonuse/system.h
@@ -48,6 +48,7 @@ void Get_all_counters( void );
 
 #define CONFIGURE_EXTRA_TASK_STACKS   (20 * RTEMS_MINIMUM_STACK_SIZE)
 
+#warning "https://devel.rtems.org/ticket/3020";
 #define CONFIGURE_DISABLE_SMP_CONFIGURATION
 #include 
 
diff --git a/testsuites/libtests/termios05/init.c 
b/testsuites/libtests/termios05/init.c
index e9f1531..ae72e91 100644
--- a/testsuites/libtests/termios05/init.c
+++ b/testsuites/libtests/termios05/init.c
@@ -166,6 +166,7 @@ rtems_task Init(
 
 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
 
+#warning "https://devel.rtems.org/ticket/3020";
 #define CONFIGURE_DISABLE_SMP_CONFIGURATION
 
 #define CONFIGURE_INIT
diff --git a/testsuites/psxtests/psx05/system.h 
b/testsuites/psxtests/psx05/system.h
index a3615d4..ab726ea 100644
--- a/testsuites/psxtests/psx05/system.h
+++ b/testsuites/psxtests/psx05/system.h
@@ -43,6 +43,7 @@ void *Task_3(
 
 #define CONFIGURE_POSIX_INIT_THREAD_TABLE
 
+#warning "https://devel.rtems.org/ticket/3020";
 #define CONFIGURE_DISABLE_SMP_CONFIGURATION
 
 #include 
diff --git a/testsuites/sptests/sp01/system.h b/testsuites/sptests/sp01/system.h
index 68f8277..5104327 100644
--- a/testsuites/sptests/sp01/system.h
+++ b/testsuites/sptests/sp01/system.h
@@ -31,6 +31,7 @@ rtems_task Task_1_through_3(
 #define CONFIGURE_EXTRA_TASK_STACKS (4 * RTEMS_MINIMUM_STACK_SIZE)
 #define CONFIGURE_MAXIMUM_TASKS 4
 
+#warning "https://devel.rtems.org/ticket/3020";
 #define CONFIGURE_DISABLE_SMP_CONFIGURATION
 
 #include 
diff --git a/testsuites/sptests/sp04/system.h b/testsuites/sptests/sp04/system.h
index 9606368..6aca983 100644
--- a/testsuites/sptests/sp04/system.h
+++ b/testsuites/sptests/sp04/system.h
@@ -52,6 +52,7 @@ void Task_switch(
 #define CONFIGURE_MAXIMUM_TASKS 4
 #define CONFIGURE_MAXIMUM_TIMERS1
 
+#warning "https://devel.rtems.org/ticket/3020";
 #define CONFIGURE_DISABLE_SMP_CONFIGURATION
 
 #include 
diff --git a/testsuites/sptests/sp07/system.h b/testsuites/sptests/sp07/system.h
index 3f8cb26..acadd35 100644
--- a/testsuites/sptests/sp07/system.h
+++ b/test

[PATCH] Update tools to gcc 7.1.0 and binutils 2.28

2017-05-12 Thread Joel Sherrill 
---
 rtems/config/4.12/rtems-default.bset   |  4 +-
 rtems/config/tools/rtems-binutils-2.28-1.cfg   | 22 
 .../rtems-gcc-7.1.0-newlib-2.5.0.20170323-1.cfg| 64 ++
 3 files changed, 88 insertions(+), 2 deletions(-)
 create mode 100644 rtems/config/tools/rtems-binutils-2.28-1.cfg
 create mode 100644 
rtems/config/tools/rtems-gcc-7.1.0-newlib-2.5.0.20170323-1.cfg

diff --git a/rtems/config/4.12/rtems-default.bset 
b/rtems/config/4.12/rtems-default.bset
index 6253367..b12d5ab 100644
--- a/rtems/config/4.12/rtems-default.bset
+++ b/rtems/config/4.12/rtems-default.bset
@@ -10,8 +10,8 @@
 4.12/rtems-autotools
 
 devel/expat-2.1.0-1
-tools/rtems-binutils-2.27-1
-tools/rtems-gcc-6.3.0-newlib-2.5.0.20170323-1
+tools/rtems-binutils-2.26-1
+tools/rtems-gcc-7.1.0-newlib-2.5.0.20170323-1
 tools/rtems-gdb-7.12-1
 tools/rtems-tools-4.12-1
 tools/rtems-kernel-4.12
diff --git a/rtems/config/tools/rtems-binutils-2.28-1.cfg 
b/rtems/config/tools/rtems-binutils-2.28-1.cfg
new file mode 100644
index 000..d1b7a11
--- /dev/null
+++ b/rtems/config/tools/rtems-binutils-2.28-1.cfg
@@ -0,0 +1,22 @@
+#
+# Binutils 2.28.
+#
+
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define binutils_version 2.28
+
+%hash sha512 binutils-%{binutils_version}.tar.bz2 
ede2e4e59a800260eea8c14eafbaee94e30abadafd5c419a3370f9f62213cf027d6400a1d4970b6958bd4d220e675dcd483a708107016e7abd5c99d7392ba8fd
+
+#
+# Enable deterministic archives by default. This will be the default
+# there all tools using this binutils will create deterministic
+# archives.
+#
+%define with_deterministic_archives 1
+
+#
+# The binutils build instructions. We use 2.xx Release 1.
+#
+%include %{_configdir}/binutils-2-1.cfg
diff --git a/rtems/config/tools/rtems-gcc-7.1.0-newlib-2.5.0.20170323-1.cfg 
b/rtems/config/tools/rtems-gcc-7.1.0-newlib-2.5.0.20170323-1.cfg
new file mode 100644
index 000..b79dd12
--- /dev/null
+++ b/rtems/config/tools/rtems-gcc-7.1.0-newlib-2.5.0.20170323-1.cfg
@@ -0,0 +1,64 @@
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define gcc_version7.1.0
+%define newlib_version 2.5.0.20170323
+%define mpfr_version   3.1.5
+%define mpc_version1.0.3
+# %define gmp_version6.1.2
+# %define mpfr_version   2.4.2
+#%define mpc_version0.8.1
+%define gmp_version4.3.2
+
+%hash sha512 gcc-7.1.0.tar.bz2 
b5d952be9a10f0e0926bb2868877d10544039d6d2f35ba0a08f51231dd622a007650764a03e173194701467547789ad7d2d9cbc10adcdf118d619cdedbd14aec
+%hash sha512 newlib-2.5.0.20170323.tar.gz 
323992603f994e82d1b8117da39ce08f8a6584330606e2d053ccefc62fce5682ac47f983aa3bc526c85bcabbcfce85cf607b08f87c5435d00cec6727c006f6b7
+%hash sha512 mpfr-3.1.5.tar.bz2 
ebf94f49e1f850db6304eec8bf3cbf592b9fb06b743e0a99a660edae3c086aa47cdd089ea958fd4631ff02a444ec034b5e45d7e9701704d74c2e2d49021e49a7
+%hash sha512 mpc-1.0.3.tar.gz 
0028b76df130720c1fad7de937a0d041224806ce5ef76589f19c7b49d956071a683e2f20d154c192a231e69756b19e48208f2889b0c13950ceb7b3cfaf059a43
+# %hash sha512 gmp-6.1.2.tar.bz2 
268db88447174617f5746d9a6ba2b105940cc1a5e73155eb23b6eedf55f8e7724eda05d161b2de19aca9e794956d226ba9ed6f23124c7c82f7e1872e32b003cf
+# %hash sha512 mpfr-2.4.2.tar.bz2 
c004b3dbf86c04960e4a1f8db37a409a7cc4cb76135e76e98dcc5ad93aaa8deb62334ee13ff84447a7c12a5e8cb57f25c62ac908c24920f1fb1a38d79d4a4c5e
+%hash sha512 mpc-0.8.1.tar.gz 
14cb9ae3d33caed24d5ae648eed28b2e00ad047a8baeff25981129af88245b4def2948573d7a00d65c5bd34e53524aa6a7351b76703c9f888b41830c1a1daae2
+%hash sha512 gmp-4.3.2.tar.bz2 
2e0b0fd23e6f10742a5517981e5171c6e88b0a93c83da701b296f5c0861d72c19782daab589a7eac3f9032152a0fc7eff7f5362db8fccc4859564a9aa82329cf
+
+
+%patch add newlib -p1 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=patch;h=f70d9ae6adc6ed7952806056349ba9f8ba3c65c8
+%patch add newlib -p1 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=patch;h=086730fb14c1c4171764e605d7510e33f0fc34ed
+%patch add newlib -p1 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=patch;h=e0dabc0e8dd6d9e2a21ceef124a1e4bf9f3d8aa3
+%patch add newlib -p1 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=patch;h=84a6dba57ed351a275889a3e8c87f566e3b3e508
+%patch add newlib -p1 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=patch;h=81c121c48739df247ade660659cd6672a9a2c7dd
+%patch add newlib -p1 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=patch;h=e1563a05b714f42502496466f12df7b461f40dd1
+%patch add newlib -p1 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=patch;h=7b07f11b1fc79224afaa8967a356796610bf82bf
+%patch add newlib -p1 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=patch;h=3abc66ec6bf8c4312da413a62a5740a33edccaad
+%patch add newlib -p1 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=patch;h=d3e919b42a26c14d47f668397519f455807dd613
+%patch add newlib -p1 
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=patch;h=a36e348a9f6d8ec690b827a3ea2e0ef

BSP Build Report

2017-05-12 Thread Joel Sherrill 
Hi

I sent my patch updating the tools to gcc 7.1 and binutils 2.28.
Unfortunately, 49 BSPs which used to build all tests with old networking
enabled now fail to completely even with networking off. Basically 48 BSPs
have one or more test which fails to link due to not fitting in memory.
Moxie has a different test issue.

I have not investigated a lot but am suspicious that Chris' recent changes
for parallelizing the test builds caused this. Some of the tests are
failing to link by ~100K or more which sounds like they should have been on
that BSPs exclude list. So maybe the exclude list isn't being honored at
all and it isn't a GCC 7.1 issue.

I spot checked simsh4 and one of the link failures is a test which is
supposed
to be excluded. Without checking, I know that moxieseim excludes the dl
tests.
So I think that confirms that we have a build system issue and not likely
any gcc 7.1 issues.


Here is the summary:

arm-atsamv - 1+ test too large
arm-lm3s3749 - 1+ test too large
arm-lm3s6965 - 1+ test too large
arm-lm4f120 - 1+ test too large
arm-lpc1768_mbed_ahb_ram_eth - 1+ test too large
arm-lpc1768_mbed_ahb_ram - 1+ test too large
arm-lpc1768_mbed - 1+ test too large
arm-lpc17xx_ea_rom_int - 1+ test too large
arm-lpc17xx_plx800_rom_int - 1+ test too large
arm-lpc2362 - 1+ test too large
arm-lpc23xx_tli800 - 1+ test too large
arm-lpc24xx_ncs_rom_int - 1+ test too large
arm-lpc24xx_plx800_rom_int - 1+ test too large
arm-lpc32xx_mzx_stage_1 - 1+ test too large
arm-lpc40xx_ea_rom_int - 1+ test too large
arm-rtl22xx - 1+ test too large
arm-rtl22xx_t - 1+ test too large
arm-stm32f105rc - 1+ test too large
arm-stm32f4 - 1+ test too large
arm-tms570ls3137_hdk_intram - 1+ test too large
arm-tms570ls3137_hdk - 1+ test too large
arm-tms570ls3137_hdk_with_loader - 1+ test too large
m32c-m32csim - 1+ test too large
m68k-mcf5206elite - 1+ test too large
m68k-mcf52235 - 1+ test too large
m68k-mcf5225x - 1+ test too large
m68k-mrm332 - 1+ test too large
mips-hurricane - 1+ test too large
mips-rbtx4925 - 1+ test too large
mips-rbtx4938 - 1+ test too large
moxie-moxiesim - dl tests unknown machine type
powerpc-gwlcfm - 1+ test too large
powerpc-mpc5566evb - 1+ test too large
powerpc-mpc5566evb_spe - 1+ test too large
powerpc-mpc5643l_dpu - 1+ test too large
powerpc-mpc5643l_evb - 1+ test too large
powerpc-mpc5668g - 1+ test too large
powerpc-mpc5674f_ecu508_app - 1+ test too large
powerpc-mpc5674f_ecu508_boot - 1+ test too large
powerpc-mpc5674fevb - 1+ test too large
powerpc-mpc5674fevb_spe - 1+ test too large
powerpc-mpc5674f_rsm6 - 1+ test too large
powerpc-phycore_mpc5554 - 1+ test too large
sh-gensh1 - 1+ test too large
sh-gensh2 - 1+ test too large
sh-simsh1 - 1+ test too large
sh-simsh2e - 1+ test too large
sh-simsh2 - 1+ test too large
sh-simsh4 - 1+ test too large

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

Re: suggested changes and bug fixes for RTEMS

2017-05-12 Thread Gedare Bloom 
Thank you Phong,

As noted by Sebastian on Trac, please use your name and real email
address in your git configuration. We need this to track the
authorship of code.

After passing review etc, the patches will be merged into rtems and be
immediately available via git-pull. We are approaching the 4.12
release, so getting these patches into shape and merging should get
your changes into 4.12 and give you a reasonably stable development
point for products.

Gedare

On Thu, May 11, 2017 at 8:02 PM, Pham, Phong  wrote:
>
> Hi Gedare,
>
> Enclosed are your requests for items 1-3.  I logged a ticket for item 4 but 
> feel free to postpone or close the ticket.  Just curious, in general when 
> will the committed changes (after sending you the patch like above) be 
> available for someone to git clone the latest rtems tree?
>
> Phong.
>
> -Original Message-
> From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf Of 
> Gedare Bloom
> Sent: Tuesday, May 09, 2017 12:26 PM
> To: Pham, Phong
> Cc: devel@rtems.org
> Subject: Re: suggested changes and bug fixes for RTEMS
>
> On Tue, May 9, 2017 at 12:16 PM, Pham, Phong  wrote:
>>
>>
>> Hi RTEMS Maintainers,
>>
>>
>>
>> Pls. let me know which of these item # changes below (or delta within
>> a given item #) you do not wish to accommodate in the main line so
>> that I will provide it as part of my BSP.  I am porting RTEMS to IBM
>> PowerPC 750 chip; very similar to MPC750 but there are minute differences.
>>
>>
>>
>> 1)  Bug: In
>> rtems\c\src\lib\libbsp\shared\src\irq-generic.c:bsp_interrupt_allocate_handler_index().
>> See attachment irq-generic.c vs. irq-generic.c.orig
>>
> Please open a ticket on our Trac and attach a git-commit patch there or here, 
> with "Close #." in the commit message. You can see the git-log for 
> examples of how to format the commit message.
>
>>
>>
>> 2)  Enhancement: Add support for IBM PowerPC 750 chip in
>> rtems\c\src\lib\libcpu\powerpc\shared\include\cpuIdent.[c,h] and
>> rtems\c\src\lib\libcpu\powerpc\new-exceptions\bspsupport\ppc_exc_categ
>> ories.c
>>
> Should be fine.
>
>>
>>
>> 3)  Bug: Missing a couple registers when DLAB is 1 in
>> rtems\c\src\libchip\serial\ns16550_p.h.  Also add a #ifndef ASM around
>> libchip/serial.h inclusion.
>>
> Ditto on Trac.
>
>>
>>
>> 4)  Suggestion: In pci.h, there are references to BSP_pci_configuration
>> data structure which is in pci.c.  However, in this file, there are
>> also references to detect_host_bridge () in detect_raven_bridge.c.
>> For folks that are just interested in pci_read_config_dword() + its
>> brothers, all they need is to include pci.h and content for where
>> BSP_pci_configuration is defined.  The rest of the stuff in pci.c
>> should be separate.  Or in another word, data structures and #defines
>> involving with BSP_pci_configuration needs to be in separate files
>> rather all stuffed in pci.c
>>
> Refactoring pci.c is acceptable.
>
>>
>>
>> 5)  rtems\c\src\lib\libcpu\powerpc\mpc6xx\mmu\pte121.c:triv121PgTblMap()
>> implementation only map virtual address to be the same as physical
>> address for a given address range (start + numPages).  It also assume
>> an increment of page size for a given address range.  I suggest that
>> an argument of
>> triv121PgTblMap() is needed to specify the physical address to be
>> mapped to for a given range of addresses.  Also another parameter is
>> whether or not to increment PhysAddr for each page.  Enclosed in
>> pte121.c is an implementation of triv121PgTblMapPhysAddr() where a
>> physical address is provided and it is hard coded not to increase the 
>> physical address for a given address range.
>> So APIs are needed for these requests.  Don’t know if and how much you
>> want to support me.  If not, I’ll just add whatever you’re not
>> supporting in my BSP.
>>
> RTEMS does not have support for a non-identity mapping of virtual-physical 
> memory. It is not clear that a non-identity mapping will work correctly, 
> although I see no reason why it would not. You are welcome to 
> suggest/implement improvements in this space. We have investigated some 
> efforts to create BSP level memory management, see the ARM bsps for some 
> ideas, and there are previous attempts to create APIs for memory 
> management/protection, but nothing that has been mergeable. 
> https://devel.rtems.org/wiki/Projects/MMU_Support
>
>>
>>
>> Thanks,
>>
>> Phong.
>>
>>
>>
>> PS: There are a couple more items but the first five should get things
>> rolling.
>>
>> Notice: This e-mail and any files transmitted with it may contain Data
>> Device Corporation's privileged and proprietary information. It is
>> intended solely for the use of the individual or entity to whom it is
>> addressed. If you are not the named recipient of this transmission,
>> any disclosure, copying, distribution or reliance on the contents of
>> this message is prohibited. If you received this e-mail in error,
>> please destroy it and any attached files

Re: Patch for ticket #2990

2017-05-12 Thread Gedare Bloom 
Hi Linda,

Thanks for your contribution. Your patch got merged, but there still
appears to be a problem with the patch it applies to fix the original
build error: https://devel.rtems.org/ticket/2990

On Fri, Apr 21, 2017 at 6:38 AM, Linda Huxley  wrote:
> Here is the patch requested by Chris.  (Hopefully you can use this patch.  I
> really don't know what I'm doing.)
>
> Regards,
>
> Linda
>
>
> ___
> 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: [PATCH 00/32] LEON

2017-05-12 Thread Daniel Hellstrom 

Hi Joel,

I have run the rtems-testsuite different configurations including SMP 
and non-smp with/without driver manager enabled. There are a couple 5-10 
failures since before, where 5 stems from known problem related to our 
toolchain config.
We use a our own scripted test environment so I haven't tested Chris BSP 
tester. Daniel Cederman added recently to our internal Jenkins test 
system that the RTEMS test-suite is run on TSIM when committing to our 
git repository, which is looking really good. This is very promising 
going forward.


I'm away all next week. So if it is okay I will push them on Sunday 
instead? but not patch 32 which had comments of course.


Regards,
Daniel

On 2017-05-11 17:32, Joel Sherrill wrote:
If this touches nothing but LEON BSP code and you have tested it, then 
I am ok with it assuming it has been adequately tested and doesn't 
introduce warnings.


Did you build smp and uniprocessor?

Have you run Chris' BSP tester?

Answer yes to all and give until Monday (to give weekend for comments) 
and then push them. IMO


--joel

On May 11, 2017 9:26 AM, "Daniel Hellstrom" > wrote:


The third set of patches for LEON. In short it contains:
 * GRCAN API changed from I/O system to C functions API, better
error handling,
   other improvements and SMP support.
 * GRETH ethernet reset/autonegotiation improvements for GR740
 * Possible to have LEON3 SMP kernel to boot on other than CPU0.
 * SMP support and warnings fixes in: GRTC, GRTM, PCI peripherals,
   GR1553BM & BC. Still need to update GRSPW and GR1553RT.
 * Removed old unused APBUART RAW driver to reduce code duplication.
 * Patches to make RTEMS build using LLVM Clang for sparc.

Best Regards,
Daniel Hellstrom


---

 c/src/lib/libbsp/sparc/Makefile.am |   1 -
 c/src/lib/libbsp/sparc/leon2/Makefile.am   |   1 -
 c/src/lib/libbsp/sparc/leon3/Makefile.am   |   3 +-
 .../libbsp/sparc/leon3/console/printk_support.c|  34 +-
 c/src/lib/libbsp/sparc/leon3/include/leon.h|   2 +-
 c/src/lib/libbsp/sparc/leon3/startup/bspstart.c|   5 +
 c/src/lib/libbsp/sparc/shared/1553/gr1553bc.c  | 123 +-
 c/src/lib/libbsp/sparc/shared/1553/gr1553bm.c  |  53 +-
 c/src/lib/libbsp/sparc/shared/amba/ahbstat.c   |   4 +-
 c/src/lib/libbsp/sparc/shared/can/grcan.c  | 2206
+++-
 c/src/lib/libbsp/sparc/shared/include/apbuart.h|  33 -
 c/src/lib/libbsp/sparc/shared/include/genirq.h |  47 +-
 c/src/lib/libbsp/sparc/shared/include/grcan.h  | 268 ++-
 c/src/lib/libbsp/sparc/shared/include/greth.h  |  11 +
 c/src/lib/libbsp/sparc/shared/irq/genirq.c |  58 +-
 c/src/lib/libbsp/sparc/shared/irq/irq-shared.c |  11 +-
 c/src/lib/libbsp/sparc/shared/irq_asm.S|  12 +-
 c/src/lib/libbsp/sparc/shared/net/greth.c  | 134 +-
 c/src/lib/libbsp/sparc/shared/pci/gr_701.c |  67 +-
 c/src/lib/libbsp/sparc/shared/pci/gr_cpci_gr740.c  |  76 +-
 c/src/lib/libbsp/sparc/shared/pci/gr_leon4_n2x.c   |  66 +-
 .../lib/libbsp/sparc/shared/pci/gr_rasta_adcdac.c  |  68 +-
 c/src/lib/libbsp/sparc/shared/pci/gr_rasta_io.c|  68 +-
 .../libbsp/sparc/shared/pci/gr_rasta_spw_router.c  |  66 +-
 c/src/lib/libbsp/sparc/shared/pci/gr_rasta_tmtc.c  |  68 +-
 c/src/lib/libbsp/sparc/shared/pci/gr_tmtc_1553.c   |  75 +-
 c/src/lib/libbsp/sparc/shared/start/start.S|  20 +-
 c/src/lib/libbsp/sparc/shared/tmtc/grtc.c  | 135 +-
 c/src/lib/libbsp/sparc/shared/tmtc/grtm.c  | 198 +-
 c/src/lib/libbsp/sparc/shared/uart/apbuart.c   | 897 
 c/src/lib/libbsp/sparc/shared/uart/apbuart_cons.c  |   8 +-
 c/src/lib/libcpu/sparc/access/access.S |   6 +-
 c/src/lib/libcpu/sparc/reg_win/window.S|   2 +-
 c/src/lib/libcpu/sparc/syscall/syscall.S   |   2 +-
 cpukit/score/include/rtems/score/threadqimpl.h |   4 +-
 35 files changed, 2382 insertions(+), 2450 deletions(-)

--
2.7.4
___
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: suggested changes and bug fixes for RTEMS

2017-05-12 Thread Pham, Phong 

Hi Gedare,

" your name and real email address"
I updated the respective tickets with patches for correct name & email addr.

"... will be merged into rtems and be immediately available via git-pull..."
I hope I would receive an email on a given ticket saying the code has been 
merged for that ticket instead of constantly git-pulling main line code?

Phong.

-Original Message-
From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf Of Gedare 
Bloom
Sent: Friday, May 12, 2017 8:21 AM
To: Pham, Phong
Cc: devel@rtems.org; Hillman, Robert
Subject: Re: suggested changes and bug fixes for RTEMS

Thank you Phong,

As noted by Sebastian on Trac, please use your name and real email address in 
your git configuration. We need this to track the authorship of code.

After passing review etc, the patches will be merged into rtems and be 
immediately available via git-pull. We are approaching the 4.12 release, so 
getting these patches into shape and merging should get your changes into 4.12 
and give you a reasonably stable development point for products.

Gedare

On Thu, May 11, 2017 at 8:02 PM, Pham, Phong  wrote:
>
> Hi Gedare,
>
> Enclosed are your requests for items 1-3.  I logged a ticket for item 4 but 
> feel free to postpone or close the ticket.  Just curious, in general when 
> will the committed changes (after sending you the patch like above) be 
> available for someone to git clone the latest rtems tree?
>
> Phong.
>
> -Original Message-
> From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf
> Of Gedare Bloom
> Sent: Tuesday, May 09, 2017 12:26 PM
> To: Pham, Phong
> Cc: devel@rtems.org
> Subject: Re: suggested changes and bug fixes for RTEMS
>
> On Tue, May 9, 2017 at 12:16 PM, Pham, Phong  wrote:
>>
>>
>> Hi RTEMS Maintainers,
>>
>>
>>
>> Pls. let me know which of these item # changes below (or delta within
>> a given item #) you do not wish to accommodate in the main line so
>> that I will provide it as part of my BSP.  I am porting RTEMS to IBM
>> PowerPC 750 chip; very similar to MPC750 but there are minute differences.
>>
>>
>>
>> 1)  Bug: In
>> rtems\c\src\lib\libbsp\shared\src\irq-generic.c:bsp_interrupt_allocate_handler_index().
>> See attachment irq-generic.c vs. irq-generic.c.orig
>>
> Please open a ticket on our Trac and attach a git-commit patch there or here, 
> with "Close #." in the commit message. You can see the git-log for 
> examples of how to format the commit message.
>
>>
>>
>> 2)  Enhancement: Add support for IBM PowerPC 750 chip in
>> rtems\c\src\lib\libcpu\powerpc\shared\include\cpuIdent.[c,h] and
>> rtems\c\src\lib\libcpu\powerpc\new-exceptions\bspsupport\ppc_exc_cate
>> g
>> ories.c
>>
> Should be fine.
>
>>
>>
>> 3)  Bug: Missing a couple registers when DLAB is 1 in
>> rtems\c\src\libchip\serial\ns16550_p.h.  Also add a #ifndef ASM
>> around libchip/serial.h inclusion.
>>
> Ditto on Trac.
>
>>
>>
>> 4)  Suggestion: In pci.h, there are references to BSP_pci_configuration
>> data structure which is in pci.c.  However, in this file, there are
>> also references to detect_host_bridge () in detect_raven_bridge.c.
>> For folks that are just interested in pci_read_config_dword() + its
>> brothers, all they need is to include pci.h and content for where
>> BSP_pci_configuration is defined.  The rest of the stuff in pci.c
>> should be separate.  Or in another word, data structures and #defines
>> involving with BSP_pci_configuration needs to be in separate files
>> rather all stuffed in pci.c
>>
> Refactoring pci.c is acceptable.
>
>>
>>
>> 5)  rtems\c\src\lib\libcpu\powerpc\mpc6xx\mmu\pte121.c:triv121PgTblMap()
>> implementation only map virtual address to be the same as physical
>> address for a given address range (start + numPages).  It also assume
>> an increment of page size for a given address range.  I suggest that
>> an argument of
>> triv121PgTblMap() is needed to specify the physical address to be
>> mapped to for a given range of addresses.  Also another parameter is
>> whether or not to increment PhysAddr for each page.  Enclosed in
>> pte121.c is an implementation of triv121PgTblMapPhysAddr() where a
>> physical address is provided and it is hard coded not to increase the 
>> physical address for a given address range.
>> So APIs are needed for these requests.  Don’t know if and how much
>> you want to support me.  If not, I’ll just add whatever you’re not
>> supporting in my BSP.
>>
> RTEMS does not have support for a non-identity mapping of
> virtual-physical memory. It is not clear that a non-identity mapping
> will work correctly, although I see no reason why it would not. You
> are welcome to suggest/implement improvements in this space. We have
> investigated some efforts to create BSP level memory management, see
> the ARM bsps for some ideas, and there are previous attempts to create
> APIs for memory management/protection, but nothing that has been
> mergeable. https://devel.rtems.org/wiki/Proje

RE: suggested changes and bug fixes for RTEMS

2017-05-12 Thread Joel Sherrill 
On May 12, 2017 1:51 PM, "Pham, Phong"  wrote:


Hi Gedare,

" your name and real email address"
I updated the respective tickets with patches for correct name & email addr.

"... will be merged into rtems and be immediately available via git-pull..."
I hope I would receive an email on a given ticket saying the code has been
merged for that ticket instead of constantly git-pulling main line code?


If the git log messages has a line like the following:

Closes #.

Then you should receive email automatically when the commit occurs. Trac
should also send you an email when anyone comments on the tickets.

-joel


Phong.

-Original Message-
From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf Of
Gedare Bloom
Sent: Friday, May 12, 2017 8:21 AM
To: Pham, Phong
Cc: devel@rtems.org; Hillman, Robert
Subject: Re: suggested changes and bug fixes for RTEMS

Thank you Phong,

As noted by Sebastian on Trac, please use your name and real email address
in your git configuration. We need this to track the authorship of code.

After passing review etc, the patches will be merged into rtems and be
immediately available via git-pull. We are approaching the 4.12 release, so
getting these patches into shape and merging should get your changes into
4.12 and give you a reasonably stable development point for products.

Gedare

On Thu, May 11, 2017 at 8:02 PM, Pham, Phong  wrote:
>
> Hi Gedare,
>
> Enclosed are your requests for items 1-3.  I logged a ticket for item 4
but feel free to postpone or close the ticket.  Just curious, in general
when will the committed changes (after sending you the patch like above) be
available for someone to git clone the latest rtems tree?
>
> Phong.
>
> -Original Message-
> From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf
> Of Gedare Bloom
> Sent: Tuesday, May 09, 2017 12:26 PM
> To: Pham, Phong
> Cc: devel@rtems.org
> Subject: Re: suggested changes and bug fixes for RTEMS
>
> On Tue, May 9, 2017 at 12:16 PM, Pham, Phong  wrote:
>>
>>
>> Hi RTEMS Maintainers,
>>
>>
>>
>> Pls. let me know which of these item # changes below (or delta within
>> a given item #) you do not wish to accommodate in the main line so
>> that I will provide it as part of my BSP.  I am porting RTEMS to IBM
>> PowerPC 750 chip; very similar to MPC750 but there are minute
differences.
>>
>>
>>
>> 1)  Bug: In
>> rtems\c\src\lib\libbsp\shared\src\irq-generic.c:bsp_
interrupt_allocate_handler_index().
>> See attachment irq-generic.c vs. irq-generic.c.orig
>>
> Please open a ticket on our Trac and attach a git-commit patch there or
here, with "Close #." in the commit message. You can see the git-log
for examples of how to format the commit message.
>
>>
>>
>> 2)  Enhancement: Add support for IBM PowerPC 750 chip in
>> rtems\c\src\lib\libcpu\powerpc\shared\include\cpuIdent.[c,h] and
>> rtems\c\src\lib\libcpu\powerpc\new-exceptions\bspsupport\ppc_exc_cate
>> g
>> ories.c
>>
> Should be fine.
>
>>
>>
>> 3)  Bug: Missing a couple registers when DLAB is 1 in
>> rtems\c\src\libchip\serial\ns16550_p.h.  Also add a #ifndef ASM
>> around libchip/serial.h inclusion.
>>
> Ditto on Trac.
>
>>
>>
>> 4)  Suggestion: In pci.h, there are references to
BSP_pci_configuration
>> data structure which is in pci.c.  However, in this file, there are
>> also references to detect_host_bridge () in detect_raven_bridge.c.
>> For folks that are just interested in pci_read_config_dword() + its
>> brothers, all they need is to include pci.h and content for where
>> BSP_pci_configuration is defined.  The rest of the stuff in pci.c
>> should be separate.  Or in another word, data structures and #defines
>> involving with BSP_pci_configuration needs to be in separate files
>> rather all stuffed in pci.c
>>
> Refactoring pci.c is acceptable.
>
>>
>>
>> 5)  rtems\c\src\lib\libcpu\powerpc\mpc6xx\mmu\pte121.c:
triv121PgTblMap()
>> implementation only map virtual address to be the same as physical
>> address for a given address range (start + numPages).  It also assume
>> an increment of page size for a given address range.  I suggest that
>> an argument of
>> triv121PgTblMap() is needed to specify the physical address to be
>> mapped to for a given range of addresses.  Also another parameter is
>> whether or not to increment PhysAddr for each page.  Enclosed in
>> pte121.c is an implementation of triv121PgTblMapPhysAddr() where a
>> physical address is provided and it is hard coded not to increase the
physical address for a given address range.
>> So APIs are needed for these requests.  Don’t know if and how much
>> you want to support me.  If not, I’ll just add whatever you’re not
>> supporting in my BSP.
>>
> RTEMS does not have support for a non-identity mapping of
> virtual-physical memory. It is not clear that a non-identity mapping
> will work correctly, although I see no reason why it would not. You
> are welcome to suggest/implement improvements in this space. We have
> investigat

Re: [PATCH] tests: CONFIGURE_DISABLE_SMP_CONFIGURATION

2017-05-12 Thread Chris Johns 
On 12/5/17 8:24 pm, Sebastian Huber wrote:
> Mark tests that require review due to
> CONFIGURE_DISABLE_SMP_CONFIGURATION.

If a test fails it fails. I feel the test results need to correctly
express the failures and we should not masks them in the way. I do not
agree with changes that suppress a failure.

I do not see SMP as any special over other reasons a test fails and I
hope we do not start adding them. We exclude tests from being built
because they do not fit into the target resources and that is fixed,
bounded.

The correct method to manage this is to tag the test as `expected-fail`
and let `rtems-test` manage the results. The only problem is scoping the
tags based on the type of build. I have not handled that case and it
seems from what we have discovered here I need to handle it. I will look
at the tagging format in the coming week and update the ticket once I
have something.

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

Re: BSP Build Report

2017-05-12 Thread Chris Johns 
On 13/5/17 1:14 am, Joel Sherrill wrote:
> 
> I sent my patch updating the tools to gcc 7.1 and binutils 2.28.
> Unfortunately, 49 BSPs which used to build all tests with old networking
> enabled now fail to completely even with networking off. Basically 48
> BSPs have one or more test which fails to link due to not fitting in
> memory. Moxie has a different test issue.
> 
> I have not investigated a lot but am suspicious that Chris' recent
> changes for parallelizing the test builds caused this. Some of the tests
> are failing to link by ~100K or more which sounds like they should have
> been on that BSPs exclude list. So maybe the exclude list isn't being
> honored at all and it isn't a GCC 7.1 issue.
> 

I simple way to check is to locally revert the change and see if that
fixes the problem.

> I spot checked simsh4 and one of the link failures is a test which is
> supposed
> to be excluded. Without checking, I know that moxieseim excludes the dl
> tests.
> So I think that confirms that we have a build system issue and not
> likely any gcc 7.1 issues.

Yes it would seem so.

I will take a look.

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

RE: suggested changes and bug fixes for RTEMS

2017-05-12 Thread Pham, Phong 

Hi Joel,

What I would like to know is when will the change shows up when someone typed

git clone git://git.rtems.org/rtems.git

on the command line?  Is it only showing up after 4.12 official release or 
after a week when someone performs configuration management (reviewed and 
merged to latest)?  As of now, when I perform a git clone, I don’t see my 
changes.

Phong.

From: Joel Sherrill [mailto:j...@rtems.org]
Sent: Friday, May 12, 2017 12:00 PM
To: Pham, Phong
Cc: rtems-de...@rtems.org; Hillman, Robert; Gedare Bloom
Subject: RE: suggested changes and bug fixes for RTEMS



On May 12, 2017 1:51 PM, "Pham, Phong" 
mailto:ph...@ddc-web.com>> wrote:

Hi Gedare,

" your name and real email address"
I updated the respective tickets with patches for correct name & email addr.

"... will be merged into rtems and be immediately available via git-pull..."
I hope I would receive an email on a given ticket saying the code has been 
merged for that ticket instead of constantly git-pulling main line code?

If the git log messages has a line like the following:

Closes #.

Then you should receive email automatically when the commit occurs. Trac should 
also send you an email when anyone comments on the tickets.

-joel


Phong.

-Original Message-
From: ged...@gwmail.gwu.edu 
[mailto:ged...@gwmail.gwu.edu] On Behalf Of 
Gedare Bloom
Sent: Friday, May 12, 2017 8:21 AM
To: Pham, Phong
Cc: devel@rtems.org; Hillman, Robert
Subject: Re: suggested changes and bug fixes for RTEMS

Thank you Phong,

As noted by Sebastian on Trac, please use your name and real email address in 
your git configuration. We need this to track the authorship of code.

After passing review etc, the patches will be merged into rtems and be 
immediately available via git-pull. We are approaching the 4.12 release, so 
getting these patches into shape and merging should get your changes into 4.12 
and give you a reasonably stable development point for products.

Gedare

On Thu, May 11, 2017 at 8:02 PM, Pham, Phong 
mailto:ph...@ddc-web.com>> wrote:
>
> Hi Gedare,
>
> Enclosed are your requests for items 1-3.  I logged a ticket for item 4 but 
> feel free to postpone or close the ticket.  Just curious, in general when 
> will the committed changes (after sending you the patch like above) be 
> available for someone to git clone the latest rtems tree?
>
> Phong.
>
> -Original Message-
> From: ged...@gwmail.gwu.edu 
> [mailto:ged...@gwmail.gwu.edu] On Behalf
> Of Gedare Bloom
> Sent: Tuesday, May 09, 2017 12:26 PM
> To: Pham, Phong
> Cc: devel@rtems.org
> Subject: Re: suggested changes and bug fixes for RTEMS
>
> On Tue, May 9, 2017 at 12:16 PM, Pham, Phong 
> mailto:ph...@ddc-web.com>> wrote:
>>
>>
>> Hi RTEMS Maintainers,
>>
>>
>>
>> Pls. let me know which of these item # changes below (or delta within
>> a given item #) you do not wish to accommodate in the main line so
>> that I will provide it as part of my BSP.  I am porting RTEMS to IBM
>> PowerPC 750 chip; very similar to MPC750 but there are minute differences.
>>
>>
>>
>> 1)  Bug: In
>> rtems\c\src\lib\libbsp\shared\src\irq-generic.c:bsp_interrupt_allocate_handler_index().
>> See attachment irq-generic.c vs. irq-generic.c.orig
>>
> Please open a ticket on our Trac and attach a git-commit patch there or here, 
> with "Close #." in the commit message. You can see the git-log for 
> examples of how to format the commit message.
>
>>
>>
>> 2)  Enhancement: Add support for IBM PowerPC 750 chip in
>> rtems\c\src\lib\libcpu\powerpc\shared\include\cpuIdent.[c,h] and
>> rtems\c\src\lib\libcpu\powerpc\new-exceptions\bspsupport\ppc_exc_cate
>> g
>> ories.c
>>
> Should be fine.
>
>>
>>
>> 3)  Bug: Missing a couple registers when DLAB is 1 in
>> rtems\c\src\libchip\serial\ns16550_p.h.  Also add a #ifndef ASM
>> around libchip/serial.h inclusion.
>>
> Ditto on Trac.
>
>>
>>
>> 4)  Suggestion: In pci.h, there are references to BSP_pci_configuration
>> data structure which is in pci.c.  However, in this file, there are
>> also references to detect_host_bridge () in detect_raven_bridge.c.
>> For folks that are just interested in pci_read_config_dword() + its
>> brothers, all they need is to include pci.h and content for where
>> BSP_pci_configuration is defined.  The rest of the stuff in pci.c
>> should be separate.  Or in another word, data structures and #defines
>> involving with BSP_pci_configuration needs to be in separate files
>> rather all stuffed in pci.c
>>
> Refactoring pci.c is acceptable.
>
>>
>>
>> 5)  rtems\c\src\lib\libcpu\powerpc\mpc6xx\mmu\pte121.c:triv121PgTblMap()
>> implementation only map virtual address to be the same as physical
>> address for a given address range (start + numPages).  It also assume
>> an increment of page size for a given address range.  I suggest that
>> an a

[PATCH 1/2] beagle i2c: Add beaglebone i2c driver code

2017-05-12 Thread Sichen Zhao 
From: Punit Vara 

This patch add the I2C driver code for Beaglebone Black:
- Add beagle/i2c/bbb-i2c.c  i2c driver code
- Modify include/i2c.h
- Modify beagle/Makefile.am

But i2c can not work currently
---
 c/src/lib/libbsp/arm/beagle/Makefile.am   |   4 +-
 c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c | 796 ++
 c/src/lib/libbsp/arm/beagle/include/i2c.h | 153 +-
 3 files changed, 934 insertions(+), 19 deletions(-)
 create mode 100644 c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c

diff --git a/c/src/lib/libbsp/arm/beagle/Makefile.am 
b/c/src/lib/libbsp/arm/beagle/Makefile.am
index 8bb8478..4da72bc 100644
--- a/c/src/lib/libbsp/arm/beagle/Makefile.am
+++ b/c/src/lib/libbsp/arm/beagle/Makefile.am
@@ -88,7 +88,6 @@ libbsp_a_SOURCES += ../../shared/timerstub.c
 libbsp_a_SOURCES += ../../shared/cpucounterread.c
 libbsp_a_SOURCES += ../shared/startup/bsp-start-memcpy.S
 libbsp_a_SOURCES += ../shared/arm-cp15-set-exception-handler.c
-libbsp_a_SOURCES += ../shared/arm-cp15-set-ttb-entries.c
 
 # Startup
 libbsp_a_SOURCES += startup/bspreset.c
@@ -116,6 +115,9 @@ libbsp_a_SOURCES += ../../shared/console.c \
 # I2C
 libbsp_a_SOURCES += misc/i2c.c
 
+# i2c
+libbsp_a_SOURCES += i2c/bbb-i2c.c
+
 # GPIO
 libbsp_a_SOURCES += gpio/bbb-gpio.c
 
diff --git a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c 
b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
new file mode 100644
index 000..6b790e5
--- /dev/null
+++ b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
@@ -0,0 +1,796 @@
+/**
+ * @file
+ *
+ * @ingroup arm_beagle
+ *
+ * @brief BeagleBoard I2C bus initialization and API Support.
+ */
+
+/*
+ * Copyright (c) 2016 Punit Vara 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+static bool am335x_i2c_pinmux(bbb_i2c_bus *bus)
+{
+  bool status =true;
+
+// We will check i2c_bus_id in am335x_i2c_bus_register
+// Apart from mode and pull_up register what about SCREWCTRL & RXACTIVE ??
+  if (bus->i2c_bus_id == I2C1) {
+REG(AM335X_PADCONF_BASE + AM335X_CONF_SPI0_CS0) = (BBB_MUXMODE(MODE2) | 
BBB_PU_EN);
+REG(AM335X_PADCONF_BASE + AM335X_CONF_SPI0_D1) = (BBB_MUXMODE(MODE2) | 
BBB_PU_EN);
+REG(AM335X_PADCONF_BASE + AM335X_CONF_UART1_TXD) = (BBB_MUXMODE(MODE3) | 
BBB_PU_EN);
+REG(AM335X_PADCONF_BASE + AM335X_CONF_UART1_RXD) = (BBB_MUXMODE(MODE3) | 
BBB_PU_EN);
+  } else if (bus->i2c_bus_id == I2C2) {
+REG(AM335X_PADCONF_BASE + AM335X_CONF_UART1_RTSN) = (BBB_MUXMODE(MODE3) | 
BBB_PU_EN);
+REG(AM335X_PADCONF_BASE + AM335X_CONF_UART1_CTSN) = (BBB_MUXMODE(MODE3) | 
BBB_PU_EN);
+REG(AM335X_PADCONF_BASE + AM335X_CONF_SPI0_D0) = (BBB_MUXMODE(MODE3) | 
BBB_PU_EN);
+REG(AM335X_PADCONF_BASE + AM335X_CONF_SPI0_SCLK) = (BBB_MUXMODE(MODE3) | 
BBB_PU_EN);
+  } else {
+  status = false;  
+  }
+  return status;   
+}
+*/
+
+/* ref. Table 21-4 I2C Clock Signals */
+/* 
+ For I2C1/2
+
+ Interface clock - 100MHz - CORE_LKOUTM4 / 2 - pd_per_l4ls_gclk
+
+ Functional clock - 48MHz - PER_CLKOUTM2 / 4 - pd_per_ic2_fclk
+*/
+
+/*
+static void am335x_i2c1_i2c2_module_clk_config(bbb_i2c_bus *bus)
+{
+*/
+/*0x2 = SW_WKUP : SW_WKUP: Start a software forced wake-up
+transition on the domain. */
+/*
+  REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKSTCTRL) |=
+AM335X_CM_PER_L4LS_CLKSTCTRL_CLKTRCTRL_SW_WKUP;
+  while((REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKSTCTRL) &
+AM335X_CM_PER_L4LS_CLKSTCTRL_CLKTRCTRL) !=
+AM335X_CM_PER_L4LS_CLKSTCTRL_CLKTRCTRL_SW_WKUP);
+*/
+
+/* 0x2 = ENABLE : Module is explicitly enabled. Interface clock (if not
+used for functions) may be gated according to the clock domain
+state. Functional clocks are guarantied to stay present. As long as in
+this configuration, power domain sleep transition cannot happen.*/
+ /* REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKCTRL) |=
+AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE_ENABLE;
+
+  while((REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKCTRL) &
+  AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE) != 
AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE_ENABLE);
+*/
+/*0x2 = ENABLE : Module is explicitly enabled. Interface clock (if not
+used for functions) may be gated according to the clock domain
+state. Functional clocks are guarantied to stay present. As long as in
+this configuration, power domain sleep transition cannot happen.*/
+/*
+  if (bus->i2c_bus_id == I2C1) {
+  REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C1_CLKCTRL) |=
+ AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE_ENABLE;
+
+  while(REG((AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C1_CLKCTRL) &
+ AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE) != 
AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE_ENABLE);
+  } else if (bus->i2c_bus_id == I2C2) {
+  REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C2_CLKCTRL) |=
+

[PATCH 2/2] Beagle i2c: Update Beaglebone i2c driver code

2017-05-12 Thread Sichen Zhao 
This patch modify the i2c code for Beaglebone Black based on PV works:
- bbb-i2c.c: Modify the interrupt handler, transfer funciton, read function, 
am335x_i2c_busbusy function etc. Add flush_fifo function
- include/i2c.h: Modify some macros, such as BBB_I2C_IRQ_ERROR

Now the i2c is working on Beaglebone Black, it can read the EEPROM information.
---
 c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c | 378 +++---
 c/src/lib/libbsp/arm/beagle/include/i2c.h |  11 +-
 2 files changed, 150 insertions(+), 239 deletions(-)

diff --git a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c 
b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
index 6b790e5..4d22831 100644
--- a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
+++ b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
@@ -21,88 +21,8 @@
 #include 
 #include 
 
-/*
-static bool am335x_i2c_pinmux(bbb_i2c_bus *bus)
-{
-  bool status =true;
-
-// We will check i2c_bus_id in am335x_i2c_bus_register
-// Apart from mode and pull_up register what about SCREWCTRL & RXACTIVE ??
-  if (bus->i2c_bus_id == I2C1) {
-REG(AM335X_PADCONF_BASE + AM335X_CONF_SPI0_CS0) = (BBB_MUXMODE(MODE2) | 
BBB_PU_EN);
-REG(AM335X_PADCONF_BASE + AM335X_CONF_SPI0_D1) = (BBB_MUXMODE(MODE2) | 
BBB_PU_EN);
-REG(AM335X_PADCONF_BASE + AM335X_CONF_UART1_TXD) = (BBB_MUXMODE(MODE3) | 
BBB_PU_EN);
-REG(AM335X_PADCONF_BASE + AM335X_CONF_UART1_RXD) = (BBB_MUXMODE(MODE3) | 
BBB_PU_EN);
-  } else if (bus->i2c_bus_id == I2C2) {
-REG(AM335X_PADCONF_BASE + AM335X_CONF_UART1_RTSN) = (BBB_MUXMODE(MODE3) | 
BBB_PU_EN);
-REG(AM335X_PADCONF_BASE + AM335X_CONF_UART1_CTSN) = (BBB_MUXMODE(MODE3) | 
BBB_PU_EN);
-REG(AM335X_PADCONF_BASE + AM335X_CONF_SPI0_D0) = (BBB_MUXMODE(MODE3) | 
BBB_PU_EN);
-REG(AM335X_PADCONF_BASE + AM335X_CONF_SPI0_SCLK) = (BBB_MUXMODE(MODE3) | 
BBB_PU_EN);
-  } else {
-  status = false;  
-  }
-  return status;   
-}
-*/
-
-/* ref. Table 21-4 I2C Clock Signals */
-/* 
- For I2C1/2
-
- Interface clock - 100MHz - CORE_LKOUTM4 / 2 - pd_per_l4ls_gclk
-
- Functional clock - 48MHz - PER_CLKOUTM2 / 4 - pd_per_ic2_fclk
-*/
 
-/*
-static void am335x_i2c1_i2c2_module_clk_config(bbb_i2c_bus *bus)
-{
-*/
-/*0x2 = SW_WKUP : SW_WKUP: Start a software forced wake-up
-transition on the domain. */
-/*
-  REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKSTCTRL) |=
-AM335X_CM_PER_L4LS_CLKSTCTRL_CLKTRCTRL_SW_WKUP;
-  while((REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKSTCTRL) &
-AM335X_CM_PER_L4LS_CLKSTCTRL_CLKTRCTRL) !=
-AM335X_CM_PER_L4LS_CLKSTCTRL_CLKTRCTRL_SW_WKUP);
-*/
-
-/* 0x2 = ENABLE : Module is explicitly enabled. Interface clock (if not
-used for functions) may be gated according to the clock domain
-state. Functional clocks are guarantied to stay present. As long as in
-this configuration, power domain sleep transition cannot happen.*/
- /* REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKCTRL) |=
-AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE_ENABLE;
-
-  while((REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKCTRL) &
-  AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE) != 
AM335X_CM_PER_L4LS_CLKCTRL_MODULEMODE_ENABLE);
-*/
-/*0x2 = ENABLE : Module is explicitly enabled. Interface clock (if not
-used for functions) may be gated according to the clock domain
-state. Functional clocks are guarantied to stay present. As long as in
-this configuration, power domain sleep transition cannot happen.*/
-/*
-  if (bus->i2c_bus_id == I2C1) {
-  REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C1_CLKCTRL) |=
- AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE_ENABLE;
-
-  while(REG((AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C1_CLKCTRL) &
- AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE) != 
AM335X_CM_PER_I2C1_CLKCTRL_MODULEMODE_ENABLE);
-  } else if (bus->i2c_bus_id == I2C2) {
-  REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C2_CLKCTRL) |=
- AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE_ENABLE;
-
-  while(REG((AM335X_CM_PER_ADDR + AM335X_CM_PER_I2C2_CLKCTRL) &
- AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE) != 
AM335X_CM_PER_I2C2_CLKCTRL_MODULEMODE_ENABLE);
-
-  while(!(REG(AM335X_CM_PER_ADDR + AM335X_CM_PER_L4LS_CLKSTCTRL) &
-   (AM335X_CM_PER_L4LS_CLKSTCTRL_CLKACTIVITY_L4LS_GCLK |
-AM335X_CM_PER_L4LS_CLKSTCTRL_CLKACTIVITY_I2C_FCLK)));
-
-  }
-}
-*/
+static void flush_fifo(i2c_bus *base);
 
 static void am335x_i2c0_pinmux(bbb_i2c_bus *bus)
 {
@@ -303,43 +223,59 @@ static void I2C0ModuleClkConfig(void)
CM_WKUP_I2C0_CLKCTRL_IDLEST));
 }
 
-/*
-void am335x_i2c_init(bbb_i2c_bus *bus, uint32_t input_clock)
-{
-  // am335x_i2c_pinmux()
-  // am335x_i2c1_i2c2_module_clk_config
-}
-*/
+
 
 static bool am335x_i2c_busbusy(volatile bbb_i2c_regs *regs)
 {
   bool status;
+  int stat;
+  int timeout=I2C_TIMEOUT;
+
+
+   while ((stat = readw(®s->BBB_I2C_IRQSTATUS_RAW) &
+AM335X_I2C_IRQSTATUS_RAW_BB) && timeout--) {
+
+writew(stat, ®s->BBB_I2C_IRQSTATUS);
+udelay(100