Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+

[Knut Kujat]

Myles Watson escribió:
>
>
> On Mon, Dec 21, 2009 at 9:15 AM, Knut Kujat  > wrote:
>
> Myles Watson escribió:
>>
>>
>> On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat > > wrote:
>>
>>
>> but I haven't changed anything but inserting some printk_spew
>> into "void dev_initialize(void)" to see where exactly jumps
>> the exception out.
>>
>> Did you try increasing the stack size?  When you inserted the
>> printk statements, were there any warnings about format strings
>> not matching the number of arguments?  Have you tried disabling
>> the siblings yet?
>>
>> Thanks,
>> Myles  
>>
>
> Hello,
>
> yes increasing stack size helped with the printks.
>
> How big did you make it?  Try making it bigger until it doesn't make a
> difference any more.
>  
>
> And yes I tried to disable siblings by adding uses
> CONFIG_LOGICAL_PROCESSORS and default CONFIG_LOGICAL_PROCESSORS=0
> to the Options.lb file but it complains at building time that this
> options is unkown so I uses LOGICAL_CPUS instead (is it the same?)
> without results.
>
> You found the right one.  Sorry I steered you wrong.  All the
> processors get initialized even with CONFIG_LOGICAL_CPUS=0?  That's
> not good.
>  
>
> Now I know that the the exception comes up in the corresponding
> init(dev) for the PCI: 00:02.0 device. So I disabled PCI 2.0 in
> the device tree and it just doesn't has any effect even it tells
> me that PCI 2.0 enabled 0 at boot times, it stucks at the same place.
>
> I don't think the init function is the problem.  It's more likely that
> something is going wrong much earlier, and just catches up to you
> there.  I would leave the device enabled.
>
> Thanks,
> Myles
>
Morning,

stack_size = 0x4000 and seems to work fine.

Sorry, I didn't explain myself, changing CONFIG_LOGICAL_CPUS to 0 made
the compile process fail in northbridge.c so I had to change it back.
Yes disabling devices didn't make any difference so I leave them enabled.

h what else could I do??

THX,

Knut Kujat.

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

Re: [coreboot] Coreboot Support for MSI Board MS-6702E

[Paul Menzel]

Dear freeman2411,


Am Dienstag, den 22.12.2009, 01:38 +0100 schrieb freeman2411:
> Can someone help me to get coreboot support for my board MS-6702E?

Could you please include more information so that the developers – not
me – can save some time by not searching for it individually for
themselves. Like a link to a web page of the manufacturer with more
information for this board.

What chipsets does this board have? Are they supported [1]?

Also some program outputs would be nice [2].

Do you have the means to recover from a failed flash? Do you have some
extra flash chips [3]?


Thanks,

Paul


[1] http://www.coreboot.org/Supported_Chipsets_and_Devices
[2] http://www.coreboot.org/FAQ#Will_coreboot_work_on_my_machine.3F
[3] 
http://www.coreboot.org/FAQ#Where_can_I_buy_BIOS_chips_.28empty_or_pre-flashed.29.3F


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] The function int15 working on the Technexion's tim5690.

[Libra Li]

Hi Marc Jones,

This is a new patch file. I modified mainboard_interrupt_handlers and
setup_interrupt_handlers in the "util/x86emu/x86.c".

Thanks.
Libra.


2009/12/22 Libra Li 

> Hi Marc Jones,
>
> 1.
> +typedef struct {
> +int mask[256];
> +int (*intXX_handler[256])(struct eregs *regs);
> +}interrupt_handlers;
>
> The mainboard_interrupt_handlers need modification if the
> structure is not needed.
>
> 2.
> +   if(!(*intXX_handler))
>
> +   {
> +   /* Set up C interrupt handlers */
> +   setup_interrupt_handlers();
> +   }
>
> Yes, this is because mainboard_interrupt_handlers gets called
> first.
>
>
> 2009/12/22 Marc Jones 
>
> On Mon, Dec 21, 2009 at 6:15 PM, Libra Li  wrote:
>> > Hi,
>> >
>> > The VGA BIOS is through int15 getting LCD panel ID. Then the VBIOS
>> call
>> > int15's "Get LCD panel ID".
>> > The panel ID is selection by switch.
>> > This function is reference "AMD RS690 ASIC Family BIOS Developer's
>> > Guide".
>> >
>> > Thanks.
>> >
>> > Signed-off-by: Libra Li 
>>
>> Hi Libra Li,
>>
>> Thanks for making these changes. I like the idea of the mainboard
>> interrupt function. I have a few comments.
>>
>> +typedef struct {
>> +int mask[256];
>> +int (*intXX_handler[256])(struct eregs *regs);
>> +}interrupt_handlers;
>>
>> This is a really big structure and probably not needed. I don't think
>> anyone would override every interrupt vector, just one or two like you
>> are doing. Maybe just use a table that has the interrupt and function
>> pointer.
>>
>>
>> +   if(!(*intXX_handler))
>> +   {
>> +   /* Set up C interrupt handlers */
>> +   setup_interrupt_handlers();
>> +   }
>> +
>>
>> Is this because mainboard_interrupt_handlers gets called first and the
>> interrupts are over written? It would be better if the defaults could
>> always be loaded and then the main board interrupts get fixed up.
>>
>> Thanks,
>> Marc
>>
>>
>> --
>> http://marcjonesconsulting.com
>>
>
>
Index: src/mainboard/technexion/tim5690/vgabios.h
===
--- src/mainboard/technexion/tim5690/vgabios.h	(revision 0)
+++ src/mainboard/technexion/tim5690/vgabios.h	(revision 0)
@@ -0,0 +1,37 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2009 coresystems GmbH
+ * Copyright (C) 2009 Libra Li 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+/* AMD Chipset */
+#define AMD_RS690_INT15 0x4E08
+
+typedef struct __rs690_int15_regs__
+{
+u8 fun00_panel_id;  // Callback Sub-Function 00h - Get LCD Panel ID
+u8 fun05_tv_standard;   // Callback Sub-Function 05h - Select Boot-up TV Standard
+}rs690_int15_regs;
+
+typedef struct __rs690_vbios_regs__
+{
+rs690_int15_regsint15_regs;
+}rs690_vbios_regs;
+
+/* Initialization VBIOS function */
+extern void vgabios_init(rs690_vbios_regs *vbios_regs);
Index: src/mainboard/technexion/tim5690/Makefile.inc
===
--- src/mainboard/technexion/tim5690/Makefile.inc	(revision 4981)
+++ src/mainboard/technexion/tim5690/Makefile.inc	(working copy)
@@ -33,6 +33,7 @@
 obj-y += tn_post_code.o
 
 obj-y += speaker.o
