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

[Michael Rolnik]

Hi Pavel.

Please see my answers below.

On Thu, Jul 25, 2019 at 1:00 PM Pavel Dovgalyuk <address@hidden> wrote:

> > From: Qemu-devel [mailto:qemu-devel-bounces+patchwork-qemu-
> > devel=address@hidden] On Behalf Of Michael Rolnik
> > From: Sarah Harris <address@hidden>
> >
> > 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).
>

This is a question for Sara as she built it. (I think it was ATmega2560)


>
> 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
>
> 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).
>
You are right.

>
> 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.
>

Gladly.
You are welcome.
My initial intent was to provide CPU only and I hoped that others will
model the devices.

*Richard, Phil & all,*
what would be the right mechanism / procedure to split the work?


>
> Pavel Dovgalyuk
>
>

-- 
Best Regards,
Michael Rolnik