linuxsh-dev

Problems starting init on a SH7750R based board

[Heiko S. <hei...@in...>]

Hello,

I am new to the sh port for Linux. I succesfully ported U-Boot to an 
SH7750R based
board, and trying to get Linux running. It works pretty nice until the 
init is loaded.
After this I get an Intevent 0x1e0, and then nothing more works ...

1) Has somebody here an idea, where this intevent come from? How I can 
prevent
    it?

2) I see this intevent only, after the console output "Freeing unused 
kernel memory: 88k freed"

3) Sometimes I see the output from the BusyBox, or from a hello_world 
applikation,
    sometimes I see nothing, somtimes after this intevent a ping to the 
board works,
    sometimes the console is working(I get back the characters I send)  ...

BTW:
4) I think the generic_irq_demux funktion dont work nice, if I get such 
an eventvector,
    the resulting irq is 0x7ffffff, and irq is used as an index in 
generic_handle_irq()
        struct irq_desc *desc = irq_desc + irq;
    , and + 0x7ffffff is somewhere in the RAM, thats not good.


Here my output from the console:

U-Boot 1.3.0-rc2-ga55412ee-dirty (Oct 26 2007 - 16:29:30)

CPU: SH4
     PVR: 4050045
     PRR: 103
     CVR: 20480000
BOARD: POSEIDON
DRAM:  128MB
FLASH: 1MB
640x480x15 31kHz 59Hz
Video: Drawing the logo ...
In:    serial
Out:   serial
Err:   serial
Net:   RTL8019AS
IDE:   Bus 0: OK
  Device 0: Model: PQI FLASH DISK Firm: db01.17a Ser#:
            Type: Removable Hard Disk
            Capacity: 62.5 MB = 0.0 GB (128000 x 512)
Hit any key to stop autoboot:  0
=>
=> run net_nfs
TFTP from server 192.168.1.4; our IP address is 192.168.1.10
Filename 'kernel'.
Load address: 0xc000000
Loading: #################################################################
         ######################
done
Bytes transferred = 1273920 (137040 hex)
## Booting image at 0c000000 ...
   Image Name:   testimage
   Created:      2007-10-26  15:31:23 UTC
   Image Type:   SuperH Linux Kernel Image (uncompressed)
   Data Size:    1273856 Bytes =  1.2 MB
   Load Address: 08800000
   Entry Point:  08800000
   Verifying Checksum ... OK
OK
starting SH kernel ...
Uncompressing Linux...
Ok, booting the kernel.

Linux version 2.6.23-rc9-ge2a57a81-dirty (hs@Zeus) (gcc version 4.1.1 
20061011 (Red Hat 4.1.1-30)) #504 Fri Oct 26 17:30:37 CEST 2007
Booting machvec: POSEIDON
Node 0: start_pfn = 0x8000, low = 0x10000
Zone PFN ranges:
  Normal      32768 ->    65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:    32768 ->    65536
Built 1 zonelists in Zone order.  Total pages: 32512
Kernel command line: root=/dev/nfs rw 
nfsroot=192.168.1.4:/home/hs/Entwicklung/sh4/rootfs,rsize=1024,wsize=1024 
ip=192.168.1.10:192.168.1.4::255.255.255.0:poseidon:eth0:off panic=1 
console=ttySC1,38400 netdev=8,0xa0200000,0,0xbad,eth0
PID hash table entries: 512 (order: 9, 2048 bytes)
Using tmu for system timer
Using 8.333 MHz high precision timer.
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 127360k/131072k available (1886k kernel code, 417k data, 88k init)
PVR=04050045 CVR=20480000 PRR=00000103
I-cache : n_ways=2 n_sets=256 way_incr=8192
I-cache : entry_mask=0x00001fe0 alias_mask=0x00001000 n_aliases=2
D-cache : n_ways=2 n_sets=512 way_incr=16384
D-cache : entry_mask=0x00003fe0 alias_mask=0x00003000 n_aliases=4
Mount-cache hash table entries: 512
CPU: SH7750R
NET: Registered protocol family 16
DMA: Registering DMA API.
DMA: Registering sh_dmac handler (8 channels).
Time: SuperH clocksource has been installed.
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
fuse init (API version 7.8)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
SuperH SCI(F) driver initialized
sh-sci: ttySC0 at MMIO 0xffe00000 (irq = 25) is a sci
sh-sci: ttySC1 at MMIO 0xffe80000 (irq = 43) is a scif
console [ttySC1] enabled
loop: module loaded
NE*000 ethercard probe at 0xa0200000:dev IRQ: 8
 5a 77 3d 57 93 16
eth0: NE2000 found at 0xa0200000, using IRQ 8.
shwdt: initialized. heartbeat=30 sec (nowayout=0)
nf_conntrack version 0.5.0 (2048 buckets, 8192 max)
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
IP-Config: Complete:
      device=eth0, addr=192.168.1.10, mask=255.255.255.0, 
gw=255.255.255.255,
     host=poseidon, domain=, nis-domain=(none),
     bootserver=192.168.1.4, rootserver=192.168.1.4, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.4
Looking up port of RPC 100005/1 on 192.168.1.4
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 88k freed
init started: BusyBox v1.7.2 (2007-10-24 12:59:04 CEST)
 irq: 7ffffff evt: 1e0
 irq: 7ffffff evt: 1e0
 irq: 7ffffff evt: 1e0
 irq: 7ffffff evt: 1e0
[...]
(between each "irq: 7ffffff evt: 1e0" line is a pause from approx. 1 minute)

To get the last outputs, I made a boardspecific irq_demux function:

static inline int poseidon_irq_demux(int irq)
{
        if ((irq != 16)  && (irq != 8) && (irq != 43))printk (" irq: %x 
evt: %x\n", irq, irq2evt(irq));
        /* 8 Ethernet, 43 Tx Empty, 16 Timer IRQ */
        irq &= 0xff;
        return irq;
}

(I now, I get now irq=255, but this is better then 0x7ffffff ;-) I 
think, the problem is in
getting the intevt 0x1e0 in the do_IRQ () function, but i have no idea, 
why this happens,
and how to prevent, solve it. Hope somebody here has an idea.

I also tried as init application an hello_world, same behaviour ....

thanks in advance
Heiko

Re: Problems starting init on a SH7750R based board

[Heiko S. <hei...@in...>]

Hello Paul,

thanks for responding

Paul Mundt wrote:
> On Sat, Oct 27, 2007 at 08:19:54AM +0200, Heiko Schocher wrote:
>> After this I get an Intevent 0x1e0, and then nothing more works ...
>>
>> 1) Has somebody here an idea, where this intevent come from? How I can
>> prevent it?
>>
> It sounds like something is generating an interrupt that you aren't
> acking, for some reason it isn't being caught as spurious and disabled,
> and you are hanging as a result. If you want to hack around it, you can

Here the text ends ... I want to hack around it, what can I do?

>> BTW:
>> 4) I think the generic_irq_demux funktion dont work nice, if I get such
>> an eventvector,
>> the resulting irq is 0x7ffffff, and irq is used as an index in
>> generic_handle_irq()
>> struct irq_desc *desc = irq_desc + irq;
>> , and + 0x7ffffff is somewhere in the RAM, thats not good.
>>
> This is rather curious. EVT 0x1e0 implies IRQ -1, and you've simply
> wrapped, that shouldn't happen. You shouldn't even be entering the
> do_IRQ() path here, are you certain that this is an INTEVT value rather
> than an EXPEVT one?
Hm.. I get this value in the do_IRQ function, so I think it is an INTEVT 
value.
Or is there a way do_IRQ () is called from an EXPEVT?
> You may also want to register a dummy handler at that EVT slot using
> set_exception_table_evt() (you probably also want to invalidate the
> I-cache for sanity after doing so), and see what falls out. That's
> certainly not a valid IRQ vector.

