linuxsh-dev

Re: GCC-4 problems

[Mike F. <va...@ge...>]

On Saturday 07 July 2007, Manuel Lauss wrote:
> Manuel Lauss wrote:
> > Did that, it still complains:
> > arch/sh/kernel/built-in.o:(__ksymtab+0xa8): undefined reference to
> > `__sdivsi3_i4i' arch/sh/kernel/built-in.o:(__ksymtab+0xb0): undefined
> > reference to `__udiv_qrnnd_16'
> > arch/sh/kernel/built-in.o:(__ksymtab+0xb8): undefined reference to
> > `__udivsi3_i4i'
> >
> > ...and the "-m4-nofpu" option is unsupported again ;-)
> >
> > I'm going to try with vanilla binutils next...
>
> and that didn't change anything either.  So the question is what gcc
> version and patches is everyone else using where the above mentioned
> symbols ARE exported?

maybe some fundamental checks first ... how are you invoking crossdev ?  ca=
n=20
you post the output of `sh4-unknown-linux-gnu-gcc -v` ?
=2Dmike

Re: GCC-4 problems

[Manuel L. <ma...@ro...>]

Manuel Lauss wrote:
> Mike Frysinger wrote:
>> On Saturday 07 July 2007, Manuel Lauss wrote:
>>> Paul Mundt wrote:
>>>> On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
>>>>> Also, these exports need to be removed from sh_ksyms.c, they give
>>>>> "undefined reference" errors:
>>>>> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
>>>> Ok, so removing these seems to be have created fallout all over the
>>>> place. Apparently it's just your GCC4 that seems to have problems with
>>>> these symbols, whereas the other ones really seem to want them. It looks
>>> Oh, sorry, that wasn't my intention at all.
>>>
>>>> like we're going to have to narrow it down to the exact release in which
>>>> they vanished (I would guess 4.1.2, since 4.1.1 still wants them).
>>>>
>>>> akpm also suggests he has a 3.4.5 toolchain that needs these, which is
>>>> also very unusual. Do you have a tarball of your compiler somewhere so
>>>> it's easier to debug?
>>> Prompted by your mail I reverted commit
>>> 9c5b406b9a857a67caf778f096bfc7f4e6b0401a and GCC builds the kernel
>>> just fine now; the only difference is that I've upgraded from 4.1.1 to
>>> 4.1.2 in the meantime.
> 
> That was bogus; I was compiling the wrong local tree again.
> 
>>> Compiler is made with Gentoo's "crossdev" tool, which AFAICT is vanilla
>>> 4.1.2 with a few bugfix patches applied (+ PR29599 fix for me)
>>> (see http://gentoo.inode.at/distfiles/gcc-4.1.2-patches-1.0.1.tar.bz2)
>>>
>>> I can rebuild gcc-4.1.1 which failed for me if you like.
>> ruh roh ... someone said Gentoo ;)
>>
>> default gcc-4.x in Gentoo enables multilib for SuperH targets akin to gcc-3.x 
>> (since vanilla gcc-4.x does not include nofpu support by default)
>>
>> to doubly verify, you can emerge gcc with USE=vanilla ... that'll disable the 
>> Gentoo patchset ...
> 
> Did that, it still complains:
> arch/sh/kernel/built-in.o:(__ksymtab+0xa8): undefined reference to `__sdivsi3_i4i'
> arch/sh/kernel/built-in.o:(__ksymtab+0xb0): undefined reference to `__udiv_qrnnd_16'
> arch/sh/kernel/built-in.o:(__ksymtab+0xb8): undefined reference to `__udivsi3_i4i'
> 
> ...and the "-m4-nofpu" option is unsupported again ;-)
> 
> I'm going to try with vanilla binutils next...

and that didn't change anything either.  So the question is what gcc version and
patches is everyone else using where the above mentioned symbols ARE exported?

Thanks,
	Manuel Lauss

Re: GCC-4 problems

[Manuel L. <ma...@ro...>]

Mike Frysinger wrote:
> On Saturday 07 July 2007, Manuel Lauss wrote:
>> Paul Mundt wrote:
>>> On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
>>>> Also, these exports need to be removed from sh_ksyms.c, they give
>>>> "undefined reference" errors:
>>>> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
>>> Ok, so removing these seems to be have created fallout all over the
>>> place. Apparently it's just your GCC4 that seems to have problems with
>>> these symbols, whereas the other ones really seem to want them. It looks
>> Oh, sorry, that wasn't my intention at all.
>>
>>> like we're going to have to narrow it down to the exact release in which
>>> they vanished (I would guess 4.1.2, since 4.1.1 still wants them).
>>>
>>> akpm also suggests he has a 3.4.5 toolchain that needs these, which is
>>> also very unusual. Do you have a tarball of your compiler somewhere so
>>> it's easier to debug?
>> Prompted by your mail I reverted commit
>> 9c5b406b9a857a67caf778f096bfc7f4e6b0401a and GCC builds the kernel
>> just fine now; the only difference is that I've upgraded from 4.1.1 to
>> 4.1.2 in the meantime.

That was bogus; I was compiling the wrong local tree again.

>> Compiler is made with Gentoo's "crossdev" tool, which AFAICT is vanilla
>> 4.1.2 with a few bugfix patches applied (+ PR29599 fix for me)
>> (see http://gentoo.inode.at/distfiles/gcc-4.1.2-patches-1.0.1.tar.bz2)
>>
>> I can rebuild gcc-4.1.1 which failed for me if you like.
> 
> ruh roh ... someone said Gentoo ;)
> 
> default gcc-4.x in Gentoo enables multilib for SuperH targets akin to gcc-3.x 
> (since vanilla gcc-4.x does not include nofpu support by default)
> 
> to doubly verify, you can emerge gcc with USE=vanilla ... that'll disable the 
> Gentoo patchset ...

