imac of booting

imac of booting

[Ben Martz]

Stupid question maybe but I can't find a definitive answer. Can I boot
linuxppc from OF on my iMac? Does the elf loader in OF work? If anyone has
it working, please share your configuration. =) I would really like to set
up my iMac without MacOS if at all possible.

Cheers,
Ben


----
Ben Martz - benmartz@earthlink.net



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: imac of booting

[Joel Klecker]

At 19:59 -0400 1999-05-10, Ben Martz wrote:
>Stupid question maybe but I can't find a definitive answer. Can I boot
>linuxppc from OF on my iMac? Does the elf loader in OF work?

The ELF loader in OF does work (part of the Mac OS boot process uses 
it in fact), however it does not like Linux kernel ELF images.

Until someone figures out the problem and fixes it, the answer is no.
-- 
Joel Klecker (aka Espy)                    Debian GNU/Linux Developer
<URL:mailto:jk@espy.org>                 <URL:mailto:espy@debian.org>
<URL:http://web.espy.org/>               <URL:http://www.debian.org/>

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: imac of booting

[David Edelsohn]

>>>>> Joel Klecker writes:

Joel> At 19:59 -0400 1999-05-10, Ben Martz wrote:
>> Stupid question maybe but I can't find a definitive answer. Can I boot
>> linuxppc from OF on my iMac? Does the elf loader in OF work?

Joel> The ELF loader in OF does work (part of the Mac OS boot process uses 
Joel> it in fact), however it does not like Linux kernel ELF images.

Joel> Until someone figures out the problem and fixes it, the answer is no.

	CHRP does not want just an ELF image, but an ELF image with a CHRP
"note" section.  The note section describes where to load the image,
whether the image is running real or virtual, and how to instantiate OF.
NetBSD has more details about this for their macppc port.  Cort may
already have addressed some of this for the CHRP-based RS/6000 port work.

	CHRP looks for a PT_NOTE section in the loader header and then
specific magic values in the section itself.

David


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: imac of booting

[Geert Uytterhoeven]

On Tue, 11 May 1999, David Edelsohn wrote:
> >>>>> Joel Klecker writes:
> Joel> At 19:59 -0400 1999-05-10, Ben Martz wrote:
> >> Stupid question maybe but I can't find a definitive answer. Can I boot
> >> linuxppc from OF on my iMac? Does the elf loader in OF work?
> 
> Joel> The ELF loader in OF does work (part of the Mac OS boot process uses 
> Joel> it in fact), however it does not like Linux kernel ELF images.
> 
> Joel> Until someone figures out the problem and fixes it, the answer is no.
> 
> 	CHRP does not want just an ELF image, but an ELF image with a CHRP
> "note" section.  The note section describes where to load the image,
> whether the image is running real or virtual, and how to instantiate OF.
> NetBSD has more details about this for their macppc port.  Cort may
> already have addressed some of this for the CHRP-based RS/6000 port work.
> 
> 	CHRP looks for a PT_NOTE section in the loader header and then
> specific magic values in the section itself.

What about doing the same as for the CHRP LongTrail (arch/ppc/chrpboot/)?

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Anyone playing with Darwin 0.2 binary yet?

[Kevin B. Hendricks]

Hi,

I was interested in playing around with Darwin (Apple's open BSD Unix
variant) and noticed the new binary available from
http://www.publicsource.apple.com

It says it will boot on most machines that MacOS server will.  And it now
includes EGCS as its compiler.

I have a PowerTower 604e system 200Mhz, PCI, 64 meg ram, etc.  It looks
like a suped up 7200 if I remember correctly.  The machine ID is 108.

Is anyone out in Linux PPC land also playing with Darwin?  Will the new
binary boot on my machine?  Are there any tricks I need to use to get it to
boot?

Thanks for any help.

Kevin



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Anyone playing with Darwin 0.2 binary yet?

[Nathan Ingersoll]

I think that it only works with G3 or newer machines.

"Kevin B. Hendricks" wrote:

> Hi,
>
> I was interested in playing around with Darwin (Apple's open BSD Unix
> variant) and noticed the new binary available from
> http://www.publicsource.apple.com
>
> It says it will boot on most machines that MacOS server will.  And it now
> includes EGCS as its compiler.
>
> I have a PowerTower 604e system 200Mhz, PCI, 64 meg ram, etc.  It looks
> like a suped up 7200 if I remember correctly.  The machine ID is 108.
>
> Is anyone out in Linux PPC land also playing with Darwin?  Will the new
> binary boot on my machine?  Are there any tricks I need to use to get it to
> boot?
>
> Thanks for any help.
>
> Kevin


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Anyone playing with Darwin 0.2 binary yet?

