On Mon, 27 Jun 2005, Markus Dahms wrote:
> I'm trying to run a current 2.6 kernel (LinuxMIPS CVS) on my
> Indy(s). It should be a 64-bit kernel (just for fun, but I tried
> 32-bit, too). From the mailing list archives some time ago (about
> half a year) I learned that there are known problems.
> My experiments: Indy with R4600PC (133MHz) boots to userspace
> | ...
> | EXT3-fs: mounted filesystem with ordered data mode.
> | atkbd.c: keyboard reset failed on hpc3ps2/serio0
> | VFS: Mounted root (ext3 filesystem) readonly.
> | Freeing unused kernel memory: 204k freed
> | INIT: version 2.86 booting
> and dies then :(. The same machine, but with a R4000PC (100MHz)
Hmm, it might be a problem with TLB handlers that have been changed to be
built at the run time. Perhaps the R4600 isn't handled right as a result.
What's the CPU revision ID? -- it's printed right at the beginning.
> processor module doesn't even come so far:
> | arcsboot: ARCS Linux ext2fs loader 0.3.8.6
> | Loading 2.6.12-64 from scsi(0)disk(2)rdisk(0)partition(0)
> | Allocated 0x38 bytes for segments
> | Loading 64-bit executable
> | Loading program segment 1 at 0x88004000, offset=0x0 4000, size = \
> | 0x0 3c4086
> | 3c0000 (cache: 95.3%)Zeroing memory at 0x883c8086, size = \
> | 0x42f9a
> | Starting ELF64 kernel
> no more action at this point....
Strange. The system should be capable enough for early printk() to be
trivially implemented using firmware call-backs. It would be more useful
to get some feedback from it this way, otherwise it's asking for a crystal
ball (mine is currently being serviced, if you recall)... It's probably a
BUG() or an Oops somewhere. It might be related to the lack of an S-cache
on this system -- there's been another report recently about it being a
problem on a different machine -- try the patch sent there as a test.