More v3 questions/issues

[Corey Osgood]

Alright, the good is that memtest boots now. The bad:

-Memtest thinks there's no memory, because...
-None of the cn700 stage2 drivers are running
-And any pci read/write operation in phase6 seems to lock up coreboot, maybe
because of a lack of memory?

I'm thinking the cn700 drivers are probably not running due to them not
having their own dts files or entries in the mainboard dts. If that's the
case, how do I represent d0f0, which acts as a PCI device, PCI domain, and
CPU bus controller, and needs drivers for all 3?

Thanks,
Corey

[Corey Osgood]

On Sun, Dec 14, 2008 at 2:23 AM, Corey Osgood wrote:
> Alright, the good is that memtest boots now. The bad:
>
> -Memtest thinks there's no memory, because...
> -None of the cn700 stage2 drivers are running
> -And any pci read/write operation in phase6 seems to lock up coreboot,
> maybe because of a lack of memory?
>
> I'm thinking the cn700 drivers are probably not running due to them not
> having their own dts files or entries in the mainboard dts. If that's the
> case, how do I represent d0f0, which acts as a PCI device, PCI domain, and
> CPU bus controller, and needs drivers for all 3?

I think I've figured it out, but it hangs during booting, boot log and patch
attached. Also, I'm trying to add a driver for the c7 cpu, but I can't find
the k8/geodelx stage2 make rules. And is the dts entry necessary?

Thanks,
Corey

[Myles Watson]

On Sun, Dec 14, 2008 at 1:30 PM, Corey Osgood wrote:
> On Sun, Dec 14, 2008 at 2:23 AM, Corey Osgood wrote:
> > Alright, the good is that memtest boots now. The bad:
> >
> > -Memtest thinks there's no memory, because...
> > -None of the cn700 stage2 drivers are running
> > -And any pci read/write operation in phase6 seems to lock up coreboot,
> > maybe because of a lack of memory?
> >
> > I'm thinking the cn700 drivers are probably not running due to them not
> > having their own dts files or entries in the mainboard dts. If that's the
> > case, how do I represent d0f0, which acts as a PCI device, PCI domain, and
> > CPU bus controller, and needs drivers for all 3?
>
> I think I've figured it out, but it hangs during booting, boot log and
> patch attached. Also, I'm trying to add a driver for the c7 cpu, but I can't
> find the k8/geodelx stage2 make rules. And is the dts entry necessary?

Corey,

Sorry I don't know that much about the cn700...

I'm looking through your log and diff, and it looks like the phase3_scan is
hanging when it finds the first device.  Is there something that needs to be
enabled in the CPU before you can do a PCI config read?  If so that needs to
get called first.

I saw that you moved something from phase6_init to phase2.  I don't think
that's necessary.  My understanding is that only things that are necessary
to enable basic things like bus reading and writing should go there.

Thanks,
Myles

[ron minnich]

On Mon, Dec 15, 2008 at 9:24 AM, Myles Watson  wrote:
> I saw that you moved something from phase6_init to phase2.  I don't think
> that's necessary.  My understanding is that only things that are necessary
> to enable basic things like bus reading and writing should go there.

Yes, Myles is right: in general phase 2 is not needed, it is really
there for pathological hardware ...

ron

[Corey Osgood]

On Mon, Dec 15, 2008 at 5:25 PM, ron minnich  wrote:
> On Mon, Dec 15, 2008 at 9:24 AM, Myles Watson  wrote:
> > I saw that you moved something from phase6_init to phase2.  I don't think
> > that's necessary.  My understanding is that only things that are
>
> necessary
> > to enable basic things like bus reading and writing should go there.
>
> Yes, Myles is right: in general phase 2 is not needed, it is really
> there for pathological hardware ...

Ignore that part of the patch, I'm plugging at a couple other things at the
moment. I think you're reading the patch wrong, nothing should be moved to
phase2, some things are moved from phase2 to phase3_chip_setup (which is not
called atm), others might be moved to phase6_init. My problem at the moment
is the hang after pci_scan_bus with the error about being called for a PCI
domain, which is the same way it's called in qemu. I need to look at a qemu
boot log to see where the next step should be, does anyone have one handy? I
don't currently have QEMU set up.

Thanks,
Corey

[Corey Osgood]

On Mon, Dec 15, 2008 at 6:12 PM, Corey Osgood wrote:
> On Mon, Dec 15, 2008 at 5:25 PM, ron minnich  wrote:
> > On Mon, Dec 15, 2008 at 9:24 AM, Myles Watson  wrote:
> > > I saw that you moved something from phase6_init to phase2.  I don't
> >
> > think
> > > that's necessary.  My understanding is that only things that are
> >
> > necessary
> > > to enable basic things like bus reading and writing should go there.
> >
> > Yes, Myles is right: in general phase 2 is not needed, it is really
> > there for pathological hardware ...
>
> Ignore that part of the patch, I'm plugging at a couple other things at the
> moment. I think you're reading the patch wrong, nothing should be moved to
> phase2, some things are moved from phase2 to phase3_chip_setup (which is not
> called atm), others might be moved to phase6_init. My problem at the moment
> is the hang after pci_scan_bus with the error about being called for a PCI
> domain, which is the same way it's called in qemu.

I thought pci_scan_bus() was causing the hang, but the PCI domain error
doesn't actually do anything, pci_scan_bus just continues along happily.
> I need to look at a qemu boot log to see where the next step should be,
> does anyone have one handy? I don't currently have QEMU set up.
>
> Thanks,
> Corey

-Corey

[Myles Watson]

