From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D706C43603 for ; Fri, 6 Dec 2019 17:08:50 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 42C8820706 for ; Fri, 6 Dec 2019 17:08:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 42C8820706 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=ispras.ru Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:41502 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1idH61-0006pP-0A for qemu-devel@archiver.kernel.org; Fri, 06 Dec 2019 12:08:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50867) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1idFEl-0001qv-70 for qemu-devel@nongnu.org; Fri, 06 Dec 2019 10:09:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1idFEj-0001PA-5l for qemu-devel@nongnu.org; Fri, 06 Dec 2019 10:09:42 -0500 Received: from mail.ispras.ru ([83.149.199.45]:53758) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1idFEi-0001KP-Ny for qemu-devel@nongnu.org; Fri, 06 Dec 2019 10:09:41 -0500 Received: from PASHAISP (unknown [85.142.117.226]) by mail.ispras.ru (Postfix) with ESMTPSA id 5E71B540081; Fri, 6 Dec 2019 14:32:17 +0300 (MSK) From: "Pavel Dovgalyuk" To: "'Aleksandar Markovic'" References: <20190719082647.18113-1-mrolnik@gmail.com> <20190719082647.18113-6-mrolnik@gmail.com> <000c01d542cf$d8476a00$88d63e00$@ru> In-Reply-To: Subject: RE: [Qemu-devel] [PATCH v27 5/8] target/avr: Add limited support for USART and 16 bit timer peripherals Date: Fri, 6 Dec 2019 14:32:12 +0300 Message-ID: <004401d5ac28$d37bc170$7a734450$@ru> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01D5AC41.F8C8F970" X-Mailer: Microsoft Office Outlook 12.0 Content-Language: ru Thread-Index: AdWrVpJ1KnWzxR93TgKTqY4duGAvxAA0QWbQ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 83.149.199.45 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: richard.henderson@linaro.org, 'Sarah Harris' , 'Michael Rolnik' , qemu-devel@nongnu.org, philmd@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" This is a multi-part message in MIME format. ------=_NextPart_000_0045_01D5AC41.F8C8F970 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 From: Aleksandar Markovic [mailto:aleksandar.m.mail@gmail.com]=20 Sent: Thursday, December 05, 2019 1:27 PM To: Pavel Dovgalyuk Cc: Michael Rolnik; qemu-devel@nongnu.org; richard.henderson@linaro.org; = Sarah Harris; philmd@redhat.com Subject: Re: [Qemu-devel] [PATCH v27 5/8] target/avr: Add limited = support for USART and 16 bit timer peripherals =20 On Thursday, July 25, 2019, Pavel Dovgalyuk wrote: > From: Qemu-devel [mailto:qemu-devel-bounces+patchwork-qemu- > devel=3Dpatchwork.kernel.org@nongnu.org] On Behalf Of Michael Rolnik > From: Sarah Harris >=20 > These were designed to facilitate testing but should provide enough = function to be useful in > other contexts. USART is very useful for testing, but to which model of AVR is belongs? We also started implementation of USART and other devices in our = internship program, using prior version of your patches. There were other register addresses for the registers and some of them = even intersect making read/write logic more complex (we looked at Atmega8). You also mix the board and the SoC into one file, making = hardware-on-chip harder to reuse. I think that the structure can be revised in the following way: Board -> SoC -> Devices =20 Pavel, =20 By "structure", did you mean structure of patches? =20 I mean structure of files/qobjects. =20 Let's say, after the all ISA instruction patches are introduced, we = first introduce one real board of our choice (only infrastructure, with = almost empty content, than devices on that board, than the corresponding = SoC/MCU infrastucture, than device in that SoC. =20 Additional boards would follow the same pattern, potentially reusing = already implemented devices, or whole SoC/MCU. =20 That=E2=80=99s why we tried to join peripherals and CPU into SoC/MCU = =E2=80=93 for reusing the hardware configuration. =20 One more question: =20 We already saw that devices within SoC/MCUs for AVR platform exibit = great variation. First, there are around 17 generation of AVR cores = (avr1, avr2, ... xmega7). Than, there is, I think 600+ SoC/MCU models = (hard to believe, but true). Each SoC defines its devices, and in = potentially different way (not only its starting address, but real = differences in terms of functionality). I thought that at least for a = particular core, the devices would be defined in a consistent way, but = even that is not true - for example ADC for a SoC having core X can be = significantly different that ADC for another SoC having the same core X. =20 How to deal with such avalanche of devices? How to organize and maintain = 27 significantly different versions of ADC; and 53 significantly = different versions of Watchdogs (the numbers are invented by me, but are = likely to describe the situation well)? =20 I hope, that the differences will be rather small and allow making = simple flag switches like in mips/translate.c, when decoding depends on = CPU features. In the opposite case we can create several instances of the device = implementations. =20 =20 Best regards, =20 Aleksandar =20 =20 =20 =20 Board includes SoC, loads the firmware, and adds some external = peripheral devices, if needed. SoC includes embedded peripherals. It dispatches IO memory accesses and = passes them to the devices. In this case you can have different register addresses = for different SoCs, but the embedded device emulation code can be mostly the same for simple = devices like USART. > Only a subset of the functions of each peripheral is implemented, = mainly due to the lack of a > standard way to handle electrical connections (like GPIO pins). We did not got too much results, you can check for our changes here: = https://github.com/Dovgalyuk/qemu/tree/avr8 But we can help you in development of better version of the patches and = split the work for making this platform more usable. Pavel Dovgalyuk =20 Pavel Dovgalyuk =20 ------=_NextPart_000_0045_01D5AC41.F8C8F970 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

