Jose França (Ext_GTBC) wrote:

Hello!

I hope this subject isn't too much off-topic, but i'm stucked... I read the FAQ's and searched in the mailing-list history for an answer, but still i can't make it work and so i'm asking for your help. The situation is this... I am develloping the bootloader and kernel for a board based on mpc8247:

- u-boot is almost fully configured and running well
- bd_t on u-boot and on linux have the same definitions
- the platform header file that i created is based on rpx8260.h and i'm using m8260_setup to fill 			  ppc_md
- CPM_MAP_ADDR and CFG_IMMR have the same value

I don't have yet a debugger at hand, but from what i've discovered it stops in rfi instruction, when turning on MMU. Any suggestions would be most welcomed...

Many thanks for reading and many more if you respond :)! Filipe.

That is where the MMU gets turned on and is a very delicate place. If there is anything wrong with your memory map/MMU configuration, life stops here with pretty much no indication of what is wrong (a hardware debugger can be used to get some clues, but even that is difficult).

Since you are working without a hardware debugger, I would note that one common trap is to try to blink LEDs/toggle ports/transmit serial messages just after the IRET to get a progress report. Unfortunately, it generally causes a _lack_ of progress because the LED/port/serial is not part of the initial memory map and thus causes an address error, which _causes_ the total lock up.

If you are trying to get progress indications, make sure the resources (port) is accessable in your memory map _before_ you try to use the port. This means either delaying your progress indicator till after the MMU is initialized or using a BAT to map it (making sure nobody else uses that BAT or re-initializes that BAT). Many of the BATs are dedicated to the start up of the MMU so you have to be careful of what one you use for mapping your progress port.

gvb