Using zImage.initrd

Using zImage.initrd

[Daniel Wu]

Does anyone what the difference between making a kernel with "make zImage" and
"Make zImage.initrd"? - Apart from the obvious fact that the later builds a
kernel which expects the rootfs to be on the RAM disk.

Anyway, the problem I'm having is that with the "make zImage" kernel, I get
alot further in the boot sequence. Here is my output:

loaded at:     00200000 0020B1E4
relocated to:  00600000 0060B1E4
board data at: 00600190 006001B8
relocated to:  001F0100 001F0128
zimage at:     00206000 00275065
avail ram:     0060B1E4 02000000

Linux/PPC load: root=/dev/nfs rw
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.2.13 (aaluser@c1rb) (gcc version 2.95.2 19991024 (release)
) #21 Fri Jun 9 08:06:48 EST 2000
Boot arguments: root=/dev/nfs rw
time_init: decrementer frequency = 187500000/60
Calibrating delay loop... 49.87 BogoMIPS
Memory: 31268k available (800k kernel code, 668k data, 32k init)
[c0000000,c2000
000]
DENTRY hash table entries: 262144 (order: 9, 2097152 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0 for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
TCP: Hash tables configured (ehash 32768 bhash 32768)
Starting kswapd v 1.5
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
ttyS01 at 0x0380 is a SMC
ttyS02 at 0x0100 is a SCC
ttyS03 at 0x0200 is a SCC
pty: 256 Unix98 ptys configured
RAM disk driver initialized:  16 RAM disks of 4096K size
PPP: version 2.3.7 (demand dialling)
TCP compression code copyright 1989 Regents of the University of California
PPP line discipline registered.
SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256).
VFS: Cannot open root device 00:00
Kernel panic: VFS: Unable to mount root fs on 00:00
Rebooting in 180 seconds..


Whereas the kernel produced using "make zImage.initrd" crashed alot earlier:

loaded at:     00200000 0020B1E4
relocated to:  00600000 0060B1E4
board data at: 00600190 006001B8
relocated to:  001F0100 001F0128
zimage at:     00206000 0027508F
initrd at:     0027508F 003535A8
avail ram:     00354000 02000000

Linux/PPC load: root=/dev/ram
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.2.13 (aaluser@c1rb) (gcc version 2.95.2 19991024 (release)
) #20 Fri Jun 9 07:56:09 EST 2000
Boot arguments: root=/dev/ram
time_init: decrementer frequency = 187500000/60
Calibrating delay loop... 49.87 BogoMIPS
Memory: 30376k available (800k kernel code, 668k data, 32k init)
[c0000000,c2000
000]
DENTRY hash table entries: 262144 (order: 9, 2097152 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
NIP: C000D23C XER: 2000E32F LR: C00B8474 REGS: c00e6a90 TRAP: 0300
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
TASK = c00e4d20[0] 'swapper' mm->pgd c00e3000 Last syscall: 0
last math 00000000
GPR00: C00B8474 C00E6B40 C00E4D20 FFFFFEFF 00000001 00000016 0000002D FFFFFFFF
GPR08: FFFFFFFF 00000004 00000004 00000000 00000040 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 00000000 00600190 0000013E C0110000
GPR24: 00000000 00000004 C00F579C 00000004 00000001 C00FF160 FFFFFFFF C00E6B40
Call backtrace:
C00FF71B C00B8474 C00B8648 C00FA2B4 C00F7774 C000221C
Kernel panic: kernel access of bad area pc c000d23c lr c00b8474 address
FFFFFEFF
 tsk swapper/0
In swapper task - not syncing
Rebooting in 180 seconds..

The crash location is in the __wake_up function according to the map.

Thanks,
Daniel


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

Re: Using zImage.initrd

[Murray Jensen]

On Fri, 9 Jun 2000 08:38:20 +1000, Daniel Wu <Daniel.Wu@alcatel.com.au> writes:
>Does anyone what the difference between making a kernel with "make zImage" and
>"Make zImage.initrd"? - Apart from the obvious fact that the later builds a
>kernel which expects the rootfs to be on the RAM disk.

Firstly, you need to select both CONFIG_BLK_DEV_RAM and CONFIG_BLK_DEV_INITRD
to build zImage.initrd. Secondly, you need a file in arch/ppc/mbxboot called
ramdisk.image.gz. When you build zImage.initrd, the secondary boot loader
is re-compiled with INITRD_OFFSET and INITRD_SIZE set, which are used to
locate the start and end of the ramdisk.image.gz file in memory. The start
and end are passed to the kernel in registers (r4/r5??), which it saves into
the variables initrd_start and initrd_end. The secondary boot loader also
changes the kernel command line arguments so that root=/dev/ram instead of
root=/dev/nfs. The kernel does various things if initrd_start is non-zero,
but the main one is to decompress the ramdisk.image.gz data into ramdisk 0,
and because root=/dev/ram, this is then mounted as the root filesystem. Others
can point out anything I have left out - I tried my best :-)