I made:

set_exception_table_evt(0x1e0, do_1e0_restore) in void __init 
trap_init(void)

with do_1e0_restore ()

asmlinkage void do_1e0_restore(unsigned long r4, unsigned long r5,
                                   unsigned long r6, unsigned long r7,
                                   struct pt_regs __regs)
{
        struct pt_regs *regs = RELOC_HIDE(&__regs, 0);
        long ex;

        lookup_exception_vector(ex);
        die_if_kernel("1e0 exception", regs, ex);
}

no change in the output ...

Must I use another gcc? I am actually using:
Linux version 2.6.24-rc1-g7d7b59ac-dirty (hs@Zeus) (gcc version 4.1.1 
20061011 (Red Hat 4.1.1-30)) #19 Tue Oct 30 09:29:07 CET 2007

I think, there is something happening, when the user application is 
starting.
Some problems with Processwitching, Stack, ... Hmm, I have only to set
the following parameters, right?

CONFIG_PAGE_OFFSET=0x80000000
CONFIG_MEMORY_START=0x08000000
CONFIG_MEMORY_SIZE=0x08000000
CONFIG_ZERO_PAGE_OFFSET=0x00001000
CONFIG_BOOT_LINK_OFFSET=0x00800000

Is there a board running with a SH7750R? Maybe there is some CPU 
specific stuff
to set up ...

thanks,
heiko

Re: Problems starting init on a SH7750R based board

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

On Tue, Oct 30, 2007 at 09:50:08AM +0100, Heiko Schocher wrote:
> Paul Mundt wrote:
> > On Sat, Oct 27, 2007 at 08:19:54AM +0200, Heiko Schocher wrote:
> >> After this I get an Intevent 0x1e0, and then nothing more works ...
> >>
> >> 1) Has somebody here an idea, where this intevent come from? How I can
> >> prevent it?
> >>
> > It sounds like something is generating an interrupt that you aren't
> > acking, for some reason it isn't being caught as spurious and disabled,
> > and you are hanging as a result. If you want to hack around it, you can
> 
> Here the text ends ... I want to hack around it, what can I do?
> 
I don't remember what I was writing here, I think it was in relation to
the set_exception_table_evt() thing that was mentioned later :-)

> > This is rather curious. EVT 0x1e0 implies IRQ -1, and you've simply
> > wrapped, that shouldn't happen. You shouldn't even be entering the
> > do_IRQ() path here, are you certain that this is an INTEVT value rather
> > than an EXPEVT one?
> Hm.. I get this value in the do_IRQ function, so I think it is an INTEVT 
> value.
> Or is there a way do_IRQ () is called from an EXPEVT?

In theory, no. In practice, you may have hit a bug in the interrupt
exception dispatch. If you can trace the path through
arch/sh/kernel/cpu/sh3/entry.S:handle_exception() and
interrupt_exception() it might uncover some clues. Dumping out both the
EXPEVT/INTEVT values would also help to see if something is getting
mangled.

In any event, the evt2irq() math is correct. If there's nothing obvious
in the exception dispatch, I'll dig out a SH7750R manual and see if there
are some vectors that behave in a strange fashion. I suspect you're
probably the first person to do much testing on SH7750R, SH7751R has had
much more testing comparatively.

> asmlinkage void do_1e0_restore(unsigned long r4, unsigned long r5,
>                                    unsigned long r6, unsigned long r7,
>                                    struct pt_regs __regs)
> {
>         struct pt_regs *regs = RELOC_HIDE(&__regs, 0);
>         long ex;
> 
>         lookup_exception_vector(ex);
>         die_if_kernel("1e0 exception", regs, ex);
> }
> 
> no change in the output ...
> 
How about just a printk()? If this triggers at all, the r4 and ex values
would be interesting to see.

