-
Notifications
You must be signed in to change notification settings - Fork 128
Add ram image (no flash) target for rp2xxx #491
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Have a POC working: Makefile SOURCES = rpblink.c
OBJECTS = $(SOURCES:.c=.o)
TARGET = rpram_blink
CC = arm-none-eabi-gcc
LD = arm-none-eabi-ld
CFLAGS = -mcpu=cortex-m0plus
LDFLAGS = -nostdlib -T rp2040_ram.ld -Map=output.map
.PHONY: all clean load
all: $(TARGET).uf2
%.o: %.c
$(CC) $(CFLAGS) -c $< -o $@
$(TARGET).elf: $(OBJECTS)
$(LD) $(LDFLAGS) -o $@ $^
$(TARGET).uf2: $(TARGET).elf
picotool uf2 convert $^ $@ rpblink.c #include <stdint.h>
#define IO_BANK0 0x40014000
#define RESET_DONE 0x4000c008
#define GPIO25_CTRL 0x400140cc
#define GPIO_OE 0xd0000020
#define GPIO_OUT_XOR 0xd000001c
#define PPB_VTOR 0xe000ed08
#define PUT32(address,value) (*((volatile uint32_t*)address))=value
#define GET32(address) *(volatile uint32_t*)address
int main(void);
typedef struct {
uint32_t initial_stack_pointer;
uint32_t reset_vector;
} vector_table_t;
vector_table_t _vector_table = { 0x20040000, (uint32_t)&main };
__attribute__ ((section ("entry"))) __attribute__((naked)) void _entry_point(void) {
__asm__ __volatile__ (
"mov r0, %[_vector_table]\n\t"
"mov r1, %[_VTOR_ADDRESS]\n\t"
"str r0, [r1]\n\t"
"eor r2, r2\n\t"
"ldm r0!, {r1, r2}\n\t"
"msr msp, r1\n\t"
"bx r2\n\t"
:
: [_vector_table] "r" (&_vector_table),
[_VTOR_ADDRESS] "r" (PPB_VTOR)
: "memory", "r0", "r1", "r2"
);
}
int main( void ) {
// Allow CORE0 to access the IO_BANK0
PUT32( IO_BANK0, ( 1 << 5 ) );
// Wait until out of reset
while (GET32(RESET_DONE) & (1 << 5) == 0);
// Set function to PIO
PUT32( GPIO25_CTRL, 0x05 );
// Output enable
PUT32( GPIO_OE, (1 << 25) );
while( 1 )
{
PUT32( GPIO_OUT_XOR, ( 1 << 25 ) );
for ( volatile unsigned int a = 50000; a > 0; a-- );
}
return 0;
} rp2040_ram.ld ENTRY(_entry_point);
MEMORY
{
entry (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00000100
ram0 (rwx) : ORIGIN = 0x20000100, LENGTH = 0x0003ff00
/* ram0 (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00040000 */
}
/* A RAM only binary */
/* ▪ 0x20000000-0x20042000 Main RAM: Blocks can be positioned with byte alignment. */
/* ▪ 0x15000000-0x15004000 Flash Cache: (since flash is not being targeted, the Flash Cache is available for use */
/* as RAM with same properties as Main RAM). */
SECTIONS
{
.entry :
{
KEEP(*(entry*))
} > entry
.text :
{
/* Using microzig_flash_start here because we put the vector table here */
KEEP(*(microzig_flash_start))
*(.text*)
*(.rodata*)
} > ram0
.ARM.extab : {
*(.ARM.extab* .gnu.linkonce.armextab.*)
} > ram0
.ARM.exidx : {
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
} > ram0
.data :
{
microzig_data_start = .;
KEEP(*(.time_critical*))
*(.data*)
microzig_data_end = .;
} > ram0
.bss :
{
microzig_bss_start = .;
*(.bss*)
microzig_bss_end = .;
} > ram0
/* Would not be used */
microzig_data_load_start = LOADADDR(.data);
} |
Done in #535 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The bootrom on rp2xxx chips support UF2 images that run directly from flash. This should allow for faster dev work, and avoid wearing out the flash prematurely.
It seems that the pico-sdk already supports this, by setting
pico_set_binary_type(blink_simple no_flash)
in the CMakeLists.txt.Trying to figure out how to do this, I figure it entails:
NOLOAD
at all obviously.startup_logic._start
, since we don't want to clear.bss
and copy.data
from flash.microzig_flash_start
,microzig_data_start
,microzig_bss_start
,microzig_data_load_start
to be defined, or give them dummy unused values.iirc, the bootrom just copies the uf2 to wherever the address says (whether that be flash or ram) and then jumps to the stage2 bootloader, which should respect the reset vector in the vector table.
I think that this means that we will need a custom stage2 bootloader which knows where the (ram) vector table is, and sets it. This implies that we would need to flash (to flash) a ram-image-aware bootloader, which would mean that we would want to hard-code a known location for the vector table in ram. We might need for this target to produce separate binaries then: One for the bootloader for flash, and another that is ram only.
Additionally, we'd like to be able to flash this in openocd/gdb. I am not sure if this copies a stub into memory, but if it does, we'd also need to make sure that we don't trample the stub.
The text was updated successfully, but these errors were encountered: