Problem with starting up 2.4.21 kernel

Problem with starting up 2.4.21 kernel

[Dmytro Bablinyuk]

After "Transferring control to Linux (at address 00000000)" nothing seems happen (see below). From BDI2000 I discovered that it shorlty after locks at 0xc0092aec address (the MPC866ADS eval board used).
I tried to turn on the kernel hacking options and turn off everything I don't need right now but it does not help a lot.
Could anybody give me a clue what this could be about.

Thank you in advance for any help.

### main_loop: bootcmd="bootm 0x2880000 0x2900000; setenv bootargs root=/dev/ram rw"
Hit any key to stop autoboot:  0
## Booting image at 02880000 ...
   Image Name:   Linux-2.4.21-erik
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    489849 Bytes = 478.4 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Current stack ends at 0x0075BBE8 => set upper limit to 0x0075B3E0
## cmdline at 0x0075B2E0 ... 0x0075B2F0
bd address  = 0x0075BFC4
memstart    = 0x00000000
memsize     = 0x00800000
flashstart  = 0x02800000
flashsize   = 0x00200000
flashoffset = 0x00025000
sramstart   = 0x00000000
sramsize    = 0x00000000
immr_base   = 0x02200000
bootflags   = 0x00000001
intfreq     =     50 MHz
busfreq     =     50 MHz
ethaddr     = 00:24:20:10:18:6A
IP addr     = 172.25.193.23
baudrate    =  19200 bps
## Loading RAMDisk Image at 02900000 ...
   Image Name:   Simple Ramdisk Image
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    859578 Bytes = 839.4 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## initrd at 0x02900040 ... 0x029D1DF9 (len=859578=0xD1DBA)
   Loading Ramdisk to 00689000, end 0075adba ... OK
## Transferring control to Linux (at address 00000000) ...


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

Re: Problem with starting up 2.4.21 kernel

[None Atall]

 There are mainly two things that you sould check:

1. Have you configured correctly the timers? It
depends
from your configuration, but ppcboot could pass to the
kernel the clocks in Mhz, although kernel could need
it in Hertz.(I dont remember exactly who needs what,
but I hope you understand that the mapping sould
be the same..)(Well, I always had to change that
inside the kernel..??...)

2. Have you correctly configured the serial interface
(where you have your console)? SCC,SMC..etc.

And, could you see inside the System.map in what
function does your kernel locks?

                 Dimitris.

--- Dmytro Bablinyuk <dmytro.bablinyuk@tait.co.nz>
wrote:
>
> After "Transferring control to Linux (at address
> 00000000)" nothing seems happen (see below). From
> BDI2000 I discovered that it shorlty after locks at
> 0xc0092aec address (the MPC866ADS eval board used).
> I tried to turn on the kernel hacking options and
> turn off everything I don't need right now but it
> does not help a lot.
> Could anybody give me a clue what this could be
> about.
>
> Thank you in advance for any help.
>
> ### main_loop: bootcmd="bootm 0x2880000 0x2900000;
> setenv bootargs root=/dev/ram rw"
> Hit any key to stop autoboot:  0
> ## Booting image at 02880000 ...
>    Image Name:   Linux-2.4.21-erik
>    Image Type:   PowerPC Linux Kernel Image (gzip
> compressed)
>    Data Size:    489849 Bytes = 478.4 kB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
>    Uncompressing Kernel Image ... OK
> ## Current stack ends at 0x0075BBE8 => set upper
> limit to 0x0075B3E0
> ## cmdline at 0x0075B2E0 ... 0x0075B2F0
> bd address  = 0x0075BFC4
> memstart    = 0x00000000
> memsize     = 0x00800000
> flashstart  = 0x02800000
> flashsize   = 0x00200000
> flashoffset = 0x00025000
> sramstart   = 0x00000000
> sramsize    = 0x00000000
> immr_base   = 0x02200000
> bootflags   = 0x00000001
> intfreq     =     50 MHz
> busfreq     =     50 MHz
> ethaddr     = 00:24:20:10:18:6A
> IP addr     = 172.25.193.23
> baudrate    =  19200 bps
> ## Loading RAMDisk Image at 02900000 ...
>    Image Name:   Simple Ramdisk Image
>    Image Type:   PowerPC Linux RAMDisk Image (gzip
> compressed)
>    Data Size:    859578 Bytes = 839.4 kB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
> ## initrd at 0x02900040 ... 0x029D1DF9
> (len=859578=0xD1DBA)
>    Loading Ramdisk to 00689000, end 0075adba ... OK
> ## Transferring control to Linux (at address
> 00000000) ...
>
>
>


=====
------------------------------------------------------------
-Dhmhtrios Meidanis
-Degree in Mathematics, University of the Aegean.
-Master in Computer Architecture and Digital
 Systems, University of Crete.
 Greece.
------------------------------------------------------------


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

Re: Problem with starting up 2.4.21 kernel

[Dmytro Bablinyuk]

>  1. Have you configured correctly the timers?

I tried to pass in Hz and in MHz by playing with clocks_in_mhz
environment variable

> 2. Have you correctly configured the serial interface
> (where you have your console)? SCC,SMC..etc.