On Mon, Dec 15, 2008 at 4:15 PM, Corey Osgood wrote:
> On Mon, Dec 15, 2008 at 6:12 PM, Corey Osgood wrote:
> > On Mon, Dec 15, 2008 at 5:25 PM, ron minnich  wrote:
> > > On Mon, Dec 15, 2008 at 9:24 AM, Myles Watson  wrote:
> > > > I saw that you moved something from phase6_init to phase2.  I don't
> > >
> > > think
> > > > that's necessary.  My understanding is that only things that are
> > >
> > > necessary
> > > > to enable basic things like bus reading and writing should go there.
> > >
> > > Yes, Myles is right: in general phase 2 is not needed, it is really
> > > there for pathological hardware ...

Sorry.  I did misread it.

Ignore that part of the patch, I'm plugging at a couple other things at the
> > moment. I think you're reading the patch wrong, nothing should be moved to
> > phase2, some things are moved from phase2 to phase3_chip_setup (which is not
> > called atm), others might be moved to phase6_init. My problem at the moment
> > is the hang after pci_scan_bus with the error about being called for a PCI
> > domain, which is the same way it's called in qemu.
>
> I thought pci_scan_bus() was causing the hang, but the PCI domain error
> doesn't actually do anything, pci_scan_bus just continues along happily.

That's right.  It's not really an error.  It's a leftover from v2, when
there was a bus device for every bus.  It's correct to call pci_scan_bus
from a domain.
> I need to look at a qemu boot log to see where the next step should be,
> > does anyone have one handy? I don't currently have QEMU set up.

Here's a snippet from the log.  I think you're probably hanging in
pci_probe_dev.  That's why I asked if anything needed to be set up before a
PCI config read.

pci_get_dev gets the device structure from the tree
pci_probe_dev actually talks to it on the bus.

Thanks,
Myles

Phase 3: Enumerating buses...
dev_phase3_scan: scanning root(Root Device)
scan_static_bus for root (Root Device)
cpus(CPU: 00) enabled
domain_0(PCI_DOMAIN: 0000) enabled
domain_0(PCI_DOMAIN: 0000) scanning...
dev_phase3_scan: scanning domain_0(PCI_DOMAIN: 0000)
pci_domain_scan_bus: calling pci_scan_bus
pci_scan_bus start bus->dev domain_0 bus 0
ERROR: pci_scan_bus called with incorrect bus->dev->path.type, path is
PCI_DOMAIN: 0000
PCI: pci_scan_bus for bus 00
pci_scan_bus: old_devices domain_0_pci_0_0, dev for this bus domain_0
PCI: scan devfn 0x0 to 0xff
PCI: devfn 0x0
pci_get_dev: list is NOT NULL, *list is NOT NULL
pci_get_dev: check dev domain_0_pci_0_0
pci_get_dev: check dev domain_0_pci_0_0 it has devfn 0x00
PCI: pci_scan_bus pci_get_dev returns dev domain_0_pci_0_0
set_pci_ops: dev domain_0_pci_0_0 already has ops of type 20504349
PCI: 00:00.0 [PCI: 8086:1237] enabled
PCI: pci_scan_bus pci_probe_dev returns dev domain_0_pci_0_0
Not a multi function device, or the device is not present. Skip to next
device.
PCI: devfn 0x8
pci_get_dev: list is NOT NULL, *list is NOT NULL
pci_get_dev: check dev domain_0_pci_1_0
pci_get_dev: check dev domain_0_pci_1_0 it has devfn 0x08
PCI: pci_scan_bus pci_get_dev returns dev domain_0_pci_1_0
set_pci_ops: dev domain_0_pci_1_0 already has ops of type 20504349
PCI: 00:01.0 [PCI: 8086:7000] enabled
PCI: pci_scan_bus pci_probe_dev returns dev domain_0_pci_1_0

[Myles Watson]

Corey,

I've been looking through the v2 code, but I don't see anywhere that pci
config reads/writes are enabled before scanning.  If you're interested, you
could send me a v2 boot log and I'll try to help more. You could also try
doing a direct pci config read to the device to see if it works before the
hang.

Thanks,
Myles

[Corey Osgood]

On Tue, Dec 16, 2008 at 12:35 PM, Myles Watson  wrote:
> Corey,
>
> I've been looking through the v2 code, but I don't see anywhere that pci
> config reads/writes are enabled before scanning.  If you're interested, you
> could send me a v2 boot log and I'll try to help more. You could also try
> doing a direct pci config read to the device to see if it works before the
> hang.

I got looking at some other drivers and reading some other mails on the
list, and changing pci_ops to use cf0/cf8 fixed it, and also fixed my
problems with the ide and sata drivers hanging (so all those phase3
functions are back in phase6 where they belong). The system now boots to
memtest and actually sees the memory to test now, but I'm still having a
problem building the cpu driver, which means booting is EXTREMEMLY slow. The
stage2 driver is in via/c7.c, but no matter where I try to include it in the
make files, arch/x86/Makefile or mainboard/jetway/j7f2/Makefile, I get this
error:

make: *** No rule to make target
`/home/corey/coreboot/coreboot-v3/build/mainboard/jetway/j7f2//home/corey/coreboot/coreboot-v3/arch/x86/via/c7.o',
needed by `/home/corey/coreboot/coreboot-v3/build/coreboot.stage2'.  Stop.

I'm no expert on makefiles, so I could use a hand. I've tried to locate
where/how geodelx/cpu.c is built, but it doesn't seem that it ever is,
adding a #error to the file still lets alix1c and other geodelx boards build
without error.

Other then that, things are looking VERY promising, I'm finishing up a few
things I put off before, and once the CPU driver is running I'd like to try
booting a kernel :)

Thanks,
Corey

[ron minnich]

why don't we commit your tree in its current state so we can get a
look and see what's going on.

ron

[Myles Watson]

