coreboot September 2006

coreboot@coreboot.org

52 participants
173 discussions

Re: [LinuxBIOS] DK8-HTX hangs on boot
by ron minnich 12 Sep '06

12 Sep '06

On 9/11/06, Chris Stillo <Chris.Stillo(a)celoxica.com> wrote: > > > Here's the detailed dump... Dies at "Copying LinuxBIOS to ram. " It's memory.When it fails here, it is memory about 99.99999% of the time :-) Which is odd, this is a very vanilla chipset. What's your memory? ron

1 0

Re: [LinuxBIOS] DK8-HTX hangs on boot
by yhlu 12 Sep '06

12 Sep '06

Can you use serengeti_leopard to build one image and test on you MB? YH On 9/11/06, Chris Stillo <Chris.Stillo(a)celoxica.com> wrote: > > Here's the detailed dump... Dies at "Copying LinuxBIOS to ram. " > > Anyone have any ideas? > > Thanks, > Chris > > -------------------------------------------------------------------- > > LinuxBIOS-2.0.0_Fallback Tue Sep 12 17:21:39 CDT 2006 starting... > A > B > (0,1) link=01 > (1,0) link=01 > 02 nodes initialized. > C > D > ht reset - > E > > dimm: 00.0: 50 > 00: 80 08 07 0d 0b 02 48 00 04 50 65 02 82 08 08 01 > 10: 0e 04 18 01 02 26 c0 60 70 00 00 3c 28 3c 28 80 > 20: 60 60 40 40 00 00 00 00 00 37 46 28 28 50 64 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 3b > 40: 7f 98 00 00 00 00 00 00 04 4b 00 00 00 00 00 00 > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 05 02 a4 > 60: 14 03 6c 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > dimm: 00.1: 51 > 00: 80 08 07 0d 0b 02 48 00 04 50 65 02 82 08 08 01 > 10: 0e 04 18 01 02 26 c0 60 70 00 00 3c 28 3c 28 80 > 20: 60 60 40 40 00 00 00 00 00 37 46 28 28 50 64 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 3b > 40: 7f 98 00 00 00 00 00 00 04 4b 00 00 00 00 00 00 > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 05 02 a4 > 60: 14 76 15 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > dimm: 01.0: 52 > 00: > dimm: 01.1: 53 > 00: > F > G > Ram1.00 > Ram1.01 > Ram2.00 > Ram2.01 > Ram3 > Initializing memory: done > Initializing memory: done > Clearing initial memory region: done > Ram4 > H > PCI: 00:18.02 > 00: 22 10 02 11 00 00 00 00 00 00 00 06 00 00 80 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 40: 01 00 00 00 01 20 00 00 00 00 00 00 00 00 00 00 > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 60: 00 de e0 07 00 de e0 07 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 80: 07 00 00 00 00 00 00 00 42 35 82 13 20 0b 10 00 > 90: 00 8c 03 08 08 0a 7b 06 00 00 00 00 12 0f 02 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: cd ef a1 39 00 00 00 00 60 9f 08 9b 8c ae 81 9f > c0: 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 96 9e 10 b4 20 01 90 23 10 a5 48 16 c5 80 01 48 > e0: 94 4b 02 89 28 24 90 05 08 81 40 00 50 07 01 21 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > J > K > Copying LinuxBIOS to ram. > > -----Original Message----- > From: Richard Smith [mailto:smithbone@gmail.com] > Sent: Monday, September 11, 2006 9:26 PM > To: ron minnich > Cc: Chris Stillo; David Gardner; linuxbios(a)linuxbios.org > Subject: Re: [LinuxBIOS] DK8-HTX hangs on boot > > > p.s. shameless plug. If you want to bring that board to Hamburg oct. 1 > > > we're going to be doing lots of linuxbios hacking at the linuxbios > > summit -- you'll have a LOT of experts in the room ready to help. > > That said. Is anyone bringing a via epia with a vt8601 on it? Perhpas > we can figure that out while we are there. > > -- > Richard A. Smith > > _____________________________________________________________________ > This incoming message has been checked for all known viruses by the > Messagelabs Scanning System, on behalf of Celoxica Ltd. > > > > _____________________________________________________________________ > This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd. > > This email and any files transmitted with it are confidential and > may be legally privileged. It is intended solely for the use of the > individual or entity to whom it is addressed. If you have received > this in error, please contact the sender and delete the material > immediately. Whilst this email has been swept for viruses, you > should carry out your own virus check before opening any > attachment. Celoxica Ltd accepts no liability for any loss or > damage which may be caused by software viruses or interception > or interruption of this email. > > -- > linuxbios mailing list > linuxbios(a)linuxbios.org > http://www.openbios.org/mailman/listinfo/linuxbios >

