linuxsh-dev

[PATCH] SHMIN's address of register different

[Nobuhiro I. <he...@t-...>]

Hi ,

SHMIN's address of register different.
I append the patch to correct it. 

Please apply this pache .

regards,
 Nobuhiro

-- 
Nobuhiro Iwamatsu
	E-Mail : he...@t-...
	GPG ID : 3170EBE9 

Signed-off-by: Nobuhiro Iwamatsu <he...@t-...>

diff --git a/arch/sh/boards/shmin/setup.c b/arch/sh/boards/shmin/setup.c
index bed9ca6..fbb522d 100644
--- a/arch/sh/boards/shmin/setup.c
+++ b/arch/sh/boards/shmin/setup.c
@@ -13,7 +13,7 @@
 #include <asm/io.h>

 #define PFC_PHCR       0xa400010eUL
-#define INTC_ICR1      0xffd00000UL
+#define INTC_ICR1      0xa4000010UL
 #define INTC_IPRC      0xa4000016UL

 static struct ipr_data shmin_ipr_map[] = 

Re: 2.6.20 instability

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

On Fri, Feb 02, 2007 at 04:45:56PM +0900, Paul Mundt wrote:
> On Fri, Feb 02, 2007 at 08:31:26AM +0100, Manuel Lauss wrote:
> > On Tue, Jan 30, 2007 at 09:36:38AM +0100, Manuel Lauss wrote:
> > > > My hesitation with this so far has been that some folks in the office
> > > > have hit troubles booting from CF with that applied, which I didn't see
> > > > on SATA when I was debugging it initially. I would prefer not to break
> > > > one set of boards in exchange for another, though it looks like it's
> > 
> > I see now what you mean: kernel occasionally oopses when I
> > insert a PCMCIA card, like this one:
> > 
> How is the situation if you have both
> 
>     sh: Don't set reserved _PAGE_WT bit on SH-3.
> 
> and
> 
>     sh: Lazy dcache writeback optimizations.
> 
> reverted? (git show <hash> | patch -p1 -R in that order works fine)

I don't run -git kernels so patch 1 is not applied anyway and
without patch 2 the situation is much worse: 
Kernel oopses every time a pcmcia ethernet card is inserted
(cf cards are not affected or much less frequently).
The difference is that for the ethernet card io ports are allocated
starting from 0x300, while the cf card io ports start at 0x0.
Also, the oops does not occur if the ethernet card is already in the
socket when kernel boots. I can then also reapeatedly eject/insert
it without problems.

> We're still not quite all the way there with the kmap_coherent() stuff
> (and the move to copy_user_highpage()), so that's still going to take a
> bit of work. While I think most of the page colouring problems are now
> taken care of, it seems in the PG_dcache_dirty route we're _still_
> missing some flushing that seems to break in certain paths regardless of
> the kmap state.

I guess I should study the mm code more closely to understand all that :)

> If you have issues with those two reverted, it would be interesting to
> see the logs. My SH7760 test board is much more stable with PG_mapped, at
> the cost of some performance.

What logs do you need?

Thanks,

-- 
  ml.

Re: 2.6.20 instability

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

On Fri, Feb 02, 2007 at 08:31:26AM +0100, Manuel Lauss wrote:
> On Tue, Jan 30, 2007 at 09:36:38AM +0100, Manuel Lauss wrote:
> > > My hesitation with this so far has been that some folks in the office
> > > have hit troubles booting from CF with that applied, which I didn't see
> > > on SATA when I was debugging it initially. I would prefer not to break
> > > one set of boards in exchange for another, though it looks like it's
> 
> I see now what you mean: kernel occasionally oopses when I
> insert a PCMCIA card, like this one:
> 
How is the situation if you have both

    sh: Don't set reserved _PAGE_WT bit on SH-3.

and

    sh: Lazy dcache writeback optimizations.

reverted? (git show <hash> | patch -p1 -R in that order works fine)

