From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Gibson <david@gibson.dropbear.id.au>,
Linuxppc-Embedded <linuxppc-embedded@lists.linuxppc.org>
Subject: Re: status of linuxppc_2_4_devel for ppc405gp
Date: Thu, 23 Aug 2001 09:41:00 +0200 [thread overview]
Message-ID: <20010823074100.31846@smtp.wanadoo.fr> (raw)
In-Reply-To: <20010823104023.I28430@zax>
>
>I'm working on this at the moment too. The first problem I found was
>that the ELF loader would refuse to exec() init, which turned out to
>be because bytes 16-32 (and possibly later ones too, I forget) of
>binprm->buf were junk. The data was correct in the page cache. I
>found this was fixed by removing the dcbz from copy_tofrom_user(),
>although I don't see why yet since the cache line size appears to be
>ok.
Ok, I didn't have this one as I removed all the cache tricks from
copy_tofrom_user & copy_page in my version, at least until I get
it working.
I had copy_tofrom_user failing earlier causing ipconfig to fail,
that's why I took this drastic workaround ;)
>I'm now able to run a very simple binary as init - basically "Hello,
>world!" implemented with one write() syscall, and none of the libc
>initialisation junk present. A one write hello world with the normal
>crt0 (statically linked) fails.
Ok. So this would mean the problem is with the libc junk ? Hrm.
I didn't trace that far yet, but I suspect the libc I've been
using (the "normal" 6xx one) lacks some cache stuffs. I'm
pretty convinced that we must inval the entire instructions cache
each time we used to do icbi's (either that or handle the cache
aliasing issues specific to the 405GP weird icache design).
I'll do more experiments later today.
Ben.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-08-23 7:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-22 10:22 status of linuxppc_2_4_devel for ppc405gp Stefan Roese
2001-08-22 12:30 ` Kenneth Johansson
2001-08-22 16:10 ` Dan Malek
2001-08-22 22:29 ` Phillip Lougher
2001-08-22 22:48 ` Dan Malek
2001-08-22 13:41 ` Benjamin Herrenschmidt
2001-08-22 13:32 ` Physically mapped FLASH David Updegraff
2001-08-22 10:32 ` Matt Porter
2001-08-22 16:06 ` status of linuxppc_2_4_devel for ppc405gp Dan Malek
[not found] ` <3B83E474.5B906F13@mvista.com>
2001-08-22 19:31 ` Dan Malek
2001-08-22 20:04 ` Benjamin Herrenschmidt
2001-08-23 0:40 ` David Gibson
2001-08-23 7:41 ` Benjamin Herrenschmidt [this message]
2001-08-23 11:08 ` Benjamin Herrenschmidt
2001-08-24 1:41 ` David Gibson
2001-08-24 5:06 ` Dan Malek
2001-08-24 6:03 ` David Gibson
2001-08-24 10:28 ` Benjamin Herrenschmidt
2001-08-25 2:53 ` 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=20010823074100.31846@smtp.wanadoo.fr \
--to=benh@kernel.crashing.org \
--cc=david@gibson.dropbear.id.au \
--cc=linuxppc-embedded@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).