Re: Problems starting init on a SH7750R based board

[Paul M. <pau...@re...>]

On Tue, Oct 30, 2007 at 09:50:08AM +0100, Heiko Schocher wrote:
> Paul Mundt wrote:
> > On Sat, Oct 27, 2007 at 08:19:54AM +0200, Heiko Schocher wrote:
> >> After this I get an Intevent 0x1e0, and then nothing more works ...
> >>
> >> 1) Has somebody here an idea, where this intevent come from? How I can
> >> prevent it?
> >>
> > It sounds like something is generating an interrupt that you aren't
> > acking, for some reason it isn't being caught as spurious and disabled,
> > and you are hanging as a result. If you want to hack around it, you can
> 
> Here the text ends ... I want to hack around it, what can I do?
> 
I don't remember what I was writing here, I think it was in relation to
the set_exception_table_evt() thing that was mentioned later :-)

> > This is rather curious. EVT 0x1e0 implies IRQ -1, and you've simply
> > wrapped, that shouldn't happen. You shouldn't even be entering the
> > do_IRQ() path here, are you certain that this is an INTEVT value rather
> > than an EXPEVT one?
> Hm.. I get this value in the do_IRQ function, so I think it is an INTEVT 
> value.
> Or is there a way do_IRQ () is called from an EXPEVT?

In theory, no. In practice, you may have hit a bug in the interrupt
exception dispatch. If you can trace the path through
arch/sh/kernel/cpu/sh3/entry.S:handle_exception() and
interrupt_exception() it might uncover some clues. Dumping out both the
EXPEVT/INTEVT values would also help to see if something is getting
mangled.

In any event, the evt2irq() math is correct. If there's nothing obvious
in the exception dispatch, I'll dig out a SH7750R manual and see if there
are some vectors that behave in a strange fashion. I suspect you're
probably the first person to do much testing on SH7750R, SH7751R has had
much more testing comparatively.

> asmlinkage void do_1e0_restore(unsigned long r4, unsigned long r5,
>                                    unsigned long r6, unsigned long r7,
>                                    struct pt_regs __regs)
> {
>         struct pt_regs *regs = RELOC_HIDE(&__regs, 0);
>         long ex;
> 
>         lookup_exception_vector(ex);
>         die_if_kernel("1e0 exception", regs, ex);
> }
> 
> no change in the output ...
> 
How about just a printk()? If this triggers at all, the r4 and ex values
would be interesting to see.

> Must I use another gcc? I am actually using:
> Linux version 2.6.24-rc1-g7d7b59ac-dirty (hs@Zeus) (gcc version 4.1.1 
> 20061011 (Red Hat 4.1.1-30)) #19 Tue Oct 30 09:29:07 CET 2007
> 
This should be fine, though you can of course try a 3.x and a 4.2.x for
comparison. I used to primarily use ST's 4.1.1 until it stopped being
able to build the kernel on any interesting configurations.

You can find 3.4.5 and 4.2.1 compilers respectively here:

	http://userweb.kernel.org/~lethal/sh4-gcc-3.4.5-glibc-2.3.5.tar.bz2
	http://userweb.kernel.org/~lethal/gnush4_linux_v0702_rc-1-1.i386.tar.gz

Both of those produce working code (at least as far as the kernel is
concerned), so should easily verify whether you've hit a code generation
problem or not.

> Is there a board running with a SH7750R? Maybe there is some CPU
> specific stuff to set up ...
> 
Can you attach your entire .config? I don't have a SH7750R handy, but can
probably dig one up if nothing else helps.