Re: [Qemu-devel] qemu vl.h hw/arm_boot.c hw/integratorcp.c hw/re...

[andrzej zaborowski]

Hi,

On 01/05/07, Daniel Silverstone <address@hidden> wrote:
> On Mon, 2007-04-30 at 02:24 +0000, Andrzej Zaborowski wrote:
> >       Account for machine with RAM which is not mapped at 0x0 in arm_boot.c.
>
> It seems a pity that you did this in a manner which didn't match the
> patch I published for the Simtec BAST boards. Now I have a bunch more
> merging effort to go through if I'm ever to get this patch merged. (Not
> that anyone has said a word to me since I posted it having solved all
> the issues that pbrook raised)

Your fix was almost identical to what I merged (and what I published
in January) so I don't think this is much to pity. Generally when
there are two versions of the same code, what is merged is bound to
not match at least one of them, however in this case this is really no
cause for a lot of rediffing effort.

> In particular you call the variable loader_start which seems somewhat
> misleading since essentially what it is is the emulated_sdram_base which
> is what I called it.

There's no reason for the bootloader to be always at the start of
SDRAM. It is at the start of some ROM in most real life cases, but
could be anywhere.

> I guess I'll have to do some serious merge work into my working tree and
> then post another patch. If you're interested. If not then I'll just
> carry on in my own little world and not bother with submitting to trunk,
> which seems a serious pity as it simply ends up being more work for all
> concerned and it forks the project.

Regarding the S3C2410 emulation we have done some of the same work and
this is never a nice thing and we'll have to figure a couple of things
out. Let me describe what would be optimal for me:
At some point we would start working with a single tree (outside
mainline). Considering that our S3C2410 implementation seems more
complete I would leave this implementation in that tree and base the
Simtec BAST machine on this implementation of the CPU. Switching the
machine code from using your implementation of the CPU should be easy
because both versions seem to have a clean api. I can try to do this.
Since you decided to ask for inclusion I assume that your tree is not
undergoing any huge changes anymore. However our tree is still heavily
evolving, thus I would be in charge of keeping the tree updated with
changes from mainline, until the point where we're *both* happy to
upstream.

I believe the area we're improving at this moment in the S3C2410 code
is not overlapping with any of your work so there's no hurry.

If anyone else is working on a machine based on S3C2410 they could
also do that in that common tree outside mainline.

Regarding slowness of the Interrupt Controller, I aimed to be correct
with the datasheet and implemented the arbitration algorithm (or
something similar to it) but I didn't mean for it to be enabled on
normal emulator runs. As you perhaps noticed the arbitration would
only have any effect in rare, little significant cases in which the
outcome is hazardous to rely on anyway - and even the hardware
implementation is probably not 100% correct. Moreover Paul already
found places in which my implementation is not even what the datasheet
describes, so this has to be changed anyway - however I don't see
anything wrong having the code present. Also I don't believe the
performance difference noticeable.

Regards,
Andrzej