Problems with MMU: address translation for 0xXXXXXXXX failed

Problems with MMU: address translation for 0xXXXXXXXX failed

[Jeremy Bowen]

I'm trying to get a BDI2000 (firmware v1.09) working in order to debug a
kernel module.
I'm using an Embedded Planet RPXlite MPC850 board running kernel v2.4.20
from kernel.org with CONFIG_BDI_SWITCH=y and CONFIG_COMPILE_OPTIONS="-g
-ggdb"
in my .config

I have compiled gdb v5.3 with --host=i686-pc-linux-gnu
--target=powerpc-linux.

The relevant bit of my BDI config file is here:
=====================================================================
WSPR    796             0x00000000      ;;M_TWB: invalibdate TWB
WM32    0x000000f0      0x00000000      ;;invalidate page table base
(PTBASE)

[TARGET]
CPUTYPE     MPC800
CPUCLOCK    50000000		;the CPU clock rate after processing the
init list
WORKSPACE   0x00000000		;workspace in target RAM for fast download
BDIMODE     AGENT       	;the BDI working mode (LOADONLY | AGENT)
BREAKMODE   SOFT	      	;SOFT or HARD, HARD uses PPC hardware
breakpoints
MMU XLAT                      ; Enable address translation
======================================================================

I have scanned the archives of this mailing list and have seen a number of
messages relating to getting the BDI working with the MMU but I don't seem
to be able to get this working on my system.

My kernel is stored in flash and booted by u-boot v0.3.0

I start the system by telneting into the BDI and issuing:
BDI>bi 0xc0000000 0xc00fffff
BDI>go

U-boot starts, loads the kernel and it is decompressed. At this point the
system stops. I then do the following:

BDI>ci
BDI>mm 0xf0 0xc014f000

(gdb) target remote 192.168.240.242:2001
Remote debugging using 192.168.240.242:2001
0xc00020f0 in start_here()
(gdb) c
Continuing.

Everything is OK until after I get a login prompt. After I log in, I don't
seem to be able to debug successfully. I'm wanting to break on a call from a
user-space program to a kernel function. On executing the program that
triggers the kernel breakpoint I get the following error in the telnet
session to the BDI

*** MMU: address translation for 0xC400E69C failed
...
*** MMU: address translation for 0xC0A05EF0 failed
etc..

and in dgb:

(gdb)
Cannot remove breakpoints because program is no longer writeable.
It might be running in another process.
Further execution is probably impossible.

Breakpoint 3, m8xx_cpm_dpalloc (size=16) at commproc.c:216
(gdb) bt
Cannot access memory at address 0xc0a05ef0

Am I missing something obvious ? Is this the right way to go about debugging
a loadable module ? Any help would be gratefully appreciated.

Cheers

Jeremy


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

Re: Problems with MMU: address translation for 0xXXXXXXXX failed

[Dan Malek]

Jeremy Bowen wrote:


> BDI>mm 0xf0 0xc014f000

Don't do this.  Use 'PTBASE 0xf0' in your BDI configuration file.
Chances are the 0xc014f000 is not the right number, so just let the
software determine this on its own.

If that doesn't work, just out of curiosity use hard breakpoints (set
BREAKMODE HARD).  Just test it setting one breakpoint.  If this works,
I suspect the BDI is honoring the write protection (via the MMU) on the
kernel text pages and we can't set a soft breakpoint.  In this case, we'll
have to add a kernel configuration to allow a debugger write.  The
CONFIG_KGDB and CONFIG_XMON enable the text writing, but they also add
too much baggage and could interfere with the BDI.  It's another thing
to try that would provide some information, though.  I didn't remember
the BDI having trouble with this before, but I could have been using
different software or configurations.

Thanks.


	-- Dan


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

Re: Problems with MMU: address translation for 0xXXXXXXXX failed

[Wolfgang Denk]

