| Submitter | Myles Watson |
|---|---|
| Date | 2009-12-04 17:10:11 |
| Message ID | <2831fecf0912040910v6f7a3c88vc188a0e4f3d14cb1@mail.gmail.com> |
| Download | mbox | patch |
| Permalink | /patch/629/ |
| State | Accepted |
| Headers | show |
Comments
> I applied the patch, but unfortunately, it still hangs in the same place. Did you check with hexdump to make sure it was effective? Does it hang in the same place with a cold boot, or only on warm reset? > > hexdump -C build/coreboot.rom | tail > > * > > 0007ff80 aa 00 44 50 c2 0f 97 61 aa 00 44 50 c2 0f 97 61 > |..DP...a..DP...a| > > * > > 0007ffa0 aa 00 44 50 c2 0f 97 61 00 00 00 00 00 00 00 00 > |..DP...a........| > > 0007ffb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > > * > > 0007ffd0 80 ff 0f 00 00 00 41 53 55 53 00 41 38 56 2d 45 > |......ASUS.A8V-E| > > 0007ffe0 20 53 45 00 2a 00 00 00 25 00 00 00 00 00 08 00 | > SE.*...%.......| > > 0007fff0 e9 11 00 ff ff 00 00 00 e9 5f 00 ff e0 ff fe ff > |........._......| > > 00080000 Thanks, Myles
On Fri, Dec 4, 2009 at 6:09 PM, Myles Watson <mylesgw@gmail.com> wrote: > >> I applied the patch, but unfortunately, it still hangs in the same place. > Did you check with hexdump to make sure it was effective? I now realize that the hexdump you sent is not the same as the one Rudolph Marek did. Mine matches yours, so that's wrong I guess. I had applied your patch, but I'm not sure where those last 128 bytes are supposed to come from. > > Does it hang in the same place with a cold boot, or only on warm reset? It hangs in exactly the same place both from cold boot and warm reset. > > >> > hexdump -C build/coreboot.rom | tail >> > * >> > 0007ff80 aa 00 44 50 c2 0f 97 61 aa 00 44 50 c2 0f 97 61 >> |..DP...a..DP...a| >> > * >> > 0007ffa0 aa 00 44 50 c2 0f 97 61 00 00 00 00 00 00 00 00 >> |..DP...a........| >> > 0007ffb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> |................| >> > * >> > 0007ffd0 80 ff 0f 00 00 00 41 53 55 53 00 41 38 56 2d 45 >> |......ASUS.A8V-E| >> > 0007ffe0 20 53 45 00 2a 00 00 00 25 00 00 00 00 00 08 00 | >> SE.*...%.......| >> > 0007fff0 e9 11 00 ff ff 00 00 00 e9 5f 00 ff e0 ff fe ff >> |........._......| >> > 00080000 > Thanks, > Myles > >
On Fri, Dec 4, 2009 at 5:05 PM, Jonathan Rogers <jonathanrrogers@gmail.com>wrote: > On Fri, Dec 4, 2009 at 6:09 PM, Myles Watson <mylesgw@gmail.com> wrote: > > > >> I applied the patch, but unfortunately, it still hangs in the same > place. > > Did you check with hexdump to make sure it was effective? > > I now realize that the hexdump you sent is not the same as the one > Rudolph Marek did. Mine matches yours, so that's wrong I guess. I had > applied your patch, but I'm not sure where those last 128 bytes are > supposed to come from. > That's good to realize. Try reverting romstrap.inc and romstrap.lds to 3110 since that one gets farther. Thanks, Myles
On Fri, Dec 4, 2009 at 5:09 PM, Myles Watson <mylesgw@gmail.com> wrote: > > > On Fri, Dec 4, 2009 at 5:05 PM, Jonathan Rogers <jonathanrrogers@gmail.com > > wrote: > >> On Fri, Dec 4, 2009 at 6:09 PM, Myles Watson <mylesgw@gmail.com> wrote: >> > >> >> I applied the patch, but unfortunately, it still hangs in the same >> place. >> > Did you check with hexdump to make sure it was effective? >> >> I now realize that the hexdump you sent is not the same as the one >> Rudolph Marek did. Mine matches yours, so that's wrong I guess. I had >> applied your patch, but I'm not sure where those last 128 bytes are >> supposed to come from. >> > That's good to realize. Try reverting romstrap.inc and romstrap.lds to > 3110 since that one gets farther. > I just looked, and those files haven't changed since then. At least you can compare the last 128 bytes from that image with your latest. As I read the file, it all looks correct. The table is there and the pointer to it is intact. Is it jumping to the "normal" image somehow? Since there is no normal image that would be bad. Myles
Hi,
I'm trying to build coreboot for the exact same board and getting to
the same point as Jonathan Rogers. I also tried with the patch and same
result it hangs at "now booting... fallback". I inserted some prints
and get till
else if (do_normal_boot()) {
printf_info("debug6");
goto normal_image;
any suggestions?
thx and have a nice weekend.
>
>> I applied the patch, but unfortunately, it still hangs in the same
>> place.
> Did you check with hexdump to make sure it was effective?
>
> Does it hang in the same place with a cold boot, or only on warm reset?
>
>
>> > hexdump -C build/coreboot.rom | tail
>> > *
>> > 0007ff80 aa 00 44 50 c2 0f 97 61 aa 00 44 50 c2 0f 97 61
>> |..DP...a..DP...a|
>> > *
>> > 0007ffa0 aa 00 44 50 c2 0f 97 61 00 00 00 00 00 00 00 00
>> |..DP...a........|
>> > 0007ffb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> |................|
>> > *
>> > 0007ffd0 80 ff 0f 00 00 00 41 53 55 53 00 41 38 56 2d 45
>> |......ASUS.A8V-E|
>> > 0007ffe0 20 53 45 00 2a 00 00 00 25 00 00 00 00 00 08 00 |
>> SE.*...%.......|
>> > 0007fff0 e9 11 00 ff ff 00 00 00 e9 5f 00 ff e0 ff fe ff
>> |........._......|
>> > 00080000
> Thanks,
> Myles
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
Am 05.12.2009 13:57, schrieb Knut Kujat: > Hi, > > I'm trying to build coreboot for the exact same board and getting to > the same point as Jonathan Rogers. I also tried with the patch and same > result it hangs at "now booting... fallback". I inserted some prints > and get till > > > > else if (do_normal_boot()) { > > printf_info("debug6"); > > goto normal_image; > > > > > > any suggestions? > "normal_image" might lead to nowhere in a kconfig build. Patrick
> -----Original Message----- > From: Knut Kujat [mailto:knuku@gap.upv.es] > Sent: Saturday, December 05, 2009 5:57 AM > To: Myles Watson > Cc: 'Jonathan Rogers'; coreboot@coreboot.org > Subject: Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE > > Hi, > > I'm trying to build coreboot for the exact same board and getting to > the same point as Jonathan Rogers. I also tried with the patch and same > result it hangs at "now booting... fallback". I inserted some prints > and get till > > else if (do_normal_boot()) { > > printf_info("debug6"); > > goto normal_image; Great. > any suggestions? There is no normal_image with Kconfig yet. The quick way to test would be to change all normal_image to fallback_image, or any other way to make sure it never jumps to normal_image. Thanks, Myles
Myles Watson escribió: > >> -----Original Message----- >> From: Knut Kujat [mailto:knuku@gap.upv.es] >> Sent: Saturday, December 05, 2009 5:57 AM >> To: Myles Watson >> Cc: 'Jonathan Rogers'; coreboot@coreboot.org >> Subject: Re: [coreboot] Coreboot fails to initialize on ASUS A8V-E SE >> >> Hi, >> >> I'm trying to build coreboot for the exact same board and getting to >> the same point as Jonathan Rogers. I also tried with the patch and same >> result it hangs at "now booting... fallback". I inserted some prints >> and get till >> >> else if (do_normal_boot()) { >> >> printf_info("debug6"); >> >> goto normal_image; >> > Great. > > >> any suggestions? >> > > There is no normal_image with Kconfig yet. The quick way to test would be > to change all normal_image to fallback_image, or any other way to make sure > it never jumps to normal_image. > Hello, worked fine now I'm getting a little further ;) : coreboot-2.3 Fri Dec 4 20:15:37 CET 2009 starting... now booting... real_main core0 started: now booting... Core0 started started ap apicid: SBLink=00 NC node|link=00 K8T890 found at LDT 00 Agreed on width: 01 CPU programmed to HT freq: 06 VIA HT caps: 0075 ht reset - soft reset coreboot-2. normal_image replaced with fallback_imageWelcome to the real_main! coreboot-2.3 Fri Dec 4 20:15:37 CET 2009 starting... now booting... real_main core0 started: now booting... Core0 started started ap apicid: SBLink=00 NC node|link=00 K8T890 found at LDT 00 Agreed on width: 01 CPU programmed to HT freq: 06 VIA HT caps: 0075 Current fid_cur: 0x10, fid_max: 0x10 Requested fid_new: 0x10 Debug: after init_fidvid_bsp Debug: after allow_all_aps_stop Debug: after fill_mem_ctrl Debug: after enable_smbus Debug: after memreset_setup Ram1.00 Ram2.00 Device error Device error No memory for this cpu Ram3 No memory but now it seems that coreboot doesn't find any ram. I already tried with patched Kconfig and without same result. thx, Knut Kujat > Thanks, > Myles > > >
> > worked fine now I'm getting a little further ;) : > Good. > coreboot-2.3 Fri Dec 4 20:15:37 CET 2009 > starting... > > now booting... > real_main > > core0 started: > now booting... Core0 started > started ap apicid: > SBLink=00 > NC node|link=00 > K8T890 found at LDT 00 Agreed on width: 01 CPU programmed to HT freq: 06 > VIA HT caps: 0075 > ht reset - > soft reset > > > coreboot-2. normal_image replaced with fallback_imageWelcome to the > real_main! > > coreboot-2.3 Fri Dec 4 20:15:37 CET 2009 starting... > now booting... real_main > core0 started: > now booting... Core0 started > started ap apicid: > SBLink=00 > NC node|link=00 > K8T890 found at LDT 00 Agreed on width: 01 CPU programmed to HT freq: 06 > VIA HT caps: 0075 > Current fid_cur: 0x10, fid_max: 0x10 > Requested fid_new: 0x10 > Debug: after init_fidvid_bsp > Debug: after allow_all_aps_stop > Debug: after fill_mem_ctrl > Debug: after enable_smbus > Debug: after memreset_setup > Ram1.00 > Ram2.00 > Device error > Device error > No memory for this cpu > Ram3 > No memory > > but now it seems that coreboot doesn't find any ram. I already tried with > patched Kconfig and without same result. > I haven't played with RAM initialization much. The "Device error" message is coming from the smbus, so I would try to see how that is configured and put more debugging statements in there. I see that enable_smbus ran, so I don't know what's missing. Hopefully someone who knows more will chime in. Is there a cmos option that could be causing trouble? I'd check that too since the board was choosing to do a normal boot. Thanks, Myles
Myles Watson escribió: > > > worked fine now I'm getting a little further ;) : > > Good. > > > coreboot-2.3 Fri Dec 4 20:15:37 CET 2009 > starting... > > now booting... > real_main > > core0 started: > now booting... Core0 started > started ap apicid: > SBLink=00 > NC node|link=00 > K8T890 found at LDT 00 Agreed on width: 01 CPU programmed to HT > freq: 06 VIA HT caps: 0075 > ht reset - > soft reset > > > coreboot-2. normal_image replaced with fallback_imageWelcome to > the real_main! > > coreboot-2.3 Fri Dec 4 20:15:37 CET 2009 starting... > now booting... real_main > core0 started: > now booting... Core0 started > started ap apicid: > SBLink=00 > NC node|link=00 > K8T890 found at LDT 00 Agreed on width: 01 CPU programmed to HT > freq: 06 VIA HT caps: 0075 > Current fid_cur: 0x10, fid_max: 0x10 > Requested fid_new: 0x10 > Debug: after init_fidvid_bsp > Debug: after allow_all_aps_stop > Debug: after fill_mem_ctrl > Debug: after enable_smbus > Debug: after memreset_setup > Ram1.00 > Ram2.00 > Device error > Device error > No memory for this cpu > Ram3 > No memory > > but now it seems that coreboot doesn't find any ram. I already > tried with patched Kconfig and without same result. > > > I haven't played with RAM initialization much. The "Device error" > message is coming from the smbus, so I would try to see how that is > configured and put more debugging statements in there. I see that > enable_smbus ran, so I don't know what's missing. Hopefully someone > who knows more will chime in. > > Is there a cmos option that could be causing trouble? I'd check that > too since the board was choosing to do a normal boot. > > Thanks, > Myles Hi, thanks for your help so far. I cleared the CMOS before restart but nothing. Ram1.00 setting up CPU00 northbridge registers done. Ram2.00 Debug: in smbus_read_byte Debug: after smbus_reset Debug: after SMBUS_DELAY (first) Debug: after smbus_wait-until_ready (first) Debug: after SMBUS_DELAY (second) Device error Debug: smbus_wait-until_ready (second) Debug: out smbus_read_byte Debug: in smbus_read_byte Debug: after smbus_reset Debug: after SMBUS_DELAY (first) Debug: after smbus_wait-until_ready (first) Debug: after SMBUS_DELAY (second) Debug: smbus_wait-until_ready (second) Debug: out smbus_read_byte Debug: in smbus_read_byte Debug: after smbus_reset Debug: after SMBUS_DELAY (first) Debug: after smbus_wait-until_ready (first) Debug: after SMBUS_DELAY (second) Device error Debug: smbus_wait-until_ready (second) Debug: out smbus_read_byte Debug: in smbus_read_byte Debug: after smbus_reset Debug: after SMBUS_DELAY (first) Debug: after smbus_wait-until_ready (first) Debug: after SMBUS_DELAY (second) Debug: smbus_wait-until_ready (second) Debug: out smbus_read_byte No memory for this cpu Ram3 No memory This board has 4 sockets but only 2 are populated with 1GB dimms each. Could the other empty two sockets be the device error, which is generated by the smbus_wait_until_ready function? But why would it say that there is no memory at all? Yet another question, I can see PRINT_DEBUG in vt8237r_early_smbus.c but i can't see them on the serial although I have the highest message level. Why? thx, Knut Kujat
> This board has 4 sockets but only 2 are populated with 1GB dimms each. Could > the other empty two sockets be the device error, which is generated by the > smbus_wait_until_ready function? But why would it say that there is no > memory at all? I don't know. > Yet another question, I can see PRINT_DEBUG in vt8237r_early_smbus.c but i > can't see them on the serial although I have the highest message level. Why? I think you're on the right track. from vt8237r.h: #if DEBUG_SMBUS == 1 #define PRINT_DEBUG(x) print_debug(x) #define PRINT_DEBUG_HEX16(x) print_debug_hex16(x) #else #define PRINT_DEBUG(x) #define PRINT_DEBUG_HEX16(x) #endif I'm guessing that DEBUG_SMBUS is not 1. Change it to #if 1 and recompile. Thanks, Myles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Try experimenting with the position of used memory slots. Maybe you just need to put DIMMS into right places ;) I think I used the slot closest to CPU then one empty and then the second DIM and then the closest to edge empty. Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksdkdYACgkQ3J9wPJqZRNVaygCfQDhss8CY0ZsWvtr9/yjxUnW4 elAAniuDIxlJq33LDiPB35M297F3mkSA =+f/r -----END PGP SIGNATURE-----
Rudolf Marek escribió: > Hi, > > Try experimenting with the position of used memory slots. Maybe you > just need to > put DIMMS into right places ;) I think I used the slot closest to CPU > then one > empty and then the second DIM and then the closest to edge empty. > > Rudolf > Hello, yes switching memory slots to "CPU yes no yes no" worked perfectly. Now I'm stucked with dev_enumeration more precisely scan_bus fails with a malloc error. I already had this error with PCI: 00:10.1 - 00:10.4 (the USB) I disabled them in the device tree with /device pci 10.1 off end /but now it fails again and i can't just disable the whole PCI bus 2 since the VGA is on it. PCI: 01:1d.0, bad id 0xffffffff PCI: 01:1e.0, bad id 0xffffffff PCI: 01:1f.0, bad id 0xffffffff POST: 0x25 PCI: pci_scan_bus returning with max=001 POST: 0x55 do_pci_scan_bridge returns max 1 do_pci_scan_bridge for PCI: 00:02.0 PCI: pci_scan_bus for bus 02 POST: 0x24 malloc Enter, size 1092, free_mem_ptr 0014bffc Error! malloc: Out of memory (free_mem_ptr >= free_mem_end_ptr)POST: 0xff Thanks again, without the maillist i would be lost! :)
> do_pci_scan_bridge returns max 1 > do_pci_scan_bridge for PCI: 00:02.0 > PCI: pci_scan_bus for bus 02 > POST: 0x24 > malloc Enter, size 1092, free_mem_ptr 0014bffc > Error! malloc: Out of memory (free_mem_ptr >= free_mem_end_ptr)POST: 0xff > Try increasing the heap size in Kconfig. Thanks, Myles
Myles Watson escribió: > > do_pci_scan_bridge returns max 1 > do_pci_scan_bridge for PCI: 00:02.0 > PCI: pci_scan_bus for bus 02 > POST: 0x24 > malloc Enter, size 1092, free_mem_ptr 0014bffc > Error! malloc: Out of memory (free_mem_ptr >= > free_mem_end_ptr)POST: 0xff > > Try increasing the heap size in Kconfig. > > Thanks, > Myles Morning :) Yip pushing the heap size to 0x40000 made the difference. But it still not booting :( Now it stucks at: POST: 0x88 Enabling resources... PCI: 00:18.0 cmd <- 00 PCI: 00:00.0 subsystem <- 00/00 PCI: 00:00.0 cmd <- 06 PCI: 00:00.1 cmd <- 06 PCI: 00:00.2 cmd <- 06 PCI: 00:00.3 cmd <- 06 PCI: 00:00.4 cmd <- 06 PCI: 00:00.5 cmd <- 06 PCI: 00:00.7 cmd <- 06 PCI: 00:01.0 bridge ctrl <- 0003 PCI: 00:01.0 cmd <- 07 PCI: 00:02.0 bridge ctrl <- 000b PCI: 00:02.0 cmd <- 07 <<<< Here it just stops and does nothing! according to lspci PCI: 00:02.0 is the K8T890 PCI to PCI Bridge Controller. Any hints? btw, I'm getting some errors like: PCI: 02:19.0 10 * [0xc8000000 - 0xcfffffff] prefmem PCI: 02:19.0 10 * [0xc8000000 - 0xcfffffff] prefmem !! Resource didn't fit !! aligned base ffffffffe0000000 size 8000000 limit febfffff ffffffffe7ffffff needs to be <= febfffff (limit) or like: ERROR: PCI: 00:11.5 10 io size: 0x0000000100 not assigned Do I have to be worried about them??
Knut Kujat escribió: > Myles Watson escribió: >> >> do_pci_scan_bridge returns max 1 >> do_pci_scan_bridge for PCI: 00:02.0 >> PCI: pci_scan_bus for bus 02 >> POST: 0x24 >> malloc Enter, size 1092, free_mem_ptr 0014bffc >> Error! malloc: Out of memory (free_mem_ptr >= >> free_mem_end_ptr)POST: 0xff >> >> Try increasing the heap size in Kconfig. >> >> Thanks, >> Myles > Morning :) > > Yip pushing the heap size to 0x40000 made the difference. But it still > not booting :( Now it stucks at: > POST: 0x88 > Enabling resources... > PCI: 00:18.0 cmd <- 00 > PCI: 00:00.0 subsystem <- 00/00 > PCI: 00:00.0 cmd <- 06 > PCI: 00:00.1 cmd <- 06 > PCI: 00:00.2 cmd <- 06 > PCI: 00:00.3 cmd <- 06 > PCI: 00:00.4 cmd <- 06 > PCI: 00:00.5 cmd <- 06 > PCI: 00:00.7 cmd <- 06 > PCI: 00:01.0 bridge ctrl <- 0003 > PCI: 00:01.0 cmd <- 07 > PCI: 00:02.0 bridge ctrl <- 000b > PCI: 00:02.0 cmd <- 07 <<<< Here it just stops > and does nothing! > > according to lspci PCI: 00:02.0 is the K8T890 PCI to PCI Bridge > Controller. Any hints? Hi again, It solves itself don't know how?! I just cleaned up some printfs recompiled and it started working till: POST: 0x89 Initializing CBMEM area to 0x7fff0000 (65536 bytes) Adding CBMEM entry as no. 1 Moving GDT to 7fff0200...ok High Tables Base is 7fff0000. POST: 0x9c Adding CBMEM entry as no. 2 ACPI: Writing ACPI tables at 7fff0400... ACPI: * FACS ACPI: * DSDT @ 7fff0508 Length 44e ACPI: * FADT ACPI: added table 1/32 Length now 40 ACPI: * MADT ACPI: added table 2/32 Length now 44 ACPI: * MCFG PCI: 00:00.5 missing resource: 61 POST: 0xff POST: 0xff is a bad thing right? So how do I fix this? THX, Knut Kujat
Sorry for spamming the maillist!!! but it stops again at: PCI: 00:02.0 cmd <- 07 I haven't changed anything! whats wrong? :( bye! Knut Kujat escribió: > Knut Kujat escribió: >> Myles Watson escribió: >>> >>> do_pci_scan_bridge returns max 1 >>> do_pci_scan_bridge for PCI: 00:02.0 >>> PCI: pci_scan_bus for bus 02 >>> POST: 0x24 >>> malloc Enter, size 1092, free_mem_ptr 0014bffc >>> Error! malloc: Out of memory (free_mem_ptr >= >>> free_mem_end_ptr)POST: 0xff >>> >>> Try increasing the heap size in Kconfig. >>> >>> Thanks, >>> Myles >> Morning :) >> >> Yip pushing the heap size to 0x40000 made the difference. But it >> still not booting :( Now it stucks at: >> POST: 0x88 >> Enabling resources... >> PCI: 00:18.0 cmd <- 00 >> PCI: 00:00.0 subsystem <- 00/00 >> PCI: 00:00.0 cmd <- 06 >> PCI: 00:00.1 cmd <- 06 >> PCI: 00:00.2 cmd <- 06 >> PCI: 00:00.3 cmd <- 06 >> PCI: 00:00.4 cmd <- 06 >> PCI: 00:00.5 cmd <- 06 >> PCI: 00:00.7 cmd <- 06 >> PCI: 00:01.0 bridge ctrl <- 0003 >> PCI: 00:01.0 cmd <- 07 >> PCI: 00:02.0 bridge ctrl <- 000b >> PCI: 00:02.0 cmd <- 07 <<<< Here it just stops >> and does nothing! >> >> according to lspci PCI: 00:02.0 is the K8T890 PCI to PCI Bridge >> Controller. Any hints? > Hi again, > > It solves itself don't know how?! I just cleaned up some printfs > recompiled and it started working till: > POST: 0x89 > Initializing CBMEM area to 0x7fff0000 (65536 bytes) > Adding CBMEM entry as no. 1 > Moving GDT to 7fff0200...ok > High Tables Base is 7fff0000. > POST: 0x9c > Adding CBMEM entry as no. 2 > ACPI: Writing ACPI tables at 7fff0400... > ACPI: * FACS > ACPI: * DSDT @ 7fff0508 Length 44e > ACPI: * FADT > ACPI: added table 1/32 Length now 40 > ACPI: * MADT > ACPI: added table 2/32 Length now 44 > ACPI: * MCFG > PCI: 00:00.5 missing resource: 61 > POST: 0xff > > POST: 0xff is a bad thing right? So how do I fix this? > > THX, > Knut Kujat >
On Thu, Dec 10, 2009 at 3:33 AM, Knut Kujat <knuku@gap.upv.es> wrote: > Sorry for spamming the maillist!!! > > but it stops again at: PCI: 00:02.0 cmd <- 07 I haven't changed anything! > whats wrong? :( > > Sounds like you're still having memory problems. Are you using util/crosgcc? > Error! malloc: Out of memory (free_mem_ptr >= free_mem_end_ptr)POST: 0xff >> > Try increasing the heap size in Kconfig. > > Thanks, > Myles > > Morning :) > > Yip pushing the heap size to 0x40000 made the difference. But it still not > booting :( Now it stucks at: > > You could try increasing the stack size too. Thanks, Myles
On Thu, Dec 10, 2009 at 2:33 AM, Knut Kujat <knuku@gap.upv.es> wrote: > Sorry for spamming the maillist!!! > > but it stops again at: PCI: 00:02.0 cmd <- 07 I haven't changed anything! > whats wrong? :( random halts and errors --> I think myles is right grow stack but maybe it is memory. ron
ron minnich escribió: > On Thu, Dec 10, 2009 at 2:33 AM, Knut Kujat <knuku@gap.upv.es> wrote: > >> Sorry for spamming the maillist!!! >> >> but it stops again at: PCI: 00:02.0 cmd <- 07 I haven't changed anything! >> whats wrong? :( >> > > random halts and errors --> I think myles is right grow stack but > maybe it is memory. > > ron > no, I don't use crossgcc I tried to install it with ./buildgcc but it fails on downloading the second tar ball. The weird thing is that it exactly once passed this point and it got to build the apci table. But as I said that only occurred once and trust me I tried it a whole bunch of times. I switched my dimms several times in different slots I tried with only one to see if the other is broken or something but nothing. So I guess next thing will be stack size. Thanks, Knut Kujat
Knut Kujat escribió: > ron minnich escribió: >> On Thu, Dec 10, 2009 at 2:33 AM, Knut Kujat <knuku@gap.upv.es> wrote: >> >>> Sorry for spamming the maillist!!! >>> >>> but it stops again at: PCI: 00:02.0 cmd <- 07 I haven't changed anything! >>> whats wrong? :( >>> >> >> random halts and errors --> I think myles is right grow stack but >> maybe it is memory. >> >> ron >> > no, I don't use crossgcc I tried to install it with ./buildgcc but it > fails on downloading the second tar ball. The weird thing is that it > exactly once passed this point and it got to build the apci table. But > as I said that only occurred once and trust me I tried it a whole > bunch of times. I switched my dimms several times in different slots I > tried with only one to see if the other is broken or something but > nothing. So I guess next thing will be stack size. > > Thanks, > Knut Kujat Hi, I tried pushing the stuck to 2000 4000 and even 20000 but nothing it still stucks at the same place: setting up some printk I found out that it hangs : void pci_write_config16(device_t dev, unsigned where, uint16_t val) { struct bus *pbus = get_pbus(dev); ops_pci_bus(pbus)->write16(pbus, dev->bus->secondary, dev->path.pci.devfn, where, val); <<<<<< HERE!! } btw, what do you mean by memory problem because as I said before I already switched my dimms whithout any results. I attached the whole boot sequence. I really appreciate your help, thx! Knut Kujat.
> I tried pushing the stuck to 2000 4000 and even 20000 but nothing it still > stucks at the same place: setting up some printk I found out that it hangs : > > void pci_write_config16(device_t dev, unsigned where, uint16_t val) > { > struct bus *pbus = get_pbus(dev); > ops_pci_bus(pbus)->write16(pbus, dev->bus->secondary, > dev->path.pci.devfn, where, val); <<<<<< HERE!! > } > I think your problem is earlier. This just happens to be where it catches up with you. > > btw, what do you mean by memory problem because as I said before I already > switched my dimms whithout any results. > I meant that it's possible that RAM is not initialized correctly. Sometimes cache will get you a long ways. > I attached the whole boot sequence. > Thanks. The device enumeration looks wrong. There are a lot of devices that are found, and there are a lot of sequences like this: Capability: type 0x10 @ 0x58 Capability: type 0x01 @ 0x50 Capability: type 0x10 @ 0x58 Capability: type 0x01 @ 0x50 Capability: type 0x10 @ 0x58 Capability: type 0x01 @ 0x50 Could you send an lspci -tvnn of your board? I really appreciate your help, thx! > No problem. Myles
Myles Watson escribió: > > I tried pushing the stuck to 2000 4000 and even 20000 but nothing > it still stucks at the same place: setting up some printk I found > out that it hangs : > > void pci_write_config16(device_t dev, unsigned where, uint16_t val) > { > struct bus *pbus = get_pbus(dev); > ops_pci_bus(pbus)->write16(pbus, dev->bus->secondary, > dev->path.pci.devfn, where, val); <<<<<< HERE!! > } > > I think your problem is earlier. This just happens to be where it > catches up with you. aha, ok! > > > > btw, what do you mean by memory problem because as I said before I > already switched my dimms whithout any results. > > I meant that it's possible that RAM is not initialized correctly. > Sometimes cache will get you a long ways. > > > I attached the whole boot sequence. > > Thanks. The device enumeration looks wrong. There are a lot of > devices that are found, and there are a lot of sequences like this: > > Capability: type 0x10 @ 0x58 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x01 @ 0x50 > Capability: type 0x10 @ 0x58 > Capability: type 0x01 @ 0x50 > > Could you send an lspci -tvnn of your board? Of course, please find it attached. > > I really appreciate your help, thx! > > No problem. > Myles > THX, Knut Kujat -[0000:00]-+-00.0 VIA Technologies, Inc. K8T890 Host Bridge [1106:0238] +-00.1 VIA Technologies, Inc. K8T890 Host Bridge [1106:1238] +-00.2 VIA Technologies, Inc. K8T890 Host Bridge [1106:2238] +-00.3 VIA Technologies, Inc. K8T890 Host Bridge [1106:3238] +-00.4 VIA Technologies, Inc. K8T890 Host Bridge [1106:4238] +-00.5 VIA Technologies, Inc. K8T890 I/O APIC Interrupt Controller [1106:5238] +-00.7 VIA Technologies, Inc. K8T890 Host Bridge [1106:7238] +-01.0-[0000:01]-- +-02.0-[0000:02]--+-00.0 ATI Technologies Inc RV370 [Sapphire X550 Silent] [1002:5b63] | \-00.1 ATI Technologies Inc RV370 secondary [Sapphire X550 Silent] [1002:5b73] +-03.0-[0000:03]-- +-03.1-[0000:04]-- +-03.2-[0000:05]----00.0 Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit Ethernet Controller [11ab:4362] +-03.3-[0000:06]-- +-0c.0 3Com Corporation 3c905B 100BaseTX [Cyclone] [10b7:9055] +-0f.0 VIA Technologies, Inc. VIA VT6420 SATA RAID Controller [1106:3149] +-0f.1 VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] +-10.0 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] +-10.1 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] +-10.2 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] +-10.3 VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller [1106:3038] +-10.4 VIA Technologies, Inc. USB 2.0 [1106:3104] +-11.0 VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] [1106:3227] +-11.5 VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller [1106:3059] +-11.6 VIA Technologies, Inc. AC'97 Modem Controller [1106:3068] +-18.0 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] +-18.1 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] +-18.2 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] \-18.3 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103]
Hi, Sorry I did not find time to test on mine board (if it still boots). Your PCI stuff looks normal. Can you try with just one DDR module? Rudolf
Rudolf Marek escribió: > Hi, > > Sorry I did not find time to test on mine board (if it still boots). > Your PCI stuff looks normal. Can you try with just one DDR module? > > Rudolf Hello, I already tried switching DDR modules in different positions and of course with only one to test if one of them is broken. But no changes! :( Thanks, Knut Kujat
Hi, Can you test with revision 3593? I think you will need to do - buildtarget stuff ;) Rudolf
Rudolf Marek escribió: > Hi, > > Can you test with revision 3593? OK, I'll try it ! > > I think you will need to do - buildtarget stuff ;) > > Rudolf Thx
Rudolf Marek escribió: > Hi, > > Can you test with revision 3593? > > I think you will need to do - buildtarget stuff ;) > > Rudolf > Hi, It fails compiling and don't know exactly why: gcc -m32 -nostdlib -nostartfiles -static -o coreboot -T ldscript.ld crt0.o nm -n coreboot | sort > coreboot.map objcopy --gap-fill 0xff -O binary coreboot coreboot.strip gcc -o buildrom /home/knuku/Documents/OldCor/coreboot/coreboot-v2/util/buildrom/buildrom.c cp /home/knuku/bios.bin.elf payload ./buildrom coreboot.strip coreboot.rom payload 0x20000 0x40000 coreboot.strip: Value too large for defined data type make[1]: *** [coreboot.rom] Error 2 make[1]: se sale del directorio `/home/knuku/Documents/OldCor/coreboot/coreboot-v2/targets/asus/a8v-e_se/asus_a8v-e_se/normal' make: *** [normal/coreboot.rom] Error 1 I did: ./buildtarget asus/a8v-e_se cd asus/a8v-e_se (set the right path to the payload in Config.lb) cd asus_a8v-e_se make I tried with the same payload I did with the newer revisions filo.elf and then I tried a already compiled seabios elf. thx, Knut Kujat
Knut Kujat escribió: > Rudolf Marek escribió: > >> Hi, >> >> Can you test with revision 3593? >> >> I think you will need to do - buildtarget stuff ;) >> >> Rudolf >> >> > Hi, > > It fails compiling and don't know exactly why: > > gcc -m32 -nostdlib -nostartfiles -static -o coreboot -T ldscript.ld crt0.o > nm -n coreboot | sort > coreboot.map > objcopy --gap-fill 0xff -O binary coreboot coreboot.strip > gcc -o buildrom > /home/knuku/Documents/OldCor/coreboot/coreboot-v2/util/buildrom/buildrom.c > cp /home/knuku/bios.bin.elf payload > ./buildrom coreboot.strip coreboot.rom payload 0x20000 0x40000 > coreboot.strip: Value too large for defined data type > make[1]: *** [coreboot.rom] Error 2 > make[1]: se sale del directorio > `/home/knuku/Documents/OldCor/coreboot/coreboot-v2/targets/asus/a8v-e_se/asus_a8v-e_se/normal' > make: *** [normal/coreboot.rom] Error 1 > > I did: > > ./buildtarget asus/a8v-e_se > cd asus/a8v-e_se > (set the right path to the payload in Config.lb) > cd asus_a8v-e_se > make > > I tried with the same payload I did with the newer revisions filo.elf > and then I tried a already compiled seabios elf. > > thx, > Knut Kujat > > > > > Hi, I made it compile and it worked I get till filo payload after that it stucks because: Error 18: Selected cylinder exceeds maximum supported by BIOS but I thing thats a minor problem the most important thing is that the old revision worked. thx, Knut Kujat
Hi, Good news! Please can you try the newer once? Also, I would recommend to use seabios and ./buildtarget build method for this board because I think kconfig was not tested. I would suggest to go up to revision like 4096 ;) or go like binary search to find out where it broke. So if 4096 works go to 4500 etc else go to 3600... etc You could try to run Seabios as payload. I will try to test the board next week. Will be back Sunday night. Folks are often on IRC but you need to be more patient. Rudolf
Rudolf Marek escribió: > Hi, > > Good news! > > Please can you try the newer once? Also, I would recommend to use > seabios and ./buildtarget build method for this board because I think > kconfig was not tested. > > I would suggest to go up to revision like 4096 ;) or go like binary > search to find out where it broke. So if 4096 works go to 4500 etc > else go to 3600... etc OK, will try it! > > You could try to run Seabios as payload. I will try to test the board > next week. > > Will be back Sunday night. Folks are often on IRC but you need to be > more patient. Yes I know! not my strength ;) > > Rudolf > Thx, Knut Kujat
> I made it compile and it worked I get till filo payload after that it > stucks because: > Error 18: Selected cylinder exceeds maximum supported by BIOS > > but I thing thats a minor problem the most important thing is that the old > revision worked. > I'd like to see it work for you with Kconfig. Could you send me a working log for me to compare with the last one you sent me? Thanks, Myles
Knut Kujat wrote: > no, I don't use crossgcc I tried to install it with ./buildgcc but > it fails on downloading the second tar ball. I just fixed this in r4977. //Peter
Myles Watson escribió: > > I made it compile and it worked I get till filo payload after that > it stucks because: > Error 18: Selected cylinder exceeds maximum supported by BIOS > > but I thing thats a minor problem the most important thing is that > the old revision worked. > > > I'd like to see it work for you with Kconfig. Could you send me a > working log for me to compare with the last one you sent me? Yes, of course. Please find it attached. > > Thanks, > Myles Thx, Knut Kujat
Myles Watson escribió: > > I made it compile and it worked I get till filo payload after that > it stucks because: > Error 18: Selected cylinder exceeds maximum supported by BIOS > > but I thing thats a minor problem the most important thing is that > the old revision worked. > > > I'd like to see it work for you with Kconfig. Could you send me a > working log for me to compare with the last one you sent me? > > Thanks, > Myles Hi again, here is a funny twist, I tried out revision 4977 building it with Kconfig and nothing still not working! But then I tried the buildtarget system with the same revision and it worked perfectly it boots and everything seems to work except the soundcard huu and I haven't tried out my NIC. I send you two log files one with the boot process using Kconfig (as far as I could get) and using buildtarget. bye and thx, Knut Kujat
Patch
Index: svn/src/mainboard/asus/a8v-e_se/Kconfig =================================================================== --- svn.orig/src/mainboard/asus/a8v-e_se/Kconfig +++ svn/src/mainboard/asus/a8v-e_se/Kconfig @@ -2,13 +2,13 @@ config BOARD_ASUS_A8V_E_SE bool "A8V-E SE" select ARCH_X86 select CPU_AMD_SOCKET_939 + select K8_HT_FREQ_1G_SUPPORT select NORTHBRIDGE_AMD_AMDK8 select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX select SOUTHBRIDGE_VIA_VT8237R select SUPERIO_WINBOND_W83627EHG select USE_PRINTK_IN_CAR select USE_DCACHE_RAM - select HAVE_HARD_RESET select IOAPIC select HAVE_ACPI_TABLES select HAVE_MP_TABLE @@ -41,7 +41,7 @@ config APIC_ID_OFFSET config SB_HT_CHAIN_ON_BUS0 int - default 2 + default 1 depends on BOARD_ASUS_A8V_E_SE config SB_HT_CHAIN_UNITID_OFFSET_ONLY @@ -66,7 +66,7 @@ config MAINBOARD_PART_NUMBER config HW_MEM_HOLE_SIZEK hex - default 0x100000 + default 0 depends on BOARD_ASUS_A8V_E_SE config MAX_CPUS @@ -81,7 +81,7 @@ config MAX_PHYSICAL_CPUS config HT_CHAIN_END_UNITID_BASE hex - default 0x0 + default 0x20 depends on BOARD_ASUS_A8V_E_SE config HT_CHAIN_UNITID_BASE @@ -94,9 +94,9 @@ config USE_INIT default n depends on BOARD_ASUS_A8V_E_SE -config SB_HT_CHAIN_ON_BUS0 - int - default 2 +config HAVE_OPTION_TABLE + bool + default n depends on BOARD_ASUS_A8V_E_SE config IRQ_SLOT_COUNT Index: svn/src/mainboard/asus/a8v-e_se/Makefile.inc =================================================================== --- svn.orig/src/mainboard/asus/a8v-e_se/Makefile.inc +++ svn/src/mainboard/asus/a8v-e_se/Makefile.inc @@ -11,6 +11,7 @@ obj-$(CONFIG_GENERATE_ACPI_TABLES) += ac initobj-y += crt0.o # FIXME in $(top)/Makefile crt0-y += ../../../../src/cpu/x86/16bit/entry16.inc +crt0-y += ../../../../src/southbridge/via/k8t890/romstrap.inc crt0-y += ../../../../src/cpu/x86/32bit/entry32.inc crt0-y += ../../../../src/cpu/x86/16bit/reset16.inc crt0-y += ../../../../src/arch/i386/lib/id.inc @@ -19,6 +20,7 @@ crt0-y += auto.inc ldscript-y += ../../../../src/arch/i386/init/ldscript_fallback_cbfs.lb ldscript-y += ../../../../src/cpu/x86/16bit/entry16.lds +ldscript-y += ../../../../src/southbridge/via/k8t890/romstrap.lds ldscript-y += ../../../../src/cpu/x86/16bit/reset16.lds ldscript-y += ../../../../src/arch/i386/lib/id.lds ldscript-y += ../../../../src/arch/i386/lib/failover.lds