+obj-y += vgabios.o
 
 # This is part of the conversion to init-obj and away from included code.
 
Index: src/mainboard/technexion/tim5690/cache_as_ram_auto.c
===
--- src/mainboard/technexion/tim5690/cache_as_ram_auto.c	(revision 4981)
+++ src/mainboard/technexion/tim5690/cache_as_ram_auto.c	(working copy)
@@ -145,20 +145,6 @@
 }
 #endif/* CONFIG_USE_FALLBACK_IMAGE == 1 */
 
-/* Early mainboard specific GPIO setup. */
-static void mb_gpio_init(void)
-{
-	/* Init Super I/O GPIOs. Done early. */
-	it8712f_enter_conf();
-	outb(IT8712F_CONFIG_REG_LDN, SIO_INDEX);
-	outb(IT8712F_GPIO, SIO_DATA);
-	outb(0x62, SIO_INDEX); // set Simple I/O Base Address 0x200
-	outb(0x02, SIO_DATA);
-	outb(0x63, SIO_INDEX);
-	outb(0x00, SIO_DATA);
-	it8712f_exit_conf();
-}
-
 void real_main(unsigned long bist, unsigned long cpu_init_detectedx);
 
 void cache_as_ram_main(u

Re: [coreboot] Coreboot Support for MSI Board MS-6702E

[Paul Menzel]

Am Dienstag, den 22.12.2009, 11:49 +0100 schrieb freeman2411:
> Ok thank you Paul for this hints. Here some Specs which I could find
> out easily, attached in the jpg file.

Thank you for your answer. Please copy the values as text into the
message next time for better quoting and handling.

• Chipset/Northbridge(?): K8T800 Pro
• Southbridge: VIA VT8237

I did not find those in the supported chipsets and devices list [1] so
it is unlikely that the status concerning support has changed since this
answer from Uwe regarding as different board but the same chips devices
[2].

• LPCIO: W83627THF

There is ? at the list [1] but Uwe suggested that it is supported [2].

So it looks like to get support for your board you would need to start
getting the documentation from VIA and start coding by yourself.

Unfortunately all developers are quite busy with long TODO lists so
porting boards, which they do not own, in their free time is very
unlikely. But they would definitely answer any questions you have during
the process of porting the board yourself on this list or on IRC.


Thanks,

Paul


[1] http://www.coreboot.org/Supported_Chipsets_and_Devices
[2] http://www.coreboot.org/pipermail/coreboot/2006-October/016385.html


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] bios_extract

[Luc Verhaegen]

On Tue, Dec 22, 2009 at 12:54:33AM +0100, Rudolf Marek wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> > 1) there is a flag for uncompressed module 0x90 instead of 0x80 dunno why
> > 2) if the module size in rom > 0x some bytes before the structure are 
> > used
> > as size, the second number looks like crc maybe.
> 
> It turns out the extra header is there for all modules.
> 
> The unknown value is a simple 32bit sum over HEADER and BODY to sum up to 0 ;)
> 
> Dont know how it works for compressed modules nor how it works for modules 
> with
> not multiple of 4. It should be easy to get.
> 
> Rudolf
I have seen these headers on compressed too i think. Will have another 
look at the 2MB module to check. In the meantime, we should add this 
info.

Luc Verhaegen.

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

Re: [coreboot] Coreboot Support for MSI Board MS-6702E

[freeman2411]

Thank you Paul. The main problem I have is that I am not a very well C
Programmer so it will be impossible for me to get this board running with
coreboot. :-(

But maybe I am lucky with my next board. :-)

Greetings


freeman2411

2009/12/22 Paul Menzel 

> Am Dienstag, den 22.12.2009, 11:49 +0100 schrieb freeman2411:
> > Ok thank you Paul for this hints. Here some Specs which I could find
> > out easily, attached in the jpg file.
>
> Thank you for your answer. Please copy the values as text into the
> message next time for better quoting and handling.
>
> • Chipset/Northbridge(?): K8T800 Pro
> • Southbridge: VIA VT8237
>
> I did not find those in the supported chipsets and devices list [1] so
> it is unlikely that the status concerning support has changed since this
> answer from Uwe regarding as different board but the same chips devices
> [2].
>
> • LPCIO: W83627THF
>
> There is ? at the list [1] but Uwe suggested that it is supported [2].
>
> So it looks like to get support for your board you would need to start
> getting the documentation from VIA and start coding by yourself.
>
> Unfortunately all developers are quite busy with long TODO lists so
> porting boards, which they do not own, in their free time is very
> unlikely. But they would definitely answer any questions you have during
> the process of porting the board yourself on this list or on IRC.
>
>
> Thanks,
>
> Paul
>
>
> [1] http://www.coreboot.org/Supported_Chipsets_and_Devices
> [2] http://www.coreboot.org/pipermail/coreboot/2006-October/016385.html
>
> --
> 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] Problems porting H8dmr_fam10 to H8qme-2+

[Ward Vandewege]

Hi Knut,

On Tue, Dec 22, 2009 at 10:25:06AM +0100, Knut Kujat wrote:
> stack_size = 0x4000 and seems to work fine.
> 
> Sorry, I didn't explain myself, changing CONFIG_LOGICAL_CPUS to 0 made
> the compile process fail in northbridge.c so I had to change it back.

Yeah, that's because of this in northbridge.c:

#if CONFIG_LOGICAL_CPUS==1
#include 
#include 
#endif

The read_nb_cfg_54() function is defined in quadcore.h, so if you set
CONFIG_LOGICAL_CPUS to zero compilation fails with an implicit definition
error for read_nb_cfg_54.

The tree compiles for me if I comment out that if/endif lines and have
CONFIG_LOGICAL_CPUS set to zero.

Thanks,
Ward.

-- 
Ward Vandewege 
Free Software Foundation - Senior Systems Administrator

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

[coreboot] arima irq issues

[Hugh Greenberg]

