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

[Antony Pavlov]

On Thu, 17 Oct 2013 20:17:15 +0100
Peter Maydell <address@hidden> wrote:

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

Here is my proposition:

1. qemu board code setup CPU to start from 0xFFFF0000. (0xffff0000 is a ROM 
address
on DIGIC chips)

2. we need somehow put a 'jump-to-beginning-of-ROM' instruction to 0xffff0000.
(We can't put barebox to 0xffff0000 as barebox image is bigger that 64K.)

There is at least two possibilities to do so:
 * we can use specially prepared ROM image;
 * qemu board code can insert by itself a 'jump-to-beginning-of-ROM' instruction
after loading ROM image (as qemu MIPS Malta board code does).

3. CPU starts as usual. Branching to barebox code in ROM happends in a natural 
way!

Please comment my proposition.

-- 
Best regards,
  Antony Pavlov