4xx - a question and a patch

4xx - a question and a patch

[David Gibson]

First the question: is there a good reason that set_dec() is a no-op
on 4xx, rather than setting the PIT?  It's not a perfect approximation
to the decrementer, but as far as I can tell it should be close enough
for the next_dec code from arch/ppc/kernel/time.c to work properly.

Second a patch - the below adds floating point emulation to the 4xx.
With this patch I've been able to boot a Walnut to a shell.  Of
course, anything I try to run from the shell dies horribly...

diff -urN ../linuxppc_2_4_devel/arch/ppc/kernel/traps.c linux-bungo/arch/ppc/kernel/traps.c
--- ../linuxppc_2_4_devel/arch/ppc/kernel/traps.c	Wed Aug 29 10:41:56 2001
+++ linux-bungo/arch/ppc/kernel/traps.c	Thu Aug 30 17:02:36 2001
@@ -1,5 +1,5 @@
 /*
- * BK Id: SCCS/s.traps.c 1.23 08/29/01 08:57:35 paulus
+ * BK Id: %F% %I% %G% %U% %#%
  */
 /*
  *  linux/arch/ppc/kernel/traps.c
@@ -265,7 +265,12 @@
 #endif
 		_exception(SIGTRAP, regs);
 	} else {
+#ifdef CONFIG_MATH_EMULATION
+		if (do_mathemu(regs))
+			_exception(SIGILL, regs);
+#else
 		_exception(SIGILL, regs);
+#endif
 	}
 #else
 	if (regs->msr & 0x100000) {


--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson


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

HHL 2.0 Journeyman and SuSE Linux

[Steven Scholz]

Hi there,

is it possible to install and use the HHL 2.0 Journeyman Edition on a
SuSE Linux 7.x machine?

Or do I actually have to buy the Profesional Edition?

It looks like Journeyman only (!) suports Red Hat as a development host?
Is that right?

TIA

Steven Scholz

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

Re: HHL 2.0 Journeyman and SuSE Linux

[Tom Rini]

On Thu, Aug 30, 2001 at 10:54:07AM +0200, Steven Scholz wrote:

> is it possible to install and use the HHL 2.0 Journeyman Edition on a
> SuSE Linux 7.x machine?

Possibly.  The RedHat rpms should 'just work'.  Or you can download the
source rpms and compile the host tools for your setup.  The target binaries
are all the same.

> It looks like Journeyman only (!) suports Red Hat as a development host?
> Is that right?

Yes.  We also provide the source however.  And everything goes into /opt
anyways.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: HHL 2.0 Journeyman and SuSE Linux

[Steven Scholz]

> > is it possible to install and use the HHL 2.0 Journeyman Edition on a
> > SuSE Linux 7.x machine?

Yep. It is!

Just "patch" the script hhl-host-install:

--- hhl-host-install.ORIG       Fri May 25 18:34:49 2001
+++ hhl-host-install    Thu Aug 30 18:07:22 2001
@@ -532,8 +532,8 @@
     elif [ -r /etc/SuSE-release ]
     then
        RPMVERSION=3
-       RPMSUBDIR=suse70
-       HOST=suse
+       RPMSUBDIR=redhat62
+       HOST=redhat
        HOSTARCH=i386

     elif [ -r /etc/yellowdog-release ]

"redhat62" is because of RPM version (3.0.06) used on SuSE 7.2.

Thanks Steven, well done! ;-)

> Possibly.  The RedHat rpms should 'just work'.  Or you can download the
> source rpms and compile the host tools for your setup.  The target binaries
> are all the same.

They do work, indeed. At least for building a kernel.

Thanks Tom.


Steven Scholz

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

Re: 4xx - a question and a patch

[Dan Malek]

David Gibson wrote:
>
> First the question: is there a good reason that set_dec() is a no-op
> on 4xx, rather than setting the PIT?

Yes.  The PIT is far from a perfect approximation of the decrementer.
When you "set the PIT" you actually set the reload register, not the
value that is decrementing.


> Second a patch - the below adds floating point emulation to the 4xx.

Got it.  Thanks.  Since we now have libraries built specially for
processors without floating point, emulation isn't necessary.  Try
them out.


	-- Dan

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

Re: 4xx - a question and a patch

[David Gibson]

On Tue, Sep 04, 2001 at 03:50:21PM -0400, Dan Malek wrote:
>
> David Gibson wrote:
> >
> > First the question: is there a good reason that set_dec() is a no-op
> > on 4xx, rather than setting the PIT?
>
> Yes.  The PIT is far from a perfect approximation of the decrementer.
> When you "set the PIT" you actually set the reload register, not the
> value that is decrementing.

The 405gp manual implies that an mtspr to the PIT writes both the
decrementing value and the reload register.  Is this a hardware /
documentation bug?  Could the PIT be used this way if auto-reload was
disabled?

> > Second a patch - the below adds floating point emulation to the 4xx.
>
> Got it.  Thanks.  Since we now have libraries built specially for
> processors without floating point, emulation isn't necessary.  Try
> them out.

Sure, but it's still useful to be able to run binaries copied from
"normal" PPC machines.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson


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

Re: 4xx - a question and a patch

[Dan Malek]

David Gibson wrote:

> The 405gp manual implies that an mtspr to the PIT writes both the
> decrementing value and the reload register.  Is this a hardware /
> documentation bug?

Well, the point is that it writes the reload register.  When it
gets to zero, it reloads with this register, which is wrong.

> .....  Could the PIT be used this way if auto-reload was
> disabled?

No, because the PIT doesn't count down past zero.  If they would
have allowed this, we could have disabled the auto-reload and
treated it just like the decrementer.

The best I could come up with is just allow the PIT run with a
proper and fixed reload value.  It isn't a decrementer and we
can't treat it like one.


> Sure, but it's still useful to be able to run binaries copied from
> "normal" PPC machines.

Just remember that you can't be mixing float emulation and in-line
floating point software.


	-- Dan

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

Re: 4xx - a question and a patch

[David Gibson]

On Wed, Sep 05, 2001 at 12:18:30AM -0400, Dan Malek wrote:
>
> David Gibson wrote:
>
> > The 405gp manual implies that an mtspr to the PIT writes both the
> > decrementing value and the reload register.  Is this a hardware /
> > documentation bug?
>
> Well, the point is that it writes the reload register.  When it
> gets to zero, it reloads with this register, which is wrong.

But when it hits zero we'll also get another timer interrupt and will
shortly be updating it with a corrected value.  Why does it matter
that the value is reloaded?

> > .....  Could the PIT be used this way if auto-reload was
> > disabled?
>
> No, because the PIT doesn't count down past zero.  If they would
> have allowed this, we could have disabled the auto-reload and
> treated it just like the decrementer.

Maybe I'm being dense, but I don't see why that matters.  We're
working out the actual time elapsed between ticks from the time base
not the decrementer (i.e. timer_interrupt() calls set_dec(), but never
get_dec()) so why are values below zero important?

> The best I could come up with is just allow the PIT run with a
> proper and fixed reload value.  It isn't a decrementer and we
> can't treat it like one.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson


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

Re: 4xx - a question and a patch

[Dan Malek]

David Gibson wrote:

> But when it hits zero we'll also get another timer interrupt and will
> shortly be updating it with a corrected value.  Why does it matter
> that the value is reloaded?

I don't understand the reason for this discussion.  Is something
not working correctly?  If so, make it work better and send me a
patch.


	-- Dan

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

Re: 4xx - a question and a patch

[David Gibson]

On Wed, Sep 05, 2001 at 11:34:03AM -0400, Dan Malek wrote:
>
> David Gibson wrote:
>
> > But when it hits zero we'll also get another timer interrupt and will
> > shortly be updating it with a corrected value.  Why does it matter
> > that the value is reloaded?
>
> I don't understand the reason for this discussion.  Is something
> not working correctly?  If so, make it work better and send me a
> patch.

Well, there's nothing actually broken, but allowing the set_dec() in
timer_interrupt() to affect the PIT should keep the timer interrupts
from drifting too far from the time base, and hence slightly reduce
the jitter in jiffies.  But, no, I don't actually have any timings or
data to confirm that that is the case.  I've been running this way in
my kernel for a month or so, so it certainly doesn't break anything
badly.  I'm trying to find out if my understanding of the situation is
actually correct.

And the patch:

diff -urN ../linuxppc_2_4_devel/include/asm-ppc/time.h linux-bungo/include/asm-ppc/time.h
--- ../linuxppc_2_4_devel/include/asm-ppc/time.h	Wed Aug 29 10:41:56 2001
+++ linux-bungo/include/asm-ppc/time.h	Thu Sep  6 11:01:04 2001
@@ -46,7 +46,7 @@
 static __inline__ void set_dec(unsigned int val)
 {
 #if defined(CONFIG_4xx)
-	return;		/* Have to let it auto-reload */
+	mtspr(SPRN_PIT, val);
 #elif defined(CONFIG_8xx_CPU6)
 	set_dec_cpu6(val);
 #else

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson


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