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

[Peter Maydell]

On 17 October 2013 19:51, Georg Hofstetter <address@hidden> wrote:
> 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.

Thanks for this explanation of the hardware.

> If you want to make the emulator behave like the real hardware, then you
> have to:
>
>  - reset to 0xFFFF0000

Yep. This implies having a cpu property corresponding to "enable
hivecs from bootup" (matching the h/w config signal), and making
sure cpu reset honours it; that's fairly easy.

>  - 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));
>      }

The easy way to do this is just to use memory region aliases
to repeat the ROM through the whole area; you can do that
in the board model without having to mess with the memory
subsystem itself.

>  - 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)

I agree that these are probably missing features in our flash
emulation, but aren't they orthogonal to the question of how
we handle CPU reset and what the starting PC should be?

-- PMM