<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On May 12, 2017 1:51 PM, "Pham, Phong" <<a href="mailto:phamp@ddc-web.com">phamp@ddc-web.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Gedare,<br>
<div class="quoted-text"><br>
" your name and real email address"<br>
</div>I updated the respective tickets with patches for correct name & email addr.<br>
<br>
"... will be merged into rtems and be immediately available via git-pull..."<br>
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?<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">If the git log messages has a line like the following:</div><div dir="auto"><br></div><div dir="auto">Closes #NNNN.</div><div dir="auto"><br></div><div dir="auto">Then you should receive email automatically when the commit occurs. Trac should also send you an email when anyone comments on the tickets.</div><div dir="auto"><br></div><div dir="auto">-joel</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="quoted-text"><br>
Phong.<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:gedare@gwmail.gwu.edu">gedare@gwmail.gwu.edu</a> [mailto:<a href="mailto:gedare@gwmail.gwu.edu">gedare@gwmail.gwu.edu</a>] On Behalf Of Gedare Bloom<br>
</div><div class="quoted-text">Sent: Friday, May 12, 2017 8:21 AM<br>
To: Pham, Phong<br>
</div><div class="elided-text">Cc: <a href="mailto:devel@rtems.org">devel@rtems.org</a>; Hillman, Robert<br>
Subject: Re: suggested changes and bug fixes for RTEMS<br>
<br>
Thank you Phong,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Gedare<br>
<br>
On Thu, May 11, 2017 at 8:02 PM, Pham, Phong <<a href="mailto:phamp@ddc-web.com">phamp@ddc-web.com</a>> wrote:<br>
><br>
> Hi Gedare,<br>
><br>
> 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?<br>
><br>
> Phong.<br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:gedare@gwmail.gwu.edu">gedare@gwmail.gwu.edu</a> [mailto:<a href="mailto:gedare@gwmail.gwu.edu">gedare@gwmail.gwu.edu</a>] On Behalf<br>
> Of Gedare Bloom<br>
> Sent: Tuesday, May 09, 2017 12:26 PM<br>
> To: Pham, Phong<br>
> Cc: <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> Subject: Re: suggested changes and bug fixes for RTEMS<br>
><br>
> On Tue, May 9, 2017 at 12:16 PM, Pham, Phong <<a href="mailto:phamp@ddc-web.com">phamp@ddc-web.com</a>> wrote:<br>
>><br>
>><br>
>> Hi RTEMS Maintainers,<br>
>><br>
>><br>
>><br>
>> Pls. let me know which of these item # changes below (or delta within<br>
>> a given item #) you do not wish to accommodate in the main line so<br>
>> that I will provide it as part of my BSP.  I am porting RTEMS to IBM<br>
>> PowerPC 750 chip; very similar to MPC750 but there are minute differences.<br>
>><br>
>><br>
>><br>
>> 1)      Bug: In<br>
>> rtems\c\src\lib\libbsp\shared\<wbr>src\irq-generic.c:bsp_<wbr>interrupt_allocate_handler_<wbr>index().<br>
>> See attachment irq-generic.c vs. irq-generic.c.orig<br>
>><br>
> 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.<br>
><br>
>><br>
>><br>
>> 2)      Enhancement: Add support for IBM PowerPC 750 chip in<br>
>> rtems\c\src\lib\libcpu\<wbr>powerpc\shared\include\<wbr>cpuIdent.[c,h] and<br>
>> rtems\c\src\lib\libcpu\<wbr>powerpc\new-exceptions\<wbr>bspsupport\ppc_exc_cate<br>
>> g<br>
>> ories.c<br>
>><br>
> Should be fine.<br>
><br>
>><br>
>><br>
>> 3)      Bug: Missing a couple registers when DLAB is 1 in<br>
>> rtems\c\src\libchip\serial\<wbr>ns16550_p.h.  Also add a #ifndef ASM<br>
>> around libchip/serial.h inclusion.<br>
>><br>
> Ditto on Trac.<br>
><br>
>><br>
>><br>
>> 4)      Suggestion: In pci.h, there are references to BSP_pci_configuration<br>
>> data structure which is in pci.c.  However, in this file, there are<br>
>> also references to detect_host_bridge () in detect_raven_bridge.c.<br>
>> For folks that are just interested in pci_read_config_dword() + its<br>
>> brothers, all they need is to include pci.h and content for where<br>
>> BSP_pci_configuration is defined.  The rest of the stuff in pci.c<br>
>> should be separate.  Or in another word, data structures and #defines<br>
>> involving with BSP_pci_configuration needs to be in separate files<br>
>> rather all stuffed in pci.c<br>
>><br>
> Refactoring pci.c is acceptable.<br>
><br>
>><br>
>><br>
>> 5)      rtems\c\src\lib\libcpu\<wbr>powerpc\mpc6xx\mmu\pte121.c:<wbr>triv121PgTblMap()<br>
>> implementation only map virtual address to be the same as physical<br>
>> address for a given address range (start + numPages).  It also assume<br>
>> an increment of page size for a given address range.  I suggest that<br>
>> an argument of<br>
>> triv121PgTblMap() is needed to specify the physical address to be<br>
>> mapped to for a given range of addresses.  Also another parameter is<br>
>> whether or not to increment PhysAddr for each page.  Enclosed in<br>
>> pte121.c is an implementation of triv121PgTblMapPhysAddr() where a<br>
>> physical address is provided and it is hard coded not to increase the physical address for a given address range.<br>
>> So APIs are needed for these requests.  Don’t know if and how much<br>
>> you want to support me.  If not, I’ll just add whatever you’re not<br>
>> supporting in my BSP.<br>
>><br>
> RTEMS does not have support for a non-identity mapping of<br>
> virtual-physical memory. It is not clear that a non-identity mapping<br>
> will work correctly, although I see no reason why it would not. You<br>
> are welcome to suggest/implement improvements in this space. We have<br>
> investigated some efforts to create BSP level memory management, see<br>
> the ARM bsps for some ideas, and there are previous attempts to create<br>
> APIs for memory management/protection, but nothing that has been<br>
> mergeable. <a href="https://devel.rtems.org/wiki/Projects/MMU_Support" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/<wbr>Projects/MMU_Support</a><br>
><br>
>><br>
>><br>
>> Thanks,<br>
>><br>
>> Phong.<br>
>><br>
>><br>
>><br>
>> PS: There are a couple more items but the first five should get<br>
>> things rolling.<br>
>><br>
>> Notice: This e-mail and any files transmitted with it may contain<br>
>> Data Device Corporation's privileged and proprietary information. It<br>
>> is intended solely for the use of the individual or entity to whom it<br>
>> is addressed. If you are not the named recipient of this<br>
>> transmission, any disclosure, copying, distribution or reliance on<br>
>> the contents of this message is prohibited. If you received this<br>
>> e-mail in error, please destroy it and any attached files and notify me immediately.<br>
>><br>
> See if you can disable this notice for messages sent to the mailing list.<br>
><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> devel mailing list<br>
>> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a><br>
> 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.<br>
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.<br>
______________________________<wbr>_________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/devel</a></div></blockquote></div><br></div></div></div>