[coreboot] Kconfig Fix for H8QME-2+.

2010-02-24 Thread Knut Kujat 
The attached patch does several fixes so the H8QME-2+ boards builds and
boots successfully with Kconfig.
I also corrected some issues regarding mptables.

/Signed-off-by: Knut Kujat 

---

/Thats all :)

thx,
Knut Kujat
Index: src/mainboard/supermicro/h8qme_fam10/Kconfig
===
--- src/mainboard/supermicro/h8qme_fam10/Kconfig	(revisión: 5149)
+++ src/mainboard/supermicro/h8qme_fam10/Kconfig	(copia de trabajo)
@@ -4,6 +4,7 @@
 	select CPU_AMD_SOCKET_F_1207
 	select NORTHBRIDGE_AMD_AMDFAM10
 	select NORTHBRIDGE_AMD_AMDFAM10_ROOT_COMPLEX
+  select SOUTHBRIDGE_AMD_AMD8132
 	select SOUTHBRIDGE_NVIDIA_MCP55
 	select SUPERIO_WINBOND_W83627HF
 	select HAVE_PIRQ_TABLE
@@ -49,7 +50,7 @@
 
 config HEAP_SIZE
 	hex
-	default 0xc
+	default 0xff000
 	depends on BOARD_SUPERMICRO_H8QME_FAM10
 
 config APIC_ID_OFFSET
@@ -134,10 +135,14 @@
 
 config SERIAL_CPU_INIT
 	bool
-	default n
+	default y
 	depends on BOARD_SUPERMICRO_H8QME_FAM10
 
 config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
 	hex
 	default 0x1511
 	depends on BOARD_SUPERMICRO_H8QME_FAM10
+config STACK_SIZE
+  hex
+  default 0x1
+  depends on BOARD_SUPERMICRO_H8QME_FAM10
Index: src/mainboard/supermicro/h8qme_fam10/devicetree.cb
===
--- src/mainboard/supermicro/h8qme_fam10/devicetree.cb	(revisión: 5149)
+++ src/mainboard/supermicro/h8qme_fam10/devicetree.cb	(copia de trabajo)
@@ -19,87 +19,45 @@
 				irq 0x70 = 6
 				drq 0x74 = 2
 			end
-				device pnp 2e.1 off #  Parallel Port
-	 			io 0x60 = 0x378
-				irq 0x70 = 7
+  device pnp 2e.1 off #  Parallel Port
+   			io 0x60 = 0x378
+   			irq 0x70 = 7
 			end
-				device pnp 2e.2 on #  Com1
-	 			io 0x60 = 0x3f8
-				irq 0x70 = 4
+  device pnp 2e.2 on #  Com1
+   			io 0x60 = 0x3f8
+   			irq 0x70 = 4
 			end
-				device pnp 2e.3 on #  Com2
-	 			io 0x60 = 0x2f8
-				irq 0x70 = 3
+  device pnp 2e.3 off #  Com2
+   			io 0x60 = 0x2f8
+   			irq 0x70 = 3
 			end
-				device pnp 2e.5 on #  Keyboard
-	 			io 0x60 = 0x60
-	 			io 0x62 = 0x64
-				irq 0x70 = 1
-irq 0x72 = 12
+  device pnp 2e.5 on #  Keyboard
+   			io 0x60 = 0x60
+   			io 0x62 = 0x64
+   			irq 0x70 = 1
+			  irq 0x72 = 12
 			end
-				device pnp 2e.6 off  # SFI 
-	 			io 0x62 = 0x100
+  device pnp 2e.6 off  # SFI 
+  			io 0x62 = 0x100
 			end
-				device pnp 2e.7 off #  GPIO_GAME_MIDI
-io 0x60 = 0x220
-io 0x62 = 0x300
-irq 0x70 = 9
+  device pnp 2e.7 off #  GPIO_GAME_MIDI
+				io 0x60 = 0x220
+io 0x62 = 0x300
+irq 0x70 = 9
 			end		
-				device pnp 2e.8 off end #  WDTO_PLED
-				device pnp 2e.9 off end #  GPIO_SUSLED
-				device pnp 2e.a off end #  ACPI
-				device pnp 2e.b on #  HW Monitor
- 	 			io 0x60 = 0x290
-irq 0x70 = 5
-	end
+	device pnp 2e.8 off end #  WDTO_PLED
+	device pnp 2e.9 off end #  GPIO_SUSLED
+	device pnp 2e.a off end #  ACPI
+	device pnp 2e.b on #  HW Monitor
+ 	 			io 0x60 = 0x290
+			 	irq 0x70 = 5
+  end
 		end
 	end
-			device pci 1.1 on # SM 0
-chip drivers/generic/generic #dimm 0-0-0
-device i2c 50 on end  
-end  
-chip drivers/generic/generic #dimm 0-0-1
-device i2c 51 on end
-end 
-chip drivers/generic/generic #dimm 0-1-0
-device i2c 52 on end
-end 
-chip drivers/generic/generic #dimm 0-1-1
-device i2c 53 on end
-end  
-

[coreboot] [commit] r5154 - trunk/src/mainboard/supermicro/h8qme_fam10

2010-02-24 Thread repository service 
Author: oxygene
Date: Wed Feb 24 09:48:35 2010
New Revision: 5154
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5154

Log:
Several fixes to the supermicro/h8qme_fam10 board, so it
builds and boots correctly.

Signed-off-by: Knut Kujat 
Acked-by: Patrick Georgi 

Modified:
   trunk/src/mainboard/supermicro/h8qme_fam10/Kconfig
   trunk/src/mainboard/supermicro/h8qme_fam10/devicetree.cb
   trunk/src/mainboard/supermicro/h8qme_fam10/mptable.c
   trunk/src/mainboard/supermicro/h8qme_fam10/romstage.c

Modified: trunk/src/mainboard/supermicro/h8qme_fam10/Kconfig
==
--- trunk/src/mainboard/supermicro/h8qme_fam10/Kconfig  Tue Feb 23 22:43:42 
2010(r5153)
+++ trunk/src/mainboard/supermicro/h8qme_fam10/Kconfig  Wed Feb 24 09:48:35 
2010(r5154)
@@ -4,6 +4,7 @@
select CPU_AMD_SOCKET_F_1207
select NORTHBRIDGE_AMD_AMDFAM10
select NORTHBRIDGE_AMD_AMDFAM10_ROOT_COMPLEX
+   select SOUTHBRIDGE_AMD_AMD8132
select SOUTHBRIDGE_NVIDIA_MCP55
select SUPERIO_WINBOND_W83627HF
select HAVE_PIRQ_TABLE
@@ -49,7 +50,7 @@
 
 config HEAP_SIZE
hex
-   default 0xc
+   default 0xff000
depends on BOARD_SUPERMICRO_H8QME_FAM10
 
 config APIC_ID_OFFSET
@@ -134,10 +135,15 @@
 
 config SERIAL_CPU_INIT
bool
-   default n
+   default y
depends on BOARD_SUPERMICRO_H8QME_FAM10
 
 config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
hex
default 0x1511
depends on BOARD_SUPERMICRO_H8QME_FAM10
+
+config STACK_SIZE
+   hex
+   default 0x1
+   depends on BOARD_SUPERMICRO_H8QME_FAM10

Modified: trunk/src/mainboard/supermicro/h8qme_fam10/devicetree.cb
==
--- trunk/src/mainboard/supermicro/h8qme_fam10/devicetree.cbTue Feb 23 
22:43:42 2010(r5153)
+++ trunk/src/mainboard/supermicro/h8qme_fam10/devicetree.cbWed Feb 24 
09:48:35 2010(r5154)
@@ -27,7 +27,7 @@
io 0x60 = 0x3f8
irq 0x70 = 4
end
-   device pnp 2e.3 on #  
Com2
+   device pnp 2e.3 off #  
Com2
io 0x60 = 0x2f8
irq 0x70 = 3
end
@@ -54,52 +54,10 @@
end
end
end
-   device pci 1.1 on # SM 0
-chip drivers/generic/generic 
#dimm 0-0-0
-device i2c 50 on end  
-end  
-chip drivers/generic/generic 
#dimm 0-0-1
-device i2c 51 on end
-end 
-chip drivers/generic/generic 
#dimm 0-1-0
-device i2c 52 on end
-end 
-chip drivers/generic/generic 
#dimm 0-1-1
-device i2c 53 on end
-end  
-chip drivers/generic/generic 
#dimm 1-0-0
-device i2c 54 on end
-end 
-chip drivers/generic/generic 
#dimm 1-0-1
-device i2c 55 on end
-end 
-chip drivers/generic/generic 
#dimm 1-1-0
-device i2c 56 on end
-end 
-chip drivers/generic/generic 
#dimm 1-1-1
-device i2c 57 on end
-end 
-   end # SM
+   device pci 1.1 on end
 device pci 1.1 on # SM 1
 #PCI device smbus address will depend on addon pci device, do we need to

Re: [coreboot] Kconfig Fix for H8QME-2+.

2010-02-24 Thread Patrick Georgi 
Am 24.02.2010 09:35, schrieb Knut Kujat:
> The attached patch does several fixes so the H8QME-2+ boards builds and
> boots successfully with Kconfig.
> I also corrected some issues regarding mptables.
> 
> /Signed-off-by: Knut Kujat 
Acked-by: Patrick Georgi 

Committed as r5154. I changed whitespace a bit, so it will probably
conflict on your tree.

Thanks,
Patrick

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Tester hardware

2010-02-24 Thread Carl-Daniel Hailfinger 
On 24.02.2010 01:22, Peter Stuge wrote:
> Ward Vandewege wrote:
>   
 I think a small microcontroller and actual flash chips may be
 the simplest and cheapest way to do it. The microcontroller is
 for flashing from ALIX, maybe also GPO pins and serial port.
 
