Subject: RE: Problems booting Linux 2.6.18.1 on MIPS34K core

From: Trevor Hamm <[email-masked]>
Date: Wed, 8 Nov 2006 11:09:37 -0800

> -----Original Message-----
> From: Atsushi Nemoto [mailto:[email-masked]] 
> Sent: Wednesday, November 01, 2006 8:19 PM
> To: Trevor Hamm
> Cc: [email-masked]
> Subject: Re: Problems booting Linux 2.6.18.1 on MIPS34K core
> 
> If dcache aliasing patch caused this problem, it might be due to
> missing flush_dcache_page() in squashfs.
> 
> With a quick look at squashfs/inode.c, it seems flush_dcache_page() is
> needed at end of squashfs_symlink_readpage() as other functions.
> Could you try it?
> 
> skip_read:
> 	memset(pageaddr + bytes, 0, PAGE_CACHE_SIZE - bytes);
> 	kunmap(page);
> 	flush_dcache_page(page);	/* THIS */
> 	SetPageUptodate(page);
> 	unlock_page(page);
> 
> ---
> Atsushi Nemoto
> 

Thanks for the suggestion Atsushi.  Unfortunately, this did not solve the problem.

I recently got my hands on a FS2 EJTAG probe, and with it was able to find the "exact" instruction causing the fault.  Which instruction is dependent on the particular linux image I'm using at the time, but usually happens while running /lib/ld-uClibc-0.9.28.so when starting up /sbin/init.  Typically what happens is that the program reads a pointer value out of memory (which returns 0 or some other random value), then when a later instruction attempts to use that address to load in a value, that's where it goes into an endless loop of TLBS or AdEL exceptions.  When I examine the memory contents where the program loads this pointer value from, after power-up both the main memory and cache appear to be loaded with random values, but after software reset the cache at least has values that look more like valid program addresses.

So just for fun, I built a linux image to use a write-through caching policy, and it boots from power-up every time.

With this information, I would conclude the problem is due to cache management, either in the way we're initializing the cache, or something else in the squashfs code.  Or is there another explanation that I'm overlooking?

Thanks,
Trevor

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 8 Nov 2006 19:24:20 +0000

> With this information, I would conclude the problem is due to cache management, either in the way we're initializing the cache, or something else in the squashfs code.  Or is there another explanat…

Does your processor have cache aliases?

  Ralf

---

From: Atsushi Nemoto <[email-masked]>
Date: Thu, 09 Nov 2006 10:57:52 +0900 (JST)

On Wed, 8 Nov 2006 11:09:37 -0800 , Trevor Hamm <[email-masked]> wrote:
> So just for fun, I built a linux image to use a write-through
> caching policy, and it boots from power-up every time.
> 
> With this information, I would conclude the problem is due to cache
> management, either in the way we're initializing the cache, or
> something else in the squashfs code.  Or is there another
> explanation that I'm overlooking?

Hmm, could you try init=/bin/sh?  If the shell invoked successfully it
might be COW issue.  In this case, could you try deleting
__HAVE_ARCH_COPY_USER_HIGHPAGE in include/asm-mips/page.h?

If init=/bin/sh not worked, COW is irrelevant and something would be
wrong around flush_dcache_page/update_mmu_cache.  But no idea now ...

---
Atsushi Nemoto