Linux crashes during memory mapping
Atit_Shah
Atit_Shah at Satyam.com
Thu Mar 31 14:45:07 EST 2005
Hi All,
I am trying to port the EP8248 Linux image (which works perfectly on the
EP8248 board) on the VPN board (In house board) which is mpc8248 based
board.
I do not have any problem with the functioning of U-Boot but Linux crashes
after printing "Uncompressing Kernel ... OK" and then it seems that nothing
is happening.
It would be great if u could help me resolve the issue. The following is how
i have configured my board:
1. The value of the IMMR in HCRW is configured to 0xF0000000 (which is same
as in the ep8248 image). The value of IMAP_ADDR in
linux/arch/ppc/platforms/ep8248.h and u-boot/include/configs/ep8248.h is
0xF0000000
2. The memory map of EP8248 board (REFERENCE BOARD) is :
=====================================================================
Memory Region Size Address Range
=====================================================================
SDRAM 16MByte 0000_0000 -- 07FF_FFFF
Flash 8MByte FF80_0000 -- FFFF_FFFF
3. The memory map of the VPN Board (MY BOARD) is as folllows:
=====================================================================
Memory Region Size Address Range
======================================================================
SDRAM 32MByte 0000_0000 -- 01FF_FFFF
Flash 32MByte FF00_0000 -- FFFF_FFFF
>From the u-boot the parameters passed to the kernel (pointer to a function
which actually starts loading the kernel image) are :
(*kernel) (kbd, initrd_start, initrd_end, cmd_start, cmd_end);
kbd (ptr to board info strcture),
initrd_start (=0, as in our case we dont have any ramdisk),
initrd_end (=0),
cmd_start (Start of command line string),
cmd_end (End of command line string)
4. Board Info Structure defined in u-boot (/include/asm-ppc/u-boot.h) and
Linux (include/asm-ppc/ep8248.h) are the same and is passed correctly from
u-boot to Linux.
By putting some Printk's I had cheacked that control is reaching to the
function mapin_ram(void) in file arch/ppc/mm/pgtable.c
Here it is supposed to map the 32 MB of virtual memory to the Physical
memory.
The control does not leave the for loop in which the memory mapping takes
place.
This is what the console log buffer has shown:
=================================================================
md 0x00177e34
00177e34: 3c363e6d 73746172 743d303c 363e6d73 <6>mstart=0<6>ms
00177e44: 697a653d 303c363e 66737461 72743d30 ize=0<6>fstart=0
00177e54: 3c363e66 73697a65 3d303c36 3e696d6d <6>fsize=0<6>imm
00177e64: 723d303c 363e626f 74666c61 673d303c r=0<6>botflag=0<
00177e74: 363e6970 6164643d 303c363e 65616464 6>ipadd=0<6>eadd
00177e84: 3d633031 35303032 383c363e 65737065 =c0150028<6>espe
00177e94: 643d303c 363e696e 6974663d 303c363e d=0<6>initf=0<6>
00177ea4: 62757366 3d303c36 3e63706d 663d303c busf=0<6>cpmf=0<
00177eb4: 363e6272 67663d30 3c363e73 6363663d 6>brgf=0<6>sccf=
00177ec4: 303c363e 76636f3d 303c363e 62617564 0<6>vco=0<6>baud
00177ed4: 3d304f6f 70733a20 6b65726e 656c2061 =0Oops: kernel a
00177ee4: 63636573 73206f66 20626164 20617265 ccess of bad are
00177ef4: 612c2073 69673a20 31310a3c 343e4e49 a, sig: 11.<4>NI
00177f04: 503a2030 30303030 30303020 5845523a P: 00000000 XER:
00177f14: 20303030 30303030 30204c52 3a203030 00000000 LR: 00
00177f24: 30303030 30302053 503a2030 30303030 000000 SP: 00000
00177f34: 30303020 52454753 3a206330 31353030 000 REGS: c01500
00177f44: 30302054 5241503a 20303030 30202020 00 TRAP: 0000
00177f54: 204e6f74 20746169 6e746564 0a3c343e Not tainted.<4>
00177f64: 4d53523a 20303030 30303030 30204545 MSR: 00000000 EE
00177f74: 3a203020 50523a20 30204650 3a203020 : 0 PR: 0 FP: 0
00177f84: 4d453a20 30204952 2f44523a 2030300a ME: 0 IR/DR: 00.
00177f94: 3c343e54 41534b20 3d206330 31346634 <4>TASK = c014f4
00177fa4: 37305b30 5d202773 77617070 65722720 70[0] 'swapper'
00177fb4: 4c617374 20737973 63616c6c 3a203020 Last syscall: 0
00177fc4: 0a3c343e 6c617374 206d6174 68203030 .<4>last math 00
00177fd4: 30303030 3030206c 61737420 616c7469 000000 last alti
00177fe4: 76656320 30303030 30303030 0a3c343e vec 00000000.<4>
00177ff4: 43616c6c 20626163 6b747261 63653a20 Call backtrace:
00178004: 30303030 30303034 200a3c34 3e4f6f70 00000004 .<4>Oop
00178014: 733a206b 65726e65 6c206163 63657373 s: kernel access
00178024: 206f6620 62616420 61726561 2c207369 of bad area, si
00178034: 673a2031 310a3c34 3e4e4950 3a204330 g: 11.<4>NIP: C0
00178044: 31353030 43302058 45523a20 43303135 1500C0 XER: C015
00178054: 30304138 204c523a 20303330 30303043 00A8 LR: 030000C
00178064: 30205350 3a203030 30333030 30312052 0 SP: 00030001 R
00178074: 4547533a 20633031 35303030 30205452 EGS: c0150000 TR
00178084: 41503a20 63303135 30306330 20202020 AP: c01500c0
00178094: 4e6f7420 7461696e 7465640a 3c343e4d Not tainted.<4>M
001780a4: 53523a20 66666666 66646661 2045453a SR: fffffdfa EE:
001780b4: 20312050 523a2031 2046503a 2031204d 1 PR: 1 FP: 1 M
001780c4: 453a2031 2049522f 44523a20 31310a3c E: 1 IR/DR: 11.<
001780d4: 343e5441 534b203d 20633031 34663437 4>TASK = c014f47
001780e4: 305b305d 20277377 61707065 7227204c 0[0] 'swapper' L
001780f4: 61737420 73797363 616c6c3a 2030200a ast syscall: 0 .
00178104: 3c343e6c 61737420 6d617468 20303030 <4>last math 000
00178114: 30303030 30206c61 73742061 6c746976 00000 last altiv
00178124: 65632030 30303030 3030300a 3c343e43 ec 00000000.<4>C
00178134: 616c6c20 6261636b 74726163 653a2030 all backtrace: 0
00178144: 30303030 30303420 0a3c343e 4f6f7073 0000004 .<4>Oops
00178154: 3a206b65 726e656c 20616363 65737320 : kernel access
00178164: 6f662062 61642061 7265612c 20736967 of bad area, sig
00178174: 3a203131 0a3c343e 4e49503a 20433031 : 11.<4>NIP: C01
00178184: 35303043 30205845 523a2043 30313530 500C0 XER: C0150
00178194: 30413820 4c523a20 30303030 31303332 0A8 LR: 00001032
001781a4: 2053503a 20433030 31333946 30205245 SP: C00139F0 RE
001781b4: 47533a20 63303135 30303030 20545241 GS: c0150000 TRA
001781c4: 503a2063 30313530 30633020 2020204e P: c01500c0 N
001781d4: 6f742074 61696e74 65640a3c 343e4d53 ot tainted.<4>MS
001781e4: 523a2066 66666666 64666120 45453a20 R: fffffdfa EE:
001781f4: 31205052 3a203120 46503a20 31204d45 1 PR: 1 FP: 1 ME
00178204: 3a203120 49522f44 523a2031 310a3c34 : 1 IR/DR: 11.<4
00178214: 3e544153 4b203d20 63303134 66343730 >TASK = c014f470
00178224: 5b305d20 27737727 204c6173 74207379 [0] 'sw' Last sy
00178234: 7363616c 6c3a202d 31303732 33363535 scall: -10723655
00178244: 3638200a 3c343e6c 61737420 6d617468 68 .<4>last math
00178254: 20303030 30303030 30206c61 73742061 00000000 last a
00178264: 6c746976 65632030 30303030 3030300a ltivec 00000000.
00178274: 00000000 00000000 00000000 00000000 ................
1.Is all this information sufficient to help you understand and pin point
our mistake, Is there any thing other than the parameters which are passed
to the kernel from the u-boot that I need to look into.
2. I have a query in the Linux source code. I would like to know why the
value of "ioremap_base = 0xfe000000UL;" in linux/arch/ppc/mm/init.c line 356
has been hard coded and how was this value determined? What is the impact of
this value?
Any pointers, ideas, comments would be of great help. i would be more than
glad to provide you with any further information required to debug the
problem.
Thanks and best regards,
Atit
**************************************************************************
This email (including any attachments) is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or
distribution or forwarding of any or all of the contents in this message is
STRICTLY PROHIBITED. If you are not the intended recipient, please contact
the sender by email and delete all copies; your cooperation in this regard
is appreciated.
**************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20050331/1a82639d/attachment.htm
More information about the Linuxppc-embedded
mailing list