Re: Problems starting init on a SH7750R based board

[Heiko S. <hei...@in...>]

Hello Paul,

Paul Mundt wrote:
> 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.

OK, I try this (but I have to say, I have no debugger ...)

> 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.

OK, I ll have a look in a SH7751R Manual, maybe there are some differences.

>> 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.

I tried this also with a printk, didnt get an output.

>> 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

thanks!
(If this not helps, I try to build the complete Toolchain ... because this
"error" triggers just after running the init application, maybe there is
a problem with some headers ...)

> 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.

Here my complete config, maybe I made a mistake somewhere ...

thanks
Heiko