From: Aleksandar Markovic <aleksandar.m.mail@gmail.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
Joaquin de Andres <me@xcancerberox.com.ar>,
Richard Henderson <richard.henderson@linaro.org>,
Sarah Harris <S.E.Harris@kent.ac.uk>,
QEMU Developers <qemu-devel@nongnu.org>,
Michael Rolnik <mrolnik@gmail.com>,
Igor Mammedov <imammedo@redhat.com>,
Pavel Dovgalyuk <dovgaluk@ispras.ru>
Subject: Re: [PATCH v37 00/17] QEMU AVR 8 bit cores
Date: Thu, 28 Nov 2019 14:41:25 +0100 [thread overview]
Message-ID: <CAL1e-=jJ5uNvYq7yNQYFhMJ0k94-d6mrybs-NyVjVi9Agb4Aeg@mail.gmail.com> (raw)
In-Reply-To: <5a784557-f322-dc3a-4ff1-a7d9a0409448@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 5481 bytes --]
On Thursday, November 28, 2019, Philippe Mathieu-Daudé <philmd@redhat.com>
wrote:
> On 11/28/19 2:25 PM, Michael Rolnik wrote:
>
>> I don't see why you say that the peripherals are inside the chip, there
>> is CPU within target/avr directory and then there are some peripherals in
>> hw directory, CPU does not depend on them. what am I missing?
>>
>> On Thu, Nov 28, 2019 at 3:22 PM Aleksandar Markovic <
>> aleksandar.m.mail@gmail.com <mailto:aleksandar.m.mail@gmail.com>> wrote:
>>
>>
>>
>> On Thursday, November 28, 2019, Michael Rolnik <mrolnik@gmail.com
>> <mailto:mrolnik@gmail.com>> wrote:
>>
>>
>>
>> On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic
>> <aleksandar.m.mail@gmail.com
>> <mailto:aleksandar.m.mail@gmail.com>> wrote:
>>
>> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik
>> <mrolnik@gmail.com <mailto:mrolnik@gmail.com>> wrote:
>> >
>> > This series of patches adds 8bit AVR cores to QEMU.
>> > All instruction, except BREAK/DES/SPM/SPMX, are
>> implemented. Not fully tested yet.
>> > However I was able to execute simple code with functions.
>> e.g fibonacci calculation.
>> > This series of patches include a non real, sample board.
>> > No fuses support yet. PC is set to 0 at reset.
>> >
>>
>> I have a couple of general remarks, so I am responding to
>> the cover
>> letter, not individual patches.
>>
>> 1) The licenses for Sarah devices differ than the rest -
>> shouldn't all
>> licenses be harmonized?
>>
>> Sarah,
>> do you mind if use the same license I use for my code?
>>
>>
>> 2) There is an architectural problem with peripherals. It is
>> possible
>> that they evolve over time, so, for example, USART could not
>> be the
>> same for older and newer CPUs (in principle, newer peripheral
>> is
>> expected to be o sort of "superset" of the older). How do
>> you solve
>> that problem? Right now, it may not looks serious to you,
>> but if you
>> don;t think about that right now, from the outset, soon the
>> code will
>> become so entangled, ti woudl be almost very difficult to
>> fix it.
>> Please think about that, how would you solve it, is there a
>> way to
>> pass the information on the currently emulated CPU to the code
>> covering a peripheral, and provide a different behaviour?
>>
>> Hi Aleksandar,
>>
>> Please explain.
>>
>>
>> My concern is about peripherals inside the chip, together with the
>> core.
>>
>> If one models, let's say an external (in the sense, it is a separate
>> chip) ADC (analog-to-digital converter), one looks at specs,
>> implement what is resonable possible in QEMU, plug it in in one of
>> machines thst contains it, and that's it. That ADC remains the same,
>> of course, whatever the surrounding system is.
>>
>> In AVR case, I think we have a phenomenon likes of which we didn't
>> see before (at least I don't know about). Number of AVR
>> microcontrollers is very large, and both cores and peripherals
>> evolved.
>>
>> For cores, you handle differences with all these AVR_FEATURE macros,
>> and this seems to be working, no significant objection from my side,
>> and btw that was not an easy task to execute, all admiration from me.
>>
>> But what about peripherals inside the chip? A peripheral with the
>> same name and the same general area of functionality may be
>> differently specified for microcontrollers from 2010 and 2018. By
>> the difference I don't mean starting address, but the difference in
>> behavior. I don't have time right now to spell many examples, but I
>> read three different specs, and there are differences in USART
>> specifications.
>>
>> I am not clear what is your envisioned solution for these cases.
>> Would you such close, but not the same, flabors of a peripheral
>> treat as if they are two completely separate cases of a peripheral?
>> Or would you have a single peripheral that would somehow configure
>> itself depending on the core it is attached to?
>>
>> I hope I was clearer this time.
>>
>> Aleksandar
>>
>>
>>
>>
>> I don't see any problem from CPU's perspective.
>> as for the sample board is just a sample, I hope other people
>> will create real models or real hw.
>> there was no way I could provide a CPU alone, that's why there
>> is sample.
>>
>
> If I understand Aleksandar correctly, the naming is incorrect because too
> generic to AVR family, why Sarah only modeled the Atmel implementation.
>
> Renaming devices such hw/char/avr_usart.c -> hw/char/atmel_usart.c
> (similarly with the macros) would be enough Aleksandar?
>
>
Some renaming could help, perhaps not quite like the one above, but my
point (which I find hard to believe I can't explain to you) is that
peripherals inside the chip evolved over time, as starkly opposed to
external peripherals that are set in stone...
[-- Attachment #2: Type: text/html, Size: 6845 bytes --]
next prev parent reply other threads:[~2019-11-28 14:06 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-27 17:52 [PATCH v37 00/17] QEMU AVR 8 bit cores Michael Rolnik
2019-11-27 17:52 ` [PATCH v37 01/17] target/avr: Add outward facing interfaces and core CPU logic Michael Rolnik
2019-11-27 22:25 ` Philippe Mathieu-Daudé
2019-11-28 12:04 ` Michael Rolnik
2019-11-27 17:52 ` [PATCH v37 02/17] target/avr: Add instruction helpers Michael Rolnik
2019-11-27 22:26 ` Philippe Mathieu-Daudé
2019-11-27 17:52 ` [PATCH v37 03/17] target/avr: Add instruction decoding Michael Rolnik
2019-11-27 17:52 ` [PATCH v37 04/17] target/avr: Add instruction translation - Registers definition Michael Rolnik
2019-11-27 17:52 ` [PATCH v37 05/17] target/avr: Add instruction translation - Arithmetic and Logic Instructions Michael Rolnik
2019-11-30 10:33 ` Aleksandar Markovic
2019-11-30 16:29 ` Aleksandar Markovic
2019-11-30 17:05 ` Michael Rolnik
2019-11-30 17:14 ` Aleksandar Markovic
2019-11-30 23:11 ` Aleksandar Markovic
2019-12-02 7:41 ` Michael Rolnik
2019-12-02 8:55 ` Aleksandar Markovic
2019-12-02 9:01 ` Aleksandar Markovic
2019-11-27 17:52 ` [PATCH v37 06/17] target/avr: Add instruction translation - Branch Instructions Michael Rolnik
2019-11-27 17:52 ` [PATCH v37 07/17] target/avr: Add instruction translation - Bit and Bit-test Instructions Michael Rolnik
2019-12-05 12:28 ` Aleksandar Markovic
2019-12-05 13:17 ` Michael Rolnik
2019-12-05 13:28 ` Michael Rolnik
2019-11-27 17:52 ` [PATCH v37 08/17] target/avr: Add instruction translation - MCU Control Instructions Michael Rolnik
2019-11-27 17:52 ` [PATCH v37 09/17] target/avr: Add instruction translation - CPU main translation function Michael Rolnik
2019-11-27 17:52 ` [PATCH v37 10/17] target/avr: Add instruction disassembly function Michael Rolnik
2019-12-02 0:28 ` Aleksandar Markovic
2019-12-02 7:04 ` Michael Rolnik
2019-12-02 10:12 ` Aleksandar Markovic
2019-12-02 12:01 ` Aleksandar Markovic
2019-12-03 11:18 ` Philippe Mathieu-Daudé
2019-12-03 14:24 ` Michael Rolnik
2019-11-27 17:52 ` [PATCH v37 11/17] target/avr: Add limited support for USART and 16 bit timer peripherals Michael Rolnik
2019-11-27 17:52 ` [PATCH v37 12/17] target/avr: Add example board configuration Michael Rolnik
2019-11-30 10:49 ` Aleksandar Markovic
2019-11-30 16:57 ` Michael Rolnik
2019-12-03 11:29 ` Philippe Mathieu-Daudé
2019-11-27 17:52 ` [PATCH v37 13/17] target/avr: Register AVR support with the rest of QEMU Michael Rolnik
2019-12-05 12:55 ` Aleksandar Markovic
2019-11-27 17:52 ` [PATCH v37 14/17] target/avr: Update build system Michael Rolnik
2019-11-27 17:52 ` [PATCH v37 15/17] target/avr: Add boot serial test Michael Rolnik
2019-11-27 17:52 ` [PATCH v37 16/17] target/avr: Add Avocado test Michael Rolnik
2019-11-27 17:52 ` [PATCH v37 17/17] target/avr: Update MAINTAINERS file Michael Rolnik
2019-11-28 20:19 ` Philippe Mathieu-Daudé
2019-11-30 13:43 ` Aleksandar Markovic
2019-11-27 21:06 ` [PATCH v37 00/17] QEMU AVR 8 bit cores Aleksandar Markovic
2019-11-28 12:28 ` Michael Rolnik
2019-11-28 13:22 ` Aleksandar Markovic
2019-11-28 13:25 ` Michael Rolnik
2019-11-28 13:31 ` Aleksandar Markovic
2019-11-28 16:20 ` Alex Bennée
2019-11-28 19:32 ` Aleksandar Markovic
2019-11-29 22:49 ` Aleksandar Markovic
2019-11-29 23:52 ` Aleksandar Markovic
2019-11-28 13:34 ` Philippe Mathieu-Daudé
2019-11-28 13:41 ` Aleksandar Markovic [this message]
2019-11-28 13:46 ` Michael Rolnik
2019-11-28 14:16 ` Philippe Mathieu-Daudé
2019-11-28 14:50 ` Aleksandar Markovic
2019-11-28 18:09 ` Aleksandar Markovic
2019-12-01 13:09 ` Aleksandar Markovic
2019-12-01 13:11 ` Aleksandar Markovic
2019-11-29 9:24 ` Sarah Harris
2019-11-28 15:00 ` Aleksandar Markovic
2019-11-30 11:28 ` Aleksandar Markovic
2019-11-30 17:00 ` Michael Rolnik
2019-12-02 9:35 ` Aleksandar Markovic
2019-12-02 9:59 ` Aleksandar Markovic
2019-12-02 13:24 ` Michael Rolnik
2019-12-02 14:01 ` Aleksandar Markovic
2019-12-02 16:09 ` Michael Rolnik
2019-12-02 21:15 ` Aleksandar Markovic
2019-12-02 23:37 ` Aleksandar Markovic
2019-12-03 1:17 ` Aleksandar Markovic
2019-12-03 1:48 ` Aleksandar Markovic
2019-12-03 9:56 ` Michael Rolnik
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='CAL1e-=jJ5uNvYq7yNQYFhMJ0k94-d6mrybs-NyVjVi9Agb4Aeg@mail.gmail.com' \
--to=aleksandar.m.mail@gmail.com \
--cc=S.E.Harris@kent.ac.uk \
--cc=dovgaluk@ispras.ru \
--cc=imammedo@redhat.com \
--cc=me@xcancerberox.com.ar \
--cc=mrolnik@gmail.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).