Re: suggested changes and bug fixes for RTEMS

2017-05-13 Thread Gedare Bloom
On Fri, May 12, 2017 at 9:25 PM, Pham, Phong  wrote:
>
>
> 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.
>
After it is reviewed and merged. You should get a CC email from Trac
when the ticket is updated/closed.

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

RE: suggested changes and bug fixes for RTEMS

2017-05-13 Thread Joel Sherrill
On May 12, 2017 8:25 PM, "Pham, Phong"  wrote:



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.


It should be days. Just a matter of review and commit. We are generally
quick.

It likely won't be me committing this round. I am dealing with a family
situation and am mostly answering from my phone.



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

Master Build Failuire

2017-05-13 Thread Joel Sherrill
Hi

Looks like no uniprocessor configurations will build

 ../rtems/configure --target=sparc-rtems4.12 --enable-rtemsbsp=leon3
--prefix=/home/joel/rtems-work/tools/4.12 --disable-networking
--enable-posix --disable-smp --disable-multiprocessing --enable-tests
--enable-cxx --enable-maintainer-mode


sparc-rtems4.12-gcc --pipe -DHAVE_CONFIG_H   -I..
-I../../cpukit/../../../leon3/lib/include   -mcpu=leon3 -msoft-float -O2 -g
-ffunction-sections -fdata-sections -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT
dummy/default-configuration.o -MD -MP -MF $depbase.Tpo -c -o
dummy/default-configuration.o ../../../../../../rtems/c/src/
../../cpukit/libmisc/dummy/default-configuration.c &&\
mv -f $depbase.Tpo $depbase.Po
In file included from ../../cpukit/../../../leon3/li
b/include/rtems/scheduler.h:143:0,
 from ../../cpukit/../../../leon3/li
b/include/rtems/confdefs.h:824,
 from ../../../../../../rtems/c/src/
../../cpukit/libmisc/dummy/default-configuration.c:111:
../../cpukit/../../../leon3/lib/include/rtems/score/schedulerprioritysmp.h:146:3:
error: unknown type name 'Thread_Scheduler_state'; did you mean
'Thread_Scheduler_control'?
   Thread_Scheduler_state   next_state
   ^~
   Thread_Scheduler_control
../../cpukit/../../../leon3/lib/include/rtems/score/schedulerprioritysmp.h:89:5:
warning: initialization from incompatible pointer type
[-Wincompatible-pointer-types]
 _Scheduler_priority_SMP_Ask_for_help, \
 ^
../../cpukit/../../../leon3/lib/include/rtems/score/schedulerprioritysmp.h:89:5:
note: in definition of macro 'SCHEDULER_PRIORITY_SMP_ENTRY_POINTS'
 _Scheduler_priority_SMP_Ask_for_help, \
 ^~~~
../../cpukit/../../../leon3/lib/include/rtems/confdefs.h:869:7: note: in
expansion of macro 'RTEMS_SCHEDULER_CONTROL_PRIORITY_SMP'
   RTEMS_SCHEDULER_CONTROL_PRIORITY_SMP(dflt, CONFIGURE_SCHEDULER_NAME)
   ^~~~

etc, etc

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

GSOC student suggestion about bug fixs

2017-05-13 Thread Sichen Zhao

Hi all,


I am GSOC 2017 student Sichen Zhao

I wanna ask whether the RTEMS-libbsd Bug is ok? And strictly speaking it's a 
suggestion not a bug.



Best Regards

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