suggested changes and bug fixes for RTEMS

[Gedare Bloom]

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