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

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/

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/

Hi,

On Friday 05 March 2004 18:01, Sylvain Munaut wrote:
[SNIPSNAP]

checkout kernel/mpc5xxx_common.c

Ciao,
Gerhard

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

Hi,

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

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/

...

...

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

Hi

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/

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/