[Roger Ivie]

>I think that it only works with G3 or newer machines.

I've had it running on a 9600, but this machine _does_ have a G3 upgrade.
Interestingly, MacOS X Server refuses to install on this machine.

-- 
Roger Ivie
TeraGlobal Communications Corporation
1770 North Research Park Way
North Logan, UT 84341
Phone: (435)787-0555
Fax: (435)787-0516

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Anyone playing with Darwin 0.2 binary yet?

[David A. Gatwood]

On Tue, 11 May 1999, Roger Ivie wrote:

> >I think that it only works with G3 or newer machines.
> 
> I've had it running on a 9600, but this machine _does_ have a G3 upgrade.
> Interestingly, MacOS X Server refuses to install on this machine.

You might try installing with another machine, then hooking the drive up
to it and see if that works.  It'd be an interesting experiment.  :-)


David

David A. Gatwood                         Visit globegate's internet
dgatwood@globegate.utm.edu                  talker, Deep Space 36
http://globegate.utm.edu                telnet globegate.utm.edu:9624


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

New PPC/Mac features of 2.2.8?

[Jason Haas]

Hi folks,

The cutting-edge linux site says there are "major PPC arch" updates and
mac arch updates in 2.2.8.  What are they?  Or, is there somewhere I can
look to find out?

Thanks,

-- h.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: New PPC/Mac features of 2.2.8?

[Matt Porter]

On Wed, 12 May 1999, Jason Haas wrote:

> Hi folks,
> 
> The cutting-edge linux site says there are "major PPC arch" updates and
> mac arch updates in 2.2.8.  What are they?  Or, is there somewhere I can
> look to find out?

Well, one thing I've noted is that a good deal of the Motorola support has
made its way out of Mot, through cvs, and into 2.2.8/2.3.0.  This includes
proper ID of every board, configuration of the MPIC, and proper PCI
interrupt routing based on the board type.  A major step forward for Mot
PReP systems.

--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: New PPC/Mac features of 2.2.8?

[Tom Rini]

On Wed, 12 May 1999, Jason Haas wrote:

> The cutting-edge linux site says there are "major PPC arch" updates and
> mac arch updates in 2.2.8.  What are they?  Or, is there somewhere I can
> look to find out?

Just a vger sync.  Common config should now be a lot nicer.  RS/6000 (or
whatever Cort has now) too.

---
Tom Rini (TR1265)
http://dobbstown.yeti.edu/


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

DB_THREAD support in Berkeley DB/glibc

[Troy Benjegerdes]

I've just figured out that the reason openldap doesn't work is that it
assumes all platforms support the DB_THREAD argument for db_appinit.

After looking at the glibc/Berkeley DB source, it turns out that all it
needs is 10 or so lines of ASM for spinlocks.

Could someone working on glibc developement add the required ASM and get
this into the mainline distribution? Thanks.

(look in glibc/db2/mutex, I believe )

--------------------------------------------------------------------------
| Troy Benjegerdes    |  troy@blacklablinux.com    |    hozer@drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------


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

Re: DB_THREAD support in Berkeley DB/glibc

[Daniel Jacobowitz]

If I'm not mistaken, David Huggins-Daines did this recently.  It is in
the debian packages of glibc in the latest release.


On Sun, Dec 26, 1999 at 09:04:12PM -0600, Troy Benjegerdes wrote:
> 
> I've just figured out that the reason openldap doesn't work is that it
> assumes all platforms support the DB_THREAD argument for db_appinit.
> 
> After looking at the glibc/Berkeley DB source, it turns out that all it
> needs is 10 or so lines of ASM for spinlocks.
> 
> Could someone working on glibc developement add the required ASM and get
> this into the mainline distribution? Thanks.
> 
> (look in glibc/db2/mutex, I believe )
> 
> --------------------------------------------------------------------------
> | Troy Benjegerdes    |  troy@blacklablinux.com    |    hozer@drgw.net   |
> |    Unix is user friendly... You just have to be friendly to it first.  |
> | This message composed with 100% free software.    http://www.gnu.org   |
> --------------------------------------------------------------------------
> 
> 


Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

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

Re: DB_THREAD support in Berkeley DB/glibc