We're still not quite all the way there with the kmap_coherent() stuff
(and the move to copy_user_highpage()), so that's still going to take a
bit of work. While I think most of the page colouring problems are now
taken care of, it seems in the PG_dcache_dirty route we're _still_
missing some flushing that seems to break in certain paths regardless of
the kmap state.

If you have issues with those two reverted, it would be interesting to
see the logs. My SH7760 test board is much more stable with PG_mapped, at
the cost of some performance.

Re: 2.6.20 instability

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

On Tue, Jan 30, 2007 at 09:36:38AM +0100, Manuel Lauss wrote:
> > My hesitation with this so far has been that some folks in the office
> > have hit troubles booting from CF with that applied, which I didn't see
> > on SATA when I was debugging it initially. I would prefer not to break
> > one set of boards in exchange for another, though it looks like it's

I see now what you mean: kernel occasionally oopses when I
insert a PCMCIA card, like this one:

pccard: PCMCIA card inserted into slot 1
pcmcia: registering new device pcmcia1.0
pcmcia: request for exclusive IRQ could not be fulfilled.
pcmcia: the driver needs updating to supported shared IRQ lines.
Unable to handle kernel paging request at virtual address c0a80ff0
pc = 8c0063b0
*pde = 00000000
Oops: 0000 [#1]
Modules linked in:

Pid : 201, Comm:              pccardd
PC is at generic_readb+0x0/0x6
PC  : 8c0063b0 SP  : 8fdb5b68 SR  : 40008101 TEA : c0a80ff0    Not tainted
R0  : 8c0063b0 R1  : 003fffff R2  : 00000000 R3  : 8c319f1c
R4  : c0a80ff0 R5  : 8c319f28 R6  : 60000534 R7  : 40008101
R8  : 8c2c2b1c R9  : c0a80ff0 R10 : 8c2c2b18 R11 : c0a80000
R12 : 8fb3dc00 R13 : 00000000 R14 : 8c2ad874
MACH: 000003da MACL: 00000000 GBR : 00000000 PR  : 8c1289dc

the TEA is in range of the address returned by  p3_ioremap() of
area 5/6.

It's very hard to reproduce reliably, it sometimes just happens :(

-- 
 ml.

Re: 2.6.20 instability

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

On Tue, Jan 30, 2007 at 05:24:42PM +0900, Paul Mundt wrote:
> On Tue, Jan 30, 2007 at 09:18:54AM +0100, Manuel Lauss wrote:
> > > On Mon, Jan 29, 2007 at 06:40:24PM +0900, Paul Mundt wrote:
> > > > We switched the lazy dcache writeback model to PG_dcache_dirty, which
> > > > results in measurably less flushing. Unfortunately it seems like there
> > > > are still some explicit flushes required that aren't being handled.
> > > > 
> > > > My boards do not frequently exhibit this behaviour however, so it's slow
> > > > debugging. If you want a quick fix, you can either revert to PG_mapped
> > > > behaviour, or insert a dummy flush for the faulting page's dcache lines
> > > > in update_mmu_cache().
> > > 
> > > With commit 0ca6a188.. ("Lazy dcache writeback optimizations") applied
> > > it seems pretty stable. I'll let it run overnight and see where
> > > it fails.
> > 
> > Compiled a few large packages overnight, and none failed.
> > If there is still a chance, can the aforementioned patch go into
> > final 2.6.20? Otherwise SH is almost unusable.
> > 
> My hesitation with this so far has been that some folks in the office
> have hit troubles booting from CF with that applied, which I didn't see
> on SATA when I was debugging it initially. I would prefer not to break
> one set of boards in exchange for another, though it looks like it's

Oh, okay then. I'll apply to my local tree and remove it once it works
for all boards.

Thanks,

-- 
 ml.

Re: 2.6.20 instability

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

On Tue, Jan 30, 2007 at 09:18:54AM +0100, Manuel Lauss wrote:
> > On Mon, Jan 29, 2007 at 06:40:24PM +0900, Paul Mundt wrote:
> > > We switched the lazy dcache writeback model to PG_dcache_dirty, which
> > > results in measurably less flushing. Unfortunately it seems like there
> > > are still some explicit flushes required that aren't being handled.
> > > 
> > > My boards do not frequently exhibit this behaviour however, so it's slow
> > > debugging. If you want a quick fix, you can either revert to PG_mapped
> > > behaviour, or insert a dummy flush for the faulting page's dcache lines
> > > in update_mmu_cache().
> > 
> > With commit 0ca6a188.. ("Lazy dcache writeback optimizations") applied
> > it seems pretty stable. I'll let it run overnight and see where
> > it fails.
> 
> Compiled a few large packages overnight, and none failed.
> If there is still a chance, can the aforementioned patch go into
> final 2.6.20? Otherwise SH is almost unusable.
> 
My hesitation with this so far has been that some folks in the office
have hit troubles booting from CF with that applied, which I didn't see
on SATA when I was debugging it initially. I would prefer not to break
one set of boards in exchange for another, though it looks like it's
going to be 2.6.21 before I can sort out the kmap API rework for the page
colouring, which I was hoping would fix the remaining issues.

I'll have Linus pull it for 2.6.20 if there are enough people that are
experiencing troubles with Linus's current tree as it is.

Re: 2.6.20 instability

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

Hi Paul,
 
> On Mon, Jan 29, 2007 at 06:40:24PM +0900, Paul Mundt wrote:
> > We switched the lazy dcache writeback model to PG_dcache_dirty, which
> > results in measurably less flushing. Unfortunately it seems like there
> > are still some explicit flushes required that aren't being handled.
> > 
> > My boards do not frequently exhibit this behaviour however, so it's slow
> > debugging. If you want a quick fix, you can either revert to PG_mapped
> > behaviour, or insert a dummy flush for the faulting page's dcache lines
> > in update_mmu_cache().
> 
> With commit 0ca6a188.. ("Lazy dcache writeback optimizations") applied
> it seems pretty stable. I'll let it run overnight and see where
> it fails.

Compiled a few large packages overnight, and none failed.
If there is still a chance, can the aforementioned patch go into
final 2.6.20? Otherwise SH is almost unusable.

Thanks,

-- 
 ml.

Re: 2.6.20 instability

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

Hi Paul,

On Mon, Jan 29, 2007 at 06:40:24PM +0900, Paul Mundt wrote:
> We switched the lazy dcache writeback model to PG_dcache_dirty, which
> results in measurably less flushing. Unfortunately it seems like there
> are still some explicit flushes required that aren't being handled.
> 
> My boards do not frequently exhibit this behaviour however, so it's slow
> debugging. If you want a quick fix, you can either revert to PG_mapped
> behaviour, or insert a dummy flush for the faulting page's dcache lines
> in update_mmu_cache().

With commit 0ca6a188.. ("Lazy dcache writeback optimizations") applied
it seems pretty stable. I'll let it run overnight and see where
it fails.

Thanks,

-- 
 ml.

Re: 2.6.20 instability

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

On Mon, Jan 29, 2007 at 10:27:19AM +0100, Manuel Lauss wrote:
> I wanted to ask if I'm the only one experiencing this:
> With 2.6.20-rc, most apps I try to launch are killed
> due to random segfaults. I tried to build udev
> on the target itself; make V=1 would fail with
> gcc simply segfaulting, sometimes /bin/sh can no longer
> be found, sometimes parts of gcc's cmdline arguments
> are missing 2-3 chars at the beginning and gcc 
> aborts with for example 
> "udev_sysdeps.c:73:1: error: ointer-arith: No such file ..."
> 
> 2.6.19 compiles xfce-4 fine so I assume this is some
> subtle sh-kernel specific fault.
> 
> I appreciate any hints!
> 
We switched the lazy dcache writeback model to PG_dcache_dirty, which
results in measurably less flushing. Unfortunately it seems like there
are still some explicit flushes required that aren't being handled.

My boards do not frequently exhibit this behaviour however, so it's slow
debugging. If you want a quick fix, you can either revert to PG_mapped
behaviour, or insert a dummy flush for the faulting page's dcache lines
in update_mmu_cache().

2.6.20 instability

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

Hello,

I wanted to ask if I'm the only one experiencing this:
With 2.6.20-rc, most apps I try to launch are killed
due to random segfaults. I tried to build udev
on the target itself; make V=1 would fail with
gcc simply segfaulting, sometimes /bin/sh can no longer
be found, sometimes parts of gcc's cmdline arguments
are missing 2-3 chars at the beginning and gcc 
aborts with for example 
"udev_sysdeps.c:73:1: error: ointer-arith: No such file ..."

2.6.19 compiles xfce-4 fine so I assume this is some
subtle sh-kernel specific fault.

I appreciate any hints!

Thanks,

-- 
 Manuel Lauss

Re: Renesas 7785 support

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

On Mon, Jan 22, 2007 at 09:31:45PM +0000, Maxim Osipov wrote:
> Is anyone in the list working with 7785 chip? I would like to ask some
> questions, like:
>  - is hardware mature enough?
>  - what is the level of kernel support (booting already?)

Yes, I have the kernel booting on the 7785 Solution Engine via JTAG/E10A,
however the port is still relatively sparse and just getting started. I
would not expect it to be fully supported prior to the 2.6.22 timeframe,
however we're aiming to have most of the basic stuff out of the way for
2.6.21. Most of the peripherals have not had any attention yet, but it's
a work in progress.

>  - how well on-chip peripherals are supported?
> 
I've mostly been focusing on the extended-mode TLB, though things like
the SCIF are working fine at the moment. Most of the other peripherals
have not been looked at yet, pending more low-level optimizations for
SH-X2. Given that, SH7722 (SH-MobileR) is in a similar state at the moment.

Renesas 7785 support

[Maxim O. <max...@gm...>]

Hello!

Is anyone in the list working with 7785 chip? I would like to ask some
questions, like:
 - is hardware mature enough?
 - what is the level of kernel support (booting already?)
 - how well on-chip peripherals are supported?

Thanks in advance!
Maxim

Re: "Lost Interrupt" error from HP620 (CE 2.0) users

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

Greetings,

Bumping MAX_HWIFS didnt change anything. Any good way to bugtrack this?

Best wishes
Kristoffer Ericson


>From: Paul Mundt <le...@li...>
>To: Kristoffer Ericson <kri...@ho...>
>CC: lin...@li...
>Subject: Re: "Lost Interrupt" error from HP620 (CE 2.0) users
>Date: Mon, 22 Jan 2007 09:15:01 +0900
>
>On Sat, Jan 13, 2007 at 09:51:19PM +0000, Kristoffer Ericson wrote:
> > We've only recently aquired a working bootloader for CE 2.0 (and most 
>likely
> > CE 1.0) but users are having issues. I've made them test all kernels
> > (2.6.11->2.6.17) and same error has appeard everytime.
> >
> > Suggestions, ideas?
> >
>The IDE registration looks a bit questionable. Either something has
>grabbed the lower IDs or the MAX_HWIFS need to be bumped up. Consider
>moving to a newer kernel and going the libata/pata_platform route,
>though. ide-sh was always a hack.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Renesas 7785 support

