It is strange that the new code (which is omitting the index parameter) does also work on the Rev.B chip, so it appears to be backwards compatible. I asked Atmel about this but they are not getting back to me. How is this possible?
According to "Procedure Call Standard for the ARM Architecture" document, when calling a subroutine using C, the parameters are passed left to right, and through registers r0 - r4 (up to 4). So I suppose in the Rev.B ROM code, "index" was expected to be in r0, and "command" was expected to be in r1. In Rev.C ROM code, "index" is omitted, so "command" is expected to be in r0.
It makes sense that I need to make the code change above to get it to work in Rev.C, but how in the world does it work on the Rev.B chip, if it expects the "command" in r1 but it is actually passed in r0?
Am I missing something here? I know I should be happy that it works, but I would like to understand why, and make sure there are no problems down the road...

hello micha,
if you have a jtag ice you can try to single step the rom code to see how it works.

regards
gerhard

ok, while doing that I solved the mystery:

The Rev B chip never actually calls that function, because it doesn't have it on the S chip (the ones with only one memory bank?!):

// Check if IAP function is implemented (opcode in SWI != 'b' or 'ldr') */
if ((((((unsigned long) IAP_PerformCommand >> 24) & 0xFF) != 0xEA) &&
(((unsigned long) IAP_PerformCommand >> 24) & 0xFF) != 0xE5)) {

IAP_PerformCommand((0x5A << 24) | (argument << 8) | command);
return (pEfc->EFC_FSR & (AT91C_MC_LOCKE | AT91C_MC_PROGE));
}

it is not running into this block on the RevB chip, only on RevC. Then, it is calling IAP_PerformCommand with an extra parameter and that fails, because the chips with one bank apparently only expect one parameter.

ok I can now sleep at night, thanks everyone.