[coreboot] [PATCH] Geode GX2 auto DRAM detect patch

Nils njacobs8 at hetnet.nl
Fri Oct 15 16:10:26 CEST 2010

Op vrijdag 15 oktober 2010 00:12:43 schreef u:
> I used to be familiar with that code and I find a 1600 line patch a
> little daunting. Who's testing which board?
> If a board can not be tested, I think it ought to be left alone or
> removed. Otherwise you risk leaving a board in a broken state, which
> someone else will discover at a later date.
> ron
As i stated in the original message i tested the patch on my Geode GX2 Wyse 
S50 board.
I didn`t test it on the Rumba and Frontrunner because i don`t have them and 
people who have them don`t seem to have time/interest to test.
But i don`t think that is very imported because both boards are broken in the 
current state for years.

As i began to test and patch the whole GX2 tree was a mess.
For instance the VSA code was non functional because Ron had committed a 
unfinished patchset in r4611 that was obviously not tested!

The Rumba target has a nonfunctional DRAM detection routine in romstage.c .(I 
tested it thats why i used an other one in S50 romstage)
It probably never worked since Ollie commited it in r2235 and that is probably 
the reason why the code was changed in the Frontrunner and later the Olpc 
targets to use hardcoded values (hack).
I think the Rumba target was abandoned at that time in favor for the 
Frontrunner board that got committed.

I don`t think the Frontrunner board works at the present state either.
I think i found a double bug in the cpureginit.c code that exists since the 
first commit in r2248 ! (The FooGlue setup should only be done for CS5535 
boards and uses a wrong address)
I am working on a patch for that.
And there are probably more bugs in the CS5535 code witch the Fronrunner uses 
that i can not test.

The PLL setup code in the romstage.c files is nonfunctional because it is 
hardcoded in pll_rst.c to 366Mhz.
The wrong PLL setup values that are still in Rumba and S50 (and were in Olpc) 
let the processor run on 100Mhz if enabled!

I think the GX2 code was never realy finished on any target and was/is a mess.
Because exept for my Wyse S50 i don`t think there is a working board.
(there is not even a free available working VSA blob for the current GX2 tree, 
i had to make it myself!)

So i think my patches are a big improvement and it is hard to "break" someones 
board with it.

I am not planning to do a lot of little patches and abuild and boot test all 
of them separately as that cost me a lot of extra time.
As i understand it only a few, for the real user unimportant, white space and 
comment change patches would get acked and committed and no one dares to ack 
the real patches.

I feel as if i was the only one cares about non functional code in the GX2 

Maybe Ron is right and all of the non functional boards (i think at least 90 
percent of coreboot) should be deleted.
Hardly anybody boot tests there big self acked and committed patches nowadays.
(i understand that is mostly impossable to do)

Sorry for the long rant.
I won`t bother you any longer.


More information about the coreboot mailing list