How to debug MMU on powerpc?

How to debug MMU on powerpc?

[Gong Zhuo]

Hi:
  I am using MVME2600 and debug my program through serial port. I must use
MMU for some reasons and the virtual address and physical address is not
consistent. That means virtual address 0 maybe physical address 0xc000. I
have used BAT method. All the mapping is finished in assembly language and I
have make the cross-compile , gdb for powerpc-eabi. But how can I link and
debug my program?
  1. If I link my program with virtual address , the code before the mmu is
opened will be linked with the virtual address but they should run in the
physical address.
  2. The powerpc-eabi-gdb will load my program to the entry-point of virtual
address, but the mmu has not been opened at that time.
  ...


Gong Zhuo


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to debug MMU on powerpc?

[Tom Roberts]

Gong Zhuo wrote:
>   I am using MVME2600 and debug my program through serial port. I must use
> MMU for some reasons and the virtual address and physical address is not
> consistent. That means virtual address 0 maybe physical address 0xc000. I
> have used BAT method. All the mapping is finished in assembly language and I
> have make the cross-compile , gdb for powerpc-eabi. But how can I link and
> debug my program?

>From your descriptiojn your program is not running under Linux, but is
a stand-alone program. If this is not true and you intend to run it
under Linux, then you must let Linux manage the MMU.

A stand-alone program which is using the MMU must be carefully designed
so that the MMU can be initialized and then enabled properly. There are
two basic ways to do this:
 A) arrange so the startup code will be mapped virtual=physical, so it
    can start with MMU disabled, setup the BATs (and segments if any),
    and then enable the MMU. Since this code is mapped virtual=physical
    it continues to run after the MMU is enabled.
 B) arrange so the startup code runs with MMU disabled, setup the BATs
    (and segments if any) and then:
	mtspr SRR1,<desired MSR value with MMU enabled>
	mtspr SRR0,<virtual address to start at>
	rfi
    Note that the fact that branches are generally PC-relative makes
    this a lot easier -- you may not need to do anything at all to
    make it work correctly (initialize the BATs with load immediates,
    not data accesses). Note also that if the code starts with the
    MMU enabled you must use much care in modifying the BATs.
Our proprietary OS uses mthod A (the entire kernel runs
virtual=physical, only user programs have non-physical virtual
addresses); Linux's head.S uses method B.


>   1. If I link my program with virtual address , the code before the mmu is
> opened will be linked with the virtual address but they should run in the
> physical address.

