[U-Boot-Users] Linux stops at turn_on_mmu when jumping to start_here

[U-Boot-Users] Linux stops at turn_on_mmu when jumping to start_here

[Jose França (Ext_GTBC)]

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.

[U-Boot-Users] Linux stops at turn_on_mmu when jumping to start_here

[Jerry Van Baren]

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