[Joel Klecker]

At 02:59 -0500 1999-12-28, Daniel Jacobowitz wrote:
>If I'm not mistaken, David Huggins-Daines did this recently.  It is in
>the debian packages of glibc in the latest release.

For convenience, here it is (note that this hasn't really been tested on powerpc):

diff -urN --exclude=*.info glibc-2.1.2/db2/config.h glibc-2.1.2.new/db2/config.h
--- glibc-2.1.2/db2/config.h	Tue Jun  9 11:02:06 1998
+++ glibc-2.1.2.new/db2/config.h	Tue Nov 30 21:33:33 1999
@@ -66,6 +66,12 @@
 /* Define if you want to use sparc/gcc assembly spinlocks. */
 /* #undef HAVE_ASSEM_SPARC_GCC */
 
+/* Define if you want to use alpha/gcc assembly spinlocks. */
+/* #undef HAVE_ASSEM_ALPHA_GCC */
+
+/* Define if you want to use powerpc/gcc assembly spinlocks. */
+/* #undef HAVE_ASSEM_POWERPC_GCC */
+
 /* Define if you want to use uts4/cc assembly spinlocks. */
 /* #undef HAVE_ASSEM_UTS4_CC */
 
diff -urN --exclude=*.info glibc-2.1.2/db2/mutex/alpha.gcc glibc-2.1.2.new/db2/mutex/alpha.gcc
--- glibc-2.1.2/db2/mutex/alpha.gcc	Wed Aug 27 15:32:54 1997
+++ glibc-2.1.2.new/db2/mutex/alpha.gcc	Tue Nov 30 23:09:14 1999
@@ -31,22 +31,23 @@
 	register tsl_t *__l = (tsl);					\
 	register tsl_t __r1, __r2;					\
 	__asm__ volatile("						\n\
-	   10: ldq_l %0,(%2)						\n\
+	   10: ldl_l %0,%3						\n\
 	       blbs  %0,30f						\n\
 	       or    %0,1,%1						\n\
-	       stq_c %1,(%2)						\n\
+	       stl_c %1,%2						\n\
 	       beq   %1,20f						\n\
 	       mb							\n\
 	       br    30f						\n\
 	   20: br    10b						\n\
 	   30: "							\
-	  : "=&r" (__r1), "=&r" (__r2)					\
-	  : "r" (__l));							\
+	  : "=&r" (__r1), "=&r" (__r2), "=m"(*__l)			\
+	  : "2" (*__l)							\
+	  : "memory");							\
 	!__r1;								\
 })
 
 #define TSL_UNSET(tsl) ({						\
 	register tsl_t *__l = (tsl);					\
-	__asm__ volatile("mb; stq $31,(%0);" : : "r" (__l));		\
+	__asm__ volatile("mb; stl $31,%0;" : "=m" (*__l) : : "memory");	\
 })
 #define	TSL_INIT(tsl)	TSL_UNSET(tsl)
diff -urN --exclude=*.info glibc-2.1.2/db2/mutex/mutex.c glibc-2.1.2.new/db2/mutex/mutex.c
--- glibc-2.1.2/db2/mutex/mutex.c	Tue Jun  9 11:04:35 1998
+++ glibc-2.1.2.new/db2/mutex/mutex.c	Tue Nov 30 21:33:33 1999
@@ -86,6 +86,14 @@
 #include "sparc.gcc"
 #endif
 
+#ifdef HAVE_ASSEM_ALPHA_GCC
+#include "alpha.gcc"
+#endif
+
+#ifdef HAVE_ASSEM_POWERPC_GCC
+#include "powerpc.gcc"
+#endif
+
 #ifdef HAVE_ASSEM_UTS4_CC
 #define TSL_INIT(x)
 #define TSL_SET(x)	(!uts_lock(x, 1))
