Current Status of DFI P2XBL (440bx w/ Winbond SuperIO W83977EW using W83977TF code. Chips similar (ie. EW is lacking one or two GP logical devices.)
I get random hangs during sdram init.
Attached is a log with multiple boots demonstrating the random hangs -- and this also explains the random post codes I've been getting on this box.
Hey! console_init works now!
-- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61
Wed May 9 08:17:12 PDT 2007
On Wed, May 09, 2007 at 08:20:56AM -0700, roger wrote:
I get random hangs during sdram init.
Hm. My guess is that some RAM parameters don't match your system (66 MHz vs. 100 MHz system bus frequency, or such), or are just plain wrong.
Don't forget, the current code is hardcoded to the S1846 (which I'll fix soon, I hope).
Uwe.
On Wed, 2007-05-09 at 19:58 +0200, Uwe Hermann wrote:
On Wed, May 09, 2007 at 08:20:56AM -0700, roger wrote:
I get random hangs during sdram init.
Hm. My guess is that some RAM parameters don't match your system (66 MHz vs. 100 MHz system bus frequency, or such), or are just plain wrong.
Don't forget, the current code is hardcoded to the S1846 (which I'll fix soon, I hope).
FYI: Attached is the current linuxbios boot log of the DFI P2XBL board using asus/p2b profile.
Seems to be *consistently* hanging at RAM3 (during Northbridge prior to SDRAM init). (Although yanking out 2 dimms gets me a step or two further ... with failing errors.)
The board has 3 PC100 SDRAM 128MB modules with only 3 DIMM sockets for a total of ~384MB.
(Dunno if the following dmesg of this motherboard will help. I'll probably be studying DRAM structure and a good 82443BX chip pdf tonight.)
BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: 0000000000000000 size: 00000000000a0000 end: 00000000000a0000 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 2 copy_e820_map() start: 0000000000100000 size: 0000000017ef0000 end: 0000000017ff0000 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0000000017ff0000 size: 0000000000003000 end: 0000000017ff3000 type: 4 copy_e820_map() start: 0000000017ff3000 size: 000000000000d000 end: 0000000018000000 type: 3 copy_e820_map() start: 00000000ffff0000 size: 0000000000010000 end: 0000000100000000 type: 2 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000017ff0000 (usable) BIOS-e820: 0000000017ff0000 - 0000000017ff3000 (ACPI NVS) BIOS-e820: 0000000017ff3000 - 0000000018000000 (ACPI data) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 383MB LOWMEM available
-- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61
Wed May 9 16:04:48 PDT 2007
BTW: I've set up my asus/p2b/auto.c to mimmick the tyan/s1846/auto.c
So DRAM *should* be working and getting to at least elfboot.
Only things I can think of would be DRAM timing too.
-- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61
Wed May 9 16:22:35 PDT 2007
roger wrote:
BTW: I've set up my asus/p2b/auto.c to mimmick the tyan/s1846/auto.c
So DRAM *should* be working and getting to at least elfboot.
Only things I can think of would be DRAM timing too.
roger, only test with one dimm for now, single sided if possible, and in the first slot. It's very possible that dram init is only working for the first dimm. Once that's working, try to get the rest going. And afaik, the timings being used right now (CL3) should be safe/sane for any sdram dimm. Also check that your dimm(s) are capable of running the same speed as your cpu's frontside bus, I haven't looked at the code recently but I'm going to guess that it's still set up to statically set the ram to the same speed as the fsb. When I was working with it, I was using an old 466MHz celeron (66MHz*7) and PC100 ram to make sure this was a non-issue. Let me know if you need a cpu with a slower fsb, I must have a few dozen old celerons and pentium 2s kicking around, socket 370 and slot 1.
Also, asus p2b's auto.c is fixed in the latest revisions ;)
Good luck! -Corey
On Thu, 2007-05-10 at 00:08 -0400, Corey Osgood wrote:
roger wrote:
BTW: I've set up my asus/p2b/auto.c to mimmick the tyan/s1846/auto.c
So DRAM *should* be working and getting to at least elfboot.
Only things I can think of would be DRAM timing too.
roger, only test with one dimm for now, single sided if possible, and in the first slot. It's very possible that dram init is only working for the first dimm. Once that's working, try to get the rest going. And afaik, the timings being used right now (CL3) should be safe/sane for any sdram dimm. Also check that your dimm(s) are capable of running the same speed as your cpu's frontside bus, I haven't looked at the code recently but I'm going to guess that it's still set up to statically set the ram to the same speed as the fsb. When I was working with it, I was using an old 466MHz celeron (66MHz*7) and PC100 ram to make sure this was a non-issue. Let me know if you need a cpu with a slower fsb, I must have a few dozen old celerons and pentium 2s kicking around, socket 370 and slot 1.
This was one minor difference, I have a slot 2 P3 450 (fsb 100). According to the Intel 82443BX spec, the fsb needs to run at 100Mhz. (...and I thought 100Mhz was compatible with 66Mhz.... anyways, no matter, I've already played with the motherboard jumper controlling the fsb for the cpu & ram. ;-)
All I did was change the cpu type within Config.lb too.
chip cpu/intel/slot_2 # chip cpu/intel/socket_PGA370
I do get past the "RAM3" state with only 1 DIMM inserted. The other other 2 banks are left empty. This is more significantly further past RAM3 then I previously thought.
As you can see, I get as far as DRAM VERIFY & DRAM VERIFY FAILURE... this is reminding me of the s1846 profile with raminit.c checking video bios memory region. But this has been fixed long ago! (Meantime, back to google to figure out what i'm doing here, and once this is fixed, I'll go back & try to get all 3 dimms working... as they *should* work like with the tyan/s1846 profile works just fine with my tyan s1832 w/ 1G Ram and all four banks filled ... :-/ )
Ram2.00 Ram3 RAM Enable 1: Apply NOP Sending RAM command 0x0020 to 0x00000000 RAM Enable 2: Precharge all Sending RAM command 0x0040 to 0x00000000 RAM Enable 3: CBR Sending RAM command 0x0080 to 0x00000000 Sending RAM command 0x0080 to 0x00000000 Sending RAM command 0x0080 to 0x00000000 Sending RAM command 0x0080 to 0x00000000 Sending RAM command 0x0080 to 0x00000000 Sending RAM command 0x0080 to 0x00000000 Sending RAM command 0x0080 to 0x00000000 Sending RAM command 0x0080 to 0x00000000 RAM Enable 4: Mode register set Sending RAM command 0x0060 to 0x000001d0 RAM Enable 5: Normal operation Sending RAM command 0x0000 to 0x00000000 RAM Enable 6: Enable refresh Enabling refresh (DRAMC = 0x09) for DIMM 02 Northbridge following SDRAM init: PCI: 00:00.00 00: 86 80 90 71 06 00 10 22 03 00 00 06 00 00 00 00 10: 08 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 a0 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 0c 80 00 ff 08 00 00 09 00 00 00 00 00 00 00 00 60: 08 08 08 08 08 08 08 08 00 00 00 00 00 00 00 00 70: 00 1f 02 38 01 00 00 00 07 01 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 80 00 00 00 04 61 00 00 00 05 00 00 00 00 00 00 a0: 02 00 10 00 03 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 18 0c 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 0c 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 f8 00 00 20 0f 00 00 00 00 00 00 Ram4 Testing DRAM : 00000000-0009ffff DRAM fill: 00000000-0009ffff 00000000 00010000 00020000 00030000 00040000 00050000 00060000 00070000 00080000 00090000 000a0000 DRAM filled DRAM verify: 00000000-0009ffff 00000000 Fail: @0x00000000 Read value=0x0009ff80 Fail: @0x00000004 Read value=0x0009fffc Fail: @0x00000008 Read value=0x0009ff80 Fail: @0x0000000c Read value=0x0009fffc Fail: @0x00000010 Read value=0x0009ff80 Fail: @0x00000014 Read value=0x0009fffc Fail: @0x00000018 Read value=0x0009ff80 Fail: @0x0000001c Read value=0x0009fffc Fail: @0x00000020 Read value=0x0009ff80 Fail: @0x00000024 Read value=0x0009fffc Fail: @0x00000028 Read value=0x0009ff80 Fail: @0x0000002c Read value=0x0009fffc Fail: @0x00000030 Read value=0x0009ff80 Fail: @0x00000034 Read value=0x0009fffc Fail: @0x00000038 Read value=0x0009ff80 Fail: @0x0000003c Read value=0x0009fffc Fail: @0x00000040 Read value=0x0009ff80 Fail: @0x00000044 Read value=0x0009fffc Fail: @0x00000048 Read value=0x0009ff80 Fail: @0x0000004c Read value=0x0009fffc Fail: @0x00000050 Read value=0x0009ff80 Fail: @0x00000054 Read value=0x0009fffc Fail: @0x00000058 Read value=0x0009ff80 Fail: @0x0000005c Read value=0x0009fffc Fail: @0x00000060 Read value=0x0009ff80 Fail: @0x00000064 Read value=0x0009fffc Fail: @0x00000068 Read value=0x0009ff80 Fail: @0x0000006c Read value=0x0009fffc Fail: @0x00000070 Read value=0x0009ff80 Fail: @0x00000074 Read value=0x0009fffc Fail: @0x00000078 Read value=0x0009ff80 Fail: @0x0000007c Read value=0x0009fffc Fail: @0x00000080 Read value=0x0009ff80 Fail: @0x00000084 Read value=0x0009fffc Fail: @0x00000088 Read value=0x0009ff80 Fail: @0x0000008c Read value=0x0009fffc Fail: @0x00000090 Read value=0x0009ff80 Fail: @0x00000094 Read value=0x0009fffc Fail: @0x00000098 Read value=0x0009ff80 Fail: @0x0000009c Read value=0x0009fffc Fail: @0x000000a0 Read value=0x0009ff80 Fail: @0x000000a4 Read value=0x0009fffc Fail: @0x000000a8 Read value=0x0009ff80 Fail: @0x000000ac Read value=0x0009fffc Fail: @0x000000b0 Read value=0x0009ff80 Fail: @0x000000b4 Read value=0x0009fffc Fail: @0x000000b8 Read value=0x0009ff80 Fail: @0x000000bc Read value=0x0009fffc Fail: @0x000000c0 Read value=0x0009ff80 Fail: @0x000000c4 Read value=0x0009fffc Fail: @0x000000c8 Read value=0x0009ff80 Fail: @0x000000cc Read value=0x0009fffc Fail: @0x000000d0 Read value=0x0009ff80 Fail: @0x000000d4 Read value=0x0009fffc Fail: @0x000000d8 Read value=0x0009ff80 Fail: @0x000000dc Read value=0x0009fffc Fail: @0x000000e0 Read value=0x0009ff80 Fail: @0x000000e4 Read value=0x0009fffc Fail: @0x000000e8 Read value=0x0009ff80 Fail: @0x000000ec Read value=0x0009fffc Fail: @0x000000f0 Read value=0x0009ff80 Fail: @0x000000f4 Read value=0x0009fffc Fail: @0x000000f8 Read value=0x0009ff80 Fail: @0x000000fc Read value=0x0009fffc Fail: @0x00000100 Read value=0x0009ff80 Fail: @0x00000104 Read value=0x0009fffc Fail: @0x00000108 Read value=0x0009ff80 Fail: @0x0000010c Read value=0x0009fffc Fail: @0x00000110 Read value=0x0009ff80 Fail: @0x00000114 Read value=0x0009fffc Fail: @0x00000118 Read value=0x0009ff80 Fail: @0x0000011c Read value=0x0009fffc Fail: @0x00000120 Read value=0x0009ff80 Fail: @0x00000124 Read value=0x0009fffc Fail: @0x00000128 Read value=0x0009ff80 Fail: @0x0000012c Read value=0x0009fffc Fail: @0x00000130 Read value=0x0009ff80 Fail: @0x00000134 Read value=0x0009fffc Fail: @0x00000138 Read value=0x0009ff80 Fail: @0x0000013c Read value=0x0009fffc Fail: @0x00000140 Read value=0x0009ff80 Fail: @0x00000144 Read value=0x0009fffc Fail: @0x00000148 Read value=0x0009ff80 Fail: @0x0000014c Read value=0x0009fffc Fail: @0x00000150 Read value=0x0009ff80 Fail: @0x00000154 Read value=0x0009fffc Fail: @0x00000158 Read value=0x0009ff80 Fail: @0x0000015c Read value=0x0009fffc Fail: @0x00000160 Read value=0x0009ff80 Fail: @0x00000164 Read value=0x0009fffc Fail: @0x00000168 Read value=0x0009ff80 Fail: @0x0000016c Read value=0x0009fffc Fail: @0x00000170 Read value=0x0009ff80 Fail: @0x00000174 Read value=0x0009fffc Fail: @0x00000178 Read value=0x0009ff80 Fail: @0x0000017c Read value=0x0009fffc Fail: @0x00000180 Read value=0x0009ff80 Fail: @0x00000184 Read value=0x0009fffc Fail: @0x00000188 Read value=0x0009ff80 Fail: @0x0000018c Read value=0x0009fffc Fail: @0x00000190 Read value=0x0009ff80 Fail: @0x00000194 Read value=0x0009fffc Fail: @0x00000198 Read value=0x0009ff80 Fail: @0x0000019c Read value=0x0009fffc Fail: @0x000001a0 Read value=0x0009ff80 Fail: @0x000001a4 Read value=0x0009fffc Fail: @0x000001a8 Read value=0x0009ff80 Fail: @0x000001ac Read value=0x0009fffc Fail: @0x000001b0 Read value=0x0009ff80 Fail: @0x000001b4 Read value=0x0009fffc Fail: @0x000001b8 Read value=0x0009ff80 Fail: @0x000001bc Read value=0x0009fffc Fail: @0x000001c0 Read value=0x0009ff80 Fail: @0x000001c4 Read value=0x0009fffc Fail: @0x000001c8 Read value=0x0009ff80 Fail: @0x000001cc Read value=0x0009fffc Fail: @0x000001d0 Read value=0x0009ff80 Fail: @0x000001d4 Read value=0x0009fffc Fail: @0x000001d8 Read value=0x0009ff80 Fail: @0x000001dc Read value=0x0009fffc Fail: @0x000001e0 Read value=0x0009ff80 Fail: @0x000001e4 Read value=0x0009fffc Fail: @0x000001e8 Read value=0x0009ff80 Fail: @0x000001ec Read value=0x0009fffc Fail: @0x000001f0 Read value=0x0009ff80 Fail: @0x000001f4 Read value=0x0009fffc Fail: @0x000001f8 Read value=0x0009ff80 Fail: @0x000001fc Read value=0x0009fffc Fail: @0x00000200 Read value=0x0009ff80 Fail: @0x00000204 Read value=0x0009fffc Fail: @0x00000208 Read value=0x0009ff80 Fail: @0x0000020c Read value=0x0009fffc Fail: @0x00000210 Read value=0x0009ff80 Fail: @0x00000214 Read value=0x0009fffc Fail: @0x00000218 Read value=0x0009ff80 Fail: @0x0000021c Read value=0x0009fffc Fail: @0x00000220 Read value=0x0009ff80 Fail: @0x00000224 Read value=0x0009fffc Fail: @0x00000228 Read value=0x0009ff80 Fail: @0x0000022c Read value=0x0009fffc Fail: @0x00000230 Read value=0x0009ff80 Fail: @0x00000234 Read value=0x0009fffc Fail: @0x00000238 Read value=0x0009ff80 Fail: @0x0000023c Read value=0x0009fffc Fail: @0x00000240 Read value=0x0009ff80 Fail: @0x00000244 Read value=0x0009fffc Fail: @0x00000248 Read value=0x0009ff80 Fail: @0x0000024c Read value=0x0009fffc Fail: @0x00000250 Read value=0x0009ff80 Fail: @0x00000254 Read value=0x0009fffc Fail: @0x00000258 Read value=0x0009ff80 Fail: @0x0000025c Read value=0x0009fffc Fail: @0x00000260 Read value=0x0009ff80 Fail: @0x00000264 Read value=0x0009fffc Fail: @0x00000268 Read value=0x0009ff80 Fail: @0x0000026c Read value=0x0009fffc Fail: @0x00000270 Read value=0x0009ff80 Fail: @0x00000274 Read value=0x0009fffc Fail: @0x00000278 Read value=0x0009ff80 Fail: @0x0000027c Read value=0x0009fffc Fail: @0x00000280 Read value=0x0009ff80 Fail: @0x00000284 Read value=0x0009fffc Fail: @0x00000288 Read value=0x0009ff80 Fail: @0x0000028c Read value=0x0009fffc Fail: @0x00000290 Read value=0x0009ff80 Fail: @0x00000294 Read value=0x0009fffc Fail: @0x00000298 Read value=0x0009ff80 Fail: @0x0000029c Read value=0x0009fffc Fail: @0x000002a0 Read value=0x0009ff80 Fail: @0x000002a4 Read value=0x0009fffc Fail: @0x000002a8 Read value=0x0009ff80 Fail: @0x000002ac Read value=0x0009fffc Fail: @0x000002b0 Read value=0x0009ff80 Fail: @0x000002b4 Read value=0x0009fffc Fail: @0x000002b8 Read value=0x0009ff80 Fail: @0x000002bc Read value=0x0009fffc Fail: @0x000002c0 Read value=0x0009ff80 Fail: @0x000002c4 Read value=0x0009fffc Fail: @0x000002c8 Read value=0x0009ff80 Fail: @0x000002cc Read value=0x0009fffc Fail: @0x000002d0 Read value=0x0009ff80 Fail: @0x000002d4 Read value=0x0009fffc Fail: @0x000002d8 Read value=0x0009ff80 Fail: @0x000002dc Read value=0x0009fffc Fail: @0x000002e0 Read value=0x0009ff80 Fail: @0x000002e4 Read value=0x0009fffc Fail: @0x000002e8 Read value=0x0009ff80 Fail: @0x000002ec Read value=0x0009fffc Fail: @0x000002f0 Read value=0x0009ff80 Fail: @0x000002f4 Read value=0x0009fffc Fail: @0x000002f8 Read value=0x0009ff80 Fail: @0x000002fc Read value=0x0009fffc Fail: @0x00000300 Read value=0x0009ff80 Fail: @0x00000304 Read value=0x0009fffc Fail: @0x00000308 Read value=0x0009ff80 Fail: @0x0000030c Read value=0x0009fffc Fail: @0x00000310 Read value=0x0009ff80 Fail: @0x00000314 Read value=0x0009fffc Fail: @0x00000318 Read value=0x0009ff80 Fail: @0x0000031c Read value=0x0009fffc Fail: @0x00000320 Read value=0x0009ff80 Fail: @0x00000324 Read value=0x0009fffc Fail: @0x00000328 Read value=0x0009ff80 Fail: @0x0000032c Read value=0x0009fffc Fail: @0x00000330 Read value=0x0009ff80 Fail: @0x00000334 Read value=0x0009fffc Fail: @0x00000338 Read value=0x0009ff80 Fail: @0x0000033c Read value=0x0009fffc Fail: @0x00000340 Read value=0x0009ff80 Fail: @0x00000344 Read value=0x0009fffc Fail: @0x00000348 Read value=0x0009ff80 Fail: @0x0000034c Read value=0x0009fffc Fail: @0x00000350 Read value=0x0009ff80 Fail: @0x00000354 Read value=0x0009fffc Fail: @0x00000358 Read value=0x0009ff80 Fail: @0x0000035c Read value=0x0009fffc Fail: @0x00000360 Read value=0x0009ff80 Fail: @0x00000364 Read value=0x0009fffc Fail: @0x00000368 Read value=0x0009ff80 Fail: @0x0000036c Read value=0x0009fffc Fail: @0x00000370 Read value=0x0009ff80 Fail: @0x00000374 Read value=0x0009fffc Fail: @0x00000378 Read value=0x0009ff80 Fail: @0x0000037c Read valu
Also, asus p2b's auto.c is fixed in the latest revisions ;)
I know. I've been monitoring the changes here including updating my svn copy more regularly.
-- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61
Wed May 9 21:27:30 PDT 2007
On Thu, 2007-05-10 at 00:08 -0400, Corey Osgood wrote:
roger wrote:
BTW: I've set up my asus/p2b/auto.c to mimmick the tyan/s1846/auto.c
So DRAM *should* be working and getting to at least elfboot.
Only things I can think of would be DRAM timing too.
roger, only test with one dimm for now, single sided if possible, and in the first slot. It's very possible that dram init is only working for the first dimm. Once that's working, try to get the rest going. And afaik, the timings being used right now (CL3) should be safe/sane for any sdram dimm. Also check that your dimm(s) are capable of running the same speed as your cpu's frontside bus, I haven't looked at the code recently but I'm going to guess that it's still set up to statically set the ram to the same speed as the fsb. When I was working with it, I was using an old 466MHz celeron (66MHz*7) and PC100 ram to make sure this was a non-issue. Let me know if you need a cpu with a slower fsb, I must have a few dozen old celerons and pentium 2s kicking around, socket 370 and slot 1.
Also, asus p2b's auto.c is fixed in the latest revisions ;)
Good luck! -Corey
Thanks for the Good luck! .. think it helped.. noticed, as usual, I was using DIMM Bank 2 instead of 0. Now it boots.
So the main issue, DIMM Banks 1 & 2 (for this 3 DIMM Bank board) needs to be empty and only one DIMM in Bank 0!
Here's proof. Granted, it only shows "Jumping to Linuxbios"
Ram4 Testing DRAM : 00000000-0009ffff DRAM fill: 00000000-0009ffff 000a0000 DRAM filled DRAM verify: 00000000-0009ffff 000a0000 DRAM range verified. Done. Testing DRAM : 00100000-007c0000 DRAM fill: 00100000-007c0000 007c0000 DRAM filled DRAM verify: 00100000-007c0000 007c0000 DRAM range verified. Done. Copying LinuxBIOS to RAM. Jumping to LinuxBIOS. LinuxBIOS-2.0.0.0Fallback Wed May 9 15:55:10 PDT 2007 booting...
I should be seeing next roughly "end 35a51f17, start 1" and PCI enumerating. More stuff to look over at this point as the Config.lb isn't entirely filled with PCI bus data.)
-- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61
Wed May 9 22:39:30 PDT 2007
On Wed, 2007-05-09 at 22:45 -0700, roger wrote:
Ram4 Testing DRAM : 00000000-0009ffff DRAM fill: 00000000-0009ffff 000a0000 DRAM filled DRAM verify: 00000000-0009ffff 000a0000 DRAM range verified. Done. Testing DRAM : 00100000-007c0000 DRAM fill: 00100000-007c0000 007c0000 DRAM filled DRAM verify: 00100000-007c0000 007c0000 DRAM range verified. Done. Copying LinuxBIOS to RAM. Jumping to LinuxBIOS. LinuxBIOS-2.0.0.0Fallback Wed May 9 15:55:10 PDT 2007 booting...
I should be seeing next roughly "end 35a51f17, start 1" and PCI enumerating. More stuff to look over at this point as the Config.lb isn't entirely filled with PCI bus data.)
As mentioned already, there's probably a DRAM error someplace causing the hang on "booting..."
Think I should also state, I'm getting a 0xE7 postcode either during DRAM Verify or DRAM Test. Other then this, I get the usual 0x80 before and 0x80 at "Jumping to LinuxBIOS..."
Are there any debugging methods I can try during DRAM verify/tests?
I see something pertaining to prink_debug but it's not being provided by console.c in auto.c, requires another include or something.
I'll go back to the tyan/s1846 profile and see if I get the same results.
-- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61
Thu May 10 20:16:58 PDT 2007
roger wrote:
On Wed, 2007-05-09 at 22:45 -0700, roger wrote:
As mentioned already, there's probably a DRAM error someplace causing the hang on "booting..."
Think I should also state, I'm getting a 0xE7 postcode either during DRAM Verify or DRAM Test. Other then this, I get the usual 0x80 before and 0x80 at "Jumping to LinuxBIOS..."
Are there any debugging methods I can try during DRAM verify/tests?
I see something pertaining to prink_debug but it's not being provided by console.c in auto.c, requires another include or something.
Roger, You should be able to use the print_debug() function in auto.c before memory/stack is initialized. I think it works as long as you have serial port setup and include arch/i386/lib/console.c.
I am not familiar with the Intel memory controller but it is most likely a timing issue. Unfortunately those are the hardest to debug. If you can I would try some different fast and slow DIMMs to see if one works better. You could try to compare timings with the PC BIOS if you still have it. From northbridge/intel/i440bx/raminit.c, it looks like you can just read the setting out of the PCI header. Maybe someone who know more about it will speak up..... :)
Good Luck! Marc
roger wrote:
On Wed, 2007-05-09 at 22:45 -0700, roger wrote:
Ram4 Testing DRAM : 00000000-0009ffff DRAM fill: 00000000-0009ffff 000a0000 DRAM filled DRAM verify: 00000000-0009ffff 000a0000 DRAM range verified. Done. Testing DRAM : 00100000-007c0000 DRAM fill: 00100000-007c0000 007c0000 DRAM filled DRAM verify: 00100000-007c0000 007c0000 DRAM range verified. Done. Copying LinuxBIOS to RAM. Jumping to LinuxBIOS. LinuxBIOS-2.0.0.0Fallback Wed May 9 15:55:10 PDT 2007 booting...
I should be seeing next roughly "end 35a51f17, start 1" and PCI enumerating. More stuff to look over at this point as the Config.lb isn't entirely filled with PCI bus data.)
As mentioned already, there's probably a DRAM error someplace causing the hang on "booting..."
Think I should also state, I'm getting a 0xE7 postcode either during DRAM Verify or DRAM Test. Other then this, I get the usual 0x80 before and 0x80 at "Jumping to LinuxBIOS..."
Are there any debugging methods I can try during DRAM verify/tests?
Not really. A few things to check: is your CAS latency being set the same on the northbridge as it's being set by MRS? Is the MA Map type correct? Is DRAM refresh being enabled correctly? Is NBXCFG correct (ie correctly set for ecc/parity, etc)? ECC should probably not be enabled for now even if your ram supports it, I think ECC requires some special init that isn't being done (yet). What happens if you don't perform the ram test? Boot up the factory BIOS, with the timings set manually to their largest values (or whatever values linuxbios is using), if your BIOS allows it, and compare the output lspci -nxxx -s 0:0.0 to dump_pci_device(0), and see if anything shows up. Once again, good luck ;)
-Corey
I've got the P2BXL board running using Uwe's tyan/s1846. Partial problem with using more then two banks of DRAM on this DFI P2BXL board. It's now running up until the point of elfboot.c as with the s1832/s1846 status. Below documents the bugs I've traced but provide no patches or solutions codewise. :-/
I've also found, 2 of the 3 SDRAM sticks I have, will only successfully make it to "booting..." (just prior to elfboot.c), the other stick of ram seems to always fail during verify/test.
So, one DRAM in DIMM BANK 0. Most times will get to "booting..." using Uwe's tyan/s1846 with this board. (I've further trouble shooted it to probably cheap sdram modules... as my Mushkin sticks from my tyan S1832 seems just fine maybe.)
I've found the major hang with the asus/p2b and found the problem lies within the asus/p2b/auto.c. I've removed lines & added lines similar to tyan/s1846/auto.c, but I think this really gets down to an anomoly with the ordering of the #includes! BUT. Both profiles will generate a 0xE7 during RAM Test/Verify.. guessing during the Test, but it's too fast to notice at what point. On the tyan/s1846/auto.c profile, there will be a *blip* of an 0xE7 on the post card and then 0x80 when it gets to "booting..." stage (just prior to elfboot.c). Then hang of course as we've already documented in the past because elfboot.c (RAM related we're guessing.)
On the asus/p2b/auto.c, when it gets to random areas within RAM Test/Verify (at the stage where the tyan/s1846/auto.c generates the *blip* of 0xE7) the asus/p2b/auto.c build will hang with the 0xE7. So.. this could be a good thing for the asus/p2b/auto.c configuration. The tyan/s1846/auto.c configuration is probably ignoring it.
(For those reading this, remember to replace the superio being used within tyan/s1846/auto.c with the winbond shown in asus/p2b/auto.c. There are currently 3 lines specifying the chip. Following shows the lines to modify and is not a patch but info/learning purposes only.
./src/mainboard/tyan/s1846/auto.c -#include "superio/nsc/pc87309/pc87309_early_serial.c" +#include "superio/winbond/w83977tf/w83977tf_early_serial.c" -#define SERIAL_DEV PNP_DEV(0x2e, PC87309_SP1) +#define SERIAL_DEV PNP_DEV(0x3f0, W83977TF_SP1) - pc87309_enable_serial(SERIAL_DEV, TTYS0_BASE); + w83977tf_enable_serial(SERIAL_DEV, TTYS0_BASE);
-- Roger http://www.eskimo.com/~roger/index.html Key fingerprint = 8977 A252 2623 F567 70CD 1261 640F C963 1005 1D61
Sun May 13 14:08:33 PDT 2007
-
Corey Osgood -
Marc Jones -
roger -
Uwe Hermann