[Maxim O. <max...@gm...>]

Hello!

Is anyone in the list working with 7785 chip? I would like to ask some
questions, like:
 - is hardware mature enough?
 - what is the level of kernel support (booting already?)
 - how well on-chip peripherals are supported?

Thanks in advance!
Maxim

the SH wiki knows all

[Bill T. <wm...@na...>]

Just wanted to remind everyone that the SH wiki
http://www.linux-sh.org is a useful resource.  Relevant to the recent
discussion in particular, the System Support page:
http://linux-sh.org/shwiki/Systems lists systems that either already
or will likely boot Linux.  Please remember to document your successes
and failures on pages linked off of the hardware you're hacking on.

Bill

Re: Looking for SuperH development Board

[Masao U. <ueb...@br...>]

> If someone could find such a guy in Japan, I would be interested in one 
> also.

There're some compatible machines available out of Japan.  FYI.

	http://www.openbsd.org/landisk.html

Masao

Re: Looking for SuperH development Board

[Nobuhiro I. <he...@t-...>]

Hi , 

On Mon, 22 Jan 2007 10:13:03 +0100
Zoltan HERPAI <wi...@br...> wrote:

> If someone could find such a guy in Japan, I would be interested in one 
> also.

LANTANK has not already been produced. 
However, it is likely to be able to buy it in Akihabara. 

