qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC v5 2/5] hw/arm/digic: prepare DIGIC-based boards s


From: Georg Hofstetter
Subject: Re: [Qemu-devel] [RFC v5 2/5] hw/arm/digic: prepare DIGIC-based boards support
Date: Thu, 17 Oct 2013 20:51:41 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1

Hello,

just for the record.

flash (ROM1) on these cameras starts at 0xF8000000 and is either
0x00800000, 0x01000000 ox 0x02000000 large. just like with every
chip-selected memory, where the CS/EN line is selected by address masks,
addressing beyond the size memory repeats the content over and over.

ROM0 (0xF0000000) is rarely used.

The ARM in DIGIC has the high vectors selected by hardware and so the
reset vector is 0xFFFF0000. There you will find a bootloader.
Due to the memories repeating over and over starting from 0xF8000000,
the CPU will read from 0xF87F0000, 0xF8FF0000 or 0xF9FF0000, depending
on flash size (see above).

This kind of addressing beyond real flash end and wrapping over is
intentionally used by canon in multiple places - even in the main
firmware and when reflashing.
Some blocks are reflashed on a regular basis. They are used for
properties, which are the configuration area.

If you want to make the emulator behave like the real hardware, then you
have to:

 - reset to 0xFFFF0000
 - place ROM0 at 0xF0000000
 - place ROM1 at 0xF8000000
 - make the memory subsystem address correctly: (pseudocode)
     if((virt_addr & 0xF8000000) == 0xF0000000)
     {
         real_addr = 0xF0000000 | (virt_addr & (rom0_size - 1));
     }
     if((virt_addr & 0xF8000000) == 0xF8000000)
     {
         real_addr = 0xF8000000 | (virt_addr & (rom1_size - 1));
     }
 - make sure the flash emulation supports reflashing (properties)
 - change qemu memory subsystem to support execution from a flash that
   can be reprogrammed (properties are rewritten during startup)
   (maybe this is already possible, but it wasn't so 6 months ago)

OR
 - make workarounds so the system gets close to that behavior ;)


BR,
Georg

Am 17.10.2013 20:01, schrieb Peter Maydell:
> On 7 September 2013 08:04, Antony Pavlov <address@hidden> wrote:
> 
> I still think this is wrong. Real hardware can't possibly
> start at this address; we should boot the same way the
> hardware does.
> 
>> +}
>> +
>> +static DigicBoard digic4_board_canon_a1100 = {
>> +    .ram_size = 64 * 1024 * 1024,
>> +    /* CHDK recommends this address for ROM disassembly */
>> +    .start_addr = 0xffc00000,
>> +};
> 
> thanks
> -- PMM
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]