From: Georg Hofstetter <qemu@g3gg0.de>
To: Peter Maydell <peter.maydell@linaro.org>,
Antony Pavlov <antonynpavlov@gmail.com>
Cc: "Alex Dumitrache" <broscutamaker@gmail.com>,
"Peter Crosthwaite" <peter.crosthwaite@xilinx.com>,
"Giovanni Condello" <condellog@gmail.com>,
g3gg0 <georg.hofstetter@lx-networking.de>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Paul Brook" <paul@codesourcery.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Andreas Färber" <afaerber@suse.de>
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 [thread overview]
Message-ID: <526031BD.9030204@g3gg0.de> (raw)
In-Reply-To: <CAFEAcA-q93o3PseJhqAYY=RABPjGmuj-RpU3PzNJ3OKn6fHEqA@mail.gmail.com>
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 <antonynpavlov@gmail.com> 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
>
next prev parent reply other threads:[~2013-10-17 18:51 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-07 7:04 [Qemu-devel] [RFC v5 0/5] hw/arm: add initial support for Canon DIGIC SoC Antony Pavlov
2013-09-07 7:04 ` [Qemu-devel] [RFC v5 1/5] hw/arm: add very " Antony Pavlov
2013-09-13 14:48 ` Andreas Färber
2013-09-07 7:04 ` [Qemu-devel] [RFC v5 2/5] hw/arm/digic: prepare DIGIC-based boards support Antony Pavlov
2013-10-17 18:01 ` Peter Maydell
2013-10-17 18:51 ` Georg Hofstetter [this message]
2013-10-17 19:17 ` Peter Maydell
2013-10-20 0:13 ` Georg Hofstetter
2013-10-22 11:26 ` Antony Pavlov
2013-12-04 20:22 ` Antony Pavlov
2013-12-04 20:29 ` Peter Maydell
2013-12-04 21:20 ` Antony Pavlov
2013-12-04 21:34 ` Peter Maydell
2013-12-05 0:20 ` Peter Crosthwaite
2013-12-05 8:02 ` Peter Maydell
2013-12-05 0:25 ` Peter Crosthwaite
2013-12-05 7:59 ` Peter Maydell
2013-12-07 0:55 ` [Qemu-devel] [RFC 0/2] ARM: make possible to use high vectors for reset exception Antony Pavlov
2013-12-07 0:55 ` [Qemu-devel] [RFC 1/2] ARM: cpu: add "hivecs" property (high vectors on reset) Antony Pavlov
2013-12-07 1:00 ` Peter Crosthwaite
2013-12-07 20:44 ` Antony Pavlov
2013-12-07 22:14 ` Peter Crosthwaite
2013-12-07 1:14 ` Peter Maydell
2013-12-07 0:55 ` [Qemu-devel] [RFC 2/2] ARM: arm_cpu_reset: make possible to use high vectors for reset_exc Antony Pavlov
2013-12-07 1:08 ` Peter Crosthwaite
2013-12-07 20:49 ` Antony Pavlov
2013-12-07 21:03 ` Peter Maydell
2013-09-07 7:04 ` [Qemu-devel] [RFC v5 3/5] hw/arm/digic: add timer support Antony Pavlov
2013-10-17 17:51 ` Peter Maydell
2013-09-07 7:04 ` [Qemu-devel] [RFC v5 4/5] hw/arm/digic: add UART support Antony Pavlov
2013-10-17 17:54 ` Peter Maydell
2013-10-22 10:48 ` Antony Pavlov
2013-09-07 7:04 ` [Qemu-devel] [RFC v5 5/5] hw/arm/digic: add NOR ROM support Antony Pavlov
2013-10-17 18:00 ` Peter Maydell
2013-09-13 14:37 ` [Qemu-devel] [RFC v5 0/5] hw/arm: add initial support for Canon DIGIC SoC Antony Pavlov
2013-09-20 9:01 ` [Qemu-devel] [RFC v5 0/5] hw/arm: add initial support for Canon DIGIC SoC: ping-ping Antony Pavlov
2013-09-28 10:41 ` [Qemu-devel] [RFC v5 0/5] hw/arm: add initial support for Canon DIGIC SoC: ping-ping-ping Antony Pavlov
2013-09-28 10:50 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=526031BD.9030204@g3gg0.de \
--to=qemu@g3gg0.de \
--cc=afaerber@suse.de \
--cc=antonynpavlov@gmail.com \
--cc=broscutamaker@gmail.com \
--cc=condellog@gmail.com \
--cc=georg.hofstetter@lx-networking.de \
--cc=paul@codesourcery.com \
--cc=pbonzini@redhat.com \
--cc=peter.crosthwaite@xilinx.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.