Did that, it still complains:
arch/sh/kernel/built-in.o:(__ksymtab+0xa8): undefined reference to `__sdivsi3_i4i'
arch/sh/kernel/built-in.o:(__ksymtab+0xb0): undefined reference to `__udiv_qrnnd_16'
arch/sh/kernel/built-in.o:(__ksymtab+0xb8): undefined reference to `__udivsi3_i4i'

...and the "-m4-nofpu" option is unsupported again ;-)

I'm going to try with vanilla binutils next...

Thanks,
	Manuel Lauss

Re: GCC-4 problems

[Mike F. <va...@ge...>]

On Saturday 07 July 2007, Manuel Lauss wrote:
> Paul Mundt wrote:
> > On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
> >> Also, these exports need to be removed from sh_ksyms.c, they give
> >> "undefined reference" errors:
> >> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
> >
> > Ok, so removing these seems to be have created fallout all over the
> > place. Apparently it's just your GCC4 that seems to have problems with
> > these symbols, whereas the other ones really seem to want them. It looks
>
> Oh, sorry, that wasn't my intention at all.
>
> > like we're going to have to narrow it down to the exact release in which
> > they vanished (I would guess 4.1.2, since 4.1.1 still wants them).
> >
> > akpm also suggests he has a 3.4.5 toolchain that needs these, which is
> > also very unusual. Do you have a tarball of your compiler somewhere so
> > it's easier to debug?
>
> Prompted by your mail I reverted commit
> 9c5b406b9a857a67caf778f096bfc7f4e6b0401a and GCC builds the kernel
> just fine now; the only difference is that I've upgraded from 4.1.1 to
> 4.1.2 in the meantime.
>
> Compiler is made with Gentoo's "crossdev" tool, which AFAICT is vanilla
> 4.1.2 with a few bugfix patches applied (+ PR29599 fix for me)
> (see http://gentoo.inode.at/distfiles/gcc-4.1.2-patches-1.0.1.tar.bz2)
>
> I can rebuild gcc-4.1.1 which failed for me if you like.

ruh roh ... someone said Gentoo ;)

default gcc-4.x in Gentoo enables multilib for SuperH targets akin to gcc-3=
=2Ex=20
(since vanilla gcc-4.x does not include nofpu support by default)

to doubly verify, you can emerge gcc with USE=3Dvanilla ... that'll disable=
 the=20
Gentoo patchset ...
=2Dmike

Re: GCC-4 problems

[Manuel L. <ma...@ro...>]

Paul Mundt wrote:
> On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
>> Also, these exports need to be removed from sh_ksyms.c, they give
>> "undefined reference" errors:
>> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
>>
> Ok, so removing these seems to be have created fallout all over the
> place. Apparently it's just your GCC4 that seems to have problems with
> these symbols, whereas the other ones really seem to want them. It looks

Oh, sorry, that wasn't my intention at all.

> like we're going to have to narrow it down to the exact release in which
> they vanished (I would guess 4.1.2, since 4.1.1 still wants them).
> 
> akpm also suggests he has a 3.4.5 toolchain that needs these, which is
> also very unusual. Do you have a tarball of your compiler somewhere so
> it's easier to debug?

Prompted by your mail I reverted commit
9c5b406b9a857a67caf778f096bfc7f4e6b0401a and GCC builds the kernel
just fine now; the only difference is that I've upgraded from 4.1.1 to 4.1.2
in the meantime.

Compiler is made with Gentoo's "crossdev" tool, which AFAICT is vanilla
4.1.2 with a few bugfix patches applied (+ PR29599 fix for me)
(see http://gentoo.inode.at/distfiles/gcc-4.1.2-patches-1.0.1.tar.bz2)

I can rebuild gcc-4.1.1 which failed for me if you like.

Thank you,

	Manuel Lauss

Re: GCC-4 problems

[Paul M. <pau...@re...>]

On Mon, Mar 19, 2007 at 09:27:57AM +0100, Manuel Lauss wrote:
> Also, these exports need to be removed from sh_ksyms.c, they give
> "undefined reference" errors:
> __sdivsi3_i4i __udiv_qrnnd_16 __udivsi3_i4i
> 
Ok, so removing these seems to be have created fallout all over the
place. Apparently it's just your GCC4 that seems to have problems with
these symbols, whereas the other ones really seem to want them. It looks
like we're going to have to narrow it down to the exact release in which
they vanished (I would guess 4.1.2, since 4.1.1 still wants them).

akpm also suggests he has a 3.4.5 toolchain that needs these, which is
also very unusual. Do you have a tarball of your compiler somewhere so
it's easier to debug?

RE: Irq priorities

[Carmelo S. <lin...@st...>]

On our 7109 board we exported the symbol set_intc2_irq_priority_mod from the
kernel file arch/sh/kernel/cpu/irq/intc2.c so that the driver can set its
own interrupt priority. However it is better to have only one entry point
for setting all of them so that it would make it easy to tune the system
during the final stage of the integration. 
Lino.
  


-----Original Message-----
From: lin...@li...
[mailto:lin...@li...] On Behalf Of Paul Mundt
Sent: Friday, July 06, 2007 10:48 AM
To: EXTERNAL Brunner Markus (Praktikant; ST-FIR/Eng)
Cc: lin...@li...
Subject: Re: Irq priorities

On Wed, Jun 27, 2007 at 02:56:39PM +0200, EXTERNAL Brunner Markus
(Praktikant;  ST-FIR/Eng) wrote:
> I have a question about the priority for the irqs. 
> I found that the priorities for the other CPUs, set in the setup-sh*.c
> are set as followed:
> low priority (2) for timers
> low priority (3) for sci(f) 
> high priority (7) for dma
> This doesn't make sens to me. I would give timers a high priority, so
> they keep acurate and dma a low priority. 
> 
> Are there any rules for setting the priority for interrupts? 
> 
Not really. I suppose we should add an abstraction to the hardirq
framework for setting the IRQ priority, as other platforms care too. I
still have some patches for this floating around from way back when, so
I'll dig those up and see what the other architecture folks think.

It's traditionally been kept in the platform setup code so the system
integrator can decide which priority levels to ship with for their
application. Pushing it down to the drivers might help for the cases
where we _know_ we can tolerate a low priority on the IRQ. We just don't
want to run in to the situation where everyone sets their IRQ to the
highest priority and weird things start happening with the more important
peripherals.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linuxsh-dev mailing list
lin...@li...
https://lists.sourceforge.net/lists/listinfo/linuxsh-dev

Re: 2.6.22-rc7

[Paul M. <pau...@re...>]

On Fri, Jul 06, 2007 at 01:10:02AM +0900, Paul Mundt wrote:
> On Sun, Jul 01, 2007 at 11:45:47PM +0100, Adrian McMenamin wrote:
> > Builds and boots on the Dreamcast. Familiar warnings about the _init
> > mismatches on the build, but runs fine
> > 
> Current git should have all of the machvec mismatches resolved, so it
> should just be the pvr2fb bits that are outstanding.
> 
This should do it. A bit larger since I fixed up some of the whitespace
damage as I was going through it. Works for me.

--

commit e9705a77f50c1fd52356f4f0e515455273aae416
Author: Paul Mundt <le...@li...>
Date:   Sat Jul 7 03:38:51 2007 +0900

    fb: pvr2fb: Fix up section mismatch warnings.
    
    A few minor things were broken here. fix and var screeninfo should have
    been __devinitdata, board_list[] gets renamed to board_driver[] so the
    modpost matching does the right thing, and we properly discard some of
    the unused exit sections.
    
    Signed-off-by: Paul Mundt <le...@li...>

diff --git a/drivers/video/pvr2fb.c b/drivers/video/pvr2fb.c
index df2909a..1b06ff5 100644
--- a/drivers/video/pvr2fb.c
+++ b/drivers/video/pvr2fb.c
@@ -147,16 +147,16 @@ static struct pvr2fb_par {
 
 static struct fb_info *fb_info;
 
-static struct fb_fix_screeninfo pvr2_fix __initdata = {
+static struct fb_fix_screeninfo pvr2_fix __devinitdata = {
 	.id =		"NEC PowerVR2",
-	.type = 	FB_TYPE_PACKED_PIXELS,
-	.visual = 	FB_VISUAL_TRUECOLOR,
+	.type =		FB_TYPE_PACKED_PIXELS,
+	.visual =	FB_VISUAL_TRUECOLOR,
 	.ypanstep =	1,
 	.ywrapstep =	1,
-	.accel = 	FB_ACCEL_NONE,
+	.accel =	FB_ACCEL_NONE,
 };
 
-static struct fb_var_screeninfo pvr2_var __initdata = {
+static struct fb_var_screeninfo pvr2_var __devinitdata = {
 	.xres =		640,
 	.yres =		480,
 	.xres_virtual =	640,
@@ -195,10 +195,6 @@ static unsigned int shdma = PVR2_CASCADE_CHAN;
 static unsigned int pvr2dma = ONCHIP_NR_DMA_CHANNELS;
 #endif
 
-/* Interface used by the world */
-
-int pvr2fb_setup(char*);
-
 static int pvr2fb_setcolreg(unsigned int regno, unsigned int red, unsigned int green, unsigned int blue,
                             unsigned int transp, struct fb_info *info);
 static int pvr2fb_blank(int blank, struct fb_info *info);
@@ -227,7 +223,7 @@ static struct fb_ops pvr2fb_ops = {
 #ifdef CONFIG_SH_DMA
 	.fb_write	= pvr2fb_write,
 #endif
-	.fb_fillrect 	= cfb_fillrect,
+	.fb_fillrect	= cfb_fillrect,
 	.fb_copyarea	= cfb_copyarea,
 	.fb_imageblit	= cfb_imageblit,
 };
@@ -252,7 +248,7 @@ static struct fb_videomode pvr2_modedb[] __initdata = {
 	/* 640x480 @ 60hz (VGA) */
 	"vga_640x480", 60, 640, 480, VGA_CLK, 38, 33, 0, 18, 146, 26,
 	0, FB_VMODE_YWRAP
-    }, 
+    },
 };
 
 #define NUM_TOTAL_MODES  ARRAY_SIZE(pvr2_modedb)
@@ -293,7 +289,7 @@ static void set_color_bitfields(struct fb_var_screeninfo *var)
 {
 	switch (var->bits_per_pixel) {
 	    case 16:        /* RGB 565 */
-	    	pvr2fb_set_pal_type(PAL_RGB565);
+		pvr2fb_set_pal_type(PAL_RGB565);
 		var->red.offset = 11;    var->red.length = 5;
 		var->green.offset = 5;   var->green.length = 6;
 		var->blue.offset = 0;    var->blue.length = 5;
@@ -306,7 +302,7 @@ static void set_color_bitfields(struct fb_var_screeninfo *var)
 		var->transp.offset = 0;  var->transp.length = 0;
 		break;
 	    case 32:        /* ARGB 8888 */
-	    	pvr2fb_set_pal_type(PAL_ARGB8888);
+		pvr2fb_set_pal_type(PAL_ARGB8888);
 		var->red.offset = 16;    var->red.length = 8;
 		var->green.offset = 8;   var->green.length = 8;
 		var->blue.offset = 0;    var->blue.length = 8;
@@ -379,13 +375,13 @@ static int pvr2fb_set_par(struct fb_info *info)
 	var->vmode &= FB_VMODE_MASK;
 	if (var->vmode & FB_VMODE_INTERLACED && video_output != VO_VGA)
 		par->is_interlaced = 1;
-	/* 
+	/*
 	 * XXX: Need to be more creative with this (i.e. allow doublecan for
 	 * PAL/NTSC output).
 	 */
 	if (var->vmode & FB_VMODE_DOUBLE && video_output == VO_VGA)
 		par->is_doublescan = 1;
-	
+
 	par->hsync_total = var->left_margin + var->xres + var->right_margin +
 	                   var->hsync_len;
 	par->vsync_total = var->upper_margin + var->yres + var->lower_margin +
@@ -408,7 +404,7 @@ static int pvr2fb_set_par(struct fb_info *info)
 	} else {
 		/* VGA mode */
 		/* XXX: What else needs to be checked? */
-		/* 
+		/*
 		 * XXX: We have a little freedom in VGA modes, what ranges
 		 * should be here (i.e. hsync/vsync totals, etc.)?
 		 */
@@ -419,8 +415,8 @@ static int pvr2fb_set_par(struct fb_info *info)
 	/* Calculate the remainding offsets */
 	par->diwstart_h = par->borderstart_h + var->left_margin;
 	par->diwstart_v = par->borderstart_v + var->upper_margin;
-	par->borderstop_h = par->diwstart_h + var->xres + 
-			    var->right_margin;    
+	par->borderstop_h = par->diwstart_h + var->xres +
+			    var->right_margin;
 	par->borderstop_v = par->diwstart_v + var->yres +
 			    var->lower_margin;
 
@@ -465,12 +461,12 @@ static int pvr2fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
 	set_color_bitfields(var);
 
 	if (var->vmode & FB_VMODE_YWRAP) {
-		if (var->xoffset || var->yoffset < 0 || 
+		if (var->xoffset || var->yoffset < 0 ||
 		    var->yoffset >= var->yres_virtual) {
 			var->xoffset = var->yoffset = 0;
 		} else {
 			if (var->xoffset > var->xres_virtual - var->xres ||
-		    	    var->yoffset > var->yres_virtual - var->yres || 
+			    var->yoffset > var->yres_virtual - var->yres ||
 			    var->xoffset < 0 || var->yoffset < 0)
 				var->xoffset = var->yoffset = 0;
 		}
@@ -478,7 +474,7 @@ static int pvr2fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
 		var->xoffset = var->yoffset = 0;
 	}
 
-	/* 
+	/*
 	 * XXX: Need to be more creative with this (i.e. allow doublecan for
 	 * PAL/NTSC output).
 	 */
@@ -507,7 +503,7 @@ static int pvr2fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
 		var->vsync_len    = par->borderstop_v +
 				   (par->vsync_total - par->borderstop_v);
 	}
-		
+
 	hsync_total = var->left_margin + var->xres + var->right_margin +
 		      var->hsync_len;
 	vtotal = var->upper_margin + var->yres + var->lower_margin +
@@ -531,7 +527,7 @@ static int pvr2fb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
 			}
 		}
 	}
-	
+
 	/* Check memory sizes */
 	line_length = get_line_length(var->xres_virtual, var->bits_per_pixel);
 	if (line_length * var->yres_virtual > info->fix.smem_len)
@@ -552,7 +548,7 @@ static void pvr2_update_display(struct fb_info *info)
 	          DISP_DIWADDRS);
 }
 
-/* 
+/*
  * Initialize the video mode.  Currently, the 16bpp and 24bpp modes aren't
  * very stable.  It's probably due to the fact that a lot of the 2D video
  * registers are still undocumented.
@@ -592,18 +588,18 @@ static void pvr2_init_display(struct fb_info *info)
 	/* display window start position */
 	fb_writel(par->diwstart_h, DISP_DIWHSTRT);
 	fb_writel((par->diwstart_v << 16) | par->diwstart_v, DISP_DIWVSTRT);
-	
+
 	/* misc. settings */
 	fb_writel((0x16 << 16) | par->is_lowres, DISP_DIWCONF);
 
 	/* clock doubler (for VGA), scan doubler, display enable */
-	fb_writel(((video_output == VO_VGA) << 23) | 
+	fb_writel(((video_output == VO_VGA) << 23) |
 	          (par->is_doublescan << 1) | 1, DISP_DIWMODE);
 
 	/* bits per pixel */
 	fb_writel(fb_readl(DISP_DIWMODE) | (--bytesperpixel << 2), DISP_DIWMODE);
 
-	/* video enable, color sync, interlace, 
+	/* video enable, color sync, interlace,
 	 * hsync and vsync polarity (currently unused) */
 	fb_writel(0x100 | ((par->is_interlaced /*|4*/) << 4), DISP_SYNCCONF);
 }
@@ -657,7 +653,7 @@ static irqreturn_t pvr2fb_interrupt(int irq, void *dev_id)
 static int pvr2_init_cable(void)
 {
 	if (cable_type < 0) {
-		fb_writel((fb_readl(PCTRA) & 0xfff0ffff) | 0x000a0000, 
+		fb_writel((fb_readl(PCTRA) & 0xfff0ffff) | 0x000a0000,
 	                  PCTRA);
 		cable_type = (fb_readw(PDTRA) >> 8) & 3;
 	}
@@ -687,7 +683,7 @@ static ssize_t pvr2fb_write(struct fb_info *info, const char *buf,
 	pages = kmalloc(nr_pages * sizeof(struct page *), GFP_KERNEL);
 	if (!pages)
 		return -ENOMEM;
-	
+
 	down_read(&current->mm->mmap_sem);
 	ret = get_user_pages(current, current->mm, (unsigned long)buf,
 			     nr_pages, WRITE, 0, pages, NULL);
@@ -700,7 +696,7 @@ static ssize_t pvr2fb_write(struct fb_info *info, const char *buf,
 	}
 
 	dma_configure_channel(shdma, 0x12c1);
-	
+
 	dst   = (unsigned long)fb_info->screen_base + *ppos;
 	start = (unsigned long)page_address(pages[0]);
 	end   = (unsigned long)page_address(pages[nr_pages]);
@@ -744,7 +740,7 @@ out_unmap:
 	kfree(pages);
 
 	return ret;
-} 
+}
 #endif /* CONFIG_SH_DMA */
 
 /**
@@ -772,14 +768,14 @@ static int __init pvr2fb_common_init(void)
 
 	fb_info->screen_base = ioremap_nocache(pvr2_fix.smem_start,
 					       pvr2_fix.smem_len);
-	
+
 	if (!fb_info->screen_base) {
 		printk(KERN_ERR "pvr2fb: Failed to remap smem space\n");
 		goto out_err;
 	}
 
 	par->mmio_base = (unsigned long)ioremap_nocache(pvr2_fix.mmio_start,
-					 		pvr2_fix.mmio_len);
+							pvr2_fix.mmio_len);
 	if (!par->mmio_base) {
 		printk(KERN_ERR "pvr2fb: Failed to remap mmio space\n");
 		goto out_err;
@@ -820,7 +816,7 @@ static int __init pvr2fb_common_init(void)
 	printk("fb%d: %s (rev %ld.%ld) frame buffer device, using %ldk/%ldk of video memory\n",
 	       fb_info->node, fb_info->fix.id, (rev >> 4) & 0x0f, rev & 0x0f,
 	       modememused >> 10, (unsigned long)(fb_info->fix.smem_len >> 10));
-	printk("fb%d: Mode %dx%d-%d pitch = %ld cable: %s video output: %s\n", 
+	printk("fb%d: Mode %dx%d-%d pitch = %ld cable: %s video output: %s\n",
 	       fb_info->node, fb_info->var.xres, fb_info->var.yres,
 	       fb_info->var.bits_per_pixel,
 	       get_line_length(fb_info->var.xres, fb_info->var.bits_per_pixel),
@@ -878,8 +874,8 @@ static int __init pvr2fb_dc_init(void)
 			video_output = VO_NTSC;
 		}
 	}
-	
-	/* 
+
+	/*
 	 * Nothing exciting about the DC PVR2 .. only a measly 8MiB.
 	 */
 	pvr2_fix.smem_start	= 0xa5000000;	/* RAM starts here */
@@ -903,7 +899,7 @@ static int __init pvr2fb_dc_init(void)
 	return pvr2fb_common_init();
 }
 
-static void pvr2fb_dc_exit(void)
+static void __exit pvr2fb_dc_exit(void)
 {
 	if (fb_info->screen_base) {
 		iounmap(fb_info->screen_base);
@@ -987,7 +983,7 @@ static int __init pvr2fb_pci_init(void)
 	return pci_register_driver(&pvr2fb_pci_driver);
 }
 
-static void pvr2fb_pci_exit(void)
+static void __exit pvr2fb_pci_exit(void)
 {
 	pci_unregister_driver(&pvr2fb_pci_driver);
 }
@@ -1021,7 +1017,7 @@ static int __init pvr2_get_param(const struct pvr2_params *p, const char *s,
  */
 
 #ifndef MODULE
-int __init pvr2fb_setup(char *options)
+static int __init pvr2fb_setup(char *options)
 {
 	char *this_opt;
 	char cable_arg[80];
@@ -1061,7 +1057,7 @@ static struct pvr2_board {
 	int (*init)(void);
 	void (*exit)(void);
 	char name[16];
-} board_list[] = {
+} board_driver[] = {
 #ifdef CONFIG_SH_DREAMCAST
 	{ pvr2fb_dc_init, pvr2fb_dc_exit, "Sega DC PVR2" },
 #endif
@@ -1071,7 +1067,7 @@ static struct pvr2_board {
 	{ 0, },
 };
 
-int __init pvr2fb_init(void)
+static int __init pvr2fb_init(void)
 {
 	int i, ret = -ENODEV;
 	int size;
@@ -1095,8 +1091,8 @@ int __init pvr2fb_init(void)
 
 	currentpar = (struct pvr2fb_par *)(fb_info + 1);
 
-	for (i = 0; i < ARRAY_SIZE(board_list); i++) {
-		struct pvr2_board *pvr_board = board_list + i;
+	for (i = 0; i < ARRAY_SIZE(board_driver); i++) {
+		struct pvr2_board *pvr_board = board_driver + i;
 
 		if (!pvr_board->init)
 			continue;
@@ -1118,13 +1114,13 @@ static void __exit pvr2fb_exit(void)
 {
 	int i;
 
-	for (i = 0; i < ARRAY_SIZE(board_list); i++) {
-		struct pvr2_board *pvr_board = board_list + i;
+	for (i = 0; i < ARRAY_SIZE(board_driver); i++) {
+		struct pvr2_board *pvr_board = board_driver + i;
 
 		if (pvr_board->exit)
 			pvr_board->exit();
 	}
-		
+
 #ifdef CONFIG_SH_STORE_QUEUES
 	sq_unmap(pvr2fb_map);
 #endif
@@ -1139,4 +1135,3 @@ module_exit(pvr2fb_exit);
 MODULE_AUTHOR("Paul Mundt <le...@li...>, M. R. Brown <mr...@0x...>");
 MODULE_DESCRIPTION("Framebuffer driver for NEC PowerVR 2 based graphics boards");
 MODULE_LICENSE("GPL");
-

Re: Irq priorities

[Paul M. <pau...@re...>]

On Wed, Jun 27, 2007 at 02:56:39PM +0200, EXTERNAL Brunner Markus (Praktikant;  ST-FIR/Eng) wrote:
> I have a question about the priority for the irqs. 
> I found that the priorities for the other CPUs, set in the setup-sh*.c
> are set as followed:
> low priority (2) for timers
> low priority (3) for sci(f) 
> high priority (7) for dma
> This doesn't make sens to me. I would give timers a high priority, so
> they keep acurate and dma a low priority. 
> 
> Are there any rules for setting the priority for interrupts? 
> 
Not really. I suppose we should add an abstraction to the hardirq
framework for setting the IRQ priority, as other platforms care too. I
still have some patches for this floating around from way back when, so
I'll dig those up and see what the other architecture folks think.

It's traditionally been kept in the platform setup code so the system
integrator can decide which priority levels to ship with for their
application. Pushing it down to the drivers might help for the cases
where we _know_ we can tolerate a low priority on the IRQ. We just don't
want to run in to the situation where everyone sets their IRQ to the
highest priority and weird things start happening with the more important
peripherals.

Re: Device Drivers for SH devices

[Paul M. <pau...@re...>]

On Sat, Jul 07, 2007 at 02:25:00AM +0900, Paul Mundt wrote:
> On Fri, Jul 06, 2007 at 01:20:04PM +0200, EXTERNAL Brunner Markus (Praktikant;  ST-FIR/Eng) wrote:
> > I have drivers for the following SH7720 onchip devices, but only for 2.4
> > usb-host, which was based on the generic usb-ohci.c
> > usb-gadget, is also listet on the usb-gadget site, but seems to be 2.4
> > only
> > LCD controller (found nowhere else)
> > 
> > Does anybody know if there are recent versions of these drivers?
> > 
> The USB drivers I don't know about, there's always been very little in
> the way of feedback from people actually using these things on the older
> parts. I've added Shimoda-san to the CC, perhaps he has some ideas about
> USB support on SH7720.
> 
Err, now I have ;-)

Re: Conflicting types for '__div64_32'

[Paul M. <pau...@re...>]

On Thu, Jun 21, 2007 at 09:45:51PM +0900, Paul Mundt wrote:
> On Thu, Jun 21, 2007 at 07:34:19PM +0900, Katsuya MATSUBARA wrote:
> >  I found an inconsistent declaration
> >  in arch/sh/lib/div-generic.c in 2.6.21.
> > 
> >  the function 'div64_32()' in arch/sh/lib/div64-generic.c
> >  returns a value of u64 type,
> >  but the declaration of that function is
> > 
> >  extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
> >         ^^^^^^^^
> >  in include/asm-generic/div64.h
> >  (which is referred by include/asm-sh/div64.h).
> > 
> Yes, div64_32() should be uint32_t, the result is passed back in r0, so
> the u64 thing is pointless. I'll queue up a patch, but probably won't get
> around to looking at it until after OLS.
> 
Pushed out a fix to current git.

Re: Device Drivers for SH devices

[Paul M. <pau...@re...>]

On Fri, Jul 06, 2007 at 01:20:04PM +0200, EXTERNAL Brunner Markus (Praktikant;  ST-FIR/Eng) wrote:
> I have drivers for the following SH7720 onchip devices, but only for 2.4
> usb-host, which was based on the generic usb-ohci.c
> usb-gadget, is also listet on the usb-gadget site, but seems to be 2.4
> only
> LCD controller (found nowhere else)
> 
> Does anybody know if there are recent versions of these drivers?
> 
The USB drivers I don't know about, there's always been very little in
the way of feedback from people actually using these things on the older
parts. I've added Shimoda-san to the CC, perhaps he has some ideas about
USB support on SH7720.

As for the LCD controller, there are quite a few various implementations
floating around. You might look at something like hitfb to see if you're
able to adapt it for your needs. Porting a 2.4 framebuffer driver to 2.6
is not a lot of work, and those are fairly trivial to merge, the main
thing to remember is that a lot of parts have rather similar controllers,
albeit occasionally with a few differences that make code-sharing more
problematic.

> I also had the smsc9115 ethernet controller working in 2.4 with the sh3
> driver from the smsc homepage. There is a SMSC911X driver in 2.6, but it
> is only for Xscale (ARCH_PXA), has anybody already portet it on SH? 
> STLinux has a 2.6 port of the driver from SMSC included in their kernel,
> but a driver, already in vanilla would be nice.
> 
Use smc91x, it's in use by most of the solution engine boards, the
sh4-202 microdev, and numerous others.

On Fri, Jul 06, 2007 at 04:50:22PM +0200, Manuel Lauss wrote:
> Free drivers for recent Linux kernels are almost non-existant;
> fortunately the datasheets are quite good (compared to other embedded SoCs I'm
> working with..) and writing linux drivers isn't that hard ;-)
> 
This largely goes back to the point that most vendors snapshot an ancient
kernel, focus their product development there, and then toss out a
tarball so they're compliant with the letter of the license.
Surprisingly, this doesn't actually help anyone, and so while we're
easily able to hunt down numerous antiquated drivers in various states of
disarray, it does require a bit of a push or at least rudimentary support
from the vendor in order to get this stuff merged.

We've too often had the situation where a vendor has submitted some
platform code and drivers, it's been merged, and then they're never heard
from again. This leads to a maintenance nightmare, and it's really just
not worth the trouble. This is getting better for some platforms and some
drivers, but it's still something that needs quite a bit of work.

It comes down to development methodology. So, if people want drivers for
their platforms integrated, do your development on a current kernel, work
with community developers rather than against them, and then pull those
back in to your snapshotted product tree rather than trying to push them
out after the fact. If folks can't do that, don't expect to see many
drivers in mainline.

Re: linux-sh wiki down ?

[Paul M. <pau...@re...>]

On Thu, Jul 05, 2007 at 09:36:46AM +0200, Alexis Polti wrote:
>    The linux-sh wiki (http://www.linux-sh.org/) seems to be unavailable 
> for several weeks now. Is it available at another location ? Or is there 
> any backup ?
> 
Conveniently it fell over right after I left for OLS, and as I'm still
traveling, I haven't had a chance to bring it back online. I'll be back
in Japan on the 11th, so it should be back up then.

Re: 2.6.22-rc7

[Paul M. <pau...@re...>]

On Sun, Jul 01, 2007 at 11:45:47PM +0100, Adrian McMenamin wrote:
> Builds and boots on the Dreamcast. Familiar warnings about the _init
> mismatches on the build, but runs fine
> 
Current git should have all of the machvec mismatches resolved, so it
should just be the pvr2fb bits that are outstanding.

Re: Device Drivers for SH devices

[Manuel L. <ma...@ro...>]

Hi,

> I'm looking for drivers for the sh3 onchip devices. I have only scif
> functional by now in 2.6. Most of the onchip devices were supportet in
> 2.4, but the drivers were never in vanilla.
> 
> I have drivers for the following SH7720 onchip devices, but only for 2.4
> usb-host, which was based on the generic usb-ohci.c
> usb-gadget, is also listet on the usb-gadget site, but seems to be 2.4
> only
> LCD controller (found nowhere else)
> 
> Does anybody know if there are recent versions of these drivers?

Free drivers for recent Linux kernels are almost non-existant;
fortunately the datasheets are quite good (compared to other embedded SoCs I'm
working with..) and writing linux drivers isn't that hard ;-)

That said, did you have a look at the CE-Linux tree(s)?

> I also had the smsc9115 ethernet controller working in 2.4 with the sh3
> driver from the smsc homepage. There is a SMSC911X driver in 2.6, but it
> is only for Xscale (ARCH_PXA), has anybody already portet it on SH? 

Have a look at the smc91x.h which works in similar ways:
in theory you have to add something like this (if your board
has the chip on a 16bit bus) to the smc911x.h file:

#ifdef CONFIG_MY_SH_BOARD
#define SMC_USE_16BIT	1
#endif

Then register a platform device for the "smc911x" device with appropriate
MMIO and IRQ in the board setup code.


	Manuel Lauss

Re: linuxsh-dev Digest, Vol 38, Issue 3

[Kristoffer E. <kri...@gm...>]

Paul is away for another couple of days, he will surely fix that once he
gets back. (Also for all the people wondering why there's no reply to
questions)

2007/7/5, lin...@li... <
lin...@li...>:
>
> Send linuxsh-dev mailing list submissions to
>         lin...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
> or, via email, send a message with subject or body 'help' to
>         lin...@li...
>
> You can reach the person managing the list at
>         lin...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of linuxsh-dev digest..."
>
>
> Today's Topics:
>
>    1. linux-sh wiki down ? (Alexis Polti)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 05 Jul 2007 09:36:46 +0200
> From: Alexis Polti <po...@en...>
> Subject: linux-sh wiki down ?
> To: linux-sh <lin...@li...>
> Message-ID: <468...@en...>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Hello !
>
>    The linux-sh wiki (http://www.linux-sh.org/) seems to be unavailable
> for several weeks now. Is it available at another location ? Or is there
> any backup ?
>
> Thanx,
>
> Alexis
>
>
>
>
> ------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
>
> ------------------------------
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>
>
> End of linuxsh-dev Digest, Vol 38, Issue 3
> ******************************************
>

Device Drivers for SH devices

[EXTERNAL B. M. (P. ST-FIR/Eng) <ext...@de...>]

Hi,

I'm looking for drivers for the sh3 onchip devices. I have only scif
functional by now in 2.6. Most of the onchip devices were supportet in
2.4, but the drivers were never in vanilla.

I have drivers for the following SH7720 onchip devices, but only for 2.4
usb-host, which was based on the generic usb-ohci.c
usb-gadget, is also listet on the usb-gadget site, but seems to be 2.4
only
LCD controller (found nowhere else)

Does anybody know if there are recent versions of these drivers?

I also had the smsc9115 ethernet controller working in 2.4 with the sh3
driver from the smsc homepage. There is a SMSC911X driver in 2.6, but it
is only for Xscale (ARCH_PXA), has anybody already portet it on SH?=20
STLinux has a 2.6 port of the driver from SMSC included in their kernel,
but a driver, already in vanilla would be nice.

Regards

Markus

linux-sh wiki down ?

[Alexis P. <po...@en...>]

Hello !

   The linux-sh wiki (http://www.linux-sh.org/) seems to be unavailable 
for several weeks now. Is it available at another location ? Or is there 
any backup ?

Thanx,

Alexis

Early printk problem

[EXTERNAL B. M. (P. ST-FIR/Eng) <ext...@de...>]

Hi there,

Still porting 2.6.22 to run on SH7720. I have a problem getting early
printk running.

Because of the "early_param" macro at the end of early_printk.c,
setup_early_printk should get invoked by=20
parse_early_param in setup.c if the kernel command line contains
earlyprintk=3D.
However it won't get called on my system. I put a ctrl_outb in
setup_early_printk, which switches on a led, but nothing happend.

Any ideas? Can anybody confirm that early_printk works in 2.6.22-rc{5,7}
?

Regards

Markus

Ps: Luckily I managed to get "late" printk working and was able to fix
an Oops which led to a kernel panic. So Linux 2.6 runs on SH7720 now.=20

2.6.22-rc7

[Adrian M. <ad...@ne...>]

Builds and boots on the Dreamcast. Familiar warnings about the _init
mismatches on the build, but runs fine

Re: sh section mismatches [was Re: 2.6.22-rc6 on Dreamcast (SH4)]

[Adrian M. <ad...@ne...>]

On Sat, 2007-06-30 at 19:50 +0530, Satyam Sharma wrote:
> Hi,

> Right, as Mike just said, these warnings are the ones from
> drivers/video/pvr2fb.c which the patch didn't touch ... that was only
> to get rid of the "(between 'mv_dreamcast' and 'systemasic_int')"
> warning. But of course, we can't be too sure about the patch till
> you can boot and run the system ...


Boots and runs fine.

Re: sh section mismatches [was Re: 2.6.22-rc6 on Dreamcast (SH4)]

[Adrian M. <ad...@ne...>]

On Sat, 2007-06-30 at 09:58 -0400, Mike Frysinger wrote:

> sure it did ... his patch was to address just the stuff in arch/sh/, not the 
> pvr video driver, and your output shows that it is working
> -mike

good point :)

Re: sh section mismatches [was Re: 2.6.22-rc6 on Dreamcast (SH4)]

[Mike F. <va...@ge...>]

On Saturday 30 June 2007, Adrian McMenamin wrote:
> On Thu, 2007-06-28 at 17:27 +0530, Satyam Sharma wrote:
> > Hi,
> >
> > > On Monday 25 June 2007, Adrian McMenamin wrote:
> > > > Still getting this:
> > > >
> > > >  MODPOST vmlinux
> > > > WARNING: arch/sh/boards/dreamcast/built-in.o(.data+0x0): Section
> > > > mismatch: reference to .init.text: (between 'mv_dreamcast' and
> > > > 'systemasic_int')
> >
> > I had sent a patch for this earlier ... Adrian, did you try (build + bo=
ot
> > + testrun) with it? Does this one go away (and system executes fine)?
> >
> > [ http://lkml.org/lkml/diff/2007/6/23/116/1 ]
> >
> > [ This has to do with __init functions calling __initmv functions in a
> > zillion files in arch/sh/boards/.../setup.c which is problematic when
> > __initmv is not __init itself (!SH_GENERIC && !SH_UNKNOWN) ]
> >
> > > > WARNING: drivers/built-in.o(.text+0x168e0): Section mismatch:
> > > > reference to .init.data: (between 'pvr2fb_check_var' and
> > > > 'pvr2fb_interrupt') WARNING: drivers/built-in.o(.text+0x1701c):
> > > > Section mismatch: reference to .init.data: (between
> > > > 'pvr2fb_pci_probe' and 'read_mem')
> > > > WARNING: drivers/built-in.o(.text+0x17024): Section mismatch:
> > > > reference to .init.text: (between 'pvr2fb_pci_probe' and 'read_mem')
> > > > WARNING: drivers/built-in.o(.data+0x738): Section mismatch: referen=
ce
> > > > to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')
> > > > WARNING: drivers/built-in.o(.data+0x750): Section mismatch: referen=
ce
> > > > to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')
> >
> > drivers/video/pvr2fb.c is a mess with __init, __initdata, __devinit and
> > __devinitdata (__exit and __devexit variants for good measure) all being
> > used and referencing each other freely ... I have no idea what function
> > should actually be what. Sam normally knows about such things,
> > adding him to Cc: list.
>
> Finally got around to applying this patch, but it doesn't fix the
> problem...

sure it did ... his patch was to address just the stuff in arch/sh/, not th=
e=20
pvr video driver, and your output shows that it is working
=2Dmike

Re: sh section mismatches [was Re: 2.6.22-rc6 on Dreamcast (SH4)]

[Adrian M. <ad...@ne...>]

On Thu, 2007-06-28 at 17:27 +0530, Satyam Sharma wrote:
> Hi,
> 
> > On Monday 25 June 2007, Adrian McMenamin wrote:
> > > Still getting this:
> > >
> > >  MODPOST vmlinux
> > > WARNING: arch/sh/boards/dreamcast/built-in.o(.data+0x0): Section
> > > mismatch: reference to .init.text: (between 'mv_dreamcast' and
> > > 'systemasic_int')
> 
> I had sent a patch for this earlier ... Adrian, did you try (build + boot +
> testrun) with it? Does this one go away (and system executes fine)?
> 
> [ http://lkml.org/lkml/diff/2007/6/23/116/1 ]
> 
> [ This has to do with __init functions calling __initmv functions in a
> zillion files in arch/sh/boards/.../setup.c which is problematic when
> __initmv is not __init itself (!SH_GENERIC && !SH_UNKNOWN) ]
> 
> > > WARNING: drivers/built-in.o(.text+0x168e0): Section mismatch: reference
> > > to .init.data: (between 'pvr2fb_check_var' and 'pvr2fb_interrupt')
> > > WARNING: drivers/built-in.o(.text+0x1701c): Section mismatch: reference
> > > to .init.data: (between 'pvr2fb_pci_probe' and 'read_mem')
> > > WARNING: drivers/built-in.o(.text+0x17024): Section mismatch: reference
> > > to .init.text: (between 'pvr2fb_pci_probe' and 'read_mem')
> > > WARNING: drivers/built-in.o(.data+0x738): Section mismatch: reference
> > > to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')
> > > WARNING: drivers/built-in.o(.data+0x750): Section mismatch: reference
> > > to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')
> 
> drivers/video/pvr2fb.c is a mess with __init, __initdata, __devinit and
> __devinitdata (__exit and __devexit variants for good measure) all being
> used and referencing each other freely ... I have no idea what function
> should actually be what. Sam normally knows about such things,
> adding him to Cc: list.
> 

Finally got around to applying this patch, but it doesn't fix the
problem...

adrian@bossclass:~/linux-2.6.21$ patch -p1 <section.patch 
patching file arch/sh/boards/dreamcast/setup.c
patching file arch/sh/boards/hp6xx/setup.c
patching file arch/sh/boards/landisk/setup.c
patching file arch/sh/boards/mpc1211/setup.c
patching file arch/sh/boards/renesas/hs7751rvoip/setup.c
patching file arch/sh/boards/renesas/r7780rp/setup.c
patching file arch/sh/boards/renesas/rts7751r2d/setup.c
patching file arch/sh/boards/se/7343/setup.c
patching file arch/sh/boards/se/770x/setup.c
patching file arch/sh/boards/se/7722/setup.c
patching file arch/sh/boards/se/7780/setup.c
patching file arch/sh/boards/sh03/setup.c
patching file arch/sh/boards/snapgear/setup.c
patching file arch/sh/boards/superh/microdev/setup.c
adrian@bossclass:~/linux-2.6.21$ make ARCH=sh
CROSS_COMPILE=/home/adrian/buildroot/build_sh4/staging_dir/bin/sh4-linux- modules zImage -j3  
  SYMLINK include/asm-sh/cpu -> include/asm-sh/cpu-sh4
  SYMLINK include/asm-sh/mach -> include/asm-sh/dreamcast
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
make[1]: `include/asm-sh/machtypes.h' is up to date.
  CALL    scripts/checksyscalls.sh
  CHK     include/linux/compile.h
  CC      arch/sh/boards/dreamcast/setup.o
  LD      arch/sh/boards/dreamcast/built-in.o
  GEN     .version
  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      .tmp_vmlinux1
  KSYM    .tmp_kallsyms1.S
  AS      .tmp_kallsyms1.o
  LD      .tmp_vmlinux2
  KSYM    .tmp_kallsyms2.S
  AS      .tmp_kallsyms2.o
  LD      vmlinux
  SYSMAP  System.map
  SYSMAP  .tmp_System.map
  MODPOST vmlinux
WARNING: drivers/built-in.o(.text+0x168e0): Section mismatch: reference
to .init.data: (between 'pvr2fb_check_var' and 'pvr2fb_interrupt')
WARNING: drivers/built-in.o(.text+0x1701c): Section mismatch: reference
to .init.data: (between 'pvr2fb_pci_probe' and 'read_mem')
WARNING: drivers/built-in.o(.text+0x17024): Section mismatch: reference
to .init.text: (between 'pvr2fb_pci_probe' and 'read_mem')
WARNING: drivers/built-in.o(.data+0x738): Section mismatch: reference
to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')
WARNING: drivers/built-in.o(.data+0x750): Section mismatch: reference
to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')
  Building modules, stage 2.
  MODPOST 14 modules
  OBJCOPY arch/sh/boot/compressed/vmlinux.bin
  GZIP    arch/sh/boot/compressed/vmlinux.bin.gz
  LD      arch/sh/boot/compressed/piggy.o
  LD      arch/sh/boot/compressed/vmlinux
  OBJCOPY arch/sh/boot/zImage
  Kernel: arch/sh/boot/zImage is ready

Re: 2.6.22-rc6 on Dreamcast (SH4)

[Mike F. <va...@ge...>]

On Monday 25 June 2007, Adrian McMenamin wrote:
> Still getting this:
>
>  MODPOST vmlinux
> WARNING: arch/sh/boards/dreamcast/built-in.o(.data+0x0): Section
> mismatch: reference to .init.text: (between 'mv_dreamcast' and
> 'systemasic_int')
> WARNING: drivers/built-in.o(.text+0x168e0): Section mismatch: reference
> to .init.data: (between 'pvr2fb_check_var' and 'pvr2fb_interrupt')
> WARNING: drivers/built-in.o(.text+0x1701c): Section mismatch: reference
> to .init.data: (between 'pvr2fb_pci_probe' and 'read_mem')
> WARNING: drivers/built-in.o(.text+0x17024): Section mismatch: reference
> to .init.text: (between 'pvr2fb_pci_probe' and 'read_mem')
> WARNING: drivers/built-in.o(.data+0x738): Section mismatch: reference
> to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')
> WARNING: drivers/built-in.o(.data+0x750): Section mismatch: reference
> to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')

it means there is code that is not marked as init making references=20
function/data that is marked as init ... this is normally not noticed at bo=
ot=20
as the init sections arent cleared/clobbered until well after boot and=20
usually these are problems just for initialization routines ...

i'd review the symbols that are being warned about here to see if they're=20
missing the proper section markers (aka functions that should be labeled as=
=20
__init but arent)
=2Dmike