anyone build 2.3.42 for ppc?

anyone build 2.3.42 for ppc?

[Brad Parker]

I am trying to build 2.3.42 for ppc and I'm running into problems.
(like "dma_addr_t" missing from include/asm-ppc/types.h).

Does that patch that just came by fix this or should I assume it just
needs fixing?

-brad


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

Re: anyone build 2.3.42 for ppc?

[Martin Costabel]

Brad Parker wrote:
>
> I am trying to build 2.3.42 for ppc and I'm running into problems.
> (like "dma_addr_t" missing from include/asm-ppc/types.h).
>
> Does that patch that just came by fix this or should I assume it just
> needs fixing?

Works for me. It fixes this and a couple of other things.

--
Martin

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

Re: anyone build 2.3.42 for ppc?

[Chas Williams]

i needed to apply the following to fix nvram access:

--- drivers/char/misc.c.000     Fri Feb  4 18:00:52 2000
+++ drivers/char/misc.c Fri Feb  4 18:03:43 2000
@@ -72,6 +72,7 @@
 extern int rtc_DP8570A_init(void);
 extern int rtc_MK48T08_init(void);
 extern int dsp56k_init(void);
+extern int nvram_init(void);
 extern int radio_init(void);
 extern int pc110pad_init(void);
 extern int pmu_device_init(void);
@@ -207,6 +208,9 @@
 #endif
 #ifdef CONFIG_ATARI_DSP56K
        dsp56k_init();
+#endif
+#ifdef CONFIG_NVRAM
+       nvram_init();
 #endif
 #ifdef CONFIG_MISC_RADIO
        radio_init();

i also saw another problem i chrp_setup.c, and i believe this is the correct
fix but have no way to test it.

--- arch/ppc/kernel/chrp_setup.c.000    Fri Feb  4 17:14:16 2000
+++ arch/ppc/kernel/chrp_setup.c        Fri Feb  4 17:14:27 2000
@@ -394,7 +394,7 @@
         * We do it this way since our irq_desc[irq].handler can change
         * with RTL and no longer be open_pic -- Cort
         */
-       if ( irq >= open_pic.irq_offset)
+       if ( irq >= open_pic_irq_offset)
                openpic_eoi( smp_processor_id() );
 }

@@ -411,7 +411,7 @@
                        (*(unsigned long *)get_property(np,
                                                        "8259-interrupt-acknowle
dge", NULL));
        }
-       open_pic.irq_offset = 16;
+       open_pic_irq_offset = 16;
        for ( i = 16 ; i < NR_IRQS ; i++ )
                irq_desc[i].handler = &open_pic;
        openpic_init(1);

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

Re: anyone build 2.3.42 for ppc?

[Jeff Garzik]

On Fri, 4 Feb 2000, Chas Williams wrote:

>
> i needed to apply the following to fix nvram access:
>
> --- drivers/char/misc.c.000     Fri Feb  4 18:00:52 2000
> +++ drivers/char/misc.c Fri Feb  4 18:03:43 2000
> @@ -72,6 +72,7 @@
>  extern int rtc_DP8570A_init(void);
>  extern int rtc_MK48T08_init(void);
>  extern int dsp56k_init(void);
> +extern int nvram_init(void);
>  extern int radio_init(void);
>  extern int pc110pad_init(void);
>  extern int pmu_device_init(void);
> @@ -207,6 +208,9 @@
>  #endif
>  #ifdef CONFIG_ATARI_DSP56K
>         dsp56k_init();
> +#endif
> +#ifdef CONFIG_NVRAM
> +       nvram_init();
>  #endif
>  #ifdef CONFIG_MISC_RADIO
>         radio_init();

This patch is wrong.  I fixed nvram to use initcalls.

If nvram doesn't load you have other problems.

	Jeff


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

Re: anyone build 2.3.42 for ppc?

[Chas Williams]

In message <Pine.LNX.3.96.1000204232520.15802L-100000@mandrakesoft.mandrakesoft
.com>,Jeff Garzik writes:
>This patch is wrong.  I fixed nvram to use initcalls.
>If nvram doesn't load you have other problems.

i think is see what you are saying, look at this:

./drivers/char/nvram.c:static int __init nvram_init(void)
./drivers/char/nvram.c:module_init(nvram_init);
./drivers/macintosh/nvram.c:int nvram_init(void)
./drivers/macintosh/nvram.c:        return( nvram_init() );

i guess the nvram_init() in macintosh/nvram.c needs the __init declaration
then?

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

Re: anyone build 2.3.42 for ppc?

[Chas Williams]

>In message <Pine.LNX.3.96.1000204232520.15802L-100000@mandrakesoft.mandrakesoft.com>,Jeff Garzik writes:
>This patch is wrong.  I fixed nvram to use initcalls.
>If nvram doesn't load you have other problems.

ok, i see the problem, with __initcall, which is missing in
drivers/macintosh/nvram.c, so this patch is more correct, however it still
doesnt work after making this change.  i believe the reason is ld related,
when vmlinux is linked, __initcall_nvram_init resides in macintosh.a along
with another initcall function, __initcall_adb_init.  after linking
vmlinux only contains __initcall_adb_init:

% nm drivers/macintosh/macintosh.a | egrep initcall
00000000 ? __initcall_adb_init
00000000 ? __initcall_nvram_init

% nm vmlinux | egrep initcall
c0259068 ? __initcall_adb_init
c0259060 ? __initcall_adb_mouse_init
c0259044 ? __initcall_bdflush_init
c0259070 A __initcall_end
c025905c ? __initcall_ide_cdrom_init
c0259058 ? __initcall_init_autofs_fs
c025904c ? __initcall_init_elf_binfmt
c0259054 ? __initcall_init_ext2_fs
c0259048 ? __initcall_init_script_binfmt
c0259040 ? __initcall_kswapd_init
c0259050 ? __initcall_partition_setup
c0259064 ? __initcall_pci_proc_init
c0259040 A __initcall_start
c023166c t do_initcalls

i changed the makefile to list drivers/macintosh/nvram.o during the link
stage (after macintosh.a but that probbaly doesnt matter), and
__initcall_nvram_init found its way into the executable.

this leads me to believe that ld cannot merge the muliple initcall's
from a library.  my ld version is 2.9.4 so i dont think its a tool
'problem'.  the right way to fix this would be to list the various
bits of macintosh.a seperately during link?

here is the patch to add initcall it macintosh/nvram.c:

--- drivers/macintosh/nvram.c.000       Sat Feb  5 08:43:10 2000
+++ drivers/macintosh/nvram.c   Sat Feb  5 09:12:39 2000
@@ -102,14 +102,17 @@
        &nvram_fops
 };