diff -urN --exclude=*.info glibc-2.1.2/db2/mutex/powerpc.gcc glibc-2.1.2.new/db2/mutex/powerpc.gcc
--- glibc-2.1.2/db2/mutex/powerpc.gcc	Wed Dec 31 19:00:00 1969
+++ glibc-2.1.2.new/db2/mutex/powerpc.gcc	Tue Nov 30 22:54:56 1999
@@ -0,0 +1,22 @@
+/*
+ * PowerPC spinlock, adapted from the Alpha and m68k ones by dhd@debian.org
+ *
+ * For gcc/powerpc, 0 is clear, 1 is set (but *tsl will always be 0 since it's a char)
+ */
+#define TSL_SET(tsl) ({						\
+	register tsl_t *__l = (tsl);					\
+	register tsl_t __r1;						\
+	__asm__ volatile("						\n\
+	   10: lwarx  %0,0,%1						\n\
+	       cmpwi  %0,0						\n\
+	       bne+   20f						\n\
+	       stwcx. %2,0,%1						\n\
+	       bne-   10b						\n\
+	   20: "							\
+	  : "=&r" (__r1)						\
+	  : "r" (__l), "r" (-1) : "cr0", "memory");			\
+	!__r1;								\
+})
+
+#define	TSL_UNSET(tsl)	(*(tsl) = 0)
+#define	TSL_INIT(tsl)	TSL_UNSET(tsl)
diff -urN --exclude=*.info glibc-2.1.2/sysdeps/alpha/Makefile glibc-2.1.2.new/sysdeps/alpha/Makefile
--- glibc-2.1.2/sysdeps/alpha/Makefile	Sat Jun 27 02:50:41 1998
+++ glibc-2.1.2.new/sysdeps/alpha/Makefile	Sun Dec 12 03:36:34 1999
@@ -34,6 +34,10 @@
 CFLAGS-rtld.c = -mbuild-constants
 endif
 
+ifeq ($(subdir),db2)
+CPPFLAGS += -DHAVE_SPINLOCKS=1 -DHAVE_ASSEM_ALPHA_GCC=1 -DMUTEX_ALIGNMENT=4
+endif
+
 divrem := divl divq reml remq
 
 # For now, build everything with full IEEE math support.
diff -urN --exclude=*.info glibc-2.1.2/sysdeps/powerpc/Makefile glibc-2.1.2.new/sysdeps/powerpc/Makefile
--- glibc-2.1.2/sysdeps/powerpc/Makefile	Tue Sep  1 07:30:52 1998
+++ glibc-2.1.2.new/sysdeps/powerpc/Makefile	Sun Dec 12 03:43:15 1999
@@ -25,6 +25,10 @@
 CFLAGS-gmon-start.o = -G0
 endif
 
+ifeq ($(subdir),db2)
+CPPFLAGS += -DHAVE_SPINLOCKS=1 -DHAVE_ASSEM_POWERPC_GCC=1  -DMUTEX_ALIGNMENT=4
+endif
+
 ifeq ($(subdir),string)
 CFLAGS-memcmp.c += -Wno-uninitialized
 endif
--- glibc-2.1.2/db2/db_int.h	Mon Aug 31 11:57:53 1998
+++ glibc-2.1.2/db2/db_int.h.fixx0red	Tue Nov 30 23:47:25 1999
@@ -165,7 +165,9 @@
  * region.  This ensures the alignment is as returned by mmap(2), which should
  * be sufficient.  All other mutex users must ensure proper alignment locally.
  */
+#ifndef MUTEX_ALIGNMENT
 #define	MUTEX_ALIGNMENT	1
+#endif
 
 /*
  * The offset of a mutex in memory.

-- 
Joel Klecker (aka Espy)       <URL:mailto:espy@debian.org>
Debian Package Maintainer for the GNU C Library.

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

Re: DB_THREAD support in Berkeley DB/glibc

[David Edelsohn]

+/*
+ * PowerPC spinlock, adapted from the Alpha and m68k ones by dhd@debian.org
+ *
+ * For gcc/powerpc, 0 is clear, 1 is set (but *tsl will always be 0 since it's a char)
+ */
+#define TSL_SET(tsl) ({						\
+	register tsl_t *__l = (tsl);					\
+	register tsl_t __r1;						\
+	__asm__ volatile("						\n\
+	   10: lwarx  %0,0,%1						\n\
+	       cmpwi  %0,0						\n\
+	       bne+   20f						\n\
+	       stwcx. %2,0,%1						\n\
+	       bne-   10b						\n\
+	   20: "							\
+	  : "=&r" (__r1)						\
+	  : "r" (__l), "r" (-1) : "cr0", "memory");			\
+	!__r1;								\
+})
+
+#define	TSL_UNSET(tsl)	(*(tsl) = 0)
+#define	TSL_INIT(tsl)	TSL_UNSET(tsl)

	The TSL_SET macro is basically correct for PowerPC uniprocessor,