>>> Speaking with y flashrom hat on, I'd like to point out that you
>>> can use the FT2232H Mini Module (~$30) to perform
>>> in-system-programming (well, as long as the machine is powered of)
>>>   
>
> In-system-programming is worth considering, but for boards with
> sockets it actually just creates extra work. In any case $30 for
> flash programming in the tester hardware is way unacceptable. I'm
>   

I think Ward mentioned that the cost of a dongle was way higher, so I
thought I'd mention something which works right now for SPI and is
significantly cheaper than a dongle.
Besides that, any testing rig has to be automated unless you're willing
to invest boatloads of time per checkin. For that, you either need a
dongle or in-system programming.


> thinking that $10 is already nearly too high cost, but on the other
> hand it buys a very nice ARM7 with USB, which could be reused also
> independently of the tester.
>   

For 6 EUR you can get a FT2232H (chip only), but you have to design a
circuit for it. The advantage of the FT2232H is that it speaks SPI
natively and reasonable speeds (a few MHz).

I know that someone is selling an ATTiny based design to do in-system
SPI programming, and it would be easy to code up flashrom support for
it. I haven't been able to contact the vendor, though.

If you plan to design that hardware yourself, let me list the requirements:
For SPI, all you need is 4 GPIOs (CLK/MISO/MOSI/CS).
For LPC/FWH, all you need is 6 GPIOs (AD[0-3]/CLK/FRAME).
For Parallel, you need a boatload of GPIOs or some demultiplexer.
More GPIOs (e.g. HOLD/WP for SPI and RST/ID/WP for LPC/FWH) are always
useful, but not a hard requirement. They can be used to speed up
programming or make it more reliable.
Vcc and GND are not listed above because they are not GPIOs.

Flashrom can deal with bitbanging SPI/LPC/FWH/Parallel (not all of them
merged yet), or it can drive programmers which understand those
protocols and just want higher-level commands (send command xy to
flash). The bitbanging variant is obviously slower than a
protocol-understanding external programmer.

Why am I listing the requirements above? I just want to avoid that
someone creates a nice piece of hardware, and afterwards notices that
he/she needs to modify the design because some key requirement was
overlooked.
If you have a proposed design, send the details to flash...@flashrom.org
so that the flashrom developers can have a look and suggest changes (if
needed).


>> What kind of hardware would one use to hook the spi chip to the
>> mini module?
>> 
>
> This is the question. Anything socketed is easy, but soldered down
> chips make it more difficult. For SO-8 I've only seen the IC-CLIP by
> Pomona, which doesn't attach with a very sturdy connection to chips. :\
>   

There's always the option of soldering a few wires to the pins of the
chip. Not exactly a clean solution, but it should work fine if you plan
permanent dedication of the machine to the test rig.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Tester hardware

2010-02-24 Thread Carl-Daniel Hailfinger 
On 24.02.2010 01:04, Ward Vandewege wrote:
> On Wed, Feb 24, 2010 at 12:14:30AM +0100, Carl-Daniel Hailfinger wrote:
>   
>> Speaking with y flashrom hat on, I'd like to point out that you can use
>> the FT2232H Mini Module (~$30) to perform in-system-programming (well,
>> as long as the machine is powered of) of SPI flash chips right now and
>> 
>
> Oh. That sounds like a much more affordable solution! What kind of hardware
> would one use to hook the spi chip to the mini module? Some sort of top hat?
>   

Basically yes. Or you solder a few wires on top of the chip pins.


>> of LPC/FWH chips in the near future. 
>> 
>
> I guess for lpc/fwh (plcc), one of the plcc adapters Peter and Stepan make 
> would
> do.
>   

Note that my suggestion does not perform flash emulation like the
dongle, it only provides a way to write chips with an external
programmer. Due to that, the PLCC adapters make it easier to connect to
the pins of the chip socket (if there is a socket), but you'll have to
stack a reverse adapter on top which has a flash chip inside. Or you use
a top-hat style adapter and plug the PLCC adapter in it. The common
requirement is to keep the flash chip attached to the board in a way
that allows booting.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Executing bootstrap from MBR in coreboot

2010-02-24 Thread Carl-Daniel Hailfinger 
On 24.02.2010 08:38, Piotr Piwko wrote:
> 2010/2/23 Peter Stuge :
>   
>> As Joseph pointed out you could look at SeaBIOS, which has quickly
>> become a very complete BIOS implementation. SeaBIOS runs well as a
>> coreboot payload, and if you combine coreboot and SeaBIOS you will
>> indeed have a legacy compatible open source firmware.
>> 
>
> I'm afraid that I will have to write my own part of code which will be
> responsible to execute a boostrap.
>   

That means you have to recreate maybe 90% of SeaBIOS. You need harddisk
drivers, interrupt services, ...
Changing SeaBIOS to work in your environment will be way easier. The
SeaBIOS mailing list  is the preferred
way to ask for help with that.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] AMD HT link frequency limit configuration patch

2010-02-24 Thread Peter Stuge 
Timothy Pearson wrote:
> This patch allows the user to select a maximum HyperTransport link
> frequency.

I like this a lot.

> +++ src/northbridge/amd/amdht/h3finit.c   (working copy)
> @@ -1327,7 +1327,25 @@
>  
>   for (i = 0; i < pDat->TotalLinks*2; i += 2)
>   {
> - cbPCBFreqLimit = 0x;
> +#if CONFIG_LIMIT_HT_SPEED_200
> + cbPCBFreqLimit = 0x0001;// 200MHz

But shouldn't this also be tied in with Kconfig files, with the
correct maximum selected for each board? (An expert mode could allow
overclocking though.)

Oh, and the comments seem redundant to me, especially if Kconfig also
gets involved in this. Maybe it already is, even?


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [commit] r5154 - trunk/src/mainboard/supermicro/h8qme_fam10

2010-02-24 Thread Peter Stuge 
repository service wrote:
> +++ trunk/src/mainboard/supermicro/h8qme_fam10/devicetree.cb  Wed Feb 24 
> 09:48:35 2010(r5154)
> @@ -142,6 +93,18 @@
>   device pci 18.3 on end
>   device pci 18.4 on end
>   device pci 19.0 on end
> + device pci 19.0 on end
> + device pci 19.0 on
> + chip southbridge/amd/amd8132

Why so many 19.0?


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Kconfig Fix for H8QME-2+.

2010-02-24 Thread Stefan Reinauer 
On 2/24/10 9:35 AM, Knut Kujat wrote:
> The attached patch does several fixes so the H8QME-2+ boards builds and
> boots successfully with Kconfig.
> I also corrected some issues regarding mptables.
>
> /Signed-off-by: Knut Kujat 
>   
Wow... about a Megabyte of heap and 64kb stack? That's quite a lot... It
will definitely break S3 as it's currently implemented (assumes that all
of coreboot fits in 1MB, code, heap, stack)

Stefan

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [commit] r5155 - trunk/src/northbridge/intel/e7501

2010-02-24 Thread repository service 
Author: stepan
Date: Wed Feb 24 14:09:09 2010
New Revision: 5155
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5155

Log:
Remove register pressure from e7501 driver by not indirectly referencing
0:0.0 through a struct passed all through the code. This behavior makes a lot
of sense for CPUs with a memory controller built-in. But this is not the case
for the e7501.

Signed-off-by: Stefan Reinauer 
Acked-by: Ronald G. Minnich 
Acked-by: Uwe Hermann 

Modified:
   trunk/src/northbridge/intel/e7501/raminit.c

Modified: trunk/src/northbridge/intel/e7501/raminit.c
==
--- trunk/src/northbridge/intel/e7501/raminit.c Wed Feb 24 09:48:35 2010
(r5154)
+++ trunk/src/northbridge/intel/e7501/raminit.c Wed Feb 24 14:09:09 2010
(r5155)
@@ -807,8 +807,7 @@
 
 
//--
 // Function:   do_ram_command
-// Parameters: ctrl - PCI addresses of memory controller functions, and
-// SMBus addresses of DIMM slots 
on the mainboard
+// Parameters: 
 // command - specifies the command to be 
sent to the DIMMs:
 // RAM_COMMAND_NOP 
- No Operation
 // RAM_COMMAND_PRECHARGE   - 
Precharge all banks
@@ -821,8 +820,7 @@
 // Return Value:   None
 // Description:Send the specified command to all DIMMs.
 //