Hello again.  I still have issues with the ARIMA.  I am now getting 
errors from Linux regarding IRQs and the MP table.  I've tried various 
Linux options and none of them have helped.  This seems to be preventing 
the ethernet and myrinet cards from functioning.  Here is the relevant 
output:


pci :00:01.0: MSI quirk detected; subordinate MSI disabled
disabled boot interrupts on PCI device 0x1022:0x7450
pci :00:01.0: AMD8131 rev 12 detected; disabling PCI-X MMRBC
pci :00:02.0: MSI quirk detected; subordinate MSI disabled
disabled boot interrupts on PCI device 0x1022:0x7450
pci :00:02.0: AMD8131 rev 12 detected; disabling PCI-X MMRBC
boot interrupts on PCI device 0x1022:0x746b already disabled
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
Non-volatile memory driver v1.3
Linux agpgart interface v0.103
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
�serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial :00:04.6: can't find IRQ for PCI INT B; probably buggy MP table
brd: module loaded
loop: module loaded
input: Macintosh mouse button emulation as /devices/virtual/input/input0
Fixed MDIO Bus: probed
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd :03:00.0: can't find IRQ for PCI INT D; probably buggy MP table
ohci_hcd :03:00.0: Found HC with no IRQ.  Check BIOS/PCI 
:03:00.0 setup!

ohci_hcd :03:00.0: init :03:00.0 fail, -19
ohci_hcd :03:00.1: can't find IRQ for PCI INT D; probably buggy MP table
ohci_hcd :03:00.1: Found HC with no IRQ.  Check BIOS/PCI 
:03:00.1 setup!

ohci_hcd :03:00.1: init :03:00.1 fail, -19
uhci_hcd: USB Universal Host Controller Interface driver
PNP: No PS/2 controller found. Probing ports directly.
Clocksource tsc unstable (delta = 148473685 ns)
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one day, 114 bytes nvram
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: 
dm-de...@redhat.com

cpuidle: using governor ladder
cpuidle: using governor menu
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
registered taskstats version 1
No TPM chip found, activating TPM-bypass!
  Magic number: 5:661:239
rtc_cmos rtc_cmos: setting system clock to 2009-12-22 17:12:30 UTC 
(1261501950)

Initalizing network drop monitor service
Freeing unused kernel memory: 1324k freed
Write protecting the kernel read-only data: 6344k
Welcome to Fedora
Press 'I' to enter interactive startup.
Starting udev: [  OK  ]
Setting hostname m91:  [  OK  ]
Setting up Logical Volume Management: [  OK  ]
Remounting root filesystem in read-write mode:  [  OK  ]
Mounting local filesystems:  [  OK  ]
Enabling /etc/fstab swaps:  [  OK  ]
Entering non-interactive startup
Starting gm... Warning: /dev/gm* devices were not created, doing it now...
active mapper... done.
Bringing up loopback interface:  [  OK  ]
Bringing up interface eth0:
Determining IP information for eth0... failed; no link present.  Check 
cable?

[FAILED]
Bringing up interface myri0:
Determining IP information for myri0...RTNETLINK answers: Input/output error

Any ideas?  Thanks.

--
Hugh Greenberg



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

Re: [coreboot] arima irq issues

[Stefan Reinauer]

On 12/22/09 5:59 PM, Hugh Greenberg wrote:
> Hello again.  I still have issues with the ARIMA.  I am now getting
> errors from Linux regarding IRQs and the MP table.  I've tried various
> Linux options and none of them have helped.  This seems to be
> preventing the ethernet and myrinet cards from functioning.  Here is
> the relevant output:
>

Please check whether the bus:device:function numbers for the devices you
see match those in mptable and pirq table. While the bus numbers may
change mp and pirq are often static in coreboot (which is a bug).

Stefan



> pci :00:01.0: MSI quirk detected; subordinate MSI disabled
> disabled boot interrupts on PCI device 0x1022:0x7450
> pci :00:01.0: AMD8131 rev 12 detected; disabling PCI-X MMRBC
> pci :00:02.0: MSI quirk detected; subordinate MSI disabled
> disabled boot interrupts on PCI device 0x1022:0x7450
> pci :00:02.0: AMD8131 rev 12 detected; disabling PCI-X MMRBC
> boot interrupts on PCI device 0x1022:0x746b already disabled
> pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> pciehp: PCI Express Hot Plug Controller Driver version: 0.4
> acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> Non-volatile memory driver v1.3
> Linux agpgart interface v0.103
> Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> �serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> serial :00:04.6: can't find IRQ for PCI INT B; probably buggy MP
> table
> brd: module loaded
> loop: module loaded
> input: Macintosh mouse button emulation as /devices/virtual/input/input0
> Fixed MDIO Bus: probed
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> ohci_hcd :03:00.0: can't find IRQ for PCI INT D; probably buggy MP
> table
> ohci_hcd :03:00.0: Found HC with no IRQ.  Check BIOS/PCI
> :03:00.0 setup!
> ohci_hcd :03:00.0: init :03:00.0 fail, -19
> ohci_hcd :03:00.1: can't find IRQ for PCI INT D; probably buggy MP
> table
> ohci_hcd :03:00.1: Found HC with no IRQ.  Check BIOS/PCI
> :03:00.1 setup!
> ohci_hcd :03:00.1: init :03:00.1 fail, -19
> uhci_hcd: USB Universal Host Controller Interface driver
> PNP: No PS/2 controller found. Probing ports directly.
> Clocksource tsc unstable (delta = 148473685 ns)
> serio: i8042 KBD port at 0x60,0x64 irq 1
> mice: PS/2 mouse device common for all mice
> rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
> rtc0: alarms up to one day, 114 bytes nvram
> device-mapper: uevent: version 1.0.3
> device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised:
> dm-de...@redhat.com
> cpuidle: using governor ladder
> cpuidle: using governor menu
> usbcore: registered new interface driver hiddev
> usbcore: registered new interface driver usbhid
> usbhid: v2.6:USB HID core driver
> nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
> CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
> nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module
> option or
> sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
> ip_tables: (C) 2000-2006 Netfilter Core Team
> TCP cubic registered
> Initializing XFRM netlink socket
> NET: Registered protocol family 17
> registered taskstats version 1
> No TPM chip found, activating TPM-bypass!
>   Magic number: 5:661:239
> rtc_cmos rtc_cmos: setting system clock to 2009-12-22 17:12:30 UTC
> (1261501950)
> Initalizing network drop monitor service
> Freeing unused kernel memory: 1324k freed
> Write protecting the kernel read-only data: 6344k
> Welcome to Fedora
> Press 'I' to enter interactive startup.
> Starting udev: [  OK  ]
> Setting hostname m91:  [  OK  ]
> Setting up Logical Volume Management: [  OK  ]
> Remounting root filesystem in read-write mode:  [  OK  ]
> Mounting local filesystems:  [  OK  ]
> Enabling /etc/fstab swaps:  [  OK  ]
> Entering non-interactive startup
> Starting gm... Warning: /dev/gm* devices were not created, doing it
> now...
> active mapper... done.
> Bringing up loopback interface:  [  OK  ]
> Bringing up interface eth0:
> Determining IP information for eth0... failed; no link present.  Check
> cable?
> [FAILED]
> Bringing up interface myri0:
> Determining IP information for myri0...RTNETLINK answers: Input/output
> error
>
> Any ideas?  Thanks.
>