Sure, but as branches and calls are PC-relative, it may still work.
You need to be careful about data accesses, however. As you are using
BATs, there is a simple subtraction/addition to relate virtual and
physical addresses, and you can explicitly do that for data accesses.
Look at Linux's head.S (in directory arch/ppc/kernel) for examples of
this during startup; the value to be subtracted for virt->phys is
called KERNELBASE (but in the mm code is called PAGE_OFFSET (:-().


>   2. The powerpc-eabi-gdb will load my program to the entry-point of virtual
> address, but the mmu has not been opened at that time.

See above. It depends in detail how your loading of the program arranges
to jump to its starting point. Note that most boot ROMs and debug ROMS
do not use the MMU and will load the program where you tell it and
simply jump to its first location or a physical address you tell it.
You must take the behavior of your boot/debug ROM into account when
designing the startup of your program.

Hmmm. Your paragraph here sort-of implies that you intend to startup
Linux, run gdb, and have gdb load and execute your program which
will then take over the MMU (etc.). This is unlikely to work,
because the execution environment for gdb and the Linux kernel will
be completely destroyed. I repeat: if you intend to run this program
under Linux then you must let Linux manage the MMU.

	Note: the version of PPC Linux I have (2.2.15) uses only
	DBAT2,DBAT3,IBAT2,IBAT3, so the other BATs are available
	for system-specific uses. My custom drivers use DBAT0 and
	DBAT1. Before doing this you must make sure that the
	system-level code for your board does not already use
	these BATs (write a module to dump the BATs, or inspect
	the Linux startup code VERY carefully). This may be what
	you are looking for.


Tom Roberts	tjroberts@lucnet.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: How to debug MMU on powerpc?

[Gong Zhuo]

>> Gong Zhuo wrote:
> >   I am using MVME2600 and debug my program through serial port. I must
use
> > MMU for some reasons and the virtual address and physical address is not
> > consistent. That means virtual address 0 maybe physical address 0xc000.
I
> > have used BAT method. All the mapping is finished in assembly language
and I
> > have make the cross-compile , gdb for powerpc-eabi. But how can I link
and
> > debug my program?
>
> From your descriptiojn your program is not running under Linux, but is
> a stand-alone program. If this is not true and you intend to run it
> under Linux, then you must let Linux manage the MMU.
>
> A stand-alone program which is using the MMU must be carefully designed
> so that the MMU can be initialized and then enabled properly. There are
> two basic ways to do this:
>  A) arrange so the startup code will be mapped virtual=physical, so it
>     can start with MMU disabled, setup the BATs (and segments if any),
>     and then enable the MMU. Since this code is mapped virtual=physical
>     it continues to run after the MMU is enabled.
>  B) arrange so the startup code runs with MMU disabled, setup the BATs
>     (and segments if any) and then:
> mtspr SRR1,<desired MSR value with MMU enabled>
> mtspr SRR0,<virtual address to start at>
> rfi
>     Note that the fact that branches are generally PC-relative makes
>     this a lot easier -- you may not need to do anything at all to
>     make it work correctly (initialize the BATs with load immediates,
>     not data accesses). Note also that if the code starts with the
>     MMU enabled you must use much care in modifying the BATs.
> Our proprietary OS uses mthod A (the entire kernel runs
> virtual=physical, only user programs have non-physical virtual
> addresses); Linux's head.S uses method B.
>
>
> >   1. If I link my program with virtual address , the code before the mmu
is
> > opened will be linked with the virtual address but they should run in
the
> > physical address.
>
> Sure, but as branches and calls are PC-relative, it may still work.
> You need to be careful about data accesses, however. As you are using
> BATs, there is a simple subtraction/addition to relate virtual and
> physical addresses, and you can explicitly do that for data accesses.
> Look at Linux's head.S (in directory arch/ppc/kernel) for examples of
> this during startup; the value to be subtracted for virt->phys is
> called KERNELBASE (but in the mm code is called PAGE_OFFSET (:-().
>
>
> >   2. The powerpc-eabi-gdb will load my program to the entry-point of
virtual
> > address, but the mmu has not been opened at that time.
>
> See above. It depends in detail how your loading of the program arranges
> to jump to its starting point. Note that most boot ROMs and debug ROMS
> do not use the MMU and will load the program where you tell it and
> simply jump to its first location or a physical address you tell it.
> You must take the behavior of your boot/debug ROM into account when
> designing the startup of your program.
>
> Hmmm. Your paragraph here sort-of implies that you intend to startup
> Linux, run gdb, and have gdb load and execute your program which
> will then take over the MMU (etc.). This is unlikely to work,
> because the execution environment for gdb and the Linux kernel will
> be completely destroyed. I repeat: if you intend to run this program
> under Linux then you must let Linux manage the MMU.
>
> Note: the version of PPC Linux I have (2.2.15) uses only
> DBAT2,DBAT3,IBAT2,IBAT3, so the other BATs are available
> for system-specific uses. My custom drivers use DBAT0 and
> DBAT1. Before doing this you must make sure that the
> system-level code for your board does not already use
> these BATs (write a module to dump the BATs, or inspect
> the Linux startup code VERY carefully). This may be what
> you are looking for.

Thank you very much for your help . I have another question. In fact , I am
developing a stand-alone program and the virtual address is not the same as
physical address. The mothed B has been used . I use the cross-compile of
gcc for powerpc-eabi and want to use the psim (powerpc simulator) to debug
my program . If the virtual=phiscal , everything will be ok. But the virtual
!= physical , can the psim still be used? If it can , how to compile my
program and load it into the psim?


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/