> Must I use another gcc? I am actually using:
> Linux version 2.6.24-rc1-g7d7b59ac-dirty (hs@Zeus) (gcc version 4.1.1 
> 20061011 (Red Hat 4.1.1-30)) #19 Tue Oct 30 09:29:07 CET 2007
> 
This should be fine, though you can of course try a 3.x and a 4.2.x for
comparison. I used to primarily use ST's 4.1.1 until it stopped being
able to build the kernel on any interesting configurations.

You can find 3.4.5 and 4.2.1 compilers respectively here:

	http://userweb.kernel.org/~lethal/sh4-gcc-3.4.5-glibc-2.3.5.tar.bz2
	http://userweb.kernel.org/~lethal/gnush4_linux_v0702_rc-1-1.i386.tar.gz

Both of those produce working code (at least as far as the kernel is
concerned), so should easily verify whether you've hit a code generation
problem or not.

> Is there a board running with a SH7750R? Maybe there is some CPU
> specific stuff to set up ...
> 
Can you attach your entire .config? I don't have a SH7750R handy, but can
probably dig one up if nothing else helps.

Re: Problems starting init on a SH7750R based board

[Heiko S. <hei...@in...>]

Hello Paul,

Paul Mundt wrote:
> On Tue, Oct 30, 2007 at 09:50:08AM +0100, Heiko Schocher wrote:
>> Paul Mundt wrote:
>>> On Sat, Oct 27, 2007 at 08:19:54AM +0200, Heiko Schocher wrote:
>>>> After this I get an Intevent 0x1e0, and then nothing more works ...
>>>>
>>>> 1) Has somebody here an idea, where this intevent come from? How I can
>>>> prevent it?
>>>>
>>> It sounds like something is generating an interrupt that you aren't
>>> acking, for some reason it isn't being caught as spurious and disabled,
>>> and you are hanging as a result. If you want to hack around it, you can
>> Here the text ends ... I want to hack around it, what can I do?
>>
> I don't remember what I was writing here, I think it was in relation to
> the set_exception_table_evt() thing that was mentioned later :-)

:-)

>>> This is rather curious. EVT 0x1e0 implies IRQ -1, and you've simply
>>> wrapped, that shouldn't happen. You shouldn't even be entering the
>>> do_IRQ() path here, are you certain that this is an INTEVT value rather
>>> than an EXPEVT one?
>> Hm.. I get this value in the do_IRQ function, so I think it is an INTEVT
>> value.
>> Or is there a way do_IRQ () is called from an EXPEVT?
>
> In theory, no. In practice, you may have hit a bug in the interrupt
> exception dispatch. If you can trace the path through
> arch/sh/kernel/cpu/sh3/entry.S:handle_exception() and
> interrupt_exception() it might uncover some clues. Dumping out both the
> EXPEVT/INTEVT values would also help to see if something is getting
> mangled.

OK, I try this (but I have to say, I have no debugger ...)

> In any event, the evt2irq() math is correct. If there's nothing obvious
> in the exception dispatch, I'll dig out a SH7750R manual and see if there
> are some vectors that behave in a strange fashion. I suspect you're
> probably the first person to do much testing on SH7750R, SH7751R has had
> much more testing comparatively.

OK, I ll have a look in a SH7751R Manual, maybe there are some differences.

>> asmlinkage void do_1e0_restore(unsigned long r4, unsigned long r5,
>> unsigned long r6, unsigned long r7,
>> struct pt_regs __regs)
>> {
>> struct pt_regs *regs = RELOC_HIDE(&__regs, 0);
>> long ex;
>>
>> lookup_exception_vector(ex);
>> die_if_kernel("1e0 exception", regs, ex);
>> }
>>
>> no change in the output ...
>>
> How about just a printk()? If this triggers at all, the r4 and ex values
> would be interesting to see.