1 0

Re: [LinuxBIOS] DK8-HTX hangs on boot
by Richard Smith 12 Sep '06

12 Sep '06

On 9/11/06, Chris Stillo <Chris.Stillo(a)celoxica.com> wrote: > > Here's the detailed dump... Dies at "Copying LinuxBIOS to ram. " > > Anyone have any ideas? > Enable the sanity ram test and see if your RAM is functional. Got to the bottom of auto.c and add ram_check(0x100000,0x400000); And see if you get any errors. -- Richard A. Smith

1 0

Re: [LinuxBIOS] DK8-HTX hangs on boot
by Chris Stillo 12 Sep '06

12 Sep '06

Here's the detailed dump... Dies at "Copying LinuxBIOS to ram. " Anyone have any ideas? Thanks, Chris -------------------------------------------------------------------- LinuxBIOS-2.0.0_Fallback Tue Sep 12 17:21:39 CDT 2006 starting... A B (0,1) link=01 (1,0) link=01 02 nodes initialized. C D ht reset - E dimm: 00.0: 50 00: 80 08 07 0d 0b 02 48 00 04 50 65 02 82 08 08 01 10: 0e 04 18 01 02 26 c0 60 70 00 00 3c 28 3c 28 80 20: 60 60 40 40 00 00 00 00 00 37 46 28 28 50 64 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 3b 40: 7f 98 00 00 00 00 00 00 04 4b 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 05 02 a4 60: 14 03 6c 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dimm: 00.1: 51 00: 80 08 07 0d 0b 02 48 00 04 50 65 02 82 08 08 01 10: 0e 04 18 01 02 26 c0 60 70 00 00 3c 28 3c 28 80 20: 60 60 40 40 00 00 00 00 00 37 46 28 28 50 64 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 3b 40: 7f 98 00 00 00 00 00 00 04 4b 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 05 02 a4 60: 14 76 15 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dimm: 01.0: 52 00: dimm: 01.1: 53 00: F G Ram1.00 Ram1.01 Ram2.00 Ram2.01 Ram3 Initializing memory: done Initializing memory: done Clearing initial memory region: done Ram4 H PCI: 00:18.02 00: 22 10 02 11 00 00 00 00 00 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 01 00 00 00 01 20 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 de e0 07 00 de e0 07 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 07 00 00 00 00 00 00 00 42 35 82 13 20 0b 10 00 90: 00 8c 03 08 08 0a 7b 06 00 00 00 00 12 0f 02 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: cd ef a1 39 00 00 00 00 60 9f 08 9b 8c ae 81 9f c0: 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 96 9e 10 b4 20 01 90 23 10 a5 48 16 c5 80 01 48 e0: 94 4b 02 89 28 24 90 05 08 81 40 00 50 07 01 21 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 J K Copying LinuxBIOS to ram. -----Original Message----- From: Richard Smith [mailto:smithbone@gmail.com] Sent: Monday, September 11, 2006 9:26 PM To: ron minnich Cc: Chris Stillo; David Gardner; linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] DK8-HTX hangs on boot > p.s. shameless plug. If you want to bring that board to Hamburg oct. 1 > we're going to be doing lots of linuxbios hacking at the linuxbios > summit -- you'll have a LOT of experts in the room ready to help. That said. Is anyone bringing a via epia with a vt8601 on it? Perhpas we can figure that out while we are there. -- Richard A. Smith _____________________________________________________________________ This incoming message has been checked for all known viruses by the Messagelabs Scanning System, on behalf of Celoxica Ltd. _____________________________________________________________________ This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd. This email and any files transmitted with it are confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed. If you have received this in error, please contact the sender and delete the material immediately. Whilst this email has been swept for viruses, you should carry out your own virus check before opening any attachment. Celoxica Ltd accepts no liability for any loss or damage which may be caused by software viruses or interception or interruption of this email.