but it is not MP safe.  For cases where this needs to be safe across a
multiprocessor complex, it should be preceded by a "sync" instruction and
ended with an "isync" instruction, or something similar depending on the
semantics one uses for accessing the word.

	It is not clear to me why the TSL_UNSET macro is sufficient.

David
===============================================================================
David Edelsohn                                      T.J. Watson Research Center
dje@watson.ibm.com                                  P.O. Box 218
+1 914 945 4364 (TL 862)                            Yorktown Heights, NY 10598

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

Re: DB_THREAD support in Berkeley DB/glibc

[BenH]

On Tue, Dec 28, 1999, David Edelsohn <dje@watson.ibm.com> wrote:

>	The TSL_SET macro is basically correct for PowerPC uniprocessor,
>but it is not MP safe.  For cases where this needs to be safe across a
>multiprocessor complex, it should be preceded by a "sync" instruction and
>ended with an "isync" instruction, or something similar depending on the
>semantics one uses for accessing the word.

Also, according to some Moto writing I read some time ago, the
reservation should be cleared in both the good case and the fail case.
Basically, once the lwarx was done, the stwcx. should be done even if
results don't match. The suggested implementation, if I recall correctly,
is to first do a normal load and compare, and if it matches, then enter
the lwarx/stwcx. pair.


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

Re: DB_THREAD support in Berkeley DB/glibc

[Daniel Jacobowitz]

[-- Attachment #1: Type: text/plain, Size: 2105 bytes --]

I'm fixing this up right now...  From what I could see, the tsl_t is a
char but this accesses it as a long; dare I just assume that struct
alignment will do the right thing?  My current code conditionally sets
tsl_t to an unsigned long on powerpc, via sysdeps.

And no, UNSET is not sufficient, from what I can tell - at least on
SMP.

I used sync at both ends, by analogy to the mutexes for linuxthreads;
is this wrong/unnecessary?

Does this implementation look right?  I'm away from my powerpc at the
moment, so I haven't even been able to verify that it compiles.


On Tue, Dec 28, 1999 at 02:02:03PM -0500, David Edelsohn wrote:
> 
> +/*
> + * PowerPC spinlock, adapted from the Alpha and m68k ones by dhd@debian.org
> + *
> + * For gcc/powerpc, 0 is clear, 1 is set (but *tsl will always be 0 since it's a char)
> + */
> +#define TSL_SET(tsl) ({						\
> +	register tsl_t *__l = (tsl);					\
> +	register tsl_t __r1;						\
> +	__asm__ volatile("						\n\
> +	   10: lwarx  %0,0,%1						\n\
> +	       cmpwi  %0,0						\n\
> +	       bne+   20f						\n\
> +	       stwcx. %2,0,%1						\n\
> +	       bne-   10b						\n\
> +	   20: "							\
> +	  : "=&r" (__r1)						\
> +	  : "r" (__l), "r" (-1) : "cr0", "memory");			\
> +	!__r1;								\
> +})
> +
> +#define	TSL_UNSET(tsl)	(*(tsl) = 0)
> +#define	TSL_INIT(tsl)	TSL_UNSET(tsl)
> 
> 	The TSL_SET macro is basically correct for PowerPC uniprocessor,
> but it is not MP safe.  For cases where this needs to be safe across a
> multiprocessor complex, it should be preceded by a "sync" instruction and
> ended with an "isync" instruction, or something similar depending on the
> semantics one uses for accessing the word.
> 
> 	It is not clear to me why the TSL_UNSET macro is sufficient.


Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

