svn@coreboot.org wrote:
Make directory hierarchy flat to match the same layout we use for other chipsets, as suggested on IRC.
I don't agree so much with this but oh well.
Maybe there will be opportunity for unifying DDR2 code.
//Peter
Peter Stuge wrote:
svn@coreboot.org wrote:
Make directory hierarchy flat to match the same layout we use for other chipsets, as suggested on IRC.
I don't agree so much with this but oh well.
Maybe there will be opportunity for unifying DDR2 code.
If you are going to flatten the structure then you should also probably correct the companion chip name. The code base this was started from was vx800 but its been modified for the vx855. At the time OLPC got the code the mods were already made so we don't know exactly what what changed from vx800 to vx855.
The vx855 is a subset of the vx800. The code will probably work on a vx800 but I'm sure there are subtle differences. Perhaps you should rename it to be vx8xx and then start dealing with the differences when you find them.
In other news... we have our Gen 1.5 hardware booting (OpenFirmware) and Linux. Most stuff seems to work but its still in testing.
The bad news is that the vx8xx code won't work on the gen 1.5 ATest board as written. We ended up having to use different RAM chips and so there is not an SPD on the ATest. Also there are various things different in the RAM subsystems between the vx555 demo board we had and the gen 1.5 Atest. The code has various bits of hardcoded things for the demo board.
The good news is that all of these settings are in the OpenFirmware repository. So you can go get the proper settings.
Is there any sort of facility in the config files for a SPDless board?
Bari: Sorry I've not yet responded to your graphics email.. I'll try to scratch out some time tonight to respond with whats going on in graphics.
Richard,
There are several boards currently running without SPD data, the one I'm looking at right now is the pcengines alix1c. Have a look at how it works there, it seems like a reasonable way to do things.
-Corey
On Thu, May 28, 2009 at 4:07 AM, Richard Smith smithbone@gmail.com wrote:
Peter Stuge wrote:
svn@coreboot.org wrote:
Make directory hierarchy flat to match the same layout we use for other chipsets, as suggested on IRC.
I don't agree so much with this but oh well.
Maybe there will be opportunity for unifying DDR2 code.
If you are going to flatten the structure then you should also probably correct the companion chip name. The code base this was started from was vx800 but its been modified for the vx855. At the time OLPC got the code the mods were already made so we don't know exactly what what changed from vx800 to vx855.
The vx855 is a subset of the vx800. The code will probably work on a vx800 but I'm sure there are subtle differences. Perhaps you should rename it to be vx8xx and then start dealing with the differences when you find them.
In other news... we have our Gen 1.5 hardware booting (OpenFirmware) and Linux. Most stuff seems to work but its still in testing.
The bad news is that the vx8xx code won't work on the gen 1.5 ATest board as written. We ended up having to use different RAM chips and so there is not an SPD on the ATest. Also there are various things different in the RAM subsystems between the vx555 demo board we had and the gen 1.5 Atest. The code has various bits of hardcoded things for the demo board.
The good news is that all of these settings are in the OpenFirmware repository. So you can go get the proper settings.
Is there any sort of facility in the config files for a SPDless board?
Bari: Sorry I've not yet responded to your graphics email.. I'll try to scratch out some time tonight to respond with whats going on in graphics.
-- Richard A. Smith smithbone@gmail.com
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Thu, May 28, 2009 at 07:26:21AM -0400, Corey Osgood wrote:
Richard,
There are several boards currently running without SPD data, the one I'm looking at right now is the pcengines alix1c. Have a look at how it works there, it seems like a reasonable way to do things.
Usually the boards hardcode the SPD contents in an array, then the SPD read functions don't do any SMBus stuff but rather read from that array (for that board).
Here's a quick sample cutnpaste from a v3 board (DBE62):
/* The part is a Micron MT46V16M16 P 5B * 4 M x 16 x 5 Banks, 200 Mhz, Plastic package, TSOP, DDR400B, 5 ns CL3 * Commercial rating. * @ 200 ns, data-out window, 1.6; access, +- 70 ns; dqs-dq skew: .4ns * http://www.micron.com/products/partdetail?part=MT46V16M16P-5B */
struct spd_entry { u8 address; u8 data; };
/* Save space by using a short list of SPD values used by Geode LX Memory init */ static const struct spd_entry spd_table[] = { {SPD_MEMORY_TYPE, 7}, {SPD_NUM_ROWS, 13}, {SPD_tRFC, 0x4b}, {SPD_ACCEPTABLE_CAS_LATENCIES, 0x10}, {SPD_DENSITY_OF_EACH_ROW_ON_MODULE, 0x40}, {SPD_tRAS, 0x2d}, {SPD_MIN_CYCLE_TIME_AT_CAS_MAX, 0x7}, /*0x <= 7},*/ {SPD_MIN_RAS_TO_CAS_DELAY, 0x58}, {SPD_tRRD, 0x3c}, {SPD_tRP, 0x58}, {SPD_PRIMARY_SDRAM_WIDTH, 8}, {SPD_NUM_BANKS_PER_SDRAM, 0x4}, {SPD_NUM_COLUMNS, 0xa}, /* 8kB */ {SPD_NUM_DIMM_BANKS, 0x1}, {SPD_REFRESH, 0x82}, {SPD_SDRAM_CYCLE_TIME_2ND, 0x0}, {SPD_SDRAM_CYCLE_TIME_3RD, 0x0}, };
/** * Given an SMBUS device, and an address in that device, return the value of SPD * for that device. In this mainboard, the only one that can return is DIMM0. * @param device The device number * @param address The address in SPD rom to return the value of * @returns The value */ u8 spd_read_byte(u16 device, u8 address) { int i; /* returns 0xFF on any failures */ u8 ret = 0xff;
printk(BIOS_DEBUG, "spd_read_byte dev %04x", device); if (device == DIMM0) { for (i = 0; i < ARRAY_SIZE(spd_table); i++) { if (spd_table[i].address == address) { ret = spd_table[i].data; break; } }
if (i == ARRAY_SIZE(spd_table)) printk(BIOS_DEBUG, " addr %02x does not exist in SPD table", address); }
printk(BIOS_DEBUG, " addr %02x returns %02x\n", address, ret); return ret; }
HTH, Uwe.
On Thu, May 28, 2009 at 04:07:08AM -0400, Richard Smith wrote:
If you are going to flatten the structure then you should also probably correct the companion chip name. The code base this was started from was vx800 but its been modified for the vx855. At the time OLPC got the code the mods were already made so we don't know exactly what what changed from vx800 to vx855.
The vx855 is a subset of the vx800. The code will probably work on a vx800 but I'm sure there are subtle differences. Perhaps you should rename it to be vx8xx and then start dealing with the differences when you find them.
Sounds like a good plan, yes. If the vx855 is a subset of vx800 the differences should be minimal and a common code base should be nicely doable.
Uwe.
-
Corey Osgood -
Peter Stuge -
Richard Smith -
Uwe Hermann