On Fri, May 12, 2017 at 9:25 PM, Pham, Phong <ph...@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: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" <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 #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: 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 <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 <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 #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@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@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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
