Hi all, and thanks for your help so far.
The problem now is that when I try to load seabios or filo, a fraction of a second after coreboot jumps to the payload the vga output starts goes crazy --colorful, geometric output, flashing in regular patterns.-- and coreboot restarts. The display keeps going, so I think in it's own special way it's trying to output what I'm seeing on the serial console, but it's garbage. With filo, it didn't actually display anything meaningful on the screen, it just went straight to the flashing colors. With seabios, depending on the optionsiit's built with it might display "press f12 for boot menu", then the two choices, for my hd and cd. Pressing either choice results in coreboot restarting. I'm attaching the serial log from the most recent attempt. Here's an excerpt:
Attempting to map option rom on dev 00:12.0 Option rom sizing returned 0 0 Searching CBFS for prefix genroms/ Found CBFS file fallback/coreboot_ram Found CBFS file fallback/payload Found CBFS file pci1106,3344.rom Found CBFS file Press F12 for boot menu.
handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 handle_hwpic1 irq=1 Mapping hd drive 0x000fdb40 to 0 pmm_malloc zone=0x000f5304 handle=ffffffff size=36 align=10 ret=0x000fdb70 (det) ebda moved from 9f800 to 9f000 pmm_malloc zone=0x000f52fc handle=ffffffff size=2048 align=10 ret=0x0009f5d0 (d) finalize PMM malloc finalize Add to e820 map: 0009f000 00001000 2 Add to e820 map: 3dfe0000 0000d000 1 Returned 53248 bytes of ZoneHigh
coreboot-4.0-r5680 Mon Aug 2 17:03:35 EDT 2010 starting... In romstage.c:main() After reset status: 0040 Waiting for SMBus to warm upDIMM 0050 OFFSET 0002 After reset status: 0040 Waiting until SMBus ready Waiting until SMBus ready Read: 0008 After reset status: 0040 .Done Enabling mainboard devices DIMM 0050 OFFSET 0005 After reset status: 0040 Waiting until SMBus ready Waiting until SMBus ready Read: 0000 After reset status: 0040 DIMM 0050 OFFSET 001f After reset status: 0040 Waiting until SMBus ready Waiting until SMBus ready Read: 0001 After reset status: 0040 Found 1024MB of ram DIMM 0050 OFFSET 0011 After reset status: 0040 Waiting until SMBus ready Waiting until SMBus ready Read: 0008 After reset status: 0040 DIMM 0050 OFFSET 0004
I'm not sure what other info might be useful, but I'll provide it or try whatever is asked. A few other possible clues: the factory bios only recognized half of my installed ram, but coreboot recognized all of it. With coreinfo or memtest as payloads, it did not restart, and it displayed the proper vga output. Memtest did report RAM errors, but I didn't understand what they meant, and at the time (before I tried seabios) I thought memtest might be wrong (which is why I wanted to load a full OS to double check). Since I can't think of what else to do, I'm going investigate the Memtest errors next.
Any ideas?
Thanks,
Rob Austin
On Mon, Aug 2, 2010 at 2:53 PM, austinro@msu.edu wrote:
I'm not sure what other info might be useful, but I'll provide it or try whatever is asked. A few other possible clues: the factory bios only recognized half of my installed ram, but coreboot recognized all of it. With coreinfo or memtest as payloads, it did not restart, and it displayed the proper vga output.
can you remove the RAM that the BIOS did not find? In this way you remove any potential hardware problems.
ron
On Mon, Aug 2, 2010 at 3:44 PM, ron minnich rminnich@gmail.com wrote:
On Mon, Aug 2, 2010 at 2:53 PM, austinro@msu.edu wrote:
I'm not sure what other info might be useful, but I'll provide it or try whatever is asked. A few other possible clues: the factory bios only recognized half of my installed ram, but coreboot recognized all of it. With coreinfo or memtest as payloads, it did not restart, and it displayed the proper vga output.
can you remove the RAM that the BIOS did not find? In this way you remove any potential hardware problems.
ron
J7F4 only has one RAM slot. I'd seen similar behavior on my J7F2 (only sees 512MB of a 1GB stick, doesn't boot from PATA), the solution was some different code to initialize IDE. I no longer have that board though (it died about a year ago, and I didn't replace it), so I have no real way to test it out. The code may be kicking around in the v2 archives.
-Corey
On Mon, Aug 2, 2010 at 10:52 PM, Corey Osgood corey.osgood@gmail.com wrote:
On Mon, Aug 2, 2010 at 3:44 PM, ron minnich rminnich@gmail.com wrote:
On Mon, Aug 2, 2010 at 2:53 PM, austinro@msu.edu wrote:
I'm not sure what other info might be useful, but I'll provide it or try whatever is asked. A few other possible clues: the factory bios only recognized half of my installed ram, but coreboot recognized all of it. With coreinfo or memtest as payloads, it did not restart, and it displayed the proper vga output.
can you remove the RAM that the BIOS did not find? In this way you remove any potential hardware problems.
ron
J7F4 only has one RAM slot. I'd seen similar behavior on my J7F2 (only sees 512MB of a 1GB stick, doesn't boot from PATA), the solution was some different code to initialize IDE.
Oops, sorry for the really unclear message. The problem with not booting from IDE was resolved with the different code, and I saw only 1/2 of the actual memory with the stock BIOS, never had a problem with coreboot. But apparently Aaron Lwe has made some changes since, and we've moved over to v4, so it's really hard to say exactly what/where/when it was broken.
-Corey
I no longer have that board though (it died about a year ago, and I didn't replace it), so I have no real way to test it out. The code may be kicking around in the v2 archives.
-Corey
Quoting ron minnich rminnich@gmail.com:
On Mon, Aug 2, 2010 at 2:53 PM, austinro@msu.edu wrote:
I'm not sure what other info might be useful, but I'll provide it or try whatever is asked. A few other possible clues: the factory bios only recognized half of my installed ram, but coreboot recognized all of it. With coreinfo or memtest as payloads, it did not restart, and it displayed the proper vga output.
can you remove the RAM that the BIOS did not find? In this way you remove any potential hardware problems.
This board only has one DIMM slot, and the board is only supposed to support up to 1G. I have 1G installed, and it gets reported as 512M. The only other nearly compatible RAM I have to try is a 2G stick; coreboot sees 2G, then has the same problem; the stock BIOS sees 1G, then Linux crashes later.
So no, I can't practically remove that RAM that wasn't found.
(This board is kind of lousy overall --when I bought it some of the reviews said it was fussy about RAM, but this particular brand/model# worked, so that's the one I bought, but as I said I could only use half, plus it's really fussy about booting from USB.)
Rob
Well, in the worst-case scenario, as a test, you can modify the raminit and just force it to use only 512M. Just as a test. I do this sometimes when I have ram issues.
ron
Yeah, I'm wondering if it's maybe that there's 2 ranks and each one needs to be initialized seperately, but only one is getting initialized. IT took away internet access on my linux box at work, so I can write a patch to test it out, but I can't send it until I get home (in about 7 hours)
-Corey
On Tue, Aug 3, 2010 at 10:41 AM, ron minnich rminnich@gmail.com wrote:
Well, in the worst-case scenario, as a test, you can modify the raminit and just force it to use only 512M. Just as a test. I do this sometimes when I have ram issues.
ron
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Please try the attached patch, and run memtest for a while (overnight would probably be best), and let me/us know the results. If this seems to correct the issue, then I'll work on a patch to initialize the extra ranks.
Thanks, Corey
On Tue, Aug 3, 2010 at 5:38 PM, Corey Osgood corey.osgood@gmail.com wrote:
Yeah, I'm wondering if it's maybe that there's 2 ranks and each one needs to be initialized seperately, but only one is getting initialized. IT took away internet access on my linux box at work, so I can write a patch to test it out, but I can't send it until I get home (in about 7 hours)
-Corey
On Tue, Aug 3, 2010 at 10:41 AM, ron minnich rminnich@gmail.com wrote:
Well, in the worst-case scenario, as a test, you can modify the raminit and just force it to use only 512M. Just as a test. I do this sometimes when I have ram issues.
ron
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
First, thank you all for your help, I wouldn't have known where to begin without it.
Quoting Corey Osgood corey.osgood@gmail.com:
Please try the attached patch, and run memtest for a while (overnight would probably be best), and let me/us know the results. If this seems to correct the issue, then I'll work on a patch to initialize the extra ranks.
Okay, I applied the patch, the relevant output reads
After reset status: 0040 ranks = 01, this is not the problem DIMM 0050 OFFSET 001f I rebuilt coreboot and it is running memtest right now. Here are a few pictures I took of the screen:
Memtest starts...[1] Memtest pauses for several minutes at 7%...[2] Memtest gets to 17%...[3] The screen goes crazy and coreboot reboots.[4]
Here is part of the serial log, showing the jump to the payload:
... Loaded segments Jumping to boot code at 10000 POST: 0xfe entry = 0x00010000 lb_start = 0x00004000 lb_size = 0x00020000 adjust = 0x3dfdc000 buffer = 0x3dfb6314 elf_boot_notes = 0x0001335c adjusted_boot_notes = 0x3dfef35c
coreboot-4.0-r5682M Wed Aug 4 11:13:09 EDT 2010 starting... In romstage.c:main() After reset status: 0040 Waiting for SMBus to warm upDIMM 0050 OFFSET 0002 After reset status: 0040 Waiting until SMBus ready Waiting until SMBus ready Read: 0008 After reset status: 0040 .Done Enabling mainboard devices DIMM 0050 OFFSET 0005 After reset status: 0040 Waiting until SMBus ready Waiting until SMBus ready Read: 0000 After reset status: 0040 ranks = 01, this is not the problem DIMM 0050 OFFSET 001f After reset status: 0040 Waiting until SMBus ready Waiting until SMBus ready Read: 0001 After reset status: 0040 Found 1024MB of ram DIMM 0050 OFFSET 0011 After reset status: 0040 Waiting until SMBus ready ... Notice that coreboot restarted in the middle. The screen does not change now, it's holding the broken colored pattern. It only restarted one time, which is at least different from the behavior with seabios or FILO, where it would keep restarting repeatedly. The final tail of the serial output is this:
... Assigned: PCI: 00:0f.0 1c * [0x24b4 - 0x24b7] io PCI_DOMAIN: 0000 allocate_resources_io: next_base: 24b8 size: 14b8 align: 8 grae PCI_DOMAIN: 0000 allocate_resources_mem: base:feba0000 size:40500 align:17 granf Assigned: PCI: 00:09.0 30 * [0xfeba0000 - 0xfebbffff] mem Assigned: PCI: 00:0b.0 30 * [0xfebc0000 - 0xfebdffff] mem Assigned: PCI: 00:09.0 14 * [0xfebe0000 - 0xfebe00ff] mem Assigned: PCI: 00:0b.0 14 * [0xfebe0100 - 0xfebe01ff] mem Assigned: PCI: 00:10.4 10 * [0xfebe0200 - 0xfebe02ff] mem Assigned: PCI: 00:10.5 10 * [0xfebe0300 - 0xfebe03ff] mem Assigned: PCI: 00:12.0 14 * [0xfebe0400 - 0xfebe04ff] mem PCI_DOMAIN: 0000 allocate_resources_mem: next_base: febe0500 size: 40500 align:e Root Device assign_resources, bus 0 link: 0 Entering cn700 pci_domain_set_resources. Entering find_pci_tolm Leaving find_pci_tolm tomk is 0x100000 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:09.0 10 <- [0x0000001000 - 0x00000010ff] size 0x00000100 gran 0x08 io PCI: 00:09.0 14 <- [0x00febe0000 - 0x00febe00ff] size 0x00000100 gran 0x08 mem PCI: 00:09.0 30 <- [0x00feba0000 - 0x00febbffff] size 0x00020000 gran 0x11 romem PCI: 00:0b.0 10 <- [0x0000001400 - 0x00000014ff] size 0x00000100 gran 0x08 io PCI: 00:0b.0 14 <- [0x00febe0100 - 0x00febe01ff] size 0x00000100 gran 0x08 mem PCI: 00:0b.0 30 <- [0x00febc0000 - 0x00febdffff] size 0x00020000 gran 0x11 romem PCI: 00:0f.0 10 <- [0x00000024a0 - 0x00000024a7] size 0x00000008 gran 0x03 io PCI: 00:0f.0 14 <- [0x00000024b0 - 0x00000024b3] size 0x00000004 gran 0x02 io PCI: 00:0f.0 18 <- [0x00000024a8 - 0x00000024af] size 0x00000008 gran 0x03 io PCI: 00:0f.0 1c <- [0x00000024b4 - 0x00000024b7] size 0x00000004 gran 0x02 io PCI: 00:0f.0 20 <- [0x0000002480 - 0x000000248f] size 0x00000010 gran 0x04 io PCI: 00:0f.0 24 <- [0x0000001800 - 0x00000018ff] size 0x00000100 gran 0x08 io PCI: 00:0f.1 20 <- [0x0000002490 - 0x000000249f] size 0x00000010 gran 0x04 io PCI: 00:10.0 20 <- [0x0000002400 - 0x000000241f] size 0x00000020 gran 0x05 io PCI: 00:10.1 20 <- [0x0000002420 - 0x000000243f] size 0x00000020 gran 0x05 io PCI: 00:10.2 20 <- [0x0000002440 - 0x000000245f] size 0x00000020 gran 0x05 io PCI: 00:10.3 20 <- [0x0000002460 - 0x000000247f] size 0x00000020 gran 0x05 io PCI: 00:10.4 10 <- [0x00febe0200 - 0x00febe02ff] size 0x00000100 gran 0x08 mem PCI: 00:10.5 10 <- [0x00febe0300 - 0x00febe03ff] size 0x00000100 gran 0x08 mem PCI: 00:11.0 assign_resources, bus 0 link: 0 I'm attaching the whole log, also.
Links: ------ [1] http://dl.dropbox.com/u/7220270/memtest_just_starting.JPG [2] http://dl.dropbox.com/u/7220270/memtest_pauses_halfway.JPG [3] http://dl.dropbox.com/u/7220270/vga_breaks_after_17_percent.JPG [4] http://dl.dropbox.com/u/7220270/vga_broken.JPG
Oh! Memtest would seem to be overwriting shared graphics memory (or AGP, or VGA BIOS...). I'm going to be busy most of the day today, I'll check it out tomorrow (unless someone else figures it out first).
-Corey
On Wed, Aug 4, 2010 at 2:15 PM, austinro@msu.edu wrote:
First, thank you all for your help, I wouldn't have known where to begin without it.
Quoting Corey Osgood corey.osgood@gmail.com:
Please try the attached patch, and run memtest for a while (overnight would probably be best), and let me/us know the results. If this seems to correct the issue, then I'll work on a patch to initialize the extra ranks.
Okay, I applied the patch, the relevant output reads
After reset status: 0040 ranks = 01, this is not the problem DIMM 0050 OFFSET 001f I rebuilt coreboot and it is running memtest right now. Here are a few pictures I took of the screen:
Memtest starts... Memtest pauses for several minutes at 7%... Memtest gets to 17%... The screen goes crazy and coreboot reboots.
Here is part of the serial log, showing the jump to the payload:
... Loaded segments Jumping to boot code at 10000 POST: 0xfe entry = 0x00010000 lb_start = 0x00004000 lb_size = 0x00020000 adjust = 0x3dfdc000 buffer = 0x3dfb6314 elf_boot_notes = 0x0001335c adjusted_boot_notes = 0x3dfef35c
coreboot-4.0-r5682M Wed Aug 4 11:13:09 EDT 2010 starting... In romstage.c:main()
After reset status: 0040 Waiting for SMBus to warm upDIMM 0050 OFFSET 0002 After reset status: 0040 Waiting until SMBus ready Waiting until SMBus ready Read: 0008 After reset status: 0040 .Done
Enabling mainboard devices DIMM 0050 OFFSET 0005 After reset status: 0040 Waiting until SMBus ready Waiting until SMBus ready Read: 0000 After reset status: 0040 ranks = 01, this is not the problem DIMM 0050 OFFSET 001f After reset status: 0040 Waiting until SMBus ready Waiting until SMBus ready Read: 0001 After reset status: 0040 Found 1024MB of ram DIMM 0050 OFFSET 0011 After reset status: 0040 Waiting until SMBus ready ... Notice that coreboot restarted in the middle. The screen does not change now, it's holding the broken colored pattern. It only restarted one time, which is at least different from the behavior with seabios or FILO, where it would keep restarting repeatedly. The final tail of the serial output is this:
... Assigned: PCI: 00:0f.0 1c * [0x24b4 - 0x24b7] io PCI_DOMAIN: 0000 allocate_resources_io: next_base: 24b8 size: 14b8 align: 8 grae PCI_DOMAIN: 0000 allocate_resources_mem: base:feba0000 size:40500 align:17 granf Assigned: PCI: 00:09.0 30 * [0xfeba0000 - 0xfebbffff] mem Assigned: PCI: 00:0b.0 30 * [0xfebc0000 - 0xfebdffff] mem Assigned: PCI: 00:09.0 14 * [0xfebe0000 - 0xfebe00ff] mem Assigned: PCI: 00:0b.0 14 * [0xfebe0100 - 0xfebe01ff] mem Assigned: PCI: 00:10.4 10 * [0xfebe0200 - 0xfebe02ff] mem Assigned: PCI: 00:10.5 10 * [0xfebe0300 - 0xfebe03ff] mem Assigned: PCI: 00:12.0 14 * [0xfebe0400 - 0xfebe04ff] mem PCI_DOMAIN: 0000 allocate_resources_mem: next_base: febe0500 size: 40500 align:e Root Device assign_resources, bus 0 link: 0 Entering cn700 pci_domain_set_resources. Entering find_pci_tolm Leaving find_pci_tolm tomk is 0x100000 PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 PCI: 00:09.0 10 <- [0x0000001000 - 0x00000010ff] size 0x00000100 gran 0x08 io PCI: 00:09.0 14 <- [0x00febe0000 - 0x00febe00ff] size 0x00000100 gran 0x08 mem PCI: 00:09.0 30 <- [0x00feba0000 - 0x00febbffff] size 0x00020000 gran 0x11 romem PCI: 00:0b.0 10 <- [0x0000001400 - 0x00000014ff] size 0x00000100 gran 0x08 io PCI: 00:0b.0 14 <- [0x00febe0100 - 0x00febe01ff] size 0x00000100 gran 0x08 mem PCI: 00:0b.0 30 <- [0x00febc0000 - 0x00febdffff] size 0x00020000 gran 0x11 romem PCI: 00:0f.0 10 <- [0x00000024a0 - 0x00000024a7] size 0x00000008 gran 0x03 io PCI: 00:0f.0 14 <- [0x00000024b0 - 0x00000024b3] size 0x00000004 gran 0x02 io PCI: 00:0f.0 18 <- [0x00000024a8 - 0x00000024af] size 0x00000008 gran 0x03 io PCI: 00:0f.0 1c <- [0x00000024b4 - 0x00000024b7] size 0x00000004 gran 0x02 io PCI: 00:0f.0 20 <- [0x0000002480 - 0x000000248f] size 0x00000010 gran 0x04 io PCI: 00:0f.0 24 <- [0x0000001800 - 0x00000018ff] size 0x00000100 gran 0x08 io PCI: 00:0f.1 20 <- [0x0000002490 - 0x000000249f] size 0x00000010 gran 0x04 io PCI: 00:10.0 20 <- [0x0000002400 - 0x000000241f] size 0x00000020 gran 0x05 io PCI: 00:10.1 20 <- [0x0000002420 - 0x000000243f] size 0x00000020 gran 0x05 io PCI: 00:10.2 20 <- [0x0000002440 - 0x000000245f] size 0x00000020 gran 0x05 io PCI: 00:10.3 20 <- [0x0000002460 - 0x000000247f] size 0x00000020 gran 0x05 io PCI: 00:10.4 10 <- [0x00febe0200 - 0x00febe02ff] size 0x00000100 gran 0x08 mem PCI: 00:10.5 10 <- [0x00febe0300 - 0x00febe03ff] size 0x00000100 gran 0x08 mem PCI: 00:11.0 assign_resources, bus 0 link: 0 I'm attaching the whole log, also.
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
austinro@msu.edu wrote:
Memtest did report RAM errors,
Then something is not set up correctly.
but I didn't understand what they meant, and at the time (before I tried seabios) I thought memtest might be wrong
Not very likely.
(which is why I wanted to load a full OS to double check). Since I can't think of what else to do, I'm going investigate the Memtest errors next.
This is the path forward!
//Peter
-
austinro＠msu.edu -
Corey Osgood -
Peter Stuge -
ron minnich