Linux 2.6 on MPC5200. First port attempt ... Early problems ;(

Linux 2.6 on MPC5200. First port attempt ... Early problems ;(

[Sylvain Munaut]

Hello,

I'd like to run a 2.6 on a MPC5200 based board. Even if at first I'll
only use a 2.4 in production, I figured that the sooner I start to test
2.6, the sooner I'll be able to use it with enough stability. So I
started to tweak the 2.6.3 tree to make it boot on my LITE5200.

So, I've written/ported/copied some code for the console, the early
serial debug, ..., added the MPC to cputable.c and modified the
Kconfig/Makefile to build theses.
So far I don't seen anything on the serial console and  apparently, the
call the setup_common_caches ( in the cpu_setup_6xx.S ), never returns.
But the code is an exact copy of the 2.4 version ...

The method I use to trace where the execution goes or not is through the
leds connected to the GPIOs. From what I understood, the MBAR (
0xf0000000 ) is always mapped so I can trace with MMU on or off.

Anyone could give me a clue ?


Sylvain Munaut


PS: I'm not an expert in PPC arch. However, I've done such a port ( 2.4
-> 2.6 ) for an ARM architecture, so I'm not completly new to this
either ( even if ARM and PPC are little alike ... )

PS2: Sorry if it's a duplicate, I just had problems with my mail server
queue and don't know wich mail were 'lost'. After waiting 2h to see it
appear on the list and still nothing, I supposed the first one was lost.


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

Re: Linux 2.6 on MPC5200. Early problems + 2.4 questions

[Sylvain Munaut]

I've got some updates on my problem.

Apparently it's not blocking at the cache activation. I just thought so
because apparently the 0xf000000 address is not mapped with the
not-cacheable flag and so the stw I used to power up/down the led on the
gpio was just waiting in the cache ...

My questions currently are :
 - Apparently 0xf0000000 is mapped to somewhere ( the MBAR ) but I don't
see where it's done ... And how do I tell it that it's IO and should not
be cached. Apparently on 2.4 it works but I don't see where is the piece
of code that just does that ...
 - The MPC5200 has 8 BAT, so shouldn't the CPU_FTR_HAS_HIGH_BATS feature
flag be set in the cputable.c of the 2.4 ? And also cfr my post on the
dev list about the code that clears those BAT. I thinks the wrong
register is used in head.S



Sylvain Munaut

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

Re: Linux 2.6 on MPC5200. Early problems + 2.4 questions

[Gerhard Jaeger]

Hi,

On Friday 05 March 2004 18:01, Sylvain Munaut wrote:
[SNIPSNAP]
> My questions currently are :
>  - Apparently 0xf0000000 is mapped to somewhere ( the MBAR ) but I don't
> see where it's done ... And how do I tell it that it's IO and should not
> be cached. Apparently on 2.4 it works but I don't see where is the piece
> of code that just does that ...

checkout kernel/mpc5xxx_common.c

Ciao,
  Gerhard

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

Re: linuxppc_2_4_devel Memory map on PPC / MPC5200

[Sylvain Munaut]

Hi,

I've got more general question about the memory mapping on the MPC5200.


Gerhard Jaeger wrote:

>>My questions currently are :
>> - Apparently 0xf0000000 is mapped to somewhere ( the MBAR ) but I don't
>>see where it's done ... And how do I tell it that it's IO and should not
>>be cached. Apparently on 2.4 it works but I don't see where is the piece
>>of code that just does that ...
>>
>>
>
>checkout kernel/mpc5xxx_common.c
>
>
>
Thanks, I've seen this but that code is executed way later. I'm talking
about the mapping that exists at near the kernel entry point, in head.S.
Maybe it's just a residual mapping of U-Boot, I should check that.

But talking about this, I see in mpc5xxx_common


void __init
mpc5xxx_map_io(void)
{
        io_block_mapping(0x40000000, 0x40000000, 0x10000000, _PAGE_IO);
        io_block_mapping(0x50000000, 0x50000000, 0x01000000, _PAGE_IO);
        io_block_mapping(0x80000000, 0x80000000, 0x10000000, _PAGE_IO);
        io_block_mapping(0xf0000000, 0xf0000000, 0x10000000, _PAGE_IO);
}

I've read the relevant part of the MPC5200 manual and still don't
understand ...

0x80000000 is the default address of the MBAR. But AFAIK, MBAR is
changed by U-Boot to remap the registers to 0xf0000000 ( physical
address space, not remapped using the mmu ).
So I see the last line as a 1:1 mapping of the internal mpc5200
registers. And looking at all the consts, it seems correct.
But then, what are the 3 other mappings ?

Also, to be sure of what I understood. When the 0xf0000000 area is 1:1
mapped via the BAT, I suppose it's just to get serial debug during early
init and the map_io call. Because the BAT2 is gonna be overwritten when
the kernel maps all the physical memory. I'm not sure whether the call
to map_io occurs after or before that. I suppose it's after, else the
same mapping would exists in two different ways and that's discribed as
a bad situation in the user manual.

Finally ( I know, I have a lot of questions ), the kernel doesn't use
the HIGH_BATS features ? I mean there is 8 BAT on this processor and I
don' t see where the 5 6 7 8 are gonna be used ? io_block_mapping could
be slightly modified to use them as well or am I wrong ?


Thanks,

    Sylvain Munaut


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

Re: linuxppc_2_4_devel Memory map on PPC / MPC5200

[Wolfgang Denk]

In message <404C5E13.9000700@246tNt.com> you wrote:
>
> But talking about this, I see in mpc5xxx_common
...
>         io_block_mapping(0x40000000, 0x40000000, 0x10000000, _PAGE_IO);
>         io_block_mapping(0x50000000, 0x50000000, 0x01000000, _PAGE_IO);
>         io_block_mapping(0x80000000, 0x80000000, 0x10000000, _PAGE_IO);
>         io_block_mapping(0xf0000000, 0xf0000000, 0x10000000, _PAGE_IO);
> }
...
> But then, what are the 3 other mappings ?

See the U-Boot sources ("include/configs/IceCube.h").

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
How long does it take a  DEC  field  service  engineer  to  change  a
lightbulb?       It depends on how many bad ones he brought with him.

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

Re: linuxppc_2_4_devel Memory map on PPC / MPC5200

[Sylvain Munaut]

Hi

Wolfgang Denk wrote:

>In message <404C5E13.9000700@246tNt.com> you wrote:
>
>
>>But talking about this, I see in mpc5xxx_common
>>
>>
>...
>
>
>>        io_block_mapping(0x40000000, 0x40000000, 0x10000000, _PAGE_IO);
>>        io_block_mapping(0x50000000, 0x50000000, 0x01000000, _PAGE_IO);
>>        io_block_mapping(0x80000000, 0x80000000, 0x10000000, _PAGE_IO);
>>        io_block_mapping(0xf0000000, 0xf0000000, 0x10000000, _PAGE_IO);
>>}
>>
>>
>...
>
>
>>But then, what are the 3 other mappings ?
>>
>>
>
>See the U-Boot sources ("include/configs/IceCube.h").
>
>
I've just read the IceCube.h file as well as the mpc5xxx init code ( in
the cpu/mpc5xxx, board/icecube and some in lib_ppc ).

So yes, indeed U-Boot, does change the MBAR from it's boot default to
0xf000000 and setup the PCI Mem & IO space to 0x40000000 & 0x50000000.
Sorry I should have searched more in details what uboot does before asking.

What still surprises me is that it's mapped before the 0x80000000, so
isn't that inside the zone of per-process mapping ? ( < TASK_SIZE ).

As far as I understand it, Uboot does not use the mmu, it just ensure
that it's all clear ( tlb, bat, ... ). And I don't see anywhere what
could 0x8000000 be ? It's not the MBAR anymore. And I don't see anything
there anymore but still it can't be a map to nowhere ?


Thanks a lot.

    Sylvain Munaut

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

io space mapping and sync

[Kevin A. Sapp]

Hello,

I am using an 8275 and map memory.
When I map my LEDS physical 0x40000000 to 0x40000000
using a BAT I can hit them, several minutes into execution
during a sync, the system hangs.

I have tried to map this to a smaller region using the
mmu (io_block_mapping) but when I do the
region is no longer accessable.  THis is the
preferred method as I have a large region at
3000.0000 that I want to map using the remaining
BAT.

What should I do?  Any clues where to search for
an explaination of what is going on?


Thanks
Kevin


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