>The crash location is in the __wake_up function according to the map.

Try this patch:

--- fs/buffer.c	2000/05/16 01:31:41	1.1.1.12
+++ fs/buffer.c	2000/06/02 04:26:16
@@ -2336,7 +2336,7 @@
 {
 	DECLARE_WAITQUEUE(wait, current);

-	if (current == bdflush_tsk)
+	if (bdflush_tsk == 0 || current == bdflush_tsk)
 		return;

 	if (!block) {

It is against the 2.3.x kernel, but I think it should apply to the 2.2.x
kernel ok. Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@cmst.csiro.au  (old address was mjj@mlb.dmt.csiro.au)


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

Re: Using zImage.initrd

[Dan Malek]

Murray Jensen wrote:

> Try this patch:
>
> --- fs/buffer.c 2000/05/16 01:31:41     1.1.1.12


The 2.2.xx kernels don't have any ramdisk patch required.  This was
broken in later 2.3.xx kernels.  Don't be trying this in 2.2 kernels.


	-- Dan

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

Re: Using zImage.initrd

[Murray Jensen]

On Thu, 08 Jun 2000 22:52:43 -0400, Dan Malek <dan@netx4.com> writes:
>Murray Jensen wrote:
>
>> Try this patch:
>>
>> --- fs/buffer.c 2000/05/16 01:31:41     1.1.1.12
>
>
>The 2.2.xx kernels don't have any ramdisk patch required.  This was
>broken in later 2.3.xx kernels.  Don't be trying this in 2.2 kernels.

It's not the ramdisk patch, just the simple check to ensure that the
"bdflush_tsk" variable is not NULL in wakeup_bdflush(). This patch should
be ok to try if you are getting a crash in __wake_up(). It may or may not
fix the problem, but it shouldn't hurt. Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@cmst.csiro.au  (old address was mjj@mlb.dmt.csiro.au)


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

Re: Using zImage.initrd

[Dan Malek]

Daniel Wu wrote:

> .... Here is my output:
>
> loaded at:     00200000 0020B1E4
> relocated to:  00600000 0060B1E4
> board data at: 00600190 006001B8
> relocated to:  001F0100 001F0128
> zimage at:     00206000 00275065
> avail ram:     0060B1E4 02000000

It would be really nice if you weren't changing the link/load addresses.
I am not sure this is causing any problem, but it doesn't help.  The
code in the mbxboot directory makes assumptions about where things
were loaded.

The Makefile in this directory should contain the line:
	ZLINKFLAGS = -T ../vmlinux.lds -Ttext 0x00100000

In the 2.4 kernel this changed to:
	ZLINKFLAGS = -T ../vmlinux.lds -Ttext 0x00180000

because the kernel is larger.  If you have this problem in 2.2.xx, change
it like this.

The zImage bits should be loaded somewhere >= 0x200000.  If this
doesn't work for you, post a message explaining why and lets find
a solution.  These addresses are based upon lots of board samples,
and if yours doesn't fit, let's try to find something that works for
everything.

> Linux/PPC load: root=/dev/nfs rw

> VFS: Cannot open root device 00:00
> Kernel panic: VFS: Unable to mount root fs on 00:00
> Rebooting in 180 seconds..

In this case, you are trying to use NFS root disk without a network
device configured.  You need to enable one of the Ethernet (SCC or FEC)
options.


> Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
> NIP: C000D23C XER: 2000E32F LR: C00B8474 REGS: c00e6a90 TRAP: 0300

This is really early in the initialization, and something is really
messed up.  What processor are you running and what is the silicon
revision?  Do you have caches enabled?  Where did you get the kernel
sources?  What have you changed?


> C00FF71B C00B8474 C00B8648 C00FA2B4 C00F7774 C000221C

What is the rest of this backtrace?


	-- Dan

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

Re: Using zImage.initrd

[Daniel Wu]

Dan Malek wrote:

> The zImage bits should be loaded somewhere >= 0x200000.  If this
> doesn't work for you, post a message explaining why and lets find
> a solution.  These addresses are based upon lots of board samples,
> and if yours doesn't fit, let's try to find something that works for
> everything.
>

The zImage.initrd is loaded at 0x200000, this ensures that the zImage >=
0x200000 since the image contains the boot + zImage + initrd. The loader is
copied to 0x600000 and execute from there ( I've reserved 4M for the boot +
zImage + initrd). Will this be a problem?

>
>
> > Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
> > NIP: C000D23C XER: 2000E32F LR: C00B8474 REGS: c00e6a90 TRAP: 0300
>
> This is really early in the initialization, and something is really
> messed up.  What processor are you running and what is the silicon
> revision?  Do you have caches enabled?  Where did you get the kernel
> sources?  What have you changed?
>

The CPU is 860T (XPC860TZP50B3). The caches are enabled as far as I can tell
from the code. I got the sources from the MontaVista site and applied the CPU6
patch you posted earlier. Apart from that, a couple of changes to
mbxboot/head.S to set the IMMR and the UPM.

>
> > C00FF71B C00B8474 C00B8648 C00FA2B4 C00F7774 C000221C
>
> What is the rest of this backtrace?
>

C00FF71B buf
C00B8474 extract_entropy
C00B8648 get random_bytes
C00FA2B4 init_elf_binfmt
C00F7774 start_kernel
C000221C start_here


Daniel


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

Re: Using zImage.initrd

[Dan Malek]

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

Daniel Wu wrote:


> .... The loader is
> copied to 0x600000 and execute from there ( I've reserved 4M for the boot +
> zImage + initrd). Will this be a problem?

That isn't necessary.  The code in the mbxboot directory takes care
of reserving space.  It assumes the loader is copied into _lower_
memory from the load point.  All of these build procedures in the
generic sources work very nicely and you shouldn't have to change
anything.



> The CPU is 860T (XPC860TZP50B3). The caches are enabled as far as I can tell
> from the code.

So, have you run any diagnostics to make sure your UPM programming
is working correctly?  When Linux comes to life with caches, MMU,
and the CPM running, it creates worst case memory cycles that are
very difficult to duplicate with diagnostic programs.  Any little
memory timing problem will show up here.  I would suggest completely
disabling the cache (I guess I should add a kernel configuration
for this).  See the attachment.

> > What is the rest of this backtrace?
> >
>
> C00FF71B buf
> C00B8474 extract_entropy
> C00B8648 get random_bytes
> C00FA2B4 init_elf_binfmt
> C00F7774 start_kernel
> C000221C start_here

Oh wow.....If this is really where the code is running, something
very fundamental is broken in the hardware because there should have
been lots more printed out on the console.  You are still running in
very generic kernel functions that work on all architectures.


	-- Dan

[-- Attachment #2: head_nocache --]
[-- Type: text/plain, Size: 935 bytes --]



Change the code that looks like this:


	lis	r8, IDC_INVALL@h
	mtspr	IC_CST, r8
	mtspr	DC_CST, r8
	lis	r8, IDC_ENABLE@h
	mtspr	IC_CST, r8
#ifdef CONFIG_8xx_COPYBACK
	mtspr	DC_CST, r8
#else
	/* For a debug option, I left this here to easily enable
	 * the write through cache mode
	 */
	lis	r8, DC_SFWT@h
	mtspr	DC_CST, r8
	lis	r8, IDC_ENABLE@h
	mtspr	DC_CST, r8
#endif

/* We now have the lower 8 Meg mapped into TLB entries, and the caches
 * ready to work.
 */
#endif /* CONFIG_8xx */
	b	turn_on_mmu



To look like this:


	lis	r8, IDC_INVALL@h
	mtspr	IC_CST, r8
	mtspr	DC_CST, r8
#if 0
	lis	r8, IDC_ENABLE@h
	mtspr	IC_CST, r8
#ifdef CONFIG_8xx_COPYBACK
	mtspr	DC_CST, r8
#else
	/* For a debug option, I left this here to easily enable
	 * the write through cache mode
	 */
	lis	r8, DC_SFWT@h
	mtspr	DC_CST, r8
	lis	r8, IDC_ENABLE@h
	mtspr	DC_CST, r8
#endif
#else
	lis	r8, IDC_DISABLE@h
	mtspr	IC_CST, r8
	mtspr	DC_CST, r8
#endif

Re: Using zImage.initrd

[Daniel Wu]

Dan Malek wrote:

>
> > > What is the rest of this backtrace?
> > >
> >
> > C00FF71B buf
> > C00B8474 extract_entropy
> > C00B8648 get random_bytes
> > C00FA2B4 init_elf_binfmt
> > C00F7774 start_kernel
> > C000221C start_here
>
> Oh wow.....If this is really where the code is running, something
> very fundamental is broken in the hardware because there should have
> been lots more printed out on the console.  You are still running in
> very generic kernel functions that work on all architectures.
>

But this is only a problem if I do "make zImage.initrd" and not "make zImage". The
latter actually passes this point without error, it fails when it can't get the root
image from the network, when is expected since I am not planning to boot using that
method.

Anyway, I will give your suggestions a try, but my feeling is that they won't make
much difference. BTW, the hardware is not "new" and it works fine with another OS and
applications. I ported the UPM setup from the existing code so I'm pretty sure they
are ok.

Daniel


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