Doesn't work for Rabbit 5000/6000

[spth]

I have tried OpenRabbit with the RCM5700 and RCM6700, but it hangs at

philipp@notebook6:~/OpenRabbit$ src/openrabbitfu --verbose --verbose coldboot/coldload.bin coldboot/pilot.bin examples/hello/hello-RCM4110.bin /dev/ttyUSB3
Reset Rabbit.
loaded 831 bytes from coldboot/coldload.bin
Sending initial loader.
set baudrate to 2400
sending 276 initial loader triplets
set baudrate to 57600
loaded 5517 bytes from coldboot/pilot.bin
Secondary loader format detected as Dynamic C 9
Sending secondary loader.
^C

By contrast, OpenRabbit works for me for various Rabbit 2000/3000/4000 boards.

[spth]

I suspect that our initial loader's clock frequency detection does not work for the Rabbit 5000/6000, and thus the baud rate gets set incorrectly. We use a timing loop (just like Dynamic C 9 does):

; MPL 2.0 code
wait_for_zero:
	ioi
	ld	(RTC0R), a                   ; fill RTC registers
	ioi
	ld	hl, (RTC0R)                  ; get lowest two RTC regs
	and	hl, de                       ; mask off bits
	jr	nz, wait_for_zero            ; wait until bits 0-9 are zero

timing_loop:
	inc	bc                           ; increment counter
	push	bc                           ; save counter
	ld	b, #0x98                     ; empirical loop value
		                             ; (timed for 2 wait states)
	ld	hl, #WDTCR
delay_loop:
	ioi
	ld	(hl), #0x5a                  ; hit watchdog
	djnz	delay_loop
	pop	bc                           ; restore counter
	ioi
	ld	(RTC0R), a                   ; fill RTC registers
	ioi
	ld	hl, (RTC0R)                  ; get lowest two RTC regs
	bit	2, h                         ; test bit 10
	jr	z, timing_loop               ; repeat until bit set

In the delay_loop, we have djnz, which takes 5 cycles on Rabbit 2000/3000/4000, but takes 6 cycles on Rabbit 5000/6000.
We could try modifying the loop to use dec b, jp nz, delay_loop since that sequence has the same timing on all Rabbits (as long as 8-bit memories are used), or try to switch to a timer-based approach, like Dynamic C 10 does.

[spth]

Hmm. I've tried a jp-based delay_loop, but the result is still the same - works for me on Rabbit 4000, but not Rabbit 5000:

	ld	hl, #WDTCR
	ld	b, #0x73                     ; empirical loop value (timed for 2 wait states)
delay_loop:
	ioi
	ld	(hl), #0x5a                  ; hit watchdog
	dec	b
	jp	nz, delay_loop

[tomlogic]

I think the documentation about Dynamic C 10's "cold boot" will help. You should make use of the cold loader and pilot BIOS files that were written for the 4000/5000/6000. The .bin files referenced in the readme appear in the Bios directory.

[spth]

I'm aiming for automatic support of Rabbit 2000 to Rabbit 6000, so the user doesn't have to specify which Rabbit is connected. I see that Dynamic C 10 does detection of Rabbit 4000 vs. Rabbit 5000/6000 by setting the lowest two bits of MB0CR to 3 (to check for the internal RAM of Rabbit 5000/6000). I guess being able to detect internal RAM would be a good next step forward OpenRabbit, too. Then we setup RAM, then send our old coldload.bin (which will only work for 8-bit memory and at most 1 MB of memory, and parallel memory only, but that should already get us to RCM5700 support). To support RCM with serial flash or 16-bit memories, or more than 1 MB of total memory, we'd then need to replicate more of the Dynamic C 10 bootstrapping.

According to the documentation, setting the lowest two bits of MB0CR to 3 has the following effect:

Rabbit 2000 - use /CS2
Rabbit 3000 - "reserved and should not be used"
Rabbit 4000 - "reserved and should not be used"
Rabbit 5000 - use /CS3 (i.e. internal RAM)
Rabbit 6000 - use /CS3 (i.e. internal RAM)

Since Dynamic C does it on the Rabbit 4000, I guess we can assume it to be safe there. That leaves the Rabbit 3000 as a possible problem, but I'll see what I'll find.

P.S.: Or we could just directly go for processor type detection? After all, we need a small helper program anyway, so that one might as well just read the CPU identifier bits in GCPU. We'd need to distinguish between Rabbit 2000/3000, 4000, 5000/6000, and can get one bit out (via status line) for each test program run, so this could be done with two test program runs. Then we wouldn't need the MB0CR trick for processor type detection.
P.P.S.: Ah, but we don't know where the RAM is, so we can't just execute any test program. Back to the MB0CR trick, I guess.

[Colonel-Bleep]

I don’t think that dc10 supports 3000 and below. Needs dc9, unless something changed.