-static void do_ram_command(const struct mem_controller *ctrl, uint8_t command, 
-  uint16_t jedec_mode_bits) 
+static void do_ram_command(uint8_t command, uint16_t jedec_mode_bits) 
 {
 int i;
uint32_t dram_controller_mode;
@@ -830,10 +828,10 @@
uint16_t e7501_mode_bits = jedec_mode_bits;
 
// Configure the RAM command
-dram_controller_mode = pci_read_config32(ctrl->d0, DRC);
+dram_controller_mode = pci_read_config32(PCI_DEV(0, 0, 0), DRC);
 dram_controller_mode &= 0xFF8F;
 dram_controller_mode |= command;
-pci_write_config32(ctrl->d0, DRC, dram_controller_mode);
+pci_write_config32(PCI_DEV(0, 0, 0), DRC, dram_controller_mode);
 
// RAM_COMMAND_NORMAL is an exception. 
// It affects only the memory controller and does not need to be "sent" 
to the DIMMs.
@@ -865,7 +863,7 @@
 
for (i = 0; i < (MAX_NUM_CHANNELS * 
MAX_DIMM_SOCKETS_PER_CHANNEL); ++i) {
 
-   uint8_t dimm_end_64M_multiple = 
pci_read_config8(ctrl->d0, DRB_ROW_0 + i);
+   uint8_t dimm_end_64M_multiple = 
pci_read_config8(PCI_DEV(0, 0, 0), DRB_ROW_0 + i);
if (dimm_end_64M_multiple > dimm_start_64M_multiple) {
 
// This code assumes DRAM row boundaries are 
all set below 4 GB
@@ -890,19 +888,17 @@
 
 
//--
 // Function:   set_ram_mode
-// Parameters: ctrl - PCI addresses of memory controller functions, and
-// SMBus addresses of DIMM slots 
on the mainboard
-// jedec_mode_bits - for mode register set 
& extended mode register set
-// commands, bits 0-12 contain the 
register value in JEDEC format.
+// Parameters: jedec_mode_bits - for mode register set & extended mode 
register set
+// commands, bits 0-12 contain the register value in JEDEC 
format.
 // Return Value:   None
 // Description:Set the mode register of all DIMMs. The proper CAS# 
latency 
 // setting is added to the mode bits 
specified by the caller.
 //
-static void set_ram_mode(const struct mem_controller *ctrl, uint16_t 
jedec_mode_bits)
+static void set_ram_mode(uint16_t jedec_mode_bits)
 {
ASSERT(!(jedec_mode_bits & SDRAM_CAS_MASK));
 
-   uint32_t dram_cas_latency = pci_read_config32(ctrl->d0, DRT) & 
DRT_CAS_MASK;
+   uint32_t dram_cas_latency = pci_read_config32(PCI_DEV(0, 0, 0), DRT) & 
DRT_CAS_MASK;

switch (dram_cas_latency) {
case DRT_CAS_2_5:
@@ -918,7 +914,7 @@
break;
}
 
-   do_ram_command(ctrl, RAM_COMMAND_MRS, jedec_mode_bits);
+   do_ram_command(RAM_COMMAND_MRS, jedec_mode_bits);
 }
 
 
/**/
@@ -927,8 +923,7 @@
 
 
//--
 // Function:   configure_dimm_row_boundaries
-// Parameters: ctrl - PCI addresses of memory controller functions, and
-// SMBus addresses of DIMM slots 
on the mainboard
+// Parameters:

[coreboot] [commit] r5156 - in trunk: . src/arch/i386

2010-02-24 Thread repository service 
Author: stepan
Date: Wed Feb 24 14:18:01 2010
New Revision: 5156
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5156

Log:
This patch fixes an issue with the wrong build rules being selected.
Make is free to choose any fitting rule for a target, and so some 
obj-y files were compiled with initobj flags. This patch also fixes
the behavior for objects being both in initobj and obj.

At the moment all object rules are the same, but if we start not including
all .c files in romstage.c anymore we need to define __PRE_RAM__ in the 
initobj rule and that's when things start breaking.

Signed-off-by: Patrick Georgi 
Acked-by: Stefan Reinauer 

Modified:
   trunk/Makefile
   trunk/src/arch/i386/Makefile.bigbootblock.inc
   trunk/src/arch/i386/Makefile.tinybootblock.inc

Modified: trunk/Makefile
==
--- trunk/Makefile  Wed Feb 24 14:09:09 2010(r5155)
+++ trunk/Makefile  Wed Feb 24 14:18:01 2010(r5156)
@@ -126,6 +126,10 @@
 subdirs:=$(PLATFORM-y) $(BUILD-y)
 $(eval $(call evaluate_subdirs, modify))
 
+initobjs:=$(addsuffix .initobj.o, $(basename $(initobjs)))
+drivers:=$(addsuffix .driver.o, $(basename $(drivers)))
+smmobjs:=$(addsuffix .smmobj.o, $(basename $(smmobjs)))
+
 allobjs:=$(foreach var, $(addsuffix s,$(types)), $($(var)))
 alldirs:=$(sort $(abspath $(dir $(allobjs
 source_with_ext=$(patsubst $(obj)/%.o,src/%.$(1),$(allobjs))
@@ -160,37 +164,37 @@
 endef
 
 define initobjs_c_template
-$(obj)/$(1)%.o: src/$(1)%.c $(obj)/config.h
+$(obj)/$(1)%.initobj.o: src/$(1)%.c $(obj)/config.h
@printf "CC $$(subst $$(obj)/,,$$(@))\n"
$(CC) -m32 $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define initobjs_S_template
-$(obj)/$(1)%.o: src/$(1)%.S $(obj)/config.h
+$(obj)/$(1)%.initobj.o: src/$(1)%.S $(obj)/config.h
@printf "CC $$(subst $$(obj)/,,$$(@))\n"
$(CC) -m32 -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define drivers_c_template
-$(obj)/$(1)%.o: src/$(1)%.c $(obj)/config.h
+$(obj)/$(1)%.driver.o: src/$(1)%.c $(obj)/config.h
@printf "CC $$(subst $$(obj)/,,$$(@))\n"
$(CC) -m32 $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define drivers_S_template
-$(obj)/$(1)%.o: src/$(1)%.S
+$(obj)/$(1)%.driver.o: src/$(1)%.S
@printf "CC $$(subst $$(obj)/,,$$(@))\n"
$(CC) -m32 -DASSEMBLY $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define smmobjs_c_template
-$(obj)/$(1)%.o: src/$(1)%.c
+$(obj)/$(1)%.smmobj.o: src/$(1)%.c
@printf "CC $$(subst $$(obj)/,,$$(@))\n"
$(CC) -m32 $$(CFLAGS) -c -o $$@ $$<
 endef
 
 define smmobjs_S_template
-$(obj)/$(1)%.o: src/$(1)%.S
+$(obj)/$(1)%.smmobj.o: src/$(1)%.S
@printf "CC $$(subst $$(obj)/,,$$(@))\n"
$(CC) -m32 $$(CFLAGS) -c -o $$@ $$<
 endef

Modified: trunk/src/arch/i386/Makefile.bigbootblock.inc
==
--- trunk/src/arch/i386/Makefile.bigbootblock.inc   Wed Feb 24 14:09:09 
2010(r5155)
+++ trunk/src/arch/i386/Makefile.bigbootblock.inc   Wed Feb 24 14:18:01 
2010(r5156)
@@ -22,7 +22,7 @@
@printf "GEN$(subst $(obj)/,,$(@))\n"
printf '$(foreach crt0,config.h $(crt0s),#include 
"$(crt0:$(obj)/%=%)"\n)' > $@
 
-$(obj)/mainboard/$(MAINBOARDDIR)/crt0.o: 
$(obj)/mainboard/$(MAINBOARDDIR)/crt0.s
+$(obj)/mainboard/$(MAINBOARDDIR)/crt0.initobj.o: 
$(obj)/mainboard/$(MAINBOARDDIR)/crt0.s
$(CC) -I$(obj) -Wa,-acdlns -c -o $@ $<  > $(dir $@)/crt0.disasm
 
 $(obj)/mainboard/$(MAINBOARDDIR)/crt0.s: $(src)/arch/i386/init/crt0.S.lb 
$(obj)/crt0_includes.h

Modified: trunk/src/arch/i386/Makefile.tinybootblock.inc
==
--- trunk/src/arch/i386/Makefile.tinybootblock.inc  Wed Feb 24 14:09:09 
2010(r5155)
+++ trunk/src/arch/i386/Makefile.tinybootblock.inc  Wed Feb 24 14:18:01 
2010(r5156)
@@ -95,7 +95,7 @@
mkdir -p $(obj)/romstage
printf '$(foreach crt0,config.h $(crt0s),#include 
"$(crt0:$(obj)/%=%)"\n)' > $@
 
-$(obj)/mainboard/$(MAINBOARDDIR)/crt0.o: 
$(obj)/mainboard/$(MAINBOARDDIR)/crt0.s
+$(obj)/mainboard/$(MAINBOARDDIR)/crt0.initobj.o: 
$(obj)/mainboard/$(MAINBOARDDIR)/crt0.s
$(CC) -I$(obj) -Wa,-acdlns -c -o $@ $<  > $(dir $@)/crt0.disasm
 
 $(obj)/mainboard/$(MAINBOARDDIR)/crt0.s: $(src)/arch/i386/init/crt0.S.lb 
$(obj)/romstage/crt0_includes.h

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Tester hardware

2010-02-24 Thread Peter Stuge 
Carl-Daniel Hailfinger wrote:
> avoid that someone creates a nice piece of hardware, and afterwards
> notices that he/she needs to modify the design because some key
> requirement was overlooked.

I wouldn't worry.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [commit] r5154 - trunk/src/mainboard/supermicro/h8qme_fam10

2010-02-24 Thread Stefan Reinauer 
On 2/24/10 1:59 PM, Peter Stuge wrote:
> repository service wrote:
>   
>> +++ trunk/src/mainboard/supermicro/h8qme_fam10/devicetree.cb Wed Feb 24 
>> 09:48:35 2010(r5154)
>> @@ -142,6 +93,18 @@
>>  device pci 18.3 on end
>>  device pci 18.4 on end
>>  device pci 19.0 on end
>> +device pci 19.0 on end
>> +device pci 19.0 on
>> +chip southbridge/amd/amd8132
>> 
> Why so many 19.0?
>   
Because an opteron CPU has three hypertransport links. Each device
reflects one of the links.

BUT: This is an overspecification in the device tree and it will likely
fail, print errors or otherwise do the wrong thing if you only put 2
CPUs on that board.
The selection of the driver in Kconfig should be enough for coreboot to
do the right thing. Is it not?

+  select SOUTHBRIDGE_AMD_AMD8132

Stefan




-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH]fallback/normal for kconfig, selectable tinybootblock handler

2010-02-24 Thread Stefan Reinauer 
On 2/10/10 8:04 PM, Patrick Georgi wrote:
> Hi,
>
> The attached patch allows the user to select one of multiple
> tinybootblock handlers. It also adds a new handler that provides
> fallback/normal behaviour (run normal iff CMOS says so and is present).
>
> The handler doesn't work yet (at least in my tests), but should be
> close. I mostly push this to start a discussion on how we want that part
> of coreboot to work.
>
> The idea would be to install the "normal" handler and fallback images in
> one pass, and normal images in a later pass using the already commited
> update feature.
>
> More special operations in tinybootblock become possible, too - maybe
> "run flashrom_romstage if GPIO x is triggered", or "run images X if
> cpuid is X, images Y if cpuid is Y".
>
> To apply the patch, src/arch/i386/init/bootblock.c must be copied to
>   src/arch/i386/include/tinybootblock_common.h
>   src/arch/i386/init/tinybootblock_normal.c
>   src/arch/i386/init/tinybootblock_simple.c
> and bootblock.c itself be removed (the patch does that, but your
> patch(1) might not delete the file properly).
>
>
> Signed-off-by: Patrick Georgi 
>   
Acked-by: Stefan Reinauer 
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] RCC chipset support?

2010-02-24 Thread Jochum Doring 

Dear Coreboot,

I am following this project for a while now and i am thinking about 
using coreboot on an old server i have.

It is an HP Visualize X-class (A1280) with an RCC Serverset III WS chipset.

I noticed it wasn't listed as supported, but i was still wondering if 
this could work.

Thanks in advance.

Cheers, Jochum


--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Kconfig Fix for H8QME-2+.

2010-02-24 Thread Knut Kujat 
Stefan Reinauer escribió:
> On 2/24/10 9:35 AM, Knut Kujat wrote:
>   
>> The attached patch does several fixes so the H8QME-2+ boards builds and
>> boots successfully with Kconfig.
>> I also corrected some issues regarding mptables.
>>
>> /Signed-off-by: Knut Kujat 
>>   
>> 
> Wow... about a Megabyte of heap and 64kb stack? That's quite a lot... It
> will definitely break S3 as it's currently implemented (assumes that all
> of coreboot fits in 1MB, code, heap, stack)
>
> Stefan
>
>   
Hi,

the big heap is because of some experiments I was doing with some htx
cards on one it told me at a certain point of the boot process that
malloc failed so I started increasing the heap size  until I was so
annoyed about none of the values were working so I "aimed high" but
without card I got it booting with  heap size = 0xc000. So which value
should go into the Kconfig file ? I guess 0xc000?!

Thx,
Knut Kujat.

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [commit] r5154 - trunk/src/mainboard/supermicro/h8qme_fam10

2010-02-24 Thread Knut Kujat 
Stefan Reinauer escribió:
> On 2/24/10 1:59 PM, Peter Stuge wrote:
>   
>> repository service wrote:
>>   
>> 
>>> +++ trunk/src/mainboard/supermicro/h8qme_fam10/devicetree.cbWed Feb 
>>> 24 09:48:35 2010(r5154)
>>> @@ -142,6 +93,18 @@
>>> device pci 18.3 on end
>>> device pci 18.4 on end
>>> device pci 19.0 on end
>>> +   device pci 19.0 on end
>>> +   device pci 19.0 on
>>> +   chip southbridge/amd/amd8132
>>> 
>>>   
>> Why so many 19.0?
>>   
>> 
> Because an opteron CPU has three hypertransport links. Each device
> reflects one of the links.
>
> BUT: This is an overspecification in the device tree and it will likely
> fail, print errors or otherwise do the wrong thing if you only put 2
> CPUs on that board.
> The selection of the driver in Kconfig should be enough for coreboot to
> do the right thing. Is it not?
>
> +  select SOUTHBRIDGE_AMD_AMD8132
>
> Stefan
>
>
>
>   
Hi,

I read in earlier mailing list entries that it is not necessary to put
all 4 cpu in the device tree since coreboot detects them automatically.
So I only go with 18 because it got the MCP 55 and 19 because thats
where the amd 8132 is. If you thing it is better to put all 4 cpu in the
device tree to avoid trouble I will do that.

THX,
Knut Kujat.

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Tester hardware

2010-02-24 Thread Peter Stuge 
Carl-Daniel Hailfinger wrote:
> >> What kind of hardware would one use to hook the spi chip to the
> >
> > For SO-8 I've only seen the IC-CLIP by Pomona, which doesn't
> > attach with a very sturdy connection to chips. :\
> 
> There's always the option of soldering a few wires to the pins

A flex cable with a cutout. It requires a little bit of clearance
around the flash chip though, which may not neccessarily be the case.

To get an idea of what I mean see:

http://www.foundmy.com/oscom/images/fm-d2ckey-flex-cable.jpg


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [commit] r5157 - in trunk/src/arch/i386: . include init

2010-02-24 Thread repository service 
Author: oxygene
Date: Wed Feb 24 14:58:23 2010
New Revision: 5157
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5157

Log:
Enable user selectable bootblocks, and provide a bootblock that
selects between "fallback" and "normal", in addition to the
already present "fallback"-only bootblock.

Signed-off-by: Patrick Georgi 
Acked-by: Stefan Reinauer 

Added:
   trunk/src/arch/i386/Makefile.bootblock.inc
  - copied, changed from r5156, 
trunk/src/arch/i386/Makefile.tinybootblock.inc
   trunk/src/arch/i386/include/bootblock_common.h
  - copied, changed from r5156, trunk/src/arch/i386/init/bootblock.c
   trunk/src/arch/i386/init/bootblock_normal.c
  - copied, changed from r5156, trunk/src/arch/i386/init/bootblock.c
   trunk/src/arch/i386/init/bootblock_simple.c
  - copied, changed from r5156, trunk/src/arch/i386/init/bootblock.c
Deleted:
   trunk/src/arch/i386/Makefile.tinybootblock.inc
   trunk/src/arch/i386/init/bootblock.c
Modified:
   trunk/src/arch/i386/Kconfig
   trunk/src/arch/i386/Makefile.inc

Modified: trunk/src/arch/i386/Kconfig
==
--- trunk/src/arch/i386/Kconfig Wed Feb 24 14:18:01 2010(r5156)
+++ trunk/src/arch/i386/Kconfig Wed Feb 24 14:58:23 2010(r5157)
@@ -49,6 +49,24 @@
default n if TINY_BOOTBLOCK
default y
 
+choice
+   prompt "Bootblock behaviour"
+   default BOOTBLOCK_SIMPLE
+   depends on TINY_BOOTBLOCK
+
+config BOOTBLOCK_SIMPLE
+   bool "Always load fallback"
+
+config BOOTBLOCK_NORMAL
+   bool "Switch to normal if CMOS says so"
+
+endchoice
+
+config BOOTBLOCK_SOURCE
+   string
+   default "bootblock_simple.c" if BOOTBLOCK_SIMPLE
+   default "bootblock_normal.c" if BOOTBLOCK_NORMAL
+
 config UPDATE_IMAGE
bool "Update existing coreboot.rom image"
default n

Copied and modified: trunk/src/arch/i386/Makefile.bootblock.inc (from r5156, 
trunk/src/arch/i386/Makefile.tinybootblock.inc)
==
--- trunk/src/arch/i386/Makefile.tinybootblock.inc  Wed Feb 24 14:18:01 
2010(r5156, copy source)
+++ trunk/src/arch/i386/Makefile.bootblock.inc  Wed Feb 24 14:58:23 2010
(r5157)
@@ -63,7 +63,7 @@
 $(obj)/mainboard/$(MAINBOARDDIR)/bootblock.s: $(obj)/bootblock/bootblock.c
$(CC) -x assembler-with-cpp -DASSEMBLY -E -I$(src)/include 
-I$(src)/arch/i386/include -I$(obj) -I$(obj)/bootblock -include $(obj)/config.h 
-I. -I$(src) $< > $...@.new && mv $...@.new $@
 
-$(obj)/mainboard/$(MAINBOARDDIR)/bootblock.inc: 
$(src)/arch/i386/init/bootblock.c $(obj)/romcc
+$(obj)/mainboard/$(MAINBOARDDIR)/bootblock.inc: $(src)/arch/i386/init/$(subst 
",,$(CONFIG_BOOTBLOCK_SOURCE)) $(obj)/romcc
$(obj)/romcc $(bootblock_romccflags) -O2 $(ROMCCFLAGS) $(INCLUDES) $< 
-o $@
 
 $(obj)/bootblock.elf: $(obj)/mainboard/$(MAINBOARDDIR)/bootblock.o 
$(obj)/bootblock/ldscript.ld

Modified: trunk/src/arch/i386/Makefile.inc
==
--- trunk/src/arch/i386/Makefile.incWed Feb 24 14:18:01 2010(r5156)
+++ trunk/src/arch/i386/Makefile.incWed Feb 24 14:58:23 2010(r5157)
@@ -95,7 +95,7 @@
 endif
 
 ifeq ($(CONFIG_TINY_BOOTBLOCK),y)
-include $(src)/arch/i386/Makefile.tinybootblock.inc
+include $(src)/arch/i386/Makefile.bootblock.inc
 else
 include $(src)/arch/i386/Makefile.bigbootblock.inc
 endif

Copied and modified: trunk/src/arch/i386/include/bootblock_common.h (from 
r5156, trunk/src/arch/i386/init/bootblock.c)
==
--- trunk/src/arch/i386/init/bootblock.cWed Feb 24 14:18:01 2010
(r5156, copy source)
+++ trunk/src/arch/i386/include/bootblock_common.h  Wed Feb 24 14:58:23 
2010(r5157)
@@ -31,17 +31,3 @@
 {
asm volatile ("jmp *%0\n\t" : : "r" (addr), "a" (bist));
 }
-
-static void main(unsigned long bist)
-{
-   if (boot_cpu()) {
-   bootblock_northbridge_init();
-   bootblock_southbridge_init();
-   }
-   const char* target1 = "fallback/romstage";
-   unsigned long entry;
-   entry = findstage(target1);
-   if (entry) call(entry, bist);
-   asm volatile ("1:\n\thlt\n\tjmp 1b\n\t");
-}
-

Copied and modified: trunk/src/arch/i386/init/bootblock_normal.c (from r5156, 
trunk/src/arch/i386/init/bootblock.c)
==
--- trunk/src/arch/i386/init/bootblock.cWed Feb 24 14:18:01 2010
(r5156, copy source)
+++ trunk/src/arch/i386/init/bootblock_normal.c Wed Feb 24 14:58:23 2010
(r5157)
@@ -1,36 +1,8 @@
-#define __PRE_RAM__
-#if CONFIG_LOGICAL_CPUS && \
- (defined(CONFIG_BOOTBLOCK_NORTHBRIDGE_INIT) || 
defined(CONFIG_BOOTBLOCK_SOUTHBRIDGE_INIT))
-#include 
-#else
-#define boot_cpu(x) 1
-#endif
-
-#ifdef CONFIG_BOOTBLOCK_NORTH

Re: [coreboot] Executing bootstrap from MBR in coreboot

2010-02-24 Thread Peter Stuge 
Piotr Piwko wrote:
> I'm afraid that I will have to write my own part of code which will
> be responsible to execute a boostrap. At this moment I use the old
> version of coreboot project (practically LinuxBIOS 2.0.0), because
> only in this release my target board (MSM800BEV) is fully supported
> out of the box.

It would really be nice if you could help make this target work with
the updated coreboot sources.

I would actually expect this to require only moderate effort.


> Unfortunately, it doesn't contain the
> 
> uint64_t high_tables_base = 0;
> uint64_t high_tables_size;
> 
> variables which are necessary to proper SeaBIOS work (according
> with http://www.coreboot.org/SeaBIOS document).
> 
> Maybe do you have any documents or advices about using SeaBIOS with
> this coreboot version?

Then there are basically two choices;

1. Backport support for high tables from current code
2. Fix current code for your target

I would strongly prefer option 2.

Can you show us boot logs from your working version and from the
very latest version?


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] MP table multicore patch

2010-02-24 Thread Myles Watson 
On Wed, Feb 24, 2010 at 12:26 AM, Timothy Pearson <
tpear...@raptorengineeringinc.com> wrote:

> > So two more steps are necessary:
> > - check all the downwards links of a device instead of just walking
> devices
> > and checking their type.
> > - run recursively in a special case on APIC clusters.
> >
> > This sounds a whole lot like something changed in the way "all_devices"
> > works. And if "all_devices" does not mean "all devices" I am sure there
> are
> > more places in our code that need similar fixes.
>
> This is the crux of the issue.  all_devices does NOT mean "all devices",
> it means "all devices attached to the root node, which is all_devices".
>
You're correct; this is the crux.  Here's a snippet of the fam10 boot log
for SimNOW:

Show all devs...Before Device Enumeration.
Root Device: enabled 1, 0 resources
APIC_CLUSTER: 0: enabled 1, 0 resources
APIC: 00: enabled 1, 0 resources
PCI_DOMAIN: : enabled 1, 0 resources
PCI: 00:18.0: enabled 1, 0 resources
PCI: 00:00.0: enabled 1, 0 resources
PCI: 00:00.1: enabled 1, 0 resources
PCI: 00:01.0: enabled 1, 0 resources
PCI: 00:01.1: enabled 1, 0 resources
PCI: 00:00.0: enabled 1, 0 resources
PCI: 00:00.0: enabled 1, 0 resources
PCI: 00:00.1: enabled 1, 0 resources
PCI: 00:00.2: enabled 0, 0 resources
PCI: 00:01.0: enabled 0, 0 resources
PCI: 00:01.0: enabled 1, 0 resources
PNP: 002e.0: enabled 0, 3 resources
PNP: 002e.1: enabled 0, 2 resources
PNP: 002e.2: enabled 1, 2 resources
PNP: 002e.3: enabled 0, 2 resources
PNP: 002e.5: enabled 1, 4 resources
PNP: 002e.6: enabled 0, 1 resources
PNP: 002e.7: enabled 0, 3 resources
PNP: 002e.8: enabled 0, 0 resources
PNP: 002e.9: enabled 0, 0 resources
PNP: 002e.a: enabled 0, 0 resources
PNP: 002e.b: enabled 1, 2 resources
PCI: 00:01.1: enabled 1, 0 resources
PCI: 00:01.2: enabled 1, 0 resources
PCI: 00:01.3: enabled 1, 0 resources
I2C: 00:18: enabled 1, 0 resources
I2C: 00:50: enabled 1, 0 resources
I2C: 00:51: enabled 1, 0 resources
I2C: 00:52: enabled 1, 0 resources
I2C: 00:53: enabled 1, 0 resources
I2C: 00:50: enabled 1, 0 resources
I2C: 00:51: enabled 1, 0 resources
I2C: 00:52: enabled 1, 0 resources
I2C: 00:53: enabled 1, 0 resources
PCI: 00:01.5: enabled 0, 0 resources
PCI: 00:01.6: enabled 0, 0 resources
PCI: 00:18.1: enabled 1, 0 resources
PCI: 00:18.2: enabled 1, 0 resources
PCI: 00:18.3: enabled 1, 0 resources
PCI: 00:18.4: enabled 1, 0 resources


Compare with tree...
Root Device: enabled 1, 0 resources
 APIC_CLUSTER: 0: enabled 1, 0 resources
  APIC: 00: enabled 1, 0 resources
 PCI_DOMAIN: : enabled 1, 0 resources
  PCI: 00:18.0: enabled 1, 0 resources
   PCI: 00:00.0: enabled 1, 0 resources
   PCI: 00:00.1: enabled 1, 0 resources
   PCI: 00:01.0: enabled 1, 0 resources
   PCI: 00:01.1: enabled 1, 0 resources
   PCI: 00:00.0: enabled 1, 0 resources
PCI: 00:00.0: enabled 1, 0 resources
PCI: 00:00.1: enabled 1, 0 resources
PCI: 00:00.2: enabled 0, 0 resources
PCI: 00:01.0: enabled 0, 0 resources
   PCI: 00:01.0: enabled 1, 0 resources
PNP: 002e.0: enabled 0, 3 resources
PNP: 002e.1: enabled 0, 2 resources
PNP: 002e.2: enabled 1, 2 resources
PNP: 002e.3: enabled 0, 2 resources
PNP: 002e.5: enabled 1, 4 resources
PNP: 002e.6: enabled 0, 1 resources
PNP: 002e.7: enabled 0, 3 resources
PNP: 002e.8: enabled 0, 0 resources
PNP: 002e.9: enabled 0, 0 resources
PNP: 002e.a: enabled 0, 0 resources
PNP: 002e.b: enabled 1, 2 resources
   PCI: 00:01.1: enabled 1, 0 resources
   PCI: 00:01.2: enabled 1, 0 resources
   PCI: 00:01.3: enabled 1, 0 resources
I2C: 00:18: enabled 1, 0 resources
 I2C: 00:50: enabled 1, 0 resources
 I2C: 00:51: enabled 1, 0 resources
 I2C: 00:52: enabled 1, 0 resources
 I2C: 00:53: enabled 1, 0 resources
 I2C: 00:50: enabled 1, 0 resources
 I2C: 00:51: enabled 1, 0 resources
 I2C: 00:52: enabled 1, 0 resources
 I2C: 00:53: enabled 1, 0 resources
   PCI: 00:01.5: enabled 0, 0 resources
   PCI: 00:01.6: enabled 0, 0 resources
  PCI: 00:18.1: enabled 1, 0 resources
  PCI: 00:18.2: enabled 1, 0 resources
  PCI: 00:18.3: enabled 1, 0 resources
  PCI: 00:18.4: enabled 1, 0 resources

There are 44 devices in the tree, and 44 in the all_devices list.  If there
is some place that the list is getting broken, we should fix it.


As the root node, usually the PCI bus and the APICs are visible.  On my
> board, the APICs are all under an APIC cluster, so they are not
> immediately visible from the root node.
>
They're not children of the root node, but they are accessible through the
next pointer:

for (dev = all_devices; dev; dev = dev->next) {
do_printk(debug_level,
  "%s: enabled %d, %d resources\n",
  dev_path(dev), dev->enabled,
  dev->resources);
}




> I don't have access to a board that I can generate before/after tables
> with at this time.  This behavior is very simple to see though; if you
> turn on printk spew and look closely at the p

[coreboot] [commit] r5158 - in trunk/src: mainboard mainboard/winent mainboard/winent/pl6064 superio/winbond/w83627hf

2010-02-24 Thread repository service 
Author: oxygene
Date: Wed Feb 24 17:36:56 2010
New Revision: 5158
URL: http://tracker.coreboot.org/trac/coreboot/changeset/5158

Log:
Add Win Enterprises' PL6064 board

Signed-off-by: Anish K. Patel 
Acked-by: Patrick Georgi 

Added:
   trunk/src/mainboard/winent/
   trunk/src/mainboard/winent/Kconfig
   trunk/src/mainboard/winent/pl6064/
   trunk/src/mainboard/winent/pl6064/Kconfig
   trunk/src/mainboard/winent/pl6064/Makefile.inc
   trunk/src/mainboard/winent/pl6064/chip.h
   trunk/src/mainboard/winent/pl6064/cmos.layout
   trunk/src/mainboard/winent/pl6064/devicetree.cb
   trunk/src/mainboard/winent/pl6064/irq_tables.c
   trunk/src/mainboard/winent/pl6064/mainboard.c
   trunk/src/mainboard/winent/pl6064/romstage.c
Modified:
   trunk/src/mainboard/Kconfig
   trunk/src/superio/winbond/w83627hf/superio.c

Modified: trunk/src/mainboard/Kconfig
==
--- trunk/src/mainboard/Kconfig Wed Feb 24 14:58:23 2010(r5157)
+++ trunk/src/mainboard/Kconfig Wed Feb 24 17:36:56 2010(r5158)
@@ -94,6 +94,8 @@
bool "Tyan"
 config VENDOR_VIA
bool "VIA"
+config VENDOR_WINENT
+   bool "Win Enterprises"
 
 endchoice
 
@@ -352,6 +354,11 @@
default 0x1019
depends on VENDOR_VIA
 
+config MAINBOARD_VENDOR
+   string
+   default "Win Enterprise"
+   depends on VENDOR_WINENT
+
 source "src/mainboard/a-trend/Kconfig"
 source "src/mainboard/abit/Kconfig"
 source "src/mainboard/advantech/Kconfig"
@@ -397,6 +404,7 @@
 source "src/mainboard/thomson/Kconfig"
 source "src/mainboard/tyan/Kconfig"
 source "src/mainboard/via/Kconfig"
+source "src/mainboard/winent/Kconfig"
 
 config BOARD_ROMSIZE_KB_128
bool

Added: trunk/src/mainboard/winent/Kconfig
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ trunk/src/mainboard/winent/Kconfig  Wed Feb 24 17:36:56 2010(r5158)
@@ -0,0 +1,28 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2009 Uwe Hermann 
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+
+choice
+   prompt "Mainboard model"
+   depends on VENDOR_WINENT
+
+source "src/mainboard/winent/pl6064/Kconfig"
+
+endchoice
+

Added: trunk/src/mainboard/winent/pl6064/Kconfig
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ trunk/src/mainboard/winent/pl6064/Kconfig   Wed Feb 24 17:36:56 2010
(r5158)
@@ -0,0 +1,38 @@
+config BOARD_WINENT_PL6064
+   bool "PL6064"
+   select ARCH_X86
+   select CPU_AMD_LX
+   select NORTHBRIDGE_AMD_LX
+   select SOUTHBRIDGE_AMD_CS5536
+   select SUPERIO_WINBOND_W83627HF
+   select HAVE_PIRQ_TABLE
+   select PIRQ_ROUTE
+   select UDELAY_TSC
+   select USE_DCACHE_RAM
+   select USE_PRINTK_IN_CAR
+   select BOARD_ROMSIZE_KB_512
+
+config MAINBOARD_DIR
+   string
+   default winent/pl6064
+   depends on BOARD_WINENT_PL6064
+
+config MAINBOARD_PART_NUMBER
+   string
+   default "PL6064"
+   depends on BOARD_WINENT_PL6064
+
+config HAVE_OPTION_TABLE
+   bool
+   default n
+   depends on BOARD_WINENT_PL6064
+
+config IRQ_SLOT_COUNT
+   int
+   default 7
+   depends on BOARD_WINENT_PL6064
+
+config RAMBASE
+   hex
+   default 0x4000
+   depends on BOARD_WINENT_PL6064

Added: trunk/src/mainboard/winent/pl6064/Makefile.inc
==
--- /dev/null   00:00:00 1970   (empty, because file is newly added)
+++ trunk/src/mainboard/winent/pl6064/Makefile.inc  Wed Feb 24 17:36:56 
2010(r5158)
@@ -0,0 +1,21 @@
+driver-y += mainboard.o
+
+# Needed by irq_tables and mptable and acpi_tables.
+obj-$(CONFIG_GENERATE_PIRQ_TABLE) += irq_tables.o
+
+# This is part of the conversion to init-obj and away from included code.
+
+initobj-y += crt0.o
+crt0s := $(src)/cpu/x86/16bit/entry16.inc
+crt0s += $(src)/cpu/x86/32bit/entry32.inc
+crt0s += $(src)/cpu/x86/16bit/reset16.inc
+crt0s += $(src)/arch/i386/lib/id.inc
+crt0s += $(src)/cpu/amd/model_lx/cache_as_ram.inc
+crt0s += $(obj)/mainboard/$(MAINBOARDD

Re: [coreboot] Executing bootstrap from MBR in coreboot

2010-02-24 Thread Piotr Piwko 
2010/2/24 Peter Stuge :
> Piotr Piwko wrote:
>> I'm afraid that I will have to write my own part of code which will
>> be responsible to execute a boostrap. At this moment I use the old
>> version of coreboot project (practically LinuxBIOS 2.0.0), because
>> only in this release my target board (MSM800BEV) is fully supported
>> out of the box.
>
> It would really be nice if you could help make this target work with
> the updated coreboot sources.

I would really like to do this job, but unfortunately I currently work
on the quite urgent project and I don't enough time and energy to join
to another project. Anyway, I am impressed with your work and I hope
that I will be able to help in the future.

> Then there are basically two choices;
> 1. Backport support for high tables from current code
> 2. Fix current code for your target
> I would strongly prefer option 2.

I've decided to write my own code to execute bootstrap from MBR. At
this moment I test the functions which are responsible for ATA
protocol support. If I have any positive results, I will post my
observations.

> Can you show us boot logs from your working version and from the
> very latest version?

I'm going to do this as soon as possible.

-- 
Piotr Piwko
http://www.embedded-engineering.pl/

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] AMD HT link frequency limit configuration patch

2010-02-24 Thread Timothy Pearson 
Here is a new patch that utilizes KConfig in expert mode.  Also, the HT
width is now configurable as well.

This patch is critical for the MSI MS-9652 mainboard and Barcelona CPUs;
without limiting the HT link the system was completely unstable due to bad
PCB layout.

---

Signed-off-by: Timothy Pearson 

Timothy Pearson
Raptor EngineeringIndex: src/Kconfig
===
--- src/Kconfig	(revision 5158)
+++ src/Kconfig	(working copy)
@@ -56,6 +56,78 @@
 comment "CPU"
 source src/cpu/Kconfig
 comment "Northbridge"
+
+menu "HyperTransport Setup"
+	depends on (NORTHBRIDGE_AMD_AMDK8 || NORTHBRIDGE_AMD_AMDFAM10) && EXPERT
+
+choice
+	prompt "HyperTransport Frequency"
+	default LIMIT_HT_SPEED_AUTO
+	help
+	  This option sets the maximum permissible HyperTransport link frequency.
+	  Use of this option will only limit the autodetected HT frequency; it will not (and cannot) increase the frequency beyond the autodetected limits.
+	  This is primarily used to work around poorly designed or laid out HT traces on certain motherboards.
+
+config LIMIT_HT_SPEED_200
+	bool "Limit HT frequency to 200MHz"
+config LIMIT_HT_SPEED_400
+	bool "Limit HT frequency to 400MHz"
+config LIMIT_HT_SPEED_600
+	bool "Limit HT frequency to 600MHz"
+config LIMIT_HT_SPEED_800
+	bool "Limit HT frequency to 800MHz"
+config LIMIT_HT_SPEED_1000
+	bool "Limit HT frequency to 1.0GHz"
+config LIMIT_HT_SPEED_1200
+	bool "Limit HT frequency to 1.2GHz"
+config LIMIT_HT_SPEED_1400
+	bool "Limit HT frequency to 1.4GHz"
+config LIMIT_HT_SPEED_1600
+	bool "Limit HT frequency to 1.6GHz"
+config LIMIT_HT_SPEED_1800
+bool "Limit HT frequency to 1.6GHz"
+config LIMIT_HT_SPEED_2000
+bool "Limit HT frequency to 2.0GHz"
+config LIMIT_HT_SPEED_2200
+bool "Limit HT frequency to 2.2GHz"
+config LIMIT_HT_SPEED_2400
+bool "Limit HT frequency to 2.4GHz"
+config LIMIT_HT_SPEED_2600
+bool "Limit HT frequency to 2.6GHz"
+config LIMIT_HT_SPEED_AUTO
+	bool "Autodetect HT frequency"
+endchoice
+
+choice
+	prompt "HyperTransport Downlink Width"
+	default LIMIT_HT_DOWN_WIDTH_16
+	help
+	  This option sets the maximum permissible HyperTransport link width.
+	  Use of this option will only limit the autodetected HT width; it will not (and cannot) increase the width beyond the autodetected limits.
+	  This is primarily used to work around poorly designed or laid out HT traces on certain motherboards.
+
+config LIMIT_HT_DOWN_WIDTH_8
+	bool "8 bits"
+config LIMIT_HT_DOWN_WIDTH_16
+	bool "16 bits"
+endchoice
+
+choice
+	prompt "HyperTransport Uplink Width"
+	default LIMIT_HT_UP_WIDTH_16
+	help
+	  This option sets the maximum permissible HyperTransport link width.
+	  Use of this option will only limit the autodetected HT width; it will not (and cannot) increase the width beyond the autodetected limits.
+	  This is primarily used to work around poorly designed or laid out HT traces on certain motherboards.
+
+config LIMIT_HT_UP_WIDTH_8
+	bool "8 bits"
+config LIMIT_HT_UP_WIDTH_16
+	bool "16 bits"
+endchoice
+
+endmenu
+
 source src/northbridge/Kconfig
 comment "Southbridge"
 source src/southbridge/Kconfig
Index: src/northbridge/amd/amdht/h3finit.c
===
--- src/northbridge/amd/amdht/h3finit.c	(revision 5158)
+++ src/northbridge/amd/amdht/h3finit.c	(working copy)
@@ -1327,9 +1327,51 @@
 
 	for (i = 0; i < pDat->TotalLinks*2; i += 2)
 	{
-		cbPCBFreqLimit = 0x;
+#if CONFIG_LIMIT_HT_SPEED_200
+		cbPCBFreqLimit = 0x0001;
+#elif CONFIG_LIMIT_HT_SPEED_300
+		cbPCBFreqLimit = 0x0003;
+#elif CONFIG_LIMIT_HT_SPEED_400
+		cbPCBFreqLimit = 0x0007;
+#elif CONFIG_LIMIT_HT_SPEED_500
+		cbPCBFreqLimit = 0x000F;
+#elif CONFIG_LIMIT_HT_SPEED_600
+		cbPCBFreqLimit = 0x001F;
+#elif CONFIG_LIMIT_HT_SPEED_800
+		cbPCBFreqLimit = 0x003F;
+#elif CONFIG_LIMIT_HT_SPEED_1000
+		cbPCBFreqLimit = 0x007F;
+#elif CONFIG_LIMIT_HT_SPEED_1200
+		cbPCBFreqLimit = 0x00FF;
+#elif CONFIG_LIMIT_HT_SPEED_1400
+		cbPCBFreqLimit = 0x01FF;
+#elif CONFIG_LIMIT_HT_SPEED_1600
+		cbPCBFreqLimit = 0x03FF;
+#elif CONFIG_LIMIT_HT_SPEED_1800
+		cbPCBFreqLimit = 0x07FF;
+#elif CONFIG_LIMIT_HT_SPEED_2000
+		cbPCBFreqLimit = 0x0FFF;
+#elif CONFIG_LIMIT_HT_SPEED_2200
+		cbPCBFreqLimit = 0x1FFF;
+#elif CONFIG_LIMIT_HT_SPEED_2400
+		cbPCBFreqLimit = 0x3FFF;
+#elif CONFIG_LIMIT_HT_SPEED_2600
+		cbPCBFreqLimit = 0x7FFF;
+#else
+		cbPCBFreqLimit = 0x;		// Maximum allowed by autoconfiguration
+#endif
+
+#if CONFIG_LIMIT_HT_DOWN_WIDTH_8
+		cbPCBABDownstreamWidth = 8;
+#else
 		cbPCBABDownstreamWidth = 16;
+#endif
+
+#if CONFIG_LIMIT_HT_UP_WIDTH_8
+		cbPCBBAUpstreamWidth = 8;
+#else
 		cbPCBBAUpstreamWidth = 16;
+#endif
 
 		if ( (pDat->PortList[i].Type == PORTLIST_TYPE_CPU) && (pDat->PortList[i+1].Type == PORTLIST_TYPE_CPU))
 		{-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Executing bootstrap from MBR in coreboot

2010-02-24 Thread Myles Watson 


> -Original Message-
> From: coreboot-bounces+mylesgw=gmail@coreboot.org [mailto:coreboot-
> bounces+mylesgw=gmail@coreboot.org] On Behalf Of Piotr Piwko
> Sent: Wednesday, February 24, 2010 11:59 AM
> To: coreboot@coreboot.org
> Subject: Re: [coreboot] Executing bootstrap from MBR in coreboot
> 
> 2010/2/24 Peter Stuge :
> > Piotr Piwko wrote:
> >> I'm afraid that I will have to write my own part of code which will
> >> be responsible to execute a boostrap. At this moment I use the old
> >> version of coreboot project (practically LinuxBIOS 2.0.0), because
> >> only in this release my target board (MSM800BEV) is fully supported
> >> out of the box.
> >
> > It would really be nice if you could help make this target work with
> > the updated coreboot sources.
> 
> I would really like to do this job, but unfortunately I currently work
> on the quite urgent project and I don't enough time and energy to join
> to another project. Anyway, I am impressed with your work and I hope
> that I will be able to help in the future.

Given the boot logs it's very possible that someone on the list will fix it
for you.  In most cases it only takes a few iterations.

Thanks,
Myles


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Fam10 breakage

2010-02-24 Thread Myles Watson 
Rev 5132 works for me on SimNOW with 1 fam10 processor.

Current head gets stuck in an infinite loop setting fixed MTRRs.

Any clues while I'm bisecting?

Thanks,
Myles
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Fam10 breakage

2010-02-24 Thread Myles Watson 
On Wed, Feb 24, 2010 at 2:27 PM, Myles Watson  wrote:

> Rev 5132 works for me on SimNOW with 1 fam10 processor.
>
> Current head gets stuck in an infinite loop setting fixed MTRRs.
>
> Any clues while I'm bisecting?
>
So far the only difference before the failure is the location of the CBFS
header:
Check CBFS header at fffeffe0 (working)
Check CBFS header at ff68a (broken)

Thanks,
Myles
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] More lists

2010-02-24 Thread Myles Watson 
On Tue, Feb 23, 2010 at 12:07 PM, Ward Vandewege  wrote:

> On Tue, Feb 23, 2010 at 10:47:21AM -0700, Myles Watson wrote:
> > > Could we have some tag to svn commit like:
> >
> > > And then add:
> > >
> > > current->works
> > And also the "haha this is broken" tag and maybe the "will fry your
> > mainboard" tag. :)
> >
> > One problem is that commits that are board-specific hopefully result in a
> > working board.  The problem is that they break other boards that weren't
> > tested (or other payloads on the same board).  I don't think there's a
> way
> > around that basic problem.
>
> Boot testing would.
>

> The automatic testing framework Stepan built a few years ago - I'd love to
> get a few boards set up for that. I have some boards lying around that
> could
> be used for that. My main problem is cost: dedicating an artec dongle +
> plcc
> adapter runs about $350 per board... And then you still need a remote power
> toggle device (can be had for cheap-ish if you look around a bit) and some
> sort of serial capture device (or just another computer if it's one or a
> few
> boards).
>
Your S2881 could host a framework for qemu, AMD serengeti, and AMD
serengeti_fam10.

Having the three simulators working would be a start.  I have no idea how
hard it is to hook a simulator into the framework.

Thanks,
Myles
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Fam10 breakage

2010-02-24 Thread Myles Watson 
On Wed, Feb 24, 2010 at 2:34 PM, Myles Watson  wrote:

>
>
> On Wed, Feb 24, 2010 at 2:27 PM, Myles Watson  wrote:
>
>> Rev 5132 works for me on SimNOW with 1 fam10 processor.
>>
>> Current head gets stuck in an infinite loop setting fixed MTRRs.
>>
>> Any clues while I'm bisecting?
>>
> So far the only difference before the failure is the location of the CBFS
> header:
> Check CBFS header at fffeffe0 (working)
> Check CBFS header at ff68a (broken)
>

That's not it, because that changes later.

Rev 5135 works Rev 5139 is broken.

Rev 5136-5138 don't build.  Rev 5136 is pretty big, and I don't see anything
that's obviously related to MTRRs.

Thanks,
Myles
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Fam10 breakage

2010-02-24 Thread Myles Watson 
On Wed, Feb 24, 2010 at 3:02 PM, Myles Watson  wrote:

>
>
> On Wed, Feb 24, 2010 at 2:34 PM, Myles Watson  wrote:
>
>>
>>
>> On Wed, Feb 24, 2010 at 2:27 PM, Myles Watson  wrote:
>>
>>> Rev 5132 works for me on SimNOW with 1 fam10 processor.
>>>
>>> Current head gets stuck in an infinite loop setting fixed MTRRs.
>>>
>>> Any clues while I'm bisecting?
>>>
>> So far the only difference before the failure is the location of the CBFS
>> header:
>> Check CBFS header at fffeffe0 (working)
>> Check CBFS header at ff68a (broken)
>>
>
> That's not it, because that changes later.
>
> Rev 5135 works Rev 5139 is broken.
>
> Rev 5136-5138 don't build.  Rev 5136 is pretty big, and I don't see
> anything that's obviously related to MTRRs.
>
Interestingly enough, 5150 fixes it.  Then 5152 breaks it a different way.

Since the commit message from 5152 is:

 Remove nonsensical wrapper for function in
 PS/2 keyboard API.

I guess it's probably some kind of stack corruption.  Something makes it
very fragile.

Suggestions welcome.

Thanks,
Myles
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Relocable payloads

2010-02-24 Thread Rudolf Marek 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I have taken memtest reloc.c and glued it into libpayload. Check attached patch.
It adds -fPIC too.

Then I taken the tint payload and make it dynamic via:

../libpayload/bin/lpgcc -shared -o tint.elf tint.o engine.o io.o utils.o

I added -shared to following rule

$(TARGET).elf: $(OBJS)
$(CC) -shared -o $@ $(OBJS)

And -fPIC to CFLAGS

I used Qemu to test this. And it does start tint! Then I changed the loading
address with attached simple patch coreboot_change_base.patch and STILL does
work! I think I have more luck than I thought.

(Except the stack, I cheated and created the temp 4K stack, but I think this can
be fixed quite easily)

Questions:

1) Does it work really work? I can't believe it.

2) If yes I think we will need to ask Eric to re-license this for libpayload

3) I think we can use this to make coreboot_ram to run on ANY address :) if
someone manages to add -fPIC to our build system. When the coreboot_ram is
created one need to add -shared too.