On Wed, Dec 17, 2008 at 11:43 AM, Corey Osgood wrote:
> On Tue, Dec 16, 2008 at 12:35 PM, Myles Watson  wrote:
> > Corey,
> >
> > I've been looking through the v2 code, but I don't see anywhere that pci
> > config reads/writes are enabled before scanning.  If you're interested, you
> > could send me a v2 boot log and I'll try to help more. You could also try
> > doing a direct pci config read to the device to see if it works before the
> > hang.
>
> I got looking at some other drivers and reading some other mails on the
> list, and changing pci_ops to use cf0/cf8 fixed it, and also fixed my
> problems with the ide and sata drivers hanging (so all those phase3
> functions are back in phase6 where they belong). The system now boots to
> memtest and actually sees the memory to test now, but I'm still having a
> problem building the cpu driver, which means booting is EXTREMEMLY slow. The
> stage2 driver is in via/c7.c, but no matter where I try to include it in the
> make files, arch/x86/Makefile or mainboard/jetway/j7f2/Makefile, I get this
> error:
>
> make: *** No rule to make target
> `/home/corey/coreboot/coreboot-v3/build/mainboard/jetway/j7f2//home/corey/coreboot/coreboot-v3/arch/x86/via/c7.o',
> needed by `/home/corey/coreboot/coreboot-v3/build/coreboot.stage2'.  Stop.
>
> I'm no expert on makefiles, so I could use a hand. I've tried to locate
> where/how geodelx/cpu.c is built, but it doesn't seem that it ever is,
> adding a #error to the file still lets alix1c and other geodelx boards build
> without error.
>
> Other then that, things are looking VERY promising, I'm finishing up a few
> things I put off before, and once the CPU driver is running I'd like to try
> booting a kernel :)
>
> Thanks,
> Corey

I agree with Ron.  You're doing good work and we could help you easier if we
commit it.  I added one more line to your Makefile and it tries to build the
file.

I think the c7.c file should move, but for now it helps.

Thanks,
Myles

Index: coreboot-v3/northbridge/via/cn700/Makefile
===================================================================
--- coreboot-v3.orig/northbridge/via/cn700/Makefile
+++ coreboot-v3/northbridge/via/cn700/Makefile
@@ -20,9 +20,12 @@

ifeq ($(CONFIG_NORTHBRIDGE_VIA_CN700),y)

-STAGE2_CHIPSET_SRC +=     $(src)/northbridge/via/cn700/stage2.c \
+STAGE2_CHIPSET_SRC +=     $(src)/northbridge/via/cn700/apic.c \
             $(src)/northbridge/via/cn700/agp.c \
+            $(src)/northbridge/via/cn700/memctrl.c \
+            $(src)/arch/x86/via/c7.c \
             $(src)/northbridge/via/cn700/pci.c \
+            $(src)/northbridge/via/cn700/pci_domain.c \
             $(src)/northbridge/via/cn700/vga.c

endif

[Corey Osgood]

On Wed, Dec 17, 2008 at 2:03 PM, Myles Watson  wrote:
> On Wed, Dec 17, 2008 at 11:43 AM, Corey Osgood wrote:
> > On Tue, Dec 16, 2008 at 12:35 PM, Myles Watson  wrote:
> > > Corey,
> > >
> > > I've been looking through the v2 code, but I don't see anywhere that pci
> > > config reads/writes are enabled before scanning.  If you're interested, you
> > > could send me a v2 boot log and I'll try to help more. You could also try
> > > doing a direct pci config read to the device to see if it works before the
> > > hang.
> >
> > I got looking at some other drivers and reading some other mails on the
> > list, and changing pci_ops to use cf0/cf8 fixed it, and also fixed my
> > problems with the ide and sata drivers hanging (so all those phase3
> > functions are back in phase6 where they belong). The system now boots to
> > memtest and actually sees the memory to test now, but I'm still having a
> > problem building the cpu driver, which means booting is EXTREMEMLY slow. The
> > stage2 driver is in via/c7.c, but no matter where I try to include it in the
> > make files, arch/x86/Makefile or mainboard/jetway/j7f2/Makefile, I get this
> > error:
> >
> > make: *** No rule to make target
> > `/home/corey/coreboot/coreboot-v3/build/mainboard/jetway/j7f2//home/corey/coreboot/coreboot-v3/arch/x86/via/c7.o',
> > needed by `/home/corey/coreboot/coreboot-v3/build/coreboot.stage2'.  Stop.
> >
> > I'm no expert on makefiles, so I could use a hand. I've tried to locate
> > where/how geodelx/cpu.c is built, but it doesn't seem that it ever is,
> > adding a #error to the file still lets alix1c and other geodelx boards build
> > without error.
> >
> > Other then that, things are looking VERY promising, I'm finishing up a few
> > things I put off before, and once the CPU driver is running I'd like to try
> > booting a kernel :)
> >
> > Thanks,
> > Corey
>
> I agree with Ron.  You're doing good work and we could help you easier if
> we commit it.  I added one more line to your Makefile and it tries to build
> the file.
>
> I think the c7.c file should move, but for now it helps.
>
> Thanks,
> Myles

Ok, adding it there work. But why does it work there but nowhere else? I'll
try to make a commit within the hour, I've just got to split the c7/cn700
stuff off from the other hacking I've been doing.

Thanks,
Corey
> Index: coreboot-v3/northbridge/via/cn700/Makefile
>
> --- coreboot-v3.orig/northbridge/via/cn700/Makefile
> +++ coreboot-v3/northbridge/via/cn700/Makefile
> @@ -20,9 +20,12 @@
>
> ifeq ($(CONFIG_NORTHBRIDGE_VIA_CN700),y)
>
> -STAGE2_CHIPSET_SRC +=     $(src)/northbridge/via/cn700/stage2.c \
> +STAGE2_CHIPSET_SRC +=     $(src)/northbridge/via/cn700/apic.c \
>              $(src)/northbridge/via/cn700/agp.c \
>        $(src)/northbridge/via/cn700/memctrl.c \
>        $(src)/arch/x86/via/c7.c \
>        $(src)/northbridge/via/cn700/pci.c \
>        $(src)/northbridge/via/cn700/pci_domain.c \
>        $(src)/northbridge/via/cn700/vga.c
>
> endif