[tomlogic]

At one point, Dynamic C 10 was going to support the 2000/3000 products. You can see that legacy in the "Lib" directory having a separate Rabbit2000_3000 subdirectory that wasn't removed until the 10.72 release.

Note that the RFU program from Dynamic C 10 supports all of the Rabbit processors, but you need to tell it whether you're doing 2000/3000 (and using the DC9-based loader/pilot) or 4000/5000/6000 (and using DC10-based loader/pilot).

[spth]

I don’t think that dc10 supports 3000 and below. Needs dc9, unless something changed.

My personal vision for openrabbitfu is as a simple, free tool to write and read the flash memory of all Rabbits, that works well on modern OSes. In the long term, I'd also see a tool for on-target debugging with gdb on all Rabbits (which might be openrabbit or something else, e.g. OpenOCD-based). I see Openrabbit as part of a free toolchain targeting the Rabbits. Since SDCC will make substantial steps towards better Rabbit support this year, OpenRabbit should try to keep up a bit, and adding Rabbit 5000/6000 support is part of that.

IMO, a good first step will be to allow the user to select the RAM location via a command-line option, then autodetection of the RAM location (CS0 vs. CS1 vs. CS2 vs CS3). This should already allow us to write the Flash on the RCM5700, RCM5710, RCM5750, RCM5760 and read out the processor type and revision on all Rabbits (unless they use 16-bit RAM).

At that point, we'd still use the pilot from Dynamic C 8 / 9, and thus would be limited to 1 MB address space, 8-bit parallel memories. Our coldload.bin might have evolved away from the Dynamic C 8 / 9 one, and might look more like the Dynamic C 10 one, or something different. Next, we'd want our coldload.bin to either support 16-bit memories or have a separate one for 16-bit memories (like Dynamic 10 does), so we can also read out the processor type and revision on Rabbits with 16-bit RAM (e.g. RCM4000 and RCM4010). This, however, is a less important feature, since there are currently no plans for SDCC to support 16-bit memories.

Once we've reached that point, the obvious next steps would be support for an address space larger than 1MB, and support for serial flash. But serial Flash would also need support on the SDCC side.

To get beyond the 1MB boundary, for 16-bit memory support, for serial flash support, we might use the pilot from Dynamic C 10 or write our own replacement.

[spth]

A little bit of progress: I have the cold / initial loader, and to some degree the pilot / secondary loader working on the RCM5700:

philipp@notebook6:~/OpenRabbit$ src/openrabbitfu --run --serialout --ramcr 0x43 examples/hello/hello-RCM5700.bin /dev/ttyUSB0
Sending initial loader.
Secondary loader format detected as Dynamic C 9
Sending secondary loader.
CPU:  0x0300 (Rabbit 5000)
Freq: 25000000
sectorSize: 0x0080
numSectors: 0x0013
flashSize:  0x0080

It then fails to upload the hello-RCM5700.bin, though. And on an RCM6710, it doesn't even get that far:

philipp@notebook6:~/OpenRabbit$ src/openrabbitfu --verbose --run --serialout --ramcr 0x43 examples/hello/hello-RCM5700.bin /dev/ttyUSB0
Reset Rabbit.
Sending initial loader.
Sending 276 initial loader triplets.
Secondary loader format detected as Dynamic C 9
Sending secondary loader.
pilot.csum 0xe2 != csum 0x90

Still, this is some progress, and once I've cleaned up the code a bit, and tested that the changes don't break Rabbit 2000 - 4000 support, I'll commit it.

[spth]

