OK, VSA is running fine. BUT, after VSA runs, memory at 0x1000 is ZERO'd. This is Bad, as this is where stage2 lives!
Any ideas :-)
ron
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
On 27.01.2008 06:35, Peter Stuge wrote:
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.
http://dev.laptop.org/git?p=geode-vsa;a=summary has the VSA source code, if you want to take a look.
Regards, Carl-Daniel
On Jan 26, 2008 9:35 PM, Peter Stuge peter@stuge.se wrote:
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.
Confirmed. But why would it do this?
Is area above %esp supposed to be usable for vsa?
ron
On 27.01.2008 18:44, ron minnich wrote:
On Jan 26, 2008 9:35 PM, Peter Stuge peter@stuge.se wrote:
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.
Confirmed. But why would it do this?
Maybe it has something to do with RCONF_SMM or RCONF_BYPASS?
Is area above %esp supposed to be usable for vsa?
Marc? Jordan? I tried to extract that information from the various databooks on the AMD web site, but I was ultimately unsuccessful.
Regards, Carl-Daniel
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?
thanks
ron
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/...
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?)
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/...
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
On Jan 27, 2008 8:23 PM, Tom Sylla tsylla@gmail.com 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/...
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
ron minnich wrote:
On Jan 27, 2008 8:23 PM, Tom Sylla tsylla@gmail.com 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/...
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
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
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 0x0000bd40 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] 0x0000c720 find_constructor: cons 0x0000c720, 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
Carl-Daniel Hailfinger wrote:
On 28.01.2008 20:38, ron minnich wrote:
It blow up here: PCI: devfn 0x8 pci_scan_get_dev: list is 0x00087ea8, *list is 0x0000bd40 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] 0x0000c720 find_constructor: cons 0x0000c720, 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.
I think it got through VSA as well. Just to be sure can you dump the registers on before and after find PCI? Marc
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
On 28.01.2008 21:57, Marc Jones wrote:
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.
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.
We place that stack at 0x1000, however Ron saw during VSA init that memory directly above 0x1000 was clobbered as well. Since the stack is growing down, that suggests that the VSA writes to memory outside the VSA init stack. IIRC the VSA also has a runtime stack to save registers when called via SMI. The Geode GX VSA2 programmer's guide is not completely clear on that or I skipped over the wrong pages. MSR_SMM_HDR is the location of the runtime stack, or rather the SMM header in which at least some part of the SMM runtime stack is stored. Do we set that anywhere?
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.
Regards, Carl-Daniel
On Jan 28, 2008 3:48 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net 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?
ron
On 29.01.2008 00:53, ron minnich wrote:
On Jan 28, 2008 3:48 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net 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
Carl-Daniel Hailfinger wrote:
On 28.01.2008 21:57, Marc Jones wrote:
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.
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.
We place that stack at 0x1000, however Ron saw during VSA init that memory directly above 0x1000 was clobbered as well. Since the stack is growing down, that suggests that the VSA writes to memory outside the VSA init stack.
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.
IIRC the VSA also has a runtime stack to save registers when called via SMI. The Geode GX VSA2 programmer's guide is not completely clear on that or I skipped over the wrong pages. MSR_SMM_HDR is the location of the runtime stack, or rather the SMM header in which at least some part of the SMM runtime stack is stored. Do we set that anywhere?
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. Marc
On Jan 28, 2008 3:58 PM, Marc Jones marc.jones@amd.com 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
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 rminnich@gmail.com wrote:
On Jan 28, 2008 3:58 PM, Marc Jones marc.jones@amd.com 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
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
On Jan 28, 2008 7:30 PM, Tom Sylla tsylla@gmail.com wrote:
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)
Thanks tom, that's a good catch! I will try to see what's going on here.
ron
Tom Sylla wrote:
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.
Tom is right, something funny is going on here. We see the VSA decompressed to buf 0x00060000 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.
The next part is very strange. The int 0x18 should be int 0x15 and as Tom points out, cs should be 0x6000 not 0x1000. What and why does it think it is at cs 0x1000.
Can you try using vsmsetup.c instead of vm86.c? Something looks strange in the reporting. ebp 0x60000000. 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"
Also, case 0x15: ret=handleint21( &edi, &esi, &ebp, &esp, &ebx, &edx, &ecx, &eax, &flags);
Please call it handleint15 it it handle int15.
Finally, the int0x15 will be removed from the next VSA.
Marc
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
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)
On Jan 28, 2008 10:15 PM, Marc Jones Marc.Jones@amd.com wrote:
Can you try using vsmsetup.c instead of vm86.c? Something looks strange in the reporting. ebp 0x60000000. 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
Marc Jones wrote:
Tom is right, something funny is going on here. We see the VSA decompressed to buf 0x00060000 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.
On Jan 28, 2008 11:23 PM, Tom Sylla tsylla@gmail.com wrote:
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.
Whoa! are you looking at biosint in v3 in northbridge/amd/geodelx/vsmsetup.c?
That code is just a copy. of the v2 code. The printks are the only realy difference. Other than that it is the same. I am looking at it now.
The stack is the same for you? That's interesting. What's the result of the very first print, for the interrupt #?
Geez, I hope this is not another toolchain problem.
ron
Another data point.
From my log.
biosint: INT# 0x18 biosint: eax 0x84e53 ebx 0x38 ecx 0xff0 edx 0x87ed8 biosint: ebp 0x60000000 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 60000000, kind of looks like cs and something else.
And so on. It's like we got someone else's stack frame.
ron
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);
So a blind memcpy over 16384. What's there?
00003fa0 T find_constructor 0000404b T constructor 000040a1 T alloc_dev 0000418b T dev_init 000041bc T dev_find_slot 000041eb T dev_find_slot_on_smbus 0000421a T dev_find_class
Oh. Our code. In fact, it's find_constructor -- which was what was blowing up.
So I'm yanking that blind memcpy, one more try, then off to bed.
We're going to need to work out a formal memory map.
ron
On Jan 29, 2008 12:00 AM, ron minnich rminnich@gmail.com 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: 0000): 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: 0000) enabled domain0(PCI_DOMAIN: 0000) scanning... dev_phase3_scan: scanning domain0(PCI_DOMAIN: 0000) pci_scan_bus start bus 0x0000bc60, bus->dev 0x0000ba20 PCI: pci_scan_bus for bus 00 pci_scan_bus: old_devices 0x0000bd20, dev for this bus 0x0000ba20 (domain0) PCI: scan devfn 0x0 to 0xff PCI: devfn 0x0 pci_scan_get_dev: list is 0x00087ea8, *list is 0x0000bd20 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 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000(c) PCI: devfn 0x8 pci_scan_get_dev: list is 0x00087ea8, *list is 0x0000bd20 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] 0x0000c700 find_constructor: cons 0x0000c700, cons id PCI_DOMAIN: 1022:2080 find_constructor: cons 0x0000c714, cons id APIC_CLUSTER: 1022:2080 find_constructor: cons 0x0000c728, 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 0x0000bd20(device0_0) PCI: devfn 0x9 pci_scan_get_dev: list is 0x00087ea8, *list is 0x0000c060 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 0xffffffff PCI: pci_scan_bus pci_probe_dev returns dev 0x00000000(c) PCI: devfn 0xa pci_scan_get_dev: list is 0x00087ea8, *list is 0x0000c060 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
ron minnich wrote:
On Jan 29, 2008 12:00 AM, ron minnich rminnich@gmail.com 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 $0x000F0000, %eax \n" " shrl $4, %eax \n" " movl %ax, %ss \n" " mov $esp, %eax \n" " andl $0x0000FFFF, %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
I have looked at sharing the stack with coreboot/vsa, but it really gets messy.
Also, there is the still unexplained zero'ing of memory at 0x1000. That mostly working example i sent was with coreboot text at 0x2000.
So vsa does nothing ABOVE %esp, just in the stack?
This is weird. Can you trap the fs2 on a write to 0x1000 and see if that occurs?
thanks
ron
ron minnich wrote:
I have looked at sharing the stack with coreboot/vsa, but it really gets messy.
Also, there is the still unexplained zero'ing of memory at 0x1000. That mostly working example i sent was with coreboot text at 0x2000.
So vsa does nothing ABOVE %esp, just in the stack?
This is weird. Can you trap the fs2 on a write to 0x1000 and see if that occurs?
thanks
ron
// for each int, we create a customized little handler // that just pushes %ax, puts the int # in %al, // then calls the common interrupt handler. // this necessitated because intel didn't know much about // architecture when they did the 8086 (it shows) // (hmm do they know anymore even now :-) // obviously you can see I don't really care about memory // efficiency. If I did I would probe back through the stack // and get it that way. But that's really disgusting. for (i = 0; i < 256; i++) { idts[i].cs = 0; codeptr = (unsigned char *) 4096 + i * codesize; idts[i].offset = (unsigned) codeptr; memcpy(codeptr, &idthandle, codesize); intbyte = codeptr + 3; *intbyte = i; }
Marc
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
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
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
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Marc Jones -
Marc Jones
-
Peter Stuge -
ron minnich -
Tom Sylla