Booting and Cog selection

d2rk · 2012-02-14 07:15

Hi,

Please correct me if I'm wrong, but program compiled with propgcc automatically runs on the Cog 0. If so, can it restart itself on the Cog that was assigned by bootloader?

Thanks.

Dave Hein · 2012-02-14 08:23

I'm not sure what you mean by "bootloader". Are you referring to the boot program in the Prop's ROM or the propeller-load program. In either case they will boot up on cog 0. After a program is running you can start up additional cogs that run COG or LMM C code.

d2rk · 2012-02-14 08:38

Yes, the boot program in the Prop's ROM or propeller-load program will boot up the image on cog 0. However I have own bootloader that boot up this image and it does it not always on cog 0. I would like to have something like Catalina compiler does, when LMM restarts cog on which it already runs.

Dave Hein · 2012-02-14 10:11

I ran some tests, and I see what the problem is now. The PropGCC binary contains a small Spin program that peforms a coginit on cog 0. You could patch the binary at byte location $18, and change it from a value of $35 to $34. $35 is the opcode for pushing a zero onto the Spin stack. $34 will push a -1 onto the stack instead, which will change the coginit to a cognew. The Spin program also sets the PAR register to $8000, which is used to initialize the C stack pointer.

d2rk · 2012-02-14 10:24

Thanks, Dave. I think you are talking about spinboot.s. I will try to test this. However can we do something like this "coginit(cogid, @entry)", since I do not need a new cog, but just need continue to use the current one?

David Betz · 2012-02-14 10:41

d2rk wrote: »

Thanks, Dave. I think you are talking about spinboot.s. I will try to test this. However can we do something like this "coginit(cogid, @entry)", since I do not need a new cog, but just need continue to use the current one?

Yes, I think using cogid to get the cog number is better than using a constant. We can probably change spinboot.s to do this by default so you don't have to patch the generated binaries.

Dave Hein · 2012-02-14 10:48

If you are starting it from a Spn program I think you could do coginit(cogid, $20, $8000). From what I can tell the starting address seems to be at $20, and the $8000 will set the stack pointer to the end of memory. If you want to reserve some space at the top of memory you could specify a lower address for PAR. However, I think you would need to set up some things in the C stack space if you do that.

David Betz · 2012-02-14 10:50

David Betz wrote: »

Yes, I think using cogid to get the cog number is better than using a constant. We can probably change spinboot.s to do this by default so you don't have to patch the generated binaries.

Ummmm... I just looked and there doesn't seem to be a cogid opcode in Spin. Does the Spin bytecode interpreter store the cog id in a global?

David Betz · 2012-02-14 11:01

David Betz wrote: »

Ummmm... I just looked and there doesn't seem to be a cogid opcode in Spin. Does the Spin bytecode interpreter store the cog id in a global?

jazzed figured it out. The Spin compiler generates the following code for cogid:

2                        n := cogid
Addr : 0018:          3F 89  : Register op $1E9 Read
Addr : 001A:             65  : Variable Operation Local Offset - 1 Write
Addr : 001B:             32  : Return

I'm trying the (0x35, 0x89) sequence in spinboot.s now.

d2rk · 2012-02-14 11:07

If you are starting it from a Spn program I think you could do coginit(cogid, $20, $8000). From what I can tell the starting address seems to be at $20, and the $8000 will set the stack pointer to the end of memory. If you want to reserve some space at the top of memory you could specify a lower address for PAR. However, I think you would need to set up some things in the C stack space if you do that.

No, the bootloader is written in Propeller Assembly.

I'm trying the (0x35, 0x89) sequence in spinboot.s now.

Great! Thanks, David. Cann't wait to try this.

David Betz · 2012-02-14 15:50

This change seems to have worked. I've checked in the new code and it should appear in the next gcc release. In case you're able to build the libraries yourselves, here is the new code for spinboot.s:

Old code:

	'' here is the spin code to switch to pasm mode
	.byte 0x35		' constant 1 $00000000 (id)
	.byte 0xc7		' memory op: push PBASE + next byte
	.byte 0x10
	.byte 0x37		' constant mask Y= 14 0x00008000
	.byte 14
	.byte 0x2C		' CogInit(Id, Addr, Ptr)
	.byte 0x32		' Return (unused)
	.byte 0x00		' padding

New code:

	'' here is the spin code to switch to pasm mode
	'' removed a load of the constant 0 and replaced it with cogid
	.byte 0x3F		' Register op $1E9 Read - cogid
	.byte 0x89
	.byte 0xc7		' memory op: push PBASE + next byte
	.byte 0x10
	.byte 0x37		' constant mask Y= 14 0x00008000
	.byte 14
	.byte 0x2C		' CogInit(Id, Addr, Ptr)
	.byte 0x32		' Return (unused)

d2rk · 2012-02-14 22:42

I've rebuilt propgcc and it works great! The problem is solved.

David Betz · 2012-02-15 00:40

d2rk wrote: »

I've rebuilt propgcc and it works great! The problem is solved.

Great! I'm glad that resolved the problem for you. Thanks for reporting it.

d2rk · 2012-02-17 11:27

David, can we make the code from spinboot.s relocatable, since right now there are fixed addresses? The purpose of this is here.

Dave Hein · 2012-02-17 11:56

Assuming ;you can relocate the C code, the Spin code can be relocated by adding the memory offset to the last 5 words of the 16-byte Spin header.

d2rk · 2012-02-17 12:44

Yes, I can fix 16-byte spin header manually, however there is also a spin code right after the header where we switch to LMM kernel.

Dave Hein · 2012-02-17 12:52

The LMM start address is loaded as $10 relative to PBASE. When you add the offset to the PBASE in the 16-byte header it will also add the offset to the LMM start address.

d2rk · 2012-02-17 12:54

Thanks Dave. I will try this with my linker script to relocate the C code.

Booting and Cog selection

Comments