[LinuxBIOS] LinuxBIOS on ASUS P2B-L

Richard Smith smithbone at gmail.com
Thu Aug 3 01:30:51 CEST 2006


>
> This took a little longer than I expected due to my son's fourth

No rush we got lots of time.

> These probes are byte-for-byte identical with what the p2b target
> LinuxBIOSv2 outputs when I flash it and start up my system.

Well thats a positive sign.  I don't know for a _fact_ that the asus
p2b has the smbus hidden.  Back when I was messing with that under V1
(several years ago) there were reports on the list that asus
motherboards did funky things with the smbus.  I took working V1
bitworks/IMS code and brought it up on a p2b (rev 1.04) with the exact
same memory and memory didn't fly.  Hardcoding the memory settings
made it work fine.  That + reports of asus smbus funkyness led me to
believe that the smbus was as fault.  At the time hardcoding the
memory was fine for what I needed to test so I didn't persue it any
further.

You are reporting that the spd reads work you under linuxbios.  Correct?
If thats the case then perhaps my V1 issues were code problems and not
hardware smbus problems.  Which is good.
I've still got that p2b so I'll test and see if I get the same results as you.

> So - does this mean that the w83781d is controlling the memory SMBUS,
> since it's detected correctly?

I don't think so.  The W83781D is a hardware monitor chip and looking
at the datasheet I don't see the ability to be an I2C master.  What I
think that is telling you is that the W83781D ISA's interface (it has
I2C and ISA) is also available at IO 0x0290.

The spd read code only talks to the PIIX4 and you got data back from
that so the W83781D really doesn't matter.

> Also, you mentioned a couple of changes to the 440bx code that you'd
> like to do.  Would it be OK for me to take a shot at these changes -
> probably tonight or tomorrow - as a way to get my feet wet with the
> codebase and hopefully make a small contribution?  I'd guess that the
> southbridge name change would be pretty trivial, but the other change
> might need a little more smarts - but I'd like to take a shot at 'em.

Sure. Any and all help is very welcome.

Lets go with Stefan's suggestion and name the southbridge chip after
its actual ID.  i82371eb.  Thats a pretty easy change.

The RAM init re-base is pertty much the same.  Copy the raminit.c and
raminit.h from the intel/e7501 on top of the raminit.[ch] thats there
and then go though and fixup any specific e7501 names.

Then the hard part starts.  We have to go though and start walking the
ram init chain and make each one of those steps match the 440bx using
the V1 assembly as a guide.  The e7501 appears to be a DDR controller
with 2 channels but its very well documented and I like the structure.
 It looks much nicer than the via example I used previously.

-- 
Richard A. Smith




More information about the coreboot mailing list