From: Heiko S. <hei...@in...> - 2007-11-10 19:01:23
|
Hello Adrian, Adrian McMenamin schrieb: > On Sat, 2007-11-10 at 18:06 +0100, Heiko Schocher wrote: >> Hello, >> >> 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? 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 Date: Sat, 10 Nov 2007 18:06:59 +0100) Now I trying the sources from git.kernel.org ... One more question, if I have my board finally running, against which kernel have i do to make my patches? bye Heiko |
From: Adrian M. <ad...@ne...> - 2007-11-10 19:07:08
|
On Sat, 2007-11-10 at 20:00 +0100, Heiko Schocher wrote: > Hello Adrian, > > Adrian McMenamin schrieb: > > On Sat, 2007-11-10 at 18:06 +0100, Heiko Schocher wrote: > >> Hello, > >> > >> 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? > Well, the mainline kernel should compile for SH and work. Everything goes into mainline these days (eventually). Paul Mundt (the Linux SH maintainer) has his own git repo on the kernel.org server where he feeds things to Linus, but if you are looking for a booting kernel as opposed to developing stuff then 2.6.23 should work for you - ie just download the tarball and go (I'm assuming you have all the tools you need). > 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 > Date: Sat, 10 Nov 2007 18:06:59 +0100) > No that's not the ST compiler issue - that was the missing symbols. Paul is the expert on the sort of stuff above - he'll see this I'm sure and reply in due course. > Now I trying the sources from git.kernel.org ... > > One more question, if I have my board finally running, against which > kernel have i do to make my patches? > Against Paul's most recent SH sources I'd guess. > bye > Heiko |
From: Paul M. <le...@li...> - 2007-11-11 04:04:16
|
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. |
From: Heiko S. <hei...@in...> - 2007-11-11 11:22:09
|
Hello Paul, Paul Mundt schrieb: > 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 > Ahh, thanks. > 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. > Hmm.. I am using git, because I think thats the "standard" todays, right? Couldnt find some informations about git on this page, maybe this should be updated? > >> 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. > > OK, thanks. Actually tried the tree from kernel.org, but my problem with the caches on my SH7750R based board isnt gone ... if I disable the cache, Linux runs fine. Actually, I think, yet found the place where my board restarts: If I make a while (1); at the end of the function sh_cpu_init() in arch/sh/kernel/cpu/init.c the cpu dont restart, the next function called is start_kernel (). If I make there as first a while (1), the cpu restarts ... dont see an SH7750R specific thing in arch/sh/kernel/head.S on this place: 10: ! Additional CPU initialization mov.l 6f, r0 jsr @r0 nop SYNCO() ! Wait for pending instructions.. ! Start kernel mov.l 5f, r0 jmp @r0 nop .balign 4 System-map: [...] 882550c0 T start_kernel [...] 88257840 T sh_cpu_init [...] Any ideas? (damned, dont have a debugger ...) bye Heiko |
From: Paul M. <le...@li...> - 2007-11-12 04:39:36
|
On Sun, Nov 11, 2007 at 12:22:13PM +0100, Heiko Schocher wrote: > Paul Mundt schrieb: > >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. > > > > Hmm.. I am using git, because I think thats the "standard" todays, > right? Couldnt find some informations about git on this page, maybe > this should be updated? > Well, the git trees aren't directly linked primarily because they're just a staging ground for the stuff that goes to Linus. I generally prefer people to use Linus's git tree directly, as I only bother syncing up if there's changing that need to be merged. I suppose the entry could use some more clarity though, I'll see about reworking it a bit. > If I make a while (1); at the end of the function sh_cpu_init() in > arch/sh/kernel/cpu/init.c the cpu dont restart, the next function > called is start_kernel (). If I make there as first a while (1), the > cpu restarts ... dont see an SH7750R specific thing in > arch/sh/kernel/head.S on this place: > [snip] > Any ideas? > (damned, dont have a debugger ...) > Sounds like something could be falling out as a result of the initial cache flush in cache_init(), possibly due to things left over from your boot loader. You might try playing with that a bit. Also, if you don't have a debugger, early printk should still be usable. If you're using sh-ipl+g then you don't have to do anything special for it, but if you want to use the SCIF directly and are using an alternate loader, you will have to plug in the I/O port and some various fixups for SH7750R (most of which you can just glean from sh-sci.[ch]). If you want to start debugging from sh_cpu_init() already and have sh-ipl+g, you can #include <asm/sh_bios.h> directly and use the write routine there. This causes a trap directly, and can be handled regardless of whether the MMU is enabled or not. Barring that, find an LED and start toggling.. this is how I do most of my debugging :-) |
From: Heiko S. <hei...@in...> - 2007-11-12 08:47:49
|
Hello Paul, Paul Mundt schrieb: > On Sun, Nov 11, 2007 at 12:22:13PM +0100, Heiko Schocher wrote: >> If I make a while (1); at the end of the function sh_cpu_init() in >> arch/sh/kernel/cpu/init.c the cpu dont restart, the next function >> called is start_kernel (). If I make there as first a while (1), the >> cpu restarts ... dont see an SH7750R specific thing in >> arch/sh/kernel/head.S on this place: >> > [snip] > >> Any ideas? >> (damned, dont have a debugger ...) >> > Sounds like something could be falling out as a result of the initial > cache flush in cache_init(), possibly due to things left over from your > boot loader. You might try playing with that a bit. Hmm.. didnt enable the cache in the bootloader ... Hmm.. I have running code from a selfmade OS, with caches enabled. There I set the CCR_CACHE_ORA bit in the CCR register, as I see in the cache_init() function, this bit is never set ... Doesnt Linux want this Bit to be set? thanks bye Heiko |
From: Paul M. <pau...@re...> - 2007-11-12 10:04:09
|
On Mon, Nov 12, 2007 at 09:47:57AM +0100, Heiko Schocher wrote: > Paul Mundt schrieb: > > On Sun, Nov 11, 2007 at 12:22:13PM +0100, Heiko Schocher wrote: > >> If I make a while (1); at the end of the function sh_cpu_init() in > >> arch/sh/kernel/cpu/init.c the cpu dont restart, the next function > >> called is start_kernel (). If I make there as first a while (1), the > >> cpu restarts ... dont see an SH7750R specific thing in > >> arch/sh/kernel/head.S on this place: > >> > > Sounds like something could be falling out as a result of the initial > > cache flush in cache_init(), possibly due to things left over from your > > boot loader. You might try playing with that a bit. > > Hmm.. didnt enable the cache in the bootloader ... > Hmm.. I have running code from a selfmade OS, with caches enabled. There > I set the CCR_CACHE_ORA bit in the CCR register, as I see in the > cache_init() > function, this bit is never set ... Doesnt Linux want this Bit to be set? > No, Linux doesn't want this bit set, and presumably neither do you. We used to have special casing for it, but its implementation varied too widely on different CPU subtypes (especially with the transition from 2 to 4-way set associative dcaches) to make it easy to support. The initial cache flush checks to see if the boot loader has set the ORA bit, in which case the flush can be optimized, as there's only half of the cache to flush. If you plan to use operand cache RAM mode under linux, you will have to handle the cache halving commonly, and account for the fact that the memory-mapped cache access varies depending on the CPU subtype (different subtypes use different ways for RAM mode, with and without EMODE). Also if your bootloader is not setting the CCR enable bit, the initial cache flush and subsequent ORA check should never be hit in the first place. |