[Corey Osgood]

On Wed, Dec 17, 2008 at 3:24 PM, Corey Osgood wrote:
> On Wed, Dec 17, 2008 at 2:03 PM, Myles Watson  wrote:
> > On Wed, Dec 17, 2008 at 11:43 AM, Corey Osgood wrote:
> > > On Tue, Dec 16, 2008 at 12:35 PM, Myles Watson wrote:
> > > > Corey,
> > > >
> > > > I've been looking through the v2 code, but I don't see anywhere that pci
> > > > config reads/writes are enabled before scanning.  If you're interested, you
> > > > could send me a v2 boot log and I'll try to help more. You could also try
> > > > doing a direct pci config read to the device to see if it works before the
> > > > hang.
> > >
> > > I got looking at some other drivers and reading some other mails on the
> > > list, and changing pci_ops to use cf0/cf8 fixed it, and also fixed my
> > > problems with the ide and sata drivers hanging (so all those phase3
> > > functions are back in phase6 where they belong). The system now boots to
> > > memtest and actually sees the memory to test now, but I'm still having a
> > > problem building the cpu driver, which means booting is EXTREMEMLY slow. The
> > > stage2 driver is in via/c7.c, but no matter where I try to include it in the
> > > make files, arch/x86/Makefile or mainboard/jetway/j7f2/Makefile, I get this
> > > error:
> > >
> > > make: *** No rule to make target
> > > `/home/corey/coreboot/coreboot-v3/build/mainboard/jetway/j7f2//home/corey/coreboot/coreboot-v3/arch/x86/via/c7.o',
> > > needed by `/home/corey/coreboot/coreboot-v3/build/coreboot.stage2'.  Stop.
> > >
> > > I'm no expert on makefiles, so I could use a hand. I've tried to locate
> > > where/how geodelx/cpu.c is built, but it doesn't seem that it ever is,
> > > adding a #error to the file still lets alix1c and other geodelx boards build
> > > without error.
> > >
> > > Other then that, things are looking VERY promising, I'm finishing up a
> > > few things I put off before, and once the CPU driver is running I'd like to
> > > try booting a kernel :)
> > >
> > > Thanks,
> > > Corey
> >
> > I agree with Ron.  You're doing good work and we could help you easier if
> > we commit it.  I added one more line to your Makefile and it tries to build
> > the file.
> >
> > I think the c7.c file should move, but for now it helps.
> >
> > Thanks,
> > Myles
>
> Ok, adding it there work. But why does it work there but nowhere else? I'll
> try to make a commit within the hour, I've just got to split the c7/cn700
> stuff off from the other hacking I've been doing.

self-acked and committed, feel free to move c7.c anywhere you think it
belongs ;) I've self-acked for expediency, I'm about to brave a snowstorm to
get to school for a final, and won't be back for probably 4 hours or so. I
also updated the epia-cn dts, so it should be in the same state as the j7f2
if you fix the superio stuff.

-Corey

[Myles Watson]

On Wed, Dec 17, 2008 at 2:19 PM, Corey Osgood wrote:
> On Wed, Dec 17, 2008 at 3:24 PM, Corey Osgood wrote:
> > On Wed, Dec 17, 2008 at 2:03 PM, Myles Watson  wrote:
> >
> > Ok, adding it there work. But why does it work there but nowhere else?
>
> I think it has to do with build order and stage0 vs. stage 2.

self-acked and committed, feel free to move c7.c anywhere you think it
> belongs ;) I've self-acked for expediency, I'm about to brave a snowstorm to
> get to school for a final, and won't be back for probably 4 hours or so. I
> also updated the epia-cn dts, so it should be in the same state as the j7f2
> if you fix the superio stuff.

Here's a patch for the dts.  (Corey - sorry I forgot to send it to the
list.)

It needs the dtc-links.diff patch from this mail.  Or you can just leave the
SuperIO as a child of the domain.

http://www.coreboot.org/pipermail/coreboot/2008-December/043327.html

Thanks,
Myles

[Corey Osgood]

On Wed, Dec 17, 2008 at 5:29 PM, Myles Watson  wrote:
> On Wed, Dec 17, 2008 at 2:19 PM, Corey Osgood wrote:
> > On Wed, Dec 17, 2008 at 3:24 PM, Corey Osgood wrote:
> > > On Wed, Dec 17, 2008 at 2:03 PM, Myles Watson  wrote:
> > >
> > > Ok, adding it there work. But why does it work there but nowhere else?
> >
> > I think it has to do with build order and stage0 vs. stage 2.
>
> self-acked and committed, feel free to move c7.c anywhere you think it
> > belongs ;) I've self-acked for expediency, I'm about to brave a snowstorm to
> > get to school for a final, and won't be back for probably 4 hours or so. I
> > also updated the epia-cn dts, so it should be in the same state as the j7f2
> > if you fix the superio stuff.
>
> Here's a patch for the dts.  (Corey - sorry I forgot to send it to the
> list.)
>
> It needs the dtc-links.diff patch from this mail.  Or you can just leave
> the SuperIO as a child of the domain.
>
> http://www.coreboot.org/pipermail/coreboot/2008-December/043327.html

One comment:

Index: coreboot-v3/mainboard/jetway/j7f2/dts
===================================================================
--- coreboot-v3.orig/mainboard/jetway/j7f2/dts
+++ coreboot-v3/mainboard/jetway/j7f2/dts
@@ -66,23 +66,46 @@
         /* How do I represent the bus and pci devices hanging here? */
         pci@1,0 {
             /config/("northbridge/via/cn700/pci.dts");
-            pci@0,1 {
+            pci@0,0 {
                 /config/("northbridge/via/cn700/vga.dts");
             };
         };
-        pci@f,0 {};
-        pci@10,0 {
+        pci@8,0 { /* RaLink RT2561/RT61 802.11g PCI */
+        };
+        pci@a,0 { /* IEEE 1394 Host Controller */
+        };

These two devices shouldn't be in the dts. The RaLink card is a PCI card I
neglected to remove before sending that lspci, and the firewire controller
is only on some j7f2-series boards

Other then that, I'll try out the rest of the changes tonight.

Thanks,
Corey

[Myles Watson]

On Wed, Dec 17, 2008 at 6:33 PM, Corey Osgood wrote:
> On Wed, Dec 17, 2008 at 5:29 PM, Myles Watson  wrote:
> > On Wed, Dec 17, 2008 at 2:19 PM, Corey Osgood wrote:
> > > On Wed, Dec 17, 2008 at 3:24 PM, Corey Osgood wrote:
> > > > On Wed, Dec 17, 2008 at 2:03 PM, Myles Watson wrote:
> > > >
> > > > Ok, adding it there work. But why does it work there but nowhere else?
> > >
> > > I think it has to do with build order and stage0 vs. stage 2.
> >
> > self-acked and committed, feel free to move c7.c anywhere you think it
> > > belongs ;) I've self-acked for expediency, I'm about to brave a snowstorm to
> > > get to school for a final, and won't be back for probably 4 hours or so. I
> > > also updated the epia-cn dts, so it should be in the same state as the j7f2
> > > if you fix the superio stuff.
> >
> > Here's a patch for the dts.  (Corey - sorry I forgot to send it to the
> > list.)
> >
> > It needs the dtc-links.diff patch from this mail.  Or you can just leave
> > the SuperIO as a child of the domain.
> >
> > http://www.coreboot.org/pipermail/coreboot/2008-December/043327.html
>
> One comment:
> Index: coreboot-v3/mainboard/jetway/j7f2/dts
>
> --- coreboot-v3.orig/mainboard/jetway/j7f2/dts
> +++ coreboot-v3/mainboard/jetway/j7f2/dts
> @@ -66,23 +66,46 @@
>          /* How do I represent the bus and pci devices hanging here? */
>          pci@1,0 {
>              /config/("northbridge/via/cn700/pci.dts");
>        pci@0,1 {
>        pci@0,0 {
>            /config/("northbridge/via/cn700/vga.dts");
>        };
>    };
>    pci@f,0 {};
>    pci@10,0 {
>    pci@8,0 { /* RaLink RT2561/RT61 802.11g PCI */
>    };
>    pci@a,0 { /* IEEE 1394 Host Controller */
>    };
>
> These two devices shouldn't be in the dts. The RaLink card is a PCI card I
> neglected to remove before sending that lspci, and the firewire controller
> is only on some j7f2-series boards

No problem.  I was just going from the lspci in the file.
> Other then that, I'll try out the rest of the changes tonight.

Great.  Good luck.

Myles

[Carl-Daniel Hailfinger]

On 17.12.2008 22:19, Corey Osgood wrote:
> On Wed, Dec 17, 2008 at 3:24 PM, Corey Osgood wrote:
> > On Wed, Dec 17, 2008 at 2:03 PM, Myles Watson  wrote:
> > > On Wed, Dec 17, 2008 at 11:43 AM, Corey Osgood wrote:
> > > > On Tue, Dec 16, 2008 at 12:35 PM, Myles Watson wrote:
> > > > > Corey,
> > > > >
> > > > > I've been looking through the v2 code, but I don't see anywhere that pci
> > > > > config reads/writes are enabled before scanning.  If you're interested, you
> > > > > could send me a v2 boot log and I'll try to help more. You could also try
> > > > > doing a direct pci config read to the device to see if it works before the
> > > > > hang.
> > > >
> > > > I got looking at some other drivers and reading some other mails on the
> > > > list, and changing pci_ops to use cf0/cf8 fixed it, and also fixed my
> > > > problems with the ide and sata drivers hanging (so all those phase3
> > > > functions are back in phase6 where they belong). The system now boots to
> > > > memtest and actually sees the memory to test now, but I'm still having a
> > > > problem building the cpu driver, which means booting is EXTREMEMLY slow. The
> > > > stage2 driver is in via/c7.c, but no matter where I try to include it in the
> > > > make files, arch/x86/Makefile or mainboard/jetway/j7f2/Makefile, I get this
> > > > error:
> > > >
> > > > make: *** No rule to make target
> > > > `/home/corey/coreboot/coreboot-v3/build/mainboard/jetway/j7f2//home/corey/coreboot/coreboot-v3/arch/x86/via/c7.o',
> > > > needed by `/home/corey/coreboot/coreboot-v3/build/coreboot.stage2'.  Stop.
> > > >
> > > > I'm no expert on makefiles, so I could use a hand. I've tried to locate
> > > > where/how geodelx/cpu.c is built, but it doesn't seem that it ever is,
> > > > adding a #error to the file still lets alix1c and other geodelx boards build
> > > > without error.
> > > >
> > > > Other then that, things are looking VERY promising, I'm finishing up a
> > > > few things I put off before, and once the CPU driver is running I'd like to
> > > > try booting a kernel :)
> > > >
> > > > Thanks,
> > > > Corey
> > >
> > > I agree with Ron.  You're doing good work and we could help you easier if
> > > we commit it.  I added one more line to your Makefile and it tries to build
> > > the file.
> > >
> > > I think the c7.c file should move, but for now it helps.
> > >
> > > Thanks,
> > > Myles
> >
> > Ok, adding it there work. But why does it work there but nowhere else? I'll
> > try to make a commit within the hour, I've just got to split the c7/cn700
> > stuff off from the other hacking I've been doing.
>
> self-acked and committed, feel free to move c7.c anywhere you think it
> belongs ;) I've self-acked for expediency, I'm about to brave a snowstorm to
> get to school for a final, and won't be back for probably 4 hours or so. I
> also updated the epia-cn dts, so it should be in the same state as the j7f2
> if you fix the superio stuff.

Sorry I didn't find time to review this sooner. Is it intentional that
one of the files written by you had a (C) coresystems?

Regards,
Carl-Daniel

[ron minnich]

just FYI, I am going on vacation for 3 weeks, so be good while I'm gone :-)

have a nice new year's everyone

ron

[Carl-Daniel Hailfinger]

On 18.12.2008 00:56, ron minnich wrote:
> just FYI, I am going on vacation for 3 weeks, so be good while I'm gone :-)
>
> have a nice new year's everyone

Thanks!

Merry Christmas and a Happy New Year to you!

Regards,
Carl-Daniel

[ron minnich]

one more note.

It's looking, increasingly, like future CPUs will require
initlalization very early in startup. Some will require it right after
initram; some during initram; and some BEFORE initram.

But they will all require it in what we call stage 1 -- before the
device tree exists.

The implication is that the device tree may not be that useful in
future for "CPUs as devices". I think we should plan around this. CPUs
were always kind of a stretch to make a device anyway. Just FYI.

ron

[Corey Osgood]

On Wed, Dec 17, 2008 at 7:05 PM, ron minnich  wrote:
> one more note.
>
> It's looking, increasingly, like future CPUs will require
> initlalization very early in startup. Some will require it right after
> initram; some during initram; and some BEFORE initram.
>
> But they will all require it in what we call stage 1 -- before the
> device tree exists.
>
> The implication is that the device tree may not be that useful in
> future for "CPUs as devices". I think we should plan around this. CPUs
> were always kind of a stretch to make a device anyway. Just FYI.

