> -----Original Message-----
> From: Atsushi Nemoto [mailto:firstname.lastname@example.org]
> Sent: Wednesday, November 01, 2006 8:19 PM
> To: Trevor Hamm
> Cc: email@example.com
> Subject: Re: Problems booting Linux 184.108.40.206 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?
> memset(pageaddr + bytes, 0, PAGE_CACHE_SIZE - bytes);
> flush_dcache_page(page); /* THIS */
> Atsushi Nemoto
Thanks for the suggestion Atsushi. Unfortunately, this did not solve the
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?