Re: i440bx RAM initialization code (SPD)

Hi,

thanks for your patch. However, please sign-off all patches you submit,
otherwise we cannot commit them.

http://linuxbios.org/Development_Guidelines#Sign-off_Procedure

Please re-send this patch with a sign-off.

On Mon, Apr 30, 2007 at 10:47:42AM -0400, Alfred Wanga wrote:
> * PMCR - When should it be updated?
> Looking at the assembly, it seems as though it's ok to just set the
> final value before the RAM refresh code instead of waiting until
> afterwards, but I don't know for sure, so I left the original code
> alone.

Yeah, I'm not sure either. Will look into that later...

> * sdram_enable delays
> I changed all the RAM timing delays (tRP, tRC, tMRD) to 1usec, since
> the timings are on the order of hundreds of nanoseconds (according to
> SPD values) and the smallest resolution timer available seems to be
> udelay() anyway. It should work for any SDRAM, and shaves a few
> milliseconds off previous code.

Yep, when everything is working fine (or maybe even before) we'll lower
the delays. I set them quite high to make sure that it's definately not
a too short delay which is causing problems...

If you want you can submit an extra patch with just the delay-fixes. I'll

Re: i440bx RAM initialization code (SPD)

Interesting... seems this patch is creating a cpu run when compiling.
Within ASM code maybe?

Roger
http://www.eskimo.com/~roger/index.html
Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61

Mon Apr 30 15:18:19 PDT 2007

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: i440bx RAM initialization code (SPD)

On Mon, Apr 30, 2007 at 12:19:46PM -0700, roger wrote:
> Uwe, from what I've read concerning the i440BX memory initialization
> docs, SPD is *required* to initialize memory.

Yes, you get the information about timings etc. of the RAM via SPD, see
Peters mail.

> Or have we verified writing to memory is successful?

Well, yes, at least I think so :) However, we only know for sure when we
booted a payload successfully (which will hopefully be soon).

Next up: investigate what the reason for the elfboot error is.

> raminit.c:407.18: raminit.c:796.20: generic_sdram.c:49.40: auto.c:97.25: 
> too few registers

Don't worry. This is a romcc problem/limitation, and we cannot do too
much to fix it. We'll switch to using Cache as RAM eventually.

Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

r2622 - trunk/LinuxBIOSv2/src/northbridge/intel/i440bx

Author: uwe
Date: 2007-05-01 01:27:27 +0200 (Tue, 01 May 2007)
New Revision: 2622

Modified:
   trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/raminit.c
Log:
Fix typo: s/PRINT_DEBUG_/PRINT_DEBUG/ (trivial).

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

Modified: trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/raminit.c
===================================================================
--- trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/raminit.c	2007-04-28 02:22:59 UTC (rev 2621)
+++ trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/raminit.c	2007-04-30 23:27:27 UTC (rev 2622)
@@ -38,7 +38,7 @@
 #define PRINT_DEBUG_HEX32(x)	print_debug_hex32(x)
 #define DUMPNORTH()		dump_pci_device(PCI_DEV(0, 0, 0))
 #else
-#define PRINT_DEBUG_(x)
+#define PRINT_DEBUG(x)
 #define PRINT_DEBUG_HEX8(x)
 #define PRINT_DEBUG_HEX16(x)
 #define PRINT_DEBUG_HEX32(x)

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: i440bx RAM initialization code (SPD)

On Tue, 2007-05-01 at 01:12 +0200, Uwe Hermann wrote:
> On Mon, Apr 30, 2007 at 12:19:46PM -0700, roger wrote:

> > Or have we verified writing to memory is successful?
> Well, yes, at least I think so :) <-- lol.

> However, we only know for sure when we
> booted a payload successfully (which will hopefully be soon).
> Next up: investigate what the reason for the elfboot error is.

Right. After spending a day hacking with my superior lower level of
intellect then everybody else here, i was ready to hack elfboot.c to
dump parts of the memory it was actually reading, rather then just the
address values.

> > raminit.c:407.18: raminit.c:796.20: generic_sdram.c:49.40: auto.c:97.25: 
> > too few registers
> 
> Don't worry. This is a romcc problem/limitation, and we cannot do too
> much to fix it. We'll switch to using Cache as RAM eventually.

