Hello,
Thanks for the detailed explaination and insightful advise!!
I firstly give a try to use objcopy from GNU binutils, but it
seems the COFF file I am work on (which is generated by TI's CCS IDE) cannot be
recognized. The COFF format used by TI sllightly differs from GNU's definition.
So I guess I have to parse and load the COFF file myself.
As far as I understand how a COFF executable file is organized,
there are generally 3 section 'chuncks' to load. A section chunck may
contain mutilple sections. For example, a program may contain 3 section chucks:
Section chucks:
target address on DSP processor
Chunk 1 = txt + bss
0x1000
Chunck 2= cio+const+data+stack
0x800000
Chunck3 = vector
0x809fc1
Now, I am trying to make use of "ROM blobs" and rom_add_blob()
call. I am confused about how to map the sections to blobs, one ROM for one
section(for example .txt) , or one ROM for a section chunk? Meanwhile,
how to use the fileds from the Rom struct:
struct Rom {
char *name;
char *path;
size_t romsize; //
size_t datasize; //
data size of a section?
uint8_t *data; // offset of section raw data from the
coff?
MemoryRegion *mr;
//associated to the target DSP memory region? when the target memory
region is linked to ROM?
AddressSpace *as;
int isrom;
char *fw_dir;
char *fw_file;
GMappedFile *mapped_file; //mapped from the coff
file, like what is done for ELF?
bool committed;
hwaddr addr;
QTAILQ_ENTRY(Rom) next;
};
I hope there is no need to modify or add new stuff to ROM.
Any advise would be appreciated!!
regards,
xiaolei
------------------ ???????? ------------------
??????: "Peter Maydell"<peter.mayd...@linaro.org>;
????????: 2020??5??12??(??????) ????5:31
??????: "casmac"<1482995...@qq.com>;
????: "qemu-devel"<qemu-devel@nongnu.org>;
????: Re: how to extend to load COFF executable image file
On Tue, 12 May 2020 at 08:41, xiaolei <1482995...@qq.com> wrote:
>
> Hi all,
> I attempt to add DSP architecture support for some TI processor,
based on QEMU 4.2.
Don't try to add new code to QEMU based on an old version.
You should always work with the head-of-git. Otherwise you'll
be dealing with stuff that's gradually drifting out of date
and you'll end up with pain when you need to rebase.
> When I work on the executable file loading , I try to load COFF
executable file. Following the ELF file processing scheme, I thought I
could write a function similar to :
> rom_add_elf_program(label, mapped_file, data,
file_size, mem_size, addr, as);
> But I got lost when I track down the usage to the global
variable :static QTAILQ_HEAD(, Rom) roms;
> I did not get where this 'roms' is used for program loading,
and how the loaded program get to run eventually. Can someone give me
some hints?
You've gone down too far into the internals of the implementation there.
The way that QEMU's image loading code works is that all the data
that must be loaded is put into a set of "ROM blobs", which we
keep in a linked list. When the system is reset then the function
rom_reset() runs through the list and copies the data in each
blob into the right location in the guest memory. The simplest
way to create a blob is to use rom_add_blob(); but you could
also use rom_add_elf_program() if you wanted. That function is
a bit misnamed: it's not ELF specific and it doesn't handle
an entire program; it just has a couple of extra properties over
rom_add_blob:
* it lets the caller provide data which only partly fills
the blob, with the remainder to be zeroes
* it can work with a GMappedFile so you don't need to copy
the data out of the mapped file to pass to it
> Also, the COFF file format differs from the ELF, there is no
program header. I wonder if I could reuse the 'rom' structure like loading a
ELF. Or there is a better way to do it.
Yes, you want to reuse the Rom struct, which isn't ELF specific
(we also use it for loading raw files and uImages). You would
need to write code which could read and parse a COFF file and
identify what parts of the input file needed to go where in
memory (and what parts of memory would need to be zeroed). Then
for each of those parts of memory you create a rom blob
(via rom_add_blob() or rom_add_elf_program()). That is, you
want the equivalent of the function "static int glue(load_elf, SZ)"
in include/hw/elf_ops.h. (That function is a bit odd because
we use the C preprocessor to create a 32 bit and a 64 bit
version of the function so we can load 32-bit ELF and 64-bit
ELF files. COFF may not need that complication.)
Consider also taking the simpler approach of just using
binutils objcopy to convert the COFF file into an ELF
and then passing that ELF file to QEMU. In particular
if you're also trying to implement an entire new architecture
you might as well skip the pain of writing a COFF file
loader for the moment.
thanks
-- PMM
