headers
Corey Osgood | 1 Sep 05:25
Picon

Re: addr_offset help

Joseph Smith wrote:
> Quoting Corey Osgood <corey.osgood <at> gmail.com>:
>
>> Joseph Smith wrote:
>>> Can someone explain the significance of the  addr_offset variable in
>>> raminit.c on the i440bx and i82810? Also why is this set to 0x1d0 for
>>> the Mode register set (MRS)?
>>>
>>> Thanks - Joe
>>>
>>>
>>
>> MRS is a setting within the ram that's set by reading from a certain
>> location while the northbridge is in MRS mode. It essentially tells the
>> ram what timings to run at. For the most part, the only values you'll
>> ever need for SDRAM are 0x1d0 for CL3 and 0x150 for CL2, but DDR and
>> DDR2 make more advanced use of MRS and E(xtended)MRS. Read the JEDEC
>> standard for more info.
>>
>> -Corey
>>
> Thanks Corey, that makes sense. Not sure how it tells the memory what
> timings to run at though. Does it tell the northbridge what timings to
> run at?
>
> Thanks - Joe
>

No. The northbridge should have the timing programmed in to some
register(s). The ram then needs to be told *the same* timings that the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Corey Osgood | 1 Sep 05:37
Picon

Re: [PATCH] Initial support for the MSI MS-6178 (i810-based)

popkonserve wrote:
>>    00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
>> ---------------------------------------------------
>> 00: 86 80 20 71 06 01 80 20 03 00 00 06 00 00 00 00
>> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 50: 60 ff 0a 20 00 00 00 00 00 00 00 00 00 00 00 00
>> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 90: 00 00 da 77 00 00 00 00 00 00 00 00 00 00 00 00
>> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> f0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00
>>     
>
> - the refresh (offset 53h) should be 15,6µs instead of 7,8µs which
> should only be used for high density rams (>256MB)
>   

No, 0x20 is correct, bit 5 is the only bit flipped.

> - CL, SRCD and SRP (offset 53h) are unconfigured. either read them from
> the spd or configure them by performing read/write tests
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Corey Osgood | 1 Sep 05:55
Picon

Re: [PATCH] Initial support for the MSI MS-6178 (i810-based)

Uwe Hermann wrote:
> On Thu, Aug 30, 2007 at 11:43:41PM -0400, Corey Osgood wrote:
>   
>>> I guess (from looking at the boot log diffs) that this may be the reason
>>> for the slow boot, but how do I fix it?
>>>
>>>    CPU: L1 I cache: 16K, L1 D cache: 16K
>>>   -CPU: L2 cache: 128K
>>>
>>> (i.e., it seems the L2 cache is never enabled when using LinuxBIOS)
>>>   
>>>       
>> Is your cpu id in model_6xx_init.c? I'm not seeing any attempt even at
>> cpu init in the LB boot log, and IIRC there should be something printed.
>> And if I'm reading the kernel boot log right, your model ID is 0x06a5,
>> which isn't currently in there and not added by your patch. I'll fire up
>> the mew-vm tomorrow and see if it has the same problem, the boot on that
>> board is slow but not that slow, I figured it was just my old 400MHz
>> celeron running over a serial connection.
>>     
>
> I checked that, but it looks correct to me. If I'm not mistaken I have
> a 0x0665 (Mendocino), but maybe I got the format of those IDs wrong?
>
> See CPU info below:
>
> $ proc/cpuinfo
> processor	: 0
> vendor_id	: GenuineIntel
> cpu family	: 6
(Continue reading)

Permalink | Reply | 0 comments |
headers
popkonserve | 1 Sep 08:28
Picon
Picon

Re: [PATCH] Initial support for the MSI MS-6178 (i810-based)

>>- the refresh (offset 53h) should be 15,6µs instead of 7,8µs which
>>should only be used for high density rams (>256MB)
>>  
> No, 0x20 is correct, bit 5 is the only bit flipped.

oops, sorry, you are right...

>>- CL, SRCD and SRP (offset 53h) are unconfigured. either read them from
>>the spd or configure them by performing read/write tests
>>  
> No, they're configured to the slowest and safest possible timings. I
> haven't gotten to optimizing it yet.

yeah, that's what i thought, too. but if you're able to read the values 
from the spd it should be no problem setting them!?

>>page 7:
>>http://www.cs.inf.ethz.ch/stricker/lab/doc/intel-part4.pdf
>>
>>line 473ff
>>http://fxr.watson.org/fxr/source/i386/i386/initcpu.c?v=RELENG4
>>
> I'll look into these later, but I suspect x86_enable_cache() does
> something similar.

hmm, no. actually x86_enable_cache() just emits a post code, prints some 
info and calls enable_cache() which is an inline in cache.h which just 
enables L1 cache by flipping a bit in the processor configuration 
register 0 (CR0). that's all.
it should be renamed to enable_L1_cache() to avoid confusion.
(Continue reading)

Permalink | Reply | 0 comments |
headers
svn | 1 Sep 13:10

r2756 - in trunk: LinuxBIOSv2/util util

