Hi all, As i finally had a little time to spend on Coreboot i was able to almost finish a patch for Coreboot to autodetect DRAM on the GX2 chipset. I still have one problem that i could use some help with.
As the Lippert FrontRunner ,the OLPC btest and the OLPC rev_a seem to have onboard DRAM without SPD memory, i implemented a SPD table in romstage.c . The problem is that i could not find much info on the used ram chips. I only could find 256 MB 64 bit 111Mhz 222 MT/s DDR SDRAM for the Frontrunner board and some SDRAM parameters for the OLPC boards. I used them to guess the rest of the parameters but it would be better to use the exact parameters.
So if someone could give me the type numbers for the used SDRAM chips i can search for datasheets and implement the right timing numbers.
Thanks,Nils.
The OLPC question is a little tricky. I have several btest boards and ... the dram on each one is different, with different timings. Two of them have custom dram timing settings (it's a long story). This target is going on 5 years old and I think it ought to be yanked -- anyone have one? It's a real distraction and I don't see the point in keeping it on when it just confuses people.
same for rev_a. I just don't see the point, given that if you have a board, you're not supposed to :-)
ron
Hi Ron and other readers, I waited a bit with answering because i hoped to get some more opinions... Op zaterdag 25 september 2010 00:05:29 schreef u:
The OLPC question is a little tricky. I have several btest boards and ... the dram on each one is different, with different timings. Two of them have custom dram timing settings (it's a long story). This target is going on 5 years old and I think it ought to be yanked -- anyone have one? It's a real distraction and I don't see the point in keeping it on when it just confuses people.
same for rev_a. I just don't see the point, given that if you have a board, you're not supposed to :-)
ron
As the OLPC btest and rev_a GX2 targets were only prototypes that never went in to production i am fine with removing them. Another option might be to include the 3 different SPD tables and make a kconfig option to chose the DRAM type. If there is interest i could try integrate that in my patch.
How do others think about it?
Nils.
Nils wrote:
This target is going on 5 years old and I think it ought to be yanked -- anyone have one? It's a real distraction and I don't see the point in keeping it on when it just confuses people.
same for rev_a.
The alternative would be to keep them and clean them up a bit.
As the OLPC btest and rev_a GX2 targets were only prototypes that never went in to production i am fine with removing them.
This is a good point.
Another option might be to include the 3 different SPD tables and make a kconfig option to chose the DRAM type. If there is interest i could try integrate that in my patch.
If easy enough, then maybe that's a pretty good idea!
//Peter
Hi Ron, You proposed removing the OLPC prototype boards and Peter voted for keeping them. I personally don`t care either way and the rest doesn`t want to express their opinion so i would like to let you decide. :) Could i ask you to delete the boards (i don`t have SVN access) or dig up the boards and give me the DRAM types?
Thanks, Nils.
On Mon, Sep 27, 2010 at 12:09 PM, Nils njacobs8@hetnet.nl wrote:
Hi Ron, You proposed removing the OLPC prototype boards and Peter voted for keeping them. I personally don`t care either way and the rest doesn`t want to express their opinion so i would like to let you decide. :) Could i ask you to delete the boards (i don`t have SVN access) or dig up the boards and give me the DRAM types?
well, let me retry my explanation. I can give you the DRAM types. But the timing for each type is incompatible. So we'd have to make three boards or do conditional compilation and Kconfig options for the three types. This is for a board nobody has.
So maybe I'm missing something, but I just can't see the point of keeping these boards.
ron
On 27.09.2010 22:24, ron minnich wrote:
On Mon, Sep 27, 2010 at 12:09 PM, Nils njacobs8@hetnet.nl wrote:
Hi Ron, You proposed removing the OLPC prototype boards and Peter voted for keeping them. I personally don`t care either way and the rest doesn`t want to express their opinion so i would like to let you decide. :) Could i ask you to delete the boards (i don`t have SVN access) or dig up the boards and give me the DRAM types?
well, let me retry my explanation. I can give you the DRAM types. But the timing for each type is incompatible. So we'd have to make three boards or do conditional compilation and Kconfig options for the three types. This is for a board nobody has.
So maybe I'm missing something, but I just can't see the point of keeping these boards.
I have various OLPC prototypes including one A-Test board which was the original coreboot target for OLPC, but information from my board won't help you at all because the DRAM soldered on my board had a too slow CL (slower than the slowest allowed setting of the memory controller) and thus it was considered to be unstable (worked for me, but hey...).
IIRC the firmware of the OLPC XO was a time-limited test version of Insyde BIOS, replaced with coreboot developed for free, then replaced with OpenFirmware which was apparently paid for. It is extremely unlikely that coreboot will ever make any inroads at OLPC, and the boards we could possibly support are not available to the general public in sizable numbers. If you're looking for GeodeLX-based boards, check out the Artec ThinCan DBE61/DBE62 models and the PCEngines Alix models. Both vendors are helpful, and Artec even sponsored coreboot development. The new VIA-based OLPC design could be supported by coreboot. AFAICS the chipset support is there, and wiring up the rest should be possible, but it again is a problem of hardware availability.
Given that the support for old Geode-based OLPC XO prototypes seems to be holding back coreboot development, I vote for removing them from svn unless someone with sufficient motivation takes care of them.
Regards, Carl-Daniel
On 9/27/10 10:40 PM, Carl-Daniel Hailfinger wrote:
I have various OLPC prototypes including one A-Test board which was the original coreboot target for OLPC, but information from my board won't help you at all because the DRAM soldered on my board had a too slow CL (slower than the slowest allowed setting of the memory controller) and thus it was considered to be unstable (worked for me, but hey...).
The last two guys here that have an OLPC board both seem to think it's not worth getting it working on their particular board. Sorry for not waiting for answers from Segher and Richard, but I kind of anticipate they would agree, too. OLPC went down the OFW road. So let's drop it.
Nils: I still think the GX2 SPD setup is worth checking in.
Signed-off-by: Stefan Reinauer stepan@coresystems.de
for the below:
svn rm src/mainboard/olpc
plus
Index: src/mainboard/Kconfig =================================================================== --- src/mainboard/Kconfig (revision 5864) +++ src/mainboard/Kconfig (working copy) @@ -80,8 +80,6 @@ bool "Nokia" config VENDOR_NVIDIA bool "NVIDIA" -config VENDOR_OLPC - bool "OLPC" config VENDOR_PC_ENGINES bool "PC Engines" config VENDOR_RCA @@ -153,7 +151,6 @@ source "src/mainboard/newisys/Kconfig" source "src/mainboard/nokia/Kconfig" source "src/mainboard/nvidia/Kconfig" -source "src/mainboard/olpc/Kconfig" source "src/mainboard/pcengines/Kconfig" source "src/mainboard/rca/Kconfig" source "src/mainboard/roda/Kconfig"
ron minnich wrote:
maybe I'm missing something, but I just can't see the point of keeping these boards.
The point would be to show how coreboot can support a single board which has been populated with different soldered-on RAM chips.
I think this would be useful to have, but on the other hand it may not be so difficult to add for the next board which needs it, and it might rot a little if only in a board noone really uses with coreboot anymore.
//Peter
On Tue, Sep 28, 2010 at 10:55 AM, Peter Stuge peter@stuge.se wrote:
The point would be to show how coreboot can support a single board which has been populated with different soldered-on RAM chips.
OK, good point; let's do that with a board people can buy, not a one-off engineering sample with DRAM parts known to be buggy.
I think this would be useful to have, but on the other hand it may not be so difficult to add for the next board which needs it, and it might rot a little if only in a board noone really uses with coreboot anymore.
it's rotted completely. Plus, it was making trouble for the guys doing GX2 work. Hence I am glad it's going away.
ron
On 09/28/2010 02:04 PM, ron minnich wrote:
On Tue, Sep 28, 2010 at 10:55 AM, Peter Stugepeter@stuge.se wrote:
The point would be to show how coreboot can support a single board which has been populated with different soldered-on RAM chips.
OK, good point; let's do that with a board people can buy, not a one-off engineering sample with DRAM parts known to be buggy.
I think this would be useful to have, but on the other hand it may not be so difficult to add for the next board which needs it, and it might rot a little if only in a board noone really uses with coreboot anymore.
it's rotted completely. Plus, it was making trouble for the guys doing GX2 work. Hence I am glad it's going away.
If you want to do a board with soldered on ram then use the XO-1.5 board rather than the XO-1 board. Its vx855 based so it won't mess up any GX2 people. XO-1.5 boards are in production and in the wild. If someone wants one then you can fill out an app on the contributors program and we send you one.
http://wiki.laptop.org/go/Contributors_program
cc: me if you apply.
The cots people do this by making a fake SPD device and plugging in the necessary data. That way you don't have to restructure the code too much.
Richard, do almost all or all of the 1.5 boards have the same memory and hence timing?
ron
On 09/28/2010 05:31 PM, ron minnich wrote:
Richard, do almost all or all of the 1.5 boards have the same memory and hence timing?
Was just discussing this with peter in private email.
Yes. 1.5 only has one set of timings. The hardware has GPIO memory selects hooked up to the vx855 so we could do multiple timings if necessary but so far they are unused as only one set has been needed.
Now that the hardware is in mass production the only reason a new timing would be introduced is if there was some critical long term part(s) shortage.
-
Carl-Daniel Hailfinger -
Nils -
Peter Stuge -
Richard A. Smith -
ron minnich -
Stefan Reinauer