-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
  Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866


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

Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+

[Myles Watson]

On Tue, Dec 22, 2009 at 9:22 AM, Knut Kujat  wrote:

>  Hello,
>
> as Myles suggested to disable siblings to see if I can pass through this
> weird exception and the impossibility  to do so because of the compile error
> I changed the physical cpu option to 1 and it worked! But increasing it back
> to 2 or 4 made the exception come back again.
> I told you, Myles, I increased stack size to 4000 that was a filthy lie
> because I thought I'm increasing it to 4000 what I didn't see was that the
> same option was repeated at the end of the Options.lb file with
> STACK_SIZE=8000
>
It's always good to check targets/vendor/board/build/fallback/ldoptions to
see what's really being used.


> (So I don't know  why the printks started working). Now fooling around with
> stack size and setting it up to 1 all 4 cpus started working and I got a
> grub menu :) in text mode :( so I have a graphics Initializing faild and
> Linux doesn't boot up completly.
>
Great.  I think we're getting to where we should add your board to the
tree.  Then we can see the device tree too.


> I attached a complete log file, it is not so complete because the first
> lines of linux boot up are missing because I had to change serial speed on
> minicom. Thats because I'm having trouble of setting a speed and getting a
> total different one.
>
> Now I thing that my device tree is not completely working and thats why
> linux got some collusion at the beginning ??
>
It device 0:02.3 isn't getting a driver.  1:06.0 is not found.

PCI: 08:01.0 Hypertransport link capability not foundPCI: pci_scan_bus for
bus 08

That doesn't look good.

PCI: Left over static devices:
PCI: 08:01.0
PCI: 08:01.1
PCI: 08:02.0




> And I have no idea why graphic mode doesn't work since it looks like it
> finds vga without any problem.
>

VGA: PCI: 00:18.0 (aka node 0) link 2 has VGA device

That doesn't look right.  I would think it's on link 0.  I don't know why
that's set wrong, but it would explain why it's not working.

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

Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+

[Knut Kujat]

Myles Watson escribió:
>
>
> On Tue, Dec 22, 2009 at 9:22 AM, Knut Kujat  > wrote:
>
> Hello,
>
> as Myles suggested to disable siblings to see if I can pass
> through this weird exception and the impossibility  to do so
> because of the compile error I changed the physical cpu option to
> 1 and it worked! But increasing it back to 2 or 4 made the
> exception come back again.
> I told you, Myles, I increased stack size to 4000 that was a
> filthy lie because I thought I'm increasing it to 4000 what I
> didn't see was that the same option was repeated at the end of the
> Options.lb file with STACK_SIZE=8000
>
> It's always good to check
> targets/vendor/board/build/fallback/ldoptions to see what's really
> being used.
>  
>
> (So I don't know  why the printks started working). Now fooling
> around with stack size and setting it up to 1 all 4 cpus
> started working and I got a grub menu :) in text mode :( so I have
> a graphics Initializing faild and Linux doesn't boot up completly.
>
> Great.  I think we're getting to where we should add your board to the
> tree.  Then we can see the device tree too.
I attached it.
>  
>
> I attached a complete log file, it is not so complete because the
> first lines of linux boot up are missing because I had to change
> serial speed on minicom. Thats because I'm having trouble of
> setting a speed and getting a total different one.
>
> Now I thing that my device tree is not completely working and
> thats why linux got some collusion at the beginning ??
>
> It device 0:02.3 isn't getting a driver.  1:06.0 is not found.
>
> PCI: 08:01.0 Hypertransport link capability not foundPCI: pci_scan_bus
> for bus 08
>
> That doesn't look good.
>
> PCI: Left over static devices:
> PCI: 08:01.0
> PCI: 08:01.1
> PCI: 08:02.0
>
>
>  
>
> And I have no idea why graphic mode doesn't work since it looks
> like it finds vga without any problem.
>
>  
> VGA: PCI: 00:18.0 (aka node 0) link 2 has VGA device
>
> That doesn't look right.  I would think it's on link 0.  I don't know
> why that's set wrong, but it would explain why it's not working.
>
> Thanks,
> Myles
## 
## This file is part of the coreboot project.
## 
## Copyright (C) 2007 AMD
## Written by Yinghai Lu  for AMD.
## 
## This program is free software; you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation; either version 2 of the License, or
## (at your option) any later version.
## 
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
## GNU General Public License for more details.
## 
## You should have received a copy of the GNU General Public License
## along with this program; if not, write to the Free Software
## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
## 

## CONFIG_XIP_ROM_SIZE must be a power of 2.
# for testing with -O != s. FIXME
#default CONFIG_XIP_ROM_SIZE = 128 * 1024
default CONFIG_XIP_ROM_SIZE = 128 * 1024
include /config/failovercalculation.lb

arch i386 end 

##
## Build the objects we have code for in this directory.
##

driver mainboard.o
#needed by irq_tables and mptable and acpi_tables
object get_bus_conf.o

if CONFIG_GENERATE_MP_TABLE object mptable.o end
if CONFIG_GENERATE_PIRQ_TABLE object irq_tables.o end

if CONFIG_USE_INIT  
makerule ./auto.o
depends "$(CONFIG_MAINBOARD)/cache_as_ram_auto.c 
option_table.h"
action "$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) 
-I$(TOP)/src -I. -c $(CONFIG_MAINBOARD)/cache_as_ram_auto.c -o $@"
end
else
makerule ./auto.inc
depends "$(CONFIG_MAINBOARD)/cache_as_ram_auto.c 
option_table.h"
action "$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) 
$(DEBUG_CFLAGS) -I$(TOP)/src -I. -c -S $(CONFIG_MAINBOARD)/cache_as_ram_auto.c 
-o $@"
action "perl -e 's/\.rodata/.rom.data/g' -pi $@"
action "perl -e 's/\.text/.section .rom.text/g' -pi $@"
end
end

if CONFIG_USE_FAILOVER_IMAGE
else
if CONFIG_AP_CODE_IN_CAR
makerule ./apc_auto.o
depends "$(CONFIG_MAINBOARD)/apc_auto.c option_table.h"
action "$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) 
-I$(TOP)/src -I. -c $(CONFIG_MAINBOARD)/apc_auto.c -o $@"
end
end
end


##
## Build our 16 bit and 32 bit coreboot entry code
##
if CONFIG_HAVE_FAILOVER_BOOT
if CONFIG_USE_FAILOVER_IMAGE
mainboardinit cpu/x86/16bit/entry16.inc
ldscript /cpu/x86/16bit/entry16.lds
end
else
if CONFIG_USE_FALLBACK_IMAGE
mainboardinit cpu/x86/16bit/entry16.inc
ldscrip

Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+

[Myles Watson]

On Tue, Dec 22, 2009 at 11:38 AM, Knut Kujat  wrote:

>  Myles Watson escribió:
>
>
>
> On Tue, Dec 22, 2009 at 9:22 AM, Knut Kujat  wrote:
>
>> Hello,
>>
>> as Myles suggested to disable siblings to see if I can pass through this
>> weird exception and the impossibility  to do so because of the compile error
>> I changed the physical cpu option to 1 and it worked! But increasing it back
>> to 2 or 4 made the exception come back again.
>> I told you, Myles, I increased stack size to 4000 that was a filthy lie
>> because I thought I'm increasing it to 4000 what I didn't see was that the
>> same option was repeated at the end of the Options.lb file with
>> STACK_SIZE=8000
>>
> It's always good to check targets/vendor/board/build/fallback/ldoptions to
> see what's really being used.
>
>
>> (So I don't know  why the printks started working). Now fooling around
>> with stack size and setting it up to 1 all 4 cpus started working and I
>> got a grub menu :) in text mode :( so I have a graphics Initializing faild
>> and Linux doesn't boot up completly.
>>
> Great.  I think we're getting to where we should add your board to the
> tree.  Then we can see the device tree too.
>
> I attached it.
>
>
>
>> I attached a complete log file, it is not so complete because the first
>> lines of linux boot up are missing because I had to change serial speed on
>> minicom. Thats because I'm having trouble of setting a speed and getting a
>> total different one.
>>
>> Now I thing that my device tree is not completely working and thats why
>> linux got some collusion at the beginning ??
>>
> It device 0:02.3 isn't getting a driver.  1:06.0 is not found.
>
> PCI: 08:01.0 Hypertransport link capability not foundPCI: pci_scan_bus for
> bus 08
>
> That doesn't look good.
>
> PCI: Left over static devices:
> PCI: 08:01.0
> PCI: 08:01.1
> PCI: 08:02.0
>
>
>
>
>device pci_domain 0 on
>chip northbridge/amd/amdfam10 #mc0
>device pci 18.0 on end
>device pci 18.0 on end
>device pci 18.0 on  # SB on link 2.0
>
So it really is on link 2?  I forgot that these boards like to be different.


>chip southbridge/nvidia/mcp55
>device pci 0.0 on end   # HT
>device pci 1.0 on # LPC
>


>device pci 2.0 on end # USB 1.1
>device pci 2.1 on end # USB 2
>device pci 4.0 on end # IDE
>device pci 5.0 on end # SATA 0
>device pci 5.1 on end # SATA 1
>device pci 5.2 on end # SATA 2
>device pci 6.0 on  # PCI
>

This device should be removed.

>  device pci 6.0 on end
>


>
>end
>device pci 6.1 off end # AZA
>#device pci 8.0 on end # NIC
>#device pci 9.0 on end # NIC
>device pci a.0 on  end # PCI E 5
>#device pci 0.0 on #nec
> pci-x
>#end
>#device pci 0.1 on #nec
> pci-x
>#   device pci 4.0 on
> end #scsi
>#   device pci 4.1 on
> end #scsi
>#end
>#ind
>device pci b.0 on end # PCI E 4
>device pci c.0 on end # PCI E 3
>device pci d.0 on end # PCI E 2
>device pci e.0 on end # PCI E 1
>device pci f.0 on end # PCI E 0
>register "ide0_enable" = "1"
>register "sata0_enable" = "1"
>register "sata1_enable" = "1"
>register "mac_eeprom_smbus" = "3" #
> 1: smbus under 2e.8, 2: SM0 3: SM1
>register "mac_eeprom_addr" = "0x51"
>end
>end #  device pci 18.0
>device pci 18.1 on end
>device pci 18.2 on end
>device pci 18.3 on end
>device pci 18.4 on end
>device pci 19.0 on end
>  device pci 19.0 on end
>  device pci 19.0 on
>   chip southbridge/amd/amd8132
> 

Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+

[Myles Watson]

> This would be easier to do in a different editor and if it were indented
> correctly.  Is there a reason not to check it in?
>
Sorry.  I just noticed that it was my mail reader that inlined it, not you.

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

Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+

[Myles Watson]

Now I thing that my device tree is not completely working and thats why
> linux got some collusion at the beginning ?? And I have no idea why graphic
> mode doesn't work since it looks like it finds vga without any problem.
>

Scan for VGA option rom
Got ps2 nak (status=51); continuing
ps2_recvbyte timeout

I can't see your VGA ROM getting run anywhere.  Did I just miss it?

You could try having Coreboot run it with vm86 and with CONFIG_CONSOLE_VGA
set to see if that works.  I'm wondering why SeaBIOS isn't finding it.

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

Re: [coreboot] fam10/newconfig on supermicro h8dme - early hang

[Ward Vandewege]

On Fri, Dec 18, 2009 at 11:38:46AM -0700, Myles Watson wrote:
> I would check the early startup code for the remote nodes.  It looks like
> you hang right where it gets garbled for Knut.

Hmm, yeah. So I tried enabling just one core by setting

default CONFIG_MAX_PHYSICAL_CPUS=1
default CONFIG_MAX_CPUS=1 * CONFIG_MAX_PHYSICAL_CPUS
default CONFIG_LOGICAL_CPUS=1

and by adding a return at the very beginning of start_other_cores in 

  cpu/amd/quadcore/quadcore.c

which gets me a bit further, but not much. It hangs in the
mcp55_early_pcie_setup function in 

  southbridge/nvidia/mcp55/mcp55_early_setup_car.c

Log attached. Anything else I should try?

Thanks,
Ward.

-- 
Ward Vandewege 
Free Software Foundation - Senior Systems Administrator


minicom-20091222aa-all-ram-on-cpu1.cap
Description: application/cap
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [PATCH]tinybootblock

[Patrick Georgi]

Hi,

attached patch implements my tinybootblock concept (formerly known as
newfailover) in Kconfig. It's designed to be non-instrusive, so boards
will continue to build as usual unless they're changed to use the feature.
As a proof of concept (which I used for development), emulation/qemu-x86
is changed to tinybootblock, but other boards will require more changes,
so it not a complete example on how to convert a board.

Objectives of tinybootblock (when fully implemented):
- Fix Fam10 boards on Kconfig, which require >64kb for raminit. That
should help with replacing newconfig with kconfig completely.
newconfig requires the failover mechanism on those boards to work around
this limit, and this solves it similarily by splitting the code in a
top-64k block and "the rest".

- Use CBFS
The newconfig failover mechanism uses the pre-CBFS image layout
(cat(1)ing files together and relying on magic offsets to determine
entry points). CBFS provides a clean solution for that.

- Provide a framework to build image selection logic
In newconfig, most boards have their own code to select the image. The
goal in this layout is to have generic decision routines to take care of
that, and encourage their use.

- Push as much as possible out of the bootblock
The failover mechanism so far did CAR in the bootblock and raminit in
the later stage. With tinybootblock, CAR is supposed to end up outside
the bootblock. "Safe updates", once we provide them, will be able to
update CAR support for new CPU types, too.


Code flow in tinybootblock:
- 16bit reset vector (0xfff0)
- jump to 32bit mode
- Do whatever is necessary to have the entire ROM around (C code,
compiled with romcc)
- Look up fallback/romstage in CBFS (this can be extended with selection
logic if desired) ("selection logic" is C, compiled with romcc, lookup
is assembly)
- Fetch the entry point which is stored in the romstage's header
- Jump to the entry point. fallback/romstage is linked for the address
where it finally resides in the image, so it's execute in place.
- fallback/romstage is the original bootblock code (except for ROM
enable): Setup CAR if available, do raminit, call coreboot_ram


Current issues:
- No support for rom enable sequences yet. QEmu doesn't need them, but
they're what I do next.

- The bootblock isn't exactly tiny, it's 64kb. Most of it is empty (on
qemu, it's ~400 used bytes including id section and reset vector, ~350
byte for all code). To be done after rom enable works.

- There might be better places to push files to (both in the sources and
in the build tree)

- There's some problem with the various section types in ELF which I
worked around in cbfstool: If the section starts earlier than the
desired load address, strip the bytes before the load address. This is
no problem in automatic operation but can have lead to mistakes in
manual operation.


Future developments:
- At some point we might want to have various variants of the bootblock:
Unconditionally loading a given romstage (what we have now), selecting
between fallback/normal by CMOS (as in newconfig), enabling a rescue
flash routine on GPIO, etc.


As mentioned, ROM enable support is still missing. Once this is done,
tinybootblock should be useful for a broader audience (eg. to port
boards), but I wanted to get the current state out now, as it finally works.

Signed-off-by: Patrick Georgi 
Index: src/cpu/x86/32bit/entry32.lds
===
--- src/cpu/x86/32bit/entry32.lds   (revision 4988)
+++ src/cpu/x86/32bit/entry32.lds   (working copy)
@@ -0,0 +1 @@
+ENTRY(protected_start)
Index: src/mainboard/emulation/qemu-x86/Kconfig
===
--- src/mainboard/emulation/qemu-x86/Kconfig(revision 4988)
+++ src/mainboard/emulation/qemu-x86/Kconfig(working copy)
@@ -26,3 +26,8 @@
bool
default n
depends on BOARD_EMULATION_QEMU_X86
+
+config TINY_BOOTBLOCK
+   bool
+   default y
+   depends on BOARD_EMULATION_QEMU_X86
Index: src/mainboard/emulation/qemu-x86/Makefile.inc
===
--- src/mainboard/emulation/qemu-x86/Makefile.inc   (revision 4988)
+++ src/mainboard/emulation/qemu-x86/Makefile.inc   (working copy)
@@ -1,18 +1,12 @@
 initobj-y += crt0.o
-crt0-y += ../../../../src/cpu/x86/16bit/entry16.inc
 crt0-y += ../../../../src/cpu/x86/32bit/entry32.inc
-crt0-y += ../../../../src/cpu/x86/16bit/reset16.inc
-crt0-y += ../../../../src/arch/i386/lib/id.inc
 crt0-y += auto.inc
 
 obj-y += mainboard.o
 obj-$(CONFIG_GENERATE_PIRQ_TABLE) += irq_tables.o
 
 ldscript-y += ../../../../src/arch/i386/init/ldscript_fallback_cbfs.lb
-ldscript-y += ../../../../src/cpu/x86/16bit/entry16.lds
 ldscript-y += ../../../../src/cpu/x86/32bit/entry32.lds
-ldscript-y += ../../../../src/cpu/x86/16bit/reset16.lds
-ldscript-y += ../../../../src/arch/i386/lib/id.lds
 
 ifdef POST_EVALUATION
 

Re: [coreboot] fam10/newconfig on supermicro h8dme - early hang

[Myles Watson]

> On Fri, Dec 18, 2009 at 11:38:46AM -0700, Myles Watson wrote:
> > I would check the early startup code for the remote nodes.  It looks
> like
> > you hang right where it gets garbled for Knut.
> 
> Hmm, yeah. So I tried enabling just one core by setting
> 
> default CONFIG_MAX_PHYSICAL_CPUS=1
> default CONFIG_MAX_CPUS=1 * CONFIG_MAX_PHYSICAL_CPUS
> default CONFIG_LOGICAL_CPUS=1
I think you need to set CONFIG_LOGICAL_CPUS=0 to disable the siblings.  I
got it to compile by moving the nb_ function it can't find into the #endif
above it.

* AP 02 didn't start timeout:0001
* AP 03 didn't start timeout:0001


Begin FIDVID MSR 0xc0010071 0x30ae00a3 0x40034c40 
FIDVID on BSP, APIC_id: 00
BSP fid = 10600
Wait for AP stage 1: ap_apicid = 1
fidvid_bsp_stage1: time out while reading from ap 01
Wait for AP stage 1: ap_apicid = 2
fidvid_bsp_stage1: time out while reading from ap 02
Wait for AP stage 1: ap_apicid = 3

It's still trying to start the APs.

> and by adding a return at the very beginning of start_other_cores in
> 
>   cpu/amd/quadcore/quadcore.c
> 
> which gets me a bit further, but not much. It hangs in the
> mcp55_early_pcie_setup function in
> 
>   southbridge/nvidia/mcp55/mcp55_early_setup_car.c
> 
> Log attached. Anything else I should try?

If inl and outl are hanging, I would dump the routing registers and read the
device's IDs to see what's going wrong.  I'm not very familiar with how the
fam10 code works, but dumping the routing registers should be mostly cut and
paste from the k8/util.c code.

Thanks,
Myles


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

Re: [coreboot] [PATCH]tinybootblock

[Patrick Georgi]

Hi again,

It was brought to my attention that svn didn't track the file copies in
the diff. The following copies are necessary:
cp src/arch/i386/init/crt0.S.lb src/arch/i386/init/bootblock_prologue.c
cp src/arch/i386/Makefile.inc src/arch/i386/Makefile.tinybootblock.inc
cp src/arch/i386/Makefile.inc src/arch/i386/Makefile.bigbootblock.inc

Then, the patch will work.

I'm sorry for the trouble,
Patrick

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

Re: [coreboot] [PATCH]tinybootblock

[Myles Watson]

On Tue, Dec 22, 2009 at 2:27 PM, Patrick Georgi wrote:

>
> - Provide a framework to build image selection logic
> In newconfig, most boards have their own code to select the image. The
> goal in this layout is to have generic decision routines to take care of
> that, and encourage their use.
>
Is it possible to have it be generic?  Won't we have to unify CMOS layouts
for that to happen?


> - Push as much as possible out of the bootblock
> The failover mechanism so far did CAR in the bootblock and raminit in
> the later stage. With tinybootblock, CAR is supposed to end up outside
> the bootblock. "Safe updates", once we provide them, will be able to
> update CAR support for new CPU types, too.
>
>
> Code flow in tinybootblock:
> - 16bit reset vector (0xfff0)
> - jump to 32bit mode
> - Do whatever is necessary to have the entire ROM around (C code,
> compiled with romcc)
>
I think it would be a mistake to bring romcc to targets that don't need it
now.


> - Look up fallback/romstage in CBFS (this can be extended with selection
> logic if desired) ("selection logic" is C, compiled with romcc, lookup
> is assembly)
>
It's more important to me to avoid assembly than to have the absolute
minimum size bootblock.  Especially for K8 & Fam10, there's plenty of space
to not have to do this.

Picky detail:
Since CONFIG_TINY_BOOTBLOCK is referenced in a Makefile that isn't board
specific, the Kconfig entry for it should go there too (with a default n).
There should just be a "select" in qemu-x86/Kconfig


> Signed-off-by: Patrick Georgi 
>

I think it's a good start, and since it doesn't break anything until it's
used...

Acked-by: Myles Watson 
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] fam10/newconfig on supermicro h8dme - early hang

[Ward Vandewege]

On Tue, Dec 22, 2009 at 02:30:21PM -0700, Myles Watson wrote:
> 
> > On Fri, Dec 18, 2009 at 11:38:46AM -0700, Myles Watson wrote:
> > > I would check the early startup code for the remote nodes.  It looks
> > like
> > > you hang right where it gets garbled for Knut.
> > 
> > Hmm, yeah. So I tried enabling just one core by setting
> > 
> > default CONFIG_MAX_PHYSICAL_CPUS=1
> > default CONFIG_MAX_CPUS=1 * CONFIG_MAX_PHYSICAL_CPUS
> > default CONFIG_LOGICAL_CPUS=1
> I think you need to set CONFIG_LOGICAL_CPUS=0 to disable the siblings.  I
> got it to compile by moving the nb_ function it can't find into the #endif
> above it.
> 
> * AP 02 didn't start timeout:0001
> * AP 03 didn't start timeout:0001
> 
> 
> Begin FIDVID MSR 0xc0010071 0x30ae00a3 0x40034c40 
> FIDVID on BSP, APIC_id: 00
> BSP fid = 10600
> Wait for AP stage 1: ap_apicid = 1
> fidvid_bsp_stage1: time out while reading from ap 01
> Wait for AP stage 1: ap_apicid = 2
> fidvid_bsp_stage1: time out while reading from ap 02
> Wait for AP stage 1: ap_apicid = 3
> 
> It's still trying to start the APs.

Right. Setting CONFIG_LOGICAL_CPUS to zero and making sure that conditional
on CONFIG_LOGICAL_CPUS at the top of northbridge.c does not apply fixed that.

Should this go into the tree?

--- northbridge/amd/amdfam10/northbridge.c (revision 4978)
+++ northbridge/amd/amdfam10/northbridge.c (working copy)
@@ -31,10 +31,10 @@
 
 #include 
 
-#if CONFIG_LOGICAL_CPUS==1
 #include 
 #include 
-#endif
 
 #include "chip.h"
 #include "root_complex/chip.h"

> > and by adding a return at the very beginning of start_other_cores in
> > 
> >   cpu/amd/quadcore/quadcore.c
> > 
> > which gets me a bit further, but not much. It hangs in the
> > mcp55_early_pcie_setup function in
> > 
> >   southbridge/nvidia/mcp55/mcp55_early_setup_car.c
> > 
> > Log attached. Anything else I should try?
> 
> If inl and outl are hanging, I would dump the routing registers and read the
> device's IDs to see what's going wrong.  I'm not very familiar with how the
> fam10 code works, but dumping the routing registers should be mostly cut and
> paste from the k8/util.c code.

Right. I've done that - log attached. I'm dumping with

showallroutes(BIOS_DEBUG, PCI_DEV(0, 0x18, 1));

I'm not sure what to make of the dump though (attached).

Thanks,
Ward.
 
-- 
Ward Vandewege 
Free Software Foundation - Senior Systems Administrator


minicom-20091222ad-ram-on-both-cpus.cap
Description: application/cap
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] fam10/newconfig on supermicro h8dme - early hang

[Myles Watson]

> Right. Setting CONFIG_LOGICAL_CPUS to zero and making sure that
> conditional
> on CONFIG_LOGICAL_CPUS at the top of northbridge.c does not apply fixed
> that.
> 
> Should this go into the tree?
> 
> --- northbridge/amd/amdfam10/northbridge.c (revision 4978)
> +++ northbridge/amd/amdfam10/northbridge.c (working copy)
> @@ -31,10 +31,10 @@
> 
>  #include 
> 
> -#if CONFIG_LOGICAL_CPUS==1
>  #include 
>  #include 
> -#endif
> 
>  #include "chip.h"
>  #include "root_complex/chip.h"

I like just moving the endif to protect nb_cfg_54, if it would work.  It
compiles for me.

--- northbridge/amd/amdfam10/northbridge.c (revision 4978)
+++ northbridge/amd/amdfam10/northbridge.c (working copy)
@@ -1235,7 +1235,6 @@
disable_siblings = !CONFIG_LOGICAL_CPUS;
 #if CONFIG_LOGICAL_CPUS == 1
get_option(&disable_siblings, "quad_core");
-#endif
 
// for pre_e0, nb_cfg_54 can not be set, ( even set, when you read
it
//still be 0)
@@ -1243,6 +1242,7 @@
//and differ d0 and e0 single core
 
nb_cfg_54 = read_nb_cfg_54();
+#endif
 
 #if CONFIG_CBB
dev_mc = dev_find_slot(0, PCI_DEVFN(CONFIG_CDB, 0)); //0x00


> 
> > > and by adding a return at the very beginning of start_other_cores in
> > >
> > >   cpu/amd/quadcore/quadcore.c
> > >
> > > which gets me a bit further, but not much. It hangs in the
> > > mcp55_early_pcie_setup function in
> > >
> > >   southbridge/nvidia/mcp55/mcp55_early_setup_car.c
> > >
> > > Log attached. Anything else I should try?
> >
> > If inl and outl are hanging, I would dump the routing registers and read
> the
> > device's IDs to see what's going wrong.  I'm not very familiar with how
> the
> > fam10 code works, but dumping the routing registers should be mostly cut
> and
> > paste from the k8/util.c code.
> 
> Right. I've done that - log attached. I'm dumping with
> 
> showallroutes(BIOS_DEBUG, PCI_DEV(0, 0x18, 1));
> 
> I'm not sure what to make of the dump though (attached).
MMIO(b8)00-31a4f2, ->(0,1), , , CPU disable 0, Lock 0, Non
posted 0

This is broken, but I'm not sure if it's the dump or the register value.  It
shouldn't affect the IO, though.  That register looked fine.  It seems like
IO is broken for you not to be able to start the other processors or
complete the mcp55 init.

You could print out PCI_DEV(0,0x18,0) @ 0x6C to make sure that the lower
bits are what you expect.  The ones I'd look at are the default link (bits
11,3,2), disable routing bit (bit 0).

