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
