Re: 750/107 CHRP question

Re: 750/107 CHRP question

[Richard Danter]

Wolfgang Denk wrote:
> In message <3F2A21D5.2040204@windriver.com> you wrote:
>
>>There is a command in the vICE-II called "CF MMU LINUX" which turns on
>>MMU handling (doesn't have to be Linux running) and then you use the
>>MMUA command to set up the mapping (eg MMUA C0000000 0 F0000000) and hey
>>presto!
>
> Will this work just for code statically linked with  the  kernel,  or
> also  for  dynamically  loaded  modules?  How about accessing dynamic
> variables on the stack?
>
> My understanding is that more than just a static  mapping  is  needed
> for full MMUP support.

You are correct. Only the kernel and drivers statically linked can be
easily debugged. It could be possible to debug modules but since the
addresses change every time you load them it would not be practical. You
would have to edit the symbol files (*.ab) each time.

For complete MMU handling the debugger would need to know where to find
the mapping tables and remap it's symbol info. None of our debuggers can
do that yet.

Rich


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

Re: 750/107 CHRP question

[Wolfgang Denk]

Dear Richard,

in message <3F2A2CB6.4030104@windriver.com> you wrote:
>
> > My understanding is that more than just a static  mapping  is  needed
> > for full MMUP support.
>
> You are correct. Only the kernel and drivers statically linked can be
> easily debugged. It could be possible to debug modules but since the
> addresses change every time you load them it would not be practical. You
> would have to edit the symbol files (*.ab) each time.

Thanks for confirming this.

> For complete MMU handling the debugger would need to know where to find
> the mapping tables and remap it's symbol info. None of our debuggers can
> do that yet.

Are there any plans to add such support?


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
Intuition, however illogical, is recognized as a command prerogative.
	-- Kirk, "Obsession", stardate 3620.7

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

Re: 750/107 CHRP question

[Richard Danter]

Wolfgang Denk wrote:
>>For complete MMU handling the debugger would need to know where to find
>>the mapping tables and remap it's symbol info. None of our debuggers can
>>do that yet.
>
>
> Are there any plans to add such support?

Very good question. Unfortunately I do not know the answer. :(

Rich


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

750/107 CHRP question

[Richard Danter]

Hi All,

Sorry if this is a bit of a newbie question....

I am trying to port a 2.4.x kernel to a PPC750 board with a 107
controller. The board has a serial port connected to one of the ROM
select lines (at 0x7C000000) and I would like to use this as my console
port.

So far I can boot the board and see (via the serial port) the kernel
load addresses etc, and the kernel gets decompressed and starts to run.
This is all fine as the MMU is off at this point. However, when the
serial_console_setup() code starts trying to configure the serial port
again, I get a kernel panic as I am accessing an invalid mem space (MMU
now on!).

How do I map this correctly???

My build is based on the sandpoint but with all the init stuff for
devices, such as the RTC, removed. So I have the "standard" mapping in
the MMU_init code.

Many thanks
Rich


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

Re: 750/107 CHRP question

[Matt Porter]

[Oh my !#$!@.  I never thought I'd be replying to a Linux question
 from WRS. I need to check for reports of natural disasters and
 mass rioting. :)]

On Thu, Jul 31, 2003 at 05:54:43PM +0100, Richard Danter wrote:
> I am trying to port a 2.4.x kernel to a PPC750 board with a 107
> controller. The board has a serial port connected to one of the ROM
> select lines (at 0x7C000000) and I would like to use this as my console
> port.

No problem.

> So far I can boot the board and see (via the serial port) the kernel
> load addresses etc, and the kernel gets decompressed and starts to run.
> This is all fine as the MMU is off at this point. However, when the
> serial_console_setup() code starts trying to configure the serial port
> again, I get a kernel panic as I am accessing an invalid mem space (MMU
> now on!).
>
> How do I map this correctly???

In 2.4, you can use early_serial_setup() or io_block_map().  It is
highly recommended to use early_serial_setup().  There are many
examples of this (spruce, lopec, etc.)

Regards,
--
Matt Porter
mporter@kernel.crashing.org

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

Re: 750/107 CHRP question

[Richard Danter]

Matt Porter wrote:
> [Oh my !#$!@.  I never thought I'd be replying to a Linux question
>  from WRS. I need to check for reports of natural disasters and
>  mass rioting. :)]

LOL!!

Yes, I work for WRS, but this is a little personal project just for the
hell of it. I just happen to be using a WRS board and vICE to do the
debugging.

>>
>>How do I map this correctly???
>
> In 2.4, you can use early_serial_setup() or io_block_map().  It is
> highly recommended to use early_serial_setup().  There are many
> examples of this (spruce, lopec, etc.)

Thanks, I'll take a look at that.