I may look for it if you are interested. 

# I have five LANTANK. :-)

regards ,
 Nobuhiro 
-- 
Nobuhiro Iwamatsu
	E-Mail : he...@t-...
	GPG ID : 3170EBE9 

Re: Looking for SuperH development Board

[Valeriy E. U. <uw...@pt...>]

Mike Frysinger <va...@ge...> wrote:

> On Sunday 21 January 2007 18:24, Kristoffer Ericson wrote:
>> Anyone out there wanting to get rid of or sell a development board (SH3,
>> SH4...) drop me a mail.
> 
> if you can pick up a lantank it's quite a good machine for doing development
> 
> 100mbit nic + ide harddrive + 64megs of ram + 200mhz sh4
> 
> find a friend in japan and have them mail you one ... they're pretty cheap

Plextor PX-EH16L, PX-EH25L and PX-EH40L are said to be rebranded
analogues.

http://www.plextor-europe.com/products/all/hard_disk.asp?choice=Professional


SY, Uwe
-- 
uw...@pt...                         |       Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/          |       Ist zu Grunde gehen

Re: Looking for SuperH development Board

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

On Mon, Jan 22, 2007 at 10:13:03AM +0100, Zoltan HERPAI wrote:
> If someone could find such a guy in Japan, I would be interested in one 
> also.
> 
The problem is that they are no longer sold in Japan either, all of the
new HDL-F versions with gigabit are XScale based. It's probably still
possible to dig the old ones up, but they're certainly no longer as
readily available (Yodobashi, etc.). ebay is probably going to be your
best bet.

