On Thursday, November 28, 2019, dovgaluk <dovga...@ispras.ru> wrote: > Aleksandar Markovic писал 2019-11-28 13:20: > >> On Thursday, November 28, 2019, dovgaluk <dovga...@ispras.ru> wrote: >> >> Aleksandar Markovic писал 2019-11-28 12:28: >>> On Thursday, November 28, 2019, Philippe Mathieu-Daudé >>> <f4...@amsat.org> wrote: >>> >>> Add famous ATmega MCUs: >>> >>> - middle range: ATmega168 and ATmega328 >>> - high range: ATmega1280 and ATmega2560 >>> >>> Signed-off-by: Philippe Mathieu-Daudé <f4...@amsat.org> >>> --- >>> >>> Philippe, hi. >>> >>> Thank you for the impetus you give us all. >>> >>> However, is this the right direction? >>> >>> Let's analyse some bits and pieces. >>> >>> Starting from the commit message, the word "famous" is used, but I >>> really don't see enumerated CPUs/MCUs are any special in Atmel >>> lineup. >>> Other than we often used the doc describing them (cited several >>> times >>> in our discussions) as our reference, but that doesn't make them >>> "famous". Ofcourse, there other docs for other Atmel CPUs/MCUs, of >>> at >>> lest equivalent significance. For example, "tiny" ones are at least >>> as >>> famous as "mega" ones. >>> >>> Then, you introduce the term MCU, without proper discussion with >>> others on terminology. In parlance of QEMU, ATmega168 at al. are >>> CPUs >>> (we all know and assume that that are some peripherals in it). I am >>> not against using the term MCU, but let's first sync up on that. >>> >>> The added terminology trouble is that MCUs, as you defined them, >>> have >>> in array atmega_mcu[] a field called "cpu_type" - why is that field >>> not called "mcu_type"? *Very* confusing for any future reader. And >>> then, similar terminology conundrum continues with macro >>> AVR_CPU_TYPE_NAME(). >>> >> >> MCU is a system-on-chip which includes CPU core and peripheral >> devices. >> Separating this is better that including everything into the machine. >> >> E.g., different MCUs may have different IO addresses for USART. >> >> Pavel, >> >> Do you know how is this resolved for other platforms? >> >> How other platfirms organize and use terms "soc", "mcu", "cpu", >> "core", "cpu core"? And what is the relation between each of them and >> QEMU command line options "-cpu" and "-machine"? Is thar organization >> the same accross all platforms? >> > > Here is an ARM example: > SoCs: hw/arm/aspeed_soc.c include/hw/arm/aspeed_soc.h > Boards: hw/arm/aspeed.c > > (I am asking you as you most likely have much wider experience in the >> topic, sincr mine i limited to mips emulation) >> > > As far as I know, there are MIPS SoCs too. > Doesn't QEMU emulate any of them?
It does, but, admitedly, we could do a much better job in that area, and we are certainly not good as a reference platform in that area. Some features of MIPS SoCs are extremely difficult to implement in QEMU though (for example, so called hardware miltithreading). Thanks, Aleksandar > > All of the above is far less important than this question: What >>>> are we >>>> achieving with proposed CPU/MCU definitions? I certainly see the >>>> value >>>> of fitting the complex variety of AVR CPUs/MCUs into QEMU object >>>> model. No question about that. However, is this the right moment >>>> to do >>>> it? There are still some unresolved architectural problems with >>>> peripheral definitions, as I noted in yhe comment to Michael's >>>> last >>>> cover letter. This patch does not solve them. It just assumes >>>> everything is ready with peripherals, let's build CPUs/MCUs. The >>>> machines based on proposed CPUs/MCUs are not more real that >>>> machine >>>> based on Michael's "sample" machine. At least Michal says "this is >>>> not >>>> a real machine". If we used proposed CPUs/MCUs from this patch, >>>> the >>>> resulting machine is as "paper" machine as yhe "sample" machine. >>>> We >>>> would just live in a la-la lend of thinking: "wow, we model real >>>> hardware now". >>>> >>>> I would rather accept into QEMU a series admitting we are still >>>> far >>>> from modelling real machine or CPU/MCU, than a series that gives >>>> an >>>> illusion that we are modelling real machine or CPU/MCU. >>>> >>>> As far as utility of this patch for Michael's series, it looks to >>>> me >>>> they add more headake than help (not saying that the help is not >>>> present) to Michael. He would have anotter abstraction layer to >>>> think >>>> of, at the moment he desperately needs (in my opinion) to focus on >>>> providing the as solid as possible, and as complete as possinle >>>> foundations. This patch looks like building castles in the air. >>>> Again, >>>> I am not claiming that the patch is not helpful at all. >>>> >>>> In summary, I think that this patch is premature. >>>> >>> > > > Pavel Dovgalyuk > >
