In my last post I mentioned that I had to employ some ugly hacks in the boot firmware for my ZPU project, to make sure certain structures ended up in SDRAM rather than the initial Boot ROM.<\/p>\n
To illustrate the problem let’s look at a minimal test program:<\/p>\n
short inconvenience;\r\n\r\nint main(int argc,char **argv)\r\n{\r\n\u00a0\u00a0 \u00a0inconvenience=0x0123;\r\n\u00a0\u00a0 \u00a0return(0);\r\n}<\/pre>\nThis little program declares a 16-bit word global variable, and then writes to it.\u00a0 The assembly output produced by<\/p>\n
zpu-elf-gcc -Os -S bsstest.c<\/pre>\nis as follows:<\/p>\n
\u00a0\u00a0\u00a0 .file\u00a0\u00a0 \u00a0\"bsstest.c\"\r\n.text\r\n\u00a0\u00a0 \u00a0.globl\u00a0\u00a0 \u00a0main\r\n\u00a0\u00a0 \u00a0.type\u00a0\u00a0 \u00a0main, @function\r\nmain:\r\n\u00a0\u00a0 \u00a0im 291\r\n\u00a0\u00a0 \u00a0nop\r\n\u00a0\u00a0 \u00a0im inconvenience\r\n\u00a0\u00a0 \u00a0storeh\r\n\u00a0\u00a0 \u00a0im 0\r\n\u00a0\u00a0 \u00a0nop\r\n\u00a0\u00a0 \u00a0im _memreg+0\r\n\u00a0\u00a0 \u00a0store\r\n\u00a0\u00a0 \u00a0poppc\r\n\u00a0\u00a0 \u00a0.size\u00a0\u00a0 \u00a0main, .-main\r\n\u00a0\u00a0 \u00a0.comm\u00a0\u00a0 \u00a0inconvenience,2,4\r\n\u00a0\u00a0 \u00a0.ident\u00a0\u00a0 \u00a0\"GCC: (GNU) 3.4.2\"<\/pre>\nNote the storeh instruction half way down.\u00a0 That’s the source of my problem.\u00a0 I’ve implemented storeh in hardware for SDRAM, but not for the BlockRAM-based Boot code, and I’d really like to avoid doing the latter if possible, because doing a 16-bit write to a 32-bit wide RAM is going to be messy and eat up logic elements.\u00a0 The boot code is also rather on the large side, so it would be nice to avoid storing unitialised data in there at all if possible.
\n
\nThe quick solution is simply to make the variable an int (32-bits) instead of a short (16-bits) – but that doesn’t help if what’s declared is a structure that has critical alignment requirements, as is the case for the FAT filesystem structures that the boot code must deal with.\u00a0 The solution I used for my last post was instead of declaring a struct, to declare a pointer to a struct, and initialise that pointer to some random location in SDRAM.\u00a0 That works just fine when there are just one or two such structs, but it’s ugly and the chances of bugs creeping in as structs collide increase with the program’s complexity, so a better solution is needed.<\/p>\n
The solution to this problem is to employ a linker script, which we supply to gcc with the -T option.<\/p>\n
Before diving into the linker script, let’s take a quick look at my ZPUTest project’s address decoding:<\/p>\n
case mem_addr(31 downto 16) is\r\n\twhen X\"0000\" =>\t-- Boot BlockRAM\r\n\t\t...\r\n\twhen X\"FFFE\" =>\t-- VGA controller\r\n\t\t...\r\n\twhen X\"FFFF\" =>\t-- Peripherals\r\n\t\t...\r\n\twhen others => -- SDRAM access\r\n\t\t...<\/pre>\nSo the memory map looks like this:<\/p>\n
So our goal with the linker script is to ensure anything we want to end up in SDRAM has an address greater than 0x10000.<\/p>\n
We’ll start the linker script by defining some memory sections:<\/p>\n
MEMORY\r\n{\r\n BOOT (rx) : ORIGIN = 0x00000000, LENGTH = 0x00002000 \/* 8192 bytes *\/\r\n SDRAM (rw)\u00a0 : ORIGIN = 0x007ff000, LENGTH = 0x00001000 \/* 4k at top end of DE1's SDRAM *\/\r\n STACK (rw) : ORIGIN = 0x40000000, LENGTH = 0x00000400 \/* 1024 bytes *\/\r\n}<\/pre>\nThe BOOT section is the BlockRAM at the beginning of the memory map. At the time of writing it’s currently 8KB (16 M4Ks) in size, but I’m hoping to get that down to 4KB in time. Once nice effect of defining memory regions like this is that we get a compile error if the code doesn’t fit.<\/p>\n
The SDRAM section is set here to point to a small region at the end of the DE1 board’s 8 megabytes of SDRAM. It doesn’t really matter where this falls, but since the whole point of this project was a minimal core for loading files into RAM from SD Card, it needs to be somewhere that won’t be overwritten when we load files!<\/p>\n
SECTIONS\r\n{\r\n \/* first section is .fixed_vectors which is used for startup code *\/\r\n . = 0x0000000;\r\n .fixed_vectors :\r\n {\r\n *(.fixed_vectors)\r\n }>BOOT\r\n<\/pre>\nThe .fixed_vectors section comes from the crt0.s startup code, and must be the first section in the BOOT region. It contains the initial jump instruction, a few memory-based registers for GCC (which isn’t happy building code for CPUs that don’t have any traditional registers at all) and the emulation code for instructions that aren’t implemented in hardware.<\/p>\n
\r\n \/* Remaining code sections *\/\r\n . = ALIGN(4);\r\n .text :\r\n {\r\n *(.text) \/* remaining code *\/\r\n } >BOOT\r\n\r\n \/* .rodata section which is used for read-only data (constants) *\/\r\n . = ALIGN(4);\r\n .rodata :\r\n {\r\n *(.rodata)\r\n } >BOOT\r\n<\/pre>\nThe above adds the rest of the program code and any constants and strings to the Boot ROM.<\/p>\n
\r\n \/* .data section which is used for initialized data *\/\r\n . = ALIGN(4);\r\n .data :\r\n {\r\n _data = . ;\r\n *(.data)\r\n SORT(CONSTRUCTORS)\r\n . = ALIGN(4);\r\n } >BOOT\r\n . = ALIGN(4);\r\n _romend = . ;\r\n<\/pre>\nInitialised data is the only problem we haven’t addressed. This will still end up in the Boot ROM. The implication of this is that declaring a global variable “short val;” should now be fine, but “short val=0x1234;” will still cause problems.
\nThe _romend symbol isn’t needed, but it’s convenient to include because we can use it to keep an eye on code size.<\/p>\n
\r\n \/* .bss section which is used for uninitialized data *\/\r\n .bss :\r\n {\r\n __bss_start = . ;\r\n __bss_start__ = . ;\r\n *(.bss)\r\n *(COMMON)\r\n } >SDRAM\r\n __bss_end__ = . ;\r\n}<\/pre>\nFinally, the BSS section, which will now end up in SDRAM. This also has the nice side-effect of reducing the space needed for the Boot ROM, since we no longer need to allow room for the BSS data.
\nAgain, the __bss_start__ and __bss_end__ symbols aren’t strictly necessary, but they allow us to keep tabs on locations and sizes.
\nI do this with an extra target in the makefile, like so:<\/p>\n
\r\n%.rpt: %.elf\r\n\t$(DUMP) -x $< | grep _romend # End of Boot ROM\r\n\t$(DUMP) -x $< | grep __bss_start__ # Start of BSS data in SDRAM\r\n\t$(DUMP) -x $< | grep __bss_end__ # End of BSS data in SDRAM\r\n<\/pre>\nEvery build finishes by printing this to the shell:<\/p>\n
\r\nzpu-elf-objdump -x boot.elf | grep _romend # End of Boot ROM\r\n000018ec g *ABS*\t00000000 _romend\r\nzpu-elf-objdump -x boot.elf | grep __bss_start__ # Start of BSS data in SDRAM\r\n007ff000 g .bss\t00000000 __bss_start__\r\nzpu-elf-objdump -x boot.elf | grep __bss_end__ # End of BSS data in SDRAM\r\n007ff2f8 g *ABS*\t00000000 __bss_end__\r\n<\/pre>\nThe Boot ROM currently ends at 0x18ec, while the BSS data occupies SDRAM between 0x7ff000 and 0x7ff2f8<\/p>\n","protected":false},"excerpt":{"rendered":"
In my last post I mentioned that I had to employ some ugly hacks in the boot firmware for my ZPU project, to make sure certain structures ended up in SDRAM rather than the initial Boot ROM. To illustrate the … Continue reading