In message <DEA23DB61B62D4118B5900508B323B84012CC7D1@OPENMAIL> you wrote:
>
> I'm trying to get a BDI2000 (firmware v1.09) working in order to debug a
> kernel module.
> I'm using an Embedded Planet RPXlite MPC850 board running kernel v2.4.20
...
> Am I missing something obvious ? Is this the right way to go about debugging
> a loadable module ? Any help would be gratefully appreciated.

There were a couple of changes  /  extensions  to  the  MMU  support.
Firmware version 1.09 is pretty old (Aug 2001). You might want to try
a  more  recent one. Also check the changes to the Linux kernel - the
use of the PTBASE parameter has changed; the BDI2000 now expects (and
the Linux kernel automatically updates) the  physical  address  which
holds  the  virtual  address  of  the  array  with the two page table
pointers.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Status quo. Latin for "the mess we're in."

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

Re: Problems with MMU: address translation for 0xXXXXXXXX failed

[Wolfgang Denk]

In message <3EC07D9A.6050604@embeddededge.com> you wrote:
>
> If that doesn't work, just out of curiosity use hard breakpoints (set
> BREAKMODE HARD).  Just test it setting one breakpoint.  If this works,
> I suspect the BDI is honoring the write protection (via the MMU) on the
> kernel text pages and we can't set a soft breakpoint.  In this case, we'll
> have to add a kernel configuration to allow a debugger write.  The
> CONFIG_KGDB and CONFIG_XMON enable the text writing, but they also add
> too much baggage and could interfere with the BDI.  It's another thing

It should be sufficient to enable  CONFIG_BDI_SWITCH  in  the  kernel
configuration (after enabling CONFIG_DEBUG_KERNEL).


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
If it happens once, it's a bug.
If it happens twice, it's a feature.
If it happens more than twice, it's a design philosophy.

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

RE: Problems with MMU: address translation for 0xXXXXXXXX failed

[Jeremy Bowen]

Success!! Thanks for the replies. Here's a brief summary of what was
necessary to get things working.

> > I'm trying to get a BDI2000 (firmware v1.09) working in
> > order to debug a kernel module.
> > I'm using an Embedded Planet RPXlite MPC850 board running
> > kernel v2.4.20
> ...
> > Am I missing something obvious ? Is this the right way to
> > go about debugging
> > a loadable module ? Any help would be gratefully appreciated.
>
> There were a couple of changes  /  extensions  to  the  MMU  support.
> Firmware version 1.09 is pretty old (Aug 2001). You might want to try
> a  more  recent one.

OK. I couldn't find any firmware on the Abatron web-site but fortunately
I've been sent v1.12 from a friend. This seems to make all the difference.

I was able to make some minor progress with the addition of "PTBASE 0xF0" to
my config file (as suggested by Dan) however the key seems to have been the
upgraded firmware in the BDI2000.

I'm not entirely sure the soft breakpoints are working correctly yet (I
suspect they probably are) but anyway I can make sufficient progress using
hard breakpoints for now.

Thanks for the assistance.


--
Jeremy Bowen
Senior Software Engineer
OPEN Networks Ltd
Wellington
New Zealand

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

Re: Problems with MMU: address translation for 0xXXXXXXXX failed

[Wolfgang Denk]

In message <DEA23DB61B62D4118B5900508B323B84012CC7D5@OPENMAIL> you wrote:
>
> OK. I couldn't find any firmware on the Abatron web-site but fortunately
> I've been sent v1.12 from a friend. This seems to make all the difference.

Tell your friend that he did something illegal, and be aware that you
are now using pirated software.

The Abatron firmware is available only if you pay  for  the  license,
then  you  will get one your of updates. After that, you can purchase
an extension for the next year for 15% or the original price for  the
license.


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Everything should be made as simple as possible, but not simpler."
                                                    - Albert Einstein

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

RE: Problems with MMU: address translation for 0xXXXXXXXX failed

[Jeremy Bowen]

> Tell your friend that he did something illegal, and be aware that you
> are now using pirated software.

No! Hang on a minute. I object to your accusations of me being a pirate.