Rudolf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkuFvm4ACgkQ3J9wPJqZRNWrFQCfddjeN0irx6eljQYIBSdYodkf
Rm0An2DlZGK7MG+6vqH+APlVKLHLAwzT
=7Nyh
-END PGP SIGNATURE-
Index: lib/libpayload.ldscript
===
--- lib/libpayload.ldscript	(revision 5158)
+++ lib/libpayload.ldscript	(working copy)
@@ -27,7 +27,7 @@
  * SUCH DAMAGE.
  */
 
-BASE_ADDRESS = 0x10;
+BASE_ADDRESS = 0x0;
 
 OUTPUT_FORMAT(elf32-i386)
 OUTPUT_ARCH(i386)
@@ -41,36 +41,50 @@
 {
 	. = BASE_ADDRESS;
 
-	. = ALIGN(16);
-	_start = .;
-
 	.text : {
-		*(.text._entry)
+		_start = .;
 		*(.text)
 		*(.text.*)
-	}
-
+		*(.plt)
+		_etext = . ;
+	} = 0x9090
 	.rodata : {
 		*(.rodata)
 		*(.rodata.*)
 	}
+	.dynsym : { *(.dynsym) }
+	.dynstr : { *(.dynstr) }
+	.hash   : { *(.hash) }
+	.gnu.hash   : { *(.gnu.hash) }
+	.dynamic: { *(.dynamic) }
 
