Re: Large number of failures on leon3

[Jiri Gaisler]

This seems to be a problem with the leon3 bsp, most of the failing tests
work fine on erc32 and leon2. This is regardless of which simulator is
used. Maybe the SMP additions to leon3 breaks something when SMP is
disabled ...? It also goes back in time - I am using git master from
early December 2016 and I see these failures there already ...

Jiri.

On 03/19/2017 02:32 PM, Joel Sherrill wrote:
> Hi
>
> I was following up on Gedare's testing and tried leon3. There
> were a surprising number of failures there with SMP disabled.
> This is testing with gdb. Does anyone else get the same 
> results with qemu or tsim?  Any idea what's broken?
>
>
> Passed:   458
> Failed:20
> Timeouts:  73
> Invalid:3
> -
> Total:554
>
> Failures:
>  cdtest.exe
>  spintrcritical20.exe
>  dl05.exe
>  spintrcritical01.exe
>  spintrcritical04.exe
>  spintrcritical10.exe
>  spintrcritical22.exe
>  sp69.exe
>  spintrcritical21.exe
>  sp11.exe
>  spintrcritical16.exe
>  spintrcritical23.exe
>  psxfile01.exe
>  spintrcritical05.exe
>  spintrcritical02.exe
>  spintrcritical08.exe
>  psxgetrusage01.exe
>  spcpucounter01.exe
>
>
>
> ___
> 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 1/5] Adding modified FREEBSD headers to sync RTEMS termios with FREEBSD

[Joel Sherrill]

On Tue, Mar 14, 2017 at 8:54 AM, Kirspel, Kevin 
wrote:

> I tested it against xilinx_zynq_a9_qemu.  I'm not sure it exists, but if
> there is a way to compile the patch against every (or most) BSP then we
> could ensure no BSP is broken.
>
>
There are scripts in rtems-testing/rtems to ease testing of a single
configuation
on all BSPs. Or a variety of configurations on a single BSP. I use them to
generate the warnings reports that I periodically announce.

I am seeing if all BSPs build now. Give me a few hours.

--joel


> Kevin Kirspel
> Electrical Engineer - Sr. Staff
> Idexx Roswell
> 235 Hembree Park Drive
> Roswell GA 30076
> Tel: (770)-510- ext. 81642
> Direct: (770)-688-1642
> Fax: (770)-510-4445
>
> -Original Message-
> From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> Sent: Tuesday, March 14, 2017 9:42 AM
> To: Kirspel, Kevin ; devel@rtems.org
> Subject: Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS
> termios with FREEBSD
>
> The patch set looks good after a rough review. I will check this in in two
> or three days if nobody objects.
>
> --
> 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: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios with FREEBSD

[Joel Sherrill]

I just built all BSPs and didn't see any failures.

Sebastian.. what was going on with the build you saw fail?

--joel

On Mon, Mar 20, 2017 at 9:19 AM, Joel Sherrill  wrote:

>
>
> On Tue, Mar 14, 2017 at 8:54 AM, Kirspel, Kevin 
> wrote:
>
>> I tested it against xilinx_zynq_a9_qemu.  I'm not sure it exists, but if
>> there is a way to compile the patch against every (or most) BSP then we
>> could ensure no BSP is broken.
>>
>>
> There are scripts in rtems-testing/rtems to ease testing of a single
> configuation
> on all BSPs. Or a variety of configurations on a single BSP. I use them to
> generate the warnings reports that I periodically announce.
>
> I am seeing if all BSPs build now. Give me a few hours.
>
> --joel
>
>
>> Kevin Kirspel
>> Electrical Engineer - Sr. Staff
>> Idexx Roswell
>> 235 Hembree Park Drive
>> Roswell GA 30076
>> Tel: (770)-510- ext. 81642
>> Direct: (770)-688-1642
>> Fax: (770)-510-4445
>>
>> -Original Message-
>> From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
>> Sent: Tuesday, March 14, 2017 9:42 AM
>> To: Kirspel, Kevin ; devel@rtems.org
>> Subject: Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS
>> termios with FREEBSD
>>
>> The patch set looks good after a rough review. I will check this in in
>> two or three days if nobody objects.
>>
>> --
>> 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: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios with FREEBSD

[Kirspel, Kevin]

