Re: [coreboot] Some help for the lay person?

Mick Reed wrote: > Procedure 2: > check out coreboot-v2 source > cd into coreboot-v2 directory > make menuconfig > make Note that this is still in alpha stage for most if not all listed boards. > Procedure 3: > cd into targets/vendor/model > edit Config.lb cd ../.. into targets ./buildtarget ven

[coreboot] Some help for the lay person?

I'm trying to build a rom with filo for my tyan s2885. I'd like to write a generic build tutorial for the lay person, or at least for non-programmers (me). I have identified some general steps, and have some questions. Some steps: = Procedure 1: get a payload source, e.g. fil

Re: [coreboot] [PATCH] HP e-Vectra P2706T support

Carl-Daniel Hailfinger wrote: > > The code does not really support more than one CPU "type" at a time. > > CAR code for K8/Fam10 autodetects the CPU and issues the right > commands based on autodetection. That's fine, but it's not worth much without actually supporting both CPU types later on in

Re: [coreboot] [PATCH] HP e-Vectra P2706T support

On 22.10.2009 03:50, Peter Stuge wrote: > Paweł Stawicki wrote: > >> but how to turn on intel processors AND via C3 processors ? >> > > This is the first time it has been done. > > The code does not really support more than one CPU "type" at a time. > It would be nice to improve this becaus

Re: [coreboot] [PATCH] Technexion TIM-5690

On 21.10.2009 06:02, Libra Li wrote: > Hi, > > This is little modification for TIM-5690. > Thanks. > > Signed-off-by: Libra Li > Thanks for the patch. Acked-by: Carl-Daniel Hailfinger and committed in r4822. Regards, Carl-Daniel -- Developer quote of the week: "We are juggling

[coreboot] [v2] r4822 - in trunk/coreboot-v2: src/mainboard/technexion/tim5690 targets/technexion/tim5690

Author: hailfinger Date: 2009-10-22 04:54:25 +0200 (Thu, 22 Oct 2009) New Revision: 4822 Modified: trunk/coreboot-v2/src/mainboard/technexion/tim5690/mainboard.c trunk/coreboot-v2/targets/technexion/tim5690/Config.lb Log: The LAN chip-set on the Technexion TIM-5690 is enabled by hardware and

Re: [coreboot] [PATCH] HP e-Vectra P2706T support

Paweł Stawicki wrote: > I was able run my VIA c3 processor :-) Nice. > but how to turn on intel processors AND via C3 processors ? This is the first time it has been done. The code does not really support more than one CPU "type" at a time. It would be nice to improve this because the AM2 mai

Re: [coreboot] [PATCH] HP e-Vectra P2706T support

I was able run my VIA c3 processor :-) changing the line: chip cpu/intel/socket_PGA370# CPU to: chip cpu/via/model_c3 in Config.lb but how to turn on intel processors AND via C3 processors ? -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinf

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

On Wed, Oct 21, 2009 at 03:03:44PM -0600, Hugh Greenberg wrote: > Alight! It booted and loaded seabios. Attached is the entire output. > One thing though, it failed to load gpxe. The only thing related to > this that looks like an error is: > > File pci14e4,16a6.rom is of type 6300 inst

[coreboot] [blub...@vmware.com: RE: [Openipmi-developer] [Discuss] [PATCH] ipmi: use round_jiffies on timers to reduce timer overhead/wakeups]

Interesting notes from LKML and openipmi. An estimate was that kipmid hogs 10W from a 70W server. //Peter - Forwarded message from Bela Lubkin - From: Bela Lubkin To: 'Corey Minyard' , Randy Dunlap CC: "disc...@lesswatts.org" , "Kok, Auke" , Arjan van de Ven ,

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

Hugh Greenberg wrote: > File pci14e4,16a6.rom is of type 6300 instead oftype 30 > and this > PCI Expansion ROM, signature 0x, INIT size 0x, data ptr 0x > Incorrect Expansion ROM Header Signature > > I got this file from gpxe's rom O matic. I tried getting a new one > just in c

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

I'm having a hard time reproducing it now. I'll post something when/if I have the output with the debug info. -- Hugh Greenberg Myles Watson wrote: While I was just trying to get seabios to boot gpxe, coreboot hung at the same spot. It seems to happen randomly now, not every time it boots

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