From:= = Aleksandar Markovic [mailto:aleksandar.m.mail@gmail.com] =
Sent: Thursday, December 05, 2019 1:27 PM
To: Pavel = Dovgalyuk
Cc: Michael Rolnik; qemu-devel@nongnu.org; = richard.henderson@linaro.org; Sarah Harris; = philmd@redhat.com
Subject: Re: [Qemu-devel] [PATCH v27 5/8] = target/avr: Add limited support for USART and 16 bit timer = peripherals

 



On = Thursday, July 25, 2019, Pavel Dovgalyuk <dovgaluk@ispras.ru> = wrote:

> From: Qemu-devel [mailto:qemu-devel-bounces+pat= chwork-qemu-
> devel=3Dpatchwork.kernel.org@nong= nu.org] On Behalf Of Michael Rolnik
> From: Sarah Harris = <S.E.Harris@kent.ac.uk>
&g= t;
> These were designed to facilitate testing but should provide = enough function to be useful in
> other contexts.

USART is = very useful for testing, but to which model of AVR is belongs?
We = also started implementation of USART and other devices in our internship = program,
using prior version of your patches.
There were other = register addresses for the registers and some of them even = intersect
making read/write logic more complex (we looked at = Atmega8).

You also mix the board and the SoC into one file, = making hardware-on-chip harder to reuse.

I think that the = structure can be revised in the following way:
Board -> SoC -> = Devices

 

Pavel,

 

By "structure", did you mean structure of = patches?

 

I mean structure of files/qobjects.

 

Let's say, after the all ISA instruction patches are = introduced, we first introduce one real board of our choice (only = infrastructure, with almost empty content, than devices on that board, = than the corresponding SoC/MCU infrastucture, than device in that = SoC.

 

Additional boards would follow the same pattern, = potentially reusing already implemented devices, or whole = SoC/MCU.

 

That=E2=80=99s why we tried to join peripherals and CPU into SoC/MCU = =E2=80=93 for reusing the hardware = configuration.

 

One more = question:

 

We already saw that devices within SoC/MCUs for AVR = platform exibit great variation. First, there are around 17 generation = of AVR cores (avr1, avr2, ... xmega7). Than, there is, I think 600+ = SoC/MCU models (hard to believe, but true). Each SoC defines its = devices, and in potentially different way (not only its starting = address, but real differences in terms of functionality). I thought that = at least for a particular core, the devices would be defined in a = consistent way, but even that is not true - for example ADC for a SoC = having core X can be significantly different that ADC for another SoC = having the same core X.

 

How to deal with such avalanche of devices? How to = organize and maintain 27 significantly different versions of ADC; and 53 = significantly different versions of Watchdogs (the numbers are invented = by me, but are likely to describe the situation well)?

 

I hope, that the differences will be rather small and allow making = simple flag switches like in mips/translate.c, when decoding depends on = CPU features.

In the opposite case we can create several instances of the device = implementations.

 

 

Best regards,

 

Aleksandar

 

 

 

 

Board includes SoC, = loads the firmware, and adds some external peripheral devices, if = needed.

SoC includes embedded peripherals. It dispatches = IO memory accesses and passes them
to the devices. In this case you = can have different register addresses for different SoCs, but
the = embedded device emulation code can be mostly the same for simple devices = like USART.

> Only a subset of the functions of each = peripheral is implemented, mainly due to the lack of a
> standard = way to handle electrical connections (like GPIO pins).

We did not = got too much results, you can check for our changes here: https://github.com/Dovgalyuk/qemu/tree/avr8

= But we can help you in development of better version of the patches and = split the work
for making this platform more usable.


Pavel = Dovgalyuk

 

Pavel Dovgalyuk

 

------=_NextPart_000_0045_01D5AC41.F8C8F970--