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