| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
* network/network.c (uti596_attach): Adjust cpp directives
and conditional braces so all cases compile.
|
|
|
|
|
|
| |
* clock/Makefile.am, console/Makefile.am, fatal/Makefile.am,
start/Makefile.am, startup/Makefile.am, timer/Makefile.am,
wrapup/Makefile.am, network/Makefile.am: Include compile.am
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* README: Updated
* console/console.c: Fix polled input.
Add support for shared printk.
Add support for more flexible polled I/O with and without termios.
I/O mode and console is selectable either from NVRAM or from
mvme167.cfg. Clean up comments.
2000-08-11 Charles-Antoine Gauthier <charles.gauthier@nrc.ca>
* startup/page_table.c (page_table_init): Reorganize NVRAM parameters.
* include/bsp.h: Reorganize NVRAM parameters.
Add support for shared printk.
* times: These are the times for the MVME167, not the MBX860-002.
2000-08-11 John Cotton <john.cotton@nrc.ca>
* network/network.c: Fix NVRAM configuration parameter
handling from previous revision.
Check J1-4, restructure NVRAM parameter handling.
2000-08-11 Charles-Antoine Gauthier <charles.gauthier@nrc.ca>
* network/network.c: Cleanup of network driver to reduce warnings.
Addition of second parameter to uti596_attach.
|
|
|
|
|
| |
removes warnings from the network.c file and has slight additions
to the configuration file to support Java.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<charles.gauthier@iit.nrc.ca>, and Darlene A. Stewart
<Darlene.Stewart@nrc.ca> to add support for a number of very
significant things:
+ BSPs for many variations on the Motorola MBX8xx board series
+ Cache Manager including initial support for m68040
and PowerPC
+ Rework of mpc8xx libcpu code so all mpc8xx CPUs now use
same code base.
+ Rework of eth_comm BSP to utiltize above.
John reports this works on the 821 and 860
|
| |
|
|
|
|
| |
adds .cvsignore.
|
| |
|
| |
|
|
Gauthier <charles.gauthier@nrc.ca>. The power supply in their
VMEbus cage died so it was submitted at this point. It passes ttcp
which is a really good sign but they would like to do more testing
and cleanup once their hardware is functional again. Please
contact them if you are interested in using or fixing this driver.
As their comments indicate, the performance is actually quite good
even at this point as indicated by the ttcp results.
Please note that this is by no means a final version. The code is still
fairly ugly, and will require some further fixing. On the bright side, what
is attached works. I finally ran the test programs successfully with
optimized code and data cache enabled:
netdemos worked, but failed on the UDP transfer (runs out of buffers).
ttcp worked, with something like 1036 KB/sec Rx, 952 KB/sec Tx.
tftp worked
|