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/

[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. :)]

No problem.

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
[email protected]

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

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.

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/

Sure, we believe you. :)

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

Regards,
--
Matt Porter
[email protected]

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

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: [email protected] 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/

Hi Wolfgang,

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

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/

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" <[email protected]>
To: <[email protected]>
Sent: Friday, August 01, 2003 1:54 AM
Subject: 750/107 CHRP question

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