+	.rel.text: { *(.rel.text   .rel.text.*) }
+	.rel.rodata  : { *(.rel.rodata .rel.rodata.*) }
+	.rel.data: { *(.rel.data   .rel.data.*) }
+	.rel.got : { *(.rel.got.rel.got.*) }
+	.rel.plt : { *(.rel.plt.rel.plt.*) }
+
+	. = ALIGN(4);
 	.data : {
-		*(.data)
-		*(.data.*)
+		 _data = .; 
+		*(.data) 
+		*(.data.*) 
 	}
+	.got : {
+		*(.got.plt)
+		*(.got)
+		_edata = . ;
+	}
+	. = ALIGN(4);
+	.bss : { 
+		_bss = .;
+		*(.dynbss)
+		*(.bss) 
+		*(.bss.*) 
+		*(COMMON) 
+		/* _end must be at least 256 byte aligned */
+		. = ALIGN(256); 
 
-	_edata = .;
-
-	.bss : {
-		*(.sbss)
-		*(.sbss.*)
-		*(.bss)
-		*(.bss.*)
-		*(COMMON)
-
-		/* Stack and heap */
-
 		. = ALIGN(16);
 		_heap = .;
 		. += HEAP_SIZE;
@@ -81,9 +95,9 @@
 		. += STACK_SIZE;
 		. = ALIGN(16);
 		_stack = .;
-	}
 
-	_end = .;
 
-	/DISCARD/ : { *(.comment) }
+		_end = .;
+	}
+	/DISCARD/ : { *(*) }	
 }
