On Monday 23 January 2012 22:35:22 Scott Duplichan wrote:
Prakash Punnoor wrote:
]So, I cannot make coreboot boot. On cold start it seems to hang in ] ]src/southbridge/amd/sb700/reset.c ] ]in soft_reset. set_bios_reset seems sucessful, but I get no post code after
]outb(0x06, 0x0cf9). Any idea, what I can try?
Maybe the reset is just causing your port 80 routing to be lost. You need to execute some port 80 enable and routing code as early as possible. Is your port 80 card PCI or LPC? For the LPC type, I believe you only have to set 'Port enable for IO port 80h' (bit 5 of pci config register 4Ah on device 14h, function 3). To route port 80 to PCI, I think you have to set 'IO Enable' (bit 0 of PCI config register 4 on device 14h, function 4).
Sounds reasonable. It is a PCI port 80 card. I'll try that when I find time. BTW, could you explain what happens after soft_reset? Will coreboot run again from start? At least the following "die(...)" statement (romstage.c cache_as_ram_main) suggests that program flow should NOT get there. So, if coreboots runs again from start, why doesn't it enable port 80 again like it did initially?
Thanks,
Prakash
Prakash Punnoor wrote:
]BTW, could you explain what happens after soft_reset? Will coreboot run ]again from start?
Yes, the CF9 soft reset starts execution at the reset vector same as a cold boot.
] At least the following "die(...)" statement (romstage.c ]cache_as_ram_main) suggests that program flow should NOT get there. So, if ]coreboots runs again from start, why doesn't it enable port 80 again like ]it did initially?
I am not sure. But the important function is sb7xx_51xx_pci_port80(), called from line 90 of romstage.c. It looks like that function does everything needed to enable PCI port 80. You could try calling the function unconditionally and see what happens.
Thanks, Scott
]Thanks, ] ]Prakash
Hi,
On Tuesday 24 January 2012 22:26:31 Scott Duplichan wrote:
Prakash Punnoor wrote:
]BTW, could you explain what happens after soft_reset? Will coreboot run ]again from start?
Yes, the CF9 soft reset starts execution at the reset vector same as a cold boot.
ah, thanks for the confirmation.
] At least the following "die(...)" statement (romstage.c ]cache_as_ram_main) suggests that program flow should NOT get there. So, if ]coreboots runs again from start, why doesn't it enable port 80 again like ]it did initially?
I am not sure. But the important function is sb7xx_51xx_pci_port80(), called from line 90 of romstage.c. It looks like that function does everything needed to enable PCI port 80. You could try calling the function unconditionally and see what happens.
Unfortunately that didn't help. So maybe coreboot isn't reaching cache_as_ram_main after soft_reset anymore. I commented out the call to soft_reset (and die) and now coreboot runs till the device init as on "warm start". Any other ideas how to make soft_reset work?
Cheers,
Prakash
On Friday 27 January 2012 12:08:01 Prakash Punnoor wrote:
On Tuesday 24 January 2012 22:26:31 Scott Duplichan wrote:
Prakash Punnoor wrote: ] At least the following "die(...)" statement (romstage.c ]cache_as_ram_main) suggests that program flow should NOT get there. So, if ]coreboots runs again from start, why doesn't it enable port 80 again like ]it did initially?
I am not sure. But the important function is sb7xx_51xx_pci_port80(), called from line 90 of romstage.c. It looks like that function does everything needed to enable PCI port 80. You could try calling the function unconditionally and see what happens.
Unfortunately that didn't help. So maybe coreboot isn't reaching cache_as_ram_main after soft_reset anymore. I commented out the call to soft_reset (and die) and now coreboot runs till the device init as on "warm start". Any other ideas how to make soft_reset work?
Yay, I think I solved this problem. Some amd functions are depending on the cpu type, which are read out at a different place:
diff --git a/src/northbridge/amd/amdfam10/raminit_amdmct.c b/src/northbridge/amd/amdfam10/raminit_amdmct.c index 0c01cf1..0d7e91e 100644 --- a/src/northbridge/amd/amdfam10/raminit_amdmct.c +++ b/src/northbridge/amd/amdfam10/raminit_amdmct.c @@ -197,6 +197,7 @@ u32 mctGetLogicalCPUID(u32 Node) ret = AMD_RB_C2; break; case 0x10043: + case 0x10053: ret = AMD_RB_C3; break; case 0x10062:
According to my research the RB C3 ist closest to my BL C3 and with this patch soft_reset seems to work now. The other problems still remains, ie
- seabios payload: no gfx output, but postcode is F8 - grub2 payload, coreboot initialized option ROM: infinte reset loop (but now "warm start" and cold start behaviour is identical).
I might try putting in a delay for the post code function, so I can wrtie down the last post code in the reset loop...
Cheers,
Prakash
Prakash Punnoor wrote:
Yay, I think I solved this problem.
Nice work!
- seabios payload: no gfx output, but postcode is F8
Focus on this. What is the serial output from coreboot and SeaBIOS?
- grub2 payload, coreboot initialized option ROM: infinte reset loop
(but now "warm start" and cold start behaviour is identical).
coreboot does not provide a BIOS environment like what is expected by VGA BIOSes. SeaBIOS is really the best way to try to make the VGA BIOS run, at least to begin with. Once that is working reliably you can try your luck with YABEL in coreboot.
//Peter
On 29.01.2012 17:50, Peter Stuge wrote:
Prakash Punnoor wrote:
- seabios payload: no gfx output, but postcode is F8
Focus on this. What is the serial output from coreboot and SeaBIOS?
That's the thing: I don't have a serial port on this mainboard, that's why I had to do painful post code debugging...
- grub2 payload, coreboot initialized option ROM: infinte reset loop
(but now "warm start" and cold start behaviour is identical).
coreboot does not provide a BIOS environment like what is expected by VGA BIOSes. SeaBIOS is really the best way to try to make the VGA BIOS run, at least to begin with. Once that is working reliably you can try your luck with YABEL in coreboot.
Oh ok, I didn't know that. Seems I have to look into seabios to find out what's going on now.
Thanks,
Prakash
Prakash Punnoor wrote:
- seabios payload: no gfx output, but postcode is F8
Focus on this. What is the serial output from coreboot and SeaBIOS?
That's the thing: I don't have a serial port on this mainboard, that's why I had to do painful post code debugging...
Maybe you can use some of the other methods for debug output. USB Debug device or RTL8029?
For serial output from SeaBIOS or later coreboot stages a PCI based serial port would also work.
//Peter
On Sunday 29 January 2012 19:38:47 Peter Stuge wrote:
Prakash Punnoor wrote:
- seabios payload: no gfx output, but postcode is F8
Focus on this. What is the serial output from coreboot and SeaBIOS?
That's the thing: I don't have a serial port on this mainboard, that's why I had to do painful post code debugging...
Maybe you can use some of the other methods for debug output. USB Debug device or RTL8029?
Thx for the hints. I knew about the USB debug device, but it seems too costly and also there is no guarantee it will work. But I have an ancient RTL8029AS which I tried. I didn't get any output, though. I configured it properly in menuconfig. (I didn't change the default ioport. Linux chooses 0xbf00, but 0xe00 seems to be free, as well...) Do I have to call some function in the code to enable console output via ethernet? I checked the connection in Linux and it worked. (I use a cross-over cable, btw.)
For serial output from SeaBIOS or later coreboot stages a PCI based serial port would also work.
Ok, this would be my second option if above doesn't work.
Thanks,
Prakash