1 0

Re: [LinuxBIOS] DK8-HTX hangs on boot
by ron minnich 12 Sep '06

12 Sep '06

What you can do. In the Config.lb, set MAXIMUM_CONSOLE_LOG_LEVEL=8 DEFAULT_CONSOLE_LOG_LEVEL=8 then see what gets printed. ALL output goes to serial. thanks ron p.s. shameless plug. If you want to bring that board to Hamburg oct. 1 we're going to be doing lots of linuxbios hacking at the linuxbios summit -- you'll have a LOT of experts in the room ready to help.

2 1

[LinuxBIOS] DK8-HTX hangs on boot
by Chris Stillo 12 Sep '06

12 Sep '06

Hello, I'm having a problem with LinuxBIOS on the DK8-HTX getting hung. The dump from the serial port is show below. Is all the info piped to the serial port, or do I need to look at the VGA output. LinuxBIOS-2.0.0_Fallback Thu Aug 10 08:57:57 CDT 2006 starting... A B C D ht reset - E F G H J K Any ideas where it is hanging up? Thanks, Chris _____________________________________________________________________ This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd. This email and any files transmitted with it are confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed. If you have received this in error, please contact the sender and delete the material immediately. Whilst this email has been swept for viruses, you should carry out your own virus check before opening any attachment. Celoxica Ltd accepts no liability for any loss or damage which may be caused by software viruses or interception or interruption of this email.

1 0

[LinuxBIOS] romcc manpage.
by Uwe Hermann 10 Sep '06

10 Sep '06

Hi, here's a preliminary manpage for romcc. Some details need to be added, e.g. the author, the extact license, bug-report address etc. Who wrote romcc, and which license applies? There's a COPYING file in the directory, so it's probably the GPL. Version 2 or v2 and later? Btw, is romcc still maintained? The romcc.c file says RELEASE_DATE "15 November 2004". Also, the test-suite doesn't build for me (I simply typed 'make'): [...] <built-in>:1.0: simple_test26.c:20.26: warning: used: %mm7 <built-in>:1.0: simple_test26.c:20.26: too few registers make: *** [tests/simple_test26.S-O2-mmmx] Error 1 Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org

4 7

[LinuxBIOS] epia memory issues
by Ben Hewson 10 Sep '06

10 Sep '06

ok I after many attempts I think I am making some progress, but not to sure why at the moment. I will need to go back over the changes I have made and see if it is any one thing that has made it work. The memory check passes up until A0000. I am assuming as this is resrvered for the VGA controller it is to be expected. I have compared northbridge register dumps of both my epia boards, rev A and D but can see no difference, so I don't think there have not been any changes to the northbridge. One difference between original bios and linuxbios is register 0x67. According to the datasheet it is reserved. However booting with the original bios this register contains 0xc4 and 0x00 with linuxbios. I am currently setting it to 0xc4 but not sure yet if that is why I have some success. I have made a few changes, while comparing the V2 to V1. Anyway I am now getting as far as running filo but have another problem. This is what I get Setting fixed MTRRs(0-88) type: UC Setting fixed MTRRs(0-88) Type: WB DONE fixed MTRRs call enable_fixed_mtrr() Setting variable MTRR 0, base: 0MB, range: 256MB, type WB ADDRESS_MASK_HIGH=0xf Unexpected Exception: 13 @ 10:00008891 - Halting Code: 0 eflags: 00010006 eax: 00000300 ebx: f0000800 ecx: 0000da00 edx: 0000000a edi: 0000da00 esi: 0000000f ebp: 00017ee0 esp: 00017ebc Perhaps someone could explain this to me. By booting from the original bios and resetting mid-boot and switching to linuxbios filo has got to the stage of looking for my kernel image although it couldn't find it (maybe bad typing on my part).

