Messages in this thread Patch in this message | | | Date | Mon, 18 Jan 1999 13:01:40 -0000 (GMT) | From | Gary Thomas <> | Subject | Re: Booting 2.2.0-pre6 on a PowerStack-II (Net 4000/200) |
| |
On 16-Jan-99 Dan Malek wrote: > > Johnnie Peters wrote: > >> I think this is the same problem I was seeing. This machine is also the known as >> the Utah. I fixed this in arch/ppc/boot/misc.c. Here is the diff: >> >> Michael Meissner wrote: 454c454 >> < if (( (unsigned long)zimage_start <= 0x01000000 ) && initrd_start) >> --- >> > if ( (unsigned long)zimage_start <= 0x01000000 ) > > Wait a minute.....this isn't the problem. Making this change will > break other machines. > > >> > > > } loaded at: 00400400 00415FD0 >> > > > } relocated to: 00600000 00615BD0 >> > > > } zimage at: 0040A400 0049A889 >> > > > } avail ram: 00400000 00600000 > > For whatever reason, at the end of the memory relocation process, > we force the available ram buffer to the location above. What happened > in this case is the load image was copied into memory into the space > we assumed was to be used for free memory. > > This boot process has become a nightmare. At first glance it looks > pretty generic, but it is full of assumptions about how specific types > of systems load images. There are actually two different loading > locations, above 8 Meg (physical) for most machines or at exactly > 2 Meg for small memory systems like the 8xx boards. When you load > the initial image between these locations, as in this example, the boot > process is unlikely to work. > > The initial boot code is built to run at either 1 Meg or 6 Meg. When started > it relocates itself to those locations. We should clean up the code in > misc.c to do something similar. The only restriction in this case would be > the boot code (plus bss, which people often forget) must not overlap the > zImage or the ramdisk. In other words, the correct thing to do is not > force the abosolute location of the free memory. We already go through > the arithmetic to find some free memory, so why not just use it? > > In this case, removing the fragment of code: > > #ifndef CONFIG_MBX > /* this is safe, just use it */ > /* I don't know why it didn't work for me on the MBX with 20 MB > * memory. I guess something was saved up there, but I can't > * figure it out......we are running on luck. -- Dan. > */ > avail_ram = (char *)0x00400000; > end_avail = (char *)0x00600000; >#endif > > would likely work. Just change the #ifdef above to #if 0. Let me know > what happens in this case. > > > Thanks. > > > -- Dan
Here's what I got to work (patches):
diff -ur /tmp/linux-2.2.0p5/arch/ppc/boot/misc.c /usr/src/linux-2.2.0p5/arch/ppc/boot/misc.c --- /tmp/linux-2.2.0p5/arch/ppc/boot/misc.c Mon Dec 21 16:37:20 1998 +++ /usr/src/linux-2.2.0p5/arch/ppc/boot/misc.c Sun Jan 17 12:15:03 1999 @@ -411,7 +417,7 @@ if ( INITRD_OFFSET ) end_avail = (char *)0x01000000; else - end_avail = (char *)0x00400000; + end_avail = (char *)0x00800000; /* let residual data tell us it's higher */ if ( (unsigned long)residual > 0x00800000 ) @@ -522,6 +528,7 @@ #ifndef CONFIG_MBX /* this is safe, just use it */ +#if 0 /* Hah! This is really wrong on PreP boxes with OF */ /* I don't know why it didn't work for me on the MBX with 20 MB * memory. I guess something was saved up there, but I can't * figure it out......we are running on luck. -- Dan. @@ -529,6 +536,7 @@ avail_ram = (char *)0x00400000; end_avail = (char *)0x00600000; #endif +#endif puts("avail ram: "); puthex((unsigned long)avail_ram); puts(" "); puthex((unsigned long)end_avail); puts("\n"); I'll try upgrading to 2.2.0p7 tonight and see how that works. I haven't been able to get the PS/2 mouse working yet. Also, I'll try to stitch in the code I had in the 2.0.XX kernels to handle/fake residual data on the PreP boxes - so I can have my 64M RAM back :-)
Please note: I'm either 'gthomas@cygnus.co.uk' or 'gdt@linuxppc.org', not 'gdt@cygnus.com'.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |