On Friday, October 11, 2019, Alex Bennée <alex.ben...@linaro.org> wrote:

>
> Aleksandar Markovic <aleksandar.m.m...@gmail.com> writes:
>
> > On Friday, October 11, 2019, Philippe Mathieu-Daudé <phi...@redhat.com>
> > 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
>
>

Reply via email to