After awhile of staring at the code, it started pointing as a more
internal coding error.

--
Roger
http://www.eskimo.com/~roger/index.html
Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61

Mon Apr 30 16:44:26 PDT 2007

r2622 build service

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

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

Change Log:
Fix typo: s/PRINT_DEBUG_/PRINT_DEBUG/ (trivial).

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
Compilation of ibm:e325 is still broken
Compilation of ibm:e326 is still broken
Compilation of iwill:dk8s2 is still broken
Compilation of iwill:dk8x is still broken

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

If this issue is not fixed within 24h the revision will 
be backed out.

   Yours truely,
     LinuxBIOS automatic build system

Re: Nifty device for SPI chips

Richard Smith wrote:
> Bari Ari wrote:
> 
>> This is what I started working on with the PLAICE project 
>> http://flash-plaice.wikispaces.com. Looks like about the same features 
>> only we add a logic analyzer to the mix for under $200.
> 
> Cool.  If I buy one is it ready or do you still have stuff to finish?
> 

The dev boards are available from Xilinx.

We have an experimental version of the logic analyzer that needs to be 
expanded to use the DDR.

The Java client currently only supports the logic analyzer.

uClinux is up and running on the MicroBlaze with support for the serial 
port and Ethernet. The MicroBlaze needs to tied to the logic analyzer 
and some apps and VHDL need to be written to support memory emulation 
and FlashROM.

-Bari

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Re: winflashrom architecture (Windows port of flashrom) -- looking for suggestions

On Mon, Apr 30, 2007 at 10:50:07AM +0700, Darmawan Salihun wrote:
> 1. The kernel mode code a.k.a kernel mode device driver is as
> simple as possible and only provides "raw" functionality, i.e.
> capability to map the physical address space in which the BIOS
> chip is mapped into the requesting user mode code.

This would be OK, but there's a constant race between making the
window large enough and new flash chips.

> 2. The kernel mode driver implements the majority of the flashrom
> code and the usermode code is merely a "front-end" to the kernel
> mode device driver which provides all of the chip related logic.

I like this a bit better.

> Anyway, I'm also thinking about a quite "universal" interface
> between the user mode code and the kernel mode code. Perhaps a well
> defined interface

This requires a lot of extra work but has the benefit of only one
generic algorithm being implemented in the kernel, thus the kernel
driver will not have to be updated to support new flash chips. It
could however have to be updated when a new driver supporting all
SPI flash is released. (But not every time a new flash chip is
added.)

After having identified the chip the app would download the
appropriate microcode to the kernel driver; a set of rather
high-level instructions to be executed by the driver.

Re: Booting Windows XP / Vista - Google Summer of Code

On Mon, Apr 30, 2007 at 07:55:56AM -0300, Augusto Pedroza wrote:
> I am trying to find that, no success up to now but thanks for the
> suggestion.

http://daemons.net/~clay/index.php/2006/03/15/dual-booting-windows-xp-and-mac-os-x-on-intel-macs/
http://daemons.net/~clay/OSXP/

http://thread.gmane.org/gmane.linux.bios/15678
http://thread.gmane.org/gmane.linux.bios/18671

//Peter

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios

Support for some more SuperIOs/old Chipsets

hi,
i just subscribed to the mailing list and i need a speedup on the 
development of LinuxBIOSv2 as i want to contribute some code. I thought 
of some SuperIO chips i still have docs for, maybe completing some of 
the code already written (there are a lot of TODOs in the code). Finally 
i'm thinking of contributing code for some older chipsets (ALi socket7, 
VIA socket7, intel socket7) and maybe cpus (cyrix 6x86 family, amd k6 
familiy, intel pentium (mmx)) as i think those boards deserve a fast 
booting bios without too much useless stuff in there.
i didn't took a deep look into the api yet. so i still have a lot of 
questions: where should i start? Chipsets and CPUs or rather some 
SuperIO stuff? and what i really need to know is: where is the 
configuration done? let's say ram timings (no spd on edo/fpm), superIO 
settings, etc. (there are a lot other chipset tweaks that could be applied).
btw. currently i'm working as a developer for embedded automotive 
systems, so i hope i can help with some code.

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios