Re: [coreboot] s289{1,2,5} whitespace (3583) and questions
> -Original Message-
> From: yhlu [mailto:[EMAIL PROTECTED]
> Sent: Saturday, September 20, 2008 4:06 PM
> To: Myles Watson
> Cc: coreboot@coreboot.org
> Subject: Re: [coreboot] s289{1,2,5} whitespace (3583) and questions
>
> On Thu, Sep 18, 2008 at 8:32 AM, Myles Watson <[EMAIL PROTECTED]> wrote:
> > I'd like to understand the v2 code for the Tyan s289{1,2,5} boards. As
> part
> > of that I fixed some whitespace. It was committed in 3583.
> >
> > Here's a list of my questions so far (I'm trying to understand
> differences)
> >
> > auto.c:
> >
> > Why does s2895 include arch/cpu.h and amd/model_fxx/model_fxx_msr.h
>
> > Why does s2895 not define K8_HT_FREQ_1G_SUPPORT
>
> it is not tested
>
> > Why does s2892 have report_bist_failure commented out
> >
> > cache_as_ram_auto.c:
> >
> > Why does s2892 have the soft_reset commented out, but still print
> ht_reset
> > Why does s2892 not get the return value
> >
> > Options.lb:
> > Why is _RAMBASE different for s2895 (0x10) than s2892 and s2891
> (0x4000)
>
> should be ok.
>
> > Why does s2891 use CONFIG_PCI_64BIT_PREF_MEM=1, but 2 and 5 don't
> only test with that with that card need that feature.
> >
> > These three lines are missing from s2892:
> > default ENABLE_APIC_EXT_ID=0
> > default APIC_ID_OFFSET=0x10
> > default LIFT_BSP_APIC_ID=0
> should be ok, already disable with
> ENABLE_APIC_EXT_ID=0
> >
> > failover.c:
> > Only s2891 passes nodeid to early_mtrr_init_detected
> > Only s2895 doesn't call enable_lapic()
> >
> > irq_tables.c:
> > All the #if 0 code, is it needed for documentation?
> should be corrected, so some uitil could do mapping between bus/dev to
> slot...
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] buildrom: Add support for the ASUS A8N-E
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Uwe Hermann > Sent: Thursday, October 02, 2008 9:52 AM > To: Jordan Crouse > Cc: coreboot@coreboot.org > Subject: Re: [coreboot] buildrom: Add support for the ASUS A8N-E > > On Wed, Oct 01, 2008 at 03:58:59PM -0600, Jordan Crouse wrote: > > > Doesn't seem to build with LZMA enabled, only if you disable it. The > > > same seems to happen to all boards which don't have a Config-lab.lb > > > which should probably be fixed. IIRC LZMA should work regardless of > > > whether you have LAB as payload or not(?) > > > > LZMA in v2 needs options set in the Config.lb that happen to > > be set in Config-lab.lb, so we sort of made the arbitrary decision to > > just use that .lb if LZMA is enabled. I dislike this solution > immensely, > > but I can't think of a good way to work around it unless we generate the > > Config.lb at runtime, which has its own bug-a-bears. Yet another > > situation where v3 will save us all... :( > > The original reason it was named Config-lab.lb was that some times it uses a larger chip than is default on the board. It also is generally fallback-only to allow for the larger payload. > > If you want to rename Config-lab.lb to something more descriptive, then > > be my guest. You have my ack for that. > > Maybe Config-lzma.lb then. I might send a patch for that. Definitely a better name. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] stop_ap is missing for QEMU, breaks v3 compile
Make v3 for QEMU build again by adding stop_ap which does nothing. I'm not
sure this is the right place for it, but it compiles.
Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
Thanks,
Myles
Index: mainboard/emulation/qemu-x86/stage1.c
===
--- mainboard/emulation/qemu-x86/stage1.c (revision 880)
+++ mainboard/emulation/qemu-x86/stage1.c (working copy)
@@ -27,6 +27,11 @@
/* Nothing to do for QEMU. */
}
+void stop_ap(void)
+{
+ /* Nothing to do for QEMU. */
+}
+
void disable_car(void)
{
}
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] v3 error messages
I can't get v3 for simnow to work with coreinfo as the payload. I get no VGA even if I enable it, VGA is never mentioned in the boot log, and it ends with a triple fault: cisc-cpu.cpp: CProcessor::GenerateException(): shutdown due to triple fault Fatal error reached, stopping simulation. Error message(s) follow: cisc-cpu.cpp: CProcessor::GenerateException(): shutdown due to triple fault NOTE: Simulation cannot be restarted until a reset is asserted. Simulation state CAN be inspected with the SimNow debugger. -- end triple fault -- This error shows up in the boot log for simnow 4.4.4pub: k8_domain_scan_bus pci_scan_bus start bus 0xce2c, bus->dev 0xcbe0 ERROR: pci_scan_bus called with incorrect bus->dev->path.type, path is PCI_DOMAIN: PCI: pci_scan_bus for bus 00 pci_scan_bus: old_devices 0xcee0, dev for this bus 0xcbe0 (domain_0) PCI: scan devfn 0xc0 to 0xff It also shows up now in QEMU (it didn't use to.) pci_domain_scan_bus: calling pci_scan_bus pci_scan_bus start bus 0xac0c, bus->dev 0xa9c0 ERROR: pci_scan_bus called with incorrect bus->dev->path.type, path is PCI_DOMAIN: PCI: pci_scan_bus for bus 00 This "Not a multi function device" message is new to QEMU too. PCI: 00:00.0 [PCI: 8086:1237] enabled PCI: pci_scan_bus pci_probe_dev returns dev 0xb918(dynamic PCI: 00:00.0) Not a multi function device, or the device is not present. Skip to next device. PCI: devfn 0x8 pci_scan_get_dev: list is 0x0008fee0, *list is 0xacc0 Has anyone gotten v3 + coreinfo to work on simnow 4.4.4pub? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 error messages
> -Original Message- > From: Jordan Crouse [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 02, 2008 3:39 PM > To: Myles Watson > Cc: Coreboot > Subject: Re: v3 error messages > > On 02/10/08 14:58 -0600, Myles Watson wrote: > > I can't get v3 for simnow to work with coreinfo as the payload. I get > no > > VGA even if I enable it, VGA is never mentioned in the boot log, and it > ends > > with a triple fault: > > > > cisc-cpu.cpp: CProcessor::GenerateException(): shutdown due to triple > fault > > > > Fatal error reached, stopping simulation. Error message(s) follow: > > > > cisc-cpu.cpp: CProcessor::GenerateException(): shutdown due to triple > fault > > > > NOTE: Simulation cannot be restarted until a reset is asserted. > > Simulation state CAN be inspected with the SimNow debugger. > > > > -- end triple fault -- > > > > This error shows up in the boot log for simnow 4.4.4pub: > > k8_domain_scan_bus > > pci_scan_bus start bus 0xce2c, bus->dev 0xcbe0 > > ERROR: pci_scan_bus called with incorrect bus->dev->path.type, path is > > PCI_DOMAIN: > > PCI: pci_scan_bus for bus 00 > > pci_scan_bus: old_devices 0xcee0, dev for this bus 0xcbe0 > (domain_0) > > PCI: scan devfn 0xc0 to 0xff > > > > It also shows up now in QEMU (it didn't use to.) > > pci_domain_scan_bus: calling pci_scan_bus > > pci_scan_bus start bus 0xac0c, bus->dev 0xa9c0 > > ERROR: pci_scan_bus called with incorrect bus->dev->path.type, path is > > PCI_DOMAIN: > > PCI: pci_scan_bus for bus 00 > > > > This "Not a multi function device" message is new to QEMU too. > > PCI: 00:00.0 [PCI: 8086:1237] enabled > > PCI: pci_scan_bus pci_probe_dev returns dev 0xb918(dynamic PCI: > 00:00.0) > > Not a multi function device, or the device is not present. Skip to next > > device. > > PCI: devfn 0x8 > > pci_scan_get_dev: list is 0x0008fee0, *list is 0xacc0 > > > > Has anyone gotten v3 + coreinfo to work on simnow 4.4.4pub? > > I ran it once, but there were clearly some issues with it. > I got it running with serial, but it was clearly sick. > > Can you figure out where it triple faulted? That would be > useful for debugging. > It was after the payload started. The serial console gets cleared and then there is no more output until the triple fault. Thanks, Myles > Jordan > > -- > Jordan Crouse > Systems Software Development Engineer > Advanced Micro Devices, Inc. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 error messages
On Thu, Oct 2, 2008 at 9:53 PM, ron minnich <[EMAIL PROTECTED]> wrote: > On Thu, Oct 2, 2008 at 7:36 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > > > > It was after the payload started. The serial console gets cleared and > then > > there is no more output until the triple fault. > > > > can you try filo? I would like to see if we can get at least to both > having filo work. Filo 75 comes up to its grub-like prompt in the serial console. Even though I enable option ROMS, VGA doesn't get initialized. Thanks, Myles > > > ron > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 error messages
> -Original Message- > From: ron minnich [mailto:[EMAIL PROTECTED] > Sent: Friday, October 03, 2008 9:31 AM > To: Myles Watson > Cc: Jordan Crouse; Coreboot > Subject: Re: [coreboot] v3 error messages > > On Fri, Oct 3, 2008 at 8:29 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > > > Filo 75 comes up to its grub-like prompt in the serial console. Even > though > > I enable option ROMS, VGA doesn't get initialized. > > > > and coreinfo requires vga? > > I'd like to take on one broken thing at a time :-) > > shall we take on vga? I don't think I'm even putting a vga bios in there > yet. Sorry. I didn't realize that was the root problem. Lets put in VGA and see where we get. Thanks, Myles > ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] keyboard tricks in SimNOW?
I found a comment in the Serengeti DTS that says it would be nice to look at an lspci. I thought "I can do that pretty easily." I booted a DSL 4.3 CD with the original BIOS and the keyboard doesn't seem to work. I tried the paste text command and couldn't get that to work either. Each keypress and release is logged correctly by the simulator, but somehow gets lost. I booted with a coreboot + LAB kernel, but there are weird key problems there too. Even though each key shows up correctly in the shell, only a random mix of the characters get passed to the shell (most of the times every other character.) I was able to do an ls /dev/* by typing llss //ddeevv//**, which passed the command once with Enter, then again with the next Enter. Is there a trick to this? I'm tried it on SimNOW 4.4.1pub 4.4.2pub and 4.4.4pub. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] keyboard tricks in SimNOW?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Jordan Crouse > Sent: Friday, October 03, 2008 10:54 AM > To: Myles Watson > Cc: 'Coreboot' > Subject: Re: [coreboot] keyboard tricks in SimNOW? > > On 03/10/08 10:48 -0600, Myles Watson wrote: > > I found a comment in the Serengeti DTS that says it would be nice to > look at > > an lspci. I thought "I can do that pretty easily." > > > > I booted a DSL 4.3 CD with the original BIOS and the keyboard doesn't > seem > > to work. I tried the paste text command and couldn't get that to work > > either. Each keypress and release is logged correctly by the simulator, > but > > somehow gets lost. > > > > I booted with a coreboot + LAB kernel, but there are weird key problems > > there too. Even though each key shows up correctly in the shell, only a > > random mix of the characters get passed to the shell (most of the times > > every other character.) I was able to do an ls /dev/* by typing llss > > //ddeevv//**, which passed the command once with Enter, then again with > the > > next Enter. > > > > Is there a trick to this? I'm tried it on SimNOW 4.4.1pub 4.4.2pub and > > 4.4.4pub. > > Hmm - I don't know if there is a trick for that or not. I booted a > Ubuntu rootfs the other day, and it seemed to work okay, I'll try > to play around and see if I can break it. I'll send your message > on to the SimNow team to see if they recognize the problem. > > I have noticed, however, that the SimNow GUI doesn't take kindly > if I use ctrl-alt- to switch workspaces - something about the > control characters seems to confuse it. Perhaps you are hitting > something similar. I habitually use ctrl-alt-tab for window switching. I'll try to control my fingers and see if that helps. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] keyboard tricks in SimNOW?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Jordan Crouse > Sent: Friday, October 03, 2008 10:54 AM > To: Myles Watson > Cc: 'Coreboot' > Subject: Re: [coreboot] keyboard tricks in SimNOW? > > On 03/10/08 10:48 -0600, Myles Watson wrote: > > I found a comment in the Serengeti DTS that says it would be nice to > look at > > an lspci. I thought "I can do that pretty easily." > > > > I booted a DSL 4.3 CD with the original BIOS and the keyboard doesn't > seem > > to work. I tried the paste text command and couldn't get that to work > > either. Each keypress and release is logged correctly by the simulator, > but > > somehow gets lost. > > > > I booted with a coreboot + LAB kernel, but there are weird key problems > > there too. Even though each key shows up correctly in the shell, only a > > random mix of the characters get passed to the shell (most of the times > > every other character.) I was able to do an ls /dev/* by typing llss > > //ddeevv//**, which passed the command once with Enter, then again with > the > > next Enter. > > > > Is there a trick to this? I'm tried it on SimNOW 4.4.1pub 4.4.2pub and > > 4.4.4pub. > > Hmm - I don't know if there is a trick for that or not. I booted a > Ubuntu rootfs the other day, and it seemed to work okay, I'll try > to play around and see if I can break it. I'll send your message > on to the SimNow team to see if they recognize the problem. > > I have noticed, however, that the SimNow GUI doesn't take kindly > if I use ctrl-alt- to switch workspaces - something about the > control characters seems to confuse it. Perhaps you are hitting > something similar. It seems that DSL doesn't empty the keyboard buffer for some reason. If I keep typing long enough it gives this warning: m_KybKeyBuffer: dropping byte 24 buffer full Interesting that this only happens after it boots. I can type at the boot prompt as long as I type slowly. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Missing devices in v3 serengeti
> -Original Message- > From: ron minnich [mailto:[EMAIL PROTECTED] > Sent: Friday, October 03, 2008 11:12 AM > To: Myles Watson > Subject: Re: [coreboot] keyboard tricks in SimNOW? > > On Fri, Oct 3, 2008 at 10:09 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > >> I don't know the trick but > >> > >> you can always just look at the view config space window :-) > > > > I don't see the VGA device or Network card in that view. I was thinking > > maybe that was why it doesn't get initialized? > > Did you wait until after stage2? Things get set up in stage2 that are > not initially visible. > > Other than that, it's bug fix time. Here's the contents of the Config space window Sorry it's sparse. I couldn't copy and paste out of that window. BUS DEV FUN NAME 0 6 0 AMD-8111 PCI 0 7 0 LPC 0 7 1 IDE 0 7 2 SMBUS 7 3 ACPI 7 7 Simple Comms Controller (v2&v3, not in Factory BIOS) 10 0 AMD-8132 10 1 11 0 11 1 24 0 K8 24 1 24 2 24 3 1 0 0 AMD-8111 USB 0 1 1 4 0 Display Controller (Factory and v2, missing in v3) 1 5 0 82540 Gigabit Eth (Factory and v2, missing in v3) Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] triple fault in SimNOW
> -Original Message- > From: ron minnich [mailto:[EMAIL PROTECTED] > Sent: Friday, October 03, 2008 3:10 PM > To: Myles Watson > Cc: Coreboot > Subject: Re: [coreboot] triple fault in SimNOW > > how are you switching? close the bsd, or just change the bios rom and > reset and go? Just reset and go. If you close the bsd you'll never see PCI problems of values that are not cleared on a reset or CMOS problems. Since switching the BIOS only changes the code the simulation runs, I would have thought it would be totally safe. If we can't trust that it makes life a lot more interesting. When you press the "log config space" button, do you know where the log goes? In the log you can see that PCI bus 0 device 6 is initialized, but bus 1 never shows up anywhere. Bus 1 is the PCI bus from the bridge at bus 0 dev 6 as far as I can tell. > I'm not totally inclined to totally trust the sim depending on how you > are doing the switch. The sim seems to like reset between switching > bios flash parts. My procedure is to have a coreboot bsd, and always > close and open that bsd when I change things; and, finally, once the > bsd opens, I always hit reset. I always start with the same bsd, no matter what I'm doing. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 updates
Ron, I'd like to help here more, but I don't understand the v3 architecture very well. I'm looking through the differences between the configuration spaces of the factory BIOS, v2, and v3. I also noticed that phase3_scan is null in 8111_ops. Could that be the problem? Which function should be used to scan this bus? I tried pci_scan_bridge and pci_domain_scan_bus, but neither Just Worked for me. Thanks, Myles > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of ron minnich > Sent: Monday, October 06, 2008 11:19 AM > To: Coreboot > Subject: [coreboot] v3 updates > > I just pushed a lot of bits across. > > The problem with serengeti, if anybody wants to work on it, is that > the 8111 device is not scanning its subordinate busses. It would be > great if someone could take a look. > > The dbm690t is almost ready for test, once the stage0 fits.It's 23k. > Help welcome. > > ron > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 updates
Could you help me understand how we get from this picture from the 8111 data sheet to the serengeti dts? It looks like to me that the nic and ide portions should be included in the amd8111 dts, not the board dts. I'm also confused why the ide and nic entries seem to be on the same bus. Thanks, Myles On Mon, Oct 6, 2008 at 12:06 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > Ron, > > I'd like to help here more, but I don't understand the v3 architecture very > well. I'm looking through the differences between the configuration spaces > of the factory BIOS, v2, and v3. > > I also noticed that phase3_scan is null in 8111_ops. Could that be the > problem? Which function should be used to scan this bus? I tried > pci_scan_bridge and pci_domain_scan_bus, but neither Just Worked for me. > > Thanks, > Myles > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] > > On Behalf Of ron minnich > > Sent: Monday, October 06, 2008 11:19 AM > > To: Coreboot > > Subject: [coreboot] v3 updates > > > > I just pushed a lot of bits across. > > > > The problem with serengeti, if anybody wants to work on it, is that > > the 8111 device is not scanning its subordinate busses. It would be > > great if someone could take a look. > > > > The dbm690t is almost ready for test, once the stage0 fits.It's 23k. > > Help welcome. > > > > ron > > > > -- > > coreboot mailing list: coreboot@coreboot.org > > http://www.coreboot.org/mailman/listinfo/coreboot > > <>-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 updates
All right. I'd love to help fix it. Here's the relevant snippet from
serengeti/dts
/* guesses; we need a real lspci */
[EMAIL PROTECTED],0 {
/config/("northbridge/amd/k8/pci");
[EMAIL PROTECTED],0 {
/config/("southbridge/amd/amd8111/amd8111.dts");
};
[EMAIL PROTECTED],0 {
/config/("southbridge/amd/amd8111/ide.dts");
};
[EMAIL PROTECTED],0 {
/config/("southbridge/amd/amd8111/nic.dts");
};
};
from amd8111.dts:
{
device_operations = "amd8111";
};
from amd8111/ide.dts:
{
device_operations = "amd8111_ide";
ide0_enable = "0";
ide1_enable = "1";
};
from amd8111/nic.dts:
{
device_operations = "amd8111_nic";
phy_lowreset = "0";
};
I see that the device_operations structures get used, but I don't see how
there are parameters being passed here. I'm sorry to be so clueless, I
don't understand the meaning of the dts yet.
Thanks,
Myles
On Mon, Oct 6, 2008 at 2:35 PM, ron minnich <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 6, 2008 at 11:59 AM, Myles Watson <[EMAIL PROTECTED]> wrote:
> > Could you help me understand how we get from this picture from the 8111
> data
> > sheet to the serengeti dts? It looks like to me that the nic and ide
> > portions should be included in the amd8111 dts, not the board dts. I'm
> also
> > confused why the ide and nic entries seem to be on the same bus.
> >
>
> nic and ide are in mainboard dts so we can set control variables.
>
> v3 is like v2 in that dts topology reflects mainboard topology but
> does also show some detailsof chipset topology.
>
> nic and ide on same bus? That's my mistake, pure and simple. The
> mainboard dts is wrong.
>
> We're in the learning phase here on dts for boards like this. We
> understand simple boards like geode boards. This is our first complex
> hierarchy board.
>
> Welcome to Adventure!
>
> ron
>
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r3638 - intrunk/coreboot-v2/src/mainboard: nvidia/l1_2pvv tyan/s2912tyan/s2912_fam10
> On Mon, Oct 06, 2008 at 11:00:46PM +0200, [EMAIL PROTECTED] wrote: > > Whitespace fixes. > > Thanks for the cleanups! What are you using to fixup the code? Some > scripts or do you do it manually? I've noticed that you only fix > whitespace issues, and sometimes that's also fixed inconsistently. Sorry about the inconsistencies. I mostly am comparing different versions of boards that I think should be similar, and trying to make them similar enough that a side-by-side diff shows me something besides white space differences. There are a lot of boards in v2 that have a lot of copy-and-paste goodness and badness. Anything besides white space cleanups have proven to be controversial in the past. I think most everyone has their own strongly-held opinions, and I'm not that opinionated on most of those issues, so I've steered clear. Thanks, Myles > Please consider basing the cleanups on the standard 'indent' options > as per http://www.coreboot.org/Development_Guidelines#Coding_Style. > That will also fix many other issues not related to indentation while > we're at it. > > indent -npro -kr -i8 -ts8 -sob -l80 -ss -ncs *.[ch] > > (will only work for C code, not Config.lb files, of course) > > But note that you should probably _not_ blindly commit 'indent'ed code, > it sometimes gets stuff wrong (which needs some manual fixing), and > some of the transformations (while correct) look a lot uglier > afterwards -- which I personally also fixup after running indent. > > > HTH, Uwe. > -- > http://www.hermann-uwe.de | http://www.holsham-traders.de > http://www.crazy-hacks.org | http://www.unmaintained-free-software.org > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 updates
> Here is a proposed change to dts. I've forgotten all I ever knew about
> the 8111 so I am pretty sure this is incomplete, but it's something
> like what we want.
>
>
> Index: mainboard/amd/serengeti/dts
> ===
> --- mainboard/amd/serengeti/dts (revision 904)
> +++ mainboard/amd/serengeti/dts (working copy)
> @@ -28,18 +28,17 @@
> /config/("northbridge/amd/k8/domain");
> [EMAIL PROTECTED],0{
> };
> - /* guesses; we need a real lspci */
> [EMAIL PROTECTED],0 {
> /config/("northbridge/amd/k8/pci");
> - [EMAIL PROTECTED],0 {
> + [EMAIL PROTECTED],0 {
>
/config/("southbridge/amd/amd8111/amd8111.dts");
> + [EMAIL PROTECTED],0 {
> +
/config/("southbridge/amd/amd8111/nic.dts");
> + };
> };
> [EMAIL PROTECTED],0 {
> /config/("southbridge/amd/amd8111/ide.dts");
> };
> - [EMAIL PROTECTED],0 {
> - /config/("southbridge/amd/amd8111/nic.dts");
> - };
> };
> [EMAIL PROTECTED],0 {
> /config/("northbridge/amd/k8/pci");
>
> It still doesn't seem quite right. Segher?
I've played with it a little more, no luck yet. Could you help me
understand the naming convention?
[EMAIL PROTECTED],0 = pci at device 5 function 0 ?
I don't see how we say there's a pci bridge at device 0 function 0 on this
bus, then specify the devices on the pci bus from there.
Should we be using the amd8111/pci.dts here too? Maybe that's why you had
the phase3_scan = 0, since the pci bus should take care of its scan?
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] keyboard tricks in SimNOW?
> -Original Message- > From: Jordan Crouse [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 07, 2008 11:10 AM > To: Myles Watson > Subject: Re: keyboard tricks in SimNOW? > > On 06/10/08 10:09 -0600, Myles Watson wrote: > > I'm pretty sure it was the default. My machine can't build a working > LAB > > image right now. It gets the "linuxrc[1] trap divide error". > > > > There also seems to be a problem with the permission bits of > > bin/construct-rom.sh I had to make it executable. I don't know how to > make > > that update in svn, or I'd just do it. > > > > I'm using this image that I built a while ago on a different machine. > > Okay - I just built a v2 image and it works fine. I'm going to try v3 > next. > I forgot to say that I was using the 64-bit kernel. It's smaller and what I needed. Hopefully you get the same success there too. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] AMD Serengeti Cheetah devices
I'm trying to undertand dts better, and found this. This patch removes extra devices from the v2 Config.lb file for serengeti cheetah. The only change without these devices is that now these lines are missing from the log: Disabling static device: PCI: 00:19.0 Disabling static device: PCI: 00:19.1 Disabling static device: PCI: 00:19.2 Disabling static device: PCI: 00:19.3 Signed-off-by: Myles Watson <[EMAIL PROTECTED]> Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Serengeti Cheetah devices
Sorry! Patch attached. Thanks, Myles On Wed, Oct 8, 2008 at 8:43 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > I'm trying to undertand dts better, and found this. This patch removes > extra devices from the v2 Config.lb file for serengeti cheetah. > > The only change without these devices is that now these lines are missing > from the log: > > Disabling static device: PCI: 00:19.0 > Disabling static device: PCI: 00:19.1 > Disabling static device: PCI: 00:19.2 > Disabling static device: PCI: 00:19.3 > > Signed-off-by: Myles Watson <[EMAIL PROTECTED]> > > Thanks, > Myles > Index: src/mainboard/amd/serengeti_cheetah/Config.lb === --- src/mainboard/amd/serengeti_cheetah/Config.lb (revision 3641) +++ src/mainboard/amd/serengeti_cheetah/Config.lb (working copy) @@ -385,23 +385,6 @@ device pci 18.2 on end device pci 18.3 on end end -chip northbridge/amd/amdk8 -device pci 19.0 on # northbridge -chip southbridge/amd/amd8151 -# the on/off keyword is mandatory -device pci 0.0 on end -device pci 1.0 on end -end -end # device pci 19.0 - -device pci 19.0 on end -device pci 19.0 on end -device pci 19.1 on end -device pci 19.2 on end -device pci 19.3 on end -end - - end #pci_domain #chip drivers/generic/debug # device pnp 0.0 off end # chip name -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Serengeti Cheetah devices
> -Original Message- > From: ron minnich [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 08, 2008 9:18 AM > To: Myles Watson > Cc: Coreboot > Subject: Re: [coreboot] AMD Serengeti Cheetah devices > > On Wed, Oct 8, 2008 at 8:14 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > > Sorry! Patch attached. > > > > You don't want to do that. That's cpu1. We may need cpu1 someday :-) > > ron Wouldn't that be a different board? Will it have an 8151 attached there? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Serengeti Cheetah devices
> > Wouldn't that be a different board? Will it have an 8151 attached > there? > > > > serengeti can have one or 2p IIRC. I only have the free version, which only allows one package. That's why I removed the second package and the 8151 which isn't even a supported chip in the free version. It doesn't matter too much. It's just confusing when I'm trying to match up devices. In v3 there's no 8131 or 8151 in the dts. Thanks, Myles > > ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Serengeti Cheetah devices
> -Original Message- > From: ron minnich [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 08, 2008 9:46 AM > To: Myles Watson > Cc: Coreboot > Subject: Re: [coreboot] AMD Serengeti Cheetah devices > > OK, let's go through the v2 for this a bit. It's interesting because, > well, I bet few people have bothered with it and I know I forgot. > > Here we go. This is great! Could we go back one more step to the 8132? It looks like the 8111 hangs off the 8132. > Hope this short writeup helps; I am testing this now. Yes. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Serengeti Cheetah devices
> -Original Message- > From: ron minnich [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 08, 2008 9:58 AM > To: Myles Watson > Cc: Coreboot > Subject: Re: [coreboot] AMD Serengeti Cheetah devices > > On Wed, Oct 8, 2008 at 8:54 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > > > This is great! Could we go back one more step to the 8132? It looks > like > > the 8111 hangs off the 8132. > > it doesn't I think, because the 8132 is a tunnel. So 8111 and 8132 are > peers. That was always my understanding. Marc? That makes sense. So the 8132 doesn't need to be mentioned at all in the dts? I think a comment in the dts would be great. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Serengeti Cheetah devices
Fix the amd8111. Remove the device struct for amd8111.c as it is not a device. Make sure that the phase4_enable_disable is named (or similar is named) in all device structs. Fix the mainboard dts to use the 8111 pci as the bridge. Add bridge keyword to the amd8111 pci dts. This gets to this point: Phase 6: Initializing devices... Phase 6: Root Device init. domain_0_pci0_18_0_pci_0_0_pci: Unknown device path type: 0 Phase 6: init. domain_0_pci0_18_0_pci_0_0_pci: Unknown device path type: 0 missing resource: 10 and stop. Still working on that. BUT: the config space shows bus 1 now! Signed-off-by: Ronald G. Minnich <[EMAIL PROTECTED]> It didn't build until I removed the Makefile change. It complained about multiple definitions. I'm also wondering if all we need to do is disable the 8111's nic and serial controller. They showed up as extra compared to v2. With the Makefile change: Acked-by: Myles Watson <[EMAIL PROTECTED]> Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Serengeti Cheetah devices
> > Why treat nic and ide differently here? I can answer this one. They are on different busses. The nic hangs off the pci controller in the 8111, and IDE doesn't. You can reference the picture from the data sheet in this thread. > > > +++ arch/x86/Makefile (working copy) > > - pci_ops_conf1.c resourcemap.c > > + pci_ops_conf1.c > > Just cleanup? Isn't resourcemap needed because of the change or was > it never needed? It just got moved to a different Makefile. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Serengeti Cheetah devices
> > Why treat nic and ide differently here? And what about that USB? Is > > it automatically added - and ide+nic needs to be explicitly listed? > > I now list them all. Very nice. Now how do we disable the 8111 nic and EHCI (like v2 does)? I'm still curious how that works. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD Serengeti Cheetah devices
> > Very nice. Now how do we disable the 8111 nic and EHCI (like v2 does)? > I'm > > still curious how that works. > > > > Disable for scanning or disable once it is all scanned and address > space allocated? Good question. What did the v2 disable mean? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] v2 and v3 pci differences
Here are the major differences between v2 and v3 initializing serengeti cheetah. The biggest problem is that the memory-mapped I/O ends up in the wrong place (see the Display controller's ROM address) I'll look at it more later, but if someone beats me to it I won't complain :) Thanks, Myles 060 AMD-8111 PCI v3 sets parity error response, v2 doesn't v2 has FD00FC00 for IO Base/LIM v3 has 0100 140Display Controller v3 sets parity error response, v2 doesn't v3 sets SERR# Enable, v2 doesn't v2 has FC00 and FD053000 for base and lim v3 has and 01055000 v2 has FD040001 v3 has 01040001 for ROM address 0240 K8 [Athlon64/Opteron] HyperTransport Technology Configuration v2 thinks nodeID is 1 in 0x60 v3 doesn't enable the second processor in 0x68 v2 sets a reserved bit in 0x6c 0241 K8 [Athlon64/Opteron] Address Map base and limits messed up in v3 using 0x012000 instead of 0x0fc000 in v2 base smaller than limit! 0xb8 & 0xbc in v3 limit 0xdc is 0x02020 v2 has 0x000. 0242 K8 [Athlon64/Opteron] DRAM Controller reserved bits differ in 0x88 v2 sets reserved bit 12 in 0x94 0243 K8 [Athlon64/Opteron] Miscellaneous Control 0x44 v2 sets bits 6, 25,27 27 is NB MCA to CPU 0 enable 0x80 & 0x84 power management totally different 0x90 & 0x94 v2 sets up the GART aperture, v3 doesn't 0xd4 & 0xd8 clock power & timing registers different. v3.pci Description: Binary data v2.pci Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v2 and v3 pci differences
> -Original Message-
> From: ron minnich [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 09, 2008 4:54 PM
> To: Myles Watson
> Cc: Coreboot
> Subject: Re: v2 and v3 pci differences
>
> On Thu, Oct 9, 2008 at 1:58 PM, Myles Watson <[EMAIL PROTECTED]> wrote:
> > Here are the major differences between v2 and v3 initializing serengeti
> > cheetah. The biggest problem is that the memory-mapped I/O ends up in
> the
> > wrong place (see the Display controller's ROM address)
>
> This one is easy:
>
> if ((dev->on_mainboard) && (dev->rom_address == 0)) {
> // Skip it if rom_address is not set in MB Config.lb.
> // TODO: No more Config.lb in coreboot-v3.
> return;
> }
>
>
>
> we have not done it yet.
>
> If anybody wants to get to this before I do, the help is appreciated.
> I think it needs a dtc fix.
>
> i.e. in a dts for a part,
> rom_address = "fff0";
> and the dtc needs to know this is one of the special properties in the
> device struct.
>
I agree that needs to be done, but in this case the VGA card is not onboard.
I think the I/O mapping is wrong, which makes it so that when the signature
gets read it comes back 0x instead of 0xa5a5.
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v2 and v3 pci differences
> -Original Message- > From: ron minnich [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 09, 2008 6:53 PM > To: Myles Watson > Cc: Coreboot > Subject: Re: v2 and v3 pci differences > > On Thu, Oct 9, 2008 at 5:08 PM, ron minnich <[EMAIL PROTECTED]> wrote: > > On Thu, Oct 9, 2008 at 5:01 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > > > >> I agree that needs to be done, but in this case the VGA card is not > onboard. > >> I think the I/O mapping is wrong, which makes it so that when the > signature > >> gets read it comes back 0x instead of 0xa5a5. > >> > > > > hmm. Looking again, I don't see that the io mapping is wrong. It's a > tad unusual, but I don't think it's wrong. > > What about it looks wrong other than the fact that is is lower than we > are used to? I guess I jumped to that conclusion because it was so low in the memory space and it wasn't working to read the magic number from the ROM. I'd have to look closer to see another reason why the read fails. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] lar -z option
On Fri, Oct 10, 2008 at 4:14 AM, Roman Yeryomin <[EMAIL PROTECTED]>wrote: > On Thursday 09 October 2008 22:44:20 Roman Yeryomin wrote: > > On Thu, Oct 9, 2008 at 10:33 PM, ron minnich <[EMAIL PROTECTED]> wrote: > > > lar z /tmp/d.bin > > > > lar -z bios.bin > > > > cool :) > > I think it should be in --help also! > > How about including -z option to lar --help? > I think it will be useful for users who read helps ;) There was disagreement about the name, so it was never documented. As I remember, Peter and possibly others were opposed to the name zero-fill being used when filling a section with 0xff. There was never agreement on a replacement name. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] flashrom and the dbm690t
> > I can easily read from the chip on the board. > > But, hot plugging is not working out. > > The basic part is a 49lf008a; putting in 49lf008 or 49lf080 just gets > reads back of ff. Is the difference FWH vs LPC? from SST's site: 8 Mbit Firmware Hub SST49LF008A 8 Mbit LPC Flash SST49LF080A > Ideas welcome. Do BIos saviours exist any more? http://www.ioss.com.tw/web/English/OnlineOrderNow.html Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ### ALDO Windows Coreboot
On Fri, Oct 10, 2008 at 1:10 PM, Steve Spano <[EMAIL PROTECTED]> wrote: > Hi Folks, > > I have an AMD LX800 custom board running coreboot v2 and linux just fine. > > We may now want to use coreboot to boot a Windows2000/XP. I have traced > through the FAQ/lists and assembled this > > 1) ALDO embedded with CorebootV3 > 2) Merged in the LX VGA ROM file (64KB) into the blob/vsa folder > When you say you're using ADLO that means you're not using SeaBIOS? If you're using the ADLO from the v2 util folder, it's out of date. The timeouts are too short for any drive with today's processor speeds. > > My goal right now is to have it recognize a CDROM, install Windows to a 4GB > Compact Flash (as an IDE slave), and then boot onto the CompactFlash as > IDE-Master. > > I cannot seem to get the CDROM to boot. Nor can I get the comapct flash, > with a known good linux image, to boot. > > I get all the way into ALDO during boot, ALDO finds the CDrom/CF but then > it seems like it has some issue scanning the ATA bus. It says that > > "in13_hardisk:function 2 unmapped device for ELDL=80" > This message is benign. Even when it finds your CDROM you'll see this message. > > Also - I assume that ADLO can boot a linux image as well. I believe that's > what I read? > > Should be able to. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 help with PCI_DOMAIN resources
I'd like to see this enabled by config option.
Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
and/or
Acked-by: Myles Watson <[EMAIL PROTECTED]>
If you want to resend it since you wrote it.
Thanks,
Myles
On 10/13/08, ron minnich <[EMAIL PROTECTED]> wrote:
>
> Myles, use this patch. Then send me output.
>
> ron
> Index: lib/console.c
> ===
> --- lib/console.c (revision 920)
> +++ lib/console.c (working copy)
> @@ -136,8 +136,14 @@
> return 0;
> }
>
> + console_tx_byte('<', (void *)0);
> + console_tx_byte(msg_level + '0', (void *)0);
> + console_tx_byte('>', (void *)0);
> +
> + i = 3;
> +
> va_start(args, fmt);
> - i = vtxprintf(console_tx_byte, (void *)0, fmt, args);
> + i += vtxprintf(console_tx_byte, (void *)0, fmt, args);
> va_end(args);
>
> return i;
>
Index: lib/Kconfig
===
--- lib/Kconfig (revision 918)
+++ lib/Kconfig (working copy)
@@ -68,6 +68,11 @@
help
Support for various types of (debugging) consoles.
+config CONSOLE_PREPEND_LOG_LEVEL
+ boolean "Prepend log level to messages"
+ default n
+ depends CONSOLE
+
choice
prompt "Console log level"
default CONSOLE_LOGLEVEL_8
Index: lib/console.c
===
--- lib/console.c (revision 918)
+++ lib/console.c (working copy)
@@ -132,12 +132,22 @@
va_list args;
int i;
+#ifdef CONFIG_CONSOLE_PREPEND_LOG_LEVEL
+ console_tx_byte('<', (void *)0);
+ console_tx_byte(msg_level + '0', (void *)0);
+ console_tx_byte('>', (void *)0);
+
+ i = 3;
+
if (msg_level > console_loglevel()) {
return 0;
}
+#else
+ i = 0;
+#endif
va_start(args, fmt);
- i = vtxprintf(console_tx_byte, (void *)0, fmt, args);
+ i += vtxprintf(console_tx_byte, (void *)0, fmt, args);
va_end(args);
return i;
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 help with PCI_DOMAIN resources
> Anyway, having such an option is a good idea, so: > Acked-by: Uwe Hermann <[EMAIL PROTECTED]> Thanks Uwe and Peter. Committed in 921. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Simple logic fix patch
Because the enable bit was masked off, checking for 0x didn't work. This patch changes the place where the bit is masked. The other way to fix it would be to check for 0xfffe. V2 doesn't seem to have the problem. Signed-off-by: Myles Watson <[EMAIL PROTECTED]> Thanks, Myles pci_rom.diff Description: Binary data -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] AMD K8 define fix
This patch fixes an ifdef that should have been an ifndef. It also changes
white space so that it was obvious what the difference from v2 to v3 was.
Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
Thanks,
Myles
Index: northbridge/amd/k8/domain.c
===
--- northbridge/amd/k8/domain.c (revision 921)
+++ northbridge/amd/k8/domain.c (working copy)
@@ -1,5 +1,5 @@
/*
- * K8 northbridge
+ * K8 northbridge
* This file is part of the coreboot project.
* Copyright (C) 2004-2005 Linux Networx
* (Written by Eric Biederman <[EMAIL PROTECTED]> and Jason Schildt for Linux Networx)
@@ -57,7 +57,7 @@
void f1_write_config32(unsigned int reg, u32 value);
unsigned int amdk8_nodeid(struct device * dev);
-static void k8_ram_resource(struct device * dev, unsigned long index,
+static void k8_ram_resource(struct device * dev, unsigned long index,
unsigned long basek, unsigned long sizek)
{
struct resource *resource;
@@ -87,7 +87,7 @@
{
struct resource *min;
u32 tolm;
- min = 0;
+ min = NULL;
search_bus_resources(bus, IORESOURCE_MEM, IORESOURCE_MEM, tolm_test, &min);
tolm = 0xUL;
if (min && tolm > min->base) {
@@ -125,41 +125,41 @@
}
}
}
-#ifdef CONFIG_PCI_64BIT_PREF_MEM
+#ifndef CONFIG_PCI_64BIT_PREF_MEM
/* Initialize the system wide io space constraints */
resource = new_resource(dev, IOINDEX_SUBTRACTIVE(0, 0));
resource->base = 0x400;
resource->limit = 0xUL;
resource->flags = IORESOURCE_IO | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
-/* Initialize the system wide memory resources constraints */
-resource = new_resource(dev, IOINDEX_SUBTRACTIVE(1, 0));
-resource->limit = 0xfcULL;
-resource->flags = IORESOURCE_MEM | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+ /* Initialize the system wide memory resources constraints */
+ resource = new_resource(dev, IOINDEX_SUBTRACTIVE(1, 0));
+ resource->limit = 0xfcULL;
+ resource->flags = IORESOURCE_MEM | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
#else
-/* Initialize the system wide io space constraints */
-resource = new_resource(dev, 0);
-resource->base = 0x400;
-resource->limit = 0xUL;
-resource->flags = IORESOURCE_IO;
-compute_allocate_resource(&dev->link[0], resource,
-IORESOURCE_IO, IORESOURCE_IO);
+ /* Initialize the system wide io space constraints */
+ resource = new_resource(dev, 0);
+ resource->base = 0x400;
+ resource->limit = 0xUL;
+ resource->flags = IORESOURCE_IO;
+ compute_allocate_resource(&dev->link[0], resource,
+ IORESOURCE_IO, IORESOURCE_IO);
-/* Initialize the system wide prefetchable memory resources constraints */
-resource = new_resource(dev, 1);
-resource->limit = 0xfcULL;
-resource->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
-compute_allocate_resource(&dev->link[0], resource,
-IORESOURCE_MEM | IORESOURCE_PREFETCH,
-IORESOURCE_MEM | IORESOURCE_PREFETCH);
+ /* Initialize the system wide prefetchable memory resources constraints */
+ resource = new_resource(dev, 1);
+ resource->limit = 0xfcULL;
+ resource->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
+ compute_allocate_resource(&dev->link[0], resource,
+ IORESOURCE_MEM | IORESOURCE_PREFETCH,
+ IORESOURCE_MEM | IORESOURCE_PREFETCH);
-/* Initialize the system wide memory resources constraints */
-resource = new_resource(dev, 2);
-resource->limit = 0xfcULL;
-resource->flags = IORESOURCE_MEM;
-compute_allocate_resource(&dev->link[0], resource,
-IORESOURCE_MEM | IORESOURCE_PREFETCH,
-IORESOURCE_MEM);
+ /* Initialize the system wide memory resources constraints */
+ resource = new_resource(dev, 2);
+ resource->limit = 0xfcULL;
+ resource->flags = IORESOURCE_MEM;
+ compute_allocate_resource(&dev->link[0], resource,
+ IORESOURCE_MEM | IORESOURCE_PREFETCH,
+ IORESOURCE_MEM);
#endif
printk(BIOS_DEBUG, "k8_pci_domain_read_resources done\n");
}
@@ -185,68 +185,68 @@
#endif
#if 0
-/* Place the IO devices somewhere safe */
-io = find_resource(dev, 0);
-io->base = DEVICE_IO_START;
+ /* Place the IO devices somewhere safe */
+ io = find_resource(dev, 0);
+ io->base = DEVICE_IO_START;
#endif
#ifdef CONFIG_PCI_64BIT_PREF_MEM
-/* Now reallocate the pci resources memory with the
- * highest addresses I can manage.
- */
-mem1 = find_resource(dev, 1);
-mem2 = find_resource(dev, 2);
+ /* Now reallocate the pci resources memory with the
+ * highest addresses I can manage.
+ */
+ mem1 = find_resource(dev, 1);
+ mem2 = find_resource(dev, 2);
#if 1
-p
Re: [coreboot] AMD K8 define fix
> -Original Message- > From: ron minnich [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 14, 2008 10:31 AM > To: Myles Watson > Cc: Coreboot > Subject: Re: AMD K8 define fix > > On Tue, Oct 14, 2008 at 9:13 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > > This patch fixes an ifdef that should have been an ifndef. It also > changes > > white space so that it was obvious what the difference from v2 to v3 > was. > > > > nice find. I am glad to see that you are going through this code. It > badly needed someone else to take a pass. > > Are things making more sense? Are BARs and ROMs ending up somewhere > sensible? It helped a little, but it's not there yet. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Extra pairs of eyes
I'm tired of staring at this piece of code wondering why printk isn't
working as I expected. Can someone point out what I've obviously missed?
code (inserted in pci_device.c in pci_get_resource() right before the limit
mask and return):
if (resource->flags)
{
printk(BIOS_DEBUG, "%s resource base %08lx limit %08lx size %08lx flags
%08lx\n",
dev_path(dev), resource->base, resource->limit,
resource->size, resource->flags);
printk(BIOS_DEBUG, "\t%s size %lx align %lx gran %lx\n",
dev_path(dev), resource->size,
resource->align, resource->gran);
printk(BIOS_DEBUG, " just broken size %08lx\n", resource->size);
printk(BIOS_DEBUG, " broken align %lx\n", resource->align);
printk(BIOS_DEBUG, "%s resource size %08lx flags %08lx\n",
dev_path(dev), resource->size, resource->flags);
printk(BIOS_DEBUG, "%s align %lx gran %lx\n",
dev_path(dev),
resource->align, resource->gran);
}
output:
PCI: 01:00.0 resource base limit size flags
PCI: 01:00.0 size 1000 align 0 gran c
just broken size 1000
broken align c
PCI: 01:00.0 resource size 1000 flags
PCI: 01:00.0 align c gran c
Notice that size is in the first, 0x1000 in the rest.
Align is 0 in the first, c in the rest.
It looks like printk is botching it. I don't know how else to explain it.
Is there a limit to the number of arguments you can pass to printk?
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Extra pairs of eyes
On Tue, Oct 14, 2008 at 3:23 PM, Carl-Daniel Hailfinger <
[EMAIL PROTECTED]> wrote:
> On 14.10.2008 23:13, Myles Watson wrote:
> > I'm tired of staring at this piece of code wondering why printk isn't
> > working as I expected. Can someone point out what I've obviously missed?
> >
> > code (inserted in pci_device.c in pci_get_resource() right before the
> limit
> > mask and return):
> > if (resource->flags)
> > {
> > printk(BIOS_DEBUG, "%s resource base %08lx limit %08lx size %08lx
> flags
> > %08lx\n",
> >dev_path(dev), resource->base, resource->limit,
> > resource->size, resource->flags);
> >
> > printk(BIOS_DEBUG, "\t%s size %lx align %lx gran %lx\n",
> > dev_path(dev), resource->size,
> > resource->align, resource->gran);
> > printk(BIOS_DEBUG, " just broken size %08lx\n", resource->size);
> >
> > printk(BIOS_DEBUG, " broken align %lx\n", resource->align);
> > printk(BIOS_DEBUG, "%s resource size %08lx flags %08lx\n",
> >dev_path(dev), resource->size, resource->flags);
> >
> > printk(BIOS_DEBUG, "%s align %lx gran %lx\n",
> > dev_path(dev),
> > resource->align, resource->gran);
> > }
> > output:
> > PCI: 01:00.0 resource base limit size flags
> >
> > PCI: 01:00.0 size 1000 align 0 gran c
> > just broken size 1000
> > broken align c
> > PCI: 01:00.0 resource size 1000 flags
> > PCI: 01:00.0 align c gran c
> >
> > Notice that size is in the first, 0x1000 in the rest.
> > Align is 0 in the first, c in the rest.
> >
> > It looks like printk is botching it. I don't know how else to explain
> it.
> > Is there a limit to the number of arguments you can pass to printk?
> >
>
> From a quick glance, this looks strange. Is this v2 or v3?
v3
> I don't trust
> the v3 printk at the moment because I've not reviewed r921 yet.
> Oh, and please be aware that any multicore/multiprocessor machine in v3
> is completely BROKEN right now and has been that way for months. (Yes, I
> have a fix in the queue. Remind me in a few days.)
single core, single processor.
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] AMD K8 define fix
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Peter Stuge > Sent: Tuesday, October 14, 2008 10:24 AM > To: Coreboot > Subject: Re: [coreboot] AMD K8 define fix > > Myles Watson wrote: > > This patch fixes an ifdef that should have been an ifndef. It also > changes > > white space so that it was obvious what the difference from v2 to v3 > was. > > > > Signed-off-by: Myles Watson <[EMAIL PROTECTED]> > > Acked-by: Peter Stuge <[EMAIL PROTECTED]> > Rev 927 Thanks, Myles > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Extra pairs of eyes
> -Original Message-
> From: ron minnich [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 14, 2008 3:29 PM
> To: Myles Watson
> Cc: Coreboot
> Subject: Re: Extra pairs of eyes
>
> On Tue, Oct 14, 2008 at 2:13 PM, Myles Watson <[EMAIL PROTECTED]> wrote:
> > I'm tired of staring at this piece of code wondering why printk isn't
> > working as I expected. Can someone point out what I've obviously
> missed?
> >
> > code (inserted in pci_device.c in pci_get_resource() right before the
> limit
> > mask and return):
> > if (resource->flags)
> > {
> > printk(BIOS_DEBUG, "%s resource base %08lx limit %08lx size %08lx
> flags
> > %08lx\n",
> >dev_path(dev), resource->base, resource->limit,
> > resource->size, resource->flags);
>
> typedef u64 resource_t;
> struct resource {
> resource_t base;/* Base address of the resource */
> resource_t size;/* Size of the resource */
> resource_t limit; /* Largest valid value base + size -1 */
> unsigned long flags;/* Descriptions of the kind of resource */
> unsigned long index;/* Bus specific per device resource id */
> unsigned char align;/* Required alignment (log 2) of the
> resource */
> unsigned char gran; /* Granularity (log 2) of the resource */
> /* Alignment must be >= the granularity of the resource */
> };
>
> Look at the type of resource_t. 64 bits.
> Your printk is printing 64-bit fields as 32 bits. Things are going to
> get very confused.
>
> A common problem.
Should I go through and make all the resource holders resource_t instead of
unsigned long? They're mixed right now.
I was expecting that my 64-bit values would lose their upper bits, but I
wasn't expecting what I got.
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Extra pairs of eyes
> -Original Message-
> From: Stefan Reinauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 14, 2008 5:18 PM
> To: Myles Watson
> Cc: Coreboot; ron minnich
> Subject: Re: [coreboot] Extra pairs of eyes
>
> Myles Watson wrote:
> > I'm tired of staring at this piece of code wondering why printk isn't
> > working as I expected. Can someone point out what I've obviously
> missed?
> >
> > code (inserted in pci_device.c in pci_get_resource() right before the
> > limit mask and return):
> > if (resource->flags)
> > {
> > printk(BIOS_DEBUG, "%s resource base %08lx limit %08lx size %08lx
> > flags %08lx\n",
> >dev_path(dev), resource->base, resource->limit,
> > resource->size, resource->flags);
> >
> > printk(BIOS_DEBUG, "\t%s size %lx align %lx gran %lx\n",
> > dev_path(dev), resource->size,
> > resource->align, resource->gran);
> > printk(BIOS_DEBUG, " just broken size %08lx\n", resource->size);
> >
> > printk(BIOS_DEBUG, " broken align %lx\n", resource->align);
> > printk(BIOS_DEBUG, "%s resource size %08lx flags %08lx\n",
> >dev_path(dev), resource->size, resource->flags);
> >
> > printk(BIOS_DEBUG, "%s align %lx gran %lx\n",
> > dev_path(dev),
> > resource->align, resource->gran);
> > }
> > output:
> > PCI: 01:00.0 resource base limit size flags
> >
> > PCI: 01:00.0 size 1000 align 0 gran c
> > just broken size 1000
> > broken align c
> > PCI: 01:00.0 resource size 1000 flags
> > PCI: 01:00.0 align c gran c
> >
> > Notice that size is in the first, 0x1000 in the rest.
> > Align is 0 in the first, c in the rest.
> >
> > It looks like printk is botching it. I don't know how else to explain
> > it. Is there a limit to the number of arguments you can pass to printk?
> > Thanks,
> > Myles
> I have seen this too, with v2, occasionally.
>
> Make sure the printk fetches 4 bytes from the stack when the parameter
> is 4 bytes.
>
> Which gcc are you using?
>
gcc 4.1.2-13.fc6
Thanks,
Myles
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IB520 Embedded MoBo
> Hi, > I have try to build rom file but I have incountered several difficulties. > There insn't a simple howto step by step? > I follow the AMD_Geode_Porting_Guide but after download the buildrom > and coreboot.. for example where I must do the command make menuconfig > and make? from buildrom/buildrom-devel/ if you want to configure coreboot v3 make coreboot-v3-config if you want to choose the payload (in your case the linux kernel) make menuconfig Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] dtc patch to emit cpus path type
Change statictree emit function to emit path correctly for cpus.
Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
Thanks,
Myles
Index: util/dtc/flattree.c
===
--- util/dtc/flattree.c (revision 929)
+++ util/dtc/flattree.c (working copy)
@@ -572,14 +572,15 @@
fprintf(f, "\t.path = { .type = DEVICE_PATH_ROOT },\n");
}
+ /* special case -- cpus don't have an @ */
+ if (tree->name && !strncmp(tree->name, "cpus", 4)){
+ fprintf(f, "\t.path = {.type=DEVICE_PATH_CPU},\n");
+ }
+
/* from the node names (tree->name) we derive the path */
path = index(tree->name, '@');
if (path && path[1]) {
path++;
- if (!strncmp(tree->name, "cpu", 3)){
- fprintf(f, "\t.path = {.type=DEVICE_PATH_CPU,{.cpu={ .id = 0x%s }}},\n",
-path);
- }
if (!strncmp(tree->name, "bus", 3)){
fprintf(f, "\t.path = {.type=DEVICE_PATH_PCI_BUS,{.pci_bus={ .bus = 0x%s }}},\n",
path);
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Serengeti vga hang
> -Original Message- > From: ron minnich [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 15, 2008 11:05 AM > To: Myles Watson > Cc: Coreboot > Subject: Re: Serengeti vga hang > > On Wed, Oct 15, 2008 at 9:14 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > > Here's the latest log. It hangs in the emulator. I've tried both > > emulators, but to no avail. > > > > Stick with the "non emulator". I'm sorry I didn't get what you meant here. vm86 and x86emu are the two choices to run the ROM and I'm using x86emu. > can you stop it and get us a register dump and tell us where eip is. I'm looking for how to get a register dump, but I don't see it. > If we can get your commits to svn I can try this tonight. Great. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] dtc patch to emit cpus path type
> Acked-by: Ronald G. Minnich <[EMAIL PROTECTED]> Rev 931. Thanks, Myles > > On Wed, Oct 15, 2008 at 9:12 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > > Change statictree emit function to emit path correctly for cpus. > > > > Signed-off-by: Myles Watson <[EMAIL PROTECTED]> > > > > Thanks, > > Myles > > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 comments - was Serengeti vga hang
> There is some 8111/8132 setup that might be causing the VGA issue? Most of your questions I don't have answers for, but right now I'm trying to figure out why the VGA_ENABLE bit in the 8111 gets cleared after it's set. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 comments - was Serengeti vga hang
I was wrong about the bridge bit. Here's the output from the SimNOW windows when it dies: EAX=B102 EBX=002E ECX=000C2067 EDX=000C1022 ESI=0001 EDI=000D ESP=63D0 EBP=000CF11C CS= DS=C000 ES= FS= GS= SS= EFLAGS=oditsZaPc GIF=1 ASID= HCR3= VMHSAVEPA= GuestVMCBPA= :0051 add [bx+si],al :0053 add [bx+si],al :0055 add [bx+si],al :0057 add [bx+si],al :0059 add [bx+si],al :005B add [bx+si],al :005D add [bx+si],al :005F 00FF add bh,bh /*Hightlighted line */ :0061 FF :0062 FF ,P: 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF a...F.a...F.a... 0010,P: 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 F.a...F.a...F.a. 0020,P: FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 ..F.a...F.a...F. 0030,P: 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF a...F.a...F.a... 0040,P: 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 F.a...F.a...F.a. 0050,P: FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 ..F.a...F.a...F. 0060,P: 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF a...F.a...F.a... 0070,P: 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 F.a...F.a...F.a. Execution halted due to Halt Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] v3 comments - was Serengeti vga hang
On Wed, Oct 15, 2008 at 1:03 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > I was wrong about the bridge bit. Here's the output from the SimNOW > windows when it dies: > EAX=B102 EBX=002E ECX=000C2067 EDX=000C1022 > ESI=0001 EDI=000D ESP=63D0 EBP=000CF11C > CS= DS=C000 ES= FS= GS= SS= EFLAGS=oditsZaPc > I would have thought CS =C000 here. I'm looking there first. Myles > > GIF=1 ASID= HCR3= > VMHSAVEPA= GuestVMCBPA= > > :0051 add [bx+si],al > :0053 add [bx+si],al > :0055 add [bx+si],al > :0057 add [bx+si],al > :0059 add [bx+si],al > :005B add [bx+si],al > :005D add [bx+si],al > :005F 00FF add bh,bh > /*Hightlighted line */ :0061 FF > :0062 FF > > ,P: 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF > a...F.a...F.a... > 0010,P: 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 > F.a...F.a...F.a. > 0020,P: FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 > ..F.a...F.a...F. > 0030,P: 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF > a...F.a...F.a... > 0040,P: 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 > F.a...F.a...F.a. > 0050,P: FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 > ..F.a...F.a...F. > 0060,P: 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 FF FF > a...F.a...F.a... > 0070,P: 46 00 61 00 FF FF 46 00 61 00 FF FF 46 00 61 00 > F.a...F.a...F.a. > > Execution halted due to Halt > > Thanks, > Myles > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] SimNOW VGA int 1a
SimNOW goes off into the weeds when int 1a is called. Here's the trace of execution: C000:0003 E9E200 jmp loc_00e8 C000:00E8 60 pusha C000:00E9 E84331 call loc_322f C000:322F B800C0 mov ax,c000 C000:3232 8ED8 mov ds,ax C000:3234 BE mov si, C000:3237 BB2C00 mov bx,002c C000:323A 8B17 mov dx,[bx] C000:323C BB2E00 mov bx,002e C000:323F 8B0F mov cx,[bx] C000:3241 B802B1 mov ax,b102 C000:3244 CD1A int 1a : FF I'm looking for the place where the interrupt vector was supposed to have been set. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
> -Original Message- > From: Tom Sylla [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 15, 2008 2:04 PM > To: Myles Watson > Cc: Coreboot; ron minnich > Subject: Re: [coreboot] SimNOW VGA int 1a > > On Wed, Oct 15, 2008 at 3:56 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > > C000:3241 B802B1 mov ax,b102 > > C000:3244 CD1A int 1a > > : FF > > Yep, "b102" is not a common signature. > > > I'm looking for the place where the interrupt vector was supposed to > have > > been set. > > I am confused, your coreboot log shows several int1a before the failure: > > int1a vector at 10ffef > dev_find_device: find PCI: 1022:2067 > ... > int1a vector at 37da2 > int1a vector at 37da2 > int1a vector at 76682 > int1a vector at 76682 > int1a vector at 76682 > int1a vector at 76682 > int1a vector at 76682 > int1a vector at 76682 Sorry. I should have sent a new log. It's the same as the old one except at the end. Once I switched to vm86 instead of x86emu, there is no longer any output after "Copying VGA ROM Image ..." Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
Here's the next part of the log now that I've enabled setup_realmode_idt (I'm running it right before real_mode_switch_call_vga. Copying VGA ROM image from 0xfe04 to 0xc, 0x8000 bytes BREAK HERE run_bios = 0x944a biosint: INT# 0x18 biosint: eax 0x2e ebx 0x1 ecx 0xfe4 edx 0xcf11c biosint: ebp 0xc000 esp 0xd edi 0x1a esi 0x0 biosint: ip 0x1022 cs 0xf flags 0x2067 BIOSINT: Unsupport int #0x18 Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
> Is int1a pci bios calls supported in the emulators? It seems to work in v2. I've never looked at them before today. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
> -Original Message- > From: Marc Jones [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 15, 2008 2:45 PM > To: Myles Watson > Cc: Tom Sylla; ron minnich; Coreboot > Subject: Re: [coreboot] SimNOW VGA int 1a > > Myles Watson wrote: > > Here's the next part of the log now that I've enabled setup_realmode_idt > > (I'm running it right before real_mode_switch_call_vga. > > > > Copying VGA ROM image from 0xfe04 to 0xc, 0x8000 bytes > > BREAK HERE run_bios = 0x944a > > biosint: INT# 0x18 > > biosint: eax 0x2e ebx 0x1 ecx 0xfe4 edx 0xcf11c > > biosint: ebp 0xc000 esp 0xd edi 0x1a esi 0x0 > > biosint: ip 0x1022 cs 0xf flags 0x2067 > > BIOSINT: Unsupport int #0x18 > > > > That isn't the same emulator that most of v2 uses. setup_realmode_idt is > certainly required. 0x18 is a strange INT to see. > http://www.ctyme.com/intr/int.htm > > Can you get back to the calling code and see what it was doing? The VGA BIOS calls 1a, but it looks like too many things get pushed onto the stack, and it thinks it's 18 instead. I'm not an assembly programmer, but it looks like the problem is in callbiosint or handler. It looks like the registers are being pushed onto the stack too many times? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
> let's look around: > > gdb build/util/x86emu/vm86.o > > Dump of assembler code for function biosint: > 0x04f3 : push %esi > 0x04f4 : mov%eax,%esi > 0x04f6 : push %ebx > 0x04f7 : sub$0x4,%esp > 0x04fa : movzwl 0x34(%esp),%eax > 0x04ff : mov0x30(%esp),%ebx > 0x0503 : mov%eax,(%esp) > 0x0506 : push %esi > 0x0507 : push $0x86 > 0x050c : push $0x7 > 0x050e : call 0x50f > > We are passing arg 1 in eax. How could this be? > > Simple. We got Clever in v3: > > -mregparm=3 > > A nice optimization that utterly destroys the bios interrupt support. > > Myles, try setting -mregparm=0 and see if life is better. I'll try it when I get back to that machine. My laptop isn't AMD64, so I can't run SimNOW on it. Thanks for finding that. > I vote we get rid of this type of Cleverness. It's just not > performance critical in a bios. We're not an OS and we should keep it > simple. I don't think we'll live or die on 3 on-stack variables. I'll be interested to see how much faster v3 is when it's not set to SPEW. Right now it seems a lot slower than v2dsr on SimNOW. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
On Wed, Oct 15, 2008 at 5:00 PM, ron minnich <[EMAIL PROTECTED]> wrote: > On Wed, Oct 15, 2008 at 1:27 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > > Here's the next part of the log now that I've enabled setup_realmode_idt > > (I'm running it right before real_mode_switch_call_vga. > > > > Copying VGA ROM image from 0xfe04 to 0xc, 0x8000 bytes > > BREAK HERE run_bios = 0x944a > > biosint: INT# 0x18 > > biosint: eax 0x2e ebx 0x1 ecx 0xfe4 edx 0xcf11c > > biosint: ebp 0xc000 esp 0xd edi 0x1a esi 0x0 > > biosint: ip 0x1022 cs 0xf flags 0x2067 > > BIOSINT: Unsupport int #0x18 > > > > when you're looking for a misaligned stack frame the registers are > always interesting. > > Note that edi looks like a 1a. > > This code is unchanged for the most part since I wrote it. What you > can do is look via gdb at the biosint function and see where it gets > the int #. It is unlikely that this is a gcc problem. A misguided > directive, on the other hand ... > > let's look around: > > gdb build/util/x86emu/vm86.o > > Dump of assembler code for function biosint: > 0x04f3 : push %esi > 0x04f4 : mov%eax,%esi > 0x04f6 : push %ebx > 0x04f7 : sub$0x4,%esp > 0x04fa : movzwl 0x34(%esp),%eax > 0x04ff :mov0x30(%esp),%ebx > 0x0503 :mov%eax,(%esp) > 0x0506 :push %esi > 0x0507 :push $0x86 > 0x050c :push $0x7 > 0x050e :call 0x50f > > We are passing arg 1 in eax. How could this be? > > Simple. We got Clever in v3: > > -mregparm=3 > > A nice optimization that utterly destroys the bios interrupt support. > > Myles, try setting -mregparm=0 and see if life is better. I get a Execution halted due to Stopping SimNow due to unhandled case(s) EAX=0001 EBX=000163A8 ECX=80012010 EDX=0FDC ESI=B10D EDI=0001 ESP=0F34 EBP=0020 CS=0010 DS=0018 ES=0018 FS=0018 GS=0018 SS=0018 EFLAGS=oditSzapc GIF=1 ASID= HCR3= VMHSAVEPA= GuestVMCBPA= 0010:F07D add [eax],al 0010:F07F 007000 add [eax+00],dh 0010:F082 add [eax],al 0010:F084 0018 add [eax],bl 0010:F086 01B448 add [eax+ecx*2+],esi 0010:F08D add [eax],al 0010:F08F 007000 add [eax+00],dh 0010:F092 add [eax],al 0010:F094 0018 add [eax],bl 0010:F096 01BC48 add [eax+ecx*2+],edi 0010:F09D FF The last output on the serial port is: biosint: INT# 0x1a biosint: eax 0xb102 ebx 0xc002e ecx 0xc2067 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd esi 0x1 biosint: ip 0x3246 cs 0xc000 flags 0x46 dev_find_device: find PCI: 1022:2067 Check Root Device Check CPU: 00 Check APIC: 00 Check PCI: 00:01.0 Check PCI: 1022:7462 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7458 Check PCI: 1022:7468 Check PCI: 1022:7469 Check PCI: 1022:746a Check PCI: 1022:746e Check PCI: 1022:746e Check PCI: 1022:746e Check PCI: 1022:1100 Check PCI: 1022:1100 Check PCI: 00:02.0 Check PCI: 1022:1100 Check PCI: 1022:1101 Check PCI: 1022:1102 Check PCI: 1022:1103 Check IOPORT: 2e Check APIC_CLUSTER: 1022:1100 Check PNP: Check PNP: Check PNP: Check PNP: Check PNP: Check PNP: Check PNP: Check PNP: Check PNP: Check PNP: Check PNP: Check PCI: 1022:7460 Check PCI: 1022:7468 Check PCI: 1022:7469 Check PCI: 1022:746a Check PCI: 1022:746b Check PCI: 1022:746d Check PCI: 1022:746e Check PCI: 1022:746f Check PCI: 1022:7459 Check PCI: 1022:7458 Check PCI: 1022:7459 Check PCI: 1022:7464 Check PCI: 1022:7464 Check PCI: 1022:7463 Check PCI: 1022:7462 Check PCI: 1022:2067 found 0xb102: return 0x120 biosint: INT# 0x1a biosint: eax 0xb108 ebx 0x120 ecx 0xc2067 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd000a esi 0x1 biosint: ip 0x325a cs 0xc000 flags 0x46 0xb108: bus 1 devfn 0x20 reg 0xa val 0x0 biosint: INT# 0x1a biosint: eax 0xb109 ebx 0x120 ecx 0x0 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0008 esi 0x1 biosint: ip 0x3269 cs 0xc000 flags 0x46 0xb109: bus 1 devfn 0x20 reg 0x8 val 0x3 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0x3 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0018 esi 0x1 biosint: ip 0x3283 cs 0xc000 flags 0x46 0xb10a: bus 1 devfn 0x20 reg 0x18 val 0x1001 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0x1000 edx 0xf1022 biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0014 esi 0x100b1 biosint: ip 0x3294 cs 0xc000 flags 0x46 0xb10a: bus 1 devfn 0x20 reg 0x14 val 0xfe055000 biosint: INT# 0x1a biosint: eax 0xb10a ebx 0x120 ecx 0xfe055000 edx 0xf1022 biosint: ebp 0xcf0d
Re: [coreboot] SimNOW VGA int 1a
On Wed, Oct 15, 2008 at 5:44 PM, Carl-Daniel Hailfinger < [EMAIL PROTECTED]> wrote: > On 16.10.2008 01:13, Peter Stuge wrote: > > ron minnich wrote: > > > >> Myles, try setting -mregparm=0 and see if life is better. > >> > > > > Good find. > > > > __attribute__((stdcall)) will do this for you. It doesn't work for me. I tried it in various places, but it doesn't change the way the parameters are handled. void __attribute__ ((stdcall)) callbiosint(void) __attribute__ ((stdcall)) void callbiosint(void) void callbiosint(void) __attribute__ ((stdcall)) biosint: INT# 0x18 biosint: eax 0x2e ebx 0x1 ecx 0xfe4 edx 0xcf11c biosint: ebp 0xc000 esp 0xd edi 0x1a esi 0x0 biosint: ip 0x1022 cs 0xf flags 0x2067 BIOSINT: Unsupport int #0x18 Thanks, Myles > > Changing compilation mode makes code to -mregparm=0 makes the code > bigger and slower and it will also possibly consume more stack which we > don't have in MP setups. > > > >> I vote we get rid of this type of Cleverness. It's just not > >> performance critical in a bios. We're not an OS and we should keep > >> it simple. I don't think we'll live or die on 3 on-stack variables. > >> > > > > If it isn't more relevant because of CAR then away it goes. > > > > See above. > > Regards, > Carl-Daniel > > -- > http://www.hailfinger.org/ > > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] __attribute__((stdcall)) vs. __attribute__((regparm(0)))
> > > > Segher: How do regparm(0) and stdcall differ for i386? > > "stdcall" means the callee pops the args from the stack when it returns; > "cdecl" (the default) means the caller has to pop them. "stdcall" gives > smaller code, but cannot work for functions without prototype (you > shouldn't have such anyway, with ISO C -- but in olden days it was the > norm). If you would like stdcall by default, use -mrtd. > > "regparm" says how many integer arguments are passed in registers > instead > of on the stack. 0 is the default, and 3 is the maximum. The registers > used are A, D, C. Use -mregparm=N to get some other default. > > So, "stdcall" and "regparm" are orthogonal. stdcall would be good for > coreboot (smaller code size), but regparm > 0 probably increases code > size (try it though). Whatever you use, "special" code (context > switching, > etc. -- but also all assembler routines in general) need to be aware of > the calling sequence in use, of course -- but they can always override > it to something of their liking. > > What is the actual problem you are trying to solve here? We are compiling with -mregparm=3 and that breaks the assembly files that support interrupts in vm86.c because they expect the other calling convention. The question is what attribute can be used to make those functions have the normal calling convention when compiling with -mregparm=3. We're using -mregparm=3 for speed reasons. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
> >> > Check PCI: 1022:2067 > >> > found > >> > 0xb102: return 0x120 > > the wrong # here? Yes. It should be device # 4 as far as I can tell. In the debugger when I do a config read to bus 1 dev 4 function 0 I get the right data back. When I do a read to bus 1 dev 2 function 0 I get an error that no device responded. Like I said, I don't know why the reads succeed. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
2008/10/16 ron minnich <[EMAIL PROTECTED]> > On Thu, Oct 16, 2008 at 5:39 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > tter. > > > > I get a > > Execution halted due to Stopping SimNow due to unhandled case(s) > > > > EAX=0001 EBX=000163A8 ECX=80012010 EDX=0FDC > > ESI=B10D EDI=0001 ESP=0F34 EBP=0020 > > CS=0010 DS=0018 ES=0018 FS=0018 GS=0018 SS=0018 EFLAGS=oditSzapc > > GIF=1 ASID= HCR3= > > VMHSAVEPA= GuestVMCBPA= > > > > 0010:F07D add [eax],al > > 0010:F07F 007000 add [eax+00],dh > > 0010:F082 add [eax],al > > 0010:F084 0018 add [eax],bl > > 0010:F086 01B448 add [eax+ecx*2+],esi > > 0010:F08D add [eax],al > > 0010:F08F 007000 add [eax+00],dh > > 0010:F092 add [eax],al > > 0010:F094 0018 add [eax],bl > > 0010:F096 01BC48 add [eax+ecx*2+],edi > > 0010:F09D FF > > see where this is is build/coreboot.map. It looks like garbage to me. > > > > > The last output on the serial port is: > > biosint: INT# 0x1a > > biosint: eax 0xb102 ebx 0xc002e ecx 0xc2067 edx 0xf1022 > > biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd esi 0x1 > > biosint: ip 0x3246 cs 0xc000 flags 0x46 > > dev_find_device: find PCI: 1022:2067 > > Check Root Device > > Check CPU: 00 > > Check APIC: 00 > > Check PCI: 00:01.0 > > Check PCI: 1022:7462 > > Check PCI: 1022:7464 > > Check PCI: 1022:7464 > > Check PCI: 1022:7464 > > Check PCI: 1022:7458 > > Check PCI: 1022:7468 > > Check PCI: 1022:7469 > > Check PCI: 1022:746a > > Check PCI: 1022:746e > > Check PCI: 1022:746e > > Check PCI: 1022:746e > > Check PCI: 1022:1100 > > Check PCI: 1022:1100 > > Check PCI: 00:02.0 > > Check PCI: 1022:1100 > > Check PCI: 1022:1101 > > Check PCI: 1022:1102 > > Check PCI: 1022:1103 > > Check IOPORT: 2e > > Check APIC_CLUSTER: 1022:1100 > > Check PNP: > > Check PNP: > > Check PNP: > > Check PNP: > > Check PNP: > > Check PNP: > > Check PNP: > > Check PNP: > > Check PNP: > > Check PNP: > > Check PNP: > > Check PCI: 1022:7460 > > Check PCI: 1022:7468 > > Check PCI: 1022:7469 > > Check PCI: 1022:746a > > Check PCI: 1022:746b > > Check PCI: 1022:746d > > Check PCI: 1022:746e > > Check PCI: 1022:746f > > Check PCI: 1022:7459 > > Check PCI: 1022:7458 > > Check PCI: 1022:7459 > > Check PCI: 1022:7464 > > Check PCI: 1022:7464 > > Check PCI: 1022:7463 > > Check PCI: 1022:7462 > > Check PCI: 1022:2067 > > found > > 0xb102: return 0x120 > > so that worked. > > > biosint: INT# 0x1a > > biosint: eax 0xb108 ebx 0x120 ecx 0xc2067 edx 0xf1022 > > biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd000a esi 0x1 > > biosint: ip 0x325a cs 0xc000 flags 0x46 > > 0xb108: bus 1 devfn 0x20 reg 0xa val 0x0 > > biosint: INT# 0x1a > > biosint: eax 0xb109 ebx 0x120 ecx 0x0 edx 0xf1022 > > biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0008 esi 0x1 > > biosint: ip 0x3269 cs 0xc000 flags 0x46 > > 0xb109: bus 1 devfn 0x20 reg 0x8 val 0x3 > > biosint: INT# 0x1a > > biosint: eax 0xb10a ebx 0x120 ecx 0x3 edx 0xf1022 > > biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0018 esi 0x1 > > biosint: ip 0x3283 cs 0xc000 flags 0x46 > > 0xb10a: bus 1 devfn 0x20 reg 0x18 val 0x1001 > > biosint: INT# 0x1a > > biosint: eax 0xb10a ebx 0x120 ecx 0x1000 edx 0xf1022 > > biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0014 esi 0x100b1 > > biosint: ip 0x3294 cs 0xc000 flags 0x46 > > 0xb10a: bus 1 devfn 0x20 reg 0x14 val 0xfe055000 > > biosint: INT# 0x1a > > biosint: eax 0xb10a ebx 0x120 ecx 0xfe055000 edx 0xf1022 > > biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0010 esi 0x100ad > > biosint: ip 0x32a2 cs 0xc000 flags 0x46 > > 0xb10a: bus 1 devfn 0x20 reg 0x10 val 0xfd00 > > biosint: INT# 0x1a > > biosint: eax 0xb10d ebx 0x120 ecx 0x edx 0xf1022 > > biosint: ebp 0xcf0d8 esp 0xfe4 edi 0xd0010 esi 0x100a9 > > biosint: ip 0x32b3 cs 0xc000 flags 0x46 > > going through looking for several things I guess? The esp looks ok. > > I suggest you set a break at c32b3 and see what you see. It looks like the problem is that coreboot is giving the VGA BIOS the wrong device number. I don't know why the reads succeed, but the device number should be 4 for the VGA controller, not 2. When it writes to the non-existant device, it triple faults. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] __attribute__((stdcall)) vs. __attribute__((regparm(0)))
> -Original Message- > From: ron minnich [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 16, 2008 9:41 AM > To: Myles Watson > Cc: Segher Boessenkool; Carl-Daniel Hailfinger; Coreboot > Subject: Re: [coreboot] __attribute__((stdcall)) vs. > __attribute__((regparm(0))) > > On Thu, Oct 16, 2008 at 7:58 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > > > > > The question is what attribute can be used to make those functions have > the > > normal calling convention when compiling with -mregparm=3. We're using > > -mregparm=3 for speed reasons. > > > > The simplest thing: put all the functions that need regparm=0 in one > file, compile that file with regparm=0 There's a warning in the man pages for gcc that says that you have to compile all the functions (including libraries) with the same setting. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
On Thu, Oct 16, 2008 at 9:49 AM, ron minnich <[EMAIL PROTECTED]> wrote: > On Thu, Oct 16, 2008 at 8:48 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > >> >> > Check PCI: 1022:2067 > >> >> > found > >> >> > 0xb102: return 0x120 > >> > >> the wrong # here? > > > > Yes. It should be device # 4 as far as I can tell. In the debugger when > I > > do a config read to bus 1 dev 4 function 0 I get the right data back. > When > > I do a read to bus 1 dev 2 function 0 I get an error that no device > > responded. > > > > Like I said, I don't know why the reads succeed. > > > > so you need some debug prints in the PCIBIOS support code. > Check PCI: 1022:2067 PCI: 01:04.0 found bus->secondary = 0x1 dev->path.pci.devfn = 0x20 0xb102: return 0x120 Now I'm confused. I guess 0x120 was correct (the slot is the upper 5 bits of the byte), so I'm still looking. Now it makes sense why the reads succeed, but the config write failure is puzzling. It's trying to write 0x to the BAR, but that changes the memory map, so after that write there's garbage everywhere. I still haven't found the config register that gets changed, but it's not in the VGA card's space. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
> -Original Message- > From: Marc Jones [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 16, 2008 10:32 AM > To: Myles Watson > Cc: ron minnich; Tom Sylla; Coreboot > Subject: Re: [coreboot] SimNOW VGA int 1a > > Myles Watson wrote: > > > > > > On Thu, Oct 16, 2008 at 9:49 AM, ron minnich <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > On Thu, Oct 16, 2008 at 8:48 AM, Myles Watson <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > >> >> > Check PCI: 1022:2067 > > >> >> > found > > >> >> > 0xb102: return 0x120 > > >> > > >> the wrong # here? > > > > > > Yes. It should be device # 4 as far as I can tell. In the > > debugger when I > > > do a config read to bus 1 dev 4 function 0 I get the right data > > back. When > > > I do a read to bus 1 dev 2 function 0 I get an error that no > device > > > responded. > > > > > > Like I said, I don't know why the reads succeed. > > > > > > > so you need some debug prints in the PCIBIOS support code. > > > > > > Check PCI: 1022:2067 > > PCI: 01:04.0 found > > bus->secondary = 0x1 dev->path.pci.devfn = 0x20 > > 0xb102: return 0x120 > > > > Now I'm confused. I guess 0x120 was correct (the slot is the upper 5 > > bits of the byte), so I'm still looking. Now it makes sense why the > > reads succeed, but the config write failure is puzzling. It's trying > > to write 0x to the BAR, but that changes the memory map, so > > after that write there's garbage everywhere. I still haven't found > > the config register that gets changed, but it's not in the VGA card's > > space. > > > Which BAR? What is the contents of 0xcf8? Not sure why, but writing > 0x to a BAR is to get the size. It shoudl disable the device > before it does that but sometimes they are sloppy and don't. cf8 = 0x80012010 Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] __attribute__((stdcall)) vs. __attribute__((regparm(0)))
> -Original Message- > From: Segher Boessenkool [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 16, 2008 10:30 AM > To: ron minnich > Cc: Myles Watson; Carl-Daniel Hailfinger; Coreboot > Subject: Re: [coreboot] __attribute__((stdcall)) vs. > __attribute__((regparm(0))) > > >> There's a warning in the man pages for gcc that says that you have to > >> compile all the functions (including libraries) with the same > >> setting. > > It says that in the description of -mregparm, not of the function > attribute "regparm", and it is slightly misleading: -mregparm > specifies the default for any function without an explicit attribute, > so you better use the same -mregparm option for any file that contains > functions (or calls functions) without explicit attribute; but you _can_ > have multiple regparm settings in total. > > > biosint is only called from assembly, so it really doesn't matter. The > > issue is that the assembly that calls biosint is written > > with as "regparm=0", from long ago, and the rules got changed when we > > set regparm=3. > > > > Again, only functions called from assembly for vm86 mode need to be > > compiled with regparm=0. > > Whatever calling sequence you choose, please put the required attribute > for any function that needs something specific in the declaration for > that function (in a header file). This includes any function > implemented > in assembler (except those without arguments at all). > > This will save you a lot of headaches ;-) I appreciate the clarification. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IB520 Embedded MoBo
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Davide Visconti > Sent: Thursday, October 16, 2008 11:27 AM > To: Coreboot > Subject: Re: [coreboot] IB520 Embedded MoBo > > >> Hi, > >> I have try to build rom file but I have incountered several > difficulties. > >> There insn't a simple howto step by step? > >> I follow the AMD_Geode_Porting_Guide but after download the buildrom > >> and coreboot.. for example where I must do the command make menuconfig > >> and make? > > > > from buildrom/buildrom-devel/ > > > > if you want to configure coreboot v3 > > make coreboot-v3-config > > > > if you want to choose the payload (in your case the linux kernel) > > make menuconfig > > > > Thanks, > > Myles > > I have econtered an error during the compilation. > I have make these step: > - svn co svn://coreboot.org/buildrom > - svn co svn://coreboot.org/repos/trunk/coreboot-v2 > - cd buildrom/buildrom-devel/ > - make menuconfig > - make > > When I run "make" I get the attached error. > How I make to understand where is the problem? > > ...and after the succesfull rom compilation? > > Thank you in advance, Davide The build log is buildrom/buildrom-devel/work/coreboot-v2/logs/build.log That's where the real error is. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] IB520 Embedded MoBo
On Thu, Oct 16, 2008 at 11:33 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] > > On Behalf Of Davide Visconti > > Sent: Thursday, October 16, 2008 11:27 AM > > To: Coreboot > > Subject: Re: [coreboot] IB520 Embedded MoBo > > > > >> Hi, > > >> I have try to build rom file but I have incountered several > > difficulties. > > >> There insn't a simple howto step by step? > > >> I follow the AMD_Geode_Porting_Guide but after download the buildrom > > >> and coreboot.. for example where I must do the command make menuconfig > > >> and make? > > > > > > from buildrom/buildrom-devel/ > > > > > > if you want to configure coreboot v3 > > > make coreboot-v3-config > > > > > > if you want to choose the payload (in your case the linux kernel) > > > make menuconfig > > > > > > Thanks, > > > Myles > > > > I have econtered an error during the compilation. > > I have make these step: > > - svn co svn://coreboot.org/buildrom > > - svn co svn://coreboot.org/repos/trunk/coreboot-v2 > > - cd buildrom/buildrom-devel/ > > - make menuconfig > > - make > > > > When I run "make" I get the attached error. > > How I make to understand where is the problem? > > > > ...and after the succesfull rom compilation? > > > > Thank you in advance, Davide > > The build log is buildrom/buildrom-devel/work/coreboot-v2/logs/build.log > I meant coreboot/logs/build.log I'd bet that the problem is the size of the payload. How big of a chip do you have? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
On Thu, Oct 16, 2008 at 1:25 PM, ron minnich <[EMAIL PROTECTED]> wrote: > On Thu, Oct 16, 2008 at 12:19 PM, Marc Jones <[EMAIL PROTECTED]> wrote: > > > AH! I see. We shouldn't be running out of the ROM. That will be slow. We > > should copy the VGA BIOS to real memory and run it there. > > > > Why are you doing ROM init in stage0? I thought this was well into > stage2. > > > > So, safety tip: we can't call ANY ROM in stage2 when we're running > doing ROM init. > > And I just realized the problem: we're calling printk and printk is in ROM. > > no printks allowed in pcibios.c unless we move printk to RAM, i.e. > compile printk into stage2. > > What a revolting development this is! Our beautiful "common code in > ROM" idea is going down in flames. > Can we make it cached? Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
On Thu, Oct 16, 2008 at 1:32 PM, ron minnich <[EMAIL PROTECTED]> wrote: > On Thu, Oct 16, 2008 at 12:30 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > > > > > Wait a second. The reason this is broken is that the code setting the > PCI > > decode register is in the ROM. Can we fix this by calling > > pci_conf1_write_config32 instead? It looks like it's in RAM. > > > > sure, but ANY call to ROM will fail. There is a huge hole: > vga bios calls pcibios to set BAR 10 to > > There is a huge window here: any call to ROM code will fail, so that > includes printk (we do this on each pcibios call), and just about > anything else. > > So we have a problem with a fundamental design decision All right. I guess I go back to being a lurker for a while until it gets worked out :) I guess the beauty of this is that it will enforce clean separation between the stages. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
> -Original Message- > From: ron minnich [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 16, 2008 1:34 PM > To: Marc Jones > Cc: Myles Watson; Jordan Crouse > Subject: Re: [coreboot] SimNOW VGA int 1a > > On Thu, Oct 16, 2008 at 12:32 PM, Marc Jones <[EMAIL PROTECTED]> wrote: > > > That gets us back to relocating or mutilple copies in the stages. I am > ok > > with multiple copies in the ROM but it should be on version in the > source. > > The problem with v2 is that there was ROMCC versions and main coreboot > > versions. > > The beauty of carl-daniel's redesign of the "call ROM" stuff is that > we can have the same printk code in stage2 as in ROM and there is no > symbol conflict. But we now have to pretty much put all stage0 stuff > in stage2 as well. no choice. > > Myles, caching won't help. I'm showing my ignorance here. Conceptually couldn't you have a small area set up like CAR for the shared portions? As long as it was all loaded before probing wouldn't it always be accessed before the ROM? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW VGA int 1a
On Thu, Oct 16, 2008 at 1:27 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 16, 2008 at 1:25 PM, ron minnich <[EMAIL PROTECTED]> wrote: > >> On Thu, Oct 16, 2008 at 12:19 PM, Marc Jones <[EMAIL PROTECTED]> wrote: >> >> > AH! I see. We shouldn't be running out of the ROM. That will be slow. We >> > should copy the VGA BIOS to real memory and run it there. >> > >> > Why are you doing ROM init in stage0? I thought this was well into >> stage2. >> > >> >> So, safety tip: we can't call ANY ROM in stage2 when we're running >> doing ROM init. >> >> And I just realized the problem: we're calling printk and printk is in >> ROM. >> >> no printks allowed in pcibios.c unless we move printk to RAM, i.e. >> compile printk into stage2. >> >> What a revolting development this is! Our beautiful "common code in >> ROM" idea is going down in flames. >> > Wait a second. The reason this is broken is that the code setting the PCI decode register is in the ROM. Can we fix this by calling pci_conf1_write_config32 instead? It looks like it's in RAM. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Fwd: SimNOW VGA int 1a
On Thu, Oct 16, 2008 at 1:56 PM, ron minnich <[EMAIL PROTECTED]> wrote: > I did not realize we had gone private. see below. > > Basically, vga bios tries to size a 16 meg register and at an > intermediate point the vga hardware ends up decoding the top 16 mb of > memory. > > I welcome a fix. It's just not obvious to me. But we could just say that VGA ROM init is a black hole, only call functions defined there and hope it works. :) Myles > > ron > > > -- Forwarded message -- > From: ron minnich <[EMAIL PROTECTED]> > Date: Thu, Oct 16, 2008 at 12:15 PM > Subject: Re: [coreboot] SimNOW VGA int 1a > To: Marc Jones <[EMAIL PROTECTED]> > Cc: Myles Watson <[EMAIL PROTECTED]>, Jordan Crouse <[EMAIL PROTECTED] > > > > > On Thu, Oct 16, 2008 at 12:08 PM, Marc Jones <[EMAIL PROTECTED]> wrote: > > ron minnich wrote: > >> > > >> well, hang on. > >> > >> I write to BAR 10. > >> Then what is left in BAR 10 is ff00. That decodes to the top 16 MB > >> of address space. At that point, all the memory goes bye bye. > >> So do we really want the device enabled? > >> > >> Is this maybe a bug in the vga bios? This won't be an issue for code > >> not running in the top 16 MB > >> > > > > Yes it goes away but nothing should access it then. Put the BAR back and > it > > should be fine. > > but the EIP is accessing it then. We're running code at . > > Here is the sequence: > > we're running at . We write at request of vgabios to > the BAR 10. At that point vga is decoding ffxx. > > We can no longer fetch code from . We go bye bye. > > Fix is to NOT compile the pcibios into stage0, or to also decode it into > stage2. > > ron > > -- > coreboot mailing list: coreboot@coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] temporary fix
This allows me to keep going while the details of where code lives gets
worked out. I removed printk references and copied the definitions of the
PCI functions.
No need to commit ever.
Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
Thanks,
Myles
Index: util/x86emu/vm86.c
===
--- util/x86emu/vm86.c (revision 929)
+++ util/x86emu/vm86.c (working copy)
@@ -29,6 +29,7 @@
#include
#include
+#define CONFIG_CMD(bdf, where) (0x8000 | (bdf) | ((where & 0xff) & ~3) | ((where & 0xf00)<<16) )
/* The address arguments to this function are PHYSICAL ADDRESSES */
static void real_mode_switch_call_vga(unsigned long devfn)
@@ -240,19 +241,7 @@
);
}
-void run_bios(struct device *dev, unsigned long addr)
-{
- int i;
-
- /* clear vga bios data area */
- for (i = 0x400; i < 0x500; i++) {
- *(unsigned char *) i = 0;
- }
- real_mode_switch_call_vga((dev->bus->secondary << 8) | dev->path.pci.devfn);
-}
-
-
// we had hoped to avoid this.
// this is a stub IDT only. It's main purpose is to ignore calls
// to the BIOS.
@@ -432,28 +421,16 @@
cs = cs_ip >> 16;
flags = stackflags;
- printk(BIOS_DEBUG, "biosint: INT# 0x%lx\n", intnumber);
- printk(BIOS_DEBUG, "biosint: eax 0x%lx ebx 0x%lx ecx 0x%lx edx 0x%lx\n",
- eax, ebx, ecx, edx);
- printk(BIOS_DEBUG, "biosint: ebp 0x%lx esp 0x%lx edi 0x%lx esi 0x%lx\n",
- ebp, esp, edi, esi);
- printk(BIOS_DEBUG, "biosint: ip 0x%lx cs 0x%lx flags 0x%lx\n",
- ip, cs, flags);
// cases in a good compiler are just as good as your own tables.
switch (intnumber) {
case 0 ... 15:
// These are not BIOS service, but the CPU-generated exceptions
- printk(BIOS_INFO, "biosint: Oops, exception %lu\n", intnumber);
if (esp < 0x1000) {
- printk(BIOS_DEBUG, "Stack contents: ");
while (esp < 0x1000) {
-printk(BIOS_DEBUG, "0x%04x ", *(unsigned short *) esp);
esp += 2;
}
- printk(BIOS_DEBUG, "\n");
}
- printk(BIOS_DEBUG, "biosint: Bailing out\n");
// "longjmp"
vga_exit();
break;
@@ -472,8 +449,6 @@
&ebx, &edx, &ecx, &eax, &flags);
break;
default:
- printk(BIOS_INFO, "BIOSINT: Unsupport int #0x%lx\n",
- intnumber);
break;
}
if (ret)
@@ -548,7 +523,20 @@
}
+void run_bios(struct device *dev, unsigned long addr)
+{
+ int i;
+
+ /* clear vga bios data area */
+ for (i = 0x400; i < 0x500; i++) {
+ *(unsigned char *) i = 0;
+ }
+ setup_realmode_idt();
+ real_mode_switch_call_vga((dev->bus->secondary << 8) | dev->path.pci.devfn);
+}
+
+
enum {
CHECK = 0xb001,
FINDDEV = 0xb102,
@@ -604,7 +592,6 @@
// devfn is an int, so we mask it off.
busdevfn = (dev->bus->secondary << 8)
| (dev->path.pci.devfn & 0xff);
- printk(BIOS_DEBUG, "0x%x: return 0x%x\n", func, busdevfn);
*pebx = busdevfn;
retval = 0;
} else {
@@ -624,54 +611,74 @@
unsigned short word;
unsigned char byte;
unsigned char reg;
+ struct bus *pbus;
devfn = *pebx & 0xff;
bus = *pebx >> 8;
reg = *pedi;
dev = dev_find_slot(bus, devfn);
if (! dev) {
- printk(BIOS_DEBUG, "0x%x: BAD DEVICE bus %d devfn 0x%x\n", func, bus, devfn);
// idiots. the pcibios guys assumed you'd never pass a bad bus/devfn!
*peax = PCIBIOS_BADREG;
retval = -1;
}
+ pbus = dev->bus;
+ while (pbus && pbus->dev && !ops_pci_bus(pbus)) {
+ pbus = pbus->dev->bus;
+ }
switch(func) {
case READCONFBYTE:
- byte = pci_read_config8(dev, reg);
+ outl(CONFIG_CMD(PCI_BDEVFN(dev->bus->secondary,
+ dev->path.pci.devfn),
+ reg),
+0xCF8);
+ byte = inb(0xCFC + (reg & 3));
*pecx = byte;
break;
case READCONFWORD:
- word = pci_read_config16(dev, reg);
+ outl(CONFIG_CMD(PCI_BDEVFN(dev->bus->secondary,
+ dev->path.pci.devfn), reg),
+0xCF8);
+ word = inw(0xCFC + (reg & 2));
*pecx = word;
break;
case READCONFDWORD:
- dword = pci_read_config32(dev, reg);
+ outl(CONFIG_CMD(PCI_BDEVFN(dev->bus->secondary,
+ dev->path.pci.devfn), reg),
+0xCF8);
+ dword = inl(0xCFC);
*pecx = dword;
break;
case WRITECONFBYTE:
byte = *pecx;
- pci_write_config8(dev, reg, byte);
+ outl(CONFIG_CMD(PCI_BDEVFN(dev->bus->secondary,
+ dev->path.pci.devfn), reg),
+0xCF8);
+ outb(byte, 0xCFC + (reg & 3));
break;
case WRITECONFWORD:
word = *pecx;
- pci_write_config16(dev, reg, word);
+ outl(CONFIG_CMD(PCI_BDEVFN(dev->bus->secondary,
+ dev->path.pci.devfn), reg),
+0xCF8);
+ outw(word, 0xCFC + (reg & 2));
break;
case WRITECONFDWORD:
dword = *pecx;
- pci_write_config
[coreboot] Funny boot log in Coreinfo
I haven't looked into the cause yet, but the boot log looks a little "funny" in coreinfo. At least it's smiling. Thanks, Myles <>-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Funny boot log in Coreinfo
On Fri, Oct 17, 2008 at 11:35 AM, ron minnich <[EMAIL PROTECTED]> wrote: > it's still news. You just booted our first K8 platform. > > WOW! nice job! Sorry to get your hopes up. The screenshot is from qemu. SimNOW boots but I get no output on VGA still. When the VGA BIOS initializes I was hoping for some output, but still nothing. I built coreinfo for qemu to compare logs and noticed the funny output. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Resource Allocation problems
This is the resource tree for SimNOW: Root Device resource base 1000 size 2000 align c gran 0 limit flags 4100 Root Device resource base fd00 size 120 align 18 gran 0 limit febf flags 4200 PCI_DOMAIN: resource base 400 size 0 align 0 gran 0 limit flags 40040100 PCI_DOMAIN: resource base 0 size 0 align 0 gran 0 limit fc flags 40040200 PCI_DOMAIN: resource base 0 size a align 0 gran 0 limit 0 flags e0004200 PCI_DOMAIN: resource base c size ff4 align 0 gran 0 limit 0 flags e0004200 PCI: 00:18.0 resource base fe20 size 0 align 14 gran 14 limit ff flags 60001200 PCI: 00:18.0 resource base 1000 size 2000 align c gran c limit flags 6100 PCI: 00:18.0 resource base fd00 size 120 align 18 gran 14 limit febf flags 6200 PCI: 00:18.0 resource base 3000 size 0 align c gran c limit flags 6100 PCI: 00:18.0 resource base fe20 size 0 align 14 gran 14 limit ff flags 60001200 PCI: 00:18.0 resource base fe20 size 0 align 14 gran 14 limit ff flags 6200 PCI: 00:18.0 resource base a size 2 align 0 gran 0 limit 0 flags 0 PCI: 00:06.0 resource base 1000 size 1000 align c gran c limit flags 6102 PCI: 00:06.0 resource base fd00 size 110 align 18 gran 14 limit febf flags 6202 PCI: 01:00.0 resource base fe05 size 1000 align c gran c limit flags 6200 PCI: 01:00.1 resource base fe051000 size 1000 align c gran c limit flags 6200 PCI: 01:00.2 resource base fe054000 size 100 align 8 gran 8 limit flags 6200 PCI: 01:01.0 resource base fe052000 size 1000 align c gran c limit flags 6200 PCI: 01:04.0 resource base fd00 size 100 align 18 gran 18 limit flags 6200 PCI: 01:04.0 resource base fe055000 size 100 align 8 gran 8 limit flags 6200 PCI: 01:04.0 resource base 1000 size 100 align 8 gran 8 limit flags 6100 PCI: 01:04.0 resource base fe04 size 1 align 10 gran 10 limit flags 60002200 PCI: 01:05.0 resource base fe00 size 2 align 11 gran 11 limit flags 6200 PCI: 01:05.0 resource base fe02 size 2 align 11 gran 11 limit flags 6200 PCI: 01:05.0 resource base 1400 size 40 align 6 gran 6 limit flags 6100 PCI: 01:05.0 resource base fe053000 size 800 align b gran b limit flags 60002200 PCI: 00:07.0 resource base 0 size 0 align 0 gran 0 limit 0 flags 40040100 PCI: 00:07.0 resource base 0 size 0 align 0 gran 0 limit 0 flags 40040200 PCI: 00:07.1 resource base 2c60 size 10 align 4 gran 4 limit flags 6100 PCI: 00:07.2 resource base 2c40 size 20 align 5 gran 5 limit flags 6100 PCI: 00:07.5 resource base 2000 size 100 align 8 gran 8 limit flags 6100 PCI: 00:07.5 resource base 2c00 size 40 align 6 gran 6 limit flags 6100 PCI: 00:07.6 resource base 2400 size 100 align 8 gran 8 limit flags 6100 PCI: 00:07.6 resource base 2800 size 80 align 7 gran 7 limit flags 6100 PCI: 00:07.7 resource base fe10 size 1000 align c gran c limit flags 6200 PCI: 00:07.7 resource base 2880 size 80 align 7 gran 7 limit flags 6100 PCI: 00:0a.1 resource base fe101000 size 1000 align c gran c limit flags 6201 PCI: 00:0b.1 resource base fe102000 size 1000 align c gran c limit flags 6201 There are several resources of size zero. Can we get rid of them? There is a nearly duplicated resource for 0:18.0, both of which are size 0. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Resource Allocation problems
On Fri, Oct 17, 2008 at 2:01 PM, ron minnich <[EMAIL PROTECTED]> wrote: > On Fri, Oct 17, 2008 at 11:31 AM, Myles Watson <[EMAIL PROTECTED]> wrote: > > > There are several resources of size zero. Can we get rid of them? > > Is there harm done in having them there? I can't see any. This all > goes away when the payload starts. > > > There is a nearly duplicated resource for 0:18.0, both of which are size > 0. > > These are the two HT links. > > I don't see a reason to yank these things unless there is harm done. > > ron I'm trying to figure out why the VGA isn't working. There are several resources that get enabled that claim to have the VGA resource in v3, but not in v2. I thought maybe that was the problem. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Resource Allocation problems
Here's the problem I was trying to get to the bottom of: There are two overlapping ranges when the payload starts: 0:18.1 B4 & BC B8 & BC BASELIMIT 00FD0003 00FE1F00 00FC0003 0000 In v2 there's only one at that point. There are also extra mappings in IO space, but they are zero size. It's very possible that it makes no difference. It just makes it harder to read the address map with extra entries. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Funny boot log in Coreinfo
On Fri, Oct 17, 2008 at 3:47 PM, Carl-Daniel Hailfinger < [EMAIL PROTECTED]> wrote: > On 17.10.2008 19:46, Jordan Crouse wrote: > > On 17/10/08 11:29 -0600, Myles Watson wrote: > > > >> I haven't looked into the cause yet, but the boot log looks a little > "funny" > >> in coreinfo. At least it's smiling. > >> > > > > Hmm - that is very unfortunate. I think we have boot log issues - I have > > also discovered that the bootlog is apparently overwriting the v3 > > coreboot tables. This could be a consequence of that. > > > > Is there any old version where you don't see the issues on qemu? Yes. I know when it was a new feature I tried it out and didn't see this garbage. > IIRC K8 has numerous issues in the v3 startup code which can (and > probably will) interfere with printk buffers. I'm currently auditing the > code to hunt all of these problems down. Please don't try using > CONFIG_PRINTK_BUFFER with K8. We should probably change the defconfigs then. It doesn't change any behavior for me, so I must just be lucky. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Resource Allocation problems
On Fri, Oct 17, 2008 at 4:27 PM, ron minnich <[EMAIL PROTECTED]> wrote: > On Fri, Oct 17, 2008 at 3:26 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > > > It's interesting to me that there is no corresponding resource for the > > FC0003 0000 pair. They get set in the resource map and are never > > touched again. > > Do you know when they get set? > Stage1: enable rom ... setting up resource map ex offset snip (0+0,18+0,1+0,bc) & 0048 | 0000+ ... (0+0,18+0,1+0,b8) & 00f0 | 00fc0003+ snip At the very beginning. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Resource Allocation problems
On Fri, Oct 17, 2008 at 4:43 PM, ron minnich <[EMAIL PROTECTED]> wrote: > On Fri, Oct 17, 2008 at 3:29 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > > > > (0+0,18+0,1+0,bc) & 0048 | 0000+ > > ... > > (0+0,18+0,1+0,b8) & 00f0 | 00fc0003+ > > > > it would do that because it thinks something on the platform needs it. > I don't know what. Go ahead and comment out those lines if they look > bogus > > ron I don't think it's bogus. I thought it was setting up the IO range to be decoded. It lets accesses go to the hardware in that range (all of PCI.) The problem is that since there's no corresponding resource, we never take care of it later. At what stage do we check the resource tree and make sure that all of the resources fit inside a parent's resource so that they're reachable? What about subtractive decoding? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Funny boot log in Coreinfo
> > Yes. I know when it was a new feature I tried it out and didn't see > > this garbage. > > I remember it working well some time ago. It would be great if you could > do a binary search and narrow it down. I can then fix the problem. I probably won't get to that very soon. Sorry. > > > IIRC K8 has numerous issues in the v3 startup code which can (and > > probably will) interfere with printk buffers. I'm currently > > auditing the > > code to hunt all of these problems down. Please don't try using > > CONFIG_PRINTK_BUFFER with K8. > > > > > > We should probably change the defconfigs then. It doesn't change any > > behavior for me, so I must just be lucky. > > I can make PRINTK_BUFFER depend on !K8. Which would make someone go through and change the defconfigs. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] tinycurses log file option
This patch creates a config option which allows you to see libpayload output
without escape sequences. It's useful for getting readable output from an
emulator whose serial port is redirected to a file.
Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
A related note: coreinfo's make menuconfig doesn't work for me. It can't
find its include files:
make menuconfig
CC build/util/kconfig/lxdialog/checklist.o
In file included from
/home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/lxdialog/checklist.c:24:
/home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/lxdialog/dialog.h:21:23:
error: sys/types.h: No such file or directory
/home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/lxdialog/dialog.h:22:19:
error: fcntl.h: No such file or directory
/home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/lxdialog/dialog.h:23:20:
error: unistd.h: No such file or directory
/home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/lxdialog/dialog.h:24:19:
error: ctype.h: No such file or directory
Thanks,
Myles
Index: curses/tinycurses.c
===
--- curses/tinycurses.c (revision 3646)
+++ curses/tinycurses.c (working copy)
@@ -201,9 +201,11 @@
int curs_set(int on)
{
#ifdef CONFIG_SERIAL_CONSOLE
+#ifndef CONFIG_SERIAL_LOG_FILE
if (curses_flags & F_ENABLE_SERIAL) {
serial_cursor_enable(on);
}
+#endif //SERIAL_LOG_FILE
#endif
#ifdef CONFIG_VIDEO_CONSOLE
if (curses_flags & F_ENABLE_CONSOLE) {
@@ -308,9 +310,11 @@
for (i = 0; i < 128; i++)
acs_map[i] = (chtype) i | A_ALTCHARSET;
#ifdef CONFIG_SERIAL_CONSOLE
+#ifndef CONFIG_SERIAL_LOG_FILE
if (curses_flags & F_ENABLE_SERIAL) {
serial_clear();
}
+#endif //SERIAL_LOG_FILE
#endif
#ifdef CONFIG_VIDEO_CONSOLE
if (curses_flags & F_ENABLE_CONSOLE) {
@@ -703,6 +707,7 @@
int wnoutrefresh(WINDOW *win)
{
#ifdef CONFIG_SERIAL_CONSOLE
+#ifndef CONFIG_SERIAL_LOG_FILE
// FIXME.
int serial_is_bold = 0;
int serial_is_reverse = 0;
@@ -711,13 +716,16 @@
int need_altcharset;
short fg, bg;
+#endif //SERIAL_LOG_FILE
#endif
int x, y;
chtype ch;
#ifdef CONFIG_SERIAL_CONSOLE
+#ifndef CONFIG_SERIAL_LOG_FILE
serial_end_bold();
serial_end_altcharset();
+#endif //SERIAL_LOG_FILE
#endif
for (y = 0; y <= win->_maxy; y++) {
@@ -729,8 +737,21 @@
#ifdef CONFIG_SERIAL_CONSOLE
if (curses_flags & F_ENABLE_SERIAL)
+#ifndef CONFIG_SERIAL_LOG_FILE
serial_set_cursor(win->_begy + y, win->_begx +
win->_line[y].firstchar);
+#else
+ {
+ serial_putchar('\r');
+ serial_putchar('\n');
+ serial_putchar('0'+(win->_begx + win->_line[y].firstchar)/10);
+ serial_putchar('0'+(win->_begx + win->_line[y].firstchar)%10);
+ serial_putchar(',');
+ serial_putchar('0'+(win->_begy + y)/10);
+ serial_putchar('0'+(win->_begy + y)%10);
+ serial_putchar(':');
+ }
+#endif //SERIAL_LOG_FILE
#endif
for (x = win->_line[y].firstchar; x <= win->_line[y].lastchar; x++) {
@@ -739,6 +760,7 @@
#ifdef CONFIG_SERIAL_CONSOLE
if (curses_flags & F_ENABLE_SERIAL) {
ch = win->_line[y].text[x].chars[0];
+#ifndef CONFIG_SERIAL_LOG_FILE
if (attr & A_BOLD) {
if (!serial_is_bold) {
@@ -798,6 +820,7 @@
serial_cur_pair = PAIR_NUMBER(attr);
}
+#endif //SERIAL_LOG_FILE
serial_putchar(ch);
}
Index: Config.in
===
--- Config.in (revision 3646)
+++ Config.in (working copy)
@@ -82,6 +82,14 @@
approximate the appearance of ACS characters on the serial port
console.
+config SERIAL_LOG_FILE
+ bool "Skip cursors and fanciness and add coordinates."
+ default n
+ depends on SERIAL_CONSOLE
+ help
+ If you're using an emulator and sending the serial output to a
+ file, this is for you.
+
config VIDEO_CONSOLE
bool "See output on a video console"
default y
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] tinycurses log file option
> > On 20/10/08 11:48 -0600, Myles Watson wrote: > > This patch creates a config option which allows you to see libpayload > output > > without escape sequences. It's useful for getting readable output from > an > > emulator whose serial port is redirected to a file. > > > > Signed-off-by: Myles Watson <[EMAIL PROTECTED]> > > > > A related note: coreinfo's make menuconfig doesn't work for me. It > can't > > find its include files: > > make menuconfig > > CC build/util/kconfig/lxdialog/checklist.o > > In file included from > > /home/myles/buildrom/buildrom- > devel/work/libpayload/svn/util/kconfig/lxdialog/checklist.c:24: > > /home/myles/buildrom/buildrom- > devel/work/libpayload/svn/util/kconfig/lxdialog/dialog.h:21:23: > > error: sys/types.h: No such file or directory > > /home/myles/buildrom/buildrom- > devel/work/libpayload/svn/util/kconfig/lxdialog/dialog.h:22:19: > > error: fcntl.h: No such file or directory > > /home/myles/buildrom/buildrom- > devel/work/libpayload/svn/util/kconfig/lxdialog/dialog.h:23:20: > > error: unistd.h: No such file or directory > > /home/myles/buildrom/buildrom- > devel/work/libpayload/svn/util/kconfig/lxdialog/dialog.h:24:19: > > error: ctype.h: No such file or directory > > Coreinfo or libpayload? That looks like output from libpayload. It also > looks like we are using the wrong include files. That doesn't happen for > me. Sorry. Libpayload. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] tinycurses log file option
> -Original Message- > From: Myles Watson [mailto:[EMAIL PROTECTED] > Sent: Monday, October 20, 2008 12:05 PM > To: 'Jordan Crouse' > Cc: 'Coreboot' > Subject: RE: tinycurses log file option > > > > > On 20/10/08 11:48 -0600, Myles Watson wrote: > > > This patch creates a config option which allows you to see libpayload > > output > > > without escape sequences. It's useful for getting readable output > from > > an > > > emulator whose serial port is redirected to a file. > > > > > > Signed-off-by: Myles Watson <[EMAIL PROTECTED]> > > > > > > A related note: coreinfo's make menuconfig doesn't work for me. It > > can't > > > find its include files: > > > make menuconfig > > > CC build/util/kconfig/lxdialog/checklist.o > > > In file included from > > > /home/myles/buildrom/buildrom- > > devel/work/libpayload/svn/util/kconfig/lxdialog/checklist.c:24: > > > /home/myles/buildrom/buildrom- > > devel/work/libpayload/svn/util/kconfig/lxdialog/dialog.h:21:23: > > > error: sys/types.h: No such file or directory > > > /home/myles/buildrom/buildrom- > > devel/work/libpayload/svn/util/kconfig/lxdialog/dialog.h:22:19: > > > error: fcntl.h: No such file or directory > > > /home/myles/buildrom/buildrom- > > devel/work/libpayload/svn/util/kconfig/lxdialog/dialog.h:23:20: > > > error: unistd.h: No such file or directory > > > /home/myles/buildrom/buildrom- > > devel/work/libpayload/svn/util/kconfig/lxdialog/dialog.h:24:19: > > > error: ctype.h: No such file or directory > > > > Coreinfo or libpayload? That looks like output from libpayload. It > also > > looks like we are using the wrong include files. That doesn't happen > for > > me. > > Sorry. Libpayload. I forgot to add that make oldconfig works just fine, so it's strange that the include files are wrong. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Serengeti VGA
I've been trying to make the configuration spaces match between v2 and v3. The biggest difference left is the disabled/hidden devices which are not hidden in v3. Any chance that's causing the problem? I've also been trying to figure out where the legacy IO space (e.g. 0x3d4) gets routed to the card. Does this happen automatically because the VGA bit is set in the bridge? Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Serengeti VGA
On Mon, Oct 20, 2008 at 1:48 PM, Marc Jones <[EMAIL PROTECTED]> wrote: > Myles Watson wrote: > >> I've been trying to make the configuration spaces match between v2 and v3. >> The biggest difference left is the disabled/hidden devices which are not >> hidden in v3. >> >> Any chance that's causing the problem? >> >> I've also been trying to figure out where the legacy IO space (e.g. 0x3d4) >> gets routed to the card. Does this happen automatically because the VGA >> bit >> is set in the bridge? >> >> Yes, The vga bit on the subtractive bridge routes the graphics io. > > How did you work around the vm86 problem? Did the graphics command register > get re-enabled? I made the interrupts self contained, with no output. The VGA ROM initialization returns, but there is no output to the screen. At least the screen turns black on an int10 now, though. The only differences between the PCI configuration registers now is that v3 has a little larger space for VGA and SERR is set. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Serengeti VGA
On Mon, Oct 20, 2008 at 1:56 PM, Myles Watson <[EMAIL PROTECTED]> wrote: > > > On Mon, Oct 20, 2008 at 1:48 PM, Marc Jones <[EMAIL PROTECTED]> wrote: > >> Myles Watson wrote: >> >>> I've been trying to make the configuration spaces match between v2 and >>> v3. >>> The biggest difference left is the disabled/hidden devices which are not >>> hidden in v3. >>> >>> Any chance that's causing the problem? >>> >>> I've also been trying to figure out where the legacy IO space (e.g. >>> 0x3d4) >>> gets routed to the card. Does this happen automatically because the VGA >>> bit >>> is set in the bridge? >>> >>> Yes, The vga bit on the subtractive bridge routes the graphics io. >> >> How did you work around the vm86 problem? Did the graphics command >> register get re-enabled? > > > I made the interrupts self contained, with no output. The VGA ROM > initialization returns, but there is no output to the screen. At least the > screen turns black on an int10 now, though. > I sent the patch to the list in a message with the subject "temporary fix" Now x86emu and vm86 have the same behavior. The both end with a black display but working serial. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Serengeti VGA
On Mon, Oct 20, 2008 at 2:26 PM, Marc Jones <[EMAIL PROTECTED]> wrote: > Myles Watson wrote: > > >> >> On Mon, Oct 20, 2008 at 1:48 PM, Marc Jones <[EMAIL PROTECTED] > [EMAIL PROTECTED]>> wrote: >> >>Myles Watson wrote: >> >>I've been trying to make the configuration spaces match between >>v2 and v3. >>The biggest difference left is the disabled/hidden devices which >>are not >>hidden in v3. >> >>Any chance that's causing the problem? >> >>I've also been trying to figure out where the legacy IO space >>(e.g. 0x3d4) >>gets routed to the card. Does this happen automatically because >>the VGA bit >>is set in the bridge? >> >>Yes, The vga bit on the subtractive bridge routes the graphics io. >> >>How did you work around the vm86 problem? Did the graphics command >>register get re-enabled? >> >> >> I made the interrupts self contained, with no output. The VGA ROM >> initialization returns, but there is no output to the screen. At least the >> screen turns black on an int10 now, though. >> >> The only differences between the PCI configuration registers now is that >> v3 has a little larger space for VGA and SERR is set. >> > > Ok, That should be fine. Black usually means all FF in the vga memory. > Check A000-B are getting to the controller. VGA enable in the bridge > control register (3e) and VGA pallet snoop in the command register (04) > should be set in the bridge. > As far as I can tell it's set correctly. I've included the config space below. What I wanted to see was the VGA BIOS message on the display when it initializes. Thanks, Myles 060 AMD-8111 PCI 74601022023001470604000700014000 4001010002001010 FE00FD00FFE0FFF0 00C0042B00FF 0604 0086F008002200D000010022 0002 00080008000F 8008 140Display Controller 2067102202A0014303034010 FD00FE0550001001 FE040001C0C00100 0240 K8 [Athlon64/Opteron] HyperTransport Technology Configuration 11001022001006000080 0080 00010101000101010001010100010101 00010101000101010001010100010101 00E40F00C8000070 2101A0080020807506220002 0251045600030007 2101C008771100D0807500220002 025104560002 21010008771100D0807500220002 025104560002 0241 K8 [Athlon64/Opteron] Address Map 1101102206000080 0003000F0001 00020003 00040005 00060007 0A030B00 00FD000300FE1F00 10132000 0303 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] tinycurses log file option
> -Original Message- > From: Stefan Reinauer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 21, 2008 4:27 AM > To: Uwe Hermann > Cc: Myles Watson; Coreboot > Subject: Re: [coreboot] tinycurses log file option > > Uwe Hermann wrote: > > On Tue, Oct 21, 2008 at 10:20:05AM +0200, Stefan Reinauer wrote: > > > >> On 20.10.2008, at 19:48, "Myles Watson" <[EMAIL PROTECTED]> wrote: > >> > >> > >>> This patch creates a config option which allows you to see libpayload > >>> output without escape sequences. It's useful for getting readable > >>> output from an emulator whose serial port is redirected to a file. > >>> > >>> Signed-off-by: Myles Watson <[EMAIL PROTECTED]> > >>> > >>> A related note: coreinfo's make menuconfig doesn't work for me. It > >>> can't find its include files: > >>> make menuconfig > >>> CC build/util/kconfig/lxdialog/checklist.o > >>> In file included from /home/myles/buildrom/buildrom-devel/work/ > >>> libpayload/svn/util/kconfig/lxdialog/checklist.c:24: > >>> /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ > >>> lxdialog/dialog.h:21:23: error: sys/types.h: No such file or directory > >>> /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ > >>> lxdialog/dialog.h:22:19: error: fcntl.h: No such file or directory > >>> /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ > >>> lxdialog/dialog.h:23:20: error: unistd.h: No such file or directory > >>> /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ > >>> lxdialog/dialog.h:24:19: error: ctype.h: No such file or directory > >>> > >>> > >> Did you install build-essentials? > >> > > > > This seems to be a build from within buildrom, so maybe it's kconfig > > related. I think we fixed one such issue a while ago in buildrom > > (unset/unexport some variables). > > > Obviously not a single one of the system include files can be found. > This is not a libpayload/coreinfo issue. They get found for the rest of kconfig, just not menuconfig. Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] tinycurses log file option
> -Original Message- > From: Uwe Hermann [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 21, 2008 4:01 AM > To: Stefan Reinauer > Cc: Myles Watson; Coreboot > Subject: Re: [coreboot] tinycurses log file option > > On Tue, Oct 21, 2008 at 10:20:05AM +0200, Stefan Reinauer wrote: > > On 20.10.2008, at 19:48, "Myles Watson" <[EMAIL PROTECTED]> wrote: > > > >> This patch creates a config option which allows you to see libpayload > >> output without escape sequences. It's useful for getting readable > >> output from an emulator whose serial port is redirected to a file. > >> > >> Signed-off-by: Myles Watson <[EMAIL PROTECTED]> > >> > >> A related note: coreinfo's make menuconfig doesn't work for me. It > >> can't find its include files: > >> make menuconfig > >> CC build/util/kconfig/lxdialog/checklist.o > >> In file included from /home/myles/buildrom/buildrom-devel/work/ > >> libpayload/svn/util/kconfig/lxdialog/checklist.c:24: > >> /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ > >> lxdialog/dialog.h:21:23: error: sys/types.h: No such file or directory > >> /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ > >> lxdialog/dialog.h:22:19: error: fcntl.h: No such file or directory > >> /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ > >> lxdialog/dialog.h:23:20: error: unistd.h: No such file or directory > >> /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ > >> lxdialog/dialog.h:24:19: error: ctype.h: No such file or directory > >> > > Did you install build-essentials? I don't know what that is. menuconfig works for all the other projects. > This seems to be a build from within buildrom, so maybe it's kconfig > related. I think we fixed one such issue a while ago in buildrom > (unset/unexport some variables). > > Is this latest svn of buildrom? Yes > Does a manual libpayload build > yield the same error? This is done manually. Libpayload builds fine, manually or with buildrom. The problem is when I want to run menuconfig. make oldconfig worked, though. If it makes a difference I'm on a 64-bit system. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] patch: unshare pci operations
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Carl-Daniel Hailfinger > Sent: Tuesday, October 21, 2008 12:28 AM > To: ron minnich > Cc: Marc Jones; Coreboot > Subject: Re: [coreboot] patch: unshare pci operations > > On 21.10.2008 01:50, ron minnich wrote: > > On Mon, Oct 20, 2008 at 4:42 PM, Marc Jones <[EMAIL PROTECTED]> wrote: > > > >> ron minnich wrote: > >> > >>> Unshare these, as we can not use them when buggy PCI expansion ROMS > >>> are active and are hiding ROM. > >>> > >>> > >> Acked-by: Marc Jones <[EMAIL PROTECTED]> > >> > >> > > > > Revision 940. > > > > Now we have to unshare the console functions; a bit trickier as they > > may also call string functions. I figure we will leave LAR shared. > > > > What about mapping the bootblock to the ROM window below 1M as was > discussed some time ago? I know it does not exactly look like fun, but > AFAIK all recent and ancient chipsets mirror the top 64k there. > > Regards, > Carl-Daniel > > P.S. I'd just say that calling console functions from during the ROM > mapping is illegal. It's our code, we get to specify what is run. That's the way I'm running now. The problem would be if someone in the future wanted to debug why their option ROM was failing, and added a few printks. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] tinycurses log file option
On Tue, Oct 21, 2008 at 8:53 AM, Jordan Crouse <[EMAIL PROTECTED]>wrote: > On 21/10/08 07:28 -0600, Myles Watson wrote: > > > > > > > -Original Message- > > > From: Uwe Hermann [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, October 21, 2008 4:01 AM > > > To: Stefan Reinauer > > > Cc: Myles Watson; Coreboot > > > Subject: Re: [coreboot] tinycurses log file option > > > > > > On Tue, Oct 21, 2008 at 10:20:05AM +0200, Stefan Reinauer wrote: > > > > On 20.10.2008, at 19:48, "Myles Watson" <[EMAIL PROTECTED]> wrote: > > > > > > > >> This patch creates a config option which allows you to see > libpayload > > > >> output without escape sequences. It's useful for getting readable > > > >> output from an emulator whose serial port is redirected to a file. > > > >> > > > >> Signed-off-by: Myles Watson <[EMAIL PROTECTED]> > > > >> > > > >> A related note: coreinfo's make menuconfig doesn't work for me. It > > > >> can't find its include files: > > > >> make menuconfig > > > >> CC build/util/kconfig/lxdialog/checklist.o > > > >> In file included from /home/myles/buildrom/buildrom-devel/work/ > > > >> libpayload/svn/util/kconfig/lxdialog/checklist.c:24: > > > >> > /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ > > > >> lxdialog/dialog.h:21:23: error: sys/types.h: No such file or > directory > > > >> > /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ > > > >> lxdialog/dialog.h:22:19: error: fcntl.h: No such file or directory > > > >> > /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ > > > >> lxdialog/dialog.h:23:20: error: unistd.h: No such file or directory > > > >> > /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/ > > > >> lxdialog/dialog.h:24:19: error: ctype.h: No such file or directory > > > >> > > > > Did you install build-essentials? > > > > I don't know what that is. menuconfig works for all the other projects. > > > > > This seems to be a build from within buildrom, so maybe it's kconfig > > > related. I think we fixed one such issue a while ago in buildrom > > > (unset/unexport some variables). > > > > > > Is this latest svn of buildrom? > > Yes > > > > > Does a manual libpayload build > > > yield the same error? > > > > This is done manually. Libpayload builds fine, manually or with > buildrom. > > The problem is when I want to run menuconfig. make oldconfig worked, > > though. > > Clean everything, and run with make V=1 - keep a special eye on how mconf > is built Here's the part that stands out to me: gcc -m32 -Wall -Werror -fno-stack-protector -nostdinc -Iinclude -Ibuild -I/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include -ffreestanding -c -o /home/myles/buildrom/buildrom-devel/work/libpayload/svn/build/util/kconfig/lxdialog/checklist.o /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/lxdialog/checklist.c Why does it use -m32 and x86_64 includes? That seems wrong. That's why I asked about the 64-bit machine. Thanks, Myles Here's the rest: make menuconfig V=1 mkdir -p /home/myles/buildrom/buildrom-devel/work/libpayload/svn/build/util/kconfig/lxdialog mkdir -p /home/myles/buildrom/buildrom-devel/work/libpayload/svn/build/crypto /home/myles/buildrom/buildrom-devel/work/libpayload/svn/build/curses /home/myles/buildrom/buildrom-devel/work/libpayload/svn/build/drivers/video mkdir -p /home/myles/buildrom/buildrom-devel/work/libpayload/svn/build/drivers/usb mkdir -p /home/myles/buildrom/buildrom-devel/work/libpayload/svn/build/i386 /home/myles/buildrom/buildrom-devel/work/libpayload/svn/build/lib/i386 /home/myles/buildrom/buildrom-devel/work/libpayload/svn/build/libc mkdir -p /home/myles/buildrom/buildrom-devel/work/libpayload/svn/lib/i386 gcc -I/home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig -I/home/myles/buildrom/buildrom-devel/work/libpayload/svn/build/util/kconfig -I/usr/include/ncurses -DCURSES_LOC="" -DLOCALE -c -o /home/myles/buildrom/buildrom-devel/work/libpayload/svn/build/util/kconfig/mconf.o /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/mconf.c cp /home/myles/buildrom/buildrom-devel/work/libpayload/svn/util/kconfig/zconf.tab.c_shipped /home/myles/buildrom/buildrom-devel/work/libpayload/svn/build/util/kconfig/zconf.tab.c cp /home/myles/buildrom/buildrom-devel/work/lib
Re: [coreboot] Serengeti VGA
On Mon, Oct 20, 2008 at 4:10 PM, Marc Jones <[EMAIL PROTECTED]> wrote: > Myles Watson wrote: > > >> 060 AMD-8111 PCI >> 74601022023001470604000700014000 >> 4001010002001010 >> FE00FD00FFE0FFF0 >> 00C0042B00FF >> > ^ > ISA isn't set. That might be a problem. > I can't tell that v2 ever sets it. In the 8111 datasheet it looks like that bit makes it so that bits 8 & 9 of the address get ignored so that only 256B of every 1024 are accessible. I don't think that's what we want. Looking for that I found an interesting couple of defines. include/device/pci_def.h:#define PCI_BRIDGE_CTL_NO_ISA 0x04/* Disable bridging of ISA ports */ include/device/pci_def.h:#define PCI_CB_BRIDGE_CTL_ISA 0x04 I can see that they're used in two different places (one for the hardware, one for the device struct), but it still seems confusing. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Serengeti VGA
On Tue, Oct 21, 2008 at 10:20 AM, Marc Jones <[EMAIL PROTECTED]> wrote: > Myles Watson wrote: > > >> >> On Mon, Oct 20, 2008 at 4:10 PM, Marc Jones <[EMAIL PROTECTED] > [EMAIL PROTECTED]>> wrote: >> >>Myles Watson wrote: >> >> >>060 AMD-8111 PCI >>74601022023001470604000700014000 >>4001010002001010 >>FE00FD00FFE0FFF0 >>00C0042B00FF >> >>^ >>ISA isn't set. That might be a problem. >> >> >> I can't tell that v2 ever sets it. In the 8111 datasheet it looks like >> that bit makes it so that bits 8 & 9 of the address get ignored so that only >> 256B of every 1024 are accessible. I don't think that's what we want. >> >> Looking for that I found an interesting couple of defines. >> >> include/device/pci_def.h:#define PCI_BRIDGE_CTL_NO_ISA 0x04/* >> Disable bridging of ISA ports */ >> include/device/pci_def.h:#define PCI_CB_BRIDGE_CTL_ISA 0x04 >> >> I can see that they're used in two different places (one for the hardware, >> one for the device struct), but it still seems confusing. >> > > I think that the problem is probably in the mmio map that Ron posted > yesterday. > This is my latest. The one Ron posted was from func 0 just after RAM init. This one is from func 1. After RAM init: DRAM(40)00-000fff, ->(0), R, W, No interleave, 0 DRAM(48)00-ff, ->(1), , , No interleave, 0 DRAM(50)00-ff, ->(2), , , No interleave, 0 DRAM(58)00-ff, ->(3), , , No interleave, 0 DRAM(60)00-ff, ->(4), , , No interleave, 0 DRAM(68)00-ff, ->(5), , , No interleave, 0 DRAM(70)00-ff, ->(6), , , No interleave, 0 DRAM(78)00-ff, ->(7), , , No interleave, 0 MMIO(80)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(88)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(90)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(98)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a0)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a8)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b0)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b8)00fc00-00, ->(0,0), R, W, CPU disable 0, Lock 0, Non posted 0 PCIIO(c0)0003-01fff000 PCIIO(c0)-01fff000, ->(0,0), R, W,VGA 0 ISA 0 PCIIO(c8)- PCIIO(c8)-, ->(0,0), , ,VGA 0 ISA 0 PCIIO(d0)- PCIIO(d0)-, ->(0,0), , ,VGA 0 ISA 0 PCIIO(d8)- PCIIO(d8)-, ->(0,0), , ,VGA 0 ISA 0 CONFIG(e0)003f- ->(0,0),R W CE 0 CONFIG(e4)- ->(0,0), CE 0 CONFIG(e8)- ->(0,0), CE 0 CONFIG(ec)- ->(0,0), CE 0 After assign resources ( I took out the ones that were all 0) DRAM(40)00-000fff, ->(0), R, W, No interleave, 0 MMIO(a8)0a-0b, ->(0,0), R, W, CPU disable 0, Lock 0, Non posted 0 MMIO(b0)00fd00-00fe1f, ->(0,0), R, W, CPU disable 0, Lock 0, Non posted 0 PCIIO(c0)1000-2000, ->(0,0), R, W,VGA 1 ISA 0 CONFIG(e0)0003- ->(0,0),R W CE 0 Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] committed route dumper code.
On Mon, Oct 20, 2008 at 9:23 PM, ron minnich <[EMAIL PROTECTED]> wrote:
> This code is now callable from anywhere. Here is output. This call is
> from initram. It looks like the dumper code or the routes are wrong in
> some, not all, cases. I am gone for next week on travel so
> I wanted to give people a look at it.
Thanks.
TODO: mv mainboard.c to stage2.c
> mv util.c to dumproutes.c
>
This patch cleans up the showallroutes utility:
1. fix if->in in comments
2. change width of output for different types
3. make all masks 0x so that it's easy to tell a mask
It also changes the invocations to do function 1 instead of 0.
I think we should consider a name that makes it clear that this is only good
for AMD K8+ processors function 1. We might need a similar utility for
other
functions later.
Signed-off-by: Myles Watson <[EMAIL PROTECTED]>
>
> DRAM(40)0100-00ff, ->(1), R, W, 2 nodes, 1
> DRAM(48)0100-00ff, ->(1), R, W, 2 nodes, 1
> DRAM(50)0100-00ff, ->(1), R, W, 2 nodes, 1
> DRAM(58)0100-00ff, ->(1), R, W, 2 nodes, 1
> DRAM(60)-00ff, ->(4), , , No interleave, 0
> DRAM(68)-00ff, ->(0), R, W, 8 nodes, 0
> DRAM(70)-00ff, ->(0), , , No interleave, 0
> DRAM(78)-00ff, ->(0), , , No interleave, 0
> MMIO(80)01a0-1100, ->(0,2), , , CPU disable 0, Lock 0, Non posted 0
> MMIO(88)7506-, ->(2,0), , , CPU disable 0, Lock 0, Non posted 0
> MMIO(90)5104-3f00, ->(0,0), , , CPU disable 1, Lock 0, Non posted 0
> MMIO(98)-, ->(0,0), R, W, CPU disable 0, Lock 0, Non posted
> 0
> MMIO(a0)01c0-1100, ->(0,1), , , CPU disable 0, Lock 0, Non posted 1
> MMIO(a8)7500-, ->(2,0), , , CPU disable 0, Lock 0, Non posted 0
> MMIO(b0)5104-, ->(0,0), , , CPU disable 1, Lock 0, Non posted 0
> MMIO(b8)-, ->(0,0), , , CPU disable 0, Lock 0, Non posted 0
> PCIIO(c0)1010-3110, ->(0,1), , ,VGA 0 ISA 0
> PCIIO(c8)0750-, ->(2,0), , ,VGA 0 ISA 1
> PCIIO(d0)2510-, ->(0,0), , ,VGA 1 ISA 0
> PCIIO(d8)-, ->(0,0), , ,VGA 0 ISA 0
> CONFIG(e0)- ->(0,0), CE 0
> CONFIG(e4)- ->(0,0), CE 0
> CONFIG(e8)- ->(0,0), CE 0
> CONFIG(ec)- ->(0,0), CE 0
Output with patch:
DRAM(40)00-000fff, ->(0), R, W, No interleave, 0
DRAM(48)00-ff, ->(1), , , No interleave, 0
DRAM(50)00-ff, ->(2), , , No interleave, 0
DRAM(58)00-ff, ->(3), , , No interleave, 0
DRAM(60)00-ff, ->(4), , , No interleave, 0
DRAM(68)00-ff, ->(5), , , No interleave, 0
DRAM(70)00-ff, ->(6), , , No interleave, 0
DRAM(78)00-ff, ->(7), , , No interleave, 0
MMIO(80)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non
posted 0
MMIO(88)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non
posted 0
MMIO(90)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non
posted 0
MMIO(98)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non
posted 0
MMIO(a0)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non
posted 0
MMIO(a8)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non
posted 0
MMIO(b0)00-00, ->(0,0), , , CPU disable 0, Lock 0, Non
posted 0
MMIO(b8)00fc00-00, ->(0,0), R, W, CPU disable 0, Lock 0, Non
posted 0
PCIIO(c0)000-1ff, ->(0,0), R, W,VGA 0 ISA 0
PCIIO(c8)000-fff, ->(0,0), , ,VGA 0 ISA 0
PCIIO(d0)000-fff, ->(0,0), , ,VGA 0 ISA 0
PCIIO(d8)000-fff, ->(0,0), , ,VGA 0 ISA 0
CONFIG(e0)3f-00 ->(0,0),R W CE 0
CONFIG(e4)00-00 ->(0,0), CE 0
CONFIG(e8)00-00 ->(0,0), CE 0
CONFIG(ec)00-00 ->(0,0), CE 0
Thanks,
Myles
Index: mainboard/amd/serengeti/mainboard.c
===
--- mainboard/amd/serengeti/mainboard.c (revision 941)
+++ mainboard/amd/serengeti/mainboard.c (working copy)
@@ -35,14 +35,14 @@
static void show(struct device *dev)
{
- showallroutes(BIOS_DEBUG, PCI_BDF(0,0x18, 0));
+ showallroutes(BIOS_DEBUG, PCI_BDF(0,0x18, 1));
}
struct device_operations serengeti = {
.id = {.type = DEVICE_ID_PCI,
{.pci = {.vendor = PCI_VENDOR_ID_AMD,
- .device = 1}}},
- .constructor = default_device_constructor,
+ .device = 1}}},
+ .constructor = default_device_constructor,
.phase6_init = show,
};
Index: mainboard/amd/serengeti/initram.c
===
--- mainboard/amd/serengeti/initram.c (revision 941)
+++ mainboard/amd/serengeti/initram.c (working copy)
@@ -250,7 +25
[coreboot] SimNOW debugger syntax help
Marc, Jordan, or another SimNOW user, f[b|w|d|q] [,[l|p]] Fill physical(default) or linear Memory I wanted to fill the VGA RAM with a pattern, but I can't figure out the syntax for an . It keeps freezing the simulator. Could you give me an example for filling 1M of memory in physical address space with some pattern? I would have expected the [,[l|p]] to come after the too. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] SimNOW debugger syntax help
> -Original Message- > From: Marc Jones [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 21, 2008 2:50 PM > To: Myles Watson > Cc: Coreboot; Jordan Crouse > Subject: Re: SimNOW debugger syntax help > > Myles Watson wrote: > > Marc, Jordan, or another SimNOW user, > > > > f[b|w|d|q] [,[l|p]] Fill physical(default) or > > linear Memory > > > > I wanted to fill the VGA RAM with a pattern, but I can't figure out the > > syntax for an . It keeps freezing the simulator. Could > > you give me an example for filling 1M of memory in physical address > > space with some pattern? > > > > I would have expected the [,[l|p]] to come after the > too. > > > > Thanks, > > Myles > > > fd 10 10001f ,p 5a5a5a5a > > worked for me. You are right about the ,p. I am not sure why it would be > freezing unless the mem map is really screwed up and it is going > somewhere bad. Thanks. It looks like the IO addresses are getting through to the VGA card, but I can't find the memory addresses changing for the buffer memory. This should help me look. I set a breakpoint on c0040 since that's the string that gets copied to the display memory. The first time it gets accessed is when the ROM gets copied to c, but the next time is the right one. Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] r3681 libpayload build failure
> -Original Message- > From: Uwe Hermann [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 22, 2008 5:12 AM > To: Stefan Reinauer > Cc: Jordan Crouse; Myles Watson; coreboot@coreboot.org > Subject: Re: [coreboot] r3681 libpayload build failure > > On Wed, Oct 22, 2008 at 01:08:19PM +0200, Uwe Hermann wrote: > > On Wed, Oct 22, 2008 at 12:48:02PM +0200, Stefan Reinauer wrote: > > > [EMAIL PROTECTED] wrote: > > > > Author: jcrouse > > > > Date: 2008-10-21 23:49:48 +0200 (Tue, 21 Oct 2008) > > > > New Revision: 3681 > > > > > > > > Modified: > > > >trunk/payloads/libpayload/Makefile > > > >trunk/payloads/libpayload/drivers/video/video.c > > > >trunk/payloads/libpayload/sample/hello.c > > > > Log: > > > > [PATCH] fix video console init > > > > > > > > Move console_add_output-driver() inside the for() loop > > > > > > > > Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]> > > > > Acked-by: Jordan Crouse <[EMAIL PROTECTED]> > > > > > > > > > > > > Modified: trunk/payloads/libpayload/Makefile > > > > === > > > > --- trunk/payloads/libpayload/Makefile 2008-10-21 16:27:38 UTC > (rev 3680) > > > > +++ trunk/payloads/libpayload/Makefile 2008-10-21 21:49:48 UTC > (rev 3681) > > > > @@ -115,6 +115,8 @@ > > > > $(Q)printf " AR $(subst $(shell pwd)/,,$(@))\n" > > > > $(Q)$(AR) rc $@ $(OBJS) > > > > > > > > +include util/kconfig/Makefile > > > > + > > > > $(obj)/%.o: $(src)/%.c > > > > $(Q)printf " CC $(subst $(shell pwd)/,,$(@))\n" > > > > $(Q)$(CC) -m32 $(CFLAGS) -c -o $@ $< > > > > @@ -164,7 +166,6 @@ > > > > $(Q)rm -rf build > > > > $(Q)rm -f .config .config.old ..config.tmp .kconfig.d > .tmpconfig* > > > > > > > > -include util/kconfig/Makefile > > > > > > > > .PHONY: $(PHONY) prepare clean distclean doxygen doxy > > > > > > > > > > This part is not mentioned in the changelog of the commit. I assume it > > > has been committed by accident, because it breaks libpayload here: > > > > > > ra:libpayload stepan$ make menuconfig > > > make: *** No rule to make target `menuconfig'. Stop. > > > ra:libpayload stepan$ make config > > > make: *** No rule to make target `config'. Stop. > > > ra:libpayload stepan$ > > > > Yep, was committed accidentally I think. Moving that include as above > > is also not sufficient, I think, as the 'ifeq' part in the Makefile is > > not honored. > > > > Please try attached patch, works for me. I hope this will also fix > > Myles' compile problems. My build failure got cleared up as of 3685, and still works with this patch applied. Acked-by: Myles Watson <[EMAIL PROTECTED]> Thanks, Myles -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