I tracked the arm failure down to a header file (s3c2410.h) that contains a 
structure that has a member with the same name as a termios #define. 
Re-ordering the include file declarations in each affected C file will fix the 
problem (I’m not sure that’s the best solution but it will do for now).  I am 
going to build all the tool chains so I can check the rest of the BSPs.  
Sebastian found another issue with a SH BSP.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

From: Joel Sherrill [mailto:j...@rtems.org]
Sent: Monday, March 20, 2017 1:33 PM
To: Kirspel, Kevin 
Cc: devel@rtems.org
Subject: Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios 
with FREEBSD

I just built all BSPs and didn't see any failures.

Sebastian.. what was going on with the build you saw fail?

--joel

On Mon, Mar 20, 2017 at 9:19 AM, Joel Sherrill 
mailto:j...@rtems.org>> wrote:


On Tue, Mar 14, 2017 at 8:54 AM, Kirspel, Kevin 
mailto:kevin-kirs...@idexx.com>> wrote:
I tested it against xilinx_zynq_a9_qemu.  I'm not sure it exists, but if there 
is a way to compile the patch against every (or most) BSP then we could ensure 
no BSP is broken.

There are scripts in rtems-testing/rtems to ease testing of a single 
configuation
on all BSPs. Or a variety of configurations on a single BSP. I use them to
generate the warnings reports that I periodically announce.

I am seeing if all BSPs build now. Give me a few hours.

--joel

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

-Original Message-
From: Sebastian Huber 
[mailto:sebastian.hu...@embedded-brains.de]
Sent: Tuesday, March 14, 2017 9:42 AM
To: Kirspel, Kevin mailto:kevin-kirs...@idexx.com>>; 
devel@rtems.org
Subject: Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios 
with FREEBSD

The patch set looks good after a rough review. I will check this in in two or 
three days if nobody objects.

--
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: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios with FREEBSD

[Kirspel, Kevin]

Actually the best thing to do is change the structure member name and fix up 
any access to that member.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Kirspel, Kevin
Sent: Monday, March 20, 2017 1:50 PM
To: devel@rtems.org
Subject: RE: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios 
with FREEBSD

I tracked the arm failure down to a header file (s3c2410.h) that contains a 
structure that has a member with the same name as a termios #define. 
Re-ordering the include file declarations in each affected C file will fix the 
problem (I’m not sure that’s the best solution but it will do for now).  I am 
going to build all the tool chains so I can check the rest of the BSPs.  
Sebastian found another issue with a SH BSP.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

From: Joel Sherrill [mailto:j...@rtems.org]
Sent: Monday, March 20, 2017 1:33 PM
To: Kirspel, Kevin mailto:kevin-kirs...@idexx.com>>
Cc: devel@rtems.org
Subject: Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios 
with FREEBSD

I just built all BSPs and didn't see any failures.

Sebastian.. what was going on with the build you saw fail?

--joel

On Mon, Mar 20, 2017 at 9:19 AM, Joel Sherrill 
mailto:j...@rtems.org>> wrote:


On Tue, Mar 14, 2017 at 8:54 AM, Kirspel, Kevin 
mailto:kevin-kirs...@idexx.com>> wrote:
I tested it against xilinx_zynq_a9_qemu.  I'm not sure it exists, but if there 
is a way to compile the patch against every (or most) BSP then we could ensure 
no BSP is broken.

There are scripts in rtems-testing/rtems to ease testing of a single 
configuation
on all BSPs. Or a variety of configurations on a single BSP. I use them to
generate the warnings reports that I periodically announce.

I am seeing if all BSPs build now. Give me a few hours.

--joel

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510- ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

-Original Message-
From: Sebastian Huber 
[mailto:sebastian.hu...@embedded-brains.de]
Sent: Tuesday, March 14, 2017 9:42 AM
To: Kirspel, Kevin mailto:kevin-kirs...@idexx.com>>; 
devel@rtems.org
Subject: Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios 
with FREEBSD

The patch set looks good after a rough review. I will check this in in two or 
three days if nobody objects.

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

Fwd: GSoC 2017 Student application period is now open!

[Joel Sherrill]

Hi

Students can now begin to apply. We are looking forward to some high
quality and interesting applications. :)

--joel

-- Forwarded message --
From: 'Stephanie' via Google Summer of Code Discuss <
google-summer-of-code-disc...@googlegroups.com>
Date: Mon, Mar 20, 2017 at 1:57 PM
Subject: GSoC 2017 Student application period is now open!
To: Google Summer of Code Discuss <
google-summer-of-code-disc...@googlegroups.com>


