qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores


From: Michael Rolnik
Subject: Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores
Date: Tue, 5 Jul 2016 23:31:13 +0300

Hi Peter,

<quote>


*    You're probably better off having the device in one    patch and the
board model in another, rather than combining them.*




*    Generally, device models don't live in hw/<arch>, only board
  models. Put the device model in the appropriate subdirectory    of hw/,
which is 'misc' for this one.*





*    So what actually is this device? Is it something that    corresponds
to real hardware, or to some other emulator's    debug/test device, or
something we've just made up?    This is a good place to put a comment
answering this kind of    question (with links or references to
documentation if relevant).*
</quote>

as far as I understand from AVR specs each board has its own mapping of IO
registers, so this sample_io device is a part of the board itself.
Generally a device, as I see it, can be put on any board regardless of CPU,
here in AVR some IO registers are mapped into CPU registers.
So it makes it a part of the architecture itself.

<quote>
*    Don't enable debug by default.*
</quote>

My fault. I will disable it in the next version. I will do it with another
fixes if there are any.

<quote>

*    If you order things the other way up you won't need all these
forward declarations.*
</quote>

I am compiling on MAC, and gcc/clang keeps complaining that the function do
not have declaration, regardless of their order.


<quote>


*    As Richard says you have problems with trying to write    CPU
registers from a device anyway, but please consider    trying to have some
level of abstraction rather than*










*    just having the device code reach into the CPU object.    The general
model here is real hardware and devices, and    a real device has no access
into the inside workings of    another one except via whatever interfaces
the other    device explicitly provides.    (Better still would be if we
don't need to do any of this    at all, because it gets pretty ugly pretty
quickly.    The guest has access to its own registers by definition,    so
having a second way to read and write them via memory    is a bit weird.)*
</quote>

The code is already fixed.
And yes this is weird but this is the architecture.

Regards,
Michael


On Tue, Jul 5, 2016 at 10:54 PM, Peter Maydell <address@hidden>
wrote:

> On 5 July 2016 at 19:15, Michael Rolnik <address@hidden> wrote:
> > Hi Richard,
> >
> > Are there more pending issues with my code?
>
> Most of the issues I raised with the board model/device
> level code still seem to be present.
>
> thanks
> -- PMM
>



-- 
Best Regards,
Michael Rolnik


reply via email to

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