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.comwrote:
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
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: 0xffTry 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: 0xffTry 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: 0xffTry 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?
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
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
On Mon, Dec 14, 2009 at 4:03 AM, Knut Kujat knuku@gap.upv.es wrote:
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.
Perfect. There is at least one major problem there. The drivers for the k8t890 weren't being built. In the log file you can see that the ops lines are missing for the Kconfig build.
Try the attached patch.
Signed-off-by: Myles Watson mylesgw@gmail.com
Thanks, Myles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thank you.
I tried to make it work here too. I can confirm now both versions actually boots. I had to disable the ROM execution inside coreboot - the VGA BIOS did something bad.
The only remaining issue is normal/fallback stuff. I had to disable the normal execution. It does not even work with buildtarget. Otherwise the board boots fine. It looks once I had some troubles with PCI resource allocation inside linux but I was not able to reproduce that.
Knut please juts save the .config and do make distclean restore the .config make
eventually there can be one more hidden file .xcompile or something which did smth wrong to the build too.
Knut, if you like to have CPU powersafe working please let me know. We dont have automatic generation code for the old family which is hardwired anyway. You will need to copy the setup from orig bios DSDT/SSDT.
Myles, Acking your patch here.
Acked-by: Rudolf Marek r.marek@assembler.cz
Commited with:
+config HEAP_SIZE + hex + default 0x40000 + depends on BOARD_ASUS_A8V_E_SE +
Committed revision 4978.
Rudolf
Knut please juts save the .config and do make distclean restore the .config make
eventually there can be one more hidden file .xcompile or something which did smth wrong to the build too.
I should probably change that back. It was giving me problems before, so I made it so that .xcompile was only removed on distclean. It probably makes more sense to have it erased on make clean.
Myles, Acking your patch here.
Acked-by: Rudolf Marek r.marek@assembler.cz
Thanks for testing and committing it.
Commited with:
+config HEAP_SIZE
- hex
- default 0x40000
- depends on BOARD_ASUS_A8V_E_SE
Was this still needed with the drivers compiled in? I was hoping that the reason the heap was too small was because so many devices had to be allocated. At some point in the future we might want to make devices take up less RAM. 1092 bytes (0x444) seems like a lot, especially as we want to put fewer devices explicitly in the device tree, and more will need to be dynamically allocated.
PCI: 00:00.0 [1106/0238] enabled malloc Enter, size 1092, free_mem_ptr 00138000 PCI: 00:00.1 [1106/1238] enabled malloc Enter, size 1092, free_mem_ptr 00138444 PCI: 00:00.2 [1106/2238] enabled malloc Enter, size 1092, free_mem_ptr 00138888 PCI: 00:00.3 [1106/3238] enabled malloc Enter, size 1092, free_mem_ptr 00138ccc
Thanks, Myles
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Was this still needed with the drivers compiled in? I was hoping that the reason the heap was too small was because so many devices had to be allocated. At some point in the future we might want to make devices take up less RAM. 1092 bytes (0x444) seems like a lot, especially as we want to put fewer devices explicitly in the device tree, and more will need to be dynamically allocated.
Yes it was needed. Otherwise it would not boot.
free_mem_ptr started at 140000 end was 147770
Like ~31KB total comparing the ptrs from bootlog start/end.
What about the failover? Remove? Fix? Ideas?
Thanks,
Rudolf
Was this still needed with the drivers compiled in? I was hoping that
the
reason the heap was too small was because so many devices had to be allocated. At some point in the future we might want to make devices
take
up less RAM. 1092 bytes (0x444) seems like a lot, especially as we want
to
put fewer devices explicitly in the device tree, and more will need to
be
dynamically allocated.
Yes it was needed. Otherwise it would not boot.
free_mem_ptr started at 140000 end was 147770
Like ~31KB total comparing the ptrs from bootlog start/end.
I should have looked at the total and the old value. You're right.
What about the failover? Remove? Fix? Ideas?
Unfortunately I don't have a clear sense of the failover plans for Kconfig builds. I think we should at least remove it in the case of a Kconfig build. I hope the old build way doesn't live long enough to justify fixing it.
Thanks, Myles
Rudolf Marek escribió:
Thank you.
I tried to make it work here too. I can confirm now both versions actually boots. I had to disable the ROM execution inside coreboot - the VGA BIOS did something bad.
The only remaining issue is normal/fallback stuff. I had to disable the normal execution. It does not even work with buildtarget. Otherwise the board boots fine. It looks once I had some troubles with PCI resource allocation inside linux but I was not able to reproduce that.
Knut please juts save the .config and do make distclean restore the .config make
eventually there can be one more hidden file .xcompile or something which did smth wrong to the build too.
Knut, if you like to have CPU powersafe working please let me know. We dont have automatic generation code for the old family which is hardwired anyway. You will need to copy the setup from orig bios DSDT/SSDT.
No, not necessary but thank you!
Myles, Acking your patch here.
Acked-by: Rudolf Marek r.marek@assembler.cz
Commited with:
+config HEAP_SIZE
- hex
- default 0x40000
- depends on BOARD_ASUS_A8V_E_SE
Committed revision 4978.
Rudolf
Hello everyone,
yes I can confirm that the Kconfig build method work for me too. As Rudolf said I had to disable VGA ROM as well otherwise it will came up with a exception error. It's necessary to have "Serial port console output" set to yes or it won't compile.
Now I will start the next Board a Supermicro H8QME-2+ :) see how this works...
bye and thank you all!!
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
-
Jonathan Rogers -
Knut Kujat -
Myles Watson -
Patrick Georgi -
Peter Stuge -
ron minnich -
Rudolf Marek