Re: [coreboot] alix1c and v3
On Jan 29, 2008 12:00 AM, ron minnich [EMAIL PROTECTED] wrote: And this is bad too. in setup_realmode_idt -- both v2 and v3 ... /* debug handler - useful to set a programmable delay between instructions if the TF bit is set upon call to real mode */ idts[1].cs = 0; idts[1].offset = 16384; memcpy((void *)16384, debughandle, end_debughandle - debughandle); And that certainly made things better, taking out that blind memcpy. We're still getting the weird error on biosint but ... Back from phase 2 Show all devs... root(Root Device): enabled 1 have_resources 0 initialized 0 cpus: Unknown device path type: 0 cpus(): enabled 1 have_resources 0 initialized 0 device0_0(PCI: 00:01.0): enabled 1 have_resources 0 initialized 0 southbridge(PCI: 00:0f.1): enabled 1 have_resources 0 initialized 0 superio: Unknown device path type: 0 superio(): enabled 0 have_resources 0 initialized 0 domain0(PCI_DOMAIN: ): enabled 1 have_resources 0 initialized 0 done show all devs Phase 3: Enumerating buses... dev_phase3_scan: scanning root(Root Device) scan_static_bus for root (Root Device) cpus: Unknown device path type: 0 cpus() enabled dev_phase5: device0_0(PCI: 00:01.0) missing ops dev_phase5: southbridge(PCI: 00:0f.1) missing ops domain0(PCI_DOMAIN: ) enabled domain0(PCI_DOMAIN: ) scanning... dev_phase3_scan: scanning domain0(PCI_DOMAIN: ) pci_scan_bus start bus 0xbc60, bus-dev 0xba20 PCI: pci_scan_bus for bus 00 pci_scan_bus: old_devices 0xbd20, dev for this bus 0xba20 (domain0) PCI: scan devfn 0x0 to 0xff PCI: devfn 0x0 pci_scan_get_dev: list is 0x00087ea8, *list is 0xbd20 pci_scan_get_dev: check dev device0_0 pci_scan_get_dev: check dev device0_0 it has devfn 0x08 pci_scan_get_dev: check dev southbridge pci_scan_get_dev: check dev southbridge it has devfn 0x79 pci_scan_get_dev: check dev superio superio: Unknown device path type: 0 pci_scan_get_dev: child superio() not a pci device: it's type 0 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x0, bad id 0x PCI: pci_scan_bus pci_probe_dev returns dev 0x(c) PCI: devfn 0x8 pci_scan_get_dev: list is 0x00087ea8, *list is 0xbd20 pci_scan_get_dev: check dev device0_0 pci_scan_get_dev: check dev device0_0 it has devfn 0x08 PCI: pci_scan_bus pci_scan_get_dev returns dev device0_0 find_constructor: find PCI: 1022:2080 find_constructor: check all_constructors[i] 0xc700 find_constructor: cons 0xc700, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0xc714, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0xc728, cons id PCI: 1022:2080 find_constructor: match PCI: 00:01.0 id PCI: 1022:2080 bus ops PCI: 00:01.0 [PCI: 1022:2080] enabled PCI: pci_scan_bus pci_probe_dev returns dev 0xbd20(device0_0) PCI: devfn 0x9 pci_scan_get_dev: list is 0x00087ea8, *list is 0xc060 pci_scan_get_dev: check dev southbridge pci_scan_get_dev: check dev southbridge it has devfn 0x79 pci_scan_get_dev: check dev superio superio: Unknown device path type: 0 pci_scan_get_dev: child superio() not a pci device: it's type 0 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) PCI: devfn 0x9, bad id 0x PCI: pci_scan_bus pci_probe_dev returns dev 0x(c) PCI: devfn 0xa pci_scan_get_dev: list is 0x00087ea8, *list is 0xc060 pci_scan_get_dev: check dev southbridge pci_scan_get_dev: check dev southbridge it has devfn 0x79 pci_scan_get_dev: check dev superio superio: Unknown device path type: 0 pci_scan_get_dev: child superio() not a pci device: it's type 0 PCI: pci_scan_bus pci_scan_get_dev returns dev None (no dev in tree yet) Too many devices. Increase MAX_DEVICES So, that's better. I need to know if my dtc patch from this morning is going to be acceptable -- I need that soon. I don't know about MAX_DEVICES -- that's a puzzle to me so far. ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
boy, do I feel dumb! OK, where do I want to put this page. I am thinking leave it where it is and move coreboot text up to, e.g., 16K so we have room for this type of thing in future? thanks! ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
ron minnich wrote: The worst part is, I looked at that code about 50 times, and each time, I thought oh yeah, i start that at idt at zero. Sheesh! ron It didn't dawn on me right away either. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
ron minnich wrote:
On Jan 29, 2008 12:00 AM, ron minnich [EMAIL PROTECTED] wrote:
And this is bad too.
in setup_realmode_idt -- both v2 and v3 ...
/* debug handler - useful to set a programmable delay between
instructions if the
TF bit is set upon call to real mode */
idts[1].cs = 0;
idts[1].offset = 16384;
memcpy((void *)16384, debughandle, end_debughandle - debughandle);
Is the debug handler even used? I don't see how it is used
And that certainly made things better, taking out that blind memcpy.
We're still getting the weird error on biosint but ...
I think that there is a calling convention problem. Look at the code
generated by v2 and by v3 for biosint(). callbiosint() expects biosint()
will get the interrupt number off the stack
// - put the INT # on the stack as a parameter
// - provides us with a temp for the %cr0 mods.
pushl %eax\n
with fs2 I step into biosint and get the following (note: intel asm)
push esi
mov esi, eax
push ebx
then there is a bunch of stack manipulation creating local
variables (that I wouldn't expect).
eax contains 0x18 from the mode change. esi is later used to report the
int #.
We get lucky in that 0x18 doesn't have a function. If biosint() were to
modify variables to return it would probably be catastrophic.
Fortunately, nothing is changed and callbiosint() restores everything as
expected and we continue on.
We don't need the int15 handling with the new VSA but this needs to be
fixed to properly identify interrupt calls when they happen from VGA or
other ROMs.
Another observation:
/* Dump zeros in the other segregs */
mov %ax, %es\n
mov %ax, %fs\n
mov %ax, %gs\n
mov $0x40, %ax \n
mov %ax, %ds\n
Isn't needed because the registers are popped off the stack in imedeatly
following.
/* pop the INT # that you pushed earlier */
popl%eax\n
pop %gs \n
pop %fs \n
pop %es \n
pop %ds \n
popal \n
At this point I am convinced that VSA is setup and working and is not
using other memory areas.
You were talking about doing a memory map. On thing to consider is that
I think VSA/ROMs can use the same stack location as the coreboot stack
(as long as it is below 1MB). Change the following:
/* put the stack at the end of page zero.
* that way we can easily share it between real and protected,
* since the 16-bit ESP at segment 0 will work for any case. */
/* Setup a stack */
mov $0x0, %ax \n
mov %ax, %ss\n
movl$0x1000, %eax \n
movl%eax, %esp \n
To (off the top of my head so it may need a tweak)
/* figure the seg:offset of the coreboot stack */
mov $esp, %eax \n
andl$0x000F, %eax \n
shrl$4, %eax\n
movl%ax, %ss\n
mov $esp, %eax \n
andl$0x, %eax \n
movl%eax, %esp \n
Maybe subtract a few bytes off if you are worried about corruption.
Hmmm that does mean you need to re-figure this on the way back in
interrupt handler but you save a segment. Maybe the old way is still
better. Maybe the stack should always be at 0x1000... (and yes this gets
into the stack moving stuff.)
OK, enough rambling.
Marc
--
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:[EMAIL PROTECTED]
http://www.amd.com/embeddedprocessors
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
ron minnich wrote: coreboot seems to by dying in VSM on some config access as well. Carl-Daniel pointed out to me: IIRC there is also a VSM stack which is located in a place differing from the one clobbered between 0x1000 and 0x2000. Notice how it blows up exactly at the time where the first virtual PCI access happens. That means it blows up inside VSM. So we need to get a complete idea of the needs of VSA/VSM for memory and stack. ron VSA needs a real mode stack for init. As Tom pointed out that is setup in real_mode_switch_call_vsm in src/cpu/amd/model_lx/vsmsetup.c. I don't think that the location matters. It could move instead ov moving stage2. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
On 28.01.2008 20:38, ron minnich wrote: coreboot seems to by dying in VSM on some config access as well. Carl-Daniel pointed out to me: IIRC there is also a VSM stack which is located in a place differing from the one clobbered between 0x1000 and 0x2000. Notice how it blows up exactly at the time where the first virtual PCI access happens. That means it blows up inside VSM. So we need to get a complete idea of the needs of VSA/VSM for memory and stack. For more context, here is a snippet from Ron's latest boot log with stage2 at 0x2000. Ron, please correct me if I misstated something. It blow up here: PCI: devfn 0x8 pci_scan_get_dev: list is 0x00087ea8, *list is 0xbd40 pci_scan_get_dev: check dev device0_0 pci_scan_get_dev: check dev device0_0 it has devfn 0x08 PCI: pci_scan_bus pci_scan_get_dev returns dev device0_0 find_constructor: find PCI: 1022:2080 find_constructor: check all_constructors[i] 0xc720 find_constructor: cons 0xc720, cons id PCI_DOMAIN: 1022:2080 LinuxBIOS-3.0.0 Sun Jan 27 19:15:18 PST 2008 starting... i.e. got through VSA, found dev 0:1.0, found it is a PCI device, running find_constructor, blowing up. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
coreboot seems to by dying in VSM on some config access as well. Carl-Daniel pointed out to me: IIRC there is also a VSM stack which is located in a place differing from the one clobbered between 0x1000 and 0x2000. Notice how it blows up exactly at the time where the first virtual PCI access happens. That means it blows up inside VSM. So we need to get a complete idea of the needs of VSA/VSM for memory and stack. ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
ron minnich wrote: On Jan 27, 2008 8:23 PM, Tom Sylla [EMAIL PROTECTED] wrote: Well, you might want to take a look at real_mode_switch_call_vsm. I see the code telling it to use real mode address 0:0x1000 as the location for the stack. http://tracker.coreboot.org/trac/coreboot/browser/trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c#L182 Maybe that is why it is getting stomped :) well, I do manage to frequently confuse myself, but stack grows down, right? If so, 0x1000 is not an issue. First push drops it into below 1000 territory. Also, it's a big blob of zeros, at least 128 of them, starting at 0x1000 and going up. Much more than I expect from errant stack pushes. thanks ron I am working on some fixes for VSA so I will look at this today. Marc -- Marc Jones Senior Firmware Engineer (970) 226-9684 Office mailto:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
On Jan 28, 2008 3:58 PM, Marc Jones [EMAIL PROTECTED] wrote: I don't think so. It is coreboot that sets the stack for VSA initialization. The more I think about it, the stack shouldn't be moved. Just switch to real mode and VSA can use the same stack as LinuxBIOS (maybe pad it a little if you are worried about alignment). This is how it works in a standard BIOS. Stack is at 8ffxx, which is way out of 64k area ... I am lazy and set %es to 0. It's really much easier to leave it on page 0 :-) It is in the VSA memory area. It is setup by VSA during init. Ron, can you provide us with logs of the last revision before VSA support went in and of your current local codebase? I hope to pinpoint the location of the explosion better. I should be building shortly and be able to find what is blowing up. Thanks ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
On 29.01.2008 00:53, ron minnich wrote: On Jan 28, 2008 3:48 PM, Carl-Daniel Hailfinger [EMAIL PROTECTED] wrote: Ron, can you provide us with logs of the last revision before VSA support went in and of your current local codebase? I hope to pinpoint the location of the explosion better. Console logs? oh boy. That may be hard ... what I can do is put a bogus VSA file in, which will fail the signature test, and hence do everything BUT run the VSA. Useful? http://www.coreboot.org/pipermail/coreboot/2008-January/029395.html was the log of the previous code base I was looking for. Regards, Carl-Daniel -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
Looking at one of your old logs, it looks like the VSA init code is *running* in the 0x1000 segment: http://www.coreboot.org/pipermail/coreboot/2008-January/029736.html (cs 0x1000) That is probably smashing the region. The int18s are certainly bad, you should just have the normal two int15s, with cs 0x6000. How do I get vsa into coreboot v3? I built an alix image, and I am able to boot it on a different lx platform, but it does not find vsa, since I didn't build it in. I'll look at the VSA load with FS2 if someone tells me how. On Jan 28, 2008 7:07 PM, ron minnich [EMAIL PROTECTED] wrote: On Jan 28, 2008 3:58 PM, Marc Jones [EMAIL PROTECTED] wrote: I don't think so. It is coreboot that sets the stack for VSA initialization. The more I think about it, the stack shouldn't be moved. Just switch to real mode and VSA can use the same stack as LinuxBIOS (maybe pad it a little if you are worried about alignment). This is how it works in a standard BIOS. Stack is at 8ffxx, which is way out of 64k area ... I am lazy and set %es to 0. It's really much easier to leave it on page 0 :-) It is in the VSA memory area. It is setup by VSA during init. Ron, can you provide us with logs of the last revision before VSA support went in and of your current local codebase? I hope to pinpoint the location of the explosion better. I should be building shortly and be able to find what is blowing up. Thanks ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
putting vsa in v3 is very simple. lar -a build/bios.bin your-vsa-file:blob/vsa That last is a tad confusing, maybe. The part before the : is the unix pathname. The part after the : is the lar pathname. Make sure it is blob/vsa, NOT /blob/vsa To see if it is there, lar -l build/bios.bin thanks ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
Marc Jones wrote: Tom is right, something funny is going on here. We see the VSA decompressed to buf 0x0006 which is a good place for VSA. Then we don't see an error that VSA isn't found. That means that it found the first post code as expected. Yep, I checked with FS2, things look pretty good until it gets into biosint. At the call to biosint, the v2 and v3 stack look the same, and esp is in the right spot. The code for biosint is very different for v2 vs v3, however. something inside of biosint is what is screwing up. The printk's were to annoying to trace through, so I stopped there. The only thing I noticed different in the source was that v3 biosint is declared static. If I remove the static, it won't compile. All of this pain is to basically get some speed and memory size parameters into VSA. Maybe it would be best to just wait for Marc's new int15-less VSA and save that pain. It probably isn't an issue that will be uncovered later, since it can all just be ripped out. -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
ron minnich wrote: here's an interesting bug in /home/rminnich/src/bios/coreboot-v3/util/x86emu/vm86.c /* Dump zeros in the other segment registers */ mov %ax, %es\n mov %ax, %fs\n mov %ax, %gs\n mov $0x40, %ax \n--WHAT? mov %ax, %ds\n mov %cx, %ax\n Why did somebody move 0x40 to the ds? That's not even a valid gdt selector? Anybody know why this was done? That is probably normal. These are real mode selectors (segment registers), and that code is calling a VGA ROM. 0x40:xx is the BDA. I think that is one of the expectations of a VGA ROM is that it is called with the BDA pointed to be ds. cx has the device/function of the card being called. Your generic case won't want that stuff (and it doesn't have it now) -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
here's an interesting bug in /home/rminnich/src/bios/coreboot-v3/util/x86emu/vm86.c /* Dump zeros in the other segment registers */ mov %ax, %es\n mov %ax, %fs\n mov %ax, %gs\n mov $0x40, %ax \n--WHAT? mov %ax, %ds\n mov %cx, %ax\n Why did somebody move 0x40 to the ds? That's not even a valid gdt selector? Anybody know why this was done? ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
On Jan 28, 2008 10:15 PM, Marc Jones [EMAIL PROTECTED] wrote: Can you try using vsmsetup.c instead of vm86.c? Something looks strange in the reporting. ebp 0x6000. Are the variables aligned on the stack correctly? Is this debug info correct? Are we being mislead? This looks suspicious in callbiosint() movw$0x18, %ax \n I'm mostly using vsmsetup.c That 0x18 should be 0x10 I think. I think the gdt in vm86.c needs to be made identical to the one in stage0.S. Not sure yet. But there is a problem here. Also, case 0x15: ret=handleint21( edi, esi, ebp, esp, ebx, edx, ecx, eax, flags); Please call it handleint15 it it handle int15. yes, we can do this, just go ahead and make a cosmetic patch. Why is the data segment for the VSA in 16-bit mode set to x40? The vsmsetup.c in geode is mostly vsmsetup.c from v2. The only bits from vm86.c that are used are code that was basically identical. I'm still puzzled. ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
Another data point. From my log. biosint: INT# 0x18 biosint: eax 0x84e53 ebx 0x38 ecx 0xff0 edx 0x87ed8 biosint: ebp 0x6000 esp 0x87f60 edi 0x15 esi 0x0 biosint: ip 0x28 cs 0x1000 flags 0x26 That's just bogus as far as I can tell. Note that edi is 15, kind of looks like the interrupt. ebp is 6000, kind of looks like cs and something else. And so on. It's like we got someone else's stack frame. ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
On 27/01/08 23:23 -0500, Tom Sylla wrote: ron minnich wrote: If I move the stage2 text address from 0x1000 to 0x2000 (see arch/x86/Makefile: -T 0x1000), I get past the problem. It's dying later but I think I know what that is. But what piece of code is trashing memory at 0x1000? Could it be VSA? If so, do we just go with moving the text address to 0x2000, instead of 0x1000? Well, you might want to take a look at real_mode_switch_call_vsm. I see the code telling it to use real mode address 0:0x1000 as the location for the stack. http://tracker.coreboot.org/trac/coreboot/browser/trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c#L182 Maybe that is why it is getting stomped :) (link is to v2, but the code is the same. Why can't I browse v3 in trac or viewvc?) http://coreboot.org/viewvc/coreboot-v3/?root=coreboot-v3 View coreboot-v3 if you want, then change repository on upper right of screen you must. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
On Jan 27, 2008 8:23 PM, Tom Sylla [EMAIL PROTECTED] wrote: Well, you might want to take a look at real_mode_switch_call_vsm. I see the code telling it to use real mode address 0:0x1000 as the location for the stack. http://tracker.coreboot.org/trac/coreboot/browser/trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c#L182 Maybe that is why it is getting stomped :) well, I do manage to frequently confuse myself, but stack grows down, right? If so, 0x1000 is not an issue. First push drops it into below 1000 territory. Also, it's a big blob of zeros, at least 128 of them, starting at 0x1000 and going up. Much more than I expect from errant stack pushes. thanks ron -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] alix1c and v3
On Sat, Jan 26, 2008 at 09:07:23PM -0800, ron minnich wrote: OK, VSA is running fine. BUT, after VSA runs, memory at 0x1000 is ZERO'd. This is Bad, as this is where stage2 lives! Can you confirm it is not zero before calling do_vsmbios() and zero immediately after returning? That would indicate that the VSA setup empties the area. //Peter -- coreboot mailing list coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