[-- Attachment #2: mydb2.diff --]
[-- Type: text/plain, Size: 4549 bytes --]

diff -uNr db2.orig/config.h db2/config.h
--- db2.orig/config.h	Tue Jun  9 11:02:06 1998
+++ db2/config.h	Tue Dec 28 15:52:12 1999
@@ -66,6 +66,12 @@
 /* Define if you want to use sparc/gcc assembly spinlocks. */
 /* #undef HAVE_ASSEM_SPARC_GCC */
 
+/* Define if you want to use alpha/gcc assembly spinlocks. */
+/* #undef HAVE_ASSEM_ALPHA_GCC */
+
+/* Define if you want to use powerpc/gcc assembly spinlocks. */
+/* #undef HAVE_ASSEM_POWERPC_GCC */
+
 /* Define if you want to use uts4/cc assembly spinlocks. */
 /* #undef HAVE_ASSEM_UTS4_CC */
 
diff -uNr db2.orig/db_int.h db2/db_int.h
--- db2.orig/db_int.h	Mon Aug 31 11:57:53 1998
+++ db2/db_int.h	Tue Dec 28 15:55:05 1999
@@ -153,8 +153,11 @@
 /*******************************************************
  * Mutex support.
  *******************************************************/
+#ifdef SPINLOCK_TYPE
+typedef SPINLOCK_TYPE tsl_t;
+#else
 typedef unsigned char tsl_t;
-
+#endif
 
 
 /*
@@ -165,7 +168,10 @@
  * region.  This ensures the alignment is as returned by mmap(2), which should
  * be sufficient.  All other mutex users must ensure proper alignment locally.
  */
+
+#ifndef MUTEX_ALIGNMENT
 #define	MUTEX_ALIGNMENT	1
+#endif
 
 /*
  * The offset of a mutex in memory.
diff -uNr db2.orig/mutex/alpha.gcc db2/mutex/alpha.gcc
--- db2.orig/mutex/alpha.gcc	Wed Aug 27 15:32:54 1997
+++ db2/mutex/alpha.gcc	Tue Dec 28 15:52:12 1999
@@ -31,22 +31,23 @@
 	register tsl_t *__l = (tsl);					\
 	register tsl_t __r1, __r2;					\
 	__asm__ volatile("						\n\
-	   10: ldq_l %0,(%2)						\n\
+	   10: ldl_l %0,%3						\n\
 	       blbs  %0,30f						\n\
 	       or    %0,1,%1						\n\
-	       stq_c %1,(%2)						\n\
+	       stl_c %1,%2						\n\
 	       beq   %1,20f						\n\
 	       mb							\n\
 	       br    30f						\n\
 	   20: br    10b						\n\
 	   30: "							\
-	  : "=&r" (__r1), "=&r" (__r2)					\
-	  : "r" (__l));							\
+	  : "=&r" (__r1), "=&r" (__r2), "=m"(*__l)			\
+	  : "2" (*__l)							\
+	  : "memory");							\
 	!__r1;								\
 })
 
 #define TSL_UNSET(tsl) ({						\
 	register tsl_t *__l = (tsl);					\
-	__asm__ volatile("mb; stq $31,(%0);" : : "r" (__l));		\
+	__asm__ volatile("mb; stl $31,%0;" : "=m" (*__l) : : "memory");	\
 })
 #define	TSL_INIT(tsl)	TSL_UNSET(tsl)
diff -uNr db2.orig/mutex/mutex.c db2/mutex/mutex.c
--- db2.orig/mutex/mutex.c	Tue Jun  9 11:04:35 1998
+++ db2/mutex/mutex.c	Tue Dec 28 15:52:12 1999
@@ -86,6 +86,14 @@
 #include "sparc.gcc"
 #endif
 
+#ifdef HAVE_ASSEM_ALPHA_GCC
+#include "alpha.gcc"
+#endif
+
+#ifdef HAVE_ASSEM_POWERPC_GCC
+#include "powerpc.gcc"
+#endif
+
 #ifdef HAVE_ASSEM_UTS4_CC
 #define TSL_INIT(x)
 #define TSL_SET(x)	(!uts_lock(x, 1))
diff -uNr db2.orig/mutex/powerpc.gcc db2/mutex/powerpc.gcc
--- db2.orig/mutex/powerpc.gcc	Wed Dec 31 19:00:00 1969
+++ db2/mutex/powerpc.gcc	Tue Dec 28 16:57:31 1999
@@ -0,0 +1,31 @@
+/*
+ * PowerPC spinlock, adapted from the Alpha and m68k ones by dhd@debian.org
+ * and dan@debian.org.
+ *
+ * For gcc/powerpc, 0 is clear, 1 is set.
+ */
+#define TSL_SET(tsl) ({							\
+	register tsl_t *__l = (tsl);					\
+	register tsl_t __r1;						\
+	__asm__ volatile("						\n\
+	       sync							\n\
+	   10: lwarx  %0,0,%1						\n\
+	       cmpwi  %0,0						\n\
+	       bne+   20f						\n\
+	       stwcx. %2,0,%1						\n\
+	       bne-   10b						\n\
+	       sync							\n\
+	   20: "							\
+	  : "=&r" (__r1)						\
+	  : "r" (__l), "r" (1) : "cr0", "memory");			\
+	!__r1;								\
+})
+
+#define TSL_UNSET(tsl) ({						\
+	register tsl_t *__l = (tsl);					\
+	__asm__ __volatile__("						\n\
+		sync							\n\
+		stw	%1, %0" : "=&r" (__l) : "r" (0));		\
+	})
+
+#define	TSL_INIT(tsl)	TSL_UNSET(tsl)
diff -uNr sysdeps/powerpc.orig/Makefile sysdeps/powerpc/Makefile
--- sysdeps/powerpc.orig/Makefile	Tue Dec 28 15:50:56 1999
+++ sysdeps/powerpc/Makefile	Tue Dec 28 15:53:01 1999
@@ -25,6 +25,10 @@
 CFLAGS-gmon-start.o = -G0
 endif
 
