Uncompress Ok, but cannot run linux kernel...

Uncompress Ok, but cannot run linux kernel...

[machael thailer]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]

Hello:

    I have a 750-based custom board. I want to port linux-2.4.2 on it. The
bootrom code which initialized the hardware is working OK. I want to
download the linux kernel via TFTP(and it is OK now) and run it. But I met
some urgent problems ...
    I modified the bootloader codes according to arch/ppc/mbxboot/head.S and
other "printf" functions to suit my cases. And it runs like the following:

################################
Loading... 611056
Starting at 0x400000...

loaded at:     00400000 004952F0
zimage at:     004062C8 0048F994
avail ram:     004952F0 10000000

Linux/PPC load:
Uncompressing Linux...done.
Now booting the kernel
###################################

Then nothing happens(I have added a serial output code at the very begining
of arch/ppc/kernel/head.S and  have nothing output.). By printing the code
from 0x0 to 0x400000 I find the uncompressed code is right. After
uncompressing it jumps to 0x0(arch/ppc/mbxboot/head.S), but it cannot run .
Why?
Then I write a simple HelloWorld program  and compile it with -Ttext=0x0
compiling options, then use it to replace /usr/src/linux/vmlinux and
recompile the kernel.This time it works OK like the following:
################################
Loading... 4326
Starting at 0x400000...

loaded at:     ..........
zimage at:     ..........
avail ram:     ..........

Linux/PPC load:
Uncompressing Linux...done.
Now booting the kernel

Hello world
###################################

Here I attach my .config and arch/ppc/mbxboot/head.S. Hope you can help me
if you are free.

Thank you very much.

machael thailer



