Cold boot code question
Seairth
Posts: 2,474
in Propeller 2
(moved from "Prop2 FPGA files!!!")
Chip,
Assuming your cold boot code has not changed, I have a few questions:
* During cold boot, is the hub egg-beater disabled?
* It looks like you are skipping the first ROM byte (it never gets written to hub ram). What's the intention?
* Also, is this mode of clkset only available during cold boot? Or can it be used to extract the ROM at any time?
* What's the purpose of the repeated coginit? Is this just to satisfy the pipeline instruction fetch?
Also, I think I see why you don't want to load the boot ROM at $1000. With only 8 instructions to initialize a cold boot, it's not possible to set up ptra, copy the ROM bytes, and restart. I have an idea on how to make that happen, but it depends on the answers to the above questions.
Chip,
Assuming your cold boot code has not changed, I have a few questions:
* During cold boot, is the hub egg-beater disabled?
* It looks like you are skipping the first ROM byte (it never gets written to hub ram). What's the intention?
* Also, is this mode of clkset only available during cold boot? Or can it be used to extract the ROM at any time?
* What's the purpose of the repeated coginit? Is this just to satisfy the pipeline instruction fetch?
Also, I think I see why you don't want to load the boot ROM at $1000. With only 8 instructions to initialize a cold boot, it's not possible to set up ptra, copy the ROM bytes, and restart. I have an idea on how to make that happen, but it depends on the answers to the above questions.
Comments
Like Evanh said, the eggbeater is the only way to hub RAM, so it's always on.
I think you are referring to the boot ROM that is realized in Verilog:
In the cold boot code, the first CLKSET reads the first address so that the next CLKSET can capture the data and read the next. There's one-CLKSET delay before the data comes out. So, the first location is not being skipped. You can always read this ROM during runtime, but no other cog can be executing CLKSET instructions, or else you'll be skipping addresses. Also, you'll have to know what the beginning of the ROM looks like, as it just wraps around and around, and it's not going to be at the start when you start reading it. For CLKSET to write the 8-bit ROM value, you'll need to use 'WC'.
The reason that I repeated trailing instructions in the booti code was to simplify the synthesized logic. For example in the warm boot code, as long as bit2 of the selector is high, it will always read 'CALLD INA,PTRB'. To put 0's in the unused locations would have taken more logic, as they would be unique values.
That's right about instructions being tight in the cold boot code. I could get around this by having
PTRA reset to $1000. I kind of like things starting at the beginning, though.
P.S. I just looked at that code and noticed that 'CLKSET #0' + 'WRBYTE 0,PTRA++' doesn't look like it should work because 0 is now INA. It's the data-forwarding circuitry that's making this function properly, despite a read-only location being used as the hub ROM recipient. I used to have data-forwarding turned off for INA/INB, because it wasn't needed, though it wouldn't hurt anything, because nobody writes INA/INB with any intent. I turned the data-forwarding back on, though, when INA/INB's shadow RAM registers got used for the debug interrupt vector set. This might have taken me a long time to debug if that data-forwarding was still shut off.