gdb load address and KERNELLOAD

gdb load address and KERNELLOAD

[Wang Yong]

Hi, all:
  I am debugging embedded Linux( linux-2.2.13 for MPC8XX) using bdm/wiggler. I do this
on windowsNT with cygwin and insight downloaded from www.ocdemon.com. The question is: how
can I download the vmlinux to a different address from KERNELLOAD which is set to 0xc0000000.
I want to do this because the SDRAM is mapped to 0x00000000 and the MMU is of course not enabled
when I download the kernel image via gdb. any comment on this subject is welcome.

  thank you.

W.Y.

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

Re: gdb load address and KERNELLOAD

[Dan Malek]

Wang Yong wrote:
>
> Hi, all:
>   I am debugging embedded Linux( linux-2.2.13 for MPC8XX) using bdm/wiggler. I do this
> on windowsNT with cygwin and insight downloaded from www.ocdemon.com.


Don't waste your time.  It will only work for the first few instructions.
Once the MMU is enabled, these tools won't work.

The only BDM debugger that works successfully with Linux is the
Abatron gdb/BDI2000, hosted on a Linux platform.


	-- Dan

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

Re: gdb load address and KERNELLOAD

[Wolfgang Denk]

In message <3ACA816E.71E4FA67@mvista.com> Dan Malek wrote:
>
> The only BDM debugger that works successfully with Linux is the
> Abatron gdb/BDI2000, hosted on a Linux platform.

This is absolutely correct except for the word "only".

The BDM4GDB  project  at  sourceforge  (see  bdm4gdb.sourceforge.net)
provides all necessary information to build a home-made parallel port
adapter  (schematics, source extension to GDB) which allows to do the
same. If you cannot build a simple PCB  yourself,  we  offer  BDM4GDB
adapters  at  production  cost ($ 50, including a CD-ROM with sources
and binary for the modified GDB) as a service to the Linux community.

The main differences between the BDI2000 and BDM4GDB:

* BDI2000 connects to the Ethernet, BDM4GDB needs a parallel port  on
  a PC.
* BDI2000 has support for  many  CPU  types,  BDM4GDB  restricted  to
  MPC8xx (so far)
* BDI2000 has support for all comon flash types, BDM4GDB  needs  some
  more  work  in that area (but you can adapt it yourself when needed -
  it's Open Source)
* BDI2000 is much faster for code download / flash programming
* The BDI2000 costs around $ 2,500, BDM4GDB $ 50.

Shameless plug:

I will give a presentation "Debugging  of  Linux  Kernel  and  Device
Drivers  Using Low-Cost BDM Interface" featuring the BDM4GDB on May 4
at the 3rd Brunswick Linux Days, see
http://braunschweiger.linuxtage.de/programm/index.html

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Remember that Beethoven wrote his first symphony in C ...

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

Re: gdb load address and KERNELLOAD

[Dan Malek]

Wolfgang Denk wrote:

> The BDM4GDB  project  at  sourceforge  (see  bdm4gdb.sourceforge.net)
> provides all necessary information to build a home-made parallel port
> adapter  (schematics, source extension to GDB) which allows to do the
> same.

Really?  Like it handles all of the memory mapping details, too?


	-- Dan

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

Re: gdb load address and KERNELLOAD

[Wolfgang Denk]

In message <3ACB3E30.E17CC550@mvista.com> Dan Malek wrote:
>
> > The BDM4GDB  project  at  sourceforge  (see  bdm4gdb.sourceforge.net)
> > provides all necessary information to build a home-made parallel port
> > adapter  (schematics, source extension to GDB) which allows to do the
> > same.
>
> Really?  Like it handles all of the memory mapping details, too?

In fact the BDM4GDB had an implementation of MMU support  before  the
BDI200  had  it - credits to Frank Przybylski, who did all (and still
does most of) the work.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
I often quote myself; it adds spice to my conversation.  - G. B. Shaw

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

how to get the physival address

[jerry]

Hi All,

I have a silly question but seem I can not figure out the answer myself. I
try write a driver, in which I define a array like"

file : dummy.o

unsigned  char buffer_array[4096];

....

bdp->cbd_bufaddr  =  __pa(buffer_array);


my problem is: I try to get the physical address of buffer array, but the
_pa did not return correct address.

I try to print out:  buffer_array = 0xC4056220
                        _pa(buffer_array) = 0x4056220

But my RAM only 16M = 0x100000

My question is: how to get the physical address of buffer_array.

Thank for any answer
Jerry


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

Re: how to get the physival address

[Dan Malek]

jerry wrote:


> I try to print out:  buffer_array = 0xC4056220

To get an address like this, you must be loading the
driver as a module.  There are a variety of opinions about
how to do this, like using kmalloc() to dynamically allocate
the space after the module is loaded.  In the linuxppc_2_5
kernel from FSM Labs are some VM modifications I have started.
The virt_to_phys() is appropriate to use on the MPC8xx for this
sort of thing, and you can even do consistent_alloc() if you want
cache inhibited pages.  In older kernels, there are no functions
that will provide this for you (well, you can trudge through the
page tables, get the PTE and convert it yourself, but that sucks :-).


	-- Dan

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

Re: how to get the physival address

[jerry]

Yes, if I use kmalloc is OK, either __pa or virt_to_phys will return the
physical address.

But it does not work  for  defined variable (it was defined in driver so it
should be in kernel space, isn't it?). I  wonder  which memory space, this
variable belong to?

Thank in advances
Jerry

- Original Message -----
From: "Dan Malek" <dan@mvista.com>
To: "jerry" <jerry.nguyen@serialsystem.com.sg>
Cc: <linuxppc-embedded@lists.linuxppc.org>
Sent: Thursday, April 05, 2001 1:58 PM
Subject: Re: how to get the physival address


> jerry wrote:
>
>
> > I try to print out:  buffer_array = 0xC4056220
>
> To get an address like this, you must be loading the
> driver as a module.  There are a variety of opinions about
> how to do this, like using kmalloc() to dynamically allocate
> the space after the module is loaded.  In the linuxppc_2_5
> kernel from FSM Labs are some VM modifications I have started.
> The virt_to_phys() is appropriate to use on the MPC8xx for this
> sort of thing, and you can even do consistent_alloc() if you want
> cache inhibited pages.  In older kernels, there are no functions
> that will provide this for you (well, you can trudge through the
> page tables, get the PTE and convert it yourself, but that sucks :-).
>
>
> -- Dan


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

Re: how to get the physival address

[Dan Malek]

jerry wrote:

> But it does not work  for  defined variable (it was defined in driver so it
> should be in kernel space, isn't it?).

A loadable driver is dynamically allocated from kernel virtual memory.
The dynamic virtual memory does not have the 1:1 mapping property to
real memory that virt_to_phys(), __pa() or anything else expects.  To
me, based upon my past experience, you should be able to get this
mapping information for any virtual address, but others want to
argue about that point.  So, I have "fixed" the PowerPC verions of
these functions in the linuxppc_2_5 kernel, but who knows if it
will last.......


	-- Dan

--

	I like MMUs because I don't have a real life.

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

Re: how to get the physival address

[Gabriel Paubert]

On Thu, 5 Apr 2001, Dan Malek wrote:

>
> jerry wrote:
>
>
> > I try to print out:  buffer_array = 0xC4056220
>
> To get an address like this, you must be loading the
> driver as a module.  There are a variety of opinions about
> how to do this, like using kmalloc() to dynamically allocate
> the space after the module is loaded.  In the linuxppc_2_5
> kernel from FSM Labs are some VM modifications I have started.
> The virt_to_phys() is appropriate to use on the MPC8xx for this
> sort of thing, and you can even do consistent_alloc() if you want
> cache inhibited pages.  In older kernels, there are no functions
> that will provide this for you (well, you can trudge through the
> page tables, get the PTE and convert it yourself, but that sucks :-).
>

Furthermre there is no guarantee that the memory will be physically
contiguous. Unless magically aligned, a 4096 bytes buffer will almost
always span 2 pages.

	Gabriel.


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

RE: how to get the physival address

[Hua Ji]

>Yes, if I use kmalloc is OK, either __pa or virt_to_phys will return the
>physical address.
>But it does not work  for  defined variable (it was defined in driver so it
>should be in kernel space, isn't it?). I  wonder  which memory space, this
>variable belong to?

My 2 cents:

Given that ONLY 2 alternatives you can use for memory allocation when
working with kernel, which
are kmalloc and vmalloc, you are facing different memory usages:

Before talking further, you may have realized:

>From 0xC0000000 to 0XC0000000 + physical_memory_size is 1:1 mapped to
0x000000~physical memory size-1.

Surely, kernel also manages virtual memory from  0XC0000000 +
physical_memory_size + 8M hole to 4G

Therefore, if you used kmalloc to allocate memory, surely, you will easily
find: virtual address-3G is the physical address. However, for vmalloc, the
case is otherwise. The reason now is clear: That virtual address is very
probably from  0XC0000000 + physical_memory_size + 8M hole to 4G. This is
REALLY dynamic. Kernel's vmalloc, just like libc malloc, will go through the
free_area to find a first-bit(libc malloc is not first fit) block for you.

Anyway, back to your question. Your variable is in a memory space after 3G.
But it is byond the 3G+physical_memory_size + 8M. For example, your machine
have a 256M memory, so your variable virtual address is possible:
3G+256M+8M+SOME_VALUE.

Wish helpful,

Mike


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