4 4

Re: [LinuxBIOS] (fwd) Re: USB bootloader
by yhlu 10 Sep '06

10 Sep '06

http://www.linuxbios.org/index.php/Etherboot YH On 9/9/06, Al Boldi <a1426z(a)gawab.com> wrote: > yhlu wrote: > > you need to use filo.zelf > > same reboot with filo.zelf. > > See attached Config, compiled with gcc4.0.1 RHEL4 > > > Thanks! > > -- > Al > > > On 9/8/06, Al Boldi <a1426z(a)gawab.com> wrote: > > > yhlu wrote: > > > > did you try filo on Etherboot? > > > > > > > > I remember I first tried out on UHCI, and then added OHCI support. > > > > > > Yes, but filo.zlilo on etherboot5.4.2 just reboots on initial loading. > > > > > > Filo 0.5 from openbios.org works fine with ide but not usb. > > > > > > Also, the i440bx board has a UHCI controller. > > > > > > > > > Thanks for looking into this! > > > > > > -- > > > Al > > > > > > > YH > > > > > > > > On 9/7/06, Stefan Reinauer <stepan(a)coresystems.de> wrote: > > > > > Hi, > > > > > > > > > > anyone has an idea on this one? > > > > > > > > > > ----- Forwarded message from Al Boldi ----- > > > > > > > > > > Date: Thu, 7 Sep 2006 13:52:28 +0300 > > > > > From: Al Boldi <a1426z(a)gawab.com> > > > > > To: Stefan Reinauer <stepan(a)coresystems.de> > > > > > Cc: openbios(a)lists.openbios.org, > > > > > etherboot-discuss(a)lists.sourceforge.net Subject: Re: USB bootloader > > > > > > > > > > > > > > > Thanks for your response! > > > > > > > > > > Stefan Reinauer wrote: > > > > > > * Al Boldi <a1426z(a)gawab.com> [060904 20:58]: > > > > > > > FILO version 0.5 .... > > > > > > > Can't get memory map from firmware. Using hardcoded default. > > > > > > > Press ... > > > > > > > boot: uda1:/vmlinuz > > > > > > > LinuxLabs USB bootloader > > > > > > > New USB device, setting address 2 (repeats 1-4 times) > > > > > > > boot: uda1:/vmlinuz > > > > > > > LinuxLabs USB bootloader > > > > > > > Out of heap space > > > > > > > > > > > > Please try increasing the heap space in i386/ldscript by changing > > > > > > the following lines: > > > > > > /* 16KB heap and stack */ > > > > > > HEAP_SIZE = 16384; > > > > > > to > > > > > > /* 32KB heap and 16K stack */ > > > > > > HEAP_SIZE = 32768; > > > > > > > > > > > > > And, how can filo 0.5 be fixed to boot USB? > > > > > > > > > > > > If the message stays, try all the way up to 262144. > > > > > > > > > > Ok, the message is gone, but it still does not boot. > > > > > > > > > > Turning on debug repeats this: > > > > > > > > > > FILO version 0.5 (root@localhost) Thu Sep 7 13:40:13 AST 2006 > > > > > collect_sys_info: boot eax = 0x0 > > > > > collect_sys_info: boot ebx = 0x0 > > > > > collect_sys_info: boot arg = 0xfeee330 > > > > > collect_elfboot_info: Bootloader: Etherboot > > > > > collect_elfboot_info: Version: 5.4.1 > > > > > malloc_diag: alloc: 0 bytes (0 blocks), free: 262136 bytes (1 > > > > > blocks) malloc_diag: alloc: 16 bytes (1 blocks), free: 262120 bytes > > > > > (1 blocks) collect_elfboot_info: Image name: > > > > > /tftpboot/boot/pxelinux.0 malloc_diag: alloc: 32 bytes (2 blocks), > > > > > free: 262104 bytes (1 blocks) collect_linuxbios_info: Searching for > > > > > LinuxBIOS tables... > > > > > Can't get memory map from firmware. Using hardcoded default. > > > > > malloc_diag: alloc: 72 bytes (3 blocks), free: 262064 bytes (1 > > > > > blocks) collect_sys_info: 0000000000000000-00000000000a0000 > > > > > collect_sys_info: 0000000000100000-0000000002000000 > > > > > collect_sys_info: RAM 32 MB > > > > > relocate: Current location: 0x100000-0x16d827 > > > > > relocate: Relocating to 0x1f927d0-0x1fffff7... ok > > > > > setup_timers: CPU 413 MHz > > > > > pci_init: Scanning PCI: found 9 devices > > > > > malloc_diag: alloc: 192 bytes (4 blocks), free: 261944 bytes (1 > > > > > blocks) pci_init: 00:00.0 8086:7120 0600 00 > > > > > pci_init: 00:01.0 8086:7121 0300 00 > > > > > pci_init: 00:1e.0 8086:2418 0604 00 > > > > > pci_init: 01:04.0 1282:9102 0200 00 > > > > > pci_init: 01:05.0 10ec:8139 0200 00 > > > > > pci_init: 01:0a.0 1191:8040 0100 00 > > > > > pci_init: 00:1f.0 8086:2410 0601 00 > > > > > pci_init: 00:1f.1 8086:2411 0101 80 > > > > > pci_init: 00:1f.2 8086:2412 0c03 00 > > > > > > > > > > boot: uda1:/vmlinuz > > > > > malloc_diag: alloc: 216 bytes (5 blocks), free: 261920 bytes (1 > > > > > blocks) malloc_diag: alloc: 232 bytes (6 blocks), free: 261904 bytes > > > > > (1 blocks) file_open: dev=uda1, path=/vmlinuz > > > > > LinuxLabs USB bootloader > > > > > uhc_init: Found UHCI at ffffd000 > > > > > uhc_reset: Resetting UHCI > > > > > uhc_init: uhc_init setting framelist to: 01e927d0 > > > > > uhc_start: Starting UHCI > > > > > dump_uhci: HCI at ffffd000 > > > > > malloc_diag: alloc: 8432 bytes (7 blocks), free: 253704 bytes (1 > > > > > blocks) init_framelist: frame_list is at 12a000 > > > > > dump_link: frame_list_link: addr: 00125850 > > > > > dump_link: frame_list_link: raw addr: 1fb8020 > > > > > dump_link: frame_list_link: terminate: 0 > > > > > dump_link: frame_list_link: queue: 1 > > > > > dump_link: frame_list_link: depth: 0 > > > > > malloc_diag: alloc: 11512 bytes (8 blocks), free: 250624 bytes (1 > > > > > blocks) poll_usb: poll_usb1 i=0 poll_u_root_hub1 v=00001083 > > > > > poll_u_root_hub2 v=00001083 poll_u_root_hub21 v=00001083 > > > > > Connection on port d010 New USB device, setting address 2 > > > > > uhci_control_msg: uhci_control_msg: request_type = 0 request = 5 > > > > > wLength=0 malloc_diag: alloc: 15616 bytes (9 blocks), free: 246520 > > > > > bytes (1 blocks) dump_uhci: HCI at ffffd000 > > > > > dump_td: failed_transaction: TD(0011d860): > > > > > dump_td: failed_transaction: type: SETUP > > > > > dump_td: failed_transaction: retries: 3 > > > > > dump_td: failed_transaction: IOC > > > > > dump_td: failed_transaction: active: 0001 > > > > > dump_td: failed_transaction: device_addr: 00 > > > > > dump_td: failed_transaction: endpoint: 0 > > > > > dump_td: failed_transaction: data_toggle: 0 > > > > > dump_td: failed_transaction: max_transfer: 7 > > > > > dump_td: failed_transaction: actual: 0 > > > > > dump_td: failed_transaction: link: > > > > > dump_link: failed_transaction: addr: 0011d880 > > > > > dump_link: failed_transaction: raw addr: 1fb0050 > > > > > dump_link: failed_transaction: terminate: 0 > > > > > dump_link: failed_transaction: queue: 0 > > > > > dump_link: failed_transaction: depth: 0 > > > > > dump_td: failed_transaction: TD(0011d880): > > > > > dump_td: failed_transaction: type: IN > > > > > dump_td: failed_transaction: retries: 0 > > > > > dump_td: failed_transaction: active: 0001 > > > > > dump_td: failed_transaction: device_addr: 00 > > > > > dump_td: failed_transaction: endpoint: 0 > > > > > dump_td: failed_transaction: data_toggle: 1 > > > > > dump_td: failed_transaction: max_transfer: 7ff > > > > > dump_td: failed_transaction: actual: 0 > > > > > dump_td: failed_transaction: link: > > > > > dump_link: failed_transaction: addr: fe16d830 > > > > > dump_link: failed_transaction: raw addr: 0000 > > > > > dump_link: failed_transaction: terminate: 1 > > > > > dump_link: failed_transaction: queue: 0 > > > > > dump_link: failed_transaction: depth: 0 > > > > > malloc_diag: alloc: 11512 bytes (8 blocks), free: 250624 bytes (1 > > > > > blocks) configure_device: configure_device: set_address failed! > > > > > > > > > > poll_u_root_hub: poll_u_root_hub1 v=00001080 poll_usb1 i=0 > > > > > poll_u_root_hub1 v=00001083 poll_u_root_hub2 v=00001083 > > > > > poll_u_root_hub21 v=00001083 Connection on port d010 > > > > > New USB device, setting address 2 > > > > > uhci_control_msg: uhci_control_msg: request_type = 0 request = 5 > > > > > wLength=0 malloc_diag: alloc: 15616 bytes (9 blocks), free: 246520 > > > > > bytes (1 blocks) dump_uhci: HCI at ffffd000 > > > > > dump_td: failed_transaction: TD(0011d860): > > > > > dump_td: failed_transaction: type: SETUP > > > > > dump_td: failed_transaction: retries: 3 > > > > > dump_td: failed_transaction: IOC > > > > > dump_td: failed_transaction: active: 0001 > > > > > dump_td: failed_transaction: device_addr: 00 > > > > > dump_td: failed_transaction: endpoint: 0 > > > > > dump_td: failed_transaction: data_toggle: 0 > > > > > dump_td: failed_transaction: max_transfer: 7 > > > > > dump_td: failed_transaction: actual: 0 > > > > > dump_td: failed_transaction: link: > > > > > dump_link: failed_transaction: addr: 0011d880 > > > > > dump_link: failed_transaction: raw addr: 1fb0050 > > > > > dump_link: failed_transaction: terminate: 0 > > > > > dump_link: failed_transaction: queue: 0 > > > > > dump_link: failed_transaction: depth: 0 > > > > > dump_td: failed_transaction: TD(0011d880): > > > > > dump_td: failed_transaction: type: IN > > > > > dump_td: failed_transaction: retries: 0 > > > > > dump_td: failed_transaction: active: 0001 > > > > > dump_td: failed_transaction: device_addr: 00 > > > > > dump_td: failed_transaction: endpoint: 0 > > > > > dump_td: failed_transaction: data_toggle: 1 > > > > > dump_td: failed_transaction: max_transfer: 7ff > > > > > dump_td: failed_transaction: actual: 0 > > > > > dump_td: failed_transaction: link: > > > > > dump_link: failed_transaction: addr: fe16d830 > > > > > dump_link: failed_transaction: raw addr: 0000 > > > > > dump_link: failed_transaction: terminate: 1 > > > > > dump_link: failed_transaction: queue: 0 > > > > > dump_link: failed_transaction: depth: 0 > > > > > malloc_diag: alloc: 11512 bytes (8 blocks), free: 250624 bytes (1 > > > > > blocks) configure_device: configure_device: set_address failed! > > > > > > > > > > (...repeats...) > > > > > > > > > > > > > > > Thanks again! > > > > > > > > > > -- > > > > > Al > > > > > > > > > > > > > > > > > > > > ----- End forwarded message ----- > > > > > > > > > > -- > > > > > coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. > > > > > Tel.: +49 761 7668825 • Fax: +49 761 7664613 > > > > > Email: info(a)coresystems.de • http://www.coresystems.de/ > > > > > > > > > > -- > > > > > linuxbios mailing list > > > > > linuxbios(a)linuxbios.org > > > > > http://www.openbios.org/mailman/listinfo/linuxbios > > >