I could not find in my .config where I can define a SMC1 to use for UART
but I have:
#
# MPC8xx CPM Options
#
# CONFIG_SCC_ENET is not set
CONFIG_FEC_ENET=y
# CONFIG_USE_MDIO is not set
CONFIG_ENET_BIG_BUFFERS=y
# CONFIG_SMC2_UART is not set
# CONFIG_USE_SCC_IO is not set
CONFIG_8xx_COPYBACK=y
CONFIG_8xx_CPU6=y
CONFIG_UCODE_PATCH=y

> And, could you see inside the System.map in what
> function does your kernel locks?

It's a m8xx_cpm_reset function.


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

Re: Problem with starting up 2.4.21 kernel

[Dean Matsen]

Dmytro Bablinyuk wrote:

>
> sramsize = 0x00000000
> immr_base = 0x02200000
> bootflags = 0x00000001
>
Just a sanity check, but that immr_base sounds pretty low to me... we
always use 0xFxxx0000.
This is not necessarily wrong, but make sure this is what you want. In
fact, I think I read
in a comment somewhere that in some cases it MUST match the value of
your boot loader.

Dean


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

Re: Problem with starting up 2.4.21 kernel

[None Atall]

 Yes, Dean is right!
And since are you stuck at the cpm_reset function,
this could probably be the answer!

                  Cheers
                   Dimitris.

--- Dean Matsen <deanm@earthlink.net> wrote:
>
> Dmytro Bablinyuk wrote:
>
> >
> > sramsize = 0x00000000
> > immr_base = 0x02200000
> > bootflags = 0x00000001
> >
> Just a sanity check, but that immr_base sounds
> pretty low to me... we
> always use 0xFxxx0000.
> This is not necessarily wrong, but make sure this is
> what you want. In
> fact, I think I read
> in a comment somewhere that in some cases it MUST
> match the value of
> your boot loader.
>
> Dean
>
>
>


=====
------------------------------------------------------------
-Dhmhtrios Meidanis
-Degree in Mathematics, University of the Aegean.
-Master in Computer Architecture and Digital
 Systems, University of Crete.
 Greece.
------------------------------------------------------------


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

Re: Problem with starting up 2.4.21 kernel

[Sung]

Hi there,

Hav you solve this problem?? Can I know what wrong with it because my
kernel also acting up the same about the samething.


On Wed, 2003-07-09 at 12:51, Dmytro Bablinyuk wrote:
>
> After "Transferring control to Linux (at address 00000000)" nothing seems happen (see below). From BDI2000 I discovered that it shorlty after locks at 0xc0092aec address (the MPC866ADS eval board used).
> I tried to turn on the kernel hacking options and turn off everything I don't need right now but it does not help a lot.
> Could anybody give me a clue what this could be about.
>
> Thank you in advance for any help.

Thanks,

mike


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

Re: Problem with starting up 2.4.21 kernel

[Dmytro Bablinyuk]

>
>
>Hav you solve this problem?? Can I know what wrong with it because my
>kernel also acting up the same about the samething.
>
Yes, we resolved this problem.
First of all there was problem with ramdisk - it should have a header.
We used this makefile to generate proper ramdisk.

initrd.mk:

STAGING_DIR=.
TARGET_DIR=root

#############################################################
#
# make an initrd image - assumes all the tools are available
#
#############################################################

# this comes from the u-boot project!!
MKIMAGE=/usr/bin/mkimage
MNTPOINT:=$(STAGING_DIR)/mnt

$(MNTPOINT):
    mkdir -p $(MNTPOINT)


#############################################################
#
# Build the ramfs root filesystem image
#
#############################################################



ramdisk.image.gz: $(TARGET_DIR) $(MNTPOINT)
    dd if=/dev/zero of=ramdisk.img bs=1024 count=2048
    /sbin/mkfs.ext2 -N 500 ramdisk.img -F
    sudo mount -o loop ramdisk.img $(MNTPOINT)
    cp -R $(TARGET_DIR)/* $(MNTPOINT)
    sudo umount $(MNTPOINT)
    cat ramdisk.img | gzip -9 -c > ramdisk.image.gz
    rm -f ramdisk.img

initrd:    ramdisk.image.gz
    $(MKIMAGE) -n 'Simple Ramdisk Image' \
     -A ppc -O linux -T ramdisk -C gzip \
     -d ramdisk.image.gz initrd
     rm -f ramdisk.image.gz

Call it "make -f initrd.mk initrd"

You should get a initrd file as output of this makefile - this what you
want. You just need to pick up a mkimage from u-boot project.

Also you should pass clocks in HZ. For this make sure that you have
undefined in u-boot clocks_in_*mhz* environment variable. Use printenv
in u-boot to make sure it is not present.

When you will get to the point when you start a busybox (if you use one)
then it could stuck if /dev has no all nodes required.

Hopefully this helps.

>After "Transferring control to Linux (at address 00000000)" nothing seems happen (see below).
>


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

Re: Problem with starting up 2.4.21 kernel

[Robin Gilks]

>> After "Transferring control to Linux (at address 00000000)" nothing
>> seems happen (see below).
>>

A further problem is that we had the IMMR mapped below the Linux virtual
address of 0xc0000000 which caused it to hang in CPM_reset. Changing
from 0x21000000 to 0xff000000 fixed that problem.

--
Robin Gilks
Senior Design Engineer              Phone: (+64)(3) 357 1569
Tait Electronics                          Fax  :  (+64)(3) 359 4632
PO Box 1645 Christchurch        Email : robin.gilks@tait.co.nz
New Zealand


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