Re: Warnings

Hi Stefan,
First of all thanks for the great  improvements in Geode (GX2).

On 4/30/10 7:50 PM, Stefan Reinauer wrote:
> src/northbridge/amd/gx2/chipsetinit.c:271: warning: suggest
> parentheses around '-' inside '<<'
>   
This would need help from someone with a GX2 (or willing to check out
the data sheets 

I would be happy if i could be of any help with this, I have a GX2 board i can 
test on.

I saw your discussion about the warning before and it inspired me to dedicate 
my spare free time to again update my working rev5446 patches to current 
trunk.
But unfortunately i can`t get it to work anymore on rev5120 and some other 
rev`s i tried.
(Linux errors out with: "hda: lost interrupt")
I will send the details in a separate mail.

Thanks,Nils

--

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

Re: Warnings

On 04/30/2010 07:34 PM, Nils wrote:
> Hi Stefan,
> First of all thanks for the great  improvements in Geode (GX2).
>
> On 4/30/10 7:50 PM, Stefan Reinauer wrote:
>> src/northbridge/amd/gx2/chipsetinit.c:271: warning: suggest
>> parentheses around '-' inside '<<'
>>
> This would need help from someone with a GX2 (or willing to check out
> the data sheets 
>
> I would be happy if i could be of any help with this, I have a GX2 board i can
> test on.
>
> I saw your discussion about the warning before and it inspired me to dedicate
> my spare free time to again update my working rev5446 patches to current
> trunk.
> But unfortunately i can`t get it to work anymore on rev5120 and some other
> rev`s i tried.
> (Linux errors out with: "hda: lost interrupt")
> I will send the details in a separate mail.
>
> Thanks,Nils
>
I have a GX2 also (AMD PIC) that is not supported by coreboot yet, but 
could test if needed.

--

-- 
Thanks,
Joseph Smith

Re: run away pci scan

On Fri, Apr 30, 2010 at 4:21 PM, Myles Watson <mylesgw <at> gmail.com> wrote:

>> Anyone have  thoughts on what is happening here?
> Have you tried increasing the stack size?  That's been a problem in the past
> with this type of failure.

Thanks, I tried increasing the stack size from 0x8000 to 0x10000, but
that didn't seem to help.

-- 
http://se-eng.com

--

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

GX2 problems

Hi all,
Attached patches add the Wyse S50 thin client to Coreboot.
I have rev5446  and some older rev`s working here with different hacks but 
rev5484 and 5520 (and some i tested in between) are not working anymore.

Linux gives the following error: "hda: lost interrupt" .
Attached also the bootlogs from rev5446 and rev5520.

Could somebody give me a hint (or even better a patch) i can try?

Although the patches are probably not ready for inclusion:

Signed-off-by: Nils Jacobs <njacobs8 <at> hetnet.nl>

Thanks,Nils.

--

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

Re: Porting to RS780/SB700 board

On Wed, Apr 28, 2010 at 6:26 AM, Myles Watson <mylesgw <at> gmail.com> wrote:
> Have you tried changing it to pci_locate_device_on_bus()?  That will
> constrain the search to a single bus.

That doesn't help; config space accesses to the PCIe bridge devices
themselves are hanging.

I worked around the problem by replacing pci_locate_device() with
hardcoded PCI_DEV values, which should be okay for this chipset as
long as the northbridge and southbridge are always at the normal
addresses.

I managed to set up SerialICE on my board and get a few thousand lines
of tracing from the factory BIOS. I notice that it doesn't touch those
PCIe bridge devices at all early on. Is it possible that some
HyperTransport magic needs to happen to get them to behave?

> I think there must be some MTRR setup problem.  Maybe you could print out
> the MTRRs just before the slow parts?

Here's a dump of various MSRs right after the call to raminit_amdmct()
in romstage.c:

/* variable MTRRs */
msr 00000200=0000000000000000
msr 00000201=0000000000000000
msr 00000202=00000000fff00006
msr 00000203=0000fffffff80800
msr 00000204=0000000000000006
msr 00000205=0000ffff80000800

Re: r5511 broke my compile

> On 4/30/10 6:25 AM, Keith Hui wrote:
>> $  make
>>     GEN        build.h
>>     ROMCC      romstage.inc
>>     GEN        crt0.S
>>     CC         mainboard/asus/p2b-ls/crt0.s
>>     CC         mainboard/asus/p2b-ls/crt0.initobj.o
>>     LINK       coreboot
>>     OBJCOPY    coreboot.bootblock
>> make: *** No rule to make target `src/arch/i386/include/arch/asm.h',
>> needed by `build/arch/i386/lib/c_start.o'.  Stop.
>>
>>
>
> The define ASSEMBLY is now passed by the Makefile for assembler files.
>
> Hence the asm.h construct is no longer needed.
>
> Just drop asm.h includes from your code. If you use the post_code()
> macro, you can now #include <cpu/x86/post_code.h> instead.

I solved the issue by a 'make clean'. Thanks.

--

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

Re: Porting to RS780/SB700 board

> On Wed, Apr 28, 2010 at 6:26 AM, Myles Watson <mylesgw <at> gmail.com> wrote:
> > Have you tried changing it to pci_locate_device_on_bus()?  That will
> > constrain the search to a single bus.
> 
> That doesn't help; config space accesses to the PCIe bridge devices
> themselves are hanging.
> 
> I worked around the problem by replacing pci_locate_device() with
> hardcoded PCI_DEV values, which should be okay for this chipset as
> long as the northbridge and southbridge are always at the normal
> addresses.
> 
> I managed to set up SerialICE on my board and get a few thousand lines
> of tracing from the factory BIOS. I notice that it doesn't touch those
> PCIe bridge devices at all early on. Is it possible that some
> HyperTransport magic needs to happen to get them to behave?

I don't know.  It's surprising to hang.

> > I think there must be some MTRR setup problem.  Maybe you could print
> out
> > the MTRRs just before the slow parts?
> 
> Here's a dump of various MSRs right after the call to raminit_amdmct()
> in romstage.c:
> 
> /* variable MTRRs */
> msr 00000200=0000000000000000
> msr 00000201=0000000000000000

Re: computers with Coreboot BIOS

On Fri, 30 Apr 2010 04:36:36 -0700 (PDT), Peter Link <petelink1 <at> yahoo.com>
wrote:
> Recently I inquired with Inatux Computers, which sells pre-installed
> systems that include gNewSense and Trisquel, among others, about plans
for
> offering
> coreboot BIOS as an option.
> 
> After a few emails back and forth, they quickly added some information on
> their website on the following page: http://inatux.com/?gnu
> 
> (text is below)
> <<<<
> Free BIOS (Coreboot, etc.): 
> ---------------------------
> Our
> computers are not yet available with a Free BIOS, but we are very
> interested in offering that option in the future. We can build systems
> with Coreboot as the BIOS, but there will be some limitations as to
> certain video cards (ATI for 3D), processors, motherboards, memory,
> WiFi, and other areas as well. Please write us if you are interested. 

Yes that is good news Pete. 
I don't really get the part about "limitations" though, why would those
items have "limitations"?

--

-- 
Thanks,
Joseph Smith

Re: run away pci scan

Am Freitag, den 30.04.2010, 16:15 -0600 schrieb Marc Jones:
> I'm working with amd/mahogany_fam10 mainboard and having problems in
> ramstage. It is going through pci device scanning when it starts
> finding the same devices again and malloc memory until it dies. It
> also looks like it never goes down a bridge, always staying on bus0.
> The problem starts at CPU: APIC: 03, it starts scanning bus0 again.
We had that case happen when a bridge had a secondary bus ID of 0.
coreboot then enters the bridge, and starts again with the root bus.

This could also happen with other bus ids, but I guess 0 is the most
obvious contender for misbehaviour.

Patrick

--

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

Re: computers with Coreboot BIOS

Joseph Smith wrote:

>> <<<<
>> Free BIOS (Coreboot, etc.): 
>> ---------------------------
>> Our
>> computers are not yet available with a Free BIOS, but we are very
>> interested in offering that option in the future. We can build systems
>> with Coreboot as the BIOS, but there will be some limitations as to
>> certain video cards (ATI for 3D), processors, motherboards, memory,
>> WiFi, and other areas as well. Please write us if you are interested. 
> 
> Yes that is good news Pete. 
> I don't really get the part about "limitations" though, why would those
> items have "limitations"?
> 
They probably meant that since there are no modern Intel chipsets or 
CPU's currently supported by coreboot that this will be limited to AMD 
only. Plus AMD DDR3 support is only ~1 week old.

-Bari

--

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