There is absolutely nothing anywhere that would indicate that upgrading the
firmware is illegal. There are no EULA's in the software or any mention of
this in any manuals and I can find nothing on the web-site. There is nothing
that I have to "click" to agree with when installing new firmware. The
firmware is distributed with no accompanying restrictions.

> The Abatron firmware is available only if you pay  for  the  license,
> then  you  will get one your of updates. After that, you can purchase
> an extension for the next year for 15% or the original price for  the
> license.

Is this like MicroSoft Licensing V6 ?? "You've bought the product but now
you have to keep paying us so you can use it!!"

This is a piece of hardware that I've bought and paid for. I cannot operate
the hardware that I own, without the firmware so the firmware is integral to
the device. If the firmware has bugs in it, should I have to pay for
bug-fixes ?

If that is, in fact, Abatron's business model then I think it sucks.

Upgrading the firmware/BIOS is commonplace in virtually any electronic
device these days. 98% of manufacturers make their BIOS updates available
free. Upgrading the firmware here allowed the product to work correctly.

As it turns out, my company does recieve updates from Abatron which I simply
hadn't applied, but again there is nothing in either the zip file or the
email that indicates anything about any restrictions on the use of the
firmware.

I don't believe I've done anything wrong and I would do the same thing next
time.

If you have any evidence to the contrary, please provide it before spreading
accusations.

Jeremy

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

Re: Problems with MMU: address translation for 0xXXXXXXXX failed

[Wolfgang Denk]

In message <DEA23DB61B62D4118B5900508B323B84012CC7D6@OPENMAIL> you wrote:
> > Tell your friend that he did something illegal, and be aware that you
> > are now using pirated software.
>
> No! Hang on a minute. I object to your accusations of me being a pirate.

I don't accuse, I just tell you.

> There is absolutely nothing anywhere that would indicate that upgrading the
> firmware is illegal. There are no EULA's in the software or any mention of
> this in any manuals and I can find nothing on the web-site. There is nothing
> that I have to "click" to agree with when installing new firmware. The
> firmware is distributed with no accompanying restrictions.

To get access to the firmware which comes on a floppy disk  you  have
to open the plastic bag thereby destroying a sticker that reads:

	License Agreement

        Against payment of a license fee the client receives the
        usage license for this software product which is not
        exclusive, cannot be transferred ...

I am not a lawyer, but this is pretty clear text, isn't it?

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Please keep your hands off the secretary's reproducing equipment.

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

Re: Problems with MMU: address translation for 0xXXXXXXXX failed

[Wolfgang Denk]

Jeremy,

in message <DEA23DB61B62D4118B5900508B323B84012CC7D6@OPENMAIL> you wrote:
>
> > The Abatron firmware is available only if you pay  for  the  license,
> > then  you  will get one your of updates. After that, you can purchase
> > an extension for the next year for 15% or the original price for  the
> > license.
>
> Is this like MicroSoft Licensing V6 ?? "You've bought the product but now
> you have to keep paying us so you can use it!!"

You can use it as long as you want. But Once the first year after the
purchase is over, you will not receive any new updates for  free  any
more.

If you need newer versions of the firmware you have to pay a  license
fee.

> This is a piece of hardware that I've bought and paid for. I cannot operate
> the hardware that I own, without the firmware so the firmware is integral to
> the device. If the firmware has bugs in it, should I have to pay for
> bug-fixes ?

If you didn't find the bugs during the first year of usage, then yes,
you have to pay for support & updates.



> If that is, in fact, Abatron's business model then I think it sucks.

Try to find _any_ tool provider that has better support!


> As it turns out, my company does recieve updates from Abatron which I simply
> hadn't applied, but again there is nothing in either the zip file or the
> email that indicates anything about any restrictions on the use of the
> firmware.

You receive the email only as long as you are entitled for it - i. e.
after installing the initial version from the floppy, which  contains
the  License Agreement. And the email updates will stop once one year
is over and you don't purchase an extension.

> I don't believe I've done anything wrong and I would do the same thing next
> time.
>
> If you have any evidence to the contrary, please provide it before spreading
> accusations.