Interested university students can now apply to be a part of Google Summer
of Code 2017.

Visit the program site, g.co/gsoc, to register and start submitting your
proposals for your summer projects to the organizations that interest you.

Be sure to read the Ideas List for each of the 201 organizations
 and reach out to the
organization early to get feedback on your proposal so that you have the
opportunity to edit it before the final deadline.

For tips on writing an excellent proposal read the short Student Manual

written by Mentors, Org Administrators and former students.

Applications close Monday, April 3 at 16:00 UTC.  All final proposals must
be submitted before the deadline to be considered by the mentor
organizations.

Good luck!

-- 
You received this message because you are subscribed to the Google Groups
"Google Summer of Code Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-summer-of-code-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to google-summer-of-code-discuss@
googlegroups.com.
Visit this group at https://groups.google.com/group/google-summer-of-code-
discuss.
For more options, visit https://groups.google.com/d/optout.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios with FREEBSD

[Joel Sherrill]

Agreed a BSP or user space code should not use the same name as
anything that is included in POSIX. :)

How did my build sweep miss this?

--joel

On Mon, Mar 20, 2017 at 1:01 PM, Kirspel, Kevin 
wrote:

> Actually the best thing to do is change the structure member name and fix
> up any access to that member.
>
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642 <(770)%20510->
>
> Direct: (770)-688-1642 <(770)%20688-1642>
>
> Fax: (770)-510-4445 <(770)%20510-4445>
>
>
>
> *From:* devel [mailto:devel-boun...@rtems.org] *On Behalf Of *Kirspel,
> Kevin
> *Sent:* Monday, March 20, 2017 1:50 PM
> *To:* devel@rtems.org
> *Subject:* RE: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS
> termios with FREEBSD
>
>
>
> I tracked the arm failure down to a header file (s3c2410.h) that contains
> a structure that has a member with the same name as a termios #define.
> Re-ordering the include file declarations in each affected C file will fix
> the problem (I’m not sure that’s the best solution but it will do for
> now).  I am going to build all the tool chains so I can check the rest of
> the BSPs.  Sebastian found another issue with a SH BSP.
>
>
>
> Kevin Kirspel
>
> Electrical Engineer - Sr. Staff
>
> Idexx Roswell
>
> 235 Hembree Park Drive
>
> Roswell GA 30076
>
> Tel: (770)-510- ext. 81642 <(770)%20510->
>
> Direct: (770)-688-1642 <(770)%20688-1642>
>
> Fax: (770)-510-4445 <(770)%20510-4445>
>
>
>
> *From:* Joel Sherrill [mailto:j...@rtems.org ]
> *Sent:* Monday, March 20, 2017 1:33 PM
> *To:* Kirspel, Kevin 
> *Cc:* devel@rtems.org
> *Subject:* Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS
> termios with FREEBSD
>
>
>
> I just built all BSPs and didn't see any failures.
>
>
>
> Sebastian.. what was going on with the build you saw fail?
>
>
>
> --joel
>
>
>
> On Mon, Mar 20, 2017 at 9:19 AM, Joel Sherrill  wrote:
>
>
>
>
>
> On Tue, Mar 14, 2017 at 8:54 AM, Kirspel, Kevin 
> wrote:
>
> I tested it against xilinx_zynq_a9_qemu.  I'm not sure it exists, but if
> there is a way to compile the patch against every (or most) BSP then we
> could ensure no BSP is broken.
>
>
>
> There are scripts in rtems-testing/rtems to ease testing of a single
> configuation
>
> on all BSPs. Or a variety of configurations on a single BSP. I use them to
>
> generate the warnings reports that I periodically announce.
>
>
>
> I am seeing if all BSPs build now. Give me a few hours.
>
>
>
> --joel
>
>
>
> Kevin Kirspel
> Electrical Engineer - Sr. Staff
> Idexx Roswell
> 235 Hembree Park Drive
> Roswell GA 30076
> Tel: (770)-510- ext. 81642
> Direct: (770)-688-1642
> Fax: (770)-510-4445
>
>
> -Original Message-
> From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> Sent: Tuesday, March 14, 2017 9:42 AM
> To: Kirspel, Kevin ; devel@rtems.org
> Subject: Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS
> termios with FREEBSD
>
> The patch set looks good after a rough review. I will check this in in two
> or three days if nobody objects.
>
> --
> 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSOC 2017 Beagleboard BSP projects