Details on what I see for the RCM5700 (with it slow clock speed and parallel Flash, the RCM5700 looks most similar to earlier RCM, so I thought I'd get somewhere using the approach that works for earlier RCM):

hilipp@notebook6:~/OpenRabbit$ src/openrabbitfu --ramcr 0x43 --verbose --verbose --verbose --run --serialout examples/hello/hello-RCM5700.bin /dev/ttyUSB1
Reset Rabbit.
Sending initial loader.
flushing data for baudrate set
set baudrate to 2400
Sending 360 initial loader triplets.
flushing data for baudrate set
set baudrate to 57600
Secondary loader format detected as Dynamic C 9
Sending secondary loader.
sending 5517 secondary loader bytes.
Negotiating baudrate.
flushing data for baudrate set
set baudrate to 57600
flushing data for baudrate set
set baudrate to 57600
flushing data for baudrate set
set baudrate to 57600
parsed 140 bytes
CPU:  0x0300 (Rabbit 5000)
Freq: 25000000
sectorSize: 0x0080
numSectors: 0x0013
flashSize:  0x0080
Flash speed: 70 ns
RAM speed: 15 ns
loaded 1166 bytes from examples/hello/hello-RCM5700.bin
warning: received NAK for subtype 0x43in... 0% (bps: in=0, out=0)

So we see that we get to the percentage display, but fail at 0% already. Looking at src/rabbit.c, that apparently means erasing the flash apparently succeeds, but writing the flash fails immediately. Looking at the secondary / pilot loader, in the part about writing the flash, we see

	push	ip
	ipset	3						; turn off interupts while in the flash-writer!
	call	FSM_XFlash			; write it all!
	pop	ip						; restore interrupts

	ld		a, 0x72				; restore XPC value for 1st flash
	ld		(_FlashInfo+flashXPC), a

	ex		de, hl
	bool	hl
	ld		l, h									; ensure HL is zero, enable
	ld		(_overwrite_block_flag), hl	;  ID/User Blocks protection
	ex		de, hl

	bool	hl
	jr		nz,._PB_WRITENak

but that FSM_XFlash called is over in the DC9 library (https://github.com/digidotcom/DCRabbit_9/blob/master/Lib/BIOSLIB/FLASHWR.LIB). Still I haven't found out, why what works with Rabbit 2000 - 4000 doesn't work for the Rabbit 5000 - based RCM5700. Is something different in the Rabbit 5000? Is it about how the flash is set up in the RCM5700 (I haven't found schematics for the RCM5700)?

P.S.: I found something that looks like it might be the problem: the pilot, when receiving the FLASHDATA packet, writes values for the MBxCRShadow registers, including the ones for RAM. If the flash driver actually uses those to write the MBxCR registers (which I'm not sure about), we'd overwrite the MB0cr for the RAM the pilot is executing from. Though if that happens I wonder how the pilot still manages to send a NAK.

[tomlogic]

Here's the schematics for the RCM5700, in case you find that helpful.

RCM5700 Schematic (090-0268).pdf

You could compare the bootstrapping sequence from Dynamic C 10 to the one from Dynamic C 9 to see if there are key differences.

Doesn't the Rabbit 5000 chip include built-in RAM? Check the data sheet on that. I think bootstrapping makes use of it for at least part of the process. It might not be large enough to hold the full Pilot BIOS.

[spth]

Thanks. I'll check the schematic, to see if it offers any hint at what might go wrong. The Rabbit 5000 has built-in RAM, and the RCM5700 has no other RAM. The amount of internal RAM is 128K, i.e. the same as the external RAM on the RCM2020 board, which works with OpenRabbit.

[spth]

While I still have hope for the Rabbit 5000, I don't think the current approach would work for the Rabbit 6000: the Rabbit 6000 internal RAM is apparently 16-bit mode only, and I think using 16-bit mode would require substantial changes.

P.S.: It looks like my primary loader is working reliably for the Rabbit 5000, using the internal memory in 8-bit mode. It does not work on the Rabbit 6000. The secondary loader (from Dynamic c 9) is barely working on the Rabbit 5000 (it can send CPU/Flash/RAM info on RCM with parallel flash, such as the RCM5700, but can't write the flash there, and won't work at all on other RCM, e.g. RCM5600W).
I guess anything beyond this will indeed require a more Dynamic C 10 - like approach. I think I'll leave that for a future 0.3.0, and for now focus on comitting and releasing what I have found so far as 0.2.5.

[tomlogic]

It's possible that 16-bit mode would only impact the memory configuration registers. IIRC, the bootstrapping process identifies 16-bit memories only to figure out register settings.

I wrote up fairly detailed documentation on the Dynamic C 10 bootstrapping process. But I understand if it's something that needs to wait for a future release.

[spth]

I'd also like to make writes to the RCM5700 8-bit parallel flash work before looking into 16-bit memories. I've tried to read out the first 512KB of the Flash I'm trying to write with OpenRabbit, and it looks like it is all 0xff (except for a few dozen bytes at the end), both before and after the write attempt.
Also, the flash info reported looks a bit odd to me (same data as before):

CPU:  0x0300 (Rabbit 5000)
Freq: 25000000
sectorSize: 0x0080
numSectors: 0x0013
flashSize:  0x0080
Flash speed: 70 ns
RAM speed: 15 ns

19 sectors matches the data sheet. But the size doesn't make sense (no single size would make sense - according to the data sheet the Spansion AL008D chip on the RCM5700 has sectors of 4 different sizes. Also, the total flash size according to RCM5700 documentation and Spansion datasheet is 1MB, not 128 KB.
According to the datasheet, this flash should erase to all 0x00 (instead of the AFAIK common all 0xff), so I'm not sure if the write itself fails, or it is actually the preceding erase that isn't working.

[spth]

Regarding "only figure out register settings" - Dynamic C 10 also uses three different coldloaders - the "normal" one, the "16 bit" one, and the "serial flash" one. I haven't looked into them in details, though I wonder why there is a separate one for serial flash - after all, AFAIK, the primary loader / coldloader is only meant to bring the secondary loader / pilot into RAM.