Hmm... This code (from arch/ppc/boot/simple/embed_config.c) appears to
help:
static const unsigned long line_size = 32;
static const unsigned long congruence_classes = 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": "=r" (dccr));
if (dccr == 0) {
for (addr = 0;
addr < (congruence_classes * line_size);
addr += line_size) {
__asm__("dccci 0,%0": :"b"(addr));
}
}
Although, I'm not sure why that should be virtex specific.
Steve
> -----Original Message-----
> From:
> [EMAIL PROTECTED]
>
> [mailto:[EMAIL PROTECTED]
> 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=powerpc for v2pro.
>
> I tried that, which essentially differed from what I was
> trying in that
> interrupts were turned off.
> It fails in the same way as before.
>
> I've booted ARCH=ppc from your tree on the exact same hardware design,
> and as near as I can tell, the code that runs in the kernel
> proper up to
> the point where I see the machine check is almost identical.
>
> The machine check (a trap into the Machine Check handler at 0x200)
> occurs at a nondeterministic point during the execution of
> memset_io in
> early_init.
>
> 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:
>
> r3: c02c80cc r5: 00022874
> r3: c02c8248 r5: 000226f4
>
> r3 is the current point being initialized, and r5 is the
> count remaining
> in the .bss.
>
> 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?
>
> Steve
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > Behalf Of Grant Likely
> > Sent: Friday, November 30, 2007 10:40 PM
> > To: Stephen Neuendorffer
> > Cc: linuxppc-embedded
> > Subject: Re: current ARCH=powerpc for v2pro.
> >
> > On 11/30/07, Stephen Neuendorffer
> > <[EMAIL PROTECTED]> 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.
> 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
> > little lost
> > > where to look from here. I also tried it with both
> > paulus_master and
> > > your virtex-for-2.6.24 branch.
> >
> >
> > I've got a patch that adds 'raw' image support (originally
> 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. :-)
> >
> > <several hours after I wrote the above>
> >
> > 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.
> >
> > Cheers,
> > g.
> >
> > --
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> > [EMAIL PROTECTED]
> > (403) 399-0195
> >
> >
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
