Re: Linux-2.1.129 boot on MCP750

Re: Linux-2.1.129 boot on MCP750

[Corey Minyard]

I have posted patches to this group that fix all these problems.
You can search the lists for them.

Alois Fertl <alois_fertl@muenchen.europe.mcd.mot.com> writes:
> If you manage to put your zImage onto a prep partition
> of a hard drive or if you boot it from floppy it should
> work fine.
> 
> There is a problem in boot/misc.c which manifests only
> if netboot is used. Current ppcbug netboots at 0x5000 and
> this forces decompress to overwrite its own source.
> 
> You can fool netboot resp. boot/misc.c if you netboot
> zImage.initrd ( make zImage.initrd which requires ramdisk.image.gz
> in arch/ppc/boot; somewhere on the R4 CD ) and type
>    noinitrd
> to the Linux/PPC load: prompt.
> 
> I found some other improvement over the weekend which help using
> linuxppc with serial console only. Due to limited time I was not
> able to propagate them yet. I promise to do so over the next days.
> 
> Regards
>   Alois
> 
> 
> 
> On Fri, 20 Nov 1998 18:25:08 +0100 (CET) VALETTE Eric 
> <valette@crf.canon.fr> wrote:
> 
> > 
> > 
> > I have sucessfully compiled the brand new linux-2.1.129 source tree
> > without any glich. I used the PREP configuration, made the zImage and tried
> > to boot it using motorola ppcbug firmware.
> > 
> > I first discovered that I add to replace all putc, puts routine because
> > I use the serial line (not a big deal). Then I added a more general code
> > than puthex in order to print also decimal and fixed some output in 
> > arch/ppc/boot to get inflate errors.
> > 
> > Here is what I get now : It shows that inflate fails.
> > 
> > -----------------------------------------------------------
> > Local Memory Found =02000000 (&33554432)
> > 
> > MPU Clock Speed =233Mhz
> > 
> > BUS Clock Speed =67Mhz
> > 
> > WARNING: Keyboard Not Connected
> > 
> > Reset Vector Location  : ROM Bank B
> > Mezzanine Configuration: Single-MPU
> > Current 60X-Bus Master : MPU0
> > Idle MPU(s)            : NONE
> > 
> > System Memory: 32MB, ECC Enabled (ECC-Memory Detected)
> > L2Cache:       1024KB, 117Mhz
> > 
> > PPC1-Bug>nbo
> > Network Booting from: DEC21140, Controller 0, Device 0
> > Device Name: /pci@80000000/pci1011,9@e,0:0,0
> > Loading: /zImage
> > 
> > Client IP Address      = 194.2.81.157
> > Server IP Address      = 194.2.81.241
> > Gateway IP Address     = 194.2.81.254
> > Subnet IP Address Mask = 255.255.255.0
> > Boot File Name         = /zImage
> > Argument File Name     = 
> > 
> > Network Boot File load in progress... To abort hit <BREAK>
> > 
> > Bytes Received =&794942, Bytes Loaded =&794942
> > Bytes/Second   =&397471, Elapsed Time =2 Second(s)
> > 
> > Residual-Data Located at: $01F78000
> > loaded at:     5400 19FC0
> > 
> > relocated to:  600000 614BC0
> > 
> > board data at: 1F78000 1F7EA0C
> > 
> > relocated to:  60E0B4 614AC0
> > 
> > zimage at:     E400 C539E
> > 
> > avail ram:     400000 600000
> > 
> > 
> > 
> > Linux/PPC load: 
> > 
> > Uncompressing Linux...descompressing to : 0 400000inflate returned-3  <============
> > exit
> > 
> > ---------------------------------------------------------------------------
> > 
> > Reading the Makefile and trying to figure out how the binary image was 
> > done, I discovered that the compressed image is set in the file at the
> > same offset than the .bss and that there is in head.S a bzero of the
> > bss section As shown by the following header dump.
> > 
> > 
> > ----------------------------------------------------------------------------
> > objdump -h zvmlinux
> > 
> > zvmlinux:     file format elf32-powerpc
> > 
> > Sections:
> > Idx Name          Size      VMA       LMA       File off  Algn
> >   0 .text         00005950  00600000  00600000  00010000  2**2
> >                   CONTENTS, ALLOC, LOAD, READONLY, CODE
> >   1 .rodata       00001560  00605950  00605950  00015950  2**4
> >                   CONTENTS, ALLOC, LOAD, READONLY, DATA
> >   2 .data         00001b2c  00607000  00607000  00017000  2**2
> >                   CONTENTS, ALLOC, LOAD, DATA
> >   3 .bss          0000bbc0  00609000  00609000  00019000  2**2
> >                   ALLOC
> >   4 image         000b6f9f  00000000  00000000  00019000  2**0
> >                   CONTENTS, READONLY
> > ---------------------------------------------------------------------------
> > 
> > So I propose the following : 
> > 
> > Make mkprep know a little bit more about ELF and make a different binary image
> > with bss already zeroed and image moved from bss size. Do you know if libelf
> > package works on Linux PPC as It does on Linux Intel?
> > 
> > 1) Is the analysis correct?
> > 2) Do you want the small modif for printing decimal and the code that
> > prints correctly errors in gunzip routine?
> > 
> > 
> > 
> > 
> > -- 
> >    __                 
> >   /  `                   	Eric Valette
> >  /--   __  o _.          	Canon CRF
> > (___, / (_(_(__         	Rue de la touche lambert
> > 				35517 Cesson-Sevigne  Cedex
> > 				FRANCE
> > Tel: +33 (0)2 99 87 68 91	Fax: +33 (0)2 99 84 11 30
> > E-mail: valette@crf.canon.fr
> 
> 
> 
> 

-- 
Corey Minyard               Internet:  minyard@acm.org
  Work: minyard@nortel.ca       UUCP:  minyard@wf-rch.cirr.com

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Linux-2.1.129 boot on MCP750

[Cort Dougan]

You can change the address that ppcbug loads the image to.  I pointed mine
at the end of memory to keep it out of the way.  The boot code for prep is
very delicate right now due to the many many addresses that boards load
the image at so anything that can make it easier (such as moving the
address the kernel is loaded at) I want to take advantage of.

}> There is a problem in boot/misc.c which manifests only
}> if netboot is used. Current ppcbug netboots at 0x5000 and
}> this forces decompress to overwrite its own source.
}
}Can you elaborate on which versions of ppcbug this is a problem with and
}in what cases?  I have been booting the kernel on MVME23/26/27/36xx and an
}MCP750 without seeing this problem...maybe cause my MCP750 has an older
}rev of ppcbug.

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Linux-2.1.129 boot on MCP750

[VALETTE Eric]

>>>>> "Cort" == Cort Dougan <cort@persephone.cs.nmt.edu> writes:

Cort> You can change the address that ppcbug loads the image to.  I pointed mine
Cort> at the end of memory to keep it out of the way.  The boot code for prep is
Cort> very delicate right now due to the many many addresses that boards load
Cort> the image at so anything that can make it easier (such as moving the
Cort> address the kernel is loaded at) I want to take advantage of.

I would like to have the instruction to make that.

Have a nice day,

-- eric

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Linux-2.1.129 boot on MCP750

[Cort Dougan]

http://linuxppc.cs.nmt.edu/ has pointers to the info for anonymous cvs
access.

}OK thanks. Is there any restriction to get acces to the CVS repository ?
}Is there a ftp of http address and something like cvsweb?


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Linux-2.1.129 boot on MCP750

[Gabriel Paubert]

On Tue, 24 Nov 1998, VALETTE Eric wrote:

> 
> >>>>> "Alois" == Alois Fertl <alois_fertl@muenchen.europe.mcd.mot.com> writes:
> 
> Thanks to your patch sugested for misc.c I'm now able to decompress
> the 2.1.129 kernel.
> 
> -----Patch included here (not from me but from Corey Minyard <minyard@acm.org>)--------------
> diff -urN linux-pmac-2.1.127.old/arch/ppc/boot/misc.c linux-pmac-2.1.127/arch/ppc/boot/misc.c
> --- linux-pmac-2.1.127.old/arch/ppc/boot/misc.c	Sun Sep 20 06:43:04 1998
> +++ linux-pmac-2.1.127/arch/ppc/boot/misc.c	Fri Nov 13 11:34:50 1998
> @@ -451,7 +451,11 @@
>  	 * insufficient memory.  In this case we don't have initrd either,
>  	 * so use that as an indicator.  -- Dan
>  	 */
> +#ifdef CONFIG_MBX
>  	if (( (unsigned long)zimage_start <= 0x01000000 ) && initrd_start)
> +#else
> +	if ( (unsigned long)zimage_start <= 0x01000000 )
> +#endif
>  	{
>  		memcpy ((void *)PAGE_ALIGN(-PAGE_SIZE+(unsigned long)end_avail-zimage_size),
>  			(void *)zimage_start, zimage_size );	
> @@ -478,7 +482,7 @@
>  		 * max ram is.
>  		 * -- Cort
>  		 */
> -#if 0		
> +#ifndef CONFIG_MBX
>  		memcpy ((void *)PAGE_ALIGN(-PAGE_SIZE+(unsigned long)end_avail-INITRD_SIZE),
>  			(void *)initrd_start,
>  			INITRD_SIZE );
> 
> -----------------------------------------------------------------------------------------------
> 
> Unfortunately, I still have problems as shown by the
> following trace :
> 
> 	  1) Apparently I have problem with Raven chipset initialization regarding
> 	  interrupt management/mapping (all chip detection see a irq 0)
> 	  2) I also have problem with the NCR53c825 initialization
> 	  as it does not find the right irq nor detect the scsi disk
> 	  I have attached,
> 
> I have a side question : readding the source code, the RAVEN chipset that
> is present on MVME2700 and MPC750 is managed only in the case of CHRP 
> architecture. So shall I add code to dynamically detect mtorola hardware
> and switch machine to MACH_chrp ?

I wannted to do something like this to enable very large windows on the
VME bus through the Universe. I think we should communnicate privately and
fast in this area unntil we converge towards a working solution...

	Gabriel.




[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]