06 August 2014, 13:38 | #21 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
Quote:
I think at least following tests should be done: - Does clearing bit 0 of REG_LOCK do anything at all? What if exact same sequence is done (write 0x85 to IPL_EMU four times, then clear REG_LOCK). - Can P5_DISABLE_INT be modified when PPC is active. Nothing happens when I try to change it, bit always stays set. And does it really stop interrupts? - Can M68K_IPLx values be modified. Don't seem to be possible at least under M68K CPU. (I assume they are always read-only) - Does SELF_RESET actually do anything at all? I also assume only phase5 and "official" p5 developers knew about that mysterious bit. For example WarpOS does not modify it. (At least I haven't noticed any accesses) |
|
06 August 2014, 15:17 | #22 | ||||
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,544
|
Quote:
Quote:
Btw. also thanks for helping Toni on this problem. Quote:
Quote:
Because, according to above link (check under "PowerASM)" he got access to prototype hardware, which allowed him to play with the PowerPC CPU's much time before endusers could buy the final hardware products. (and probably got some more infos about from board developer, I guess) Perhaps, but according the above project list, Sam might be also of help specially with his good knowledge about PowerPC (didnt he wrote PowerASM & WarpOS) and thus we will newer know if he is interested to project while it does not check, right ? (now we can only guess) Last edited by amilo3438; 06 August 2014 at 15:49. Reason: small corrections (as usual) |
||||
06 August 2014, 16:47 | #23 |
Italian Amiga Zealot
Join Date: Jan 2009
Location: Italy
Age: 36
Posts: 1,913
|
Not really sure of that - he posted it on a Wikipedia Talk page around 4 years ago.
Looks like he was back for a while in 2012 to work on UltimatePPC (which looks to be dead in the water) http://www.amiga.org/forums/showpost...&postcount=139 Now enough off-topic or Toni will punish us |
06 August 2014, 17:31 | #24 | |||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,539
|
Quote:
Quote:
Quote:
|
|||
06 August 2014, 17:48 | #25 | |
Amiga 500 User
Join Date: Jun 2013
Location: EU
Posts: 1,544
|
Quote:
Perhaps you re right. Anyway, as Toni just mentioned, WarpUP seems working fine! (great) |
|
06 August 2014, 22:22 | #26 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,539
|
Quote:
Quote:
When I bring P5_DISABLE_INT back to 1, when PowerUp is running, then all PPC processes are frozen. So it definitely has an effect on the PPC. The M68k interrupts are still working. |
||
08 August 2014, 19:46 | #27 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
I debugged some more and noticed that 68K code also modifies f60020 bit 0. And sometimes BPPC boot code and ppctest.dms powerup tests succeed, even if I ignore bit 0. It seems to be timing sensitive.
Not very optimal code.. Code:
68EB54CE 48e7 000e MOVEM.L A4-A6,-(A7) 68EB54D2 2a4e MOVEA.L A6,A5 68EB54D4 7001 MOVE.L #$00000001,D0 68EB54D6 b0ad 015c CMP.L (A5, $015c) == $6803555e,D0 68EB54DA 6610 BNE.B #$00000010 == $68eb54ec 68EB54DC 287c fff1 0082 MOVEA.L #$fff10082,A4 68EB54E2 4e71 NOP 68EB54E4 18bc 0040 MOVE.B #$40,(A4) 68EB54E8 4e71 NOP 68EB54EA 6026 BT .B #$00000026 == $68eb5512 68EB54EC 7002 MOVE.L #$00000002,D0 68EB54EE b0ad 015c CMP.L (A5, $015c) == $6803555e,D0 68EB54F2 6610 BNE.B #$00000010 == $68eb5504 68EB54F4 287c 00f6 0020 MOVEA.L #$00f60020,A4 68EB54FA 4e71 NOP 68EB54FC 18bc 0001 MOVE.B #$01,(A4) 68EB5500 4e71 NOP 68EB5502 600e BT .B #$0000000e == $68eb5512 68EB5504 287c 00f6 0020 MOVEA.L #$00f60020,A4 68EB550A 4e71 NOP 68EB550C 18bc 0001 MOVE.B #$01,(A4) 68EB5510 4e71 NOP 68EB5512 4cdf 7000 MOVEM.L (A7)+,A4-A6 68EB5516 4e75 RTS 68EB5518 48e7 000e MOVEM.L A4-A6,-(A7) 68EB551C 2a4e MOVEA.L A6,A5 68EB551E 7001 MOVE.L #$00000001,D0 68EB5520 b0ad 015c CMP.L (A5, $015c) == $6803555e,D0 68EB5524 6610 BNE.B #$00000010 == $68eb5536 68EB5526 287c fff1 0082 MOVEA.L #$fff10082,A4 68EB552C 4e71 NOP 68EB552E 18bc 00c0 MOVE.B #$c0,(A4) 68EB5532 4e71 NOP 68EB5534 6026 BT .B #$00000026 == $68eb555c 68EB5536 7002 MOVE.L #$00000002,D0 68EB5538 b0ad 015c CMP.L (A5, $015c) == $6803555e,D0 68EB553C 6610 BNE.B #$00000010 == $68eb554e 68EB553E 287c 00f6 0020 MOVEA.L #$00f60020,A4 68EB5544 4e71 NOP 68EB5546 18bc 0081 MOVE.B #$81,(A4) 68EB554A 4e71 NOP 68EB554C 600e BT .B #$0000000e == $68eb555c 68EB554E 287c 00f6 0020 MOVEA.L #$00f60020,A4 68EB5554 4e71 NOP 68EB5556 18bc 0081 MOVE.B #$81,(A4) 68EB555A 4e71 NOP 68EB555C 4cdf 7000 MOVEM.L (A7)+,A4-A6 68EB5560 4e75 RTS Code:
68EB54B6 48e7 0006 MOVEM.L A5-A6,-(A7) 68EB54BA 2a4e MOVEA.L A6,A5 68EB54BC 4cdf 6000 MOVEM.L (A7)+,A5-A6 68EB54C0 4e75 RTS 68EB54C2 48e7 0006 MOVEM.L A5-A6,-(A7) 68EB54C6 2a4e MOVEA.L A6,A5 68EB54C8 4cdf 6000 MOVEM.L (A7)+,A5-A6 68EB54CC 4e75 RTS |
08 August 2014, 21:50 | #28 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
Those two functions are in ppc.library but they are marked private between PPCSetAttrs and PPCCacheTrashE. Bah.
Quote:
ppc.library/1a4 exec.library/Remove ppc.library/1aa EDIT2: It has to be hardware semaphore. I think this problem is now solved. It would be interesting to see if you can lock yourself out by clearing the bit twice (Probably not) Last edited by Toni Wilen; 09 August 2014 at 08:47. |
|
10 August 2014, 18:45 | #29 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
P5_SELF_RESET function found: It is protected bit (need unlock sequence to set/reset it) and it needs to be cleared or P5_AMIGA_RESET bit does nothing.
For some reason display blanks for few seconds if I try to clear P5_AMIGA_RESET without P5_SELF_RESET, without reseting anything at all. Possibly something to do with Indivision AGA MK2. If P5_SELF_RESET is cleared, P5_AMIGA_RESET does reset whole system. P5_M68K_RESET does nothing, P5_SELF_RESET cleared or set. Perhaps it only works when P5_M68K_RESET is cleared by PPC CPU? I am not sure if it also needs P5_SELF_RESET. P5_AUX_RESET and P5_SCSI_RESET does not require P5_SELF_RESET bit. |
10 August 2014, 21:22 | #30 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,539
|
Quote:
Quote:
|
||
10 August 2014, 21:48 | #31 | |||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,539
|
Quote:
I reassured myself that P5_SELF_RESET is set. Then I cleared P5_AMIGA_RESET, and my A3000 resets. Quote:
Quote:
I'm using P5_M68K_RESET to stop the M68k when the NetBSD/amigappc kernel starts. As far as I can see this works fine. Otherwise the 68k would continue flashing the background colours, which it doesn't. This is how I launch the PPC kernel from the 68k: Code:
; reset PPC, which runs into our bootstrap routine at the Reset vector lea P5_BASE,a5 move.b #P5_CLR|P5_PPC_RESET,P5_REG_RESET(a5) nop move.b #P5_CLR|P5_ENABLE_IPL,P5_REG_INT(a5) nop move.b #$a8,P5_REG_ENABLE(a5) nop move.b #$10,P5_REG_ENABLE(a5) nop move.b #P5_SET|P5_DISABLE_INT,P5_IPL_EMU(a5) nop move.b #P5_SET|P5_PPC_RESET,P5_REG_RESET(a5) nop ; wait for the PowerPC to kill us... stop #$271f err: move.w #$888,$180(a6) move.w #$f00,$180(a6) bra err |
|||
10 August 2014, 22:11 | #32 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,539
|
Concerning P5_M68K_IPL:
These three bits are read-only and reflect the current IPL state on the mainboard. When an interrupt occurs, the PPC can read these bits to know which interrupt level it was. P5_PPC_IPL is for masking interrupt levels on the PPC. |
11 August 2014, 13:22 | #33 | ||||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
Quote:
Emulation does this and it seems to work. Quote:
Quote:
I can try to do A3000 test but I am not sure if I am bothered to set correct jumpers.. Quote:
|
||||
16 August 2014, 17:08 | #34 | |||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,539
|
Quote:
I inserted a printf in amiga_get_irq() in the NetBSD/amigappc kernel. It definitely prints the current interrupt level. Quote:
Quote:
|
|||
17 August 2014, 14:09 | #35 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
Quote:
Run PPC code that has as small loop as possible that takes at least 5+ seconds to finish, it must only modify CPU registers. After loop ends, save some status value ("loop done") to memory, exit. After PPC code has been started, m68k CPU should near immediately clear REG_LOCK bit 0. Wait 10 seconds, set REG_LOCK bit 0. If PPC code finishes immediately, CPU was still executing, CPU was stopped if it does not finish immediately. I expect it to be memory accesses blocking only, memory controller already needs to prevent simultaneous memory accesses from both CPUs. |
|
22 August 2014, 19:32 | #36 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,539
|
Ok, I did that. Unfortunately the result is not what you expected. Seems that the PPC is halted, and the rest of the loop continues after I have set bit 0 of REG_LOCK again (with the M68k).
Usually the code must run in the cache. I made the following PowerUp program: Code:
.text .globl start start: nop lis r3,0x1f0000@h li r0,0 stw r0,0(r3) li r0,-1 lis r4,0x80000000@h loop: subic. r4,r4,1 bne loop stw r0,0(r3) sync li r3,0 blr I made another interesting observation: when clearing bit 0 of REG_LOCK then it also locks out something else. I guess that Cyberstorm-SCSI is locked, because nothing happens anymore, when I access the disk. |
07 September 2014, 07:16 | #37 | |
Registered User
Join Date: Sep 2008
Location: Germany
Posts: 331
|
Quote:
I think it has something to do with the LACE, during WhichAmiga-tests the LACE is interruppted for a short moment, but enough to start the MKII-screenmode scanning (blank). |
|
07 September 2014, 08:29 | #38 |
Registered User
Join Date: Sep 2008
Location: Germany
Posts: 331
|
Regarding unaccessible pci-roms on grex-pci-bridges.
I found out that there might be some kind of mmu-protection around pci-devices used in a grex-board. Is not easy to get in touch with a rom from a installed pci-device (graphiccards). Following the pci-specs its easy to point the xrombar to somewhere in the (unused) memorymap and perform a read on it (to build a shadowrom). After reading the rom, the xrombar must be disabled and the normal bar must be reactivated for normal memoryaccess (graphicsmem). The grex-problem .... its possible to act normal with the xrombar and bar registers, but the rom is INVISIBLE. Now pci-specs told us, that you can read a rom or access the memory, but not both at the same time. So i decided to check what will happen, if i set the xrombar to the memarea where the (deactivated) bar is pointing to ... and voilà ... finally the pci-rom is visible! Pointing with xrombar to the same area like the deactivated bar (graphicsmem). Next steps are daily business ... copying the rom to somewhere in the ram .. disable xrombar, activated (mem)bar and so on ... I just send a message to Radoslaw (strim?) for the netbsd-grex-port. Maybe on day, the os4-team is able to handle a grex-pci-bridge. |
18 September 2014, 19:16 | #39 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,570
|
Unknown bits that MorphOS for classic sets very early in boot process (before hanging):
REG_IRQ (0xf60008) bit 5 is set. (Sets bit 3 and 5, clears 4) REG_INT (0xf60028) bit 2 is set. Must be some unknown interrupt "mode" or something.. |
19 September 2014, 02:50 | #40 | |
Registered User
Join Date: Aug 2008
Location: London / Canada
Posts: 781
|
Quote:
1/ move.l #$FFFE0000,a0 move.l (a0),d1 nop andi.l #$80000020,d1 2/ move.l #$FFFE0000,a0 moveq #2,d0 move.l d0,(a0) nop move.l #$FFFE0010,a0 moveq #1,d0 move.l d0,(a0) nop move.l #$FFFE0020,a0 moveq #1,d0 move.l d0,(a0) nop 3/ move.l #$FFFE0000,a0 move.l (a0),d7 nop clr.w d7 swap d7 lsr.l #8,d7 moveq #$F,d1 and.l d1,d7 moveq #2,d0 cmp.l d0,d7 bcs.b JL_0_31C move.l #$FFFE0040,a0 move.l d0,(a0) nop 4/ lea $FFFE0000,a1 nop move.l (a1),d2 nop swap d2 andi.l #$000000FF,d2 bne.b JL_0_20E4 nop clr.l $30(a1) nop move.l (a1),d2 nop andi.l #$00000003,d2 bne.b JL_0_20E4 nop move.l #$00000003,$30(a1) nop move.l (a1),d2 nop andi.l #$00000003,d2 cmpi.w #$0003,d2 bne.b JL_0_20E4 moveq #1,d0 JL_0_20DA move.l d1,8(a0) movem.l (sp)+,d2/a5-a6 rts JL_0_20E4 moveq #0,d0 5/ We are trying to preserve the information for the Amiga community so it is not lost as source code is lost or knowledge lost by people passing away, etc. I know it is a long shot, We suspect there are additional registers 020, 030, 040: 0xFFFE0000 = 2 (Endian swapper, write 0x02 to switch bridge into big endian mode) 0xFFFE0010 = 1 (Interrupt Enable - write 0x01 to enable Interrupts (INT2 on Amiga side) 0xFFFE0020 = 1 ? 0xFFFE0030 = 3 ? 0xFFFE0040 = 2 ? Any help you could give would be most appreciated.... |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
HELP cyberstormppc failure!!!!! | klapdeur | support.Hardware | 2 | 01 January 2010 13:02 |
Identifying CyberstormPPC | THX1138 | support.Hardware | 6 | 12 May 2007 17:00 |
CyberstormPPC card for A4000 | macce2 | MarketPlace | 71 | 13 February 2007 01:28 |
cyberstormPPC users, SCSI issues | superBuster | support.Hardware | 28 | 07 December 2006 20:36 |
For sale: CyberStormPPC 233 - 060/50 | martin-flash | MarketPlace | 13 | 16 June 2005 11:53 |
|
|