From: Michael Rolnik <mrolnik@gmail.com>
To: Aleksandar Markovic <aleksandar.m.mail@gmail.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>,
"Pavel Dovgalyuk" <dovgaluk@ispras.ru>,
"Igor Mammedov" <imammedo@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: [PATCH v37 00/17] QEMU AVR 8 bit cores
Date: Thu, 28 Nov 2019 15:46:53 +0200 [thread overview]
Message-ID: <CAK4993i8zPyYH2hGxx0hP4qQKr9oTJV2T5JDtQmKHZe2EpAsvw@mail.gmail.com> (raw)
In-Reply-To: <CAL1e-=jJ5uNvYq7yNQYFhMJ0k94-d6mrybs-NyVjVi9Agb4Aeg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5787 bytes --]
I will rename them.
On Thu, Nov 28, 2019 at 3:41 PM Aleksandar Markovic <
aleksandar.m.mail@gmail.com> wrote:
>
>
> 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...
>
--
Best Regards,
Michael Rolnik
[-- Attachment #2: Type: text/html, Size: 7401 bytes --]
next prev parent reply other threads:[~2019-11-28 14:29 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
2019-11-28 13:46 ` Michael Rolnik [this message]
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=CAK4993i8zPyYH2hGxx0hP4qQKr9oTJV2T5JDtQmKHZe2EpAsvw@mail.gmail.com \
--to=mrolnik@gmail.com \
--cc=S.E.Harris@kent.ac.uk \
--cc=aleksandar.m.mail@gmail.com \
--cc=dovgaluk@ispras.ru \
--cc=imammedo@redhat.com \
--cc=me@xcancerberox.com.ar \
--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).