Re: PPC should not use -fno-builtin (was Re: 2.3.47 imac build?)

Re: PPC should not use -fno-builtin (was Re: 2.3.47 imac build?)

[Paul Mackerras]

On Tue, 29 Feb 2000, Jeff Garzik wrote:

> That is the crux of the matter....   In the PPC arch, size_t is
> unconditionally the same whether you have a 32-bit or 64-bit procesor...

Well, no... unsigned long is 32 bits wide when compiling for 32-bit
machines, 64 bits wide when compiling for 64-bit machines.

Anyway, I have caved in and put the following ugliness in
asm-ppc/posix-types.h:

#include <linux/config.h>	/* for CONFIG_PPC64 */

[snip]

/* Grrr... gcc thinks size_t is unsigned int, so we either
   have to have this nonsense or use -fno-builtin. - paulus */
#ifdef CONFIG_PPC64
typedef unsigned long	__kernel_size_t;
typedef long		__kernel_ssize_t;
#else
typedef unsigned int	__kernel_size_t;
typedef int		__kernel_ssize_t;
#endif /* CONFIG_PPC64 */

My linuxcare.com.au::linux-pmac-devel rsync tree is now up to 2.3.48, BTW.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

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

Re: PPC should not use -fno-builtin (was Re: 2.3.47 imac build?)

[Michael Schmitz]

>
> My linuxcare.com.au::linux-pmac-devel rsync tree is now up to 2.3.48, BTW.

Fails to compile (drivers/char/n_tty.c uses asm/spinlock.h, should use
linux/spinlock.h perhaps). After forcing it, it fails to boot on Lombard.
The way it fails booting is a bit entertaining: using BootX 1.1.3, it will
show a little more than half a page of messages (arch_exit or similar in
the last), then starts drawing funny color fringes on the screen until I
reset. Using BootX 1.2b3, it locks up after the first six or so lines of
text (before getting to the early console output). 2.3.29 worked fine. Any
ideas?

Patch appended (adbmouse.o is only built if CONFIG_BUSMOUSE is set and
make complained about getting busmouse.o twice in the target line, so
there).

	Michael

--- 2.3.48-devel/drivers/char/Makefile.org	Tue Feb 29 17:52:59 2000
+++ 2.3.48-devel/drivers/char/Makefile	Tue Feb 29 16:42:32 2000
@@ -154,7 +154,7 @@
 obj-$(CONFIG_MIXCOMWD) += mixcomwd.o
 obj-$(CONFIG_AMIGAMOUSE) += amigamouse.o
 obj-$(CONFIG_ATARIMOUSE) += atarimouse.o
-obj-$(CONFIG_ADBMOUSE) += adbmouse.o busmouse.o
+obj-$(CONFIG_ADBMOUSE) += adbmouse.o
 obj-$(CONFIG_PC110_PAD) += pc110pad.o
 obj-$(CONFIG_WDT) += wdt.o
 obj-$(CONFIG_RTC) += rtc.o
--- 2.3.48-devel/drivers/char/n_tty.c.org	Mon Feb 28 11:56:43 2000
+++ 2.3.48-devel/drivers/char/n_tty.c	Tue Feb 29 14:57:35 2000
@@ -28,6 +28,7 @@
 #include <linux/errno.h>
 #include <linux/signal.h>
 #include <linux/fcntl.h>
+#include <linux/spinlock.h>
 #include <linux/sched.h>
 #include <linux/interrupt.h>
 #include <linux/tty.h>
@@ -42,7 +43,6 @@
 #include <asm/uaccess.h>
 #include <asm/system.h>
 #include <asm/bitops.h>
-#include <asm/spinlock.h>

 #define CONSOLE_DEV MKDEV(TTY_MAJOR,0)
 #define SYSCONS_DEV  MKDEV(TTYAUX_MAJOR,1)


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

Re: PPC should not use -fno-builtin (was Re: 2.3.47 imac build?)

[Jeff Garzik]

Michael Schmitz wrote:
> Patch appended (adbmouse.o is only built if CONFIG_BUSMOUSE is set and
> make complained about getting busmouse.o twice in the target line, so
> there).

Ignore the complaint, this patch is wrong.

With the "new-style" makefiles, adding busmouse.o to the end of the line
is the correct way to specify dependencies.  If your patch is applied, I
cannot build adbmouse into my kernel, as busmouse.o is never referenced
nor built.



> --- 2.3.48-devel/drivers/char/Makefile.org      Tue Feb 29 17:52:59 2000
> +++ 2.3.48-devel/drivers/char/Makefile  Tue Feb 29 16:42:32 2000
> @@ -154,7 +154,7 @@
>  obj-$(CONFIG_MIXCOMWD) += mixcomwd.o
>  obj-$(CONFIG_AMIGAMOUSE) += amigamouse.o
>  obj-$(CONFIG_ATARIMOUSE) += atarimouse.o
> -obj-$(CONFIG_ADBMOUSE) += adbmouse.o busmouse.o
> +obj-$(CONFIG_ADBMOUSE) += adbmouse.o
>  obj-$(CONFIG_PC110_PAD) += pc110pad.o
>  obj-$(CONFIG_WDT) += wdt.o
>  obj-$(CONFIG_RTC) += rtc.o

--
Jeff Garzik              | "Are you the police?"
Building 1024            |
MandrakeSoft, Inc.       | "No ma'am.  We're musicians."

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

Re: PPC should not use -fno-builtin (was Re: 2.3.47 imac build?)

[Benjamin Herrenschmidt]

