Strange behavior on FADS with ICTRL==0

Hello,

I am working with 2.2.5 on a FADS 823. If the ISCT_SER field of the
ICTRL register is set to 0 (which is the value on reset), the system is
very unstable. This field controls whether the core is serialized and
provides options for placing instruction fetches from cache on the
external pins for tracing and debugging purposes.  Mainly, I get one of
two errors after init has started:
    Panic: Kernel Mode Software FPU Emulation
    page fault in interrupt handler
When ISCT_SER is set to 0, the core is fully serialized and all
instruction fetches are shown. On the other hand, if I set the ISCT_SER
to 7 (the recommended "production" value), the core is not serialized
and no fetches are shown. The system is stable with this setting.

Has anyone else experienced anything like this?

Thanks
--
Jim Lewis
Sr. Field Applications Engineer
MontaVista Software, Inc.
(817)261-9088 http://www.mvista.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Jim Lewis wrote:

........ If the ISCT_SER field of the
ICTRL register is set to 0 (which is the value on reset), the system is
very unstable.

You have to be very careful with the configuration of 8xx control and
debug registers.  Depending upon the silicon revision, there are certain
errata that require explicit settings of these registers.  This is certainly
one of them.....some die require serialization to be set, others require you
never set it, others require subsequent software work around depending
upon the setting.


    -- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Check the version of the chip and change it to a B2 version if it is
not it. You should be able to get a sample.

Claude

Jim Lewis wrote:

quoted

........ If the ISCT_SER field of the
ICTRL register is set to 0 (which is the value on reset), the system is
very unstable.

You have to be very careful with the configuration of 8xx control and
debug registers.  Depending upon the silicon revision, there are certain
errata that require explicit settings of these registers.  This is certainly
one of them.....some die require serialization to be set, others require you
never set it, others require subsequent software work around depending
upon the setting.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Claude and Dan:

Thanks for the pointers. I do have an old chip and the erratta does describe this
problem. Shame on me for not having looked at the erratta!
-Jim Lewis

Claude Robitaille wrote:

Check the version of the chip and change it to a B2 version if it is
not it. You should be able to get a sample.

Claude

quoted

Jim Lewis wrote:

quoted

........ If the ISCT_SER field of the
ICTRL register is set to 0 (which is the value on reset), the system is
very unstable.

You have to be very careful with the configuration of 8xx control and
debug registers.  Depending upon the silicon revision, there are certain
errata that require explicit settings of these registers.  This is certainly
one of them.....some die require serialization to be set, others require you
never set it, others require subsequent software work around depending
upon the setting.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Hi,

I see many people using the FADS but yet, enet.c does not seems to
support it. So, people are either just using the SMC serial port
or the change in enet.c is not committed yet into vger. Is there
someone using the Ethernet port on the FADS?

Thanks

Claude


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Hello Claude,

I am using Ethernet on an 823 FADS. I sort of inherited some work that someone
else began. I don't consider it finished yet, but if you want a snapshot of
what we have now, let me know.

-Jim Lewis

Claude Robitaille wrote:

Hi,

I see many people using the FADS but yet, enet.c does not seems to
support it. So, people are either just using the SMC serial port
or the change in enet.c is not committed yet into vger. Is there
someone using the Ethernet port on the FADS?

Thanks

Claude

--
Jim Lewis
Sr. Field Applications Engineer
MontaVista Software, Inc.
(817)261-9088 http://www.mvista.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Hi Jim,

thanks for your offer. Are you using 2.2.5 or 2.3.18? I found that there
is not much to modify, here is what I found:
 1) add FADS board type in config.in in arch/ppc
 2) change init.c in arch/ppc/mm
 3) change commproc.h and enet.c in arch/ppc/8xx_io
 4) add fads_cfg im embedded_config.c in arch/ppc/mbxboot
 5) modify head.S in arch/ppc/mbxboot to call 4)
 6) modify Makefile in arch/ppc/mbxboot to remove unnecessary OBJ
 7) update fads.h in include/asm-ppc

It seems that the FADS was supported in the past since there is some
trace of it. Is it possible to put it back in a public tree?

Right now I am able to go to the point where the kernel is trying to
bootp except that an error is reported in devinet.c.

So, Jim, if you are using 2.3.18 can you generate a patch? I am 
tempted to look at what you have done.

Another question: it there a way to track down the source file containing
a given function? And track down an include file containing a definition?
I am sure there is a way.

Claude

On Thu, 14 Oct 1999, Jim Lewis wrote:

I am using Ethernet on an 823 FADS. I sort of inherited some work that someone
else began. I don't consider it finished yet, but if you want a snapshot of
what we have now, let me know.

Claude Robitaille wrote:

quoted

I see many people using the FADS but yet, enet.c does not seems to
support it. So, people are either just using the SMC serial port
or the change in enet.c is not committed yet into vger. Is there
someone using the Ethernet port on the FADS?

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Claude Robitaille wrote:

It seems that the FADS was supported in the past since there is some
trace of it. Is it possible to put it back in a public tree?

The FADS was never really supported because I didn't have one long
enough to ensure all of the modifications were done.  I had an 860T
FADS for developing the initial FEC driver, and the fadsrom code.

I am getting updates from a few folks that I will put into the CVS tree,
but I can't verify they are correct against other modifications.  Those
will be in my next batch of updates.....soon :-).


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/