> While I was just trying to get seabios to boot gpxe, coreboot hung at > the same spot. It seems to happen randomly now, not every time it boots > like before. Too bad. I guess put all the debugging back in and see if it still hangs randomly, and if it is exactly the same spot. Thanks, Myles

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

While I was just trying to get seabios to boot gpxe, coreboot hung at the same spot. It seems to happen randomly now, not every time it boots like before. -- Hugh Greenberg Myles Watson wrote: On Wed, Oct 21, 2009 at 3:03 PM, Hugh Greenberg > wrote: Alight!

[coreboot] PCI config

The attached patch fixes booting for arima/hdama. How should we really fix it? In v3 didn't we just scrap type 2 accesses all together? Thanks, Myles Index: svn/src/arch/i386/lib/pci_ops_auto.c === --- svn.orig/src/arch/i386/lib/pci

[coreboot] arima hdama and SeaBIOS + gpxe

On Wed, Oct 21, 2009 at 3:54 PM, Hugh Greenberg wrote: > Yeah, those two patches solved the problem. Thank you very much for your > help with this. No problem. > One thing though, it failed to load gpxe. > The only thing related to this that looks like an error is: > >File pci14e4,16a

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

Yeah, those two patches solved the problem. Thank you very much for your help with this. I followed those directions, but still no luck. I'll keep working at it. -- Hugh Greenberg Myles Watson wrote: On Wed, Oct 21, 2009 at 3:03 PM, Hugh Greenberg > wrote: Ali

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

On Wed, Oct 21, 2009 at 3:03 PM, Hugh Greenberg wrote: > Alight! It booted and loaded seabios. Attached is the entire output. Great. So the two problems were init_timer and pci_check_direct, right? I've attached the two patches. Signed-off-by: Myles Watson > One thing though, it failed

Re: [coreboot] [PATCH] Make various DEBUG defines user-configurable in menuconfig

On Wed, Oct 21, 2009 at 3:04 PM, Uwe Hermann wrote: > On Wed, Oct 21, 2009 at 01:23:21PM -0600, Myles Watson wrote: > > As long as all of the code that gets enabled/disabled is only print > > statements, that's probably true. I was worried that some of these > boards > > may depend on the correc

Re: [coreboot] [PATCH] Make various DEBUG defines user-configurable in menuconfig

On Wed, Oct 21, 2009 at 01:23:21PM -0600, Myles Watson wrote: > As long as all of the code that gets enabled/disabled is only print > statements, that's probably true. I was worried that some of these boards > may depend on the correct setting of those debug flags to be functional. I don't think

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

On Wed, Oct 21, 2009 at 2:21 PM, Hugh Greenberg wrote: > Here is the output: > > before scan bus of PCI: 00:18.0 > amdk8_scan_chains: PCI: 00:18.0, node 0 > amdk8_scan_chains: PCI: 00:18.0, node 0, link 0 > amdk8_scan_chain: PCI: 00:18.0, node 0, link 0 > connected > Init Complete > non coherent

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

Here is the output: before scan bus of PCI: 00:18.0 amdk8_scan_chains: PCI: 00:18.0, node 0 amdk8_scan_chains: PCI: 00:18.0, node 0, link 0 amdk8_scan_chain: PCI: 00:18.0, node 0, link 0 connected Init Complete non coherent scan chain ht_collapse_early_enumeration: PCI: 00:18.0 children PCI: 00:1

Re: [coreboot] [PATCH] Make various DEBUG defines user-configurable in menuconfig

> On Tue, Oct 20, 2009 at 11:37:02AM -0600, Myles Watson wrote: > > I like the idea of having Options that we use more available. > > > > DEBUG_SMI was the default. Now it isn't. > > DEBUG_RAM_SETUP was the default for i440bx & vx800 > > True, but that's intentional. Just like the "use lzma" or "

Re: [coreboot] [PATCH] Make various DEBUG defines user-configurable in menuconfig

On Tue, Oct 20, 2009 at 11:37:02AM -0600, Myles Watson wrote: > I like the idea of having Options that we use more available. > > DEBUG_SMI was the default. Now it isn't. > DEBUG_RAM_SETUP was the default for i440bx & vx800 True, but that's intentional. Just like the "use lzma" or "execute vga b

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