The default link should be 2.  The disable routing bit can tell you if it's
important that the routing registers are messed up.

Thanks,
Myles


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

Re: [coreboot] fam10/newconfig on supermicro h8dme - early hang

[Ward Vandewege]

On Tue, Dec 22, 2009 at 04:11:06PM -0700, Myles Watson wrote:
> > Right. Setting CONFIG_LOGICAL_CPUS to zero and making sure that
> > conditional
> > on CONFIG_LOGICAL_CPUS at the top of northbridge.c does not apply fixed
> > that.
> > 
> > Should this go into the tree?
> > 
> > --- northbridge/amd/amdfam10/northbridge.c (revision 4978)
> > +++ northbridge/amd/amdfam10/northbridge.c (working copy)
> > @@ -31,10 +31,10 @@
> > 
> >  #include 
> > 
> > -#if CONFIG_LOGICAL_CPUS==1
> >  #include 
> >  #include 
> > -#endif
> > 
> >  #include "chip.h"
> >  #include "root_complex/chip.h"
> 
> I like just moving the endif to protect nb_cfg_54, if it would work.  It
> compiles for me.
> 
> --- northbridge/amd/amdfam10/northbridge.c (revision 4978)
> +++ northbridge/amd/amdfam10/northbridge.c (working copy)
> @@ -1235,7 +1235,6 @@
>   disable_siblings = !CONFIG_LOGICAL_CPUS;
>  #if CONFIG_LOGICAL_CPUS == 1
>   get_option(&disable_siblings, "quad_core");
> -#endif
>  
>   // for pre_e0, nb_cfg_54 can not be set, ( even set, when you read
> it
>   //still be 0)
> @@ -1243,6 +1242,7 @@
>   //and differ d0 and e0 single core
>  
>   nb_cfg_54 = read_nb_cfg_54();
> +#endif
>  
>  #if CONFIG_CBB
>   dev_mc = dev_find_slot(0, PCI_DEVFN(CONFIG_CDB, 0)); //0x00

OK - with that patch it builds and boots, and the output looks similar (but
not identical. See

  
http://ward.vandewege.net/coreboot/h8dme/fam10/minicom-20091222af-ram-on-both-cpus.cap

The only difference is this

-MMIO(b8)00-31a4f2, ->(0,1), , , CPU disable 0, Lock 0, Non
posted 0
+MMIO(b8)00-31a6b2, ->(0,1), , , CPU disable 0, Lock 0, Non
posted 1

which may be entirely unrelated?

I'll look at that other register tomorrow.

Thanks!
Ward.

-- 
Ward Vandewege 
Free Software Foundation - Senior Systems Administrator

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

Re: [coreboot] [PATCH]tinybootblock

[ron minnich]

Sweet!

Acked-by: Ronald G. Minnich 

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