Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
Myles Watson escribió: On Mon, Dec 21, 2009 at 9:15 AM, Knut Kujat kn...@gap.upv.es mailto:kn...@gap.upv.es wrote: Myles Watson escribió: On Mon, Dec 21, 2009 at 3:27 AM, Knut Kujat kn...@gap.upv.es mailto:kn...@gap.upv.es 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
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.
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 librali1...@gmail.com
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 marcj...@gmail.com
On Mon, Dec 21, 2009 at 6:15 PM, Libra Li librali1...@gmail.com 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 libra...@technexion.com
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 libra...@technexion.com
+ *
+ * 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(unsigned long bist, unsigned long
Re: [coreboot] Coreboot Support for MSI Board MS-6702E
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
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
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 paulepan...@users.sourceforge.net 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+
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 cpu/amd/quadcore.h #include pc80/mc146818rtc.h #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 w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] arima irq issues
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
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+
On Tue, Dec 22, 2009 at 9:22 AM, Knut Kujat kn...@gap.upv.es 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+
Myles Watson escribió: On Tue, Dec 22, 2009 at 9:22 AM, Knut Kujat kn...@gap.upv.es mailto:kn...@gap.upv.es 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 yingha...@amd.com 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 ldscript /cpu/x86/16bit/entry16.lds end end
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
On Tue, Dec 22, 2009 at 11:38 AM, Knut Kujat kn...@gap.upv.es wrote: Myles Watson escribió: On Tue, Dec 22, 2009 at 9:22 AM, Knut Kujat kn...@gap.upv.es 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 device pci 1.0 on end device pci 1.1 on end
Re: [coreboot] Problems porting H8dmr_fam10 to H8qme-2+
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+
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
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 w...@fsf.org 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
Re: [coreboot] fam10/newconfig on supermicro h8dme - early hang
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
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] fam10/newconfig on supermicro h8dme - early hang
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 cpu/x86/lapic.h -#if CONFIG_LOGICAL_CPUS==1 #include cpu/amd/quadcore.h #include pc80/mc146818rtc.h -#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 w...@fsf.org 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
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 cpu/x86/lapic.h -#if CONFIG_LOGICAL_CPUS==1 #include cpu/amd/quadcore.h #include pc80/mc146818rtc.h -#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
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 cpu/x86/lapic.h -#if CONFIG_LOGICAL_CPUS==1 #include cpu/amd/quadcore.h #include pc80/mc146818rtc.h -#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 w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [PATCH]tinybootblock
Sweet! Acked-by: Ronald G. Minnich rminn...@gmail.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