[Joel Sherrill]

On Sun, Mar 19, 2017 at 4:38 PM, Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> - Ursprüngliche Mail -
> > Von: "赵 思晨" 
> > An: "RTEMS" 
> > Gesendet: Sonntag, 19. März 2017 15:29:03
> > Betreff: GSOC 2017 Beagleboard BSP projects
>
> > Hi all:
> >
> >
> > I am interested in the ticket #2819 Beagleboard BSP projects
> >
> >
> > And i have a idea about the project: add the USB and wireless network
> card
> > driver to RTEMS. So RTEMS can apply on many scene applications such as
> the UAV.
> > And for now, i am working on transplant the USB driver from FreeBSD to
> RTEMS.
> >
> >
> >
> > I am a master student from China NanJing University. and i am interested
> in
> > applying for GSoC 2017 under RTEMS.
> > I have develop project on RTEMS for almost a year, so i am very familiar
> with
> > RTEMS development.
> >
> > For now, i have done these works on RTEMS:
> > 1.Porting the ethernet driver from FreeBSD to RTEMS on BBB bsp.
> > 2.Transplant the ION-DTN protocol stack on RTEMS.
> > 3.Took over Punitvara's(GSOC 2016 student) unfinished work on BBB i2c
> driver,
> > and can use i2c read the EEPROM info..(already send PV my pull request)
> > 4.Porting  the ethernet driver from UBoot to RTEMS on BBB bsp.
> >
> > Best Regrads
> > Sichen Zhao
> >
> >
> >
> >
> > 发自 Outlook
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> Hello Sichen Zhao,
>
> just a note regarding the WLAN support in rtems-libbsd: I have just
> recently ported a lot of the necessary kernel modules for unencrypted WLAN.
> Depending on the projects progress, It's quite possible that we (embedded
> brains) will work on encrypted WLAN too in the near future. So this might
> could collide with the goals in your proposal that relate to the hardware
> independent parts of the network stack.
>

Christian.. I appreciate you giving a heads up but isn't the work of
USB support for a BB and a specific WLAN driver for a USB WLAN stick
rather independent of adding encryption support? It would seem they
are in different areas of the tree.

I can see where he could focus on unencrypted support and then
if things work out, take advantage of the encrypted support later.
I thought the tree was already up to date so there wouldn't be any
massive updates of code.

What conflicts do you foresee? And can you work with the student
to avoid or minimize them.

Working in the open and coordinating efforts is critical in any open
source project. This seems like one which can be managed. Especially
if you help out on this project so you can help avoid the issues.

Thanks.

--joel


>

Kind regards
>
> Christian Mauderer
> --
> 
> embedded brains GmbH
> Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> 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: timeouts and failure

[Chris Johns]

On 20/03/2017 17:20, Sebastian Huber wrote:



On 18/03/17 21:52, Joel Sherrill wrote:


FWIW here are my results for sparc/erc32:

Passed:   548
Failed: 1
Timeouts:   5
Invalid:0
-
Total:554

Failures:
 spcontext01.exe


Yes, this is expected.


Timeouts:
 fileio.exe
 top.exe
 termios.exe
 capture.exe
 monitor.exe


These tests should terminate after 20 seconds or so without input. A
timeout should therefore not occur.


That is 20 seconds of target time and not real-time if running on a 
heavily loaded machine running simulators in parallel. The test tool's 
timeout is real time.


I have created https://devel.rtems.org/ticket/2946 to look into this.

Chris


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

Re: RTEMS 4.11.2 milestone date

[Chris Johns]

On 17/03/2017 12:34, Chris Johns wrote:

On 17/03/2017 10:58, Gedare Bloom wrote:

On Thu, Mar 16, 2017 at 7:52 PM, Joel Sherrill  wrote:

You couldn't build powerpc gdb because of the error symbol. There was
something


Ah yes something in the simulator is referencing a C symbol when it will
now be a C++ symbol, ie missing include somewhere. I wonder if this is a
clang vs gcc issue. This was using the latest gdb so I will see if it is
a problem with the 4.11 gdb.



This does not happen building the 4.11 tools on FreeBSD 11.0.


with max_align_t but I think that got resolved.



https://sourceware.org/bugzilla/show_bug.cgi?id=21206


