Re: Why QEMU translates one instruction to a TB？

* Re: Why QEMU translates one instruction to a TB？
       [not found] <tencent_EAC696641F035EB7E9885302EAAE37455907@qq.com>
@ 2020-09-17  7:38 ` Philippe Mathieu-Daudé
  2020-09-17  7:45 ` Philippe Mathieu-Daudé
  2020-09-17  8:41 ` Alex Bennée
  2 siblings, 0 replies; 5+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-09-17  7:38 UTC (permalink / raw)
  To: casmac, qemu-devel; +Cc: Peter Maydell

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 2793 bytes --]

On 9/17/20 8:25 AM, casmac wrote:
> Hi all,
> 0„20„2 0„2 We try to add DSP architecure to QEMU 4.2. To load the COFF format
> object file, we have added loader code to load content from
> 0„2 the object file. The rom_add_blob() function is used. We firstly
> analyze the COFF file to figure out which sections are chained
> 0„2 together(so each chain forms a "memory blob"), and then allocate the
> memory blobs.
> 0„2
> 0„2 The psuedo code looks like:
> 0„2
> 0„20„20„2 0„2 0„2 0„2 for(i=0; i<BADTYPE; i++){
> 0„2 0„2 0„2 0„2 0„2 0„2 if(ary_sect_chain[i].exist) 0„2 //there is a chain of sections
> to allocate
> 0„2 0„2 0„2 0„2 0„2 0„2 {
> 0„2 0„2 0„2 0„2 0„2 0„2 0„2 0„2 ary_sect_chain[i].mem_region = g_new(MemoryRegion, 1);
> 0„2 0„2 0„2 0„2 0„2 0„2 0„2 0„2 memory_region_init_ram(...);
> 0„2 0„2 0„2 0„2 0„2 0„2 0„2 0„2 memory_region_add_subregion(sysmem, ....);
> 0„2 0„2 0„2 0„2 0„2 0„2 0„2 0„2 rom_add_blob(....);
> 0„2 0„2 0„2 0„2 0„2 0„2 }
> 0„2 0„2 0„20„2 0„2 }

Why do this silly mapping when you know your DSP memory map?

> ------------------------------------------------------
> ok.lds file:
> 
> MEMORY 0„2 /* MEMORY directive */
> {
> 0„2 0„2 ROM:0„20„20„20„20„20„20„20„20„2 0„2 origin = 000000h0„2 0„2 length = 001000h0„20„2 0„2 /* 4K
> 32-bit words on-chip ROM (C31/VC33) */

Per the TI spru031f datasheet, this is external (there is no
on-chip ROM).

I have my doubts there is actually a ROM mapped here...
Is this linkscript used to *test* a BIOS written in SRAM by
some JTAG?

> 0„2 0„2 /* 256K 32-bit word off-chip SRAM (D.Module.VC33-150-S2) */
> 0„2 0„2 BIOS:0„20„20„20„2 0„2 origin = 001000h0„20„20„2 0„2 length = 000300h
> 0„2 0„2 CONF_UTL: 0„2 origin = 001300h0„20„20„2 0„2 length = 000800h
> 0„2 0„2 FREE:0„20„20„20„2 0„2 origin = 001B00h0„20„20„2 0„2 length = 03F500h0„2 /* 259328 32-bit
> words */
> 0„2 0„2 RAM_0_1:0„20„2 0„2 origin = 809800h0„2 0„2 length = 000800h0„20„2 0„2 /* 2 x 1K
> 32-bit word on-chip SRAM (C31/VC33) */
> 0„2 0„2 RAM_2_3:0„20„2 0„2 origin = 800000h0„2 0„2 length = 008000h0„20„2 0„2 /* 2 x 16K
> 32-bit word on-chip SRAM (VC33 only) */
> }

You probably want to use:

  memory_region_init_ram(&s->extsram, OBJECT(dev), "eSRAM",
                         256 * KiB, &error_fatal);
  memory_region_add_subregion(get_system_memory(),
                              0x000000, &s->extsram);

  memory_region_init_ram(&s->ocsram, OBJECT(dev), "iSRAM",
                         2 * KiB, &error_fatal);
  memory_region_add_subregion(get_system_memory(),
                              0x809800, &s->ocsram);

Then different areas of the object file will be loaded into
the either the iSRAM or the eSRAM.

^ permalink raw reply	[flat|nested] 5+ messages in thread