-int nvram_init(void)
+int __init nvram_init(void)
 {
        printk(KERN_INFO "Macintosh non-volatile memory driver v%s\n",
                NVRAM_VERSION);
        misc_register(&nvram_dev);
        return 0;
 }
-#ifdef MODULE
+
+#ifndef MODULE
+__initcall(nvram_init);
+#else
 int init_module (void)
 {
         return( nvram_init() );

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

Re: anyone build 2.3.42 for ppc?

[Jeff Garzik]

Chas Williams wrote:
>
> >In message <Pine.LNX.3.96.1000204232520.15802L-100000@mandrakesoft.mandrakesoft.com>,Jeff Garzik writes:
> >This patch is wrong.  I fixed nvram to use initcalls.
> >If nvram doesn't load you have other problems.
>
> ok, i see the problem, with __initcall, which is missing in
> drivers/macintosh/nvram.c, so this patch is more correct, however it still
> doesnt work after making this change.  i believe the reason is ld related,
> when vmlinux is linked, __initcall_nvram_init resides in macintosh.a along
> with another initcall function, __initcall_adb_init.  after linking
> vmlinux only contains __initcall_adb_init:

Ah!  The solution:  follow the example in other makefiles, and create
'macintosh.o' not 'macintosh.a'.  That is the only problem...

initcall gets removed during link if you use an 'ar' library.  This is
why some of the core subsystems have been changed from 'ar' to 'ld
-r'...  As this change stops the elimination of dead code, you must
ensure that no dead code exists by virtue of a bug-free Makefile and
Config.in system.

--
Jeff Garzik         | See you at Linux Expo in Paris!
Building 1024       |
MandrakeSoft, Inc.  |

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

Re: anyone build 2.3.42 for ppc?

[Chas Williams]

In message <389C6ABF.1138CC1B@mandrakesoft.com>,Jeff Garzik writes:
>Ah!  The solution:  follow the example in other makefiles, and create
>'macintosh.o' not 'macintosh.a'.  That is the only problem...

ok then, the patch that 'correctly' adds nvram support back into 2.3.42
would look more like:

--- Makefile.000	Sat Feb  5 14:28:42 2000
+++ Makefile	Sat Feb  5 14:28:53 2000
@@ -203,7 +203,7 @@
 endif

 ifdef CONFIG_PPC
-DRIVERS := $(DRIVERS) drivers/macintosh/macintosh.a
+DRIVERS := $(DRIVERS) drivers/macintosh/macintosh.o
 endif

 ifeq ($(CONFIG_ISAPNP),y)
--- drivers/macintosh/Makefile.000	Sat Feb  5 14:25:10 2000
+++ drivers/macintosh/Makefile	Sat Feb  5 14:44:01 2000
@@ -12,16 +12,16 @@
 SUB_DIRS     :=
 MOD_SUB_DIRS := $(SUB_DIRS)

-L_TARGET := macintosh.a
-L_OBJS   :=
+O_TARGET := macintosh.o
+O_OBJS   :=
 M_OBJS   :=

 ifeq ($(CONFIG_PMAC_PBOOK),y)
-  L_OBJS += mediabay.o
+  O_OBJS += mediabay.o
 endif

 ifeq ($(CONFIG_MAC_SERIAL),y)
-  L_OBJS += macserial.o
+  O_OBJS += macserial.o
 else
   ifeq ($(CONFIG_MAC_SERIAL),m)
     M_OBJS += macserial.o
@@ -29,7 +29,7 @@
 endif

 ifeq ($(CONFIG_NVRAM),y)
-  L_OBJS += nvram.o
+  O_OBJS += nvram.o
 else
   ifeq ($(CONFIG_NVRAM),m)
     M_OBJS += nvram.o
@@ -37,35 +37,35 @@
 endif

 ifdef CONFIG_ADB
-  LX_OBJS  := adb.o
+  OX_OBJS  := adb.o
 endif

 ifdef CONFIG_ADB_KEYBOARD
-  L_OBJS += mac_keyb.o
+  O_OBJS += mac_keyb.o
 endif

 ifdef CONFIG_ADB_MACII
-  L_OBJS += via-macii.o
+  O_OBJS += via-macii.o
 endif

 ifdef CONFIG_ADB_MACIISI
-  L_OBJS += via-maciisi.o
+  O_OBJS += via-maciisi.o
 endif

 ifdef CONFIG_ADB_CUDA
-  L_OBJS += via-cuda.o
+  O_OBJS += via-cuda.o
 endif

 ifdef CONFIG_ADB_IOP
-  L_OBJS += adb-iop.o
+  O_OBJS += adb-iop.o
 endif

 ifdef CONFIG_ADB_PMU
-  L_OBJS += via-pmu.o
+  O_OBJS += via-pmu.o
 endif

 ifdef CONFIG_ADB_MACIO
-  L_OBJS += macio-adb.o
+  O_OBJS += macio-adb.o
 endif

 include $(TOPDIR)/Rules.make
--- drivers/macintosh/nvram.c.000	Sat Feb  5 08:43:10 2000
+++ drivers/macintosh/nvram.c	Sat Feb  5 09:12:39 2000
@@ -102,14 +102,17 @@
 	&nvram_fops
 };

