mirror of
https://github.com/Ysurac/openmptcprouter.git
synced 2025-03-09 15:40:20 +00:00
Kernel 5.4 RUTX support
This commit is contained in:
Ycarus (Yannick Chabanois)
parent
839fcf1cab
commit
cfce9f52b2
7376 changed files with 3902 additions and 546 deletions
|
|
@ -1,136 +0,0 @@
|
|||
AMCC Ebony Board
|
||||
|
||||
Last Update: September 12, 2002
|
||||
=======================================================================
|
||||
|
||||
This file contains some handy info regarding U-Boot and the AMCC
|
||||
Ebony evaluation board. See the README.ppc440 for additional
|
||||
information.
|
||||
|
||||
|
||||
SWITCH SETTINGS & JUMPERS
|
||||
==========================
|
||||
|
||||
Here's what I've been using successfully. If you feel inclined to
|
||||
change things ... please read the docs!
|
||||
|
||||
DIPSW U46 U80
|
||||
------------------------
|
||||
SW 1 off on
|
||||
SW 2 on on
|
||||
SW 3 on on
|
||||
SW 4 off on
|
||||
SW 5 on off
|
||||
SW 6 on on
|
||||
SW 7 on off
|
||||
SW 8 on off
|
||||
|
||||
J41: strapped
|
||||
J42: open
|
||||
|
||||
All others are factory default.
|
||||
|
||||
|
||||
I2C probe
|
||||
=====================
|
||||
|
||||
The i2c utilities have been tested on both Rev B. and Rev C. and
|
||||
look good. The CONFIG_SYS_I2C_NOPROBES macro is defined to prevent
|
||||
probing the CDCV850 clock controller at address 0x69 (since reading
|
||||
it causes the i2c implementation to misbehave. The output of
|
||||
'i2c probe' should look like this (assuming you are only using a single
|
||||
SO-DIMM:
|
||||
|
||||
=> i2c probe
|
||||
Valid chip addresses: 50 53 54
|
||||
Excluded chip addresses: 69
|
||||
|
||||
|
||||
GETTING OUT OF I2C TROUBLE
|
||||
===========================
|
||||
|
||||
If you're like me ... you may have screwed up your bootstrap serial
|
||||
eeprom ... or worse, your SPD eeprom when experimenting with the
|
||||
i2c commands. If so, here are some ideas on how to get out of
|
||||
trouble:
|
||||
|
||||
Serial bootstrap eeprom corruption:
|
||||
-----------------------------------
|
||||
Power down the board and set the following straps:
|
||||
|
||||
J41 - open
|
||||
J42 - strapped
|
||||
|
||||
This will select the default sys0 and sys1 settings (the serial
|
||||
eeproms are not used). Then power up the board and fix the serial
|
||||
eeprom using the 'i2c mm' command. Here are the values I currently
|
||||
use:
|
||||
|
||||
=> i2c md 50 0 10
|
||||
0000: bf a2 04 01 ae 94 11 00 00 00 00 00 00 00 00 00 ................
|
||||
|
||||
=> i2c md 54 0 10
|
||||
0000: 8f b3 24 01 4d 14 11 00 00 00 00 00 00 00 00 00 ..$.M...........
|
||||
|
||||
Once you have the eeproms set correctly change the
|
||||
J41/J42 straps as you desire.
|
||||
|
||||
SPD eeprom corruption:
|
||||
------------------------
|
||||
I've corrupted the SPD eeprom several times ... perhaps too much coffee
|
||||
and not enough presence of mind ;-). By default, the ebony code uses
|
||||
the SPD to initialize the DDR SDRAM control registers. So if the SPD
|
||||
eeprom is corrupted, U-Boot will never get into ram. Here's how I got
|
||||
out of this situation:
|
||||
|
||||
0. First, _before_ playing with the i2c utilities, do an 'i2c probe', then
|
||||
use 'i2c md' to capture the various device contents to a file. Some day
|
||||
you may be glad you did this ... trust me :-). Otherwise try the
|
||||
following:
|
||||
|
||||
1. In the include/configs/EBONY.h file find the line that defines
|
||||
the CONFIG_SPD_EEPROM macro and undefine it. E.g:
|
||||
|
||||
#undef CONFIG_SPD_EEPROM
|
||||
|
||||
This will make the code use default SDRAM control register
|
||||
settings without using the SPD eeprom.
|
||||
|
||||
2. Rebuild U-Boot
|
||||
|
||||
3. Load the new U-Boot image and reboot ebony.
|
||||
|
||||
4. Repair the SPD eeprom using the 'i2c mm' command. Here's the eeprom
|
||||
contents that work with the default SO-DIMM that comes with the
|
||||
ebony board (micron 8VDDT164AG-265A1). Note: these are probably
|
||||
_not_ the factory settings ... but they work.
|
||||
|
||||
=> i2c md 53 0 10 80
|
||||
0000: 80 08 07 0c 0a 01 40 00 04 75 75 00 80 08 00 01 ......@..uu.....
|
||||
0010: 0e 04 0c 01 02 20 00 a0 75 00 00 50 3c 50 2d 20 ..... ..u..P<P-
|
||||
0020: 90 90 50 50 00 00 00 00 00 41 4b 34 32 75 00 00 ..PP.....AK42u..
|
||||
0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9c ................
|
||||
0040: 2c 00 00 00 00 00 00 00 08 38 56 44 44 54 31 36 ,........8VDDT16
|
||||
0050: 36 34 41 47 2d 32 36 35 41 31 20 01 00 01 2c 63 64AG-265A1 ...,c
|
||||
0060: 22 25 ab 00 00 00 00 00 00 00 00 00 00 00 00 00 "%..............
|
||||
0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
||||
|
||||
|
||||
PCI DOUBLE-ENUMERATION WOES
|
||||
===========================
|
||||
|
||||
If you're not using PCI-X cards and are simply using 32-bit and/or
|
||||
33 MHz cards via extenders and the like, you may notice that the
|
||||
initial pci scan reports various devices twice ... and configuration
|
||||
does not succeed (one or more devices are enumerated twice). To correct
|
||||
this we replaced the 2K ohm resistor on the IDSEL line(s) with a
|
||||
22 ohm resistor and the problem went away. This change hasn't broken
|
||||
anything yet -- use at your own risk.
|
||||
|
||||
We never tested anything other than 33 MHz/32-bit cards. If you have
|
||||
the chance to do this, please let me know how things turn out :-)
|
||||
|
||||
|
||||
Regards,
|
||||
--Scott
|
||||
<smcnutt@artesyncp.com>
|
||||
Loading…
Add table
Add a link
Reference in a new issue