Hi, all
I am using BDI2000 to debug dynamically loaded module under Linux. When I
put a breakpoint, it never goes off, but code does execute.
At the moment the only 8260 board we have is used 100% of the time, so I do
not have much chance to do any investigation.
I'll describe what I do, may be
Hi JoAnna.
I'm just a user of the driver of Gabriel and I need to use
it in normal user applications. Givint public r/w permission to /dev/vme
is not enough, since the driver will not accept to change the
attribute if you are not root. I have found the following
workaround, which
Hi,
i trying to run a Compact Flash on MBX860,
i have a 2.4.2_hhl20 Montavista Kernel and Linux
PCMCIA Card Services 3.1.22 running on the board.
Kernel has MTD support.
Kernel has msdos,vfat support.
When I put the Compact Flash into the socket the next
message appear:
fatfs: bogus cluster
Just one dumb question: do you have branches to self in ALL the unused
exceptions (since you don't appear to be using any in your monitor, that
would be all but the reset exception)? Is it possible you are getting a
different exception and your CPU is executing uninitialized memory (opcode
Just a guess...when you do the add-symbol-file, do you specify the
address for the .text (and possibly other) section(s)? If you don't,
I'm not sure what it will default to be, but it will almost certainly be
wrong.
When you do the insmod, use the -m parameter and redirect the output to
the
On the IBM book E part, __va()/__pa() will have to be obsoleted. The
address space is
36 bits. Better now than later.
These macros are not used on I/O space addresses, and would continue
to work properly on the Book E parts when used as intended. In fact they
are still used in all kernel
I've made some progress but have hit a strange snag and would
appreciate any context / suggestions you might have.
I'm able to run gdbserver on the target,
connect to it w/ target remote ...
list a small test program being debugged,
set multiple breakpoints,
and (c)ontinue -- the first
Hi JoAnna,
I think the following code fragments in the ioctl function of the VME driver
simply prevent normal users from doing bad things:
/* Is this the right capability to use ? Everybody seems
to use
* CAPS_SYS_ADMIN as a default to replace suser().
Hello!
I am having problems booting HardHat Linux kernel on Sandpoint.
After uncompress_kernel() writes the message
Now booting the kernel
and the booter jumps the the kernel, there is a delay of at least 40
(forty) minutes before the kernel displays the messages (see the log at
the end of
Hi, all.
Seeing this is topical right now...
I get a LOT of failed MMU translations reported.
Is this b/c I have something misconfigured?
I'm running 2.4.18 out of bk on an 860P.
TIA,
Regards,
Matt
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
It's straight 2_4. I wasn't stopping at start_kernel though.
I don't have PTBASE set up.
Not sure what I need.
Following some advice from mattl on #mklinux, I'm going to
break at start kernel FIRST, then connect with BDI, then
see if I can look at my data.
THX and Regards,
Matt
Gessner, Matt wrote:
It's straight 2_4. I wasn't stopping at start_kernel though.
You don't need to stop anywhere unless there are some breakpoints
you want to set for early debug.
I don't have PTBASE set up.
You need:
MMU XLAT 0xc000
PTBASE 0x00f0
The newer
Ok,
This still doesn't solve my problem.
In the Makefile:
CONFIG_KERNEL = -g -ggdb
In mpc860.cnf for the bdi:
MMU XLAT 0xc000 (this is the default BTW)
PTBASE 0xf0
BREAK SOFT
On the BDI:
bi 0xc0157640 (start_kernel)
go
breakpoint
Ah... breaking at start_here works much better...
-Original Message-
From: Dan Malek [mailto:dan at embeddededge.com]
Sent: Wednesday, January 23, 2002 5:51 PM
To: Gessner, Matt
Cc: 'Linux PPC'
Subject: Re: BDI2000 and failed MMU translations
Gessner, Matt wrote:
It's
Whooops, too soon.
OK, AFTER the first breakpoint, it then gets mad about
single stepping.
The MMU xlation fails for the next address.
Matt
-Original Message-
From: Dan Malek [mailto:dan at embeddededge.com]
Sent: Wednesday, January 23, 2002 5:51 PM
To: Gessner, Matt
Cc: 'Linux
Gessner, Matt wrote:
Whooops, too soon.
I'm sure it's my fault, I'm sorry.
I started making some changes to support large page sizes and I think
it screwed up the BDI2000. I'll have a patch in as quickly as possible
(yet tonight) and post it. I won't be able to test it with the BDI2000
but
16 matches
Mail list logo