-int nvram_init(void)
+int __init nvram_init(void)
 {
 	printk(KERN_INFO "Macintosh non-volatile memory driver v%s\n",
 		NVRAM_VERSION);
 	misc_register(&nvram_dev);
 	return 0;
 }
-#ifdef MODULE
+
+#ifndef MODULE
+__initcall(nvram_init);
+#else
 int init_module (void)
 {
         return( nvram_init() );

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

Re: anyone build 2.3.42 for ppc?

[Brad Midgley]

you guys are having great luck. i haven't been able to get past

In file included from init/main.c:33:
/usr/src/linux/include/linux/pci.h:318: parse error before `dma_addr_t'
/usr/src/linux/include/linux/pci.h:318: warning: no semicolon at end of struct or union
/usr/src/linux/include/linux/pci.h:346: parse error before `}'

this is the plain common_config on an rs/6000. using gcc 2.95.2, glibc
2.1.3-0j.

Brad
brad@turbolinux.com | http://www.turbolinux.com/~brad/


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

Re: anyone build 2.3.42 for ppc?

[Martin Costabel]

Brad Midgley wrote:
>
> you guys are having great luck. i haven't been able to get past
>
> In file included from init/main.c:33:
> /usr/src/linux/include/linux/pci.h:318: parse error before `dma_addr_t'
> /usr/src/linux/include/linux/pci.h:318: warning: no semicolon at end of struct or union
> /usr/src/linux/include/linux/pci.h:346: parse error before `}'
>
> this is the plain common_config on an rs/6000. using gcc 2.95.2, glibc
> 2.1.3-0j.

But you *did* apply AJoshi's patch which includes the line
typedef u32 dma_addr_t;
into /include/asm-ppc/types.h and several #include <linux/types.h> at
various places, didn't you?

--
Martin

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

Re: anyone build 2.3.42 for ppc?

[Dan Burcaw]

Brad,

Take a look at Ani's 2.3.42 patch. I believe it fixes this.

>
> you guys are having great luck. i haven't been able to get past
>
> In file included from init/main.c:33:
> /usr/src/linux/include/linux/pci.h:318: parse error before `dma_addr_t'
> /usr/src/linux/include/linux/pci.h:318: warning: no semicolon at end of struct or union
> /usr/src/linux/include/linux/pci.h:346: parse error before `}'
>
> this is the plain common_config on an rs/6000. using gcc 2.95.2, glibc
> 2.1.3-0j.

Regards,
Dan

Terra Soft Solutions, Inc.
 Yellow Dog Linux
 "The Ultimate Companion for a Dedicated Server"
 http://www.yellowdoglinux.com/

 Black Lab Linux
 Advanced Workstations and Parallel Solutions
 http://www.blacklablinux.com/


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