[LinuxBIOS] patch 2:corrected alix1c memory size

Uwe Hermann uwe at hermann-uwe.de
Fri Oct 26 17:20:32 CEST 2007


On Thu, Oct 25, 2007 at 08:55:10PM -0700, ron minnich wrote:
> p.s. will send memory image and instructions to anyone who wants to take a try.

Please rather make a wiki page out of the instructions, i.e.

http://linuxbios.org/index.php?title=PC_Engines_ALIX.1C_Build_Tutorial&action=edit

(and attach a license template, please, e.g. {{GPL}} or {{PD-self}} etc).

Later a full status table as we have for some other boards now would be
great.


> +static u8 spd_read_byte(unsigned device, unsigned address)

Maybe

  static u8 spd_read_byte(u16 device, u16 address)

Are device and address of fixed size (16 bit)? Or rather 8 bit?


>  {
> -		return smbus_read_byte(device, address);
> +	print_debug("spd_read_byte dev ");
> +	print_debug_hex8(device);

You use *hex8 here, but device is 16 bit above. One of them should
be fixed.


> +
> +	if (device != (0x50<<1)){
> +		print_debug(" returns 0xff\n");
> +		return 0xff;
> +	}
> +
> +	print_debug(" addr ");
> +	print_debug_hex8(address);

Ditto.


> -	/* Switch from Cache as RAM to real RAM */
> -	/* There are two ways we could think about this.
> -	 1. If we are using the auto.inc ROMCC way, the stack is going to be re-setup in the code following this code.
> -		Just wbinvd the stack to clear the cache tags. We don't care where the stack used to be.
> -	 2. This file is built as a normal .c -> .o and linked in etc. The stack might be used to return etc.
> -		That means we care about what is in the stack. If we are smart we set the CAR stack to the same location
> -		as the rest of LinuxBIOS. If that is the case we can just do a wbinvd. The stack will be written into real
> -		RAM that is now setup and we continue like nothing happened. If the stack is located somewhere other than
> -		where LB would like it, you need to write some code to do a copy from cache to RAM
> -
> -	 We use method 1 on Norwich and on this board too. 
> -	*/
> +	/* Switch from Cache as RAM to real RAM 
> +	 * There are two ways we could think about this.  
> +	 *
> +	 * 1. If we are using the auto.inc ROMCC way, the stack is
> +	 * going to be re-setup in the code following this code.  Just
> +	 * wbinvd the stack to clear the cache tags.  We don't care
> +	 * where the stack used to be.
> +	 * 
> +	 * 2. This file is built as a normal .c -> .o and linked in
> +	 * etc.  The stack might be used to return etc.  That means we
> +	 * care about what is in the stack.  If we are smart we set
> +	 * the CAR stack to the same location as the rest of
> +	 * LinuxBIOS. If that is the case we can just do a wbinvd.
> +	 * The stack will be written into real RAM that is now setup
> +	 * and we continue like nothing happened.  If the stack is
> +	 * located somewhere other than where LB would like it, you
> +	 * need to write some code to do a copy from cache to RAM
> +	 *
> +	 * We use method 1 on Norwich and on this board too. 
> +	 */

Yep, much better.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20071026/d06df6b4/attachment.sig>


More information about the coreboot mailing list