qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: OMAP3 bug: disassembler disagreed with translator


From: Антон Кочков
Subject: Re: [Qemu-devel] Re: OMAP3 bug: disassembler disagreed with translator
Date: Wed, 2 Mar 2011 21:23:05 +0300

Good day!
Right now it works, you can see source at the http://gitorious.org/droid/qemu

Don't see at the hw/motorola.c - here is only stub yet, not with real
hardware, i'm experimenting with it.
But omap3* files works ok with every other hardware.

Here you can see examples how it works:
https://www.droid-developers.org/wiki/QEMU

It works ok, but somewhere at the middle of bootrom chain it also
rewrite low bootrom location. (see attached trace files). For this
case i'm only change register for jump to the high bootrom location,
but i think it need to be more smart.

Also i'm dont know where I can add support for Secure
World/Services/Any other early TrustZone staff + efuse driver.

Best regards,
Anton Kochkov.




On Fri, Feb 18, 2011 at 15:39, Peter Maydell <address@hidden> wrote:
> On 18 February 2011 12:24,  <address@hidden> wrote:
>> On Feb 18, 2011, at 14:08, ext Антон Кочков wrote:
>>
>>> Here also modified omap3_boot.c file. I'm dont know why it is
>>> successfully load bootrom at 0x40014000, but cant do this for 0x14000
>>> - it always fill by zeroes.
>>> I'm only need copy memory from already loaded rom image from
>>> 0x40014000 to 0x00014000 and nothing more.
>>
>> Our OMAP3 boot emulation is a very simplified model. For example,
>> the boot ROM is never mapped to Q0 region, only Q1 region --
>> the boot ROM execution is started at 0x40014000 rather than
>> 0x00014000. There is no memory mapped at Q0 unless you attach
>> something to the GPMC before reset.
>
> However most boards do attach something to the GPMC;
> the Beagle puts a NAND device on GPMC CS0, which means that
> the GPMC will try to map NAND read/write functions on address
> 0 [*]. If you're trying to map a boot ROM there as well this will
> clash and you need to do something clever to work however
> the hardware does (presumably mapping the ROM there at startup
> and unmapping the ROM later in response to some undocumented
> event).
>
> [*] Only true in the version of omap_gpmc.c in the meego
> tree, but if you're doing omap3 stuff then I assume you're
> using that, not upstream.
>
> -- PMM
>

Attachment: qemu.log.gz
Description: GNU Zip compressed data

Attachment: omap3430_boot_rom.log.gz
Description: GNU Zip compressed data

Attachment: qemu-crash.log.gz
Description: GNU Zip compressed data


reply via email to

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