Author: uwe
Date: 2007-09-01 13:10:56 +0200 (Sat, 01 Sep 2007)
New Revision: 2756

Added:
   trunk/util/getpir/
   trunk/util/mptable/
Removed:
   trunk/LinuxBIOSv2/util/getpir/
   trunk/LinuxBIOSv2/util/mptable/
Log:
Move getpir and mptable into the global util/ directory.

Signed-off-by: Uwe Hermann <uwe <at> hermann-uwe.de>
Acked-by: Uwe Hermann <uwe <at> hermann-uwe.de>

Copied: trunk/util/getpir (from rev 2755, trunk/LinuxBIOSv2/util/getpir)

Copied: trunk/util/mptable (from rev 2755, trunk/LinuxBIOSv2/util/mptable)

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 0 comments |
headers
Uwe Hermann | 1 Sep 13:12
Picon
Favicon
Gravatar

Re: [PATCH] Move common utilities to util/

On Thu, Aug 30, 2007 at 08:03:34PM +0200, Carl-Daniel Hailfinger wrote:
> On 30.08.2007 13:37, Uwe Hermann wrote:
> > So here's the updated plan:
> > 
> >  - Move probe_superio to util/superio-detect (rename it while we're at it).
> 
> It does much more than detection these days. It also has the ability to
> verify and dump SuperI/O configuration. Can we think about the name a
> little bit more?

'superiotool'.

And then add an interface like this:

$ superiotool --detect
IT8712F

$ superiotool --dump
[...]

$ superiotool --verify

etc...

> >  - Move getpir to util/.
> >  - Move mptable to util/.
> > 
> > Everything else stays where it is. Looks good?
> 
> Nice.
(Continue reading)

Permalink | Reply | 3 comments |
headers
LinuxBIOS information | 1 Sep 13:56
Picon

r2756 build service

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2756 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Move getpir and mptable into the global util/ directory.

Signed-off-by: Uwe Hermann <uwe <at> hermann-uwe.de>
Acked-by: Uwe Hermann <uwe <at> hermann-uwe.de>

Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2756&device=hdama&vendor=arima
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2756&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2756&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2756&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2756&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2756&device=dk8x&vendor=iwill

If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rudolf Marek | 1 Sep 14:09
Picon

Re: problems with reboot on K8

Hi all,

Just an update to this problem, removing soft_reset in cpu_init module does not 
help. I added 1s delay before calling the setup_resource map, now it hangs when 
it writes third "line" of the the resource table. I dont think there is anything 
significant, yet I dont know what could be wrong that it will just hang up. The 
PCI writes are to device 18, this is inside a processor, and there is no need to 
have correctly setup the HT Link correct?

Any clue?

If someone needs additional info, I will provide that too.

Rudolf

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 4 comments |
headers
Philipp Degler | 1 Sep 15:46
Picon
Picon

Re: hotplugging flash piece on A8N-E / ROMSIZE

On Friday 31 August 2007 18:49:55 Robert Millan wrote:
> On Thu, Aug 30, 2007 at 06:57:18PM +0200, Philipp Degler wrote:
> > On Monday 27 August 2007 00:31:37 Quux wrote:
> > > Peter Stuge schrieb:
> > > > It may not be best practice to hotplug, but it is rather safe since
> > > > the chip is never accessed once the system is running.
> > >
> > >  saves plug cycles and time ...
> > >
> > > >> Even an 8 Mbit piece 49LF080A works with the Asus a8ne, so
> > > >> maybe a kernel may be squeezed in there as well.
> > > >
> > > > Yup, but only with a minimum of drivers.
> > >
> > > a 2 MByte piece was used to contain LB + Kernel. I guess a 2 MByte
> > > flash would work in A8N-E , too.
> > >
> > >
> > > currently I am trying to manage with the variables ROMSIZE , IMAGE SIZE
> > > asf. to build a ROM with correct size 512 KB, which seems tricky for
> > > some obscure reason.  --Q
> >
> > Today I checked out the latest svn revision and tested on our ASUS A8N-E
> > rev 2.0.
> >
> > Status of the board is unchanged. It boots with filo 5.0 from IDE. The
> > autmatically build images are not working. Reason is the RAM issue with
> > Athlon64 CPU in 939 socket.
> >
> > You need to modify amdk8/raminit.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joseph Smith | 1 Sep 15:56

Re: addr_offset help


>>> MRS is a setting within the ram that's set by reading from a certain
>>> location while the northbridge is in MRS mode. It essentially tells the
>>> ram what timings to run at. For the most part, the only values you'll
>>> ever need for SDRAM are 0x1d0 for CL3 and 0x150 for CL2, but DDR and
>>> DDR2 make more advanced use of MRS and E(xtended)MRS. Read the JEDEC
>>> standard for more info.
>>>
What do you mean by this??

> And just realized something else, directly related to the email I just
> sent for Joe. Please change the MRS value from 0x1d0 to 0xad0. Heh, that
> could seriously bork things up, my bad.
>
> -Corey
>
>
What am I supposed to use for CL3?

Thanks - Joe

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 1 comment |

Gmane