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

[Sarah Harris]

Hi Michael and Pavel,

The USART was based on the ATMega2560.
It was designed for testing so its functionality is somewhat limited.

Peripherals seem to vary between AVR chips so the configuration in the 2560 may 
not match other chips, especially the older ones.
>From memory, the only shared registers in the 2560 USART are the PRR's, which 
>we implemented by adding single byte memory regions during board 
>initialisation (so that the memory region wasn't part of any one device).
I expect there are cleaner ways to do it.

Kind regards,
Sarah Harris

On Thu, 25 Jul 2019 20:52:33 +0300
Michael Rolnik <address@hidden> wrote:

> 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