1 0

Re: [LinuxBIOS] FILO link errors on AMD64
by Chris Stillo 09 Sep '06

09 Sep '06

Stefan, You were correct, gcc was out-of-date. Initially, I was using the latest Debian release. After reading your hint, I decided to start from a clean slate and re-image to SUSE 10.1. No problems with FILO compile now. Thanks for the hints! Chris -----Original Message----- From: Stefan Reinauer [mailto:stepan@coresystems.de] Sent: Friday, September 08, 2006 4:31 PM To: Chris Stillo Cc: linuxbios(a)linuxbios.org Subject: Re: [LinuxBIOS] FILO link errors on AMD64 * Chris Stillo <Chris.Stillo(a)celoxica.com> [060908 23:02]: > Hello, > > I am attempting to compile FILO on a AMD64 (dk8htx) platform. Which version? svn? > I'm getting link errors(shown below), due to the 64-bit math > operations not being implemented in i386_x64 libgcc. Has anyone run > into this previously? not me. > ld -m elf_i386 -N -T i386/ldscript -o filo main/builtin.o > main/grub/builtin.o fs/builtin.o drivers/builtin.o > drivers/usb/builtin.o i386/builtin.o /usr/lib/ > gcc-lib/x86_64-linux/3.3.5/./libgcc.a Is this with a clean checkout? If so, your gcc is broken as it points to the wrong libgcc. What does the following command tell you? $ gcc -m32 -print-libgcc-file-name on my system it says: /usr/lib64/gcc/x86_64-suse-linux/4.1.2/32/libgcc.a ^^^^ Try updating your gcc. Stefan -- coresystems GmbH * Brahmsstr. 16 * D-79104 Freiburg i. Br. Tel.: +49 761 7668825 * Fax: +49 761 7664613 Email: info(a)coresystems.de * http://www.coresystems.de/ _____________________________________________________________________ This incoming message has been checked for all known viruses by the Messagelabs Scanning System, on behalf of Celoxica Ltd. _____________________________________________________________________ This message has been checked for all known viruses by the MessageLabs Virus Scanning Service, on behalf of Celoxica Ltd. This email and any files transmitted with it are confidential and may be legally privileged. It is intended solely for the use of the individual or entity to whom it is addressed. If you have received this in error, please contact the sender and delete the material immediately. Whilst this email has been swept for viruses, you should carry out your own virus check before opening any attachment. Celoxica Ltd accepts no liability for any loss or damage which may be caused by software viruses or interception or interruption of this email.

1 0

← Newer
1
...
11
12
13
14
15
16
17
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot September 2006