Yes, and this is fixed on 4.12 (master). I may need to backport the fix.
It is isolated to FreeBSD hosts so a low impact fix.


This issue does not appear on the 4.11 branch on FreeBSD 11.0.

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

Current 4.11.2 tickets.

[Chris Johns]

Hi,

Can all developers please take a look at the 4.11.2 roadmap and the 
in-progress and new tickets and update, fix or change as appropriate.


 https://devel.rtems.org/milestone/4.11.2

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

Re: [PATCH] modify punitvara's works on BBB i2c, and now can read the eeprom info.

[Ben Gras]

Dear all,

SZ, great initiative. Gedare and Sebastian have commented.

For my part, can I just check - the implementation is supposed to be
generic to i2c devices, correct?

If so, can you explain what read_eeprom is for? Is it just as demo? Is
the code generic otherwise?

Cheers,

Ben


On 03/14/2017 10:05 AM, Sichen Zhao wrote:
> ---
>  c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c | 684 
> --
>  c/src/lib/libbsp/arm/beagle/include/i2c.h |  18 +-
>  cpukit/dev/i2c/eeprom.c   |  24 +-
>  testsuites/samples/i2c0/init.c|  98 -
>  4 files changed, 777 insertions(+), 47 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..6a22125 100644
> --- a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> +++ b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> @@ -21,11 +21,23 @@
>  #include 
>  #include 
>  
> +#define u16 unsigned int
> +
> +static int am335x_i2c_set_clock(i2c_bus *base, unsigned long clock);
> +static void omap24_i2c_init(i2c_bus *base);
> +static void flush_fifo(i2c_bus *base);
> +static int wait_for_bb(i2c_bus *base);
> +static int omap24_i2c_probe(i2c_bus *base);
> +static u16 wait_for_event(i2c_bus *base);
> +static int am335x_i2c_read(i2c_bus *base, unsigned char chip, uint addr, int 
> alen, unsigned char *buffer, 
> +   int len);
> +static int read_eeprom(i2c_bus *base,struct am335x_baseboard_id *header);
> +static int am335x_i2c_write(i2c_bus *base, unsigned char chip, uint addr,int 
> alen, unsigned char *buffer, 
> +int len);
>  /*
>  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) {
> @@ -48,9 +60,7 @@ static bool am335x_i2c_pinmux(bbb_i2c_bus *bus)
>  /* 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
>  */
>  
> @@ -74,7 +84,6 @@ 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);
>  */
> @@ -86,30 +95,29 @@ 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 am335x_i2c0_pinmux(bbb_i2c_bus *bus)
>  {
> -  REG(bus->regs + AM335X_CONF_I2C0_SDA) =
> +  printf("0x44e1 + AM335X_CONF_I2C0_SDA:%x\n",0x44e1 + 
> AM335X_CONF_I2C0_SDA);
> +  printf("bus->regs:%x\n", bus->regs);
> + 
> +  REG(0x44e1 + AM335X_CONF_I2C0_SDA) =
>(BBB_RXACTIVE | BBB_SLEWCTRL | BBB_PU_EN);
>  
> -  REG(bus->regs + AM335X_CONF_I2C0_SCL) =
> +  REG(0x44e1 + AM335X_CONF_I2C0_SCL) =
>(BBB_RXACTIVE | BBB_SLEWCTRL | BBB_PU_EN); 
>  }
>  
> @@ -314,14 +322,29 @@ void am335x_i2c_init(bbb_i2c_bus *bus, uint32_t 
> input_clock)
>  static bool am335x_i2c_busbusy(volatile bbb_i2c_regs *regs)
>  {
>bool status;
> -
> -  if (REG(®s->BBB_I2C_IRQSTATUS_RAW) & AM335X_I2C_IRQSTATUS_RAW_BB)
> +  unsigned short stat;
> +  int timeout = I2C_TIMEOUT;
> +
> +  REG(®s->BBB_I2C_IRQSTATUS)=0x;
> +  
> printf("REG(®s->BBB_I2C_IRQSTATUS_RAW):%x\n",REG(®s->BBB_I2C_IRQSTATUS_RAW)
>  );
> + // printf("%x\n",0x1400 & 0x1000 );
> + printf("REG(®s->BBB_I2C_IRQSTATUS_RAW) & 
> AM335X_I2C_IRQSTATUS_RAW_BB:%x\n",(REG(®s->BBB_I2C_IRQSTATUS_RAW) & 
> AM335X_I2C_IRQSTATUS_RAW_BB));
> +while(stat =( REG(®s->BBB_I2C_IRQSTATUS_RAW) & 
> AM335X_I2C_IRQSTATUS_RAW_BB) && timeout--)
>{
> -status = true; 
> -  } else {
> -status = false;
> +
> +REG

Re: [PATCH] modify punitvara's works on BBB i2c, and now can read theeeprom info.

[??????]

I think it can use in i2c devices, but i don't test it.
and the read_eeprom is using reading the eeprom. and i will modify it in the 
future, conform to the RTEMS code specification.
 




-- Original --
From:  "beng";;
Date:  Tue, Mar 21, 2017 12:12 PM
To:  "devel"; "??"<1473996...@qq.com>; 

Subject:  Re: [PATCH] modify punitvara's works on BBB i2c, and now can read 
theeeprom info.



Dear all,

SZ, great initiative. Gedare and Sebastian have commented.

For my part, can I just check - the implementation is supposed to be
generic to i2c devices, correct?

If so, can you explain what read_eeprom is for? Is it just as demo? Is
the code generic otherwise?

Cheers,

Ben


On 03/14/2017 10:05 AM, Sichen Zhao wrote:
> ---
>  c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c | 684 
> --
>  c/src/lib/libbsp/arm/beagle/include/i2c.h |  18 +-
>  cpukit/dev/i2c/eeprom.c   |  24 +-
>  testsuites/samples/i2c0/init.c|  98 -
>  4 files changed, 777 insertions(+), 47 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..6a22125 100644
> --- a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> +++ b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> @@ -21,11 +21,23 @@
>  #include 
>  #include 
>  
> +#define u16 unsigned int
> +
> +static int am335x_i2c_set_clock(i2c_bus *base, unsigned long clock);
> +static void omap24_i2c_init(i2c_bus *base);
> +static void flush_fifo(i2c_bus *base);
> +static int wait_for_bb(i2c_bus *base);
> +static int omap24_i2c_probe(i2c_bus *base);
> +static u16 wait_for_event(i2c_bus *base);
> +static int am335x_i2c_read(i2c_bus *base, unsigned char chip, uint addr, int 
> alen, unsigned char *buffer, 
> +   int len);
> +static int read_eeprom(i2c_bus *base,struct am335x_baseboard_id *header);
> +static int am335x_i2c_write(i2c_bus *base, unsigned char chip, uint addr,int 
> alen, unsigned char *buffer, 
> +int len);
>  /*
>  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) {
> @@ -48,9 +60,7 @@ static bool am335x_i2c_pinmux(bbb_i2c_bus *bus)
>  /* 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
>  */
>  
> @@ -74,7 +84,6 @@ 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);
>  */
> @@ -86,30 +95,29 @@ 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 am335x_i2c0_pinmux(bbb_i2c_bus *bus)
>  {
> -  REG(bus->regs + AM335X_CONF_I2C0_SDA) =
> +  printf("0x44e1 + AM335X_CONF_I2C0_SDA:%x\n",0x44e1 + 
> AM335X_CONF_I2C0_SDA);
> +  printf("bus->regs:%x\n", bus->regs);
> + 
> +  REG(0x44e1 + AM335X_CONF_I2C0_SDA) =
>(BBB_RXACTIVE | BBB_SLEWCTRL | BBB_PU_EN);
>  
> -  REG(bus->regs + AM335X_CONF_I2C0_SCL) =
> +  REG(0x44e1 + AM335X_CONF_I2C0_SCL) =
>(BBB_RXACTIVE | BBB_SLEWCTRL | BBB_PU_EN); 
>  }
>  
> @@ -314,14 +322,29 @@ void am335x_i2c_init(bbb_i2c_bus *bus, uint32_t 
> input_clock)
>  static bool am335x_i2c_busbusy(volatile bbb_i2c_regs *regs)
>  {
>bool status;
> -
> -  if (REG(®s->BBB_I2C_IRQSTATUS_RAW) & AM335X_I2C_IRQSTATUS_RAW_BB)
> +  unsigned short stat;
> +  int timeout = I2C_TIMEOUT;
> +
> +  REG(®s->BBB_I2C_IRQSTATUS)=0x;
> +  
> printf("REG(®s->BB

答复: [PATCH] modify punitvara's works on BBB i2c, and now can read the eeprom info.

[赵 思晨]

Hi all:
I think it can use in i2c devices, but i don't test it.
and the read_eeprom is using reading the eeprom. and i will modify it in the 
future, conform my code to the RTEMS code specification.


Best regrads

Sichen Zhao


发自 Outlook

发件人: devel  代表 Ben Gras 
发送时间: 2017年3月21日 12:12:42
收件人: devel@rtems.org; 1473996...@qq.com
主题: Re: [PATCH] modify punitvara's works on BBB i2c, and now can read the 
eeprom info.

Dear all,

SZ, great initiative. Gedare and Sebastian have commented.

For my part, can I just check - the implementation is supposed to be
generic to i2c devices, correct?

If so, can you explain what read_eeprom is for? Is it just as demo? Is
the code generic otherwise?

Cheers,

Ben


On 03/14/2017 10:05 AM, Sichen Zhao wrote:
> ---
>  c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c | 684 
> --
>  c/src/lib/libbsp/arm/beagle/include/i2c.h |  18 +-
>  cpukit/dev/i2c/eeprom.c   |  24 +-
>  testsuites/samples/i2c0/init.c|  98 -
>  4 files changed, 777 insertions(+), 47 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..6a22125 100644
> --- a/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> +++ b/c/src/lib/libbsp/arm/beagle/i2c/bbb-i2c.c
> @@ -21,11 +21,23 @@
>  #include 
>  #include 
>
> +#define u16 unsigned int
> +
> +static int am335x_i2c_set_clock(i2c_bus *base, unsigned long clock);
> +static void omap24_i2c_init(i2c_bus *base);
> +static void flush_fifo(i2c_bus *base);
> +static int wait_for_bb(i2c_bus *base);
> +static int omap24_i2c_probe(i2c_bus *base);
> +static u16 wait_for_event(i2c_bus *base);
> +static int am335x_i2c_read(i2c_bus *base, unsigned char chip, uint addr, int 
> alen, unsigned char *buffer,
> +   int len);
> +static int read_eeprom(i2c_bus *base,struct am335x_baseboard_id *header);
> +static int am335x_i2c_write(i2c_bus *base, unsigned char chip, uint addr,int 
> alen, unsigned char *buffer,
> +int len);
>  /*
>  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) {
> @@ -48,9 +60,7 @@ static bool am335x_i2c_pinmux(bbb_i2c_bus *bus)
>  /* 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
>  */
>
> @@ -74,7 +84,6 @@ 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);
>  */
> @@ -86,30 +95,29 @@ 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 am335x_i2c0_pinmux(bbb_i2c_bus *bus)
>  {
> -  REG(bus->regs + AM335X_CONF_I2C0_SDA) =
> +  printf("0x44e1 + AM335X_CONF_I2C0_SDA:%x\n",0x44e1 + 
> AM335X_CONF_I2C0_SDA);
> +  printf("bus->regs:%x\n", bus->regs);
> +
> +  REG(0x44e1 + AM335X_CONF_I2C0_SDA) =
>(BBB_RXACTIVE | BBB_SLEWCTRL | BBB_PU_EN);
>
> -  REG(bus->regs + AM335X_CONF_I2C0_SCL) =
> +  REG(0x44e1 + AM335X_CONF_I2C0_SCL) =
>(BBB_RXACTIVE | BBB_SLEWCTRL | BBB_PU_EN);
>  }
>
> @@ -314,14 +322,29 @@ void am335x_i2c_init(bbb_i2c_bus *bus, uint32_t 
> input_clock)
>  static bool am335x_i2c_busbusy(volatile bbb_i2c_regs *regs)
>  {
>bool status;
> -
> -  if (REG(®s->BBB_I2C_IRQSTATUS_RAW) & AM335X_I2C_IRQSTATUS_RAW_BB)
> +  unsigned short stat;
> +  int timeout = I2C_TIMEOUT;
> +
> +  REG(®s->BBB_I2C_IRQSTATU

Re: [PATCH 1/5] Adding modified FREEBSD headers to sync RTEMS termios with FREEBSD

[Sebastian Huber]

On 21/03/17 00:25, Joel Sherrill wrote:

Agreed a BSP or user space code should not use the same name as
anything that is included in POSIX. :)

How did my build sweep miss this?


You didn't apply Kevin's patches?

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