Index: Makefile
===
--- Makefile	(revision 5158)
+++ Makefile	(working copy)
@@ -101,7 +101,7 @@
 STACKPROTECT += $(call cc-option, -fno-stack-protector,)
 
 # TODO: Re-add -Os as soon as we find out why it caused problems.
-CFLAGS := -Wall -Werror $(STACKPROTECT) -nostdinc $(INCLUDES) -ffreestanding
+CFLAGS := -Wall -Werror $(STACKPROTECT) -nostdinc $(INCLUDES) -ffreestanding -fPIC
 
 all: lib
 
Index: arch/i386/head.S
===
--- arch/i386/head.S	(revision 5158)
+++ arch/i386/head.S	(working copy)
@@ -38,6 +38,8 @@
  * change anything.
  */
 _entry:
+	jmp 0f
+
 	call _init
 
 	/* We're back - go back to the bootloader. */
@@ -62,22 +64,42 @@
  * This function saves off the previous stack and switches us to our
  * own execution environment.
  */
+0:
 _init:
 	/* No interrupts, please. */
 	cli
 
+	/* Ensure I have a boot_stack pointer */
+	testl	%esp, %esp
+	jnz 0f
+	movl	$(0x1000 + _GLOBAL_OFFSET_TABLE_), %esp
+	leal	boot_stack_...@gotoff(%esp), %esp
+0:
+
+	/* Load the GOT pointer */
+	call	0f
+0:	popl	%ebx
+	addl	$_GLOBAL_OFFSET_TABLE_+[.-0b], %ebx
+
+	/* Pick the appropriate boot_stack address */
+	leal	boot_stack_...@gotoff(%ebx), %esp
+
 	/* Store current stack pointer. */
 	movl %esp, %esi
 
 	/* Store EAX and EBX */
 