On Tue, Feb 29, 2000, Michael Schmitz
<schmitz@opal.biophys.uni-duesseldorf.de> wrote:

>Fails to compile (drivers/char/n_tty.c uses asm/spinlock.h, should use
>linux/spinlock.h perhaps). After forcing it, it fails to boot on Lombard.
>The way it fails booting is a bit entertaining: using BootX 1.1.3, it will
>show a little more than half a page of messages (arch_exit or similar in
>the last), then starts drawing funny color fringes on the screen until I
>reset. Using BootX 1.2b3, it locks up after the first six or so lines of
>text (before getting to the early console output). 2.3.29 worked fine. Any
>ideas?

I think I know what's going on:

 - make sure setting the display BAT in arch/ppc/mm/init.c (MMU_Init) is
commented out, this is a hack and need some alignement tricks to work in
all cases. It should already be in #if 0/#endif

 - in arch/ppc/kernel/pmac_setup.c, comment out the content of the
function pmac_progress. (Or change pmac_init() so that it sets
ppc_md.progress to NULL, and set it to pmac_progress only pmac_setup_arch()).

The problem is that pmac_progress will try to print to the framebuffer at
a time where it's not mapped (MMU_Init).

I've hacked a fix which should be in the current bk tree.


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

Re: PPC should not use -fno-builtin (was Re: 2.3.47 imac build?)

[Michael Schmitz]

> >The way it fails booting is a bit entertaining: using BootX 1.1.3, it will
> >show a little more than half a page of messages (arch_exit or similar in
> >the last), then starts drawing funny color fringes on the screen until I
> >reset. Using BootX 1.2b3, it locks up after the first six or so lines of
> >text (before getting to the early console output). 2.3.29 worked fine. Any
> >ideas?
>
> I think I know what's going on:
>
>  - make sure setting the display BAT in arch/ppc/mm/init.c (MMU_Init) is
> commented out, this is a hack and need some alignement tricks to work in
> all cases. It should already be in #if 0/#endif

Check.

>  - in arch/ppc/kernel/pmac_setup.c, comment out the content of the
> function pmac_progress. (Or change pmac_init() so that it sets
> ppc_md.progress to NULL, and set it to pmac_progress only pmac_setup_arch()).

Tried both. I get the arch: exit if I set ppc_md.progress in pmac_setup
arch. Shortly after this output, the color fringe fun starts again.

I'll strip my .config to the bare minimum to narrow this down. Thanks for
getting me this far :-)

	Michael


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

Re: PPC should not use -fno-builtin (was Re: 2.3.47 imac build?)

[Andreas Tobler]

Michael Schmitz wrote:
>
> > >The way it fails booting is a bit entertaining: using BootX 1.1.3, it will
> > >show a little more than half a page of messages (arch_exit or similar in
> > >the last), then starts drawing funny color fringes on the screen until I
> > >reset. Using BootX 1.2b3, it locks up after the first six or so lines of
> > >text (before getting to the early console output). 2.3.29 worked fine. Any
> > >ideas?
> >
> > I think I know what's going on:
> >
> >  - make sure setting the display BAT in arch/ppc/mm/init.c (MMU_Init) is
> > commented out, this is a hack and need some alignement tricks to work in
> > all cases. It should already be in #if 0/#endif
>
> Check.
>
> >  - in arch/ppc/kernel/pmac_setup.c, comment out the content of the
> > function pmac_progress. (Or change pmac_init() so that it sets
> > ppc_md.progress to NULL, and set it to pmac_progress only pmac_setup_arch()).
>
> Tried both. I get the arch: exit if I set ppc_md.progress in pmac_setup
> arch. Shortly after this output, the color fringe fun starts again.
>
> I'll strip my .config to the bare minimum to narrow this down. Thanks for
> getting me this far :-)
Well, I wanted to reply earlier, but unfortunately my telco dropped my
line for two hours and I was thinking about having destroied my modems
until I had a look to my /var/log/messages arghhhh.

What I did: I have both trees living around on my PB. I did a diff
against the linux-pmac-devel/arch/ppc and patched the missing things. I
know a bit dangerous, but it did the trick. It's not only the things Ben
mentioned, also the drawx vs. prom_drawx are necessary I think. So it
boots on an Wallstreet I, AND on an ancient pm7200!!

I may post a patch, but I'm not quite satiesfied with since I don't know
at all what's really necessary. Sorry, but I think it's better not to
distribute a wrong patch.

Andreas

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

Re: PPC should not use -fno-builtin (was Re: 2.3.47 imac build?)

[Michael Schmitz]

> > Tried both. I get the arch: exit if I set ppc_md.progress in pmac_setup
> > arch. Shortly after this output, the color fringe fun starts again.
> >
> > I'll strip my .config to the bare minimum to narrow this down. Thanks for
> > getting me this far :-)
> Well, I wanted to reply earlier, but unfortunately my telco dropped my
> line for two hours and I was thinking about having destroied my modems
> until I had a look to my /var/log/messages arghhhh.
>
> What I did: I have both trees living around on my PB. I did a diff

Which trees? Unfortunatly I removed 2.3.29 before I could test 2.3.48 ...

> I may post a patch, but I'm not quite satiesfied with since I don't know
> at all what's really necessary. Sorry, but I think it's better not to
> distribute a wrong patch.

Just tell me which files you had to patch :-) I'll start poking around in
drivers/video first. It seems like other parts of the kernel are fine
(sound is switched on, the disk spins up) and it's just atyfb acting
funny.

	Michael


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