Re: [Qemu-devel] [PATCH v30 0/8] QEMU AVR 8 bit cores

From:

Aleksandar Markovic

Subject:

Date:

Fri, 11 Oct 2019 23:15:07 +0200

address@hidden

Aleksandar Markovic <address@hidden> writes:

> On Friday, October 11, 2019, Philippe Mathieu-Daudé <address@hidden>
> wrote:
>
>> Hi Michael,
>>
>> On 9/2/19 4:01 PM, Michael Rolnik 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.
>>>
>>> the patches include the following
>>> 1. just a basic 8bit AVR CPU, without instruction decoding or translation
>>> 2. CPU features which allow define the following 8bit AVR cores
>>> avr1
>>> avr2 avr25
>>> avr3 avr31 avr35
>>> avr4
>>> avr5 avr51
>>> avr6
>>> xmega2 xmega4 xmega5 xmega6 xmega7
>>> 3. a definition of sample machine with SRAM, FLASH and CPU which allows
>>> to execute simple code
>>> 4. encoding for all AVR instructions
>>> 5. interrupt handling
>>> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
>>> 7. a decoder which given an opcode decides what istruction it is
>>> 8. translation of AVR instruction into TCG
>>> 9. all features together
>>>
>>> [..]
>>
>>> Michael Rolnik (7):
>>> target/avr: Add outward facing interfaces and core CPU logic
>>> target/avr: Add instruction helpers
>>> target/avr: Add instruction decoding
>>> target/avr: Add instruction translation
>>> target/avr: Add example board configuration
>>> target/avr: Register AVR support with the rest of QEMU, the build
>>> system, and the MAINTAINERS file
>>> target/avr: Add tests
>>>
>>> Sarah Harris (1):
>>> target/avr: Add limited support for USART and 16 bit timer peripherals
>>>
>>
>> Overall architecture patches look good, but I'd like some more time to
>> review the hardware patches. Unfortunately I won't have time until November.
>> There was a chat on IRC about your series,
>>
> I don't see the reason why do you initiate IRC communication on this topic,
> if we have the mailing list for discussing such important issues as
> introducing a new target (that should be definitely visible to all
> participants).

IRC is often a good way of quickly discussing something when someone is
about (often as a tangent from another discussion). I don't think there
is anything wrong with that as long as it's followed up on the mailing
list.

OK, at least the series got some attention, be it on IRC or on the list. I still find it odd that suddenly, after months and months of this series practically sitting on the list, any suggestion couldn't first be discussed here, so that we collectively find the best outcome. But, yes, I probably produced much ado about nothing. I hope that this would soon result in helping Michael complete the integration. Micheal, whatever I said regarding patch 4, is only a suggestion - if others are fine with it, I am fine too. Best luck to all involved! :)

Aleksandar

>
>> I suggested Richard we could merge patches 1-4 and 7. They are almost
>> sufficient to run the qemu-avr-tests gdbstub tests (but not the FreeRTOS
>> ones).

Which is was ;-)

--
Alex Bennée