Move vector table to beginning of flash image #10

2021-01-23T17:10:18-06:00

Wren6991 commented

2021-01-23 17:10:18 -06:00

(Migrated from github.com)

See #6.

Vector table moved to start of user image for flash builds (immediately after boot2)
boot2 vectors through this table, initialises VTOR and SP
Move ELF entry point to start of .reset to simplify NO_FLASH builds (as there's no need to handle debugger entry specially there)

This is WIP, I haven't tested debugger flash entry, haven't modified the non-default second stages, haven't tried any non-default builds. We should probably take this chance to do something about the copy/paste between the boot2 files.

See #6. - Vector table moved to start of user image for flash builds (immediately after boot2) - boot2 vectors through this table, initialises VTOR and SP - Move ELF entry point to start of `.reset` to simplify NO_FLASH builds (as there's no need to handle debugger entry specially there) This is WIP, I haven't tested debugger flash entry, haven't modified the non-default second stages, haven't tried any non-default builds. We should probably take this chance to do something about the copy/paste between the boot2 files.

thejpster (Migrated from github.com) reviewed

2021-01-24 04:00:08 -06:00

src/rp2_common/pico_standard_link/crt0.S

					
				@ -188,11 +209,12 @@ __vector_entry:

				.type _reset_handler,%function

				.thumb_func

				_reset_handler:

Thank you!!

Wren6991 (Migrated from github.com) reviewed

2021-01-24 08:05:11 -06:00

src/rp2_common/pico_standard_link/crt0.S

					
				@ -188,11 +209,12 @@ __vector_entry:

				.type _reset_handler,%function

				.thumb_func

				_reset_handler:

Yeah I had already fixed in passing, but I laughed when you mentioned it in the stream.

thejpster (Migrated from github.com) reviewed

2021-01-24 08:59:12 -06:00

src/rp2_common/pico_standard_link/crt0.S

					
				@ -188,11 +209,12 @@ __vector_entry:

				.type _reset_handler,%function

				.thumb_func

				_reset_handler:

Any chance you can not have both the processor model identification register and the core number identification register not both called CPUID whilst you're at it? :)

lurch (Migrated from github.com) reviewed

2021-01-24 10:21:06 -06:00

src/rp2_common/pico_standard_link/crt0.S

					
				@ -188,11 +209,12 @@ __vector_entry:

				.type _reset_handler,%function

				.thumb_func

				_reset_handler:

the processor model identification register

That's M0PLUS: CPUID Register on page 80 of the RP2040 datasheet.
https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_regs/include/hardware/regs/m0plus.h#L565
https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_structs/include/hardware/structs/scb.h#L14

the core number identification register

That's SIO: CPUID Register on page 42 of the RP2040 datasheet.
https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_regs/include/hardware/regs/sio.h#L21
https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_structs/include/hardware/structs/sio.h#L15

not both called CPUID whilst you're at it? :)

I suspect it's too late to change that at this stage. And I'm sure there's probably other registers which also have "duplicated names" between different peripheral blocks?

> the processor model identification register That's `M0PLUS: CPUID Register` on page 80 of the RP2040 datasheet. https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_regs/include/hardware/regs/m0plus.h#L565 https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_structs/include/hardware/structs/scb.h#L14 > the core number identification register That's `SIO: CPUID Register` on page 42 of the RP2040 datasheet. https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_regs/include/hardware/regs/sio.h#L21 https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_structs/include/hardware/structs/sio.h#L15 > not both called CPUID whilst you're at it? :) I suspect it's too late to change that at this stage. And I'm sure there's probably other registers which also have "duplicated names" between different peripheral blocks?

Wren6991 (Migrated from github.com) reviewed

2021-01-24 13:57:26 -06:00

src/rp2_common/pico_standard_link/crt0.S

					
				@ -188,11 +209,12 @@ __vector_entry:

				.type _reset_handler,%function

				.thumb_func

				_reset_handler:

It's a bit late in the day to rename registers, but there is at least a documentation issue there, so I'll drop a couple of NOTE boxes in the relevant parts of the datasheet. I think you were lead down the garden path a little by this literal value appearing in the crt0 disassembly.

Wren6991 (Migrated from github.com) reviewed

2021-01-24 13:59:59 -06:00

src/rp2_common/pico_standard_link/crt0.S

					
				@ -188,11 +209,12 @@ __vector_entry:

				.type _reset_handler,%function

				.thumb_func

				_reset_handler:

Note that the core number check in crt0 should be redundant anyway. It should be impossible to reach this point on core 1 (see github.com/raspberrypi/pico-bootrom@00a4a19114/bootrom/bootrom_rt0.S (L222)), there's just a paranoia check there in case you do something spectacularly broken

Note that the core number check in crt0 should be redundant anyway. It should be impossible to reach this point on core 1 (see https://github.com/raspberrypi/pico-bootrom/blob/00a4a19114195e20fb817bdfbca1165e157eef37/bootrom/bootrom_rt0.S#L222), there's just a paranoia check there in case you do something spectacularly broken

Wren6991 commented

2021-01-24 18:56:00 -06:00

(Migrated from github.com)

Have briefly tried:

blinky on flash, COPY_TO_RAM, NO_FLASH
Stepping through the ELF entry point thing for catching debugger entries
flash_program example, to make sure still callable as void(*)(void) for recovering XIP state while running
blinky and flash_program with generic 03h second stage

should be most paths covered

Have briefly tried: - blinky on flash, COPY_TO_RAM, NO_FLASH - Stepping through the ELF entry point thing for catching debugger entries - flash_program example, to make sure still callable as `void(*)(void)` for recovering XIP state while running - blinky and flash_program with generic 03h second stage should be most paths covered

kilograham (Migrated from github.com) requested changes

2021-01-27 12:43:12 -06:00

src/rp2_common/pico_standard_link/crt0.S