Progress - new problem

Progress - new problem

[Sébastien Côté]

Hi,

I progressed quite a bit since my last e-mail... I put back KERNELBASE +
PAGE_OFFSET + KERNELLOAD to 0xc0000000 even though it complicates debugging
quite a bit.  Now, the kernel goes through create_elf_tables without a
problem.  The elf file (init) seems to have been loaded correctly.

Now, the problem.  When the kernel tries to jump to the first address of
the executable (0x10000074), I get an Instruction Access Exception and it
jumps to address 0x400.  I guess this should be ok and the the memory pages
should then be set up correctly.  However, these pages never seem to be set
correctly!  The kernel jumps back and forth between the executable
(0x10000074) and InstructionAccess (0x400), forever it seems.  Now I have
no idea what could be wrong!

Here is what my BATs point to (I didn't change the default configuration):
IBAT0 = 0
IBAT1 = 0
IBAT2 = C0000000 pointing to 0
IBAT3 = 0

DBAT0 = F0000000 pointing to F0000000
DBAT1 = 80000000 pointing to 80000000
DBAT2 = C0000000 pointing to 0
DBAT3 = 0

Board is similar to Sandpoint, processor is 7400 running in little-endian.
Btw, r3 hasn't been filled with PReP at boot, I didn't think it would
really matter (and since I got this far, I think it didn't).

Thanks!

Sébastien Côté

P.S.:  What do you guys use for debugging?  Is there any debugger out there
that does address translation (from MMU) to see what instruction gets
executed when you're at a virtual address?


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

Re: Progress - new problem

[Wolfgang Denk]

In message <20010209161931.A30585@dyn-52-73.matrox.com> you wrote:
>
> I progressed quite a bit since my last e-mail... I put back KERNELBASE +
> PAGE_OFFSET + KERNELLOAD to 0xc0000000 even though it complicates debugging
> quite a bit.  Now, the kernel goes through create_elf_tables without a

Oops? Why do you think this makes debugging more complicated? I don't
care where something is mapped, it's  the  job  of  the  debugger  to
resolve those addresses, isn't it?

> Board is similar to Sandpoint, processor is 7400 running in little-endian.
                                                              ^^^^^^^^^^^^^^
							      ^^^^^^^^^^^^^^

Are you really trying to run in little-endian mode? Really???
You are not supposed to do that.

> P.S.:  What do you guys use for debugging?  Is there any debugger out there
> that does address translation (from MMU) to see what instruction gets
> executed when you're at a virtual address?

We use the Abatron BD2000; it supports the MMU, interfaces to  GDB  /
DDD,  comes  with  3  years  of warranty on the hardware, _excellent_
support from the Abatron folks, and is cheaper than  other  solutions
(2500 Euro).

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Visit us at Embedded Systems: Feb 14-16 2001, Nuremberg, Halle 12/K01
(with TQ Components); our presentation "Starke Zwerge: Embedded Linux
auf PowerPC-Systemen" on Thursday, Feb 15 2001, 13:30 Forum Halle 11.

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

Re: Progress - new problem

[Wolfgang Denk]

Dear Sébastien,

in message <20010212083954.A768@dyn-52-73.matrox.com> you wrote:
>
> > Oops? Why do you think this makes debugging more complicated? I don't
> > care where something is mapped, it's  the  job  of  the  debugger  to
> > resolve those addresses, isn't it?
>
> Yes, the debugger should do it but ours don't.  Also, I haven't found a way

Then convert it into a doorstop, and get a real debugger.

I strongly recommend the BDI2000  by  Abatron  (see  www.abatron.ch).
Send me a message when you want a quote for it.

> to tell it to load the kernel image at address 0 even if the linking was
> done for address 0xc0000000.  So I have to load the kernel with another

You can't specify any load offsets? Oh dear. Get a real debugger!

> > Are you really trying to run in little-endian mode? Really???
> > You are not supposed to do that.
>
> Yes, really!  I don't see why I shouldn't do that.  The kernel itself seems
> to be running fine (no panic, it goes to the scheduler).  My only problem
> right now is to load executables and I'm not sure it's endian related.

Be assured that this will not remain the only problem. From all I know,
the PowerPC version of Linux is a big-endian kernel by design.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Visit us at Embedded Systems: Feb 14-16 2001, Nuremberg, Halle 12/K01
(with TQ Components); our presentation "Starke Zwerge: Embedded Linux
auf PowerPC-Systemen" on Thursday, Feb 15 2001, 13:30 Forum Halle 11.

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

Re: Progress - new problem

[Marius Groeger]

Hi Ross,

On Mon, 12 Feb 2001, Ross A. Osborn wrote:

> I have been fighting with an old Nohau BDM debugger and was trying to
> get information together to talk my boss into ordering the BDI2000.  I
> could not find any price information on there web site.

I believe the BDI2000 sells for about 2000 Euro. I can only recommend to buy
one, the units are definitely worth the money. They have a very compentent
and helpful support staff. Today they sent me a new firmware update, without
having been asked for it.

> So, the right thing to do is to send you a message to a quote?  Is it
> just me or is this an odd way to conduct business?

Try Abatron's phone or mail contact, they are usually very responsive.

Regards,
Marius

-----------------------------------------------------------------------------
Marius Groeger           SYSGO Real-Time Solutions GmbH     mgroeger@sysgo.de
Software Engineering     Embedded and Real-Time Software    www.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14                 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com


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

Re: Progress - new problem

[Marius Groeger]

On Mon, 12 Feb 2001, Sébastien Côté wrote:

> Believe me, I'd really like to do the doorstop thing but support for
> 74xx is very difficult to find.  Abatron doesn't seem to be an
> exception... :-(

Check out http://www.abatron.ch/News/news.html. The latest version of
the firmware, V1.07 supports the MPC7400.

Regards,
Marius

-----------------------------------------------------------------------------
Marius Groeger           SYSGO Real-Time Solutions GmbH     mgroeger@sysgo.de
Software Engineering     Embedded and Real-Time Software    www.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14                 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com


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

Re: Progress - new problem

[Matt Porter]

On Mon, Feb 12, 2001 at 03:35:33PM +0100, Marius Groeger wrote:
>
> On Mon, 12 Feb 2001, Sébastien Côté wrote:
>
> > Believe me, I'd really like to do the doorstop thing but support for
> > 74xx is very difficult to find.  Abatron doesn't seem to be an
> > exception... :-(
>
> Check out http://www.abatron.ch/News/news.html. The latest version of
> the firmware, V1.07 supports the MPC7400.

MPC7410 support is there, as well.  The new rev. C hardware that handles
down to 1.8V I/O is supposed to be available too.

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

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

Re: Progress - new problem

[Ross A. Osborn]

On Mon, Feb 12, 2001 at 02:52:25PM +0100, Wolfgang Denk wrote:
>
> Dear Sébastien,
>
> in message <20010212083954.A768@dyn-52-73.matrox.com> you wrote:
> >
> > > Oops? Why do you think this makes debugging more complicated? I don't
> > > care where something is mapped, it's  the  job  of  the  debugger  to
> > > resolve those addresses, isn't it?
> >
> > Yes, the debugger should do it but ours don't.  Also, I haven't found a way
>
> Then convert it into a doorstop, and get a real debugger.
>
> I strongly recommend the BDI2000  by  Abatron  (see  www.abatron.ch).
> Send me a message when you want a quote for it.

I have been fighting with an old Nohau BDM debugger and was trying to
get information together to talk my boss into ordering the BDI2000.  I
could not find any price information on there web site.

So, the right thing to do is to send you a message to a quote?  Is it
just me or is this an odd way to conduct business?

This will certainly not make it any easier to convice my boss to buy
this instead of (or in addition to) the EST products they are currently
looking at.

--
|      Ross Osborn        |   Motorola, Broadband Comm. Sector   |
|     rosborn@gi.com      |        101 Tournament Drive          |
|                         |         Horsham, PA 19044            |


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

Re: Progress - new problem

[Sébastien Côté]

Wolfgang Denk wrote:
> Then convert it into a doorstop, and get a real debugger.
>
> I strongly recommend the BDI2000  by  Abatron  (see  www.abatron.ch).
> Send me a message when you want a quote for it.

Believe me, I'd really like to do the doorstop thing but support for
74xx is very difficult to find.  Abatron doesn't seem to be an
exception... :-(

Sébastien Côté

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

Re: Progress - new problem

[Wolfgang Denk]

In message <20010212095429.E8453@gi.com> Ross A. Osborn wrote:
>
> I have been fighting with an old Nohau BDM debugger and was trying to
> get information together to talk my boss into ordering the BDI2000.  I
> could not find any price information on there web site.
>
> So, the right thing to do is to send you a message to a quote?  Is it
> just me or is this an odd way to conduct business?

Well, yes, we are a reseller for Abatron, so you can ask me.

Please understand that I don't want to flood this mailing  list  with
too obvious commercial plugs :-)

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Visit us at Embedded Systems: Feb 14-16 2001, Nuremberg, Halle 12/K01
(with TQ Components); our presentation "Starke Zwerge: Embedded Linux
auf PowerPC-Systemen" on Thursday, Feb 15 2001, 13:30 Forum Halle 11.

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

Re: Progress - new problem

[Wolfgang Denk]

Hi Ross,

in message <20010212095429.E8453@gi.com> you wrote:
>
> I have been fighting with an old Nohau BDM debugger and was trying to
> get information together to talk my boss into ordering the BDI2000.  I
> could not find any price information on there web site.

Please understand that I cannot speak for the design and contents  of
Abatron's  web pages.

Speaking for us: we are a reseller for Abatron, and I  certainly  can
send  you a quote. But I'm pretty sure there is US based reseller for
Abatron, too. I have no idea if the US prices  are  highr  or  lower
than ours.

> So, the right thing to do is to send you a message to a quote?  Is it
> just me or is this an odd way to conduct business?

In such situations I'm biased when posting to the  mailing  list.  On
one  side,  I like to help, and give the best advice I am able to. On
the other  side,  this  _is_  commercial  advertising,  and  as  such
inappropriate for the list.

If we're talking directly to each other, we can talk clean business :-)

> This will certainly not make it any easier to convice my boss to buy
> this instead of (or in addition to) the EST products they are currently
> looking at.

Well, when comparing products, just ask a few questions:

* How much does the Linux version of the debugger cost? [And how much
  is the Windows version, and why is there a difference, if any?]

  Our price for  the  BDI2000  bundled  with  bdiGDB  software  which
  interfaces  to  GDB  is  2500  Euro, or about $ 2325 (including the
  power supply).

* Does the debugger support the MMU? Will you get  a  guarantee  that
  you  can  use  it to symbolically debug the LInux kernel, including
  automatic variables (on the stack)?

  Many debuggers fail here, and AFAIK the EST is one of them.  Lately
  I've heard that they provide some MMU support, but it sounded as it
  was  just  for  static  mappings,  so  it  would  fail  for dynamic
  situations like data on the stack.

* Is there any warranty? The BDI2000 comes with 3 years  of  warranty
  for the hardware.

* How good is there  support  if  you  have  any  problems,  or  need
  extensions, etc.?


OK, now I want to ask you a question: what hardware do you  have?  If
you  can  do  with  BDM,  are  you  aware  of  the BDM4GDB project at
sourceforge? You can built the parallel port adapter yourself, or get
it for less than $ 50.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Visit us at Embedded Systems: Feb 14-16 2001, Nuremberg, Halle 12/K01
(with TQ Components); our presentation "Starke Zwerge: Embedded Linux
auf PowerPC-Systemen" on Thursday, Feb 15 2001, 13:30 Forum Halle 11.

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

Re: Progress - new problem

[Sébastien Côté]

Matt Porter wrote:
> MPC7410 support is there, as well.  The new rev. C hardware that handles
> down to 1.8V I/O is supposed to be available too.

The only problem is that they do not support little-endian.  Otherwise,
it looks like a very good product.  I guess I'll keep on working with
bad tools!

Sébastien Côté

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