current ARCH=powerpc for v2pro.

[Stephen Neuendorffer]

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: 
> linuxppc-embedded-bounces+stephen=neuendorffer.name at ozlabs.org
>  
> [mailto:linuxppc-embedded-bounces+stephen=neuendorffer.name at 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=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: glikely at secretlab.ca [mailto:glikely at secretlab.ca] 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 
> > <stephen.neuendorffer at 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.  
> 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.
> > grant.likely at secretlab.ca
> > (403) 399-0195
> > 
> > 
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
>