P8X32A - Clarification on boot sequence details.

Wossname

Does anyone know of any official / unofficial information regarding the gory details of the Propeller's startup sequence?

I think I've worked it out based on reading through the various files we've collected so far. I reckon it goes like this but I have a few question marks over a couple of details...

• 1. VCC applied to Propeller
• 2. The "booter" PASM code is copied from ROM into Cog0 and executed immediately. (I don't know the mechanism behind this PASM insertion and cog activation, is this code transfer hard-wired in the silicon?).
• 3. If the booter is happy with the data it receives from the EEPROM or the serial port then it loads the SPIN interpreter (496 longs of bytecode) from ROM (0xf004 onwards) into Cog0 and configures its PAR address with the settings to begin interpreting the "runner" SPIN bytecode which resides in ROM.
• 4. The runner code sets up the stack and a few other important values so that the SPIN interpreter can be re-used to run the user's custom code.
• 5. The SPIN interpreter is reloaded into Cog0 and runs the user's code. (I can't seem to find the jump associated with this)
• 6. The user's code does whatever it likes, including spawning other cogs and generally having a great time.

Is this vaguely close? It seem to me that the "booter" code is entirely self-contained and needs no setting-up or parameters, for instance it doesn't use the PAR register.

I must say that looking into the intricacies of the Propeller has doubled my already considerable respect for the P8X32A. It is a very elegant system.

Seairth

Take a look at https://github.com/parallaxinc/Propeller_1_Design

it doesn't get any more detailed than that!

Wossname

I've had a look at that already. I'm afraid I am not well versed in FPGA technology, alas. I don't know how to answer my questions based on that information.

I'm not trying to implement anything at the moment, just trying to understand in my head, the process the Prop goes through.

Mike Green

#2 Look at section 3.1 of the Propeller Datasheet which describes the start-up sequence. Everything done in #1 is done by hardware. Cog 0 is started by the hardware by essentially forcing a COGINIT instruction to copy the bootloader from ROM to Cog 0's RAM, initialize the cog's registers, then start the bootloader at cog RAM location zero. Everything else is done by the bootloader or the interpreter which is loaded from ROM on top of the bootloader. runner is additional initialization code essentially written in Spin and hand translated into Spin bytecodes. It's loaded with the interpreter and finishes the Spin program's initialization.

Wossname

Post deleted.

Mike Green

The "forced COGINIT" is not an instruction that appears anywhere. There's a state machine in the hardware that is triggered by a reset. At a certain point, the instruction register is effectively forced to contain a COGINIT instruction and the source and operands are set up to use cog 0 and the address of booter in ROM.

The Spin interpreter and booter are encrypted in the ROM. That's why you can't find them. There's additional hardware in the hub that decrypts these if they're being copied from ROM to cog RAM by a COGINIT. This was done to try to prevent them from being stolen. Eventually this fostered a contest to try to defeat the encryption. This was done and Chip released the source codes as the prize.

Wossname

Hi again Mike,

Sorry I deleted my post before you posted yours. Yes you're right of course.

I deleted my post out of frustration with 1) myself and 2) the ongoing "Documentation Nightmare".

SaucySoliton

I had to figure this out when I was doing some experiments with pre-loading code into the FPGA ram. I haven't investigated past step 2. The Verilog (and ROM source code) is the definitive Propeller reference. It could use a lot more comments in some parts. The part where I say "almost certainty," I just took an educated guess instead spending more time to be 100% certain.

nres goes low (external input)
cog_e is set to enable only cog 0 (hub.v:218)
cog_ena is set to all cogs off (hub.v:224)
ptr is set to 0xF800>>2 (cog.v:212)
run is set to 0 (cog.v:241)
nres goes high (external input)
ena_bus starts oscillating (dig.v:61)
cog_ena is set to enable only cog 0 (hub.v:226)

cog_start is almost certainly 0, masking out num_dcd

this mask is inverted to all ones

so, cog_ena is set to cog_e

cog state machine starts (cog.v:227)
since run=0, instructions are replaced with RDLONG p,0 (cog.v:420)
since run=0, bus_a is replaced with (ptr+p)<<2 (cog.v:492)

last 2 address bits are ignored for RDLONG

the s[1:0] bits pass regardless of run [saves logic?]

alu zeros data for last 16 registers (cog_alu.v:144)
when p reaches 511, set run to 1 (cog.v:244)

jmg

Wossname wrote: »

• 1. VCC applied to Propeller
• 2. The "booter" PASM code is copied from ROM into Cog0 and executed immediately. (I don't know the mechanism behind this PASM insertion and cog activation, is this code transfer hard-wired in the silicon?).

Is this vaguely close? It seem to me that the "booter" code is entirely self-contained and needs no setting-up or parameters, for instance it doesn't use the PAR register.

Yes, the ROM -> RAM has to be hard-wired in the silicon, so you can think of Prop as having many stages of booter..

ROM -> RAM is very small and almost invisible (Data sheet Current specs show 640us for this)
Loaded UART.EE Booter interacts with EE and RXD
Loading Spin is yet another 'boot' step...

The source code link given above mentions these 3 :
interpreter.src - begins at $F004
booter.src - begins at $F800
runner.src - butts up against $FFFF