Re: [Qemu-devel] [PATCH v27 5/8] target/avr: Add limited support for USART and 16 bit timer peripherals

[Aleksandar Markovic <aleksandar.m.mail@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4176 bytes --]

On Thursday, December 5, 2019, Aleksandar Markovic <
aleksandar.m.mail@gmail.com> wrote:

>
>
> On Thursday, December 5, 2019, Aleksandar Markovic <
> aleksandar.m.mail@gmail.com> wrote:
>
>>
>>
>> On Thursday, July 25, 2019, Pavel Dovgalyuk <dovgaluk@ispras.ru> wrote:
>>
>>> > From: Qemu-devel [mailto:qemu-devel-bounces+patchwork-qemu-
>>> > devel=patchwork.kernel.org@nongnu.org] On Behalf Of Michael Rolnik
>>> > From: Sarah Harris <S.E.Harris@kent.ac.uk>
>>> >
>>> > 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?
>>
>> 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.
>>
>> 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)?
>>
>>
> Peter, may I ask you the same questions?
>
> I have a strong impression we here need to think colectively.
>
>
Of course, I did not mean that we'll ever support 600+ AVR SoCs/MCUs, or 53
AVR watchogs, but, as the work in Pavel's repository illustrates, we will
stumble very soon on, let's say different USART devices (in this case
between "atmega2560" and one of "xmega" cores. It is realistic that we can
potentially end up needing support for 5-6 AVR USARTs. How to name them, as
a first question?

Not to mention also possible dependencies between various devices,
interleaved memory ranges, shared registers...



> Yours,
>
> Aleksandar
>
>
>
>> 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
>>>
>>>
>>>

[-- Attachment #2: Type: text/html, Size: 5785 bytes --]