-	movl %eax,loader_eax
-	movl %ebx,loader_ebx
+	movl %eax,loader_...@gotoff(%ebx)
+	movl %ebx,loader_...@gotoff(%ebx)
 
+	leal	_dl_st...@gotoff(%ebx), %eax
+	call	*%eax
+
 	/* Setup new stack. */
-	movl $_stack, %ebx
+/*	movl $_stack, %ebx 
 
 	movl %ebx, %esp
+*/
 
 	/* Save old stack pointer. */
 	pushl %esi
@@ -95,3 +117,11 @@
 
 	/* Return to the original context. */
 	ret
+.bss
+.balign 16
+boot_stack:
+	.globl boot_stack
+	. = . + 4096
+boot_stack_top:
+	.globl boot_stack_top
+.previous
Index: arch/i386/Makefile.inc
===
--- arch/i386/Makefile.inc	(revision 5158)
+++ arch/i386/Makefile.inc	(working copy)
@@ -29,7 +29,7 @@
 
 T

Re: [coreboot] Fam10 breakage

2010-02-24 Thread Bao, Zheng 
I am pretty sure that you meet the same the same problem.

It seems to be ridiculous. Please check the maillist about this issue.

http://www.coreboot.org/pipermail/coreboot/2010-February/055730.html

 