[-- Attachment #2: config --]
[-- Type: application/octet-stream, Size: 6857 bytes --]

#
# Automatically generated make config: don't edit
#
# CONFIG_UID16 is not set

#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
# CONFIG_KMOD is not set

#
# Platform support
#
CONFIG_PPC=y
CONFIG_6xx=y
# CONFIG_4xx is not set
# CONFIG_POWER3 is not set
# CONFIG_POWER4 is not set
# CONFIG_8xx is not set
# CONFIG_8260 is not set
CONFIG_ALL_PPC=y
# CONFIG_APUS is not set
# CONFIG_PPC601_SYNC_FIX is not set
# CONFIG_SMP is not set
# CONFIG_ALTIVEC is not set

#
# General setup
#
# CONFIG_HIGHMEM is not set
# CONFIG_MOL is not set
# CONFIG_ISA is not set
# CONFIG_EISA is not set
# CONFIG_SBUS is not set
# CONFIG_MCA is not set
CONFIG_PCI=y
CONFIG_NET=y
CONFIG_SYSCTL=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_KCORE_ELF=y
CONFIG_BINFMT_ELF=y
CONFIG_KERNEL_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_PCI_NAMES=y
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set
# CONFIG_PPC_RTC is not set
CONFIG_PROC_DEVICETREE=y
CONFIG_PPC_RTAS=y
# CONFIG_BOOTX_TEXT is not set
# CONFIG_PREP_RESIDUAL is not set
# CONFIG_CMDLINE_BOOL is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Plug and Play configuration
#
# CONFIG_PNP is not set

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_INITRD is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Networking options
#
# CONFIG_PACKET is not set
# CONFIG_NETLINK is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set

#
#  
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# ATA/IDE/MFM/RLL support
#
# CONFIG_IDE is not set
# CONFIG_BLK_DEV_IDE_MODES is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI support
#
# CONFIG_SCSI is not set

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_MACE is not set
# CONFIG_BMAC is not set
# CONFIG_GMAC is not set
# CONFIG_NCR885E is not set
# CONFIG_OAKNET is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_APRICOT is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_DGRS is not set
CONFIG_EEPRO100=y
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_HAMACHI is not set
# CONFIG_SK98LIN is not set
# CONFIG_FDDI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Console drivers
#
# CONFIG_VGA_CONSOLE is not set

#
# Frame-buffer support
#
# CONFIG_FB is not set

#
# Input core support
#
# CONFIG_INPUT is not set

#
# Macintosh device drivers
#
# CONFIG_ADB_CUDA is not set
# CONFIG_ADB_PMU is not set
# CONFIG_MAC_FLOPPY is not set
# CONFIG_MAC_SERIAL is not set
# CONFIG_ADB is not set

#
# Character devices
#
# CONFIG_VT is not set
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_UNIX98_PTYS is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_MOUSE is not set

#
# Joysticks
#

#
# Game port support
#

#
# Gameport joysticks
#

#
# Serial port support
#

#
# Serial port joysticks
#

#
# Parallel port joysticks
#

#
#   Parport support is needed for parallel port joysticks
#
# CONFIG_QIC02_TAPE is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_INTEL_RNG is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# File systems
#
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FAT_FS is not set
CONFIG_JFFS_FS_VERBOSE=0
# CONFIG_CRAMFS is not set
# CONFIG_RAMFS is not set
# CONFIG_ISO9660_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_CODA_FS is not set
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFSD is not set
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_SMB_NLS is not set
# CONFIG_NLS is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
# CONFIG_USB is not set

#
# Kernel hacking
#
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_KGDB is not set
# CONFIG_XMON is not set

[-- Attachment #3: head.S --]
[-- Type: application/octet-stream, Size: 6238 bytes --]

#include "../kernel/ppc_defs.h"
#include "../kernel/ppc_asm.tmpl"
#include <asm/processor.h>
#include <asm/cache.h>

	.text

/*
 * $Id: head_750.S,v 1.1 2001/04/27 01:27:32 gujianxin Exp $
 *	
 * Boot loader philosophy:
 *
 *      ROM loads us to some arbitrary location
 *      ROM loads these registers:
 *	
 *          R3 = Pointer to the board configuration data
 *          R5 = Pointer to Open Firmware data 	
 *		 	
 *      ROM jumps to start/start_
 *      Move the boot code to the link address (4 MB)
 *      Call decompress_kernel()
 *         Relocate the initrd, zimage and residual data to 4 MB
 *         Decompress the kernel to 0
 *      Jump to the kernel entry
 *            -- Cort
 */
	.globl	start
start:

	bl	start_
start_:

	li 	r3,0x0
	li 	r5,0x0

	mr	r11,r3		/* Save pointer to residual/board data */
	mr      r25,r5          /* Save OFW pointer */
	li	r3,MSR_IP	/* Establish default MSR value */
	mtmsr	r3

/* check if we need to relocate ourselves to the link addr or were we
   loaded there to begin with -- Cort */
	lis	r4,start@h
	ori	r4,r4,start@l
	mflr	r3
	subi	r3,r3,4		/* we get the nip, not the ip of the branch */
	mr	r8,r3
	cmp	0,r3,r4
	bne	1010f
/* compute size of whole image in words.  this should be moved to
 * start_ldr() -- Cort
 */
	lis	r4,start@h
	ori	r4,r4,start@l
	lis	r5,end@h
	ori	r5,r5,end@l
	addi	r5,r5,3		/* round up */
	sub	r5,r5,r4
	srwi	r5,r5,2
	mr	r7,r5
	b	start_ldr
1010:
/* 
 * no matter where we're loaded, move ourselves to -Ttext address
 */
relocate:
	mflr	r3		/* Compute code bias */
	subi	r3,r3,4
	mr	r8,r3
	lis	r4,start@h
	ori	r4,r4,start@l
	lis	r5,end@h
	ori	r5,r5,end@l
	addi	r5,r5,3			/* Round up - just in case */
	sub	r5,r5,r4		/* Compute # longwords to move */
	srwi	r5,r5,2
	mtctr	r5
	mr	r7,r5
	li	r6,0
	subi	r3,r3,4			/* Set up for loop */
	subi	r4,r4,4
00:	lwzu	r5,4(r3)
	stwu	r5,4(r4)
	xor	r6,r6,r5
	bdnz	00b
  	lis	r3,start_ldr@h
	ori	r3,r3,start_ldr@l
	mtlr	r3			/* Easiest way to do an absolute jump */
	blr
start_ldr:
/* Clear all of BSS */
	lis	r3,edata@h
	ori	r3,r3,edata@l
	lis	r4,end@h
	ori	r4,r4,end@l
	subi	r3,r3,4
	subi	r4,r4,4
	li	r0,0
50:	stwu	r0,4(r3)
	cmp	0,r3,r4
	bne	50b
90:	mr	r9,r1			/* Save old stack pointer (in case it matters) */
	lis	r1,.stack@h
	ori	r1,r1,.stack@l
	addi	r1,r1,4096*2
	subi	r1,r1,256
	li	r2,0x000F		/* Mask pointer to 16-byte boundary */
	andc	r1,r1,r2

	/* Speed us up a little.
	*/
	bl	flush_instruction_cache

/* Run loader */
	mr	r3,r8			/* Load point */
	mr	r4,r7			/* Program length */
	mr	r5,r6			/* Checksum */
	mr	r6,r11			/* Residual data */
	mr      r7,r25                  /* OFW interfaces */
	bl	decompress_kernel

	
	
	/* changed to use r3 (as firmware does) for kernel
	   as ptr to residual -- Cort*/
	lis	r6,cmd_line@h
	ori	r6,r6,cmd_line@l
	lwz	r6, 0(r6)
	subi	r7,r6,1
00:	lbzu	r2,1(r7)
	cmpi	0,r2,0
	bne	00b

	/* r4,r5 have initrd_start, size */
	lis	r2,initrd_start@h
	ori	r2,r2,initrd_start@l
	lwz	r4,0(r2)
	lis	r2,initrd_end@h
	ori	r2,r2,initrd_end@l
	lwz	r5,0(r2)
	
	/* tell kernel we're prep */
	/* 
	 * get start address of kernel code which is stored as a coff
	 * entry.  see boot/head.S -- Cort 
	 */
	li	r9,0x4
	mtlr	r9
	lis	r10,0xdeadc0de@h
	ori	r10,r10,0xdeadc0de@l
	li	r9,0
	stw	r10,0(r9)


#if 1	 
/*
 * The Radstone firmware maps PCI memory at 0xc0000000 using BAT2
 * so disable BATs before setting this to avoid a clash
 */
	li      r8,0
	mtspr   DBAT0U,r8
	isync
	mtspr   DBAT0L,r8
	isync
	mtspr   DBAT1U,r8
	isync
	mtspr   DBAT1L,r8
	isync
	mtspr   DBAT2U,r8
	isync
	mtspr   DBAT2L,r8
	isync
	mtspr   DBAT3U,r8
	isync
	mtspr   DBAT3L,r8
	isync
	mtspr   IBAT0U,r8
	isync
	mtspr   IBAT0L,r8
	isync
	mtspr   IBAT1U,r8
	isync
	mtspr   IBAT1L,r8
	isync
	mtspr   IBAT2U,r8
	isync
	mtspr   IBAT2L,r8
	isync
	mtspr   IBAT3U,r8
	isync
	mtspr   IBAT3L,r8
	isync

    xor	    r0,r0,r0		
    mfspr   r8,HID0
    sync
    addi    r9,r0,0x0800
    or      r8,r9,r8
    mtspr   HID0,r8         /* set ICFI (bit 20) */
    sync

    andc    r8,r8,r9
    mtspr   HID0,r8         /* clear ICFI (bit 20) */
    sync

    addi    r9,r0,0x2000    /* Clear ILOCK (bit 18) (instr sign extends) */
    andc     r8,r8,r9 
    mtspr   HID0,r8
    sync

    addi    r9,r0,0x7fff   
    and     r8,r8,r9    /* CLear ICE (bit 16) */
    mtspr   HID0,r8
    sync
#endif    


	blr
hang:
	b	hang	

/*
 * Delay for a number of microseconds
 * -- Use the BUS timer (assumes 66MHz)
 */
	.globl	udelay
udelay:		
	mfspr	r4,PVR
	srwi	r4,r4,16
	cmpi	0,r4,1		/* 601 ? */
	bne	.udelay_not_601
00:	li	r0,86	/* Instructions / microsecond? */
	mtctr	r0
10:	addi	r0,r0,0 /* NOP */
	bdnz	10b
	subic.	r3,r3,1
	bne	00b
	blr

.udelay_not_601:		
	mulli	r4,r3,1000	/* nanoseconds */
	addi	r4,r4,59
	li	r5,60
	divw	r4,r4,r5	/* BUS ticks */
1:	mftbu	r5
	mftb	r6
	mftbu	r7
	cmp	0,r5,r7
	bne	1b		/* Get [synced] base time */
	addc	r9,r6,r4	/* Compute end time */
	addze	r8,r5
2:	mftbu	r5
	cmp	0,r5,r8
	blt	2b
	bgt	3f
	mftb	r6
	cmp	0,r6,r9
	blt	2b
3:	blr		

.globl _get_HID0
_get_HID0:		
	mfspr	r3,HID0
	blr

.globl _put_HID0
_put_HID0:		
	mtspr	HID0,r3
	blr
		
.globl _get_MSR
_get_MSR:		
	mfmsr	r3
	blr
	
.globl _put_MSR
_put_MSR:		
	mtmsr	r3
	blr

/*
 * Flush instruction cache
 * *** I'm really paranoid here!
 */
_GLOBAL(flush_instruction_cache)
	mflr	r5
	bl	flush_data_cache
	mfspr	r3,HID0	/* Caches are controlled by this register */
	li	r4,0
	ori	r4,r4,(HID0_ICE|HID0_ICFI)
	or	r3,r3,r4	/* Need to enable+invalidate to clear */
	mtspr	HID0,r3
	andc	r3,r3,r4
	ori	r3,r3,HID0_ICE	/* Enable cache */
	mtspr	HID0,r3
	mtlr	r5
	blr
	
#define NUM_CACHE_LINES 128*8
#define CACHE_LINE_SIZE 32 
#define cache_flush_buffer 0x1000

/*
 * Flush data cache
 * *** I'm really paranoid here!
 */
_GLOBAL(flush_data_cache)
	lis	r3,cache_flush_buffer@h
	ori	r3,r3,cache_flush_buffer@l
	li	r4,NUM_CACHE_LINES
	mtctr	r4
00:	lwz	r4,0(r3)
	addi	r3,r3,CACHE_LINE_SIZE	/* Next line, please */
	bdnz	00b	
10:	blr
	.comm	.stack,4096*2,4

Re: Uncompress Ok, but cannot run linux kernel...

[Dan Malek]

machael thailer wrote:
> ..... But I met
> some urgent problems ...
>     I modified the bootloader codes according to arch/ppc/mbxboot/head.S

For starters, you shouldn't be using this "boot loader" for a 750.....
How did you configure a kernel to get there in the first place?
A 750 should be a CHRP (or PReP, if you have to.....), which will
direct you to a working "chrpboot" boot loader.


	-- Dan

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

Re: Uncompress Ok, but cannot run linux kernel...

[Michael Habermann]

At 09:01 AM 5/6/2001 +0800, machael thailer wrote:


>     I have a 750-based custom board. I want to port linux-2.4.2 on it. The
>bootrom code which initialized the hardware is working OK. I want to
>download the linux kernel via TFTP(and it is OK now) and run it. But I met
>some urgent problems ...

I have the same problem on an FADS board. Tracing head.S showed me that the
code returns with
a return from interrupt instead of a branch. So it maybe works if the image
is used without bootloader or by changing head.S.

I'll test it today, please let me know if you've found the problem.


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

Re: Uncompress Ok, but cannot run linux kernel...

[Dan Malek]

Michael Habermann wrote:

> I have the same problem on an FADS board.

What "same" problem?  How are you loading and tracing the kernel?

> ......... So it maybe works if the image
> is used without bootloader or by changing head.S.

The image certainly won't work without any bootloader, whether it
is PPCBoot or the code found in arch/ppc/mbx (or arch/ppc/boot/mbx
depending on your source base).  The kernel requires a bunch of
registers and information set up before it is called, and one of
those two methods must be used to ensure this happens.

I believe there is a working FADS port in the FSM Labs BitKeeper
sources.  If not, you can download the older 2.4.0-test2 LSP from
MontaVista and use it as a guide for updating a later kernel.  The
changes are very minor.


	-- Dan

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

Re: Uncompress Ok, but cannot run linux kernel...

[machael thailer]

>
> machael thailer wrote:
> > ..... But I met
> > some urgent problems ...
> >     I modified the bootloader codes according to arch/ppc/mbxboot/head.S
>
> For starters, you shouldn't be using this "boot loader" for a 750.....
> How did you configure a kernel to get there in the first place?
> A 750 should be a CHRP (or PReP, if you have to.....), which will
> direct you to a working "chrpboot" boot loader.

Yes, I choose "6xx/7xx/74xx/8260" and "/PowerMac/PRep/MTX/CHRP" when
configuring the kernel.
Now I find that something is wrong with my serial output codes. When I fix
it , I can trace into arch/ppc/kernel/head.S now.
But it hangs after running "turn_on_mmu". That is to say, it should be able
to run "start_here" (but it cannot .)
By the way , I find that "initial_bats" do 2 different branches according to
whether PVR is 601 or 604. I don't know which branch will 750 do?

Thank you very much.

machael


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

Re: Uncompress Ok, but cannot run linux kernel...

[Michael Habermann]

At 09:16 PM 5/7/2001 -0400, Dan Malek wrote:

> > I have the same problem on an FADS board.
>
>What "same" problem?  How are you loading and tracing the kernel?

The same problem is that the kernel doesn't survive until the welcome
messge is printed.
The kernel is loaded with ppcboot and the tftpboot commando. To trace, I
used mpc8bug.

I use the Montavista linux-2.4.0-test2-1.2.0-1 kernel.
I set a breakpoint at the entry of the __start routine. After passing
the turn_on_mmu label, it returns with an rfi and hangs.
It is maybe ment to be started from a power_on interrupt, because in
this context, I don't see the sense for an rfi. But I don't know much details.


I believe there is a working FADS port in the FSM Labs BitKeeper
>sources.  If not, you can download the older 2.4.0-test2 LSP from
>MontaVista and use it as a guide for updating a later kernel.  The
>changes are very minor.

The Montavista is the one I used. I also tried one from Bitkeeper, but I
didn't found support
for the FADS board. Even when I compiled for MBX, I got no image in
arch/ppc/coffboot.
Which is the machine type I should configure for a MPC860FADS?

It would be nice if you could help me. So far I couldn't start any kernel.


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

Re: Uncompress Ok, but cannot run linux kernel...

[machael thailer]

>
> At 09:16 PM 5/7/2001 -0400, Dan Malek wrote:
>
> > > I have the same problem on an FADS board.
> >
> >What "same" problem?  How are you loading and tracing the kernel?
>
> The same problem is that the kernel doesn't survive until the welcome
> messge is printed.
> The kernel is loaded with ppcboot and the tftpboot commando. To trace, I
> used mpc8bug.
>
> I use the Montavista linux-2.4.0-test2-1.2.0-1 kernel.
> I set a breakpoint at the entry of the __start routine. After passing
> the turn_on_mmu label, it returns with an rfi and hangs.

This is exactly what I meet now.
If you have good solutions, please let me know.

Thank you very much.

machael


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

Re: Uncompress Ok, but cannot run linux kernel...

[Wolfgang Denk]

In message <000b01c0d795$c3e15f80$8021690a@huawei.com> you wrote:
>
> > The kernel is loaded with ppcboot and the tftpboot commando. To trace, I
> > used mpc8bug.
...
> > I set a breakpoint at the entry of the __start routine. After passing
> > the turn_on_mmu label, it returns with an rfi and hangs.
>
> This is exactly what I meet now.
> If you have good solutions, please let me know.

Use a debugger that understands the MMU, like the BDI2000 by Abatron.

In any case, make sure the DER does not trap into BDM mode on  normal
MMU work, i. e. set it to something like 0x2002000F.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"I didn't know it was impossible when I did it."

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

Re: Uncompress Ok, but cannot run linux kernel...

[machael thailer]

>
> In message <000b01c0d795$c3e15f80$8021690a@huawei.com> you wrote:
> >
> > > The kernel is loaded with ppcboot and the tftpboot commando. To trace,
I
> > > used mpc8bug.
> ...
> > > I set a breakpoint at the entry of the __start routine. After passing
> > > the turn_on_mmu label, it returns with an rfi and hangs.
> >
> > This is exactly what I meet now.
> > If you have good solutions, please let me know.
>
> Use a debugger that understands the MMU, like the BDI2000 by Abatron.
>
> In any case, make sure the DER does not trap into BDM mode on  normal
> MMU work, i. e. set it to something like 0x2002000F.
>

My board use Powerpc 750. Does 750 has DER?

machael


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

RE: Uncompress Ok, but cannot run linux kernel...

[Zehetbauer Thomas]

I stumbled into the same problem a while ago.

While I did not use a hardware debugger I used the sample demonstrating
serial output to find that the Montavista kernel stops at the rfi
instruction which is used to simultanoeusly turn on instruction and data
address translation and to set the instruction pointer to the (remapped)
start_here label. Unfortunately I lost my PPC hardware (405GP Walnut
board) before I could find any solution.

Regards
Tom

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

Re: Uncompress Ok, but cannot run linux kernel...

[machael thailer]

>
> I stumbled into the same problem a while ago.
>
> While I did not use a hardware debugger I used the sample demonstrating
> serial output to find that the Montavista kernel stops at the rfi
> instruction which is used to simultanoeusly turn on instruction and data
> address translation and to set the instruction pointer to the (remapped)
> start_here label. Unfortunately I lost my PPC hardware (405GP Walnut
> board) before I could find any solution.

Yes, this is also exactly what i meet now.
I find that "turn_on_mmu" use SYNC as following:
turn_on_mmu:
    .....
    SYNC
    RFI

here SYNC may do nothing according to your .config(CONFIG_PPC601_SYNC_FIX)
if you look into arch/ppc/kernel/ppc_asm.h.
Will this be a problem? I use linux-2.4.2 .

machael


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

Re: Uncompress Ok, but cannot run linux kernel...

[Freddy Lugo]

> turn_on_mmu:
>     .....
>     SYNC
>     RFI


I am dealing with same problem.  After the rfi (on
turn_on_mmu) instruction an signal is generated and
the progam counter is lost.  When performing an rfi
most of the bits of the SRR1 registers become the MSR
bits and the SRR0 register become the next instruction
pointer (NIA).  I read the manual and if the new MSR
value enables some pending exceptions then this
exceptions are processed by exception priority.  The
bits modified after the rfi are MSR_IR & MSR_DR so I
think (I am not sure yet) this bits enables a waiting
exception of some kind and when the rfi is processed
the exception is executed.  gdb only said it recevies
a SIGSTOP signal.  I will be working with that today.
If I found anything I will let you know.

Thanks

Freddy Lugo


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

Re: Uncompress Ok, but cannot run linux kernel...

[Wolfgang Denk]

In message <20010508135003.34130.qmail@web9906.mail.yahoo.com> you wrote:
>
> I am dealing with same problem.  After the rfi (on
> turn_on_mmu) instruction an signal is generated and
> the progam counter is lost.  When performing an rfi
...
> the exception is executed.  gdb only said it recevies
> a SIGSTOP signal.  I will be working with that today.

What exectly are you trying to do?

Single-stepping over an RFI instruction? I  don't  think  you'll  get
this working.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Gods don't like people not doing much work. People  who  aren't  busy
all the time might start to _think_.  - Terry Pratchett, _Small Gods_

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

Re: Uncompress Ok, but cannot run linux kernel...

[Freddy Lugo]

--- Wolfgang Denk <wd@denx.de> wrote:
> Single-stepping over an RFI instruction? I  don't
> think  you'll  get
> this working.

thanks, I discovered that the 'hard' way!.

However I found the problem but I don't have any clue
what is happenning.  On the start_here after
turn_on_mmu there are some memory access instructions:

start_here:
....
c000361c addi r11,r11,_endl@l
c0003620 lis r8, __bss_start@h
c0003624 addi r8,r8,__bss_start@l
c0003628 subf r11,r8,r11
....
c0003644 stwu r0,4(r8)

the problem is that for some reason the when the
c000361c instruction is executed the program counter
jumps to the c0003644 instruction.  R8 don't have the
value it should be and the current value is way out of
the 16MB declare initialy on initial_bats.
This cause an SIGSTOP signal cause the MMU can't
translate the address requested.  I think this should
be a debuging or compiler issue cause I don't have any
explanation about what is happenning.

I repeated the procedure several times and it is not
on the same instruction but is the same cause, and in
the same procedure (start_here).  Previous
instructions were not executed, and a memory access is
tried with anunexpected value on the register.

Any suggestions?

Debugging Environment:
BDI2000 -> gdb 5.0
MPC750 (6xx,7xx,7400) using a PReP Type

Thanks,

Freddy Lugo


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

Re: Uncompress Ok, but cannot run linux kernel...

[machael thailer]

> machael thailer wrote:
> > ..... But I met
> > some urgent problems ...
> >     I modified the bootloader codes according to arch/ppc/mbxboot/head.S
>
> For starters, you shouldn't be using this "boot loader" for a 750.....
> How did you configure a kernel to get there in the first place?
> A 750 should be a CHRP (or PReP, if you have to.....), which will
> direct you to a working "chrpboot" boot loader.

If I use  "chrpboot " bootloader, I have to provide many functions in my
boot codes according to CHRP specifications:

1  "prom"(promptr) functions which can provide with "/chosen" ,"claim" and
"getprop" services etc in arch/ppc/chrpboot/start.c and in
arch/ppc/kernel/prom.c .
2  device-trees for my custom board.

Are these functions all necessary for booting the linux kernel?


And do I have to  modify arch/ppc/mm/init.c=>MMU_init() and
arch/ppc/kernel/setup.c=>identify_machines() to suit my cases?
I notice that in identify_machines(), there are many types initializations
functions such as pmac_init(),prep_init(),chrp_init(),apus_init(),
oak_init(),m8xx_init(),m8260_init(). Do I have to provide my own ***_init()
functions?


Thank you  very much.

machael


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

Re: Uncompress Ok, but cannot run linux kernel...

[machael thailer]

> turn_on_mmu:
>     .....
>     SYNC
>     RFI


>I am dealing with same problem.  After the rfi (on
>turn_on_mmu) instruction an signal is generated and
>the progam counter is lost.  When performing an rfi
>most of the bits of the SRR1 registers become the MSR
>bits and the SRR0 register become the next instruction
>pointer (NIA).  I read the manual and if the new MSR
>value enables some pending exceptions then this
>exceptions are processed by exception priority.  The
>bits modified after the rfi are MSR_IR & MSR_DR so I
>think (I am not sure yet) this bits enables a waiting
>exception of some kind and when the rfi is processed
>the exception is executed.  gdb only said it recevies
>a SIGSTOP signal.  I will be working with that today.
>If I found anything I will let you know.

Now I can "turn_on_mmu" and run "start_here" . I make a mistake when I try
to debug by outputing a character vi SERIAL Port after "turn_on_mmu".
The serial port IO is 0xfe0003f8, and the "initial_bats" only do the
physical address 0~256M to virtual address 0xc0000000~0xc0000000+256M
memory-mapping. To make the serial port output work, we have to do
additional memory-mapping from physical address 0xf000000-0xffffffff to
virtual address 0xf0000000~0xffffffff as following:

initial_bats:
        ......
        ......
       mtspr DBAT0L,r8
        mtspr DBAT0U,r11
        mtspr IBAT0L,r8
        mtspr IBAT0U,r11

/*the start added  lines  */
        lis r9,0xf000
        ori    r9,r9,0x1ffe
        lis r8,0xf000
        ori r8,r8,0x2a
        mtspr DBAT1L,r8
        mtspr DBAT1U,r9
/*the end added lines*/

        isync
        blr

Now I meet a new problem. I can run through here:
start_here:
...
bl identify_machine
bl MMU_init
lis r4,2f@h
 ori r4,r4,2f@l
 tophys(r4,r4)
 li r3,MSR_KERNEL & ~(MSR_IR|MSR_DR)
 FIX_SRR1(r3,r5)
 mtspr SRR0,r4
 mtspr SRR1,r3
 SYNC
 RFI

  /*Here I add my serial output codes, but it outputs nothing. System seems
to halt here?*/

2:
  sync
  tlbia
  sync

Do you have any ideas?
thank you very much.


machael thailer


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

Re: Uncompress Ok, but cannot run linux kernel...

[Paul White]

Michael,

Please see comments below..

On Thu, 10 May 2001, machael thailer wrote:

>
> > turn_on_mmu:
> >     .....
> >     SYNC
> >     RFI
>
>
> >I am dealing with same problem.  After the rfi (on
> >turn_on_mmu) instruction an signal is generated and
> >the progam counter is lost.  When performing an rfi
> >most of the bits of the SRR1 registers become the MSR
> >bits and the SRR0 register become the next instruction
> >pointer (NIA).  I read the manual and if the new MSR
> >value enables some pending exceptions then this
> >exceptions are processed by exception priority.  The
> >bits modified after the rfi are MSR_IR & MSR_DR so I
> >think (I am not sure yet) this bits enables a waiting
> >exception of some kind and when the rfi is processed
> >the exception is executed.  gdb only said it recevies
> >a SIGSTOP signal.  I will be working with that today.
> >If I found anything I will let you know.
>
> Now I can "turn_on_mmu" and run "start_here" . I make a mistake when I try
> to debug by outputing a character vi SERIAL Port after "turn_on_mmu".
> The serial port IO is 0xfe0003f8, and the "initial_bats" only do the
> physical address 0~256M to virtual address 0xc0000000~0xc0000000+256M
> memory-mapping. To make the serial port output work, we have to do
> additional memory-mapping from physical address 0xf000000-0xffffffff to
> virtual address 0xf0000000~0xffffffff as following:
>
> initial_bats:
>         ......
>         ......
>        mtspr DBAT0L,r8
>         mtspr DBAT0U,r11
>         mtspr IBAT0L,r8
>         mtspr IBAT0U,r11
>
> /*the start added  lines  */
>         lis r9,0xf000
>         ori    r9,r9,0x1ffe
>         lis r8,0xf000
>         ori r8,r8,0x2a
>         mtspr DBAT1L,r8
>         mtspr DBAT1U,r9
> /*the end added lines*/
>
>         isync
>         blr
>
> Now I meet a new problem. I can run through here:
> start_here:
> ...
> bl identify_machine
> bl MMU_init
> lis r4,2f@h
>  ori r4,r4,2f@l
>  tophys(r4,r4)
>  li r3,MSR_KERNEL & ~(MSR_IR|MSR_DR)
>  FIX_SRR1(r3,r5)
>  mtspr SRR0,r4
>  mtspr SRR1,r3
>  SYNC
>  RFI
>
>   /*Here I add my serial output codes, but it outputs nothing. System seems
> to halt here?*/
>
> 2:
>   sync
>   tlbia
>   sync
>
> Do you have any ideas?
> thank you very much.

Note that it is loading the "physical" address of the "2:" label into r4.  What its doing, is its
telling the CPU to turn off MMU (BAT mapping) and then jumping to the "2:" label.  If you add your
serial output after the "2:" label, it should work again.

The next stage would be to make sure MMU_init() in arch/ppc/mm/init.c will set up the right BATs
you need as well (f0000000-0xffffffff), As after all hash tables are modified and such, it will
then write out the new BATs saved in the "BATS" variable from MMU_init(), and then will jump
to start_kernel() after turning MMU on for the last time.

Hope this helps...

Paul W.


>
>
> machael thailer
>
>
>


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

Re: Uncompress Ok, but cannot run linux kernel...

[Matt Porter]

On Thu, May 10, 2001 at 11:08:21AM +0800, machael thailer wrote:
>
> > machael thailer wrote:
> > > ..... But I met
> > > some urgent problems ...
> > >     I modified the bootloader codes according to arch/ppc/mbxboot/head.S
> >
> > For starters, you shouldn't be using this "boot loader" for a 750.....
> > How did you configure a kernel to get there in the first place?
> > A 750 should be a CHRP (or PReP, if you have to.....), which will
> > direct you to a working "chrpboot" boot loader.
>
> If I use  "chrpboot " bootloader, I have to provide many functions in my
> boot codes according to CHRP specifications:
>
> 1  "prom"(promptr) functions which can provide with "/chosen" ,"claim" and
> "getprop" services etc in arch/ppc/chrpboot/start.c and in
> arch/ppc/kernel/prom.c .
> 2  device-trees for my custom board.
>
> Are these functions all necessary for booting the linux kernel?

You're doing this all wrong.  There have been a bunch of good examples
of ports to non-CHRP/PReP/Pmac 6xx/7xx/74xx hardware in the linuxppc_2_5
tree for a while now.  Most of them have just been moved into the
new linuxppc_2_4_devel tree.  See the K2, MVME5100, MCPN765, PCore,
PrPMC750, F1, etc. ports for details on how to quickly and easily do
a port to a custom board.

> And do I have to  modify arch/ppc/mm/init.c=>MMU_init() and
> arch/ppc/kernel/setup.c=>identify_machines() to suit my cases?
> I notice that in identify_machines(), there are many types initializations
> functions such as pmac_init(),prep_init(),chrp_init(),apus_init(),
> oak_init(),m8xx_init(),m8260_init(). Do I have to provide my own ***_init()
> functions?

Yes.

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

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