I'm agreeing with this. I think proper init for the cpu right after
disable_car() would greatly speed up the boot process. Carl-Daniel, would
there be any problem with calling functions to enable mtrrs and the cache
(if it's not already) from the end of disable_car()? If not permanently, at
least for the time being, to find out if it would help and to reduce the
current 20 minute test cycle?

Thanks,
Corey

[Peter Stuge]

Corey Osgood wrote:
> would there be any problem with calling functions to enable mtrrs
> and the cache (if it's not already) from the end of disable_car()?

None whatsoever. Commit at will.

//Peter

[Corey Osgood]

On Wed, Dec 17, 2008 at 8:55 PM, Peter Stuge  wrote:
> Corey Osgood wrote:
> > would there be any problem with calling functions to enable mtrrs
> > and the cache (if it's not already) from the end of disable_car()?
>
> None whatsoever. Commit at will.

It didn't help, disable_car() already does essentially the same thing;
disable cache, enable mtrrs, re-enable cache. I'm comparing memtest between
the stock bios and coreboot right now, the throughput for the stock bios is
6122MB/s for L1 cache and 574MB/s for memory. With v2, it's 3265 and 191,
respectively (using ROMCC), with v3 it's 15 and 18. So something's not right
somewhere. The other thing is that in v2 and v3, the CPU is only running at
800MHz in memtest, but with the stock BIOS it runs at 1.5GHz, that's
probably the reason for the differing cache throughputs. Anyways, I'm diving
into both v2 and v3 and trying to track down why this is running so slowly.

Corey

[Corey Osgood]

On Wed, Dec 17, 2008 at 11:04 PM, Corey Osgood wrote:
> On Wed, Dec 17, 2008 at 8:55 PM, Peter Stuge  wrote:
> > Corey Osgood wrote:
> > > would there be any problem with calling functions to enable mtrrs
> > > and the cache (if it's not already) from the end of disable_car()?
> >
> > None whatsoever. Commit at will.
>
> It didn't help, disable_car() already does essentially the same thing;
> disable cache, enable mtrrs, re-enable cache. I'm comparing memtest between
> the stock bios and coreboot right now, the throughput for the stock bios is
> 6122MB/s for L1 cache and 574MB/s for memory. With v2, it's 3265 and 191,
> respectively (using ROMCC), with v3 it's 15 and 18. So something's not right
> somewhere. The other thing is that in v2 and v3, the CPU is only running at
> 800MHz in memtest, but with the stock BIOS it runs at 1.5GHz, that's
> probably the reason for the differing cache throughputs. Anyways, I'm diving
> into both v2 and v3 and trying to track down why this is running so slowly.

<insert happy dance here>
> From the currently-running memtest86 on coreboot-v3:

L1 Cache:  128K   3265 MB/s
Memory  :  480M    240 MB/s

That's right, faster then v2 :) I've managed to coerce the northbridge into
running the memory at 200MHz (DDR400) without locking up the system like it
does in v2, and also to use 1GB of ram, which the fuctory BIOS only sees as
512MB, and v2 for some reason trips over. However, it's a mixed blessing,
even though memtest86 now runs at an acceptable speed, coreboot is still
running fairly slowly. I'm attaching a patch that brings over mtrr.c from v2
and hacks it to work with v3, but no sign-off because IMO it's not ready to
be committed. I'll try booting a FILO payload and a kernel tomorrow, but
right now it's time for some sleep.

-Corey

[Myles Watson]

On Wed, Dec 17, 2008 at 11:38 PM, Corey Osgood wrote:
> On Wed, Dec 17, 2008 at 11:04 PM, Corey Osgood wrote:
> > On Wed, Dec 17, 2008 at 8:55 PM, Peter Stuge  wrote:
> > > Corey Osgood wrote:
> > > > would there be any problem with calling functions to enable mtrrs
> > > > and the cache (if it's not already) from the end of disable_car()?
> > >
> > > None whatsoever. Commit at will.
> >
> > It didn't help, disable_car() already does essentially the same thing;
> > disable cache, enable mtrrs, re-enable cache. I'm comparing memtest between
> > the stock bios and coreboot right now, the throughput for the stock bios is
> > 6122MB/s for L1 cache and 574MB/s for memory. With v2, it's 3265 and 191,
> > respectively (using ROMCC), with v3 it's 15 and 18. So something's not right
> > somewhere. The other thing is that in v2 and v3, the CPU is only running at
> > 800MHz in memtest, but with the stock BIOS it runs at 1.5GHz, that's
> > probably the reason for the differing cache throughputs. Anyways, I'm diving
> > into both v2 and v3 and trying to track down why this is running so slowly.
>
> <insert happy dance here>
>
> From the currently-running memtest86 on coreboot-v3:
> L1 Cache:  128K   3265 MB/s
> Memory  :  480M    240 MB/s

Congratulations!
> That's right, faster then v2 :) I've managed to coerce the northbridge into
> running the memory at 200MHz (DDR400) without locking up the system like it
> does in v2, and also to use 1GB of ram, which the fuctory BIOS only sees as
> 512MB, and v2 for some reason trips over. However, it's a mixed blessing,
> even though memtest86 now runs at an acceptable speed, coreboot is still
> running fairly slowly. I'm attaching a patch that brings over mtrr.c from v2
> and hacks it to work with v3, but no sign-off because IMO it's not ready to
> be committed. I'll try booting a FILO payload and a kernel tomorrow, but
> right now it's time for some sleep.

I know it takes a while to try new things, but have you tried a different
debug level.  Switching Serengeti from BIOS_SPEW to BIOS_INFO cuts boot time
by about 10x.  I'm interested if that's true for you too.

Thanks,
Myles

[Corey Osgood]

On Thu, Dec 18, 2008 at 9:22 AM, Myles Watson  wrote:
> On Wed, Dec 17, 2008 at 11:38 PM, Corey Osgood wrote:
> > On Wed, Dec 17, 2008 at 11:04 PM, Corey Osgood wrote:
> > > On Wed, Dec 17, 2008 at 8:55 PM, Peter Stuge  wrote:
> > > > Corey Osgood wrote:
> > > > > would there be any problem with calling functions to enable mtrrs
> > > > > and the cache (if it's not already) from the end of disable_car()?
> > > >
> > > > None whatsoever. Commit at will.
> > >
> > > It didn't help, disable_car() already does essentially the same thing;
> > > disable cache, enable mtrrs, re-enable cache. I'm comparing memtest between
> > > the stock bios and coreboot right now, the throughput for the stock bios is
> > > 6122MB/s for L1 cache and 574MB/s for memory. With v2, it's 3265 and 191,
> > > respectively (using ROMCC), with v3 it's 15 and 18. So something's not right
> > > somewhere. The other thing is that in v2 and v3, the CPU is only running at
> > > 800MHz in memtest, but with the stock BIOS it runs at 1.5GHz, that's
> > > probably the reason for the differing cache throughputs. Anyways, I'm diving
> > > into both v2 and v3 and trying to track down why this is running so slowly.
> >
> > <insert happy dance here>
> >
> > From the currently-running memtest86 on coreboot-v3:
> > L1 Cache:  128K   3265 MB/s
> > Memory  :  480M    240 MB/s
>
> Congratulations!
> > That's right, faster then v2 :) I've managed to coerce the northbridge
> > into running the memory at 200MHz (DDR400) without locking up the system
> > like it does in v2, and also to use 1GB of ram, which the fuctory BIOS only
> > sees as 512MB, and v2 for some reason trips over. However, it's a mixed
> > blessing, even though memtest86 now runs at an acceptable speed, coreboot is
> > still running fairly slowly. I'm attaching a patch that brings over mtrr.c
> > from v2 and hacks it to work with v3, but no sign-off because IMO it's not
> > ready to be committed. I'll try booting a FILO payload and a kernel
> > tomorrow, but right now it's time for some sleep.
>
> I know it takes a while to try new things, but have you tried a different
> debug level.  Switching Serengeti from BIOS_SPEW to BIOS_INFO cuts boot time
> by about 10x.  I'm interested if that's true for you too.

Still running with no errors, 9 hours later :) I dropped the debug level
from SPEW to DEBUG and it helped greatly, it seems for some reason that v3
takes longer to print messages then v2 did. Also, disabling the console log
buffer seems to have shaved a little time off, but I couldn't say for sure.

-Corey

[Myles Watson]

On Thu, Dec 18, 2008 at 9:07 AM, Corey Osgood wrote:
> On Thu, Dec 18, 2008 at 9:22 AM, Myles Watson  wrote:
> > On Wed, Dec 17, 2008 at 11:38 PM, Corey Osgood wrote:
> > > On Wed, Dec 17, 2008 at 11:04 PM, Corey Osgood wrote:
> > > > On Wed, Dec 17, 2008 at 8:55 PM, Peter Stuge  wrote:
> > > > > Corey Osgood wrote:
> > > > > > would there be any problem with calling functions to enable mtrrs
> > > > > > and the cache (if it's not already) from the end of disable_car()?
> > > > >
> > > > > None whatsoever. Commit at will.
> > > >
> > > > It didn't help, disable_car() already does essentially the same thing;
> > > > disable cache, enable mtrrs, re-enable cache. I'm comparing memtest between
> > > > the stock bios and coreboot right now, the throughput for the stock bios is
> > > > 6122MB/s for L1 cache and 574MB/s for memory. With v2, it's 3265 and 191,
> > > > respectively (using ROMCC), with v3 it's 15 and 18. So something's not right
> > > > somewhere. The other thing is that in v2 and v3, the CPU is only running at
> > > > 800MHz in memtest, but with the stock BIOS it runs at 1.5GHz, that's
> > > > probably the reason for the differing cache throughputs. Anyways, I'm diving
> > > > into both v2 and v3 and trying to track down why this is running so slowly.
> > >
> > > <insert happy dance here>
> > >
> > > From the currently-running memtest86 on coreboot-v3:
> > > L1 Cache:  128K   3265 MB/s
> > > Memory  :  480M    240 MB/s
> >
> > Congratulations!
> > > That's right, faster then v2 :) I've managed to coerce the northbridge
> > > into running the memory at 200MHz (DDR400) without locking up the system
> > > like it does in v2, and also to use 1GB of ram, which the fuctory BIOS only
> > > sees as 512MB, and v2 for some reason trips over. However, it's a mixed
> > > blessing, even though memtest86 now runs at an acceptable speed, coreboot is
> > > still running fairly slowly. I'm attaching a patch that brings over mtrr.c
> > > from v2 and hacks it to work with v3, but no sign-off because IMO it's not
> > > ready to be committed. I'll try booting a FILO payload and a kernel
> > > tomorrow, but right now it's time for some sleep.
> >
> > I know it takes a while to try new things, but have you tried a different
> > debug level.  Switching Serengeti from BIOS_SPEW to BIOS_INFO cuts boot time
> > by about 10x.  I'm interested if that's true for you too.
>
> Still running with no errors, 9 hours later :) I dropped the debug level
> from SPEW to DEBUG and it helped greatly, it seems for some reason that v3
> takes longer to print messages then v2 did. Also, disabling the console log
> buffer seems to have shaved a little time off, but I couldn't say for sure.

It's possible that that's because printk is running out of the ROM.  There
have been some discussions on the list about that.

Thanks,
Myles

[Corey Osgood]

On Wed, Dec 17, 2008 at 6:51 PM, Carl-Daniel Hailfinger <
[e-mail]> wrote:
> On 17.12.2008 22:19, Corey Osgood wrote:
> > On Wed, Dec 17, 2008 at 3:24 PM, Corey Osgood <[e-mail]
> > wrote:
> > > On Wed, Dec 17, 2008 at 2:03 PM, Myles Watson
>
> wrote:
> > > > On Wed, Dec 17, 2008 at 11:43 AM, Corey Osgood <[e-mail]
> >
> > wrote:
> > > > > On Tue, Dec 16, 2008 at 12:35 PM, Myles Watson <[e-mail]
> >
> > wrote:
> > > > > > Corey,
> > > > > >
> > > > > > I've been looking through the v2 code, but I don't see anywhere that
>
> pci
> > > > > > config reads/writes are enabled before scanning.  If you're
>
> interested, you
> > > > > > could send me a v2 boot log and I'll try to help more. You could also
>
> try
> > > > > > doing a direct pci config read to the device to see if it works
>
> before the
> > > > > > hang.
> > > > >
> > > > > I got looking at some other drivers and reading some other mails on
>
> the
> > > > > list, and changing pci_ops to use cf0/cf8 fixed it, and also fixed my
> > > > > problems with the ide and sata drivers hanging (so all those phase3
> > > > > functions are back in phase6 where they belong). The system now boots
>
> to
> > > > > memtest and actually sees the memory to test now, but I'm still having
>
> a
> > > > > problem building the cpu driver, which means booting is EXTREMEMLY
>
> slow. The
> > > > > stage2 driver is in via/c7.c, but no matter where I try to include it
>
> in the
> > > > > make files, arch/x86/Makefile or mainboard/jetway/j7f2/Makefile, I get
>
> this
> > > > > error:
> > > > >
> > > > > make: *** No rule to make target
>
> `/home/corey/coreboot/coreboot-v3/build/mainboard/jetway/j7f2//home/corey/coreboot/coreboot-v3/arch/x86/via/c7.o',
> > > > > needed by `/home/corey/coreboot/coreboot-v3/build/coreboot.stage2'.
>
> Stop.
> > > > > I'm no expert on makefiles, so I could use a hand. I've tried to
>
> locate
> > > > > where/how geodelx/cpu.c is built, but it doesn't seem that it ever is,
> > > > > adding a #error to the file still lets alix1c and other geodelx boards
>
> build
> > > > > without error.
> > > > >
> > > > > Other then that, things are looking VERY promising, I'm finishing up a
> > > > > few things I put off before, and once the CPU driver is running I'd
>
> like to
> > > > > try booting a kernel :)
> > > > >
> > > > > Thanks,
> > > > > Corey
> > > >
> > > > I agree with Ron.  You're doing good work and we could help you easier
>
> if
> > > > we commit it.  I added one more line to your Makefile and it tries to
>
> build
> > > > the file.
> > > >
> > > > I think the c7.c file should move, but for now it helps.
> > > >
> > > > Thanks,
> > > > Myles
> > >
> > > Ok, adding it there work. But why does it work there but nowhere else?
>
> I'll
> > > try to make a commit within the hour, I've just got to split the
>
> c7/cn700
> > > stuff off from the other hacking I've been doing.
> >
> > self-acked and committed, feel free to move c7.c anywhere you think it
> > belongs ;) I've self-acked for expediency, I'm about to brave a snowstorm
>
> to
> > get to school for a final, and won't be back for probably 4 hours or so.
>
> I
> > also updated the epia-cn dts, so it should be in the same state as the
>
> j7f2
> > if you fix the superio stuff.
>
> Sorry I didn't find time to review this sooner. Is it intentional that
> one of the files written by you had a (C) coresystems?

Yes - those files are pretty much direct copies from v2 code, just with the
v3 driver struct, x_t -> struct x changes, and include files fixed.

-Corey