From: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx•com>
To: "Stephen Neuendorffer" <stephen.neuendorffer@xilinx•com>,
"Grant Likely" <grant.likely@secretlab•ca>
Cc: linuxppc-embedded <linuxppc-embedded@ozlabs•org>
Subject: RE: current ARCH=powerpc for v2pro.
Date: Mon, 3 Dec 2007 17:28:08 -0800 [thread overview]
Message-ID: <20071204012811.AD70CEF004D@mail134-dub.bigfish.com> (raw)
In-Reply-To: <20071204004843.8B5FB1C20046@mail6-sin.bigfish.com>
Hmm... This code (from arch/ppc/boot/simple/embed_config.c) appears to
help:
static const unsigned long line_size =3D 32;
static const unsigned long congruence_classes =3D 256;
unsigned long addr;
unsigned long dccr;
/*
* Invalidate the data cache if the data cache is turned off.
* - The 405 core does not invalidate the data cache on power-up
* or reset but does turn off the data cache. We cannot assume
* that the cache contents are valid.
* - If the data cache is turned on this must have been done by
* a bootloader and we assume that the cache contents are
* valid.
*/
__asm__("mfdccr %0": "=3Dr" (dccr));
if (dccr =3D=3D 0) {
for (addr =3D 0;
addr < (congruence_classes * line_size);
addr +=3D line_size) {
__asm__("dccci 0,%0": :"b"(addr));
}
}
Although, I'm not sure why that should be virtex specific.
Steve=20
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs•org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
> labs.org] On Behalf Of Stephen Neuendorffer
> Sent: Monday, December 03, 2007 4:49 PM
> To: Grant Likely
> Cc: linuxppc-embedded
> Subject: RE: current ARCH=3Dpowerpc for v2pro.
>=20
> I tried that, which essentially differed from what I was=20
> trying in that
> interrupts were turned off.
> It fails in the same way as before.
>=20
> I've booted ARCH=3Dppc from your tree on the exact same hardware =
design,
> and as near as I can tell, the code that runs in the kernel=20
> proper up to
> the point where I see the machine check is almost identical.
>=20
> The machine check (a trap into the Machine Check handler at 0x200)
> occurs at a nondeterministic point during the execution of=20
> memset_io in
> early_init.
>=20
> In the kernel I have, _bss_start is c02c8000, and these are the
> registers in the trap handler on two different runs of the kernel:
>=20
> r3: c02c80cc r5: 00022874
> r3: c02c8248 r5: 000226f4
>=20
> r3 is the current point being initialized, and r5 is the=20
> count remaining
> in the .bss.
>=20
> So, what would cause a machine check in the middle of a loop, in the
> middle of the almost the simplest code absolutely possible, and not on
> an obvious memory boundary?
>=20
> Steve
>=20
> > -----Original Message-----
> > From: glikely@secretlab•ca [mailto:glikely@secretlab•ca] On=20
> > Behalf Of Grant Likely
> > Sent: Friday, November 30, 2007 10:40 PM
> > To: Stephen Neuendorffer
> > Cc: linuxppc-embedded
> > Subject: Re: current ARCH=3Dpowerpc for v2pro.
> >=20
> > On 11/30/07, Stephen Neuendorffer=20
> > <stephen.neuendorffer@xilinx•com> wrote:
> > >
> > > Grant,
> > >
> > > I'm trying to bring up your arch/powerpc work, using a compiled in
> > > device tree. I added this:
> > >
> > <snip>
> > >
> > > Which seems bizarre, because that code is very simple. =20
> I'm guessing
> > > that something in the memory configuration is wierd (or maybe
> > > zImage.virtex is not the right way to do this?) but I'm a=20
> > little lost
> > > where to look from here. I also tried it with both=20
> > paulus_master and
> > > your virtex-for-2.6.24 branch.
> >=20
> >=20
> > I've got a patch that adds 'raw' image support (originally=20
> written by
> > Scott Wood) which somewhat works for booting (but not entirely; I
> > haven't had time to dig into it properly yet). It's not suitable to
> > go into mainline yet. I'll try to get the patch out to my tree this
> > evening... actually I've been trying to get my tree pushed out all
> > today, but other things keep coming up. :-)
> >=20
> > <several hours after I wrote the above>
> >=20
> > Okay, I pushed my current patch set out to the master branch of my
> > linux-2.6-virtex tree. Give it a whirl. It's not perfect, but it
> > should be usable for booting.
> >=20
> > Cheers,
> > g.
> >=20
> > --=20
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> > grant.likely@secretlab•ca
> > (403) 399-0195
> >=20
> >=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs•org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
next prev parent reply other threads:[~2007-12-04 1:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-30 22:21 current ARCH=powerpc for v2pro Stephen Neuendorffer
2007-12-01 6:39 ` Grant Likely
2007-12-04 0:48 ` Stephen Neuendorffer
2007-12-04 1:28 ` Stephen Neuendorffer [this message]
2007-12-13 23:41 ` Device Tree updates for xilinx Stephen Neuendorffer
2007-12-16 7:04 ` David Gibson
2007-12-16 13:38 ` Josh Boyer
2007-12-17 4:58 ` Stephen Neuendorffer
2007-12-17 5:21 ` David Gibson
2007-12-17 6:04 ` Stephen Neuendorffer
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=20071204012811.AD70CEF004D@mail134-dub.bigfish.com \
--to=stephen.neuendorffer@xilinx$(echo .)com \
--cc=grant.likely@secretlab$(echo .)ca \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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