You stated that you received the software "from a  friend".  This  is
not  exactly  the  same  as  receiving  an  official update from your
distributor.


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
It is the quality rather than the quantity that matters.
- Lucius Annaeus Seneca (4 B.C. - A.D. 65)

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

Re: Problems with MMU: address translation for 0xXXXXXXXX failed

[Wolfgang Denk]

In message <DEA23DB61B62D4118B5900508B323B84012CC7D7@OPENMAIL> you wrote:
> > I don't accuse, I just tell you.
>
> You can tell me I'm a purple elephant but that doesn't make it true :-)

I just tell you a fact: The BDI2000 firmware is  a  software  product
for which you have to pay a license fee. The license explicitely says
that this license cannot be transferred.

> > To get access to the firmware which comes on a floppy disk  you  have
> > to open the plastic bag thereby destroying a sticker that reads:
>
> To access the new firmware, I unzip the zip file.
> There is no text to read. There is no license agreement.
>
> > I am not a lawyer, but this is pretty clear text, isn't it?
>
> There was *no* text accompanying the zipfile.

I want to call your attention to the fact that if  you  received  the
zip  file  from  anyboy else but Abatron support or from one of their
official distributors you might have been given an  illegal  copy  of
the software.

In the previous message you claimed that you were using version  1.09
before, i. e. you must have purchased your BDI2000 before the release
of  1.10 which was in November 2001. So your one year warranty period
must have ended in November 2002 (or earlier). 1.12 was  released  in
anuary  2003  -  if  you  did not pay for an extension of the support
(which you obviously did not, as you did  not  even  know  that  this
option exists) you probably have no legal right to use version 1.12.


I agree that it is unfortunate that Abatron did not include any  EULA
or  other  legal  stuff in their zip files. I have put Abatron on the
Cc: list, maybe they will change this now.


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
A fanatic is a person who can't change his mind and won't change  the
subject.                                          - Winston Churchill

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

Re: Problems with MMU: address translation for 0xXXXXXXXX failed

[Wolfgang Denk]

In message <DEA23DB61B62D4118B5900508B323B84012CC7D8@OPENMAIL> you wrote:
>
> I'm happy to pay a hardware maintenenace contract for if the hardware breaks
> down but if the product I bought initially contains a defect in manufacture
> then I see no reason to have to pay for this fault. The defect in this case
> is buggy firmware.

You may be wrong again.

Are you absolutely sure that it's  a  bug  in  the  firmware?  Please
consider  the possibility that the firware was designed for a version
of the Linux kernel which showed a  different  behaviour.  You  might
want  to  check  when  the PTBASE support first appeared in the Linux
kernel and relate this to BDI2000 firmware releases.

> > You stated that you received the software "from a  friend".  This  is
> > not  exactly  the  same  as  receiving  an  official update from your
> > distributor.
>
> Not it is not the same, however both statements can be true with no
> contradiction.

Let's put it straight: either you (or  your  company)  payed  for  an
extension  of  your  software  support,  or  your  copy of the bdiGDB
software version 1.12 is illegal. Period.


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
A bore is someone who persists in holding his own views after we have
enlightened him with ours.

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

RE: Problems with MMU: address translation for 0xXXXXXXXX failed

[Jeremy Bowen]

> You may be wrong again.
> Are you absolutely sure that it's  a  bug  in  the  firmware?

The old firmware doesn't work. The new firmware does. I'd call that a bug.

> Please
> consider  the possibility that the firware was designed for a version
> of the Linux kernel which showed a  different  behaviour.  You  might
> want  to  check  when  the PTBASE support first appeared in the Linux
> kernel and relate this to BDI2000 firmware releases.

>From the BDI release notes it appears that this was corrected in BDI2000
firmware v1.10 (2 Nov 2001) - clearly listed as a bug-fix. This corresponds
approximately with the release of Linux kernel v2.4.13

BDI v1.09 (11 Aug 2001) release notes indicates support for changed Linux
MMU behaviour coinciding with Linux kernel v2.4.7/8

Therefore, as v1.09 doesn't work on my kernel and v1.12 does, this fix in
v1.10 was made to correct behaviour that has been present in kernels since
v2.4.12 if not before.

I suspect that had I upgraded only to v1.10 I would also have solved the
issues as the release notes do not indicate any bug-fixes since v1.10

> Let's put it straight: either you (or  your  company)  payed  for  an
> extension  of  your  software  support,  or  your  copy of the bdiGDB
> software version 1.12 is illegal. Period.

Wrong. You have been unable to demonstrate anything illegal.
I still believe I'm completely and entirely innocent here. I have acted in
good faith and cannot find any evidence of a license agreement you say I've
breached.

* I can find no documentation anywhere about what the "software support"
consists of or what it entitles me to. Email ? 24 hour phone ? Feature
requests ? Updates ?

* There is nothing to indicate that firmware upgrades are time limited to
only 1 year. Nor on the other hand is there anything to indicate that I'm
entitled to any firmware updates at all. There is simply no information
whatsoever.

* The only licensing agreement anywhere was apparently on the "packaging" of
the original floppy (long since discarded), which could easily be argued
applied only to the software on that floppy. (Shrinkwrap licenses are a
whole other issue anyway)

* There is nothing to indicate that the firmware updates are licensed
software items nor that they are only available to purchasers of extended
licenses.

* There is nothing on the Abatron web-site which indicates that extended
support is even available to be purchased. We received no information to
this effect when we purchased the BDI2000's either.

* I have received firmware updates in their original form and without
modification and there is nothing either accompanying them nor contained
within to suggest that their use is restricted.

* Driver/BIOS/firmware updates are standard industry practices and, without
a single exception I can think of, are provided free and unencumbered by
restrictive licenses. I had no reason (nor any evidence) to think that this
should be any different for the BDI.

* Wolfgang, you even told me to use a newer version of the firmware without
indicating any issues with licenses.

All of the above may well be an oversight by Abatron but for you to suggest
that what I have done is illegal is just plain wrong. All we have is your
un-supported opinion that I'm not supposed to be running v1.12 firmware
(which I reject).

It is Abatron's responsibility to ensure that, if their software has license
restrictions, these are distributed with the software, but as there are no
such restrictions, I fail to see what you're complaining about.

Jeremy Bowen


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

Re: Problems with MMU: address translation for 0xXXXXXXXX failed

[Dan Malek]

Jeremy Bowen wrote:

> The old firmware doesn't work. The new firmware does. I'd call that a bug.

Abatron was very good at working with us through a couple of different
Linux support implementations.  We (well, I) decided how to do it, Abatron
provided the support, then we (I) changed our mind to add more support.

Some versions of the PPC kernel require v1.08 of the BDI-2000 firmware,
others require v1.09, and I think with v1.10 we finally got it right.
It's not Abatron's fault, and I didn't keep track of which versions of
firmware worked with what kernels.  I'm running v1.10, and I guess I
could make a kernel configuration so v1.09 of their firmware works.

Abatron should be given a "best vendor to support Linux" award.  They
are kind and patient with us, and gave us exactly the tool we asked
for.  I'm certain if you asked Abatron support for assistance, they
will provide what you need.


> Wrong. You have been unable to demonstrate anything illegal.
> I still believe I'm completely and entirely innocent here. I have acted in
> good faith and cannot find any evidence of a license agreement you say I've
> breached.

Did you actually ask Abatron for an update?  :-)  Sorry, I've unfortunately
had to spend too much time with lawyers while in the software business.

I don't want to get involved in this argument.  I just want to say that
most of us have to work for a living and like to get paid for the work
we do.  The few hundred dollars they may have asked for would have already
saved you many times more than that.  I'm particularly sensitive to this
because some of the largest corporations in the world have expected me
to work for free, taken forever to pay invoices of a few thousand dollars,
for work I've done that has made them millions of dollars on the product.
We shouldn't treat each other that way.


	-- Dan


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