Re: Looking for SuperH development Board

[Zoltan H. <wi...@br...>]

If someone could find such a guy in Japan, I would be interested in one 
also.

Regards,
-w-

Mike Frysinger wrote:
> On Sunday 21 January 2007 18:24, Kristoffer Ericson wrote:
>   
>> Anyone out there wanting to get rid of or sell a development board (SH3,
>> SH4...) drop me a mail.
>>     
>
> if you can pick up a lantank it's quite a good machine for doing development
>
> 100mbit nic + ide harddrive + 64megs of ram + 200mhz sh4
>
> find a friend in japan and have them mail you one ... they're pretty cheap
> -mike
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev
>   

Re: Dreamcast Linux - Info, how much it would cost to get it going, etc. / Lantank japan?

[nick t. <nic...@mc...>]

Paul Mundt wrote:
> On Sun, Jan 21, 2007 at 07:06:53PM -0600, nick thompson wrote:
>   
>>  I am wondering how much it would cost to get all of the appropriate 
>> equipment to run dreamcast linux. There was an ide adapter that was 
>> homemade if I recall correctly from years back?? Anyway, any pointers or 
>> especially information from anyone actually running it at the moment 
>> would be wonderful.
>>
>>     
> The more compelling question would be, why bother? That little RAM and a
> direct-mapped cache was painful all of these years ago too, and things
> haven't gotten any smaller over time.
>
> Your best bet would be serial console and fetching a BBA for nfsroot. If
> you really feel like resurrecting the maple code, you can always go that
> route with the pvr2fb console as well.
>
> I wouldn't hold out any hope for the IDE adapter. Everything that even
> got near the expansion port was nothing but a horrid hack (GAPSPCI is a
> brilliant example), and you're not going to magically get any faster I/O
> or intelligent IRQ routing over the port regardless of what's hanging off
> of it.
>
> As others have suggested, the landisk/lantank is a good compromise, and
> there are also various SH7751R-based routers floating around that are
> fairly easily acquirable.
>
>   
Paul,
 Thank you again for a very insightful, information filled post. I 