On Wed, Oct 21, 2009 at 12:23 PM, Hugh Greenberg wrote: > Here is the new output: > > before scan bus of PCI: 00:18.0 > amdk8_scan_chains: PCI: 00:18.0, node 0 > amdk8_scan_chains: PCI: 00:18.0, node 0, link 0 > amdk8_scan_chain: PCI: 00:18.0, node 0, link 0 > connected > Init Complete > non cohe

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

Here is the new output: before scan bus of PCI: 00:18.0 amdk8_scan_chains: PCI: 00:18.0, node 0 amdk8_scan_chains: PCI: 00:18.0, node 0, link 0 amdk8_scan_chain: PCI: 00:18.0, node 0, link 0 connected Init Complete non coherent scan chain ht_collapse_early_enumeration: PCI: 00:18.0 children PCI:

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

On Wed, Oct 21, 2009 at 11:37 AM, Hugh Greenberg wrote: > Below is the end of the output. I have no idea what coreboot_ram.map > should look like, so I've attached that file. Thanks. That was just in case amdk8_scan_chains wasn't being called, so we could see why. 0010131c matches the value f

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

Below is the end of the output. I have no idea what coreboot_ram.map should look like, so I've attached that file. before scan bus of PCI: 00:18.0 In scan bus of PCI: 00:18.0 scan_bus() = 0010131c amdk8_scan_chains: PCI: 00:18.0, node 0 amdk8_scan_chains: PCI: 00:18.0, node 0, link 0 amdk8_scan

[coreboot] Help getting a P2B board running with coreboot

Hi. I've been lurking here for some time, and am slowly trying to get a ASUS P2B board to run with coreboot. This is mainly so that I can get to grips with how coreboot works - the P2B seemed to be an easy starting point (well documented and cheap, they're on e-bay for < £10). I've built a

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

On Wed, Oct 21, 2009 at 10:32 AM, Hugh Greenberg wrote: > Attached is a patch that contains the extra debug statements I added. > Below is the new output: > > before scan bus of PCI: 00:18.0 > In scan bus of PCI: 00:18.0 OK. This next patch prints the location of scan_bus and puts some prints

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

Attached is a patch that contains the extra debug statements I added. Below is the new output: before scan bus of PCI: 00:18.0 In scan bus of PCI: 00:18.0 -- Hugh Greenberg Myles Watson wrote: On Wed, Oct 21, 2009 at 9:31 AM, Hugh Greenberg > wrote: PCI: 00:1f.

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

On Wed, Oct 21, 2009 at 9:31 AM, Hugh Greenberg wrote: > > PCI: 00:1f.0, bad id 0x > POST: 0x25 > scan bus of PCI: 00:18.0 > While we're doing this part only the last few lines (or the new lines since the last time) really matter. It looks like it gets stuck in scan_bus. Try adding prin

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

Here is the output after adding the print statement: coreboot-2.3 Wed Oct 21 09:25:50 MDT 2009 starting... Enabling routing table for node 00 done. Enabling SMP settings (0,1) link=01 (1,0) link=01 setup_remote_node: done Renaming current temporary node to 01 done. Enabling routing table for node

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

> -Original Message- > From: Hugh Greenberg [mailto:h...@lanl.gov] > Sent: Wednesday, October 21, 2009 8:58 AM > To: Myles Watson; coreboot@coreboot.org > Subject: Re: [Fwd: Re: [Fwd: Re: [coreboot] [Fwd: Re: arima hdama > problem]]] > > It seems like the changes to apic_timer.c were not

Re: [coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

It seems like the changes to apic_timer.c were not needed as it is still getting to the same spot without them: coreboot-2.3 Wed Oct 21 08:50:27 MDT 2009 starting... Enabling routing table for node 00 done. Enabling SMP settings (0,1) link=01 (1,0) link=01 setup_remote_node: done Renaming curren

[coreboot] [Fwd: Re: [Fwd: Re: [Fwd: Re: arima hdama problem]]]

Please disregard my last message. I mean do you want me to apply the patch without any of the changes to apic_timer.c ? Myles Watson wrote: Below is the output with the no_smp patch and the previous patch. Is there another problem since the payload is not being loaded? There's definitel

Re: [coreboot] [Fwd: Re: [Fwd: Re: arima hdama problem]]

Do you to mean apply your last patch without the do { ... timeout++;} while(((start - value) < ticks) && (timeout < 100)); in apic_timer.c ? -- Hugh Greenberg Myles Watson wrote: Below is the output with the no_smp patch and the previous patch. Is there another problem since the pay