From: Dan Malek <dmalek@jlc.net>
To: Helmut Buchsbaum <helmut.buchsbaum@siemens.at>
Cc: linuxppc-dev <linuxppc-dev@lists.linuxppc.org>
Subject: Re: Problems starting up system on a MPC823FADS
Date: Wed, 16 Dec 1998 17:27:16 -0500 [thread overview]
Message-ID: <367833C4.60C22371@jlc.net> (raw)
In-Reply-To: 36750901.A3E0E6D1@siemens.at
Helmut Buchsbaum wrote:
> I try to get a linux system up and running on a Motorola MPC823FADS
Cool!
> ...... I only adopted the boot code slightly to feed the
> correct board info data, set up the correct clocks, etc., since my board
> has no boot prom.
Points again!
> 3) Setting up MMU works fine, the kernel initializes SMC1 (my console)
> and SMC2 for UART and SCC2 for ethernet (I adopted Dan's drivers for the
> MPC823, wasn't a big deal ;-)
Sorry about that. I have recently finished an 821, 823, and 850
port to several boards. I am sitting on lots of configuration changes
like this. It was easy to just hack the files, but now I have to
make the config process work. That is going to take longer
than the other changes :-(. I hope to have it done as a new year
treat for everyone!
> Now the kernel tries to load & exec /sbin/init and /lib/ld.so.1. Loading
> via nfs seems to work fine (haven't had any trouble with this part) but
> when the kernel sets up the memory for this process I realized a strange
Yes. I and others have seen this on the FADS boards. I don't
yet understand it since the same software will run on other boards.
> BTW, why must the M_TWB be set in SET_PAGE_DIR ?
The M_TWB points to the first level page table (Linux pgd_t)
and is used in the mpc8xx page fault handler. When Linux
deletes or otherwise modifies the memory map object such that
the first level page table is modified (as during exec), it
uses SET_PAGE_DIR. Since the first level table has potentially
moved to a new memory location, we have to set M_TWB at
this time. If we don't, a process exec without an intervening
context switch will cause us to use a bogus M_TWB when
trying to find page tables.
-- 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:[~1998-12-16 22:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-12-14 12:48 Problems starting up system on a MPC823FADS Helmut Buchsbaum
1998-12-16 22:27 ` Dan Malek [this message]
-- strict thread matches above, loose matches on Subject: below --
1998-12-16 18:05 Magnus Damm
1998-12-18 18:10 ` Dan Malek
[not found] <H0000b360900f795@MHS>
1998-12-17 9:59 ` Helmut Buchsbaum
1998-12-17 19:28 ` Dan Malek
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=367833C4.60C22371@jlc.net \
--to=dmalek@jlc.net \
--cc=helmut.buchsbaum@siemens.at \
--cc=linuxppc-dev@lists.linuxppc.org \
/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).