I'm sure this bit is easy, the tricky stuff will probably be when I
start playing with PCI...

Rich


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

Re: 750/107 CHRP question

[Matt Porter]

On Thu, Jul 31, 2003 at 10:41:01PM +0100, Richard Danter wrote:
>
> Matt Porter wrote:
> > [Oh my !#$!@.  I never thought I'd be replying to a Linux question
> >  from WRS. I need to check for reports of natural disasters and
> >  mass rioting. :)]
>
> LOL!!
>
> Yes, I work for WRS, but this is a little personal project just for the
> hell of it. I just happen to be using a WRS board and vICE to do the
> debugging.

Sure, we believe you. :)

> >>How do I map this correctly???
> >
> > In 2.4, you can use early_serial_setup() or io_block_map().  It is
> > highly recommended to use early_serial_setup().  There are many
> > examples of this (spruce, lopec, etc.)
>
> Thanks, I'll take a look at that.
>
> I'm sure this bit is easy, the tricky stuff will probably be when I
> start playing with PCI...

That'll be easy too.  Look at how the MPC10x-based ports are using
the mpc10x_common.c code.

Regards,
--
Matt Porter
mporter@kernel.crashing.org

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

Re: 750/107 CHRP question

[Wolfgang Denk]

In message <3F298CED.8010701@windriver.com> you wrote:
>
> Yes, I work for WRS, but this is a little personal project just for the
> hell of it. I just happen to be using a WRS board and vICE to do the
> debugging.

Did you try what happens when you disconnect the visionIce?
Are you 100% sure it understands virtual addresses correctly?

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
And now remains  That we find out the cause of this effect, Or rather
say, the cause of this defect...           -- Hamlet, Act II, Scene 2

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

Re: 750/107 CHRP question

[Richard Danter]

Hi Wolfgang,

I am CC'ing the list as there may be some useful info in here...

Wolfgang Denk wrote:
> In message <3F298CED.8010701@windriver.com> you wrote:
>>Yes, I work for WRS, but this is a little personal project just for the
>>hell of it. I just happen to be using a WRS board and vICE to do the
>>debugging.
>
> Did you try what happens when you disconnect the visionIce?
> Are you 100% sure it understands virtual addresses correctly?

Yes, in fact besides my personal interest in Linux, my job is supporting
visionXXX customers (I worked for EST before it was bought by WR).

There is a command in the vICE-II called "CF MMU LINUX" which turns on
MMU handling (doesn't have to be Linux running) and then you use the
MMUA command to set up the mapping (eg MMUA C0000000 0 F0000000) and hey
presto!

I have been stepping through the kernel source code quite happily. I
tracked the problem down the the point where the 1st write occurs to the
serial port. If I let it run on from there I end up in an inf. loop
which just jumps to itself. When I reach that point I can stop the
target and use the memory window to dump the "log_buf" which is where
all the kprintf messages are going and I can get the back trace from
that and it points to the same offending instruction in serial setup.

I also tried not having a serial port compiled in and everything works
perfectly.

It is fixed now tho as I decided to add a ioremap() call. The other
suggestions I got ware probably more flexible but this was so simple -
just editing 1 line.


Rich


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

Re: 750/107 CHRP question

[Sangmoon Kim]

Hi,

Some serial port driver doesn't ioremap and directly use the physical address for accessing device.
This doesn't causes any problem when the base address is above 0x80000000.

There are two solutions for this
Solution 1. Change the serial port base address above 0x80000000, such as 0xff000000.

Solution 2. Ioremap to get the base address of the serial port and use the address.
ie. base = ioremap(0x7c000000,0x1000);

I think the solution 2 is more appropriate because changing hardware requires a lot of money.

Regards,
Sangmoon Kim

----- Original Message -----
From: "Richard Danter" <richard.danter@windriver.com>
To: <linuxppc-embedded@lists.linuxppc.org>
Sent: Friday, August 01, 2003 1:54 AM
Subject: 750/107 CHRP question


>
> Hi All,
>
> Sorry if this is a bit of a newbie question....
>
> I am trying to port a 2.4.x kernel to a PPC750 board with a 107
> controller. The board has a serial port connected to one of the ROM
> select lines (at 0x7C000000) and I would like to use this as my console
> port.
>
> So far I can boot the board and see (via the serial port) the kernel
> load addresses etc, and the kernel gets decompressed and starts to run.
> This is all fine as the MMU is off at this point. However, when the
> serial_console_setup() code starts trying to configure the serial port
> again, I get a kernel panic as I am accessing an invalid mem space (MMU
> now on!).
>
> How do I map this correctly???
>
> My build is based on the sandpoint but with all the init stuff for
> devices, such as the RTC, removed. So I have the "standard" mapping in
> the MMU_init code.
>
> Many thanks
> Rich
>
>
>
>

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