On Thursday, December 5, 2019, Aleksandar Markovic < [email protected]> wrote:
> > > On Thursday, July 25, 2019, Pavel Dovgalyuk <[email protected]> wrote: > >> > From: Qemu-devel [mailto:qemu-devel-bounces+patchwork-qemu- >> > [email protected]] On Behalf Of Michael Rolnik >> > From: Sarah Harris <[email protected]> >> > >> > 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. 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 >> >> >>
