[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v37 00/17] QEMU AVR 8 bit cores
From: |
Aleksandar Markovic |
Subject: |
Re: [PATCH v37 00/17] QEMU AVR 8 bit cores |
Date: |
Thu, 28 Nov 2019 14:41:25 +0100 |
On Thursday, November 28, 2019, Philippe Mathieu-Daudé <address@hidden> 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 <address@hidden <mailto:aleksandar.m.mail@gmail.com>> wrote:
On Thursday, November 28, 2019, Michael Rolnik <address@hidden
<mailto:address@hidden>> wrote:
On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic
<address@hidden
<mailto:aleksandar.m.mail@gmail.com>> wrote:
On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik
<address@hidden <mailto:address@hidden>> 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...
- [PATCH v37 17/17] target/avr: Update MAINTAINERS file, (continued)
- [PATCH v37 17/17] target/avr: Update MAINTAINERS file, Michael Rolnik, 2019/11/27
- [PATCH v37 16/17] target/avr: Add Avocado test, Michael Rolnik, 2019/11/27
- [PATCH v37 11/17] target/avr: Add limited support for USART and 16 bit timer peripherals, Michael Rolnik, 2019/11/27
- [PATCH v37 15/17] target/avr: Add boot serial test, Michael Rolnik, 2019/11/27
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Aleksandar Markovic, 2019/11/27
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Michael Rolnik, 2019/11/28
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Aleksandar Markovic, 2019/11/28
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Michael Rolnik, 2019/11/28
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Philippe Mathieu-Daudé, 2019/11/28
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores,
Aleksandar Markovic <=
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Michael Rolnik, 2019/11/28
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Philippe Mathieu-Daudé, 2019/11/28
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Aleksandar Markovic, 2019/11/28
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Aleksandar Markovic, 2019/11/28
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Aleksandar Markovic, 2019/11/28
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Alex Bennée, 2019/11/28
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Aleksandar Markovic, 2019/11/28
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Aleksandar Markovic, 2019/11/29
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Aleksandar Markovic, 2019/11/29
- Re: [PATCH v37 00/17] QEMU AVR 8 bit cores, Sarah Harris, 2019/11/29