[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