Menu
▾
▴
linuxsh-dev
|
From: Adrian M. <ad...@ne...> - 2007-07-15 18:09:35
|
It appears it is not the sh_dmac code which is to blame, but the pvr2_dma code. If I fix the build to exclude pvr2_dma.c, the Dreamcast will boot with CONFIG_NR_ONCHIP_DMA_CHANNELS set correctly (ie to 4) Plainly the pvr code is broken when it tries to take channel 4, not sure why though, will have a deeper look. Adrian |
|
From: Adrian M. <ad...@ne...> - 2007-07-15 19:49:44
|
On Sun, 2007-07-15 at 19:09 +0100, Adrian McMenamin wrote: > It appears it is not the sh_dmac code which is to blame, but the > pvr2_dma code. If I fix the build to exclude pvr2_dma.c, the Dreamcast > will boot with CONFIG_NR_ONCHIP_DMA_CHANNELS set correctly (ie to 4) > > Plainly the pvr code is broken when it tries to take channel 4, not sure > why though, will have a deeper look. Further investigation shows that while the above holds true (though it should be dma-pvr2.c obviously) I cannot boot the machine with the pvr fb driver selected and if I don't select it I get no sound output - (presumably this is because the sound is multiplexed with the video output?). The sound driver appears to be working perfectly other than there is no output. |
|
From: Paul M. <le...@li...> - 2007-07-15 22:43:06
|
On Sun, Jul 15, 2007 at 07:09:02PM +0100, Adrian McMenamin wrote: > It appears it is not the sh_dmac code which is to blame, but the > pvr2_dma code. If I fix the build to exclude pvr2_dma.c, the Dreamcast > will boot with CONFIG_NR_ONCHIP_DMA_CHANNELS set correctly (ie to 4) > CONFIG_NR_ONCHIP_DMA_CHANNELS should be 4 for this, yes. CONFIG_NR_DMA_CHANNELS should be 9, as per the Kconfig entry. > Plainly the pvr code is broken when it tries to take channel 4, not sure > why though, will have a deeper look. > How do you reach that conclusion? The pvr code is requesting the first channel of the pvr2 DMAC. SH DMAC channels are mapped to virtual channels 0 - 3, pvr2 at 4, andthe G2 channels above that. It's all ordering dependent. While there might be some problems in the channel management, you're barking up the wrong tree here. This stuff worked fine before, and the driver has undergone zero changes in terms of the DMA code since then. |
|
From: Adrian M. <ad...@ne...> - 2007-07-16 20:40:49
|
On Mon, 2007-07-16 at 07:42 +0900, Paul Mundt wrote: > On Sun, Jul 15, 2007 at 07:09:02PM +0100, Adrian McMenamin wrote: > > It appears it is not the sh_dmac code which is to blame, but the > > pvr2_dma code. If I fix the build to exclude pvr2_dma.c, the Dreamcast > > will boot with CONFIG_NR_ONCHIP_DMA_CHANNELS set correctly (ie to 4) > > > CONFIG_NR_ONCHIP_DMA_CHANNELS should be 4 for this, yes. > CONFIG_NR_DMA_CHANNELS should be 9, as per the Kconfig entry. > > > Plainly the pvr code is broken when it tries to take channel 4, not sure > > why though, will have a deeper look. > > > How do you reach that conclusion? The pvr code is requesting the first > channel of the pvr2 DMAC. SH DMAC channels are mapped to virtual channels > 0 - 3, pvr2 at 4, andthe G2 channels above that. It's all ordering > dependent. > > While there might be some problems in the channel management, you're > barking up the wrong tree here. This stuff worked fine before, and the > driver has undergone zero changes in terms of the DMA code since then. OK, I've made sure that the modules are compiled and loaded in the right order, and built pvr2fb as a module - get this now: Builds with correct number of channels: [ 0.036116] DMA: Registering DMA API. [ 0.036203] DMA: Registering sh_dmac handler (4 channels). [ 0.038616] DMA: Registering pvr2_dmac handler (1 channel). [ 0.039326] DMA: Registering g2_dmac handler (4 channels). But oopses on attempt to load module - don't know if this is a toolset problem or code: / # modprobe pvr2fb [ 74.814053] Fault in unaligned fixup: 0000 [#1] [ 74.817984] Modules linked in: pvr2fb cfbcopyarea cfbimgblt cfbfillrect [ 74.824808] [ 74.826344] Pid : 713, Comm: modprobe [ 74.831211] PC is at request_dma+0x2a/0x84 [ 74.835429] PC : 8c10f96e SP : 8c1fbea8 SR : 400080f1 TEA : c0103be4 Not tainted [ 74.843601] R0 : 00000000 R1 : 00000001 R2 : 8c1e20d0 R3 : 8c1e20d0 [ 74.850428] R4 : 00000004 R5 : c010f11c R6 : 00000000 R7 : 8c1fbd98 [ 74.857253] R8 : ffffffea R9 : 00000000 R10 : 00000000 R11 : c010f11c [ 74.864082] R12 : c0110244 R13 : 8cd21998 R14 : c0109000 [ 74.869557] MACH: 00000245 MACL: 00000005 GBR : 00000000 PR : 8c10f95e [ 74.876368] [ 74.876395] Call trace: [ 74.880507] [<c01000b8>] pvr2fb_dc_init+0x9c/0x108 [pvr2fb] [ 74.886261] [<c010018c>] pvr2fb_init+0x68/0xb8 [pvr2fb] [ 74.891644] [<8c02e4be>] sys_init_module+0xfba/0x1090 [ 74.896857] [<8c174ee4>] mutex_unlock+0x0/0x40 [ 74.901438] [<8c174ee4>] mutex_unlock+0x0/0x40 [ 74.906061] [<8c007244>] syscall_call+0xc/0x10 [ 74.910604] [<8c02d504>] sys_init_module+0x0/0x1090 [ 74.915645] [ 74.917161] Process: modprobe (pid: 713, stack limit = 8c1fa001) [ 74.923360] Stack: (0x8c1fbea8 to 0x8c1fc000) [ 74.927840] bea0: c01000b8 ffffffed 00000000 c010fd54 c010fd6c c010018c [ 74.936372] bec0: 8c02e4be c010aa8c 8c174ee4 c011015c c01100a0 8c174ee4 00000000 00000000 [ 74.944905] bee0: 00000000 00000000 004160c8 c010a9e4 8cd1b7c0 c010bbdc 00000011 00000012 [ 74.953438] bf00: 00000000 00000000 00000000 0000000b 00000000 00000007 00000000 00000000 [ 74.961971] bf20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000006f [ 74.970505] bf40: 0000006f 00000000 00000001 00000000 00000000 00000000 00000000 00000013 [ 74.979038] bf60: 00000174 00000028 c0109030 c0109030 c0109030 c0109030 000002f8 8c1793e8 [ 74.987571] bf80: 8c007244 7bf5fadc 00418290 295e2490 ffffff0f 00000001 8c1fbff8 8c02d504 [ 74.996104] bfa0: 0000308d 00400ef8 7bf5fadc 00000080 29560000 0000308d 004160c8 004160c8 [ 75.004637] bfc0: 00000000 00000000 00000000 004160b8 295e2490 00418290 7bf5fadc 7bf5fadc [ 75.013170] bfe0: 2959862e 00402b48 00008001 00000000 00000210 07ab98f7 00000054 00000160 Segmentation fault |
|
From: Paul M. <le...@li...> - 2007-07-16 21:08:58
|
On Mon, Jul 16, 2007 at 09:40:03PM +0100, Adrian McMenamin wrote: > On Mon, 2007-07-16 at 07:42 +0900, Paul Mundt wrote: > > While there might be some problems in the channel management, you're > > barking up the wrong tree here. This stuff worked fine before, and the > > driver has undergone zero changes in terms of the DMA code since then. > > OK, I've made sure that the modules are compiled and loaded in the right > order, and built pvr2fb as a module - get this now: > > Builds with correct number of channels: > > [ 0.036116] DMA: Registering DMA API. > [ 0.036203] DMA: Registering sh_dmac handler (4 channels). > [ 0.038616] DMA: Registering pvr2_dmac handler (1 channel). > [ 0.039326] DMA: Registering g2_dmac handler (4 channels). > > But oopses on attempt to load module - don't know if this is a toolset > problem or code: > What happens if you have pvr2fb built in, does it simply reboot? > / # modprobe pvr2fb > [ 74.814053] Fault in unaligned fixup: 0000 [#1] > [ 74.817984] Modules linked in: pvr2fb cfbcopyarea cfbimgblt > cfbfillrect > [ 74.824808] > [ 74.826344] Pid : 713, Comm: modprobe > [ 74.831211] PC is at request_dma+0x2a/0x84 > [ 74.835429] PC : 8c10f96e SP : 8c1fbea8 SR : 400080f1 TEA : > c0103be4 Not tainted That's certainly not good. I suppose I'll have to plug in some dummy DMACs and hash out where things went wrong. I'll take a look at it later today. Should also probably redo the dependencies so we're not able to artificially change the number of channels (or better yet, let the platform device take care of it). |
|
From: Adrian M. <ad...@ne...> - 2007-07-16 21:56:06
|
On Tue, 2007-07-17 at 06:08 +0900, Paul Mundt wrote:
>
> That's certainly not good. I suppose I'll have to plug in some dummy
> DMACs and hash out where things went wrong. I'll take a look at it later
> today.
>
> Should also probably redo the dependencies so we're not able to
> artificially change the number of channels (or better yet, let the
> platform device take care of it).
Finally managed to test this properly with earlyprintk - here is the
output - much as with the module insertion:
Linux version 2.6.22-gc2dc1ad5 (adrian@bossclass) (gcc version 3.4.6)
#10 PREEMPT Mon Jul 16 22:52:32 BST 2007
console [sercon0] enabled
Booting machvec: Sega Dreamcast
Node 0: start_pfn = 0xc000, low = 0xd000
Zone PFN ranges:
Normal 49152 -> 53248
early_node_map[1] active PFN ranges
0: 49152 -> 53248
Built 1 zonelists in Zone order. Total pages: 4064
Kernel command line: console=ttySC1,115200 panic=3 root=/dev/nfs rw
nfsaddrs=192.168.61.55:192.168.61.50:192.168.61.50: earlyprintk=serial
PID hash table entries: 64 (order: 6, 256 bytes)
Using tmu for system timer
Using 12.469 MHz high precision timer.
Console: colour dummy device 80x25
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 14104k/16384k available (1499k kernel code, 444k data, 72k init)
PVR=040205c1 CVR=00000000 PRR=00000000
I-cache : n_ways=1 n_sets=256 way_incr=8192
I-cache : entry_mask=0x00001fe0 alias_mask=0x00001000 n_aliases=2
D-cache : n_ways=1 n_sets=512 way_incr=16384
D-cache : entry_mask=0x00003fe0 alias_mask=0x00003000 n_aliases=4
Mount-cache hash table entries: 512
CPU: SH7750
NET: Registered protocol family 16
DMA: Registering DMA API.
DMA: Registering sh_dmac handler (4 channels).
DMA: Registering pvr2_dmac handler (1 channel).
DMA: Registering g2_dmac handler (4 channels).
Autoconfig PCI channel 0x8c1e23f0
Scanning bus 00, I/O 0x01001600:0x01003600, Mem 0x01840000:0x01848000
00:00.0 Class 0200: 11db:1234 (rev 10)
I/O at 0x01001600 [size=0x100]
Mem at 0x01840000 [size=0x100]
PCI: Fixing up device 0000:00:00.0
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: 512 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 512 bind 512)
TCP reno registered
sq: Registering store queue API.
Total HugeTLB memory allocated, 0
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Fault in unaligned fixup: 0000 [#1]
Modules linked in:
Pid : 1, Comm: swapper
PC is at request_dma+0x2a/0x84
PC : 8c10d666 SP : 8c255e70 SR : 400000f1 TEA : 0000001a Not
tainted
R0 : 00000000 R1 : 00000001 R2 : 8c1e2210 R3 : 8c1e2210
R4 : 00000004 R5 : 8c1b0394 R6 : 000000c6 R7 : 8c247ee8
R8 : ffffffea R9 : 00000000 R10 : 00000000 R11 : 8c1b0394
R12 : ffffffed R13 : 8c1fb468 R14 : 00000000
MACH: 00000000 MACL: 00000005 GBR : 00000000 PR : 8c10d656
Call trace:
[<8c1f26e8>] pvr2fb_dc_init+0x9c/0x108
[<8c1f298a>] pvr2fb_init+0x236/0x26c
[<8c063018>] ifind+0x14/0x98
[<8c0127f4>] acquire_console_sem+0x0/0xb4
[<8c087884>] sysfs_ilookup_test+0x0/0xa
[<8c06310a>] ilookup5_nowait+0x2a/0x44
[<8c0879d8>] sysfs_addrm_finish+0x18/0x248
[<8c0878b8>] sysfs_addrm_start+0x2a/0x9e
[<8c086d6e>] sysfs_add_file+0x56/0xc0
[<8c0127f4>] acquire_console_sem+0x0/0xb4
[<8c1f25ae>] fb_console_init+0xae/0x134
[<8c0127f4>] acquire_console_sem+0x0/0xb4
[<8c1ea848>] kernel_init+0x90/0x244
[<8c0035e4>] kernel_thread_helper+0x4/0x10
[<8c1ea7b8>] kernel_init+0x0/0x244
[<8c0035e0>] kernel_thread_helper+0x0/0x10
Process: swapper (pid: 1, stack limit = 8c254001)
Stack: (0x8c255e70 to 0x8c256000)
5e60: 8c1f26e8 8c208644 00000000
8c1dd8f4
5e80: 8c1dd90c 8c1f298a 8c205cd4 8c291508 00000002 8c1b0038 00000000
8c1dd8c0
5ea0: 8c254000 8c247998 00000000 8c1afe54 00000000 8c29e4c0 8c1afe54
00000000
5ec0: 8c063018 8c1fb464 8c0127f4 8c2085b4 8c2915b4 8c087884 8c254000
8c06310a
5ee0: 8c0879d8 8c244a00 00000000 8c0878b8 8c086d6e 8c1fb464 8c0127f4
8c2085b4
5f00: 8c2915b4 8c1dd8c0 8c2914e4 8c2915b4 00000000 00000000 8c1f25ae
8c0127f4
5f20: 8c2085b4 8c2085bc 00000000 00000000 8c1ea848 00000000 00000000
00000000
5f40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
5f60: 00000000 00000000 00000000 00000000 00000001 00000000 00000000
00000000
5f80: 8c0035e4 00000000 00000000 00000000 00000000 00000000 00000000
00000000
5fa0: 00000000 00000000 00000000 00000000 00000000 8c1ea7b8 00000000
00000000
5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
8c255fa0
5fe0: 8c0035e0 00000000 40000000 00000000 00000000 00000000 00000000
00000000
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 3 seconds..
|
|
From: Adrian M. <ad...@ne...> - 2007-07-16 22:28:30
|
More on this...
Code seemed to be failing on this:
if (atomic_xchg(&channel->busy, 1))
atomic_xchg expands out to this:
#define atomic_xchg(v, new) (xchg(&((v)->counter), new))
and in sh xchg expands out to this:
#define xchg(ptr,x) \
((__typeof__(*(ptr)))__xchg((ptr),(unsigned long)(x), sizeof(*(ptr))))
But this has a slightly different format in other archs - eg i386:
#define xchg(ptr,v) ((__typeof__(*(ptr)))__xchg((unsigned long)(v),(ptr),sizeof(*(ptr))))
arm -
#define xchg(ptr,x) \
((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
MIPS
#define xchg(ptr,x) ((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
So I wondered if it was the reversal of the params that was the issue and did this quick and very dirty hack ---
#define xchg(ptr,x) \
((__typeof__(*(ptr)))__xchg((ptr),(unsigned long)(x), sizeof(*(ptr))))
#define xchg_dma(ptr, x) \
((__typeof__(*(ptr)))__xchg((unsigned long)(x),(ptr),sizeof(*(ptr))))
and changing atomic_chg to this:
#define atomic_xchg(v, new) (xchg_dma(&((v)->counter), new))
But, as with most quick and dirty hacks, it didn't work...
Linux version 2.6.22-gc2dc1ad5-dirty (adrian@bossclass) (gcc version 3.4.6) #12 PREEMPT Mon Jul 16 23:16:34 BST 2007
console [sercon0] enabled
Booting machvec: Sega Dreamcast
Node 0: start_pfn = 0xc000, low = 0xd000
Zone PFN ranges:
Normal 49152 -> 53248
early_node_map[1] active PFN ranges
0: 49152 -> 53248
Built 1 zonelists in Zone order. Total pages: 4064
Kernel command line: console=ttySC1,115200 panic=3 root=/dev/nfs rw nfsaddrs=192.168.61.55:192.168.61.50:192.168.61.50: earlyprintk=serial
PID hash table entries: 64 (order: 6, 256 bytes)
Using tmu for system timer
Using 12.469 MHz high precision timer.
Console: colour dummy device 80x25
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 14104k/16384k available (1499k kernel code, 444k data, 72k init)
PVR=040205c1 CVR=00000000 PRR=00000000
I-cache : n_ways=1 n_sets=256 way_incr=8192
I-cache : entry_mask=0x00001fe0 alias_mask=0x00001000 n_aliases=2
D-cache : n_ways=1 n_sets=512 way_incr=16384
D-cache : entry_mask=0x00003fe0 alias_mask=0x00003000 n_aliases=4
Mount-cache hash table entries: 512
CPU: SH7750
NET: Registered protocol family 16
DMA: Registering DMA API.
DMA: Registering sh_dmac handler (4 channels).
Fault in unaligned fixup: 0000 [#1]
Modules linked in:
Pid : 1, Comm: swapper
PC is at request_dma+0x2e/0x88
PC : 8c10d66a SP : 8c255f30 SR : 400000f1 TEA : 00000001 Not tainted
R0 : 00000000 R1 : 00000001 R2 : 8c24c538 R3 : 40000001
R4 : 00000084 R5 : 00000084 R6 : 00000004 R7 : 8c24c400
R8 : 8c24c508 R9 : 00000000 R10 : 8c1e22f0 R11 : 8c1b2fec
R12 : 00000000 R13 : 8c1fb370 R14 : 00000000
MACH: 00000000 MACL: 00000108 GBR : 00000000 PR : 8c10d656
Call trace:
[<8c1f403a>] pvr2_dma_init+0x12/0x34
[<8c1ea848>] kernel_init+0x90/0x244
[<8c0035e4>] kernel_thread_helper+0x4/0x10
[<8c1ea7b8>] kernel_init+0x0/0x244
[<8c0035e0>] kernel_thread_helper+0x0/0x10
Process: swapper (pid: 1, stack limit = 8c254001)
Stack: (0x8c255f30 to 0x8c256000)
5f20: 8c1f403a 00000000 00000000 00000000
5f40: 00000000 8c1ea848 00000000 00000000 00000000 00000000 00000000 00000000
5f60: 00000000 00000000 00000000 00000000 00000001 00000000 00000000 00000000
5f80: 8c0035e4 00000000 00000000 00000000 00000000 00000000 00000000 00000000
5fa0: 00000000 00000000 00000000 00000000 00000000 8c1ea7b8 00000000 00000000
5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8c255fa0
5fe0: 8c0035e0 00000000 40000000 00000000 00000000 00000000 00000000 00000000
Kernel panic - not syncing: Attempted to kill init!
Rebooting in 3 seconds..
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X