I tried this also with a printk, didnt get an output.

>> Must I use another gcc? I am actually using:
>> Linux version 2.6.24-rc1-g7d7b59ac-dirty (hs@Zeus) (gcc version 4.1.1
>> 20061011 (Red Hat 4.1.1-30)) #19 Tue Oct 30 09:29:07 CET 2007
>>
> This should be fine, though you can of course try a 3.x and a 4.2.x for
> comparison. I used to primarily use ST's 4.1.1 until it stopped being
> able to build the kernel on any interesting configurations.
>
> You can find 3.4.5 and 4.2.1 compilers respectively here:
>
> http://userweb.kernel.org/~lethal/sh4-gcc-3.4.5-glibc-2.3.5.tar.bz2
> http://userweb.kernel.org/~lethal/gnush4_linux_v0702_rc-1-1.i386.tar.gz

thanks!
(If this not helps, I try to build the complete Toolchain ... because this
"error" triggers just after running the init application, maybe there is
a problem with some headers ...)

> Both of those produce working code (at least as far as the kernel is
> concerned), so should easily verify whether you've hit a code generation
> problem or not.
>
>> Is there a board running with a SH7750R? Maybe there is some CPU
>> specific stuff to set up ...
>>
> Can you attach your entire .config? I don't have a SH7750R handy, but can
> probably dig one up if nothing else helps.

Here my complete config, maybe I made a mistake somewhere ...

thanks
Heiko

Re: Problems starting init on a SH7750R based board

[Heiko S. <hei...@in...>]

Hello Paul,

Paul Mundt schrieb:
>> Is there a board running with a SH7750R? Maybe there is some CPU
>> specific stuff to set up ...
>>
> Can you attach your entire .config? I don't have a SH7750R handy, but can
> probably dig one up if nothing else helps.

After looking in the SH7751R Manual, I saw, that the SH7751R can t use
SDRAM with Bussize 64 Bit. The SH7750R can use SDRAM with 64 Bit
Bussize, which I use on my board. Also can the SH7750R map the
SDRAM to Area 2 or 3, the SH7751R only to Area 3, maybe there is a problem?

bye
Heiko

Re: Problems starting init on a SH7750R based board

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

On Tue, Oct 30, 2007 at 06:44:32PM +0100, Heiko Schocher wrote:
> Paul Mundt schrieb:
> >> Is there a board running with a SH7750R? Maybe there is some CPU
> >> specific stuff to set up ...
> >>
> > Can you attach your entire .config? I don't have a SH7750R handy, but can
> > probably dig one up if nothing else helps.
> 
> After looking in the SH7751R Manual, I saw, that the SH7751R can t use
> SDRAM with Bussize 64 Bit. The SH7750R can use SDRAM with 64 Bit
> Bussize, which I use on my board. Also can the SH7750R map the
> SDRAM to Area 2 or 3, the SH7751R only to Area 3, maybe there is a problem?
> 
No, that shouldn't matter. If this was a problem, you wouldn't be making
it very far in the kernel at least.

There are two other things to try first, write-through caching, and
reverting commit-id 023ef184fff6ac2e7cba345708f35536a2a419cb. Your
problem does not seem to be related to what Kristoffer is hitting, but
the bogus INTEVT is rather perplexing.

Re: Problems starting init on a SH7750R based board

[Heiko S. <hei...@in...>]

Hello Paul,

