[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
pc386 uart handling
- Date: Mon, 28 Sep 1998 13:22:37 -0700
- From: erik.ivanenko at utoronto.ca (erik.ivanenko)
- Subject: pc386 uart handling
VALETTE Eric wrote:
> D> So in short: I think the PCI support is appropriate for inclusion with the
> D> bare 386 configurations, but must always be configurable.
> On the other hand, AMI BIOS have PCI support as we use it for one
> of our embedded Intel board. Anyway libraries are configurable ...
If there are no objections, I will move i386/pc386/pc386dev/pcibios.c to
i386/shared/pci/pcibios.c and i386/pc386/include/pcibios.h to
i386/shared/pci/pcibios.h. The Makefile in pci will $(INSTALL) the .h file in
The library that will include the symbols from pcibios.c will be
i386/pc386/startup/startup.rel. The BSP developer will include PCI bios support
if necessary, by using the C_PIECES variable in the startup/Makefile.
eg. The C_PIECES symbol defined in i386/pc386/startup/Makefile will contain
pcibios and the i386/i386ex/startup/Makefile will not define pcibios.
I am also moving the uart and GDB specific files to i386/shared/comm from
pc386dev. ( comm referring to communications port, NOT common code. ) the
i386/shared/comm Makefile will again, $(INSTALL) the uart.h file to
$(PROJECT_INCLUDE). The symbols from comm/*.c will be placed into the
startup.rel library in each i386 based BSP that uses them, again controlled by
the C_PIECES variable in the startup/Makefile
So, i386/pc386/pc386dev will vanish.
Update i386ex console.c to use termios. ( This will be the same stuff as pc386,
but using a serial port instead of the monitor. I hope that no one wants to
move this code over to the shared area, as it will break the standards within
the source tree.)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 291 bytes
Desc: Card for Erik Ivanenko
Url : http://rtems.rtems.org/pipermail/rtems-users/attachments/19980928/d7eede1a/attachment.vcf