Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

[Aleksandar Markovic]

On Thursday, November 28, 2019, dovgaluk <address@hidden> wrote:
> Aleksandar Markovic писал 2019-11-28 13:20:
> > On Thursday, November 28, 2019, dovgaluk <address@hidden> wrote:
> >
> > > Aleksandar Markovic писал 2019-11-28 12:28:
> > > On Thursday, November 28, 2019, Philippe Mathieu-Daudé
> > > <address@hidden> wrote:
> > >
> > > Add famous ATmega MCUs:
> > >
> > > - middle range: ATmega168 and ATmega328
> > > - high range: ATmega1280 and ATmega2560
> > >
> > > Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
> > > ---
> > >
> > > Philippe, hi.
> > >
> > > Thank you for the impetus you give us all.
> > >
> > > However, is this the right direction?
> > >
> > > Let's analyse some bits and pieces.
> > >
> > > Starting from the commit message, the word "famous" is used, but I
> > > really don't see enumerated CPUs/MCUs are any special in Atmel
> > > lineup.
> > > Other than we often used the doc describing them (cited several
> > > times
> > > in our discussions) as our reference, but that doesn't make them
> > > "famous". Ofcourse, there other docs for other Atmel CPUs/MCUs, of
> > > at
> > > lest equivalent significance. For example, "tiny" ones are at least
> > > as
> > > famous as "mega" ones.
> > >
> > > Then, you introduce the term MCU, without proper discussion with
> > > others on terminology. In parlance of QEMU, ATmega168 at al. are
> > > CPUs
> > > (we all know and assume that that are some peripherals in it). I am
> > > not against using the term MCU, but let's first sync up on that.
> > >
> > > The added terminology trouble is that MCUs, as you defined them,
> > > have
> > > in array atmega_mcu[] a field called "cpu_type" - why is that field
> > > not called "mcu_type"? *Very* confusing for any future reader. And
> > > then, similar terminology conundrum continues with macro
> > > AVR_CPU_TYPE_NAME().
> >
> > MCU is a system-on-chip which includes CPU core and peripheral
> > devices.
> > Separating this is better that including everything into the machine.
> >
> > E.g., different MCUs may have different IO addresses for USART.
> >
> > Pavel,
> >
> > Do you know how is this resolved for other platforms?
> >
> > How other platfirms organize and use terms "soc", "mcu", "cpu",
> > "core", "cpu core"? And what is the relation between each of them and
> > QEMU command line options "-cpu" and "-machine"? Is thar organization
> > the same accross all platforms?
>
> Here is an ARM example:
>  SoCs: hw/arm/aspeed_soc.c include/hw/arm/aspeed_soc.h
>  Boards: hw/arm/aspeed.c
>
> > (I am asking you as you most likely have much wider experience in the
> > topic, sincr mine i limited to mips emulation)
>
> As far as I know, there are MIPS SoCs too.
> Doesn't QEMU emulate any of them?

It does, but, admitedly, we could do a much better job in that area, and we are certainly not good as a reference platform in that area. Some features of MIPS SoCs are extremely difficult to implement in QEMU though (for example, so called hardware miltithreading).

Thanks,

Aleksandar

 

> > > > All of the above is far less important than this question: What
> > > > are we
> > > > achieving with proposed CPU/MCU definitions? I certainly see the
> > > > value
> > > > of fitting the complex variety of AVR CPUs/MCUs into QEMU object
> > > > model. No question about that. However, is this the right moment
> > > > to do
> > > > it? There are still some unresolved architectural problems with
> > > > peripheral definitions, as I noted in yhe comment to Michael's
> > > > last
> > > > cover letter. This patch does not solve them. It just assumes
> > > > everything is ready with peripherals, let's build CPUs/MCUs. The
> > > > machines based on proposed CPUs/MCUs are not more real that
> > > > machine
> > > > based on Michael's "sample" machine. At least Michal says "this is
> > > > not
> > > > a real machine". If we used proposed CPUs/MCUs from this patch,
> > > > the
> > > > resulting machine is as "paper" machine as yhe "sample" machine.
> > > > We
> > > > would just live in a la-la lend of thinking: "wow, we model real
> > > > hardware now".
> > > >
> > > > I would rather accept into QEMU a series admitting we are still
> > > > far
> > > > from modelling real machine or CPU/MCU, than a series that gives
> > > > an
> > > > illusion that we are modelling real machine or CPU/MCU.
> > > >
> > > > As far as utility of this patch for Michael's series, it looks to
> > > > me
> > > > they add more headake than help (not saying that the help is not
> > > > present) to Michael. He would have anotter abstraction layer to
> > > > think
> > > > of, at the moment he desperately needs (in my opinion) to focus on
> > > > providing the as solid as possible, and as complete as possinle
> > > > foundations. This patch looks like building castles in the air.
> > > > Again,
> > > > I am not claiming that the patch is not helpful at all.
> > > >
> > > > In summary, I think that this patch is premature.
>
>
>
> Pavel Dovgalyuk