+ifeq ($(subdir),db2)
+CPPFLAGS += -DHAVE_SPINLOCKS=1 -DHAVE_ASSEM_POWERPC_GCC=1 -DSPINLOCK_TYPE='unsigned long' -DMUTEX_ALIGNMENT=4
+endif
+
 ifeq ($(subdir),string)
 CFLAGS-memcmp.c += -Wno-uninitialized
 endif
diff -uNr sysdeps/alpha.orig/Makefile sysdeps/alpha/Makefile
--- sysdeps/alpha.orig/Makefile	Tue Dec 28 15:50:56 1999
+++ sysdeps/alpha/Makefile	Tue Dec 28 15:52:12 1999
@@ -34,6 +34,10 @@
 CFLAGS-rtld.c = -mbuild-constants
 endif
 
+ifeq ($(subdir),db2)
+CPPFLAGS += -DHAVE_SPINLOCKS=1 -DHAVE_ASSEM_ALPHA_GCC=1 -DMUTEX_ALIGNMENT=4
+endif
+
 divrem := divl divq reml remq
 
 # For now, build everything with full IEEE math support.

Re: DB_THREAD support in Berkeley DB/glibc

[David Edelsohn]

	The TSL_UNSET still does not look sufficient to me.  It needs to
use lwarx/stwcx as well:

#define TSL_UNSET(tsl) ({
	register tsl_t *__l = (tsl);
	register tsl_t __r1;
	__asm__ __volatile__ ("
	       sync
           10: lwarx   %0,0,%1
	       stwcx.  %2,0,%1
               bne-    10b
	       isync"
         : "=&r" (__r1) : "r" (__l), "r" (0));
        })

As I mentioned privately to David Huggins-Daines, the order I normally use
is: 1) sync, 2) perform the atomic update, 3) isync.  This ensures that
the cached copy of the memory location is consistent, performs the update,
and the ensures that no later instructions which depend on the atomicity
are moved ahead of the atomic operation.  I am not sure how that maps to
the Alpha "memory barrier" instruction as I have seen some discussion
about it on the Linux/PPC mailinglists in the past.  As long as all
threads using the macro sync first, there is should be no need to sync
after.

David

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

Re: DB_THREAD support in Berkeley DB/glibc

[Tony Mantler]

At 4:28 PM -0600 12/28/99, David Edelsohn wrote:
>	The TSL_UNSET still does not look sufficient to me.  It needs to
>use lwarx/stwcx as well:
>
>#define TSL_UNSET(tsl) ({
>	register tsl_t *__l = (tsl);
>	register tsl_t __r1;
>	__asm__ __volatile__ ("
>	       sync
>           10: lwarx   %0,0,%1
>	       stwcx.  %2,0,%1
>               bne-    10b
>	       isync"
>         : "=&r" (__r1) : "r" (__l), "r" (0));
>        })

Why? It would seem to me that the only time that atomic code would be
tripped is if the calling thread didn't have the lock when it tried to
clear it (umm, biiiig no-no), and a different thread tried to set the lock
at the same time.

I would agree with Daniel Jacobowitz's code, all that should be needed is a
sync and write for the unset.


Cheers - Tony :)


--
Tony Mantler         Renaissance Nerd Extraordinaire         eek@escape.ca
Winnipeg, Manitoba, Canada                       http://www.escape.ca/~eek


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

Re: DB_THREAD support in Berkeley DB/glibc

[Geoff Keating]