Paul Mundt schrieb:
> On Tue, Oct 30, 2007 at 06:44:32PM +0100, Heiko Schocher wrote:
>> Paul Mundt schrieb:
>>>> Is there a board running with a SH7750R? Maybe there is some CPU
>>>> specific stuff to set up ...
>>>>
>>> Can you attach your entire .config? I don't have a SH7750R handy, 
>>> but can
>>> probably dig one up if nothing else helps.
>> After looking in the SH7751R Manual, I saw, that the SH7751R can t use
>> SDRAM with Bussize 64 Bit. The SH7750R can use SDRAM with 64 Bit
>> Bussize, which I use on my board. Also can the SH7750R map the
>> SDRAM to Area 2 or 3, the SH7751R only to Area 3, maybe there is a 
>> problem?
>>
> No, that shouldn't matter. If this was a problem, you wouldn't be making
> it very far in the kernel at least.
>
> There are two other things to try first, write-through caching, and
> reverting commit-id 023ef184fff6ac2e7cba345708f35536a2a419cb. Your
> problem does not seem to be related to what Kristoffer is hitting, but
> the bogus INTEVT is rather perplexing.
>
I have it running :-)

=> run sh
TFTP from server 192.168.1.4; our IP address is 192.168.1.10
Filename 'kernel-sh'.
Load address: 0xc000000
Loading: #################################################################
         ########################
done
Bytes transferred = 1302592 (13e040 hex)
## Booting image at 0c000000 ...
   Image Name:   sh-linux-image
   Created:      2007-11-01  21:34:14 UTC
   Image Type:   SuperH Linux Kernel Image (uncompressed)
   Data Size:    1302528 Bytes =  1.2 MB
   Load Address: 88800000
   Entry Point:  88800000
   Verifying Checksum ... OK
OK
starting SH kernel ...
Uncompressing Linux...
Ok, booting the kernel.

Linux version 2.6.24-rc1-gc5f67c68-dirty (@Zeus) (gcc version 4.1.1 
20061011 (Red Hat 4.1.1-30)) #77 Thu Nov 1 22:33:47 CET 2007
Booting machvec: POSEIDON
Node 0: start_pfn = 0x8000, low = 0x10000
Zone PFN ranges:
  Normal      32768 ->    65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:    32768 ->    65536
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: root=/dev/nfs rw 
nfsroot=192.168.1.4:/home/hs/Entwicklung/sh4/rootfs,rsize=1024,wsize=1024 
ip=192.168.1.10:192.168.1.4::255.255.255.0:poseidon:eth0:off panic=1 
console=ttySC1,38400 netdev=8,0xa0200000,0,0xbad,eth0
arch/sh/boards/emblux/poseidon/irq.c init_poseidon_IRQ
arch/sh/kernel/cpu/sh4/setup-sh7750.c plat_irq_setup_pins mode: 0
PID hash table entries: 512 (order: 9, 2048 bytes)
Using tmu for system timer
Using 8.333 MHz high precision timer.
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 127360k/131072k available (1906k kernel code, 445k data, 92k init)
PVR=04050045 CVR=20480000 PRR=00000103
I-cache : n_ways=2 n_sets=256 way_incr=8192
I-cache : entry_mask=0x00001fe0 alias_mask=0x00001000 n_aliases=2
D-cache : n_ways=2 n_sets=512 way_incr=16384
D-cache : entry_mask=0x00003fe0 alias_mask=0x00003000 n_aliases=4
Mount-cache hash table entries: 512
CPU: SH7750R
net_namespace: 64 bytes
NET: Registered protocol family 16
DMA: Registering DMA API.
DMA: Registering sh_dmac handler (8 channels).
Time: SuperH clocksource has been installed.
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
fuse init (API version 7.9)
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
SuperH SCI(F) driver initialized
sh-sci: ttySC0 at MMIO 0xffe00000 (irq = 25) is a sci
sh-sci: ttySC1 at MMIO 0xffe80000 (irq = 43) is a scif
console [ttySC1] enabled
loop: module loaded
8390.c:v1.10cvs 9/23/94 Donald Becker (be...@ce...)
ne.c:v1.10 9/23/94 Donald Becker (be...@sc...)
Last modified Nov 1, 2000 by Paul Gortmaker
NE*000 ethercard probe at 0xa0200000:5a:77:3d:57:93:16
eth0: NE2000 found at 0xa0200000, using IRQ 8.
8390.c:v1.10cvs 9/23/94 Donald Becker (be...@ce...)
shwdt: initialized. heartbeat=30 sec (nowayout=0)
nf_conntrack version 0.5.0 (2048 buckets, 8192 max)
IPv4 over IPv4 tunneling driver
GRE over IPv4 tunneling driver
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
IP-Config: Complete:
      device=eth0, addr=192.168.1.10, mask=255.255.255.0, 
