From: Dan Malek <dmalek@jlc.net>
To: Johnnie Peters <jpeters@phx.mcd.mot.com>
Cc: Michael Meissner <meissner@cygnus.com>,
Alois Fertl <alois_fertl@mucmot.muenchen.europe.mcd.mot.com>,
Cort Dougan <cort@persephone.cs.nmt.edu>,
linux-kernel@vger.rutgers.edu, linuxppc-dev@lists.linuxppc.org,
gdt@cygnus.com
Subject: Re: Booting 2.2.0-pre6 on a PowerStack-II (Net 4000/200)
Date: Sat, 16 Jan 1999 13:54:50 -0500 [thread overview]
Message-ID: <36A0E079.F90619F5@jlc.net> (raw)
In-Reply-To: 369FF02B.8684CA2A@phx.mcd.mot.com
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
[[ 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 ]]
next prev parent reply other threads:[~1999-01-16 18:54 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-01-12 22:43 Booting 2.2.0-pre6 on a PowerStack-II (Net 4000/200) Michael Meissner
1999-01-13 20:10 ` Cort Dougan
1999-01-15 15:28 ` Alois Fertl
1999-01-15 20:10 ` Cort Dougan
1999-01-15 21:58 ` Michael Meissner
1999-01-15 22:04 ` Cort Dougan
1999-01-15 23:33 ` Michael Meissner
1999-01-18 8:51 ` Alois Fertl
1999-01-16 1:49 ` Johnnie Peters
1999-01-16 18:54 ` Dan Malek [this message]
1999-01-17 18:58 ` Cort Dougan
1999-01-18 9:21 ` Gabriel Paubert
1999-01-18 13:01 ` Gary Thomas
1999-01-18 16:54 ` Cort Dougan
1999-01-18 17:58 ` Michael Meissner
1999-01-19 22:43 ` Michael Meissner
1999-01-20 0:18 ` Johnnie Peters
1999-01-20 3:53 ` 3-button mouse Brent H Mundy
1999-01-20 22:20 ` Benjamin Herrenschmidt
1999-01-21 9:34 ` pre8(vger) kills button 3 on 1-button mouse Martin Costabel
1999-01-21 10:05 ` 3-button mouse fritzwe.linux
1999-01-20 15:21 ` Booting 2.2.0-pre6 on a PowerStack-II (Net 4000/200) Gary Thomas
1999-01-20 15:31 ` Johnnie Peters
1999-01-21 23:46 ` Johnnie Peters
1999-01-22 1:52 ` Michael Meissner
1999-01-22 2:04 ` Cort Dougan
1999-01-22 7:54 ` Gary Thomas
1999-01-22 8:19 ` Cort Dougan
1999-01-22 11:07 ` Gary Thomas
1999-01-22 15:17 ` Johnnie Peters
1999-02-01 15:58 ` Michael Meissner
1999-02-01 16:18 ` Gary Thomas
1999-02-04 19:09 ` Michael Meissner
1999-02-04 19:21 ` Gary Thomas
1999-02-04 20:23 ` Michael Meissner
[not found] ` <XFMail.990119102730.gdt@linuxppc.org>
1999-01-19 13:13 ` Michael Meissner
1999-01-19 13:28 ` Gary Thomas
1999-01-19 18:54 ` Dan Malek
1999-01-20 13:56 ` Loic Prylli
1999-01-18 18:11 ` Dan Malek
-- strict thread matches above, loose matches on Subject: below --
1999-01-16 2:23 Johnnie Peters
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=36A0E079.F90619F5@jlc.net \
--to=dmalek@jlc.net \
--cc=alois_fertl@mucmot.muenchen.europe.mcd.mot.com \
--cc=cort@persephone.cs.nmt.edu \
--cc=gdt@cygnus.com \
--cc=jpeters@phx.mcd.mot.com \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=meissner@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).