> -----Original Message----- > From: Atsushi Nemoto [mailto:anemo@xxxxxxxxxxxxx] > Sent: Wednesday, November 01, 2006 8:19 PM > To: Trevor Hamm > Cc: linux-mips@xxxxxxxxxxxxxx > 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