really do appreciate when you find someone who is willing to help out 
with as much info as you have on a list, thanks.

lantank route it is.

ebay first, other if anyone in japan wants to send me one, I will pay 
for it and shipping...and... be your best friend.. :) or perhaps I could 
pay you a little fee.

Anyway, if anyone is in japan, and wants to be a super nice linux 
person, I would love to get one. I will pay all fees. And if there is 
anything I can buy here and send you, I of course would do the same, 
however I bet you have better stuff there than we do anyway, here in the 
states. :)

Nick

"All unix, all the time."

http://npt.ath.cx

Re: Dreamcast Linux - Info, how much it would cost to get it going, etc.

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

On Sun, Jan 21, 2007 at 07:06:53PM -0600, nick thompson wrote:
>  I am wondering how much it would cost to get all of the appropriate 
> equipment to run dreamcast linux. There was an ide adapter that was 
> homemade if I recall correctly from years back?? Anyway, any pointers or 
> especially information from anyone actually running it at the moment 
> would be wonderful.
> 
The more compelling question would be, why bother? That little RAM and a
direct-mapped cache was painful all of these years ago too, and things
haven't gotten any smaller over time.

Your best bet would be serial console and fetching a BBA for nfsroot. If
you really feel like resurrecting the maple code, you can always go that
route with the pvr2fb console as well.

I wouldn't hold out any hope for the IDE adapter. Everything that even
got near the expansion port was nothing but a horrid hack (GAPSPCI is a
brilliant example), and you're not going to magically get any faster I/O
or intelligent IRQ routing over the port regardless of what's hanging off
of it.

As others have suggested, the landisk/lantank is a good compromise, and
there are also various SH7751R-based routers floating around that are
fairly easily acquirable.

Dreamcast Linux - Info, how much it would cost to get it going, etc.

[nick t. <nic...@mc...>]

Hello all,
 I am wondering how much it would cost to get all of the appropriate 
equipment to run dreamcast linux. There was an ide adapter that was 
homemade if I recall correctly from years back?? Anyway, any pointers or 
especially information from anyone actually running it at the moment 
would be wonderful.

Thanks,

Nick

"All unix, all the time."

http://npt.ath.cx

Re: IBM Workpad Z50 - vr linux - current 2.6 kernel - etc

[nick t. <nic...@mc...>]

Paul Mundt wrote:
>
> This is a Vr41xx MIPS, the appropriate forum would be
> http://www.linux-mips.org.
>
> Yoichi Yuasa has been looking after that code.
>
>   
Paul,
 Thanks for the tip. I apologize for the misunderstanding on my part. :)

Nick

"All unix, all the time."

http://npt.ath.cx

Re: Looking for SuperH development Board

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

On Sunday 21 January 2007 18:24, Kristoffer Ericson wrote:
> Anyone out there wanting to get rid of or sell a development board (SH3,
> SH4...) drop me a mail.

if you can pick up a lantank it's quite a good machine for doing development

100mbit nic + ide harddrive + 64megs of ram + 200mhz sh4

find a friend in japan and have them mail you one ... they're pretty cheap
-mike