summaryrefslogtreecommitdiffstats
path: root/c/src/lib/libbsp/i386/i386ex/console (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Large patch from Erik Ivanenko <erik.ivanenko@utoronto.ca> whichJoel Sherrill1998-10-051-235/+341
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | moves pieces of the pc386 bsp up to a shared level for all i386 BSPs and modifies the i386ex BSP to use those shared pieces. Serial remote debugging is included for both targets. Erik's notes: There are several workarounds in it: 1) #define NEXT_GAS is hardcoded in pc386/start/start.s 2) #define NEXT_GAS is hardcoded in i386ex/start/start.s 3) #define NEW_GAS is hardcoded in pc386/start16.s 4) #undef __assert and redeclare _assert hardcoded in console.c for both pc386 and i386ex due to my egcs1.1b ~ newlib problem. Should have modified t-rtems.cfg ( no time ) I've tested pc386 with both video and serial consoles and GDB remote. All work fine, except that GDB acts weird. ( re: other posting) I hope this will work for you. It took quite some time to locate the autoconf error. The remainder was just grunt work. Unfortunately, I think I've unwound the removal of the IBMPCInitVideo stuff. Sorry. I REALLY can't spend more time... I've been at this conversion to 4.0 locally and updating the release since Sept. 8th, and have yet to compile my network driver.... This is as much as I can do right now. I look forward to the next patch to really test i368ex. I did make sure that the sample tests worked for pc386.
* Removed by patch from Aleksey.Joel Sherrill1998-09-211-1/+0
|
* Patch from Eric Valette <valette@crf.canon.fr> which brings the i386ex BSPJoel Sherrill1998-08-052-3/+25
| | | | inline with the new IRQ structure.
* Update from "erik.ivanenko" <erik.ivanenko@utoronto.ca>.Joel Sherrill1998-03-301-1/+1
| | | | | Also removed bsp_postdriver_hook() from every bsp possible and moved to shared version.
* updated copyright to 1998Joel Sherrill1998-02-171-1/+1
|
* Big patch form Ralf Corsepius described in this email:Joel Sherrill1998-01-301-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here is the result of my nightly work to get RTEMS_ROOT=$srcdir working with different shells and relative/absolute paths. What I did is relatively simple in principle: Instead of setting RTEMS_ROOT in configure.in and then let configure substitute @RTEMS_ROOT@ inside the Makefiles, I now let each Makefile set RTEMS_ROOT from each Makefile's @top_srcdir@ value. The difference is subtile, but with enormous side effects: - If RTEMS_ROOT is set in configure, then the same single value will be propagated to all Makefiles. This breaks using relative paths, as the relative path to the root of the source tree is used inside of all subdirectory Makefiles. - Now each Makefile.in sets RTEMS_ROOT = @top_srcdir@. top_srcdir is computed individually by configure for each single Makefile.in, hereby receiving the correct value, no matter if relative or absolute paths are used. To get this working, I needed to remove setting RTEMS_ROOT from target.cfg.in, because this overrides the value of RTEMS_ROOT from each individual Makefile. Furthermore, I removed RTEMS_CUSTOM from the Makefiles and replaced all "include $(RTEMS_CUSTOM)" directives with"include $(RTEMS_ROOT)/make/custom/$(RTEMS_BSP)". Perhaps you don't like this, but I think, to have one variable less is clearer and easier to understand than having several variables refering to the next one. I enclose a small patch to this mail, which - fixes the config.h problem (to finally clearify misunderstands) - removes assignment/subsitution of RTEMS_ROOT from configure.in - contains a workaround for the application Makefile's RTEMS_ROOT problem (reported by Eric) - removes some unused lines from the toplevel Makefile.in - removes assignment of RTEMS_ROOT from make/target.cfg.in
* Removed CONFIG_DIR and PROJECT_HOME directories.Joel Sherrill1998-01-201-1/+1
|
* Modified a lot of files to take a first cut at supporting building fromJoel Sherrill1997-12-101-1/+4
| | | | | any directory in the build tree. The only variable which must be set before the command "gmake" is invoked is RTEMS_BSP (e.g. RTEMS_BSP=erc32).
* Fixed typo in the pointer to the license terms.Joel Sherrill1997-10-081-2/+2
|
* eliminated potential for overfilling buffer on readJoel Sherrill1997-09-151-1/+0
|
* headers updated to reflect new style copyright notice as partJoel Sherrill1997-04-221-5/+5
| | | | of switching to the modified GNU GPL.
* This set of changes is the build of what was required to convert toJoel Sherrill1997-04-011-0/+57
| | | | | | | | | | | | | | | | | | | | GNU autoconf. This is the first large step in allowing an RTEMS user to perform a one-tree build (per crossgcc FAQ) including RTEMS in the build process. With this change RTEMS is configured in built in the same style as the GNU tools, yet retains the basic structure of its traditional Makefiles (ala Tony Bennett). Jiri Gaisler (jgais@wd.estec.esa.nl) deserves (and received) a big thank you for doing this. There are still issues to be resolved but as of this commit, all target which can be built on a linux host have been using a modified version of the source Jiri submitted. This source was merged and most targets built in the tree before this commit. There are some issues which remain to be resolved but they are primarily related to host OS dependencies, script issues, the use of gawk for hack_specs, and the dependence on gcc snapshots. These will be resolved.
* updated to format of 3.6.0 console driversJoel Sherrill1996-10-151-51/+111
|
* initial version from ErikJoel Sherrill1996-10-151-0/+220