I will rename them. On Thu, Nov 28, 2019 at 3:41 PM Aleksandar Markovic < aleksandar.m.m...@gmail.com> wrote:
> > > On Thursday, November 28, 2019, Philippe Mathieu-Daudé <phi...@redhat.com> > wrote: > >> On 11/28/19 2:25 PM, Michael Rolnik wrote: >> >>> I don't see why you say that the peripherals are inside the chip, there >>> is CPU within target/avr directory and then there are some peripherals in >>> hw directory, CPU does not depend on them. what am I missing? >>> >>> On Thu, Nov 28, 2019 at 3:22 PM Aleksandar Markovic < >>> aleksandar.m.m...@gmail.com <mailto:aleksandar.m.m...@gmail.com>> wrote: >>> >>> >>> >>> On Thursday, November 28, 2019, Michael Rolnik <mrol...@gmail.com >>> <mailto:mrol...@gmail.com>> wrote: >>> >>> >>> >>> On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic >>> <aleksandar.m.m...@gmail.com >>> <mailto:aleksandar.m.m...@gmail.com>> wrote: >>> >>> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik >>> <mrol...@gmail.com <mailto:mrol...@gmail.com>> 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. >>> > >>> >>> I have a couple of general remarks, so I am responding to >>> the cover >>> letter, not individual patches. >>> >>> 1) The licenses for Sarah devices differ than the rest - >>> shouldn't all >>> licenses be harmonized? >>> >>> Sarah, >>> do you mind if use the same license I use for my code? >>> >>> >>> 2) There is an architectural problem with peripherals. It is >>> possible >>> that they evolve over time, so, for example, USART could not >>> be the >>> same for older and newer CPUs (in principle, newer >>> peripheral is >>> expected to be o sort of "superset" of the older). How do >>> you solve >>> that problem? Right now, it may not looks serious to you, >>> but if you >>> don;t think about that right now, from the outset, soon the >>> code will >>> become so entangled, ti woudl be almost very difficult to >>> fix it. >>> Please think about that, how would you solve it, is there a >>> way to >>> pass the information on the currently emulated CPU to the >>> code >>> covering a peripheral, and provide a different behaviour? >>> >>> Hi Aleksandar, >>> >>> Please explain. >>> >>> >>> My concern is about peripherals inside the chip, together with the >>> core. >>> >>> If one models, let's say an external (in the sense, it is a separate >>> chip) ADC (analog-to-digital converter), one looks at specs, >>> implement what is resonable possible in QEMU, plug it in in one of >>> machines thst contains it, and that's it. That ADC remains the same, >>> of course, whatever the surrounding system is. >>> >>> In AVR case, I think we have a phenomenon likes of which we didn't >>> see before (at least I don't know about). Number of AVR >>> microcontrollers is very large, and both cores and peripherals >>> evolved. >>> >>> For cores, you handle differences with all these AVR_FEATURE macros, >>> and this seems to be working, no significant objection from my side, >>> and btw that was not an easy task to execute, all admiration from me. >>> >>> But what about peripherals inside the chip? A peripheral with the >>> same name and the same general area of functionality may be >>> differently specified for microcontrollers from 2010 and 2018. By >>> the difference I don't mean starting address, but the difference in >>> behavior. I don't have time right now to spell many examples, but I >>> read three different specs, and there are differences in USART >>> specifications. >>> >>> I am not clear what is your envisioned solution for these cases. >>> Would you such close, but not the same, flabors of a peripheral >>> treat as if they are two completely separate cases of a peripheral? >>> Or would you have a single peripheral that would somehow configure >>> itself depending on the core it is attached to? >>> >>> I hope I was clearer this time. >>> >>> Aleksandar >>> >>> >>> >>> >>> I don't see any problem from CPU's perspective. >>> as for the sample board is just a sample, I hope other people >>> will create real models or real hw. >>> there was no way I could provide a CPU alone, that's why there >>> is sample. >>> >> >> If I understand Aleksandar correctly, the naming is incorrect because too >> generic to AVR family, why Sarah only modeled the Atmel implementation. >> >> Renaming devices such hw/char/avr_usart.c -> hw/char/atmel_usart.c >> (similarly with the macros) would be enough Aleksandar? >> >> > > Some renaming could help, perhaps not quite like the one above, but my > point (which I find hard to believe I can't explain to you) is that > peripherals inside the chip evolved over time, as starkly opposed to > external peripherals that are set in stone... > -- Best Regards, Michael Rolnik