gw=255.255.255.255,
     host=poseidon, domain=, nis-domain=(none),
     bootserver=192.168.1.4, rootserver=192.168.1.4, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.4
Looking up port of RPC 100005/1 on 192.168.1.4
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 92k freed
init started: BusyBox v1.7.2 (2007-11-01 20:25:53 CET)



Welcome to POSEIDON LINUX done by EmbLux KFT (2007) (sh7750R) - Kernel 
2.6.24-rc1-gc5f67c68-dirty (ttySC1).


poseidon login: root
login[18]: root login on 'ttySC1'
[\u@\h \W]$


:-)

But I get it running without caches enabled -> There is somewhere the 
Problem, I am searching
for it ... if I enable the caches I get allways this bogus INTEVT 0x1e0 
after starting the init ... (And
sometimes the complete Kernel never starts ...)

Thanks for your help!

When I found it, I give you feedback, also adding the patches for the 
board here, right?

BTW:
It runs with the patch from Kristoffer commit-ID: 
023ef184fff6ac2e7cba345708f35536a2a419cb.
It also runs without this patch ...

bye
Heiko

Re: Problems starting init on a SH7750R based board

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

On Thu, Nov 01, 2007 at 10:44:06PM +0100, Heiko Schocher wrote:
> PVR=04050045 CVR=20480000 PRR=00000103
> I-cache : n_ways=2 n_sets=256 way_incr=8192
> I-cache : entry_mask=0x00001fe0 alias_mask=0x00001000 n_aliases=2
> D-cache : n_ways=2 n_sets=512 way_incr=16384
> D-cache : entry_mask=0x00003fe0 alias_mask=0x00003000 n_aliases=4
> 
[snip]

> But I get it running without caches enabled -> There is somewhere the 
> Problem, I am searching
> for it ... if I enable the caches I get allways this bogus INTEVT 0x1e0 
> after starting the init ... (And
> sometimes the complete Kernel never starts ...)
> 
So it looks like you're being bitten by the same problem that Manuel
reported with regards to breakage on 2-way caches. I'm presently
debugging this, and will post patches once the remaining bugs I know of
are fixed.

Re: Problems starting init on a SH7750R based board

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

On Sat, Oct 27, 2007 at 08:19:54AM +0200, Heiko Schocher wrote:
> After this I get an Intevent 0x1e0, and then nothing more works ...
> 
> 1) Has somebody here an idea, where this intevent come from? How I can 
> prevent it?
> 
It sounds like something is generating an interrupt that you aren't
acking, for some reason it isn't being caught as spurious and disabled,
and you are hanging as a result. If you want to hack around it, you can 

> BTW:
> 4) I think the generic_irq_demux funktion dont work nice, if I get such 
> an eventvector,
>     the resulting irq is 0x7ffffff, and irq is used as an index in 
> generic_handle_irq()
>         struct irq_desc *desc = irq_desc + irq;
>     , and + 0x7ffffff is somewhere in the RAM, thats not good.
> 
This is rather curious. EVT 0x1e0 implies IRQ -1, and you've simply
wrapped, that shouldn't happen. You shouldn't even be entering the
do_IRQ() path here, are you certain that this is an INTEVT value rather
than an EXPEVT one?

You may also want to register a dummy handler at that EVT slot using
set_exception_table_evt() (you probably also want to invalidate the
I-cache for sanity after doing so), and see what falls out. That's
certainly not a valid IRQ vector.