> Date: Tue, 28 Dec 1999 17:28:23 -0500
> From: David Edelsohn <dje@watson.ibm.com>
> 
> 	The TSL_UNSET still does not look sufficient to me.  It needs to
> use lwarx/stwcx as well:
> 
> #define TSL_UNSET(tsl) ({
> 	register tsl_t *__l = (tsl);
> 	register tsl_t __r1;
> 	__asm__ __volatile__ ("
> 	       sync
>            10: lwarx   %0,0,%1
> 	       stwcx.  %2,0,%1
>                bne-    10b
> 	       isync"
>          : "=&r" (__r1) : "r" (__l), "r" (0));
>         })
> 
> As I mentioned privately to David Huggins-Daines, the order I normally use
> is: 1) sync, 2) perform the atomic update, 3) isync.  This ensures that
> the cached copy of the memory location is consistent, performs the update,
> and the ensures that no later instructions which depend on the atomicity
> are moved ahead of the atomic operation.  I am not sure how that maps to
> the Alpha "memory barrier" instruction as I have seen some discussion
> about it on the Linux/PPC mailinglists in the past.  As long as all
> threads using the macro sync first, there is should be no need to sync
> after.

Hmmm.

I'm pretty sure the loop and lwarx/stwcx pair are unnecessary.  Stores
on ppc are atomic, and we're not taking any action based on the
previous value, so we can just use a normal store.  The store will
clear any reservations, although in the context of this code it
doesn't matter (because presumably only one thread will be unsetting
the lock).

Again, '__volatile__' does not imply a memory clobber, so we want to
do that instead.

We don't need 'isync', 'sync' will do just fine, and is faster.  We
are only concerned here with memory coherency.  In fact, 'isync' does
not imply 'sync' in a multiprocessor implementation; 'sync' does an
extra broadcast on the bus.  The PowerPC User's Manual says

  The sync instruction can be used to ensure that the result of all
  stores into a data structure, performed in a "critical section" of a
  program, are seen by other processors before the data structure is
  seen as unlocked.

We probably want 'sync' before and after, although it's probable the
'after' is unnecessary.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

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

Re: DB_THREAD support in Berkeley DB/glibc

[David Edelsohn]

	If you only are using the TSL_UNSET in the context that one
already has the lock, then the lwarx/stwcx are unnecessary.  What you have
written, however, is not a general atomic clear macro.

David

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

Re: DB_THREAD support in Berkeley DB/glibc

[David Edelsohn]

>>>>> Geoff Keating writes:

Geoff> We don't need 'isync', 'sync' will do just fine, and is faster.  We
Geoff> are only concerned here with memory coherency.  In fact, 'isync' does
Geoff> not imply 'sync' in a multiprocessor implementation; 'sync' does an
Geoff> extra broadcast on the bus.  The PowerPC User's Manual says

Geoff> The sync instruction can be used to ensure that the result of all
Geoff> stores into a data structure, performed in a "critical section" of a
Geoff> program, are seen by other processors before the data structure is
Geoff> seen as unlocked.

Geoff> We probably want 'sync' before and after, although it's probable the
Geoff> 'after' is unnecessary.

	"sync" is not faster; sync is a full context synchronization
instruction.  As I had mentioned to David, the necessity of a sync *after*
the store depends on the semantics of this programming model.  Maybe in
this context one should sync before acquiring the lock and then sync after
releasing the lock.

David

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

Re: DB_THREAD support in Berkeley DB/glibc

[Geoff Keating]

> Date: Tue, 28 Dec 1999 19:15:59 -0500
> From: David Edelsohn <dje@watson.ibm.com>

You were right about sync being slower than isync.  I expect
the difference is caused by sync needing to perform bus operations
where isync does not.

Anyway, they're not substitutes for each other; they do different
things, and in a given situation only one (or, possibly, both in
sequence) will be right.

> 	If you only are using the TSL_UNSET in the context that one
> already has the lock, then the lwarx/stwcx are unnecessary.  What you have
> written, however, is not a general atomic clear macro.

How is it not atomic?

The PUM says "With the exception of double-precision floating-point
accesses on 32-bit implementations, all aligned accesses are atomic."

-- 
- Geoffrey Keating <geoffk@cygnus.com>

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

Re: DB_THREAD support in Berkeley DB/glibc

[David Edelsohn]

>>>>> Geoff Keating writes:

>> If you only are using the TSL_UNSET in the context that one
>> already has the lock, then the lwarx/stwcx are unnecessary.  What you have
>> written, however, is not a general atomic clear macro.

Geoff> How is it not atomic?

	If this thread is the only one that can clear the cell, I think
that it is okay.  The store to acquire the lock also is atomic, but one
cannot simply store the value.  If the programming model allows contention
when clearing the word, one needs to use the lwarx/stwcx instructions.

David

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