If everything goes as I expected, the following patch can fix your
problem

at any revision.

 

 

Zheng

 

 

Index: src/arch/i386/coreboot_ram.ld

===

--- src/arch/i386/coreboot_ram.ld   (revision 5153)

+++ src/arch/i386/coreboot_ram.ld   (working copy)

@@ -1,7 +1,7 @@

 /*

  *   Memory map:

  *

- *   CONFIG_RAMBASE  

+ *   CONFIG_RAMBASE

  * : data segment

  * : bss segment

  * : heap

@@ -19,7 +19,7 @@

  */

 /*

  *   We use ELF as output format. So that we can

- *   debug the code in some form. 

+ *   debug the code in some form.

  */

 INCLUDE ldoptions

 

@@ -62,7 +62,7 @@

 . = ALIGN(4);

 

_erodata = .;

- } 

+ }

  /*

   * After the code we place initialized data (typically initialized

   * global variables). This gets copied into ram by startup code.

@@ -101,11 +101,10 @@

  _end = .;

  . = ALIGN(CONFIG_STACK_SIZE);

  _stack = .;

- .stack . : {

-   /* Reserve a stack for each possible cpu */

-   /* the stack for ap will be put after pgtbl in 1M to
CONFIG_RAMTOP range when VGA and ROM_RUN and CONFIG_RAMTOP>1M*/

-   . = ((CONFIG_CONSOLE_VGA ||
CONFIG_PCI_ROM_RUN)&&(CONFIG_RAMBASE<0x10)&&(CONFIG_RAMTOP>0x10)
) ? CONFIG_STACK_SIZE : (CONFIG_MAX_CPUS*CONFIG_STACK_SIZE);

- }

+ /* Reserve a stack for each possible cpu */

+ /* the stack for ap will be put after pgtbl in 1M to CONFIG_RAMTOP
range when VGA and ROM_RUN and CONFIG_RAMTOP>1M*/

+ /* TODO: workaround for the bug of GNU linker. */

+ . += ((CONFIG_CONSOLE_VGA ||
CONFIG_PCI_ROM_RUN)&&(CONFIG_RAMBASE<0x10)&&(CONFIG_RAMTOP>0x10)
) ? CONFIG_STACK_SIZE : (CONFIG_MAX_CPUS*CONFIG_STACK_SIZE);

  _estack = .;

 _heap = .;

 .heap . : {

@@ -117,7 +116,7 @@

  /* The ram segment

   * This is all address of the memory resident copy of coreboot.

   */

- _ram_seg = _text; 

+ _ram_seg = _text;

  _eram_seg = _eheap;

 

  _bogus = ASSERT( ( _eram_seg < (CONFIG_RAMTOP)) , "please increase
CONFIG_RAMTOP");

 

 

 



From: coreboot-boun...@coreboot.org
[mailto:coreboot-boun...@coreboot.org] On Behalf Of Myles Watson
Sent: Thursday, February 25, 2010 6:48 AM
To: coreboot
Subject: Re: [coreboot] Fam10 breakage

 

 

On Wed, Feb 24, 2010 at 3:02 PM, Myles Watson  wrote:

 

On Wed, Feb 24, 2010 at 2:34 PM, Myles Watson  wrote:

 

On Wed, Feb 24, 2010 at 2:27 PM, Myles Watson  wrote:

Rev 5132 works for me on SimNOW with 1 fam10 processor.

Current head gets stuck in an infinite loop setting fixed MTRRs.

Any clues while I'm bisecting?

So far the only difference before the failure is the location of the
CBFS header:
Check CBFS header at fffeffe0 (working)
Check CBFS header at ff68a (broken)


That's not it, because that changes later.

Rev 5135 works Rev 5139 is broken.

Rev 5136-5138 don't build.  Rev 5136 is pretty big, and I don't see
anything that's obviously related to MTRRs.

Interestingly enough, 5150 fixes it.  Then 5152 breaks it a different
way.

Since the commit message from 5152 is:

 Remove nonsensical wrapper for function in
 PS/2 keyboard API.  


I guess it's probably some kind of stack corruption.  Something makes it
very fragile.

Suggestions welcome.

Thanks,
Myles

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Error building cache_as_ram.inc

2010-02-24 Thread Joseph Smith 

Anyone seen this error before?

/home/joe/coreboot/src/cpu/intel/model_6ex/cache_as_ram.inc: Assembler 
messages:
/home/joe/coreboot/src/cpu/intel/model_6ex/cache_as_ram.inc:43: Error: 
unbalanced parenthesis in operand 1.
/home/joe/coreboot/src/cpu/intel/model_6ex/cache_as_ram.inc:93: Error: 
unbalanced parenthesis in operand 1.
make: *** 
[/home/joe/coreboot/build/mainboard/kontron/986lcd-m/crt0.initobj.o] Error 1

[...@smitty2m coreboot]$

gcc (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)
binutils-2.19.51.0.14-37.fc12.x86_64

--
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Error building cache_as_ram.inc

2010-02-24 Thread Patrick Georgi 
Am 25.02.2010 06:14, schrieb Joseph Smith:
> Anyone seen this error before?
> 
> /home/joe/coreboot/src/cpu/intel/model_6ex/cache_as_ram.inc: Assembler
> messages:
> /home/joe/coreboot/src/cpu/intel/model_6ex/cache_as_ram.inc:43: Error:
> unbalanced parenthesis in operand 1.
> /home/joe/coreboot/src/cpu/intel/model_6ex/cache_as_ram.inc:93: Error:
> unbalanced parenthesis in operand 1.
> make: ***
> [/home/joe/coreboot/build/mainboard/kontron/986lcd-m/crt0.initobj.o]
> Error 1
> [...@smitty2m coreboot]$
> 
> gcc (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)
> binutils-2.19.51.0.14-37.fc12.x86_64
> 
That's a classic: some assembler variants consider "/" in assembler code
to be the start of a comment. Use crossgcc.


Patrick

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Fam10 breakage

2010-02-24 Thread Patrick Georgi 
Am 25.02.2010 02:46, schrieb Bao, Zheng:
> I am pretty sure that you meet the same the same problem.
> 
> It seems to be ridiculous. Please check the maillist about this issue.
> 
> http://www.coreboot.org/pipermail/coreboot/2010-February/055730.html
> 
>  
> 
> If everything goes as I expected, the following patch can fix your problem
> 
> at any revision.
Just a data point: amd/serengeti_cheetah_fam10 works for me in SimNow
without any changes. (using crossgcc as toolchain)


Patrick

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot