RE: Makefile changes for symbols

  <Stephen.Kimball(a)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

Makefile changes for symbols

[Ronald G. Minnich]

On Fri, 22 Oct 2004 Stephen.Kimball(a)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

Makefile changes for symbols

[Li-Ta Lo]

      On Fri, 2004-10-22 at 14:55, Ronald G. Minnich wrote:
  On Fri, 22 Oct 2004 Stephen.Kimball(a)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(a)clustermatic.org
 http://www.clustermatic.org/mailman/listinfo/linuxbios

Makefile changes for symbols

[Steve Kimball]

      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(a)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

Makefile changes for symbols

[Ronald G. Minnich]

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

Makefile changes for symbols

[Steve Kimball]

      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

Makefile changes for symbols

[Ronald G. Minnich]

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

Makefile changes for symbols

[Steve Kimball]

      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

Makefile changes for symbols

[Ronald G. Minnich]

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

Makefile changes for symbols

[Li-Ta Lo]

      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

Makefile changes for symbols

[Stefan Reinauer]

      * Li-Ta Lo <ollie(a)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

Makefile changes for symbols

      Stefan Reinauer <stepan(a)openbios.org> writes:

  * Li-Ta Lo <ollie(a)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

Makefile changes for symbols

[Ronald G. Minnich]

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

Makefile changes for symbols

[Stefan Reinauer]

      * Eric W. Biederman <ebiederman(a)lnxi.com> [041026 12:50]:
  Stefan Reinauer <stepan(a)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

Makefile changes for symbols

      Stefan Reinauer <stepan(a)openbios.org> writes:

  * Eric W. Biederman <ebiederman(a)lnxi.com>
[041026 12:50]:
  Stefan Reinauer <stepan(a)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

Makefile changes for symbols

[Ronald G. Minnich]

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