Re: actual kernel not compiling

[Paul M. <le...@li...>]

On Sat, Nov 10, 2007 at 08:00:58PM +0100, Heiko Schocher wrote:
> Adrian McMenamin schrieb:
>  > On Sat, 2007-11-10 at 18:06 +0100, Heiko Schocher wrote:
>  >> I get the newest kernel from
>  >> git clone git://newgolddream.dyndns.info/
>  >
>  > Well, that's my Dreamcast git and it has some patches to get the kernel
>  > to work with ST's compiler and that may well be the reason. By all means
>  > use it but it has no official status and there is certainly no guarantee
>  > it will work at any given time.
>  >
>  > Go to git.kernel.org instead.
> 
> Ups, didnt know this. Thought this is the "SH linux kernel", which
> contains the newest special SH patches (like the patches from this
> mailinglist), before they go into the mainline ...
> Is there somewhere such a special sh-linux kernel?
> 
I'm not sure where you got that idea from, this is documented on the
wiki:

	http://linux-sh.org/shwiki/Getting_source

I also have a number of SH-related git trees for development work, but
the current kernel bits are always pushed to Linus once a week or so on
average.

You can browse http://git.kernel.org for different trees.

Feel free to complain if you think the wiki page should be updated with
some more information that might be helpful, this should be a fairly
painless process, so we'd like to have all of the ambiguities addressed.

> BTW:
> I get this kernel compiling and running on a SH7750R based board without
> caches :-), following patch is additionally needed:
> 
> diff --git a/include/asm-sh/cacheflush.h b/include/asm-sh/cacheflush.h
> index b912461..9d528ad 100644
> --- a/include/asm-sh/cacheflush.h
> +++ b/include/asm-sh/cacheflush.h
> @@ -43,7 +43,7 @@ extern void __flush_purge_region(void *start, int size);
>   extern void __flush_invalidate_region(void *start, int size);
>   #endif
> 
> -#ifdef CONFIG_CPU_SH4
> +#if defined(CONFIG_CPU_SH4) && !defined(CONFIG_CACHE_OFF)
>   extern void copy_to_user_page(struct vm_area_struct *vma,
>   	struct page *page, unsigned long vaddr, void *dst, const void *src,
>   	unsigned long len);
> 
> I think, that has nothing to do with some special ST compiler, it should be
> fixed, or? (Same as my patch from today

Hmm, yes, that's probably true. We can certainly use the generic routines
for this with CONFIG_CACHE_OFF=y. Anyways, the intent with the
kmap_coherent() interface was that we could gradually nop this out on the
platforms that don't care and then end up with a single set of page
copying routines, rather than having subtype-specific cruft.

For 2.6.24 though, your patch is probably the best solution. I'll apply
it to my 2.6.24 tree.