[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Software reboot problem

What happens at reboot? Nothing at all or does the LED starts to
flash fast? 

Do you use DMA to the FGPAs?
Is the ETRAX WAIT pin connected to the FPGA?
Is the ETRAX BS pins connected to the FPGA?
Is the ETRAX IRQ pin connected to the FPGA?
Is any PA pins connected between ETRAX and the FPGA?

One problem may be that the FPGA is not reset when ETRAX is
reset and the FPGA outputs are not tristated.


-----Original Message-----
From: owner-dev-etrax@xxxxxxx.com">mailto:owner-dev-etrax@xxxxxxx.com] On
Behalf Of Pieter Grimmerink
Sent: Monday, March 08, 2004 4:23 PM
To: Arne Bockholdt
Cc: dev-etrax
Subject: Re: Software reboot problem

On Monday 08 March 2004 13:34, Arne Bockholdt wrote:
> > > I'm trying to reboot our custom MCM design with help of the 
> > > busybox reboot command, which is calling the kernel function 
> > > hard_reset_now() indirectly
> > > to let the watchdoc reset the CPU. Unfortunetly it doesn't work, I
> > > the "hard reset" printk and nothing happens after that
> > Did you get an answer / find the reason in the meantime?
> > We're having the same problem here with our custom design with an
> > 100LX

> It's on my TODO list, I've found out that it seems to be a problem
> by the configuration of the FPGA we've attached to the CPU via CSP1,
> seems the CPU isn't able to reboot after the FPGA is configured,
> the FPGA configuration (bus interface is in tri-state then, same as
> boot-time) at run-time doesn't help. We need to investigate this.

Our problem might have the same cause, since we also attached an FPGA
I've done a quick test, but even when we don't configure the FPGA at
all, the 
hard reset does not work.

> Another related problem is that reboot doesn't call "init 6", the
> for runlevel 6 weren't called, so I stick with calling "init 6" .

I think busybox' reset is designed to work with busybox' built-in init.

But if I understand you right, even "init 6" does not actually succeed
performing the hard reset at the end?
For us, this is the case. All daemons are stopped, at the end
is called, but does not actually reset the Etrax.