I'm trying to write an mbr-manager in GNU-assembler, everything works great except that I'm doing an .include "print_routines" and I want that to change but I don't know how I could write a linker script to do the same thing as an include.
When writing my mbr-manager, I know that after the 0x1BE bytes there as the 4 partition entries, so basically all of my code needs to be from 0 --> 446 bytes. Also my code should be at 0x600, as the mbr reallocate itself
Here is what I have :
2 files named "mbr.s" and "print_16.s"
In mbr.s all of my code is under the section ".mbr"
In print_16.s all of my code is under the section ".utils"
My question is then the following:
How can I write a linker script to have the first 446 bytes of the .mbr section, followed by the .utils section and finally the rest of the .mbr, that is from 446 to 512 ?
Basically I should have something like this :
mbr.s
.intel_syntax noprefix
.code16
.section .mbr, "ax
_start:
init code
...
// Here, we are at the 0x1BEth byte
// !!! This is were I want to place my "print_routines.s" code, that is in between the .mbr section and before the 0x1BEth byte
. = _start + 0x1BE
/* Here are the partition entries, basically I souldn't touch this area*/
.word 0x55AA // Magic word, this is at the 512th byte
Here is what I tried so far but the linker says that my sections overlaps.. I'm out of ideas
SECTIONS
{
.mbr 0x0600 : AT(0)
{
mbr_start = .;
*(.mbr)
mbr_end = .;
}
.utils : AT (0x1BE)
{
*(.utils)
}
}
Related
I have a new standard c++ project on an imx rt 1024 (an nxp chip), in which I try to move my vector table to SRAM. It fails, depending on a change I apply in the linker script.
The project is a new project from scratch created by MCUxpresso. I am not looking for answers MCUxpresso related, or c/c++/startup code related. I only want to properly understand the consequences of my changed linker script I show below.
The part that works
My starting point is a small program on my evk board, using a simple FreeRTOS task to blink a led. This works fine, when I put my vector table in flash.
linker script:
/* Not relevant for this question, other than showing there is something
written to flash before my vector table, harmless I think, but didn't want to leave
out of this question
*/
.boot_hdr : ALIGN(4)
{
__boot_hdr_start__ = ABSOLUTE(.) ;
KEEP(*(.boot_hdr.conf))
. = 0x1000 ;
KEEP(*(.boot_hdr.ivt))
. = 0x1020 ;
KEEP(*(.boot_hdr.boot_data))
. = 0x1030 ;
KEEP(*(.boot_hdr.dcd_data))
__boot_hdr_end__ = ABSOLUTE(.) ;
. = 0x2000 ;
} >PROGRAM_FLASH
/*
Here I write my vector table to flash
*/
.vector : ALIGN(4)
{
__vector_table_flash_start__ = ADDR(.vector) ;
__vector_table_itc_start__ = LOADADDR(.vector) ;
KEEP(*(.isr_vector))
__vector_table_flash_end__ = ABSOLUTE(.) ;
. = ALIGN(4) ;
} >PROGRAM_FLASH
Disassembled code for vector table
Disassembled code of reset handler
Note: 0x600022e5 corresponds to 0x600022e4, this has something to do with arm .thumb. I don't exactly know how that works tbh.
When I run this app, it runs fine. If I set a breakpoint in the ResetHandler it breaks and I can step through the startup code and jump to main. When I let the program run, my led will blink every second.
The part which fails
I changed my linker script to put my vector table in SRAM as follows
.vector : ALIGN(4)
{
__vector_table_flash_start__ = ADDR(.vector) ;
__vector_table_itc_start__ = LOADADDR(.vector) ;
KEEP(*(.isr_vector))
__vector_table_flash_end__ = ABSOLUTE(.) ;
. = ALIGN(4) ;
} >SRAM_ITC AT>PROGRAM_FLASH
For reference, the memory section:
MEMORY
{
PROGRAM_FLASH (rx) : ORIGIN = 0x60000000, LENGTH = 0x400000
SRAM_DTC (rwx) : ORIGIN = 0x20000000, LENGTH = 0x10000
SRAM_ITC (rwx) : ORIGIN = 0x0, LENGTH = 0x10000
SRAM_OC (rwx) : ORIGIN = 0x20200000, LENGTH = 0x20000
}
ENTRY(ResetISR)
When I upload, my program doesn't even reach the reset vector. It goes straight into the woods, and crashes somewhere outside program code.
The questions
What EXACTLY happens when I adjust my linker script with >SRAM_ITC AT>PROGRAM_FLASH?
I am pretty sure the produced elf file still contains the entire vector table starting from address 0x60002000. The >SRAM_ITC only tells the linker where certain parts of memory will end up AFTER the startup code copied all parts to their final ram location. Right? So how on earth can the initial jump to 0x60002004 (the address which holds the location of the reset handler) fail? The nxp bootloader always expects the reset vector on that location. I didn't change that. I only told the linker that the memory on that location will finally end up in SRAM. What am I misunderstanding here?
Maybe a stupid question: If I am completely wrong with my above assumptions, is there a way to see this from disassembly? I think objdump only shows the final addresses, but my debug probe will only write to flash as far as I know. So after uploading my code to my target, I still assume that stuff got written to flash, and after reset the built in bootloader will jump to 0x60002004 and set the PC to the address located at 0x60002000. Where can I see the actual blob of bytes which is programmed to flash memory?
Copying the vector table to sram from my custom bootloader solved the problem. That way the "on chip bootloader" from nxp can jump to my custom bootloader.
Before I just to my app from my custom bootloader, I copy the vector table to sram and set SCB->VTOR to the start of sram vector table.
As I have stated previously, both my ASM and C skills are not up to scratch so please be patient with me.
I am in the process of writing a bootloader in C and have begun to rub up against the 512 byte limit, but I am not sure how to configure my linker script to split my file into two 512b segments so that I can load on from the other. My current linker script is as follows:
linker.ld
ENTRY(main);
SECTIONS
{
. = 0x7C00;
.text : AT(0x7C00)
{
_text = .;
*(.text);
_text_end = .;
}
.data :
{
_data = .;
*(.bss);
*(.bss*);
*(.data);
*(.rodata*);
*(COMMON)
_data_end = .;
}
.sig : AT(0x7DFE)
{
SHORT(0xaa55);
}
/DISCARD/ :
{
*(.note*);
*(.iplt*);
*(.igot*);
*(.rel*);
*(.comment);
}
}
However, despite trying to research them online I cannot for the life of me understand this enough to go about what I am trying to do.
I can achieve what I am trying to do in assembly but I would rather keep this project solely in C
Help is massively appreciated!
And to clarify (as my initial statement seems rather nonsensical in retrospect), I need a way to load one compiled file padded to 512b into a binary with the magic word present, and then do the same to another file without the magic word with the end result being a single binary
I have a bootloader program "boot.asm" which must contains a special word at an offset of 510 bytes from the beginning. And I have a kernel source written in C "kernel.c".
My plan is to call the Kernel (which will be in the second sector of hd) by loading second sector of hard disk from the bootloader program and put it at location 0x8000 in memory.
Now I am compiling both the source files into ELF object files (separately) into "boot.o" and "kernel.o" and then linking them through a linker and outputting a raw binary file "kernel.bin" .
I want to put my bootloader code starting at 0x7c00 and then at the 0x7dfe location I have to put the special word. Then right at 0x8000 I have to place my kernel code. i.e I want to put respective sections of both the object files at different locations.
This is my failed attempt.
ENTRY(boot)
OUTPUT_FORMAT("binary")
SECTIONS{
. = 0x7c00;
.text :
{
*(.boot)
}
.sig : AT(0x7dfe){
SHORT(0xaa55);
}
. = 0x8000;
.text :
{
kernel.o(.text)
}
.rodata :
{
kernel.o(.rodata)
}
.data :
{
kernel.o(.data)
}
.bss :
{
kernel.o(.bss)
}
}
What I have understood is that an executable cannot have a section more than once.
I have limited knowledge about low level programming.
How do I solve this problem.
Thankyou.
You need to fix two things, don't split the .text output section, and use AT() to place the kernel immediately after the boot sector in the output binary while keeping its address at 0x8000. For example, a linker script something like this should work:
ENTRY(boot)
OUTPUT_FORMAT("binary")
SECTIONS {
. = 0x7c00;
.boot :
{
*(.boot)
}
. = 0x7dfe;
.sig : {
SHORT(0xaa55);
}
. = 0x8000;
.kernel : AT(0x7e00) /* place immediately after the boot sector */
{
*(.text)
*(.rodata)
*(.data)
_bss_start = .;
*(.bss)
*(COMMON)
_bss_end = .;
}
kernel_sectors = (SIZEOF(.kernel) + 511) / 512;
/DISCARD/ : {
*(.eh_frame)
}
}
I've added some stuff to handle sections you'll see in GCC compiled object files. The _bss_start and _bss_end symbols can be used to zero out the .bss section, and per Michael Petch's suggestion the kernel_sector symbol is set to the length of the kernel in 512 byte sectors.
What exactly does ". = 0x7c00" in a linker script do?
More specifically, when I place . = 0x7c00 at the beginning of a linker script, why doesn't the resulting output file begin with 0x7c00 = 31,744 zeros?
I understand that when a PC boots, the BIOS places the 512 byte MBR at memory address 0x7c00. However, I am confused as to how exactly the linker's location counter affects how the output file is laid out.
(For context, I'm trying to thoroughly understand the sample code from the "x86 bare metal" project. https://github.com/cirosantilli/x86-bare-metal-examples. I've included the entire linker script below for context.)
SECTIONS
{
/*
We could also pass the -Ttext 0x7C00 to as instead of doing this.
If your program does not have any memory accesses, you can omit this.
*/
. = 0x7c00;
.text :
{
__start = .;
/*
We are going to stuff everything
into a text segment for now, including data.
Who cares? Other segments only exist to appease C compilers.
*/
*(.text)
/*
Magic bytes. 0x1FE == 510.
We could add this on each Gas file separately with `.word`,
but this is the perfect place to DRY that out.
*/
. = 0x1FE;
SHORT(0xAA55)
*(.stage2)
__stage2_nsectors = ABSOLUTE((. - __start) / 512);
. = ALIGN(512);
__end = .;
__end_align_4k = ALIGN(4k);
}
}
It looks like the ". = 0x7c00" is not meaning a length but an absolute address. It reads to me as 'set the current value of the special variable "." to be the hex value 0x7c00 and then it plans to use that address as an offset later in the script like with the . = ALIGN(512) it is also why it saves that address off as __start so it can then do math on the resulting image. If you manipulate . during the script so it points to the last chunk of memory added to the image then you can use it to determine the total size:
__stage2_nsectors = ABSOLUTE((. - __start) / 512);
in English would be
The difference between the starting place and wherever I ended divided by sector size.
Below is a portion of the C code I am using:
pushbutton_ISR()
{
int press;
int key_pressed;
press = *(KEYS_ptr + 3); // read the pushbutton Edge Det Register interrupt register
*(KEYS_ptr + 3) = 0; // Clear the Edge Det registers.
if (press & 0x1) { // KEY1
key_pressed = KEY1;
//sum = sum + *NEW_NUMBER;
}
else if (press & 0x2) { // KEY2
key_pressed = KEY2;
*GREEN_LEDS = *NEW_NUMBER;
sum = sum + *NEW_NUMBER;
*RED_LEDS = sum;
}
else // i.e. (press & 0x8), which is KEY3
sum = *(NEW_NUMBER); // Read the SW slider switch values; store in pattern
return;
}
The compiler compiles this fine and the code appears to run (on an Altera board) fine. However, when I change the first if statement to:
if (press & 0x1) { // KEY1
//key_pressed = KEY1;
sum = sum + *NEW_NUMBER;
}
the compiler gives the following error messages:
.../nios2-elf/bin/ld.exe: section .data loaded at [00000a00,00000e0f] overlaps section .text loaded at [00000500,00000a0f]
.../nios2-elf/bin/ld.exe: section .ctors loaded at [00000a10,00000a13] overlaps section .data loaded at [00000a00,00000e0f]
.../nios2-elf/bin/ld.exe: Z:/Projects/Altera/3215_W15_LabB/Part2/from_handout.elf: section .data vma 0xa00 overlaps previous sections
.../nios2-elf/bin/ld.exe: Z:/Projects/Altera/3215_W15_LabB/Part2/from_handout.elf: section .ctors vma 0xa10 overlaps previous sections
.../nios2-elf/bin/ld.exe: Z:/Projects/Altera/3215_W15_LabB/Part2/from_handout.elf: section .rodata vma 0xa14 overlaps previous sections
.../nios2-elf/bin/ld.exe: Z:/Projects/Altera/3215_W15_LabB/Part2/from_handout.elf: section .sdata vma 0xe10 overlaps previous sections
.../nios2-elf/bin/ld.exe: Z:/Projects/Altera/3215_W15_LabB/Part2/from_handout.elf: section .sbss vma 0xe18 overlaps previous sections
Could you please advise me about the reasons for these errors, and how to resolve them.
This has nothing to do with your code being incorrect.
These are linker errors (it even tells you ld.exe is the program complaining) about output sections overlapping. This probably means you just ran out of space, but could also mean the linker directive file your project is using has some problems.
When you add in this line, it causes the size of the compiled code to be too big for the memory area that you are loading the code into.
You can see from the first line of the linker error message that .text (the code) is loaded at 0x500, and .data (the non-zero static variables) is loaded at 0xa00. However, the .text section is so long that it is too big to fit in the space between 0x500 and 0xa00.
To fix this you will either need to:
Make your code smaller
Increase the amount of space available for .text
To do the first one, you could use -Os or similar compiler option to compile for minimum code size ; or manually rewrite your code to be smaller.
For the second one you really need to understand the hardware you are loading the code into. Is it a hardware requirement that code goes at 0x500 and data goes at 0xa00? If not, then you may be able to load the code and/or data into different addresses.
These addresses are configured in your linker script (this may be hardcoded into the makefile or it may be an actual file somewhere). Hopefully the hardware device came with documentation that explains how much memory it has and where you're allowed to load your code to.