suggested changes and bug fixes for RTEMS

Sat May 13 15:13:18 UTC 2017

On Fri, May 12, 2017 at 9:25 PM, Pham, Phong <phamp at ddc-web.com> 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:joel at rtems.org]
> Sent: Friday, May 12, 2017 12:00 PM
> To: Pham, Phong
> Cc: rtems-devel at rtems.org; Hillman, Robert; Gedare Bloom
> Subject: RE: suggested changes and bug fixes for RTEMS
>
>
>
>
>
>
>
> On May 12, 2017 1:51 PM, "Pham, Phong" <phamp at 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 #NNNN.
>
>
>
> 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: gedare at gwmail.gwu.edu [mailto:gedare at gwmail.gwu.edu] On Behalf Of
> Gedare Bloom
>
> Sent: Friday, May 12, 2017 8:21 AM
> To: Pham, Phong
>
> Cc: devel at 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 <phamp at 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: gedare at gwmail.gwu.edu [mailto:gedare at gwmail.gwu.edu] On Behalf
>> Of Gedare Bloom
>> Sent: Tuesday, May 09, 2017 12:26 PM
>> To: Pham, Phong
>> Cc: devel at rtems.org
>> Subject: Re: suggested changes and bug fixes for RTEMS
>>
>> On Tue, May 9, 2017 at 12:16 PM, Pham, Phong <phamp at 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 #xxxx." 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/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 and notify me
>>> immediately.
>>>
>> See if you can disable this notice for messages sent to the mailing list.
>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>> 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 and notify me immediately.
> 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 and notify me immediately.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
>
>
> 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 and notify me immediately.