On Thu, 17 Oct 2013 20:17:15 +0100
Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 17 October 2013 19:51, Georg Hofstetter <q...@g3gg0.de> 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
