Re: Ingenic JZ4730 - illegal instruction

[Nils Faerber <nils.faerber@kernelconcepts.de>]

Kevin D. Kissell schrieb:
> I don't have time to go chasing this stuff any further on your behalf,

I do not expect that either ;)
I am already quite happy that you shared your experience with me - it
already helped me a lot to fid some points in the code that could be the
culprit and I can dig further from here.

> but it *does* smell to me like an icache management problem.  Remember,
> MIPS processors almost universally have split I/D caches and no
> coherence support between them, so if you either (a) forget to do an
> explicit D-cache write-back operation after copying to a page mapped
> write-back that's going to be used as instructions/text, or (b) forget
> to do an explicit I-cache invalidate when you re-use a page for
> instructions that has been previously used for a different instruction
> page, you will have problems, even without going into DMA I/O coherence
> issues.  If your problem were (b), though, you'd be seeing bad answers,
> segmentation violations, bus errors, etc., at least as often as you'd be
> seeing illegal instruction exceptions.  So my money would be on (a).

Yes, it is only illegal instructions, no other faults.

> The need for cache management is so fundamental to Linux for MIPS that
> all the necessary general hooks have been there for years.  If I were
> you, I'd focus on the definitions of the primitives that you spotted in
> c-r4k.c.  Does the stuff in the JZ_RISC section correspond to the

OK.

> assembly language flush sequence done in the Ingenic patch to head.S? 
> Are you sure that the JZ_RISC section is in fact the version of those
> functions that's being built into your kernel?

Well, there is CONFIG_JZRISC=y in the kernel .config and a
switch(current_cpu_type) { case CPU_JZRISC: ...} so I would assume it is
being used. But I will verify that the CONFIG_JZRISC=y is correctly
translated into a current_cpu_type.

Oh, one last question, in order to rule out the cache as bug-spot would
the kernel option "run uncached" "solve" the issue (and be darn slow)?

>           Regards,
>           Kevin K.
Thanks a lot so far!
It helped me a great deal to start to understand what is going on here...

Cheers
  nils faerber

-- 
kernel concepts GbR        Tel: +49-271-771091-12
Sieghuetter Hauptweg 48    Fax: +49-271-771091-19
D-57072 Siegen             Mob: +49-176-21024535
http://www.kernelconcepts.de