Stephen.Kimball@bench.com writes:
Rod,
I'm using Source Point 7.0.0. I can see the source files. I can display source, disassembly or mixed. However, the disassembly
doesn't
match up with the source code. There is a way to give Source Point
an
offset when the symbols are loaded, but I can't seem to get the
right
value. I know the address of _start and __protected_start but these labels are not in linuxbios_c.o. I need to find the location of a symbol in linuxbios_c.o to compute the offset.
???
linuxbios_c is run at an absolute location in memory so the address of the symbols within it should be fine.
Look at readelf -a linuxbios_c.
I have looked at the readelf output. Readelf says hardwaremain is at 000020b8, but I can't find it. SourcePoint thinks it's at 0008:000020B8 (32-bit mode). But it's not there even after the copy into RAM.
Now these are not addresses within the rom chip. The are the
addresses
the code is copied to after memory initialization.
Currently romcc which generates the code that executes immediately out of the rom chip does not give good debugging output. But you should still be able to see the assembly. crt0.s should match what you are looking at.
You don't have the debugger in 16bit mode or something do you?
SourcePoint switches to 32-bit mode 16 instructions into crt0.s at the JMP instruction.
Am I right that crt0.s loads LinuxBIOS into RAM then branches to hardwaremain?
Steve
On Fri, 22 Oct 2004 Stephen.Kimball@bench.com wrote:
I have looked at the readelf output. Readelf says hardwaremain is at 000020b8, but I can't find it. SourcePoint thinks it's at 0008:000020B8 (32-bit mode). But it's not there even after the copy into RAM.
well that's interesting, now I have to try to remember if you're v1 or v2. But that segment: address pair looks quite reasonable.
For example on the arima I am using hardwaremain is 723c. Basically all this stuff is in low memory.
When you say "not there" you mean you see nothing in memory, right?
I wonder if there's an issue with the debugger?
ron
On Fri, 2004-10-22 at 14:55, Ronald G. Minnich wrote:
On Fri, 22 Oct 2004 Stephen.Kimball@bench.com wrote:
I have looked at the readelf output. Readelf says hardwaremain is at 000020b8, but I can't find it. SourcePoint thinks it's at 0008:000020B8 (32-bit mode). But it's not there even after the copy into RAM.
well that's interesting, now I have to try to remember if you're v1 or v2. But that segment: address pair looks quite reasonable.
For example on the arima I am using hardwaremain is 723c. Basically all this stuff is in low memory.
When you say "not there" you mean you see nothing in memory, right?
I think he means the ROMCC part of LinuxBIOS copy the hardwaremain part to RAM but he can't find it at the address.
I think you should try "linear" or "physical" address 000020b8. Some hardware debugger have problem doing virtual to physical translation.
Ollie
I wonder if there's an issue with the debugger?
ron _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Fri, 2004-10-22 at 17:24, Li-Ta Lo wrote:
On Fri, 2004-10-22 at 14:55, Ronald G. Minnich wrote:
On Fri, 22 Oct 2004 Stephen.Kimball@bench.com wrote:
I have looked at the readelf output. Readelf says hardwaremain is at 000020b8, but I can't find it. SourcePoint thinks it's at 0008:000020B8 (32-bit mode). But it's not there even after the copy into RAM.
well that's interesting, now I have to try to remember if you're v1 or v2. But that segment: address pair looks quite reasonable.
I'm using freebios2. Is that v2?
For example on the arima I am using hardwaremain is 723c. Basically all this stuff is in low memory.
When you say "not there" you mean you see nothing in memory, right?
I look at the hardwaremain source code in mixed mode (assembly with C code mixed in). Even the two post_code() calls don't disassemble to similar code. It's code, but not the right code.
I think he means the ROMCC part of LinuxBIOS copy the hardwaremain part to RAM but he can't find it at the address.
I think you should try "linear" or "physical" address 000020b8. Some hardware debugger have problem doing virtual to physical translation.
Ollie
I wonder if there's an issue with the debugger?
ron
On Fri, 22 Oct 2004, Steve Kimball wrote:
I'm using freebios2. Is that v2?
that's v2.
I look at the hardwaremain source code in mixed mode (assembly with C code mixed in). Even the two post_code() calls don't disassemble to similar code. It's code, but not the right code.
I'm really sorry, what mobo again?
ron
On Fri, 2004-10-22 at 18:17, Ronald G. Minnich wrote:
On Fri, 22 Oct 2004, Steve Kimball wrote:
I'm using freebios2. Is that v2?
that's v2.
I look at the hardwaremain source code in mixed mode (assembly with C code mixed in). Even the two post_code() calls don't disassemble to similar code. It's code, but not the right code.
I'm really sorry, what mobo again?
AMD/Serenade with a FILO payload. It runs great. It loads Linux fine. Just can get the source and disassembly to line up.
Steve
On Mon, 25 Oct 2004, Steve Kimball wrote:
AMD/Serenade with a FILO payload. It runs great. It loads Linux fine. Just can get the source and disassembly to line up.
it seems to me that the addresses you are using are correct. Did you try pointing the arium at physical memory instead of seg:offset addresses?
ron
On Mon, 2004-10-25 at 10:50, Ronald G. Minnich wrote:
On Mon, 25 Oct 2004, Steve Kimball wrote:
AMD/Serenade with a FILO payload. It runs great. It loads Linux fine. Just can get the source and disassembly to line up.
it seems to me that the addresses you are using are correct. Did you try pointing the arium at physical memory instead of seg:offset addresses?
ron
I don't know how to force physical or virtual addressing. The arium seems to change automaically when the mode changes. I can single step an follow instruction execution as log as I'd like. I have been displaying hardwaremain in mixed (source and assembly) at various points. I'm assuming it gets copied from FLASH to RAM at some point. So it should be junk initially.
time mode hardwaremain address instr values after reset 16-bit F000:0000 20b8 non-zero junk after 16 instr 32-bit 0008:0000 20b8 different non-zero junk later all 0xff scanning PCI bus 32-bit 0018:0000 20b8 all zeros
If I display memory at 0000:0000 20b8 it seems to always match the values at hardwaremain? Why does the American Arium think the segment register for hardwaremain changes? Why is it never good instructions?
Steve
On Mon, 25 Oct 2004, Steve Kimball wrote:
I don't know how to force physical or virtual addressing. The arium seems to change automaically when the mode changes.
yes, that automagic thing is wonderful ... when it works.
You can force it, and I forget how. I think you just close the seg:offset window and then pop up a disassembly but specify physical addressing.
If I display memory at 0000:0000 20b8 it seems to always match the values at hardwaremain? Why does the American Arium think the segment register for hardwaremain changes?
All I know is that displaying memory with seg:offset was always a problem for me, so I tried to keep it at physical addressing.
ron
On Mon, 2004-10-25 at 10:00, Ronald G. Minnich wrote:
On Mon, 25 Oct 2004, Steve Kimball wrote:
I don't know how to force physical or virtual addressing. The arium seems to change automaically when the mode changes.
yes, that automagic thing is wonderful ... when it works.
You can force it, and I forget how. I think you just close the seg:offset window and then pop up a disassembly but specify physical addressing.
If I display memory at 0000:0000 20b8 it seems to always match the values at hardwaremain? Why does the American Arium think the segment register for hardwaremain changes?
All I know is that displaying memory with seg:offset was always a problem for me, so I tried to keep it at physical addressing.
BTW, the ht reset confused the AMD HDT such that I have no way to debug anything other the auto.c. Is AA as stupid ?
Ollie
* Li-Ta Lo ollie@lanl.gov [041025 21:26]:
All I know is that displaying memory with seg:offset was always a problem for me, so I tried to keep it at physical addressing.
BTW, the ht reset confused the AMD HDT such that I have no way to debug anything other the auto.c. Is AA as stupid ?
Now that A stepping CPUs start dying out, could we not switch the reset mechanism to use LDTSTOP instead of a complete reset? It's more solid and a lot faster.
Stefan
Stefan Reinauer stepan@openbios.org writes:
- Li-Ta Lo ollie@lanl.gov [041025 21:26]:
All I know is that displaying memory with seg:offset was always a problem for me, so I tried to keep it at physical addressing.
BTW, the ht reset confused the AMD HDT such that I have no way to debug anything other the auto.c. Is AA as stupid ?
Now that A stepping CPUs start dying out, could we not switch the reset mechanism to use LDTSTOP instead of a complete reset? It's more solid and a lot faster.
Solid? There are several errata with using LDTSTOP and you can not use it after memory is initialized.
As for performance now that we have removed the earlier unnecessary cache invalidations that killed performance there is no noticeable speed penalty.
So far I have not seen a reason to use LDTSTOP, or a win by doing so. Perhaps when we get as far as hotplug hypertransport that will be a win.
Eric
On Tue, 26 Oct 2004, Eric W. Biederman wrote:
As for performance now that we have removed the earlier unnecessary cache invalidations that killed performance there is no noticeable speed penalty.
Stefan, try the newest snap. Startup on K8 is FAST now.
ron
* Eric W. Biederman ebiederman@lnxi.com [041026 12:50]:
Stefan Reinauer stepan@openbios.org writes:
Now that A stepping CPUs start dying out, could we not switch the reset mechanism to use LDTSTOP instead of a complete reset? It's more solid and a lot faster.
Solid? There are several errata with using LDTSTOP and you can not use it after memory is initialized.
We don't do this anyways, do we?
In situations with marginal timing for RESET#, there is less chance of something going wrong. Hardware is rarely perfect, and LDTSTOP# affects less of it, so it is a little more robust.
Stefan
Stefan Reinauer stepan@openbios.org writes:
- Eric W. Biederman ebiederman@lnxi.com [041026 12:50]:
Stefan Reinauer stepan@openbios.org writes:
Now that A stepping CPUs start dying out, could we not switch the reset mechanism to use LDTSTOP instead of a complete reset? It's more solid and a lot faster.
Solid? There are several errata with using LDTSTOP and you can not use it
after
memory is initialized.
We don't do this anyways, do we?
Yes. We avoid it but the generic code is run after memory is initialized.
In situations with marginal timing for RESET#, there is less chance of something going wrong. Hardware is rarely perfect, and LDTSTOP# affects less of it, so it is a little more robust.
Possibly. At the same time reset# must be implemented and work correctly, as reset# is used to during board power on. Whereas it is not fatal if LDTSTOP# is implemented incorrectly.
I think you can tweak the calls to reset in the romcc compiled code to use LDTSTOP# on a per motherboard basis so it may be worth trying to use LDTSTOP#.
Eric
On Fri, 22 Oct 2004, Li-Ta Lo wrote:
I think you should try "linear" or "physical" address 000020b8. Some hardware debugger have problem doing virtual to physical translation.
good point. I forgot completely about that. On the arium I would almost always use 'physical' on the mapping. try that.
ron
-
ebiederman＠lnxi.com -
Li-Ta Lo -
Ronald G. Minnich -
Stefan Reinauer -
Stephen.Kimball＠bench.com -
Steve Kimball