Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik  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?

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?

> Following are examples of possible usages, assuming program.elf is compiled 
> for AVR cpu
> 1.  Continious non interrupted execution
> run `qemu-system-avr -kernel program.elf`
> 2.  Continious non interrupted execution with serial output into telnet window
> run `qemu-system-avr -kernel program.elf -serial tcp::5678,server,nowait 
> -nographic `
> run `telent localhost 5678`
> 3.  Continious non interrupted execution with serial output into stdout
> run `qemu-system-avr -kernel program.elf -serial stdio`
> 4.  Debugging wit GDB debugger
> run `qemu-system-avr -kernel program.elf -s -S`
> run `avr-gdb program.elf` and then within GDB shell `target remote :1234`
> 5.  Print out executed instructions
> run `qemu-system-avr -kernel program.elf -d in_asm`
>

Thank you so much for these examples!

Aleksandar


>
> the patches include the following
> 1. just a basic 8bit AVR CPU, without instruction decoding or translation
> 2. CPU features which allow define the following 8bit AVR cores
>  avr1
>  avr2 avr25
>  avr3 avr31 avr35
>  avr4
>  avr5 avr51
>  avr6
>  xmega2 xmega4 xmega5 xmega6 xmega7
> 3. a definition of sample machine with SRAM, FLASH and CPU which allows to 
> execute simple code
> 4. encoding for all AVR instructions
> 5. interrupt handling
> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
> 7. a decoder which given an opcode decides what istruction it is
> 8. translation of AVR instruction into TCG
> 9. all features together
>
> changes since v3
> 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of 0x00ff) 
> for faster address manipulaton
> 2. ffs changed to ctz32
> 3. duplicate code removed at avr_cpu_do_interrupt
> 4. using andc instead of not + and
> 5. fixing V flag calculation in varios instructions
> 6. freeing local variables in PUSH
> 7. tcg_const_local_i32 -> tcg_const_i32
> 8. using sextract32 instead of my implementation
> 9. fixing BLD instruction
> 10.xor(r) instead of 0xff - r at COM
> 11.fixing MULS/MULSU not to modify inputs' content
> 12.using SUB for NEG
> 13.fixing tcg_gen_qemu_ld/st call in XCH
>
> changes since v4
> 1. target is now defined as big endian in order to optimize push_ret/pop_ret
> 2. all style warnings are fixed
> 3. adding cpu_set/get_sreg functions
> 4. simplifying gen_goto_tb as there is no real paging
> 5. env->pc -> env->pc_w
> 6. making flag dump more compact
> 7. more spacing
> 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
> 9. removing avr_set_feature
> 10. SPL/SPH set bug fix
> 11. switching stb_phys to cpu_stb_data
> 12. cleaning up avr_decode
> 13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
> 14. saving CPU features (savevm)
>
> changes since v5
> 1. BLD bug fix
> 2. decoder generator is added
>
> chages since v6
> 1. using cpu_get_sreg/cpu_set_sreg in 
> avr_cpu_gdb_read_register/avr_cpu_gdb_write_register
> 2. configure the target as little endian because otherwise GDB does not work
> 3. fixing and testing gen_push_ret/gen_pop_ret
>
> changes since v7
> 1. folding back v6
> 2. logging at helper_outb and helper_inb are done for non supported yet 
> registers only
> 3. MAINTAINERS updated
>
> changes since v8
> 1. removing hw/avr from hw/Makefile.obj as it should not be built for all
> 2. making linux compilable
> 3. testing on
> a. Mac, Apple LLVM version 7.0.0
> b. Ubuntu 12.04, gcc 4.9.2
> c. Fedora 23, gcc 5.3.1
> 4. folding back some patches
> 5. translation bug fixes for ORI, CPI, XOR instructions
> 6. propper handling of cpu register writes though memory
>
> changes since v9
> 1. removing forward declarations of static functions
> 2. disabling debug prints
> 3. switching to case range instead of 

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Michael Rolnik]

On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik  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. 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.



>
> > Following are examples of possible usages, assuming program.elf is
> compiled for AVR cpu
> > 1.  Continious non interrupted execution
> > run `qemu-system-avr -kernel program.elf`
> > 2.  Continious non interrupted execution with serial output into telnet
> window
> > run `qemu-system-avr -kernel program.elf -serial
> tcp::5678,server,nowait -nographic `
> > run `telent localhost 5678`
> > 3.  Continious non interrupted execution with serial output into stdout
> > run `qemu-system-avr -kernel program.elf -serial stdio`
> > 4.  Debugging wit GDB debugger
> > run `qemu-system-avr -kernel program.elf -s -S`
> > run `avr-gdb program.elf` and then within GDB shell `target remote
> :1234`
> > 5.  Print out executed instructions
> > run `qemu-system-avr -kernel program.elf -d in_asm`
> >
>
> Thank you so much for these examples!
>
> Aleksandar
>
>
> >
> > the patches include the following
> > 1. just a basic 8bit AVR CPU, without instruction decoding or translation
> > 2. CPU features which allow define the following 8bit AVR cores
> >  avr1
> >  avr2 avr25
> >  avr3 avr31 avr35
> >  avr4
> >  avr5 avr51
> >  avr6
> >  xmega2 xmega4 xmega5 xmega6 xmega7
> > 3. a definition of sample machine with SRAM, FLASH and CPU which allows
> to execute simple code
> > 4. encoding for all AVR instructions
> > 5. interrupt handling
> > 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
> > 7. a decoder which given an opcode decides what istruction it is
> > 8. translation of AVR instruction into TCG
> > 9. all features together
> >
> > changes since v3
> > 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of
> 0x00ff) for faster address manipulaton
> > 2. ffs changed to ctz32
> > 3. duplicate code removed at avr_cpu_do_interrupt
> > 4. using andc instead of not + and
> > 5. fixing V flag calculation in varios instructions
> > 6. freeing local variables in PUSH
> > 7. tcg_const_local_i32 -> tcg_const_i32
> > 8. using sextract32 instead of my implementation
> > 9. fixing BLD instruction
> > 10.xor(r) instead of 0xff - r at COM
> > 11.fixing MULS/MULSU not to modify inputs' content
> > 12.using SUB for NEG
> > 13.fixing tcg_gen_qemu_ld/st call in XCH
> >
> > changes since v4
> > 1. target is now defined as big endian in order to optimize
> push_ret/pop_ret
> > 2. all style warnings are fixed
> > 3. adding cpu_set/get_sreg functions
> > 4. simplifying gen_goto_tb as there is no real paging
> > 5. env->pc -> env->pc_w
> > 6. making flag dump more compact
> > 7. more spacing
> > 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
> > 9. removing avr_set_feature
> > 10. SPL/SPH set bug fix
> > 11. switching stb_phys to cpu_stb_data
> > 12. cleaning up avr_decode
> > 13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
> > 14. saving CPU features (savevm)
> >
> > changes since v5
> > 1. BLD bug fix
> > 2. decoder generator is added
> >
> > chages since v6
> > 1. using cpu_get_sreg/cpu_set_sreg in
> avr_cpu_gdb_read_register/avr_cpu_gdb_write_register
> > 2. configure the target as little endian because otherwise GDB does not
> work
> > 3. fixing and testing gen_push_ret/gen_pop_ret
> >
> > changes since v7
> > 1. folding back v6
> > 2. logging at helper_outb 

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Michael Rolnik]

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> wrote:

>
>
> On Thursday, November 28, 2019, Michael Rolnik  wrote:
>
>>
>>
>> On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic <
>> aleksandar.m.m...@gmail.com> wrote:
>>
>>> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik 
>>> 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.
>>
>>
>>
>>>
>>> > Following are examples of possible usages, assuming program.elf is
>>> compiled for AVR cpu
>>> > 1.  Continious non interrupted execution
>>> > run `qemu-system-avr -kernel program.elf`
>>> > 2.  Continious non interrupted execution with serial output into
>>> telnet window
>>> > run `qemu-system-avr -kernel program.elf -serial
>>> tcp::5678,server,nowait -nographic `
>>> > run `telent localhost 5678`
>>> > 3.  Continious non interrupted execution with serial output into stdout
>>> > run `qemu-system-avr -kernel program.elf -serial stdio`
>>> > 4.  Debugging wit GDB debugger
>>> > run `qemu-system-avr -kernel program.elf -s -S`
>>> > run `avr-gdb program.elf` and then within GDB shell `target remote
>>> :1234`
>>> > 5.  Print out executed instructions
>>> > run `qemu-system-avr -kernel program.elf -d in_asm`
>>> >
>>>
>>> Thank you so much for these examples!
>>>
>>> Aleksandar
>>>
>>>
>>> >
>>> > the patches include the following
>>> > 1. just a basic 8bit AVR CPU, without instruction decoding or
>>> translation
>>> > 2. CPU features which allow define the following 8bit AVR cores
>>> >  avr1
>>> >   

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Philippe Mathieu-Daudé]

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 
mailto:aleksandar.m.m...@gmail.com>> wrote:




On Thursday, November 28, 2019, Michael Rolnik mailto:mrol...@gmail.com>> wrote:



On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic
mailto:aleksandar.m.m...@gmail.com>> wrote:

On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik
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?

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Thursday, November 28, 2019, 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?
>
>>
>>
I meant these peripherals are physically inside the chip together with the
core.

And USART in a micricontroler from 2010 is different than USART from one
from 2018.


> On Thu, Nov 28, 2019 at 3:22 PM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>>
>>
>> On Thursday, November 28, 2019, Michael Rolnik  wrote:
>>
>>>
>>>
>>> On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic <
>>> aleksandar.m.m...@gmail.com> wrote:
>>>
 On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik 
 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.
>>>
>>>
>>>

 > Following are examples of possible usages, assuming program.elf is
 compiled for AVR cpu
 > 1.  Continious non interrupted execution
 > run `qemu-system-avr -kernel program.elf`
 > 2.  Continious non interrupted execution with serial output into
 telnet window
 > run `qemu-system-avr -kernel program.elf -serial
 tcp::5678,server,nowait -nographic `
 > run `telent localhost 5678`
 > 3.  Continious non interrupted execution with serial output into
 stdout
 > run `qemu-system-avr -kernel program.elf -serial stdio`
 > 4.  Debugging wit GDB debugger
 > run `qemu-system-avr -kernel program.elf -s -S`
 > run `avr-gdb program.elf` and then within GDB shell `target
 remote :1234`
 > 5.  Print out executed instructions
 >

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Thursday, November 28, 2019, Michael Rolnik  wrote:

>
>
> On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik  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.
>
>
>
>>
>> > Following are examples of possible usages, assuming program.elf is
>> compiled for AVR cpu
>> > 1.  Continious non interrupted execution
>> > run `qemu-system-avr -kernel program.elf`
>> > 2.  Continious non interrupted execution with serial output into telnet
>> window
>> > run `qemu-system-avr -kernel program.elf -serial
>> tcp::5678,server,nowait -nographic `
>> > run `telent localhost 5678`
>> > 3.  Continious non interrupted execution with serial output into stdout
>> > run `qemu-system-avr -kernel program.elf -serial stdio`
>> > 4.  Debugging wit GDB debugger
>> > run `qemu-system-avr -kernel program.elf -s -S`
>> > run `avr-gdb program.elf` and then within GDB shell `target remote
>> :1234`
>> > 5.  Print out executed instructions
>> > run `qemu-system-avr -kernel program.elf -d in_asm`
>> >
>>
>> Thank you so much for these examples!
>>
>> Aleksandar
>>
>>
>> >
>> > the patches include the following
>> > 1. just a basic 8bit AVR CPU, without instruction decoding or
>> translation
>> > 2. CPU features which allow define the following 8bit AVR cores
>> >  avr1
>> >  avr2 avr25
>> >  avr3 avr31 avr35
>> >  avr4
>> >  avr5 avr51
>> >  avr6
>> >  xmega2 xmega4 xmega5 xmega6 xmega7
>> > 3. a definition of sample machine with SRAM, FLASH and CPU which allows
>> to execute simple code
>> > 4. encoding for all AVR instructions
>> > 5. interrupt handling
>> > 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
>> > 7. a decoder which given an opcode decides what istruction it is
>> > 8. tran

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Thursday, November 28, 2019, Philippe Mathieu-Daudé 
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 > wrote:
>>
>>
>>
>> On Thursday, November 28, 2019, Michael Rolnik > > wrote:
>>
>>
>>
>> On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic
>> > > wrote:
>>
>> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik
>> 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 Aleksand

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Michael Rolnik]

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é 
> 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 > wrote:
>>>
>>>
>>>
>>> On Thursday, November 28, 2019, Michael Rolnik >> > wrote:
>>>
>>>
>>>
>>> On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic
>>> >> > wrote:
>>>
>>> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik
>>> 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 correc

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Philippe Mathieu-Daudé]

On 11/28/19 2:46 PM, Michael Rolnik wrote:

I will rename them.


Please wait comments from Richard before a version respin.

On Thu, Nov 28, 2019 at 3:41 PM Aleksandar Markovic 
mailto:aleksandar.m.m...@gmail.com>> wrote:

[...]



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

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Wednesday, November 27, 2019, Michael Rolnik  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.
>
> Following are examples of possible usages, assuming program.elf is
> compiled for AVR cpu
> 1.  Continious non interrupted execution
> run `qemu-system-avr -kernel program.elf`
> 2.  Continious non interrupted execution with serial output into telnet
> window
> run `qemu-system-avr -kernel program.elf -serial
> tcp::5678,server,nowait -nographic `
> run `telent localhost 5678`
> 3.  Continious non interrupted execution with serial output into stdout
> run `qemu-system-avr -kernel program.elf -serial stdio`
> 4.  Debugging wit GDB debugger
> run `qemu-system-avr -kernel program.elf -s -S`
> run `avr-gdb program.elf` and then within GDB shell `target remote
> :1234`
> 5.  Print out executed instructions
> run `qemu-system-avr -kernel program.elf -d in_asm`
>
>
What is still missing is a documentstion patch. You need to browse a bit
QEMU online documentation  https://qemu.weilnetz.de/doc/qemu-doc.html  and
find the right place and content for AVR. Source for documentation is
within the tree, in one of .texi or .rst files.

Please also split Sarah's patch into three, not only for reviewing purpose,
but for the sake of future readers.

Yours,
Aleksandar


>
> the patches include the following
> 1. just a basic 8bit AVR CPU, without instruction decoding or translation
> 2. CPU features which allow define the following 8bit AVR cores
>  avr1
>  avr2 avr25
>  avr3 avr31 avr35
>  avr4
>  avr5 avr51
>  avr6
>  xmega2 xmega4 xmega5 xmega6 xmega7
> 3. a definition of sample machine with SRAM, FLASH and CPU which allows to
> execute simple code
> 4. encoding for all AVR instructions
> 5. interrupt handling
> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
> 7. a decoder which given an opcode decides what istruction it is
> 8. translation of AVR instruction into TCG
> 9. all features together
>
> changes since v3
> 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of 0x00ff)
> for faster address manipulaton
> 2. ffs changed to ctz32
> 3. duplicate code removed at avr_cpu_do_interrupt
> 4. using andc instead of not + and
> 5. fixing V flag calculation in varios instructions
> 6. freeing local variables in PUSH
> 7. tcg_const_local_i32 -> tcg_const_i32
> 8. using sextract32 instead of my implementation
> 9. fixing BLD instruction
> 10.xor(r) instead of 0xff - r at COM
> 11.fixing MULS/MULSU not to modify inputs' content
> 12.using SUB for NEG
> 13.fixing tcg_gen_qemu_ld/st call in XCH
>
> changes since v4
> 1. target is now defined as big endian in order to optimize
> push_ret/pop_ret
> 2. all style warnings are fixed
> 3. adding cpu_set/get_sreg functions
> 4. simplifying gen_goto_tb as there is no real paging
> 5. env->pc -> env->pc_w
> 6. making flag dump more compact
> 7. more spacing
> 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
> 9. removing avr_set_feature
> 10. SPL/SPH set bug fix
> 11. switching stb_phys to cpu_stb_data
> 12. cleaning up avr_decode
> 13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
> 14. saving CPU features (savevm)
>
> changes since v5
> 1. BLD bug fix
> 2. decoder generator is added
>
> chages since v6
> 1. using cpu_get_sreg/cpu_set_sreg in avr_cpu_gdb_read_register/avr_
> cpu_gdb_write_register
> 2. configure the target as little endian because otherwise GDB does not
> work
> 3. fixing and testing gen_push_ret/gen_pop_ret
>
> changes since v7
> 1. folding back v6
> 2. logging at helper_outb and helper_inb are done for non supported yet
> registers only
> 3. MAINTAINERS updated
>
> changes since v8
> 1. removing hw/avr from hw/Makefile.obj as it should not be built for all
> 2. making linux compilable
> 3. testing on
> a. Mac, Apple LLVM version 7.0.0
> b. Ubuntu 12.04, gcc 4.9.2
> c. Fedora 23, gcc 5.3.1
> 4. folding back some patches
> 5. translation bug fixes for ORI, CPI, XOR instructions
> 6. propper handling of cpu register writes though memory
>
> changes since v9
> 1. removing forward declarations of static functions
> 2. disabling debug prints
> 3. switching to case range instead of if else if ...
> 4. LD/ST IN/OUT accessing CPU maintainder registers are not routed to any
> device
> 5. commenst about sample board and sample IO device added
> 6. sample board description is more descriptive now
> 7. memory_region_allocate_system_memory is used to create RAM
> 8. now there are helper_fullrd & helper_fullwr when LD/ST try to access
> registers
>
> changes since v10
> 1. movig back fullwr & fullrd into the commit where outb and inb were
> introduced
> 2. changing tlb_fill function signature

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Thursday, November 28, 2019, Philippe Mathieu-Daudé 
wrote:

> On 11/28/19 2:46 PM, Michael Rolnik wrote:
>
>> I will rename them.
>>
>
>>
Renaming alone won't solve anything.


> Please wait comments from Richard before a version respin.
>
> On Thu, Nov 28, 2019 at 3:41 PM Aleksandar Markovic <
>> aleksandar.m.m...@gmail.com > wrote:
>>
> [...]
>
>>
>>
>> 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...
>>
>
>

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Alex Bennée]

Aleksandar Markovic  writes:

> On Thursday, November 28, 2019, 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?
>>
>>>
>>>
> I meant these peripherals are physically inside the chip together with the
> core.
>
> And USART in a micricontroler from 2010 is different than USART from one
> from 2018.

Won't these be different chip parts? Or at least revs of the part?

I think broadly the difference between SoC devices is handled by
handling versioning in the board models - the board being in this case a
CPU core + a bunch of SoC components + the actual board itself.

All the target/cpu stuff needs to deal with is actual architectural
revs (c.f. target/arm/cpu[64].c).

>
>
>> On Thu, Nov 28, 2019 at 3:22 PM Aleksandar Markovic <
>> aleksandar.m.m...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thursday, November 28, 2019, Michael Rolnik  wrote:
>>>


 On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic <
 aleksandar.m.m...@gmail.com> wrote:

> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik 
> 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.



>
> > Following are examples of possible usages, assuming program.elf is
> compiled for AVR cpu
> > 1.  Continious non interrupted execution
> > run `qemu-system-avr -kernel program.elf`
> > 2.  Continious non interrupted execution with serial output into
> telnet win

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Thursday, November 28, 2019, Alex Bennée  wrote:

>
> Aleksandar Markovic  writes:
>
> > On Thursday, November 28, 2019, 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?
> >>
> >>>
> >>>
> > I meant these peripherals are physically inside the chip together with
> the
> > core.
> >
> > And USART in a micricontroler from 2010 is different than USART from one
> > from 2018.
>
> Won't these be different chip parts? Or at least revs of the part?
>
> I think broadly the difference between SoC devices is handled by
> handling versioning in the board models - the board being in this case a
> CPU core + a bunch of SoC components + the actual board itself.
>
> All the target/cpu stuff needs to deal with is actual architectural
> revs (c.f. target/arm/cpu[64].c).
>
>
This sounds like a very good way of dealing with this.

I don't want to force Michael to implement some of such cases before
integration, but just to think about such cases - for future improvements
and developments.

Alex, I appreciate your advice, very nice of you!

Aleksandar




> >
> >
> >> On Thu, Nov 28, 2019 at 3:22 PM Aleksandar Markovic <
> >> aleksandar.m.m...@gmail.com> wrote:
> >>
> >>>
> >>>
> >>> On Thursday, November 28, 2019, Michael Rolnik 
> wrote:
> >>>
> 
> 
>  On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic <
>  aleksandar.m.m...@gmail.com> wrote:
> 
> > On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik 
> > 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.
> >>>
> >>> Aleks

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Thursday, November 28, 2019, Philippe Mathieu-Daudé 
wrote:

> On 11/28/19 2:46 PM, Michael Rolnik wrote:
>
>> I will rename them.
>>
>
> Please wait comments from Richard before a version respin.
>
>
Everything went well last 10 or so days, Michael and Sarah were responsive,
the code and series got slowly improved more and more, but there was this
disruption by your idea to "take over" the series with implementation of
"real boards", rather than leave Michael doing improvements by himself,
based on our feedback, like in a regular process of review... There are
some pending quite reasonable and simple review items from me, Michael
should continue working on them... But now he is told to wait... Shouldn't
it be some better way?


On Thu, Nov 28, 2019 at 3:41 PM Aleksandar Markovic <
>> aleksandar.m.m...@gmail.com > wrote:
>>
> [...]
>
>>
>>
>> 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...
>>
>
>

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Sarah Harris]

> Sarah,
> do you mind if use the same license I use for my code?
I'm happy to use the same license.

Kind regards,
Sarah Harris


On Thu, 28 Nov 2019 14:28:19 +0200
Michael Rolnik  wrote:

> On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
> 
> > On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik  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. 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.
> 
> 
> 
> >
> > > Following are examples of possible usages, assuming program.elf is
> > compiled for AVR cpu
> > > 1.  Continious non interrupted execution
> > > run `qemu-system-avr -kernel program.elf`
> > > 2.  Continious non interrupted execution with serial output into telnet
> > window
> > > run `qemu-system-avr -kernel program.elf -serial
> > tcp::5678,server,nowait -nographic `
> > > run `telent localhost 5678`
> > > 3.  Continious non interrupted execution with serial output into stdout
> > > run `qemu-system-avr -kernel program.elf -serial stdio`
> > > 4.  Debugging wit GDB debugger
> > > run `qemu-system-avr -kernel program.elf -s -S`
> > > run `avr-gdb program.elf` and then within GDB shell `target remote
> > :1234`
> > > 5.  Print out executed instructions
> > > run `qemu-system-avr -kernel program.elf -d in_asm`
> > >
> >
> > Thank you so much for these examples!
> >
> > Aleksandar
> >
> >
> > >
> > > the patches include the following
> > > 1. just a basic 8bit AVR CPU, without instruction decoding or translation
> > > 2. CPU features which allow define the following 8bit AVR cores
> > >  avr1
> > >  avr2 avr25
> > >  avr3 avr31 avr35
> > >  avr4
> > >  avr5 avr51
> > >  avr6
> > >  xmega2 xmega4 xmega5 xmega6 xmega7
> > > 3. a definition of sample machine with SRAM, FLASH and CPU which allows
> > to execute simple code
> > > 4. encoding for all AVR instructions
> > > 5. interrupt handling
> > > 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
> > > 7. a decoder which given an opcode decides what istruction it is
> > > 8. translation of AVR instruction into TCG
> > > 9. all features together
> > >
> > > changes since v3
> > > 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of
> > 0x00ff) for faster address manipulaton
> > > 2. ffs changed to ctz32
> > > 3. duplicate code removed at avr_cpu_do_interrupt
> > > 4. using andc instead of not + and
> > > 5. fixing V flag calculation in varios instructions
> > > 6. freeing local variables in PUSH
> > > 7. tcg_const_local_i32 -> tcg_const_i32
> > > 8. using sextract32 instead of my implementation
> > > 9. fixing BLD instruction
> > > 10.xor(r) instead of 0xff - r at COM
> > > 11.fixing MULS/MULSU not to modify inputs' content
> > > 12.using SUB for NEG
> > > 13.fixing tcg_gen_qemu_ld/st call in XCH
> > >
> > > changes since v4
> > > 1. target is now defined as big endian in order to optimize
> > push_ret/pop_ret
> > > 2. all style warnings are fixed
> > > 3. adding cpu_set/get_sreg functions
> > > 4. simplifying gen_goto_tb as there is no real paging
> > > 5. env->pc -> env->pc_w
> > > 6. making flag dump more compact
> > > 7. more spacing
> > > 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
> > > 9. removing avr_set_feature
> > > 10. SPL/SPH set bug fix
> > > 11. switching stb_phys to cpu_stb_data
> > > 12. cleaning up avr_decode
> > > 13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
> > > 14. sa

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Thursday, November 28, 2019, Alex Bennée  wrote:

>
> Aleksandar Markovic  writes:
>
> > On Thursday, November 28, 2019, 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?
> >>
> >>>
> >>>
> > I meant these peripherals are physically inside the chip together with
> the
> > core.
> >
> > And USART in a micricontroler from 2010 is different than USART from one
> > from 2018.
>
> Won't these be different chip parts? Or at least revs of the part?
>
> I think broadly the difference between SoC devices is handled by
> handling versioning in the board models - the board being in this case a
> CPU core + a bunch of SoC components + the actual board itself.
>
> All the target/cpu stuff needs to deal with is actual architectural
> revs (c.f. target/arm/cpu[64].c).
>
>
Michael, please take a look at this link:

https://web-engineering.info/node/28

"Part number" seems to be the thing you'll need to incorporate in the
overall AVR support in QEMU in order to get the correct emulation of
in-chip peripherals - as Alex actually hinted. (In my opinion, you don't
need it now, in the initial version, but by no means in near future.)

Have a great weekend!


>
> >
> >> On Thu, Nov 28, 2019 at 3:22 PM Aleksandar Markovic <
> >> aleksandar.m.m...@gmail.com> wrote:
> >>
> >>>
> >>>
> >>> On Thursday, November 28, 2019, Michael Rolnik 
> wrote:
> >>>
> 
> 
>  On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic <
>  aleksandar.m.m...@gmail.com> wrote:
> 
> > On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik 
> > 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 dependin

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Friday, November 29, 2019, Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

>
>
> On Thursday, November 28, 2019, Alex Bennée 
> wrote:
>
>>
>> Aleksandar Markovic  writes:
>>
>> > On Thursday, November 28, 2019, 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?
>> >>
>> >>>
>> >>>
>> > I meant these peripherals are physically inside the chip together with
>> the
>> > core.
>> >
>> > And USART in a micricontroler from 2010 is different than USART from one
>> > from 2018.
>>
>> Won't these be different chip parts? Or at least revs of the part?
>>
>> I think broadly the difference between SoC devices is handled by
>> handling versioning in the board models - the board being in this case a
>> CPU core + a bunch of SoC components + the actual board itself.
>>
>> All the target/cpu stuff needs to deal with is actual architectural
>> revs (c.f. target/arm/cpu[64].c).
>>
>>
> Michael, please take a look at this link:
>
> https://web-engineering.info/node/28
>
> "Part number" seems to be the thing you'll need to incorporate in the
> overall AVR support in QEMU in order to get the correct emulation of
> in-chip peripherals - as Alex actually hinted. (In my opinion, you don't
> need it now, in the initial version, but by no means in near future.)
>
>
Here is the list of "part numbers" for 212 (!! a mind-blowing number) of
AVR microcontrollers:

https://github.com/felias-fogg/RescueAVR/blob/master/all.list


> Have a great weekend!
>
>
> >
>> >
>> >> On Thu, Nov 28, 2019 at 3:22 PM Aleksandar Markovic <
>> >> aleksandar.m.m...@gmail.com> wrote:
>> >>
>> >>>
>> >>>
>> >>> On Thursday, November 28, 2019, Michael Rolnik 
>> wrote:
>> >>>
>> 
>> 
>>  On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic <
>>  aleksandar.m.m...@gmail.com> wrote:
>> 
>> > On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik 
>> > 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, 

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Wednesday, November 27, 2019, Michael Rolnik  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.
>
> Following are examples of possible usages, assuming program.elf is
> compiled for AVR cpu
> 1.  Continious non interrupted execution
> run `qemu-system-avr -kernel program.elf`
> 2.  Continious non interrupted execution with serial output into telnet
> window
> run `qemu-system-avr -kernel program.elf -serial
> tcp::5678,server,nowait -nographic `
> run `telent localhost 5678`
> 3.  Continious non interrupted execution with serial output into stdout
> run `qemu-system-avr -kernel program.elf -serial stdio`
> 4.  Debugging wit GDB debugger
> run `qemu-system-avr -kernel program.elf -s -S`
> run `avr-gdb program.elf` and then within GDB shell `target remote
> :1234`
> 5.  Print out executed instructions
> run `qemu-system-avr -kernel program.elf -d in_asm`
>
>
Hi, Michael.

Can you explain to me the mechanisms of recognition of what
core/microcontroller QEMU is supposed to emulate in the examples above?

Yours, Aleksandar



> the patches include the following
> 1. just a basic 8bit AVR CPU, without instruction decoding or translation
> 2. CPU features which allow define the following 8bit AVR cores
>  avr1
>  avr2 avr25
>  avr3 avr31 avr35
>  avr4
>  avr5 avr51
>  avr6
>  xmega2 xmega4 xmega5 xmega6 xmega7
> 3. a definition of sample machine with SRAM, FLASH and CPU which allows to
> execute simple code
> 4. encoding for all AVR instructions
> 5. interrupt handling
> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
> 7. a decoder which given an opcode decides what istruction it is
> 8. translation of AVR instruction into TCG
> 9. all features together
>
> changes since v3
> 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of 0x00ff)
> for faster address manipulaton
> 2. ffs changed to ctz32
> 3. duplicate code removed at avr_cpu_do_interrupt
> 4. using andc instead of not + and
> 5. fixing V flag calculation in varios instructions
> 6. freeing local variables in PUSH
> 7. tcg_const_local_i32 -> tcg_const_i32
> 8. using sextract32 instead of my implementation
> 9. fixing BLD instruction
> 10.xor(r) instead of 0xff - r at COM
> 11.fixing MULS/MULSU not to modify inputs' content
> 12.using SUB for NEG
> 13.fixing tcg_gen_qemu_ld/st call in XCH
>
> changes since v4
> 1. target is now defined as big endian in order to optimize
> push_ret/pop_ret
> 2. all style warnings are fixed
> 3. adding cpu_set/get_sreg functions
> 4. simplifying gen_goto_tb as there is no real paging
> 5. env->pc -> env->pc_w
> 6. making flag dump more compact
> 7. more spacing
> 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
> 9. removing avr_set_feature
> 10. SPL/SPH set bug fix
> 11. switching stb_phys to cpu_stb_data
> 12. cleaning up avr_decode
> 13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
> 14. saving CPU features (savevm)
>
> changes since v5
> 1. BLD bug fix
> 2. decoder generator is added
>
> chages since v6
> 1. using cpu_get_sreg/cpu_set_sreg in avr_cpu_gdb_read_register/avr_
> cpu_gdb_write_register
> 2. configure the target as little endian because otherwise GDB does not
> work
> 3. fixing and testing gen_push_ret/gen_pop_ret
>
> changes since v7
> 1. folding back v6
> 2. logging at helper_outb and helper_inb are done for non supported yet
> registers only
> 3. MAINTAINERS updated
>
> changes since v8
> 1. removing hw/avr from hw/Makefile.obj as it should not be built for all
> 2. making linux compilable
> 3. testing on
> a. Mac, Apple LLVM version 7.0.0
> b. Ubuntu 12.04, gcc 4.9.2
> c. Fedora 23, gcc 5.3.1
> 4. folding back some patches
> 5. translation bug fixes for ORI, CPI, XOR instructions
> 6. propper handling of cpu register writes though memory
>
> changes since v9
> 1. removing forward declarations of static functions
> 2. disabling debug prints
> 3. switching to case range instead of if else if ...
> 4. LD/ST IN/OUT accessing CPU maintainder registers are not routed to any
> device
> 5. commenst about sample board and sample IO device added
> 6. sample board description is more descriptive now
> 7. memory_region_allocate_system_memory is used to create RAM
> 8. now there are helper_fullrd & helper_fullwr when LD/ST try to access
> registers
>
> changes since v10
> 1. movig back fullwr & fullrd into the commit where outb and inb were
> introduced
> 2. changing tlb_fill function signature
> 3. adding empty line between functions
> 4. adding newline on the last line of the file
> 5. using tb->flags to generae full access ST/LD instructions
> 6. fixing SBRC bug
> 7. folding back 10th commit
> 8. whenever a new file is in

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Michael Rolnik]

There is *-cpu *option where you can specify what CPU you want, if this
option is not specified avr6 (avr6-avr-cpu) is chosen.

*./avr-softmmu/qemu-system-avr -cpu help*
avr1-avr-cpu
avr2-avr-cpu
avr25-avr-cpu
avr3-avr-cpu
avr31-avr-cpu
avr35-avr-cpu
avr4-avr-cpu
avr5-avr-cpu
avr51-avr-cpu
avr6-avr-cpu
xmega2-avr-cpu
xmega4-avr-cpu
xmega5-avr-cpu
xmega6-avr-cpu
xmega7-avr-cpu

Regards,
Michael Rolnik



On Sat, Nov 30, 2019 at 1:28 PM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

>
>
> On Wednesday, November 27, 2019, Michael Rolnik  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.
>>
>> Following are examples of possible usages, assuming program.elf is
>> compiled for AVR cpu
>> 1.  Continious non interrupted execution
>> run `qemu-system-avr -kernel program.elf`
>> 2.  Continious non interrupted execution with serial output into telnet
>> window
>> run `qemu-system-avr -kernel program.elf -serial
>> tcp::5678,server,nowait -nographic `
>> run `telent localhost 5678`
>> 3.  Continious non interrupted execution with serial output into stdout
>> run `qemu-system-avr -kernel program.elf -serial stdio`
>> 4.  Debugging wit GDB debugger
>> run `qemu-system-avr -kernel program.elf -s -S`
>> run `avr-gdb program.elf` and then within GDB shell `target remote
>> :1234`
>> 5.  Print out executed instructions
>> run `qemu-system-avr -kernel program.elf -d in_asm`
>>
>>
> Hi, Michael.
>
> Can you explain to me the mechanisms of recognition of what
> core/microcontroller QEMU is supposed to emulate in the examples above?
>
> Yours, Aleksandar
>
>
>
>> the patches include the following
>> 1. just a basic 8bit AVR CPU, without instruction decoding or translation
>> 2. CPU features which allow define the following 8bit AVR cores
>>  avr1
>>  avr2 avr25
>>  avr3 avr31 avr35
>>  avr4
>>  avr5 avr51
>>  avr6
>>  xmega2 xmega4 xmega5 xmega6 xmega7
>> 3. a definition of sample machine with SRAM, FLASH and CPU which allows
>> to execute simple code
>> 4. encoding for all AVR instructions
>> 5. interrupt handling
>> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
>> 7. a decoder which given an opcode decides what istruction it is
>> 8. translation of AVR instruction into TCG
>> 9. all features together
>>
>> changes since v3
>> 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of
>> 0x00ff) for faster address manipulaton
>> 2. ffs changed to ctz32
>> 3. duplicate code removed at avr_cpu_do_interrupt
>> 4. using andc instead of not + and
>> 5. fixing V flag calculation in varios instructions
>> 6. freeing local variables in PUSH
>> 7. tcg_const_local_i32 -> tcg_const_i32
>> 8. using sextract32 instead of my implementation
>> 9. fixing BLD instruction
>> 10.xor(r) instead of 0xff - r at COM
>> 11.fixing MULS/MULSU not to modify inputs' content
>> 12.using SUB for NEG
>> 13.fixing tcg_gen_qemu_ld/st call in XCH
>>
>> changes since v4
>> 1. target is now defined as big endian in order to optimize
>> push_ret/pop_ret
>> 2. all style warnings are fixed
>> 3. adding cpu_set/get_sreg functions
>> 4. simplifying gen_goto_tb as there is no real paging
>> 5. env->pc -> env->pc_w
>> 6. making flag dump more compact
>> 7. more spacing
>> 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
>> 9. removing avr_set_feature
>> 10. SPL/SPH set bug fix
>> 11. switching stb_phys to cpu_stb_data
>> 12. cleaning up avr_decode
>> 13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
>> 14. saving CPU features (savevm)
>>
>> changes since v5
>> 1. BLD bug fix
>> 2. decoder generator is added
>>
>> chages since v6
>> 1. using cpu_get_sreg/cpu_set_sreg in
>> avr_cpu_gdb_read_register/avr_cpu_gdb_write_register
>> 2. configure the target as little endian because otherwise GDB does not
>> work
>> 3. fixing and testing gen_push_ret/gen_pop_ret
>>
>> changes since v7
>> 1. folding back v6
>> 2. logging at helper_outb and helper_inb are done for non supported yet
>> registers only
>> 3. MAINTAINERS updated
>>
>> changes since v8
>> 1. removing hw/avr from hw/Makefile.obj as it should not be built for all
>> 2. making linux compilable
>> 3. testing on
>> a. Mac, Apple LLVM version 7.0.0
>> b. Ubuntu 12.04, gcc 4.9.2
>> c. Fedora 23, gcc 5.3.1
>> 4. folding back some patches
>> 5. translation bug fixes for ORI, CPI, XOR instructions
>> 6. propper handling of cpu register writes though memory
>>
>> changes since v9
>> 1. removing forward declarations of static functions
>> 2. disabling debug prints
>> 3. switching to case range instead of if else if ...
>> 4. LD/ST IN/OUT accessing CPU maintainder registers are not routed to any
>> device
>> 5. commenst ab

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

>
> Renaming devices such hw/char/avr_usart.c -> hw/char/atmel_usart.c
> (similarly with the macros) would be enough Aleksandar?
>
> On Thursday, November 28, 2019, Michael Rolnik  wrote:

> I will rename them.
>

AVR is the name of a microcontroller lineup, and Atmel is the name of the
company that started producing them. Atmel was recently acquired by
Microchip, so thw word Atmel now does not even exist in new specs.

Taking this into account, I don't think renaming

hw/char/avr_usart.c -> hw/char/atmel_usart.c

is not appropriate. Renaming macros, too. The current names are fine, for
now.

A separate but related naming question will show up later in future, when
we, let's say, want to implement two different version of a peripheral
(let's say USART), one as specified for older microcontrollers, and one for
newer.

But, OK, let's leave that for future.

Regards,
Aleksandar



> 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é 
>> 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 >
 wrote:



 On Thursday, November 28, 2019, Michael Rolnik >>> > wrote:



 On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic
 >>> > wrote:

 On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik
 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

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Sunday, December 1, 2019, Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

> Renaming devices such hw/char/avr_usart.c -> hw/char/atmel_usart.c
>> (similarly with the macros) would be enough Aleksandar?
>>
>> On Thursday, November 28, 2019, Michael Rolnik  wrote:
>
>> I will rename them.
>>
>
> AVR is the name of a microcontroller lineup, and Atmel is the name of the
> company that started producing them. Atmel was recently acquired by
> Microchip, so thw word Atmel now does not even exist in new specs.
>
> Taking this into account, I don't think renaming
>
> hw/char/avr_usart.c -> hw/char/atmel_usart.c
>
> is not appropriate.
>
>
I meant to say the renaming is not appropriate. Sorry for confusion.


>
>
>  Renaming macros, too. The current names are fine, for now.
>
> A separate but related naming question will show up later in future, when
> we, let's say, want to implement two different version of a peripheral
> (let's say USART), one as specified for older microcontrollers, and one for
> newer.
>
> But, OK, let's leave that for future.
>
> Regards,
> Aleksandar
>
>
>
>> 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 >
> wrote:
>
>
>
> On Thursday, November 28, 2019, Michael Rolnik  > wrote:
>
>
>
> On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic
>  > wrote:
>
> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik
> 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 signif

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Saturday, November 30, 2019, Michael Rolnik  wrote:

> There is *-cpu *option where you can specify what CPU you want, if this
> option is not specified avr6 (avr6-avr-cpu) is chosen.
>
> *./avr-softmmu/qemu-system-avr -cpu help*
> avr1-avr-cpu
> avr2-avr-cpu
> avr25-avr-cpu
> avr3-avr-cpu
> avr31-avr-cpu
> avr35-avr-cpu
> avr4-avr-cpu
> avr5-avr-cpu
> avr51-avr-cpu
> avr6-avr-cpu
> xmega2-avr-cpu
> xmega4-avr-cpu
> xmega5-avr-cpu
> xmega6-avr-cpu
> xmega7-avr-cpu
>
>
What happens if you specify a core via -cpu, and supply elf file compiled
for another core?

Best regards,
Akeksandar




> Regards,
> Michael Rolnik
>
>
>
> On Sat, Nov 30, 2019 at 1:28 PM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>>
>>
>> On Wednesday, November 27, 2019, Michael Rolnik 
>> 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.
>>>
>>> Following are examples of possible usages, assuming program.elf is
>>> compiled for AVR cpu
>>> 1.  Continious non interrupted execution
>>> run `qemu-system-avr -kernel program.elf`
>>> 2.  Continious non interrupted execution with serial output into telnet
>>> window
>>> run `qemu-system-avr -kernel program.elf -serial
>>> tcp::5678,server,nowait -nographic `
>>> run `telent localhost 5678`
>>> 3.  Continious non interrupted execution with serial output into stdout
>>> run `qemu-system-avr -kernel program.elf -serial stdio`
>>> 4.  Debugging wit GDB debugger
>>> run `qemu-system-avr -kernel program.elf -s -S`
>>> run `avr-gdb program.elf` and then within GDB shell `target remote
>>> :1234`
>>> 5.  Print out executed instructions
>>> run `qemu-system-avr -kernel program.elf -d in_asm`
>>>
>>>
>> Hi, Michael.
>>
>> Can you explain to me the mechanisms of recognition of what
>> core/microcontroller QEMU is supposed to emulate in the examples above?
>>
>> Yours, Aleksandar
>>
>>
>>
>>> the patches include the following
>>> 1. just a basic 8bit AVR CPU, without instruction decoding or translation
>>> 2. CPU features which allow define the following 8bit AVR cores
>>>  avr1
>>>  avr2 avr25
>>>  avr3 avr31 avr35
>>>  avr4
>>>  avr5 avr51
>>>  avr6
>>>  xmega2 xmega4 xmega5 xmega6 xmega7
>>> 3. a definition of sample machine with SRAM, FLASH and CPU which allows
>>> to execute simple code
>>> 4. encoding for all AVR instructions
>>> 5. interrupt handling
>>> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
>>> 7. a decoder which given an opcode decides what istruction it is
>>> 8. translation of AVR instruction into TCG
>>> 9. all features together
>>>
>>> changes since v3
>>> 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of
>>> 0x00ff) for faster address manipulaton
>>> 2. ffs changed to ctz32
>>> 3. duplicate code removed at avr_cpu_do_interrupt
>>> 4. using andc instead of not + and
>>> 5. fixing V flag calculation in varios instructions
>>> 6. freeing local variables in PUSH
>>> 7. tcg_const_local_i32 -> tcg_const_i32
>>> 8. using sextract32 instead of my implementation
>>> 9. fixing BLD instruction
>>> 10.xor(r) instead of 0xff - r at COM
>>> 11.fixing MULS/MULSU not to modify inputs' content
>>> 12.using SUB for NEG
>>> 13.fixing tcg_gen_qemu_ld/st call in XCH
>>>
>>> changes since v4
>>> 1. target is now defined as big endian in order to optimize
>>> push_ret/pop_ret
>>> 2. all style warnings are fixed
>>> 3. adding cpu_set/get_sreg functions
>>> 4. simplifying gen_goto_tb as there is no real paging
>>> 5. env->pc -> env->pc_w
>>> 6. making flag dump more compact
>>> 7. more spacing
>>> 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
>>> 9. removing avr_set_feature
>>> 10. SPL/SPH set bug fix
>>> 11. switching stb_phys to cpu_stb_data
>>> 12. cleaning up avr_decode
>>> 13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
>>> 14. saving CPU features (savevm)
>>>
>>> changes since v5
>>> 1. BLD bug fix
>>> 2. decoder generator is added
>>>
>>> chages since v6
>>> 1. using cpu_get_sreg/cpu_set_sreg in avr_cpu_gdb_read_register/avr_
>>> cpu_gdb_write_register
>>> 2. configure the target as little endian because otherwise GDB does not
>>> work
>>> 3. fixing and testing gen_push_ret/gen_pop_ret
>>>
>>> changes since v7
>>> 1. folding back v6
>>> 2. logging at helper_outb and helper_inb are done for non supported yet
>>> registers only
>>> 3. MAINTAINERS updated
>>>
>>> changes since v8
>>> 1. removing hw/avr from hw/Makefile.obj as it should not be built for all
>>> 2. making linux compilable
>>> 3. testing on
>>> a. Mac, Apple LLVM version 7.0.0
>>> b. Ubuntu 12.04, gcc 4.9.2
>>> c. Fedora 23, gcc 5.3.1
>>> 4. folding back some patches
>>> 5. translation bug fixes for ORI

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Monday, December 2, 2019, Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

>
>
> On Saturday, November 30, 2019, Michael Rolnik  wrote:
>
>> There is *-cpu *option where you can specify what CPU you want, if this
>> option is not specified avr6 (avr6-avr-cpu) is chosen.
>>
>> *./avr-softmmu/qemu-system-avr -cpu help*
>> avr1-avr-cpu
>> avr2-avr-cpu
>> avr25-avr-cpu
>> avr3-avr-cpu
>> avr31-avr-cpu
>> avr35-avr-cpu
>> avr4-avr-cpu
>> avr5-avr-cpu
>> avr51-avr-cpu
>> avr6-avr-cpu
>> xmega2-avr-cpu
>> xmega4-avr-cpu
>> xmega5-avr-cpu
>> xmega6-avr-cpu
>> xmega7-avr-cpu
>>
>>
> What happens if you specify a core via -cpu, and supply elf file compiled
> for another core?
>
>
It looks there is some related info written in ELF header. This is from a
binutils header:

(so it looks you could detect the core from elf file - do you do that
detection right now?)

#define E_AVR_MACH_AVR1 1
#define E_AVR_MACH_AVR2 2
#define E_AVR_MACH_AVR25   25
#define E_AVR_MACH_AVR3 3
#define E_AVR_MACH_AVR31   31
#define E_AVR_MACH_AVR35   35
#define E_AVR_MACH_AVR4 4
#define E_AVR_MACH_AVR5 5
#define E_AVR_MACH_AVR51   51
#define E_AVR_MACH_AVR6 6
#define E_AVR_MACH_AVRTINY 100
#define E_AVR_MACH_XMEGA1  101
#define E_AVR_MACH_XMEGA2  102
#define E_AVR_MACH_XMEGA3  103
#define E_AVR_MACH_XMEGA4  104
#define E_AVR_MACH_XMEGA5  105
#define E_AVR_MACH_XMEGA6  106
#define E_AVR_MACH_XMEGA7  107



Best regards,
> Akeksandar
>
>
>
>
>> Regards,
>> Michael Rolnik
>>
>>
>>
>> On Sat, Nov 30, 2019 at 1:28 PM Aleksandar Markovic <
>> aleksandar.m.m...@gmail.com> wrote:
>>
>>>
>>>
>>> On Wednesday, November 27, 2019, Michael Rolnik 
>>> 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.

 Following are examples of possible usages, assuming program.elf is
 compiled for AVR cpu
 1.  Continious non interrupted execution
 run `qemu-system-avr -kernel program.elf`
 2.  Continious non interrupted execution with serial output into telnet
 window
 run `qemu-system-avr -kernel program.elf -serial
 tcp::5678,server,nowait -nographic `
 run `telent localhost 5678`
 3.  Continious non interrupted execution with serial output into stdout
 run `qemu-system-avr -kernel program.elf -serial stdio`
 4.  Debugging wit GDB debugger
 run `qemu-system-avr -kernel program.elf -s -S`
 run `avr-gdb program.elf` and then within GDB shell `target remote
 :1234`
 5.  Print out executed instructions
 run `qemu-system-avr -kernel program.elf -d in_asm`


>>> Hi, Michael.
>>>
>>> Can you explain to me the mechanisms of recognition of what
>>> core/microcontroller QEMU is supposed to emulate in the examples above?
>>>
>>> Yours, Aleksandar
>>>
>>>
>>>
 the patches include the following
 1. just a basic 8bit AVR CPU, without instruction decoding or
 translation
 2. CPU features which allow define the following 8bit AVR cores
  avr1
  avr2 avr25
  avr3 avr31 avr35
  avr4
  avr5 avr51
  avr6
  xmega2 xmega4 xmega5 xmega6 xmega7
 3. a definition of sample machine with SRAM, FLASH and CPU which allows
 to execute simple code
 4. encoding for all AVR instructions
 5. interrupt handling
 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
 7. a decoder which given an opcode decides what istruction it is
 8. translation of AVR instruction into TCG
 9. all features together

 changes since v3
 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of
 0x00ff) for faster address manipulaton
 2. ffs changed to ctz32
 3. duplicate code removed at avr_cpu_do_interrupt
 4. using andc instead of not + and
 5. fixing V flag calculation in varios instructions
 6. freeing local variables in PUSH
 7. tcg_const_local_i32 -> tcg_const_i32
 8. using sextract32 instead of my implementation
 9. fixing BLD instruction
 10.xor(r) instead of 0xff - r at COM
 11.fixing MULS/MULSU not to modify inputs' content
 12.using SUB for NEG
 13.fixing tcg_gen_qemu_ld/st call in XCH

 changes since v4
 1. target is now defined as big endian in order to optimize
 push_ret/pop_ret
 2. all style warnings are fixed
 3. adding cpu_set/get_sreg functions
 4. simplifying gen_goto_tb as there is no real paging
 5. env->pc -> env->pc_w
 6. making flag dump more compact
 7. more spacing
 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
 9. removing avr_set_feature
 10. SPL/SPH set bug fix
 11. switching stb_phys to cpu_stb_data

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Michael Rolnik]

No, I don't.
but I also can load and execute a binary file which does not have this
information.

On Mon, Dec 2, 2019 at 11:59 AM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

>
>
> On Monday, December 2, 2019, Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>>
>>
>> On Saturday, November 30, 2019, Michael Rolnik  wrote:
>>
>>> There is *-cpu *option where you can specify what CPU you want, if this
>>> option is not specified avr6 (avr6-avr-cpu) is chosen.
>>>
>>> *./avr-softmmu/qemu-system-avr -cpu help*
>>> avr1-avr-cpu
>>> avr2-avr-cpu
>>> avr25-avr-cpu
>>> avr3-avr-cpu
>>> avr31-avr-cpu
>>> avr35-avr-cpu
>>> avr4-avr-cpu
>>> avr5-avr-cpu
>>> avr51-avr-cpu
>>> avr6-avr-cpu
>>> xmega2-avr-cpu
>>> xmega4-avr-cpu
>>> xmega5-avr-cpu
>>> xmega6-avr-cpu
>>> xmega7-avr-cpu
>>>
>>>
>> What happens if you specify a core via -cpu, and supply elf file compiled
>> for another core?
>>
>>
> It looks there is some related info written in ELF header. This is from a
> binutils header:
>
> (so it looks you could detect the core from elf file - do you do that
> detection right now?)
>
> #define E_AVR_MACH_AVR1 1
> #define E_AVR_MACH_AVR2 2
> #define E_AVR_MACH_AVR25   25
> #define E_AVR_MACH_AVR3 3
> #define E_AVR_MACH_AVR31   31
> #define E_AVR_MACH_AVR35   35
> #define E_AVR_MACH_AVR4 4
> #define E_AVR_MACH_AVR5 5
> #define E_AVR_MACH_AVR51   51
> #define E_AVR_MACH_AVR6 6
> #define E_AVR_MACH_AVRTINY 100
> #define E_AVR_MACH_XMEGA1  101
> #define E_AVR_MACH_XMEGA2  102
> #define E_AVR_MACH_XMEGA3  103
> #define E_AVR_MACH_XMEGA4  104
> #define E_AVR_MACH_XMEGA5  105
> #define E_AVR_MACH_XMEGA6  106
> #define E_AVR_MACH_XMEGA7  107
>
>
>
> Best regards,
>> Akeksandar
>>
>>
>>
>>
>>> Regards,
>>> Michael Rolnik
>>>
>>>
>>>
>>> On Sat, Nov 30, 2019 at 1:28 PM Aleksandar Markovic <
>>> aleksandar.m.m...@gmail.com> wrote:
>>>


 On Wednesday, November 27, 2019, Michael Rolnik 
 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.
>
> Following are examples of possible usages, assuming program.elf is
> compiled for AVR cpu
> 1.  Continious non interrupted execution
> run `qemu-system-avr -kernel program.elf`
> 2.  Continious non interrupted execution with serial output into
> telnet window
> run `qemu-system-avr -kernel program.elf -serial
> tcp::5678,server,nowait -nographic `
> run `telent localhost 5678`
> 3.  Continious non interrupted execution with serial output into stdout
> run `qemu-system-avr -kernel program.elf -serial stdio`
> 4.  Debugging wit GDB debugger
> run `qemu-system-avr -kernel program.elf -s -S`
> run `avr-gdb program.elf` and then within GDB shell `target remote
> :1234`
> 5.  Print out executed instructions
> run `qemu-system-avr -kernel program.elf -d in_asm`
>
>
 Hi, Michael.

 Can you explain to me the mechanisms of recognition of what
 core/microcontroller QEMU is supposed to emulate in the examples above?

 Yours, Aleksandar



> the patches include the following
> 1. just a basic 8bit AVR CPU, without instruction decoding or
> translation
> 2. CPU features which allow define the following 8bit AVR cores
>  avr1
>  avr2 avr25
>  avr3 avr31 avr35
>  avr4
>  avr5 avr51
>  avr6
>  xmega2 xmega4 xmega5 xmega6 xmega7
> 3. a definition of sample machine with SRAM, FLASH and CPU which
> allows to execute simple code
> 4. encoding for all AVR instructions
> 5. interrupt handling
> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
> 7. a decoder which given an opcode decides what istruction it is
> 8. translation of AVR instruction into TCG
> 9. all features together
>
> changes since v3
> 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of
> 0x00ff) for faster address manipulaton
> 2. ffs changed to ctz32
> 3. duplicate code removed at avr_cpu_do_interrupt
> 4. using andc instead of not + and
> 5. fixing V flag calculation in varios instructions
> 6. freeing local variables in PUSH
> 7. tcg_const_local_i32 -> tcg_const_i32
> 8. using sextract32 instead of my implementation
> 9. fixing BLD instruction
> 10.xor(r) instead of 0xff - r at COM
> 11.fixing MULS/MULSU not to modify inputs' content
> 12.using SUB for NEG
> 13.fixing tcg_gen_qemu_ld/st call in XCH
>
> changes since v4
> 1. target is now defined as big endian in order to optimize
> push_ret/pop_ret
> 2. all s

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Monday, December 2, 2019, Michael Rolnik  wrote:

> No, I don't.
> but I also can load and execute a binary file which does not have this
> information.
>
>>
>>
OK. Let's think about that for a while. I currently think you have here an
opportunity to add a really clean interface from the outset of AVR support
in QEMU (that even some established platforms don't have in full), which
is, trust me, very important for future. And it not that difficult to
implement at all. But let's both think for a while.

Best regards,
Aleksandar



> On Mon, Dec 2, 2019 at 11:59 AM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>>
>>
>> On Monday, December 2, 2019, Aleksandar Markovic <
>> aleksandar.m.m...@gmail.com> wrote:
>>
>>>
>>>
>>> On Saturday, November 30, 2019, Michael Rolnik 
>>> wrote:
>>>
 There is *-cpu *option where you can specify what CPU you want, if
 this option is not specified avr6 (avr6-avr-cpu) is chosen.

 *./avr-softmmu/qemu-system-avr -cpu help*
 avr1-avr-cpu
 avr2-avr-cpu
 avr25-avr-cpu
 avr3-avr-cpu
 avr31-avr-cpu
 avr35-avr-cpu
 avr4-avr-cpu
 avr5-avr-cpu
 avr51-avr-cpu
 avr6-avr-cpu
 xmega2-avr-cpu
 xmega4-avr-cpu
 xmega5-avr-cpu
 xmega6-avr-cpu
 xmega7-avr-cpu


>>> What happens if you specify a core via -cpu, and supply elf file
>>> compiled for another core?
>>>
>>>
>> It looks there is some related info written in ELF header. This is from a
>> binutils header:
>>
>> (so it looks you could detect the core from elf file - do you do that
>> detection right now?)
>>
>> #define E_AVR_MACH_AVR1 1
>> #define E_AVR_MACH_AVR2 2
>> #define E_AVR_MACH_AVR25   25
>> #define E_AVR_MACH_AVR3 3
>> #define E_AVR_MACH_AVR31   31
>> #define E_AVR_MACH_AVR35   35
>> #define E_AVR_MACH_AVR4 4
>> #define E_AVR_MACH_AVR5 5
>> #define E_AVR_MACH_AVR51   51
>> #define E_AVR_MACH_AVR6 6
>> #define E_AVR_MACH_AVRTINY 100
>> #define E_AVR_MACH_XMEGA1  101
>> #define E_AVR_MACH_XMEGA2  102
>> #define E_AVR_MACH_XMEGA3  103
>> #define E_AVR_MACH_XMEGA4  104
>> #define E_AVR_MACH_XMEGA5  105
>> #define E_AVR_MACH_XMEGA6  106
>> #define E_AVR_MACH_XMEGA7  107
>>
>>
>>
>> Best regards,
>>> Akeksandar
>>>
>>>
>>>
>>>
 Regards,
 Michael Rolnik



 On Sat, Nov 30, 2019 at 1:28 PM Aleksandar Markovic <
 aleksandar.m.m...@gmail.com> wrote:

>
>
> On Wednesday, November 27, 2019, Michael Rolnik 
> 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.
>>
>> Following are examples of possible usages, assuming program.elf is
>> compiled for AVR cpu
>> 1.  Continious non interrupted execution
>> run `qemu-system-avr -kernel program.elf`
>> 2.  Continious non interrupted execution with serial output into
>> telnet window
>> run `qemu-system-avr -kernel program.elf -serial
>> tcp::5678,server,nowait -nographic `
>> run `telent localhost 5678`
>> 3.  Continious non interrupted execution with serial output into
>> stdout
>> run `qemu-system-avr -kernel program.elf -serial stdio`
>> 4.  Debugging wit GDB debugger
>> run `qemu-system-avr -kernel program.elf -s -S`
>> run `avr-gdb program.elf` and then within GDB shell `target
>> remote :1234`
>> 5.  Print out executed instructions
>> run `qemu-system-avr -kernel program.elf -d in_asm`
>>
>>
> Hi, Michael.
>
> Can you explain to me the mechanisms of recognition of what
> core/microcontroller QEMU is supposed to emulate in the examples above?
>
> Yours, Aleksandar
>
>
>
>> the patches include the following
>> 1. just a basic 8bit AVR CPU, without instruction decoding or
>> translation
>> 2. CPU features which allow define the following 8bit AVR cores
>>  avr1
>>  avr2 avr25
>>  avr3 avr31 avr35
>>  avr4
>>  avr5 avr51
>>  avr6
>>  xmega2 xmega4 xmega5 xmega6 xmega7
>> 3. a definition of sample machine with SRAM, FLASH and CPU which
>> allows to execute simple code
>> 4. encoding for all AVR instructions
>> 5. interrupt handling
>> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
>> 7. a decoder which given an opcode decides what istruction it is
>> 8. translation of AVR instruction into TCG
>> 9. all features together
>>
>> changes since v3
>> 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of
>> 0x00ff) for faster address manipulaton
>> 2. ffs changed to ctz32
>> 3. duplicate code removed at avr

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Michael Rolnik]

how can I get this elf flags from within QEMU?

On Mon, Dec 2, 2019 at 4:01 PM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

>
>
> On Monday, December 2, 2019, Michael Rolnik  wrote:
>
>> No, I don't.
>> but I also can load and execute a binary file which does not have this
>> information.
>>
>>>
>>>
> OK. Let's think about that for a while. I currently think you have here an
> opportunity to add a really clean interface from the outset of AVR support
> in QEMU (that even some established platforms don't have in full), which
> is, trust me, very important for future. And it not that difficult to
> implement at all. But let's both think for a while.
>
> Best regards,
> Aleksandar
>
>
>
>> On Mon, Dec 2, 2019 at 11:59 AM Aleksandar Markovic <
>> aleksandar.m.m...@gmail.com> wrote:
>>
>>>
>>>
>>> On Monday, December 2, 2019, Aleksandar Markovic <
>>> aleksandar.m.m...@gmail.com> wrote:
>>>


 On Saturday, November 30, 2019, Michael Rolnik 
 wrote:

> There is *-cpu *option where you can specify what CPU you want, if
> this option is not specified avr6 (avr6-avr-cpu) is chosen.
>
> *./avr-softmmu/qemu-system-avr -cpu help*
> avr1-avr-cpu
> avr2-avr-cpu
> avr25-avr-cpu
> avr3-avr-cpu
> avr31-avr-cpu
> avr35-avr-cpu
> avr4-avr-cpu
> avr5-avr-cpu
> avr51-avr-cpu
> avr6-avr-cpu
> xmega2-avr-cpu
> xmega4-avr-cpu
> xmega5-avr-cpu
> xmega6-avr-cpu
> xmega7-avr-cpu
>
>
 What happens if you specify a core via -cpu, and supply elf file
 compiled for another core?


>>> It looks there is some related info written in ELF header. This is from
>>> a binutils header:
>>>
>>> (so it looks you could detect the core from elf file - do you do that
>>> detection right now?)
>>>
>>> #define E_AVR_MACH_AVR1 1
>>> #define E_AVR_MACH_AVR2 2
>>> #define E_AVR_MACH_AVR25   25
>>> #define E_AVR_MACH_AVR3 3
>>> #define E_AVR_MACH_AVR31   31
>>> #define E_AVR_MACH_AVR35   35
>>> #define E_AVR_MACH_AVR4 4
>>> #define E_AVR_MACH_AVR5 5
>>> #define E_AVR_MACH_AVR51   51
>>> #define E_AVR_MACH_AVR6 6
>>> #define E_AVR_MACH_AVRTINY 100
>>> #define E_AVR_MACH_XMEGA1  101
>>> #define E_AVR_MACH_XMEGA2  102
>>> #define E_AVR_MACH_XMEGA3  103
>>> #define E_AVR_MACH_XMEGA4  104
>>> #define E_AVR_MACH_XMEGA5  105
>>> #define E_AVR_MACH_XMEGA6  106
>>> #define E_AVR_MACH_XMEGA7  107
>>>
>>>
>>>
>>> Best regards,
 Akeksandar




> Regards,
> Michael Rolnik
>
>
>
> On Sat, Nov 30, 2019 at 1:28 PM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>>
>>
>> On Wednesday, November 27, 2019, Michael Rolnik 
>> 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.
>>>
>>> Following are examples of possible usages, assuming program.elf is
>>> compiled for AVR cpu
>>> 1.  Continious non interrupted execution
>>> run `qemu-system-avr -kernel program.elf`
>>> 2.  Continious non interrupted execution with serial output into
>>> telnet window
>>> run `qemu-system-avr -kernel program.elf -serial
>>> tcp::5678,server,nowait -nographic `
>>> run `telent localhost 5678`
>>> 3.  Continious non interrupted execution with serial output into
>>> stdout
>>> run `qemu-system-avr -kernel program.elf -serial stdio`
>>> 4.  Debugging wit GDB debugger
>>> run `qemu-system-avr -kernel program.elf -s -S`
>>> run `avr-gdb program.elf` and then within GDB shell `target
>>> remote :1234`
>>> 5.  Print out executed instructions
>>> run `qemu-system-avr -kernel program.elf -d in_asm`
>>>
>>>
>> Hi, Michael.
>>
>> Can you explain to me the mechanisms of recognition of what
>> core/microcontroller QEMU is supposed to emulate in the examples above?
>>
>> Yours, Aleksandar
>>
>>
>>
>>> the patches include the following
>>> 1. just a basic 8bit AVR CPU, without instruction decoding or
>>> translation
>>> 2. CPU features which allow define the following 8bit AVR cores
>>>  avr1
>>>  avr2 avr25
>>>  avr3 avr31 avr35
>>>  avr4
>>>  avr5 avr51
>>>  avr6
>>>  xmega2 xmega4 xmega5 xmega6 xmega7
>>> 3. a definition of sample machine with SRAM, FLASH and CPU which
>>> allows to execute simple code
>>> 4. encoding for all AVR instructions
>>> 5. interrupt handling
>>> 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
>>> 7. a decoder which given an opcode decides what istruction it

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Monday, December 2, 2019, Michael Rolnik  wrote:

> how can I get this elf flags from within QEMU?
>
>>
>>
In one of files from your "machine" patch, you have this snippet:

+bytes_loaded = load_elf(
+filename, NULL, NULL, NULL, NULL, NULL, NULL, 0, EM_NONE, 0,
0);

With this line you a kind of "blindly" load whatever you find in the file
"filename". I think you need to modify load_elf() to fetch the information
on what core the elf in question is compiled for. Additionally, you most
likely have to check if the elf file is compiled for AVR at all.

I don't know enough about AVR-specifics of ELF format, but I know that we
in MIPS read successfuly some MIPS-specific things we need to know. Do some
research for ELF format headrr content for AVR.

This is really missing in your series, seriously.

Please keep in mind that I don't have right now at hand any dev system, so
all I said here is off of my head.

You have to do some code digging.

Best regards, Aleksandar


> On Mon, Dec 2, 2019 at 4:01 PM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>>
>>
>> On Monday, December 2, 2019, Michael Rolnik  wrote:
>>
>>> No, I don't.
>>> but I also can load and execute a binary file which does not have this
>>> information.
>>>


>> OK. Let's think about that for a while. I currently think you have here
>> an opportunity to add a really clean interface from the outset of AVR
>> support in QEMU (that even some established platforms don't have in full),
>> which is, trust me, very important for future. And it not that difficult to
>> implement at all. But let's both think for a while.
>>
>> Best regards,
>> Aleksandar
>>
>>
>>
>>> On Mon, Dec 2, 2019 at 11:59 AM Aleksandar Markovic <
>>> aleksandar.m.m...@gmail.com> wrote:
>>>


 On Monday, December 2, 2019, Aleksandar Markovic <
 aleksandar.m.m...@gmail.com> wrote:

>
>
> On Saturday, November 30, 2019, Michael Rolnik 
> wrote:
>
>> There is *-cpu *option where you can specify what CPU you want, if
>> this option is not specified avr6 (avr6-avr-cpu) is chosen.
>>
>> *./avr-softmmu/qemu-system-avr -cpu help*
>> avr1-avr-cpu
>> avr2-avr-cpu
>> avr25-avr-cpu
>> avr3-avr-cpu
>> avr31-avr-cpu
>> avr35-avr-cpu
>> avr4-avr-cpu
>> avr5-avr-cpu
>> avr51-avr-cpu
>> avr6-avr-cpu
>> xmega2-avr-cpu
>> xmega4-avr-cpu
>> xmega5-avr-cpu
>> xmega6-avr-cpu
>> xmega7-avr-cpu
>>
>>
> What happens if you specify a core via -cpu, and supply elf file
> compiled for another core?
>
>
 It looks there is some related info written in ELF header. This is from
 a binutils header:

 (so it looks you could detect the core from elf file - do you do that
 detection right now?)

 #define E_AVR_MACH_AVR1 1
 #define E_AVR_MACH_AVR2 2
 #define E_AVR_MACH_AVR25   25
 #define E_AVR_MACH_AVR3 3
 #define E_AVR_MACH_AVR31   31
 #define E_AVR_MACH_AVR35   35
 #define E_AVR_MACH_AVR4 4
 #define E_AVR_MACH_AVR5 5
 #define E_AVR_MACH_AVR51   51
 #define E_AVR_MACH_AVR6 6
 #define E_AVR_MACH_AVRTINY 100
 #define E_AVR_MACH_XMEGA1  101
 #define E_AVR_MACH_XMEGA2  102
 #define E_AVR_MACH_XMEGA3  103
 #define E_AVR_MACH_XMEGA4  104
 #define E_AVR_MACH_XMEGA5  105
 #define E_AVR_MACH_XMEGA6  106
 #define E_AVR_MACH_XMEGA7  107



 Best regards,
> Akeksandar
>
>
>
>
>> Regards,
>> Michael Rolnik
>>
>>
>>
>> On Sat, Nov 30, 2019 at 1:28 PM Aleksandar Markovic <
>> aleksandar.m.m...@gmail.com> wrote:
>>
>>>
>>>
>>> On Wednesday, November 27, 2019, Michael Rolnik 
>>> 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.

 Following are examples of possible usages, assuming program.elf is
 compiled for AVR cpu
 1.  Continious non interrupted execution
 run `qemu-system-avr -kernel program.elf`
 2.  Continious non interrupted execution with serial output into
 telnet window
 run `qemu-system-avr -kernel program.elf -serial
 tcp::5678,server,nowait -nographic `
 run `telent localhost 5678`
 3.  Continious non interrupted execution with serial output into
 stdout
 run `qemu-system-avr -kernel program.elf -serial stdio`
 4.  Debugging wit GDB debugger
 run `qemu-system-avr -kernel program.elf -s -S`
 run `avr-gdb program.elf` and then within GDB shell `ta

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Tuesday, December 3, 2019, Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

>
>
> On Monday, December 2, 2019, Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>>
>>
>> On Monday, December 2, 2019, Michael Rolnik  wrote:
>>
>>> how can I get this elf flags from within QEMU?
>>>


>> In one of files from your "machine" patch, you have this snippet:
>>
>> +bytes_loaded = load_elf(
>> +filename, NULL, NULL, NULL, NULL, NULL, NULL, 0, EM_NONE, 0,
>> 0);
>>
>> With this line you a kind of "blindly" load whatever you find in the file
>> "filename". I think you need to modify load_elf() to fetch the information
>> on what core the elf in question is compiled for. Additionally, you most
>> likely have to check if the elf file is compiled for AVR at all.
>>
>> I don't know enough about AVR-specifics of ELF format, but I know that we
>> in MIPS read successfuly some MIPS-specific things we need to know. Do some
>> research for ELF format headrr content for AVR.
>>
>> This is really missing in your series, seriously.
>>
>> Please keep in mind that I don't have right now at hand any dev system,
>> so all I said here is off of my head.
>>
>> You have to do some code digging.
>>
>>
> First, you need to update
>
> https://github.com/qemu/qemu/blob/master/include/elf.h
>
> with bits and pieces for AVR.
>
> In binutils file:
>
> https://github.com/bminor/binutils-gdb/blob/master/include/elf/common.h
>
> you will spot the line:
>
> #define EM_AVR 83 /* Atmel AVR 8-bit microcontroller */
>
> that is the value of e_machine field for AVR, which you need to insert in
> qemu's include/elf.h about at line 162.
>
> Then, in another binutils file:
>
> https://github.com/bminor/binutils-gdb/blob/master/include/elf/avr.h
>
> you find the lines:
>
> #define E_AVR_MACH_AVR1 1
> #define E_AVR_MACH_AVR2 2
> #define E_AVR_MACH_AVR25 25
> #define E_AVR_MACH_AVR3 3
> #define E_AVR_MACH_AVR31 31
> #define E_AVR_MACH_AVR35 35
> #define E_AVR_MACH_AVR4 4
> #define E_AVR_MACH_AVR5 5
> #define E_AVR_MACH_AVR51 51
> #define E_AVR_MACH_AVR6 6
> #define E_AVR_MACH_AVRTINY 100
> #define E_AVR_MACH_XMEGA1 101
> #define E_AVR_MACH_XMEGA2 102
> #define E_AVR_MACH_XMEGA3 103
> #define E_AVR_MACH_XMEGA4 104
> #define E_AVR_MACH_XMEGA5 105
> #define E_AVR_MACH_XMEGA6 106
> #define E_AVR_MACH_XMEGA7 107
>
> That you also need to insert in qemu's include/elf.h, probably at the end
> of tge foke or elsewhere.
>
> Perhaps something more you need to insert into that file, you'll see.
>
> Than, you need to modify the file where load_elf() resides with AVR
> support, take a look at other architectures' support, and adjust to what
> you need.
>
> I know it will be contrieved at times, but, personally, similar ELF
> support must be done for any upcoming platform. Only if there is some
> unsourmantable obstacle, that support can be omitted.
>
> I am on vacation next 10 days.
>
>
In the source of readelf utility:


static void
decode_AVR_machine_flags (unsigned e_flags, char buf[], size_t size)
{
  --size; /* Leave space for null terminator.  */

  switch (e_flags & EF_AVR_MACH)
{
case E_AVR_MACH_AVR1:
  strncat (buf, ", avr:1", size);
  break;
case E_AVR_MACH_AVR2:
  strncat (buf, ", avr:2", size);
  break;
case E_AVR_MACH_AVR25:
  strncat (buf, ", avr:25", size);
  break;
case E_AVR_MACH_AVR3:
  strncat (buf, ", avr:3", size);
  break;
case E_AVR_MACH_AVR31:
  strncat (buf, ", avr:31", size);
  break;
case E_AVR_MACH_AVR35:
  strncat (buf, ", avr:35", size);
  break;
case E_AVR_MACH_AVR4:
  strncat (buf, ", avr:4", size);
  break;
case E_AVR_MACH_AVR5:
  strncat (buf, ", avr:5", size);
  break;
case E_AVR_MACH_AVR51:
  strncat (buf, ", avr:51", size);
  break;
case E_AVR_MACH_AVR6:
  strncat (buf, ", avr:6", size);
  break;
case E_AVR_MACH_AVRTINY:
  strncat (buf, ", avr:100", size);
  break;
case E_AVR_MACH_XMEGA1:
  strncat (buf, ", avr:101", size);
  break;
case E_AVR_MACH_XMEGA2:
  strncat (buf, ", avr:102", size);
  break;
case E_AVR_MACH_XMEGA3:
  strncat (buf, ", avr:103", size);
  break;
case E_AVR_MACH_XMEGA4:
  strncat (buf, ", avr:104", size);
  break;
case E_AVR_MACH_XMEGA5:
  strncat (buf, ", avr:105", size);
  break;
case E_AVR_MACH_XMEGA6:
  strncat (buf, ", avr:106", size);
  break;
case E_AVR_MACH_XMEGA7:
  strncat (buf, ", avr:107", size);
  break;
default:
  strncat (buf, ", avr:", size);
  break;
}


So, it looks, for 8-bit AVR, e_machine must be 83 (EM_AVR), while e_flags
is one of E_AVR_MACH_XXX constants. You just need to store somewhere
E_AVR_MACH_XXX that you read from given ELF file, and compare it with core
specified by "-cpu" command line option.



> Yours,
> Aleksandar
>
> .
>
>> Best regards, Aleksandar
>>
>>
>>> On Mon, Dec 2, 2019 at 4:01 PM Aleks

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Tuesday, December 3, 2019, Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

>
>
> On Tuesday, December 3, 2019, Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>>
>>
>> On Monday, December 2, 2019, Aleksandar Markovic <
>> aleksandar.m.m...@gmail.com> wrote:
>>
>>>
>>>
>>> On Monday, December 2, 2019, Michael Rolnik  wrote:
>>>
 how can I get this elf flags from within QEMU?

>
>
>>> In one of files from your "machine" patch, you have this snippet:
>>>
>>> +bytes_loaded = load_elf(
>>> +filename, NULL, NULL, NULL, NULL, NULL, NULL, 0, EM_NONE,
>>> 0, 0);
>>>
>>> With this line you a kind of "blindly" load whatever you find in the
>>> file "filename". I think you need to modify load_elf() to fetch the
>>> information on what core the elf in question is compiled for. Additionally,
>>> you most likely have to check if the elf file is compiled for AVR at all.
>>>
>>> I don't know enough about AVR-specifics of ELF format, but I know that
>>> we in MIPS read successfuly some MIPS-specific things we need to know. Do
>>> some research for ELF format headrr content for AVR.
>>>
>>> This is really missing in your series, seriously.
>>>
>>> Please keep in mind that I don't have right now at hand any dev system,
>>> so all I said here is off of my head.
>>>
>>> You have to do some code digging.
>>>
>>>
>> First, you need to update
>>
>> https://github.com/qemu/qemu/blob/master/include/elf.h
>>
>> with bits and pieces for AVR.
>>
>> In binutils file:
>>
>> https://github.com/bminor/binutils-gdb/blob/master/include/elf/common.h
>>
>> you will spot the line:
>>
>> #define EM_AVR 83 /* Atmel AVR 8-bit microcontroller */
>>
>> that is the value of e_machine field for AVR, which you need to insert in
>> qemu's include/elf.h about at line 162.
>>
>> Then, in another binutils file:
>>
>> https://github.com/bminor/binutils-gdb/blob/master/include/elf/avr.h
>>
>> you find the lines:
>>
>> #define E_AVR_MACH_AVR1 1
>> #define E_AVR_MACH_AVR2 2
>> #define E_AVR_MACH_AVR25 25
>> #define E_AVR_MACH_AVR3 3
>> #define E_AVR_MACH_AVR31 31
>> #define E_AVR_MACH_AVR35 35
>> #define E_AVR_MACH_AVR4 4
>> #define E_AVR_MACH_AVR5 5
>> #define E_AVR_MACH_AVR51 51
>> #define E_AVR_MACH_AVR6 6
>> #define E_AVR_MACH_AVRTINY 100
>> #define E_AVR_MACH_XMEGA1 101
>> #define E_AVR_MACH_XMEGA2 102
>> #define E_AVR_MACH_XMEGA3 103
>> #define E_AVR_MACH_XMEGA4 104
>> #define E_AVR_MACH_XMEGA5 105
>> #define E_AVR_MACH_XMEGA6 106
>> #define E_AVR_MACH_XMEGA7 107
>>
>> That you also need to insert in qemu's include/elf.h, probably at the end
>> of tge foke or elsewhere.
>>
>> Perhaps something more you need to insert into that file, you'll see.
>>
>> Than, you need to modify the file where load_elf() resides with AVR
>> support, take a look at other architectures' support, and adjust to what
>> you need.
>>
>> I know it will be contrieved at times, but, personally, similar ELF
>> support must be done for any upcoming platform. Only if there is some
>> unsourmantable obstacle, that support can be omitted.
>>
>> I am on vacation next 10 days.
>>
>>
> In the source of readelf utility:
>
>
> static void
> decode_AVR_machine_flags (unsigned e_flags, char buf[], size_t size)
> {
>   --size; /* Leave space for null terminator.  */
>
>   switch (e_flags & EF_AVR_MACH)
> {
> case E_AVR_MACH_AVR1:
>   strncat (buf, ", avr:1", size);
>   break;
> case E_AVR_MACH_AVR2:
>   strncat (buf, ", avr:2", size);
>   break;
> case E_AVR_MACH_AVR25:
>   strncat (buf, ", avr:25", size);
>   break;
> case E_AVR_MACH_AVR3:
>   strncat (buf, ", avr:3", size);
>   break;
> case E_AVR_MACH_AVR31:
>   strncat (buf, ", avr:31", size);
>   break;
> case E_AVR_MACH_AVR35:
>   strncat (buf, ", avr:35", size);
>   break;
> case E_AVR_MACH_AVR4:
>   strncat (buf, ", avr:4", size);
>   break;
> case E_AVR_MACH_AVR5:
>   strncat (buf, ", avr:5", size);
>   break;
> case E_AVR_MACH_AVR51:
>   strncat (buf, ", avr:51", size);
>   break;
> case E_AVR_MACH_AVR6:
>   strncat (buf, ", avr:6", size);
>   break;
> case E_AVR_MACH_AVRTINY:
>   strncat (buf, ", avr:100", size);
>   break;
> case E_AVR_MACH_XMEGA1:
>   strncat (buf, ", avr:101", size);
>   break;
> case E_AVR_MACH_XMEGA2:
>   strncat (buf, ", avr:102", size);
>   break;
> case E_AVR_MACH_XMEGA3:
>   strncat (buf, ", avr:103", size);
>   break;
> case E_AVR_MACH_XMEGA4:
>   strncat (buf, ", avr:104", size);
>   break;
> case E_AVR_MACH_XMEGA5:
>   strncat (buf, ", avr:105", size);
>   break;
> case E_AVR_MACH_XMEGA6:
>   strncat (buf, ", avr:106", size);
>   break;
> case E_AVR_MACH_XMEGA7:
>   strncat (buf, ", avr:107", size);
>   break;
> default:
>   strncat (buf, ", avr:", size);
>   break;
> }
>
>
> So, it looks, for 8-bit AVR, e_machin

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Michael Rolnik]

Aleksandar.

enjoy your vacation.

Regards,
Michael Rolnik

On Tue, Dec 3, 2019 at 3:48 AM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

>
>
> On Tuesday, December 3, 2019, Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>>
>>
>> On Tuesday, December 3, 2019, Aleksandar Markovic <
>> aleksandar.m.m...@gmail.com> wrote:
>>
>>>
>>>
>>> On Monday, December 2, 2019, Aleksandar Markovic <
>>> aleksandar.m.m...@gmail.com> wrote:
>>>


 On Monday, December 2, 2019, Michael Rolnik  wrote:

> how can I get this elf flags from within QEMU?
>
>>
>>
 In one of files from your "machine" patch, you have this snippet:

 +bytes_loaded = load_elf(
 +filename, NULL, NULL, NULL, NULL, NULL, NULL, 0, EM_NONE,
 0, 0);

 With this line you a kind of "blindly" load whatever you find in the
 file "filename". I think you need to modify load_elf() to fetch the
 information on what core the elf in question is compiled for. Additionally,
 you most likely have to check if the elf file is compiled for AVR at all.

 I don't know enough about AVR-specifics of ELF format, but I know that
 we in MIPS read successfuly some MIPS-specific things we need to know. Do
 some research for ELF format headrr content for AVR.

 This is really missing in your series, seriously.

 Please keep in mind that I don't have right now at hand any dev system,
 so all I said here is off of my head.

 You have to do some code digging.


>>> First, you need to update
>>>
>>> https://github.com/qemu/qemu/blob/master/include/elf.h
>>>
>>> with bits and pieces for AVR.
>>>
>>> In binutils file:
>>>
>>> https://github.com/bminor/binutils-gdb/blob/master/include/elf/common.h
>>>
>>> you will spot the line:
>>>
>>> #define EM_AVR 83 /* Atmel AVR 8-bit microcontroller */
>>>
>>> that is the value of e_machine field for AVR, which you need to insert
>>> in qemu's include/elf.h about at line 162.
>>>
>>> Then, in another binutils file:
>>>
>>> https://github.com/bminor/binutils-gdb/blob/master/include/elf/avr.h
>>>
>>> you find the lines:
>>>
>>> #define E_AVR_MACH_AVR1 1
>>> #define E_AVR_MACH_AVR2 2
>>> #define E_AVR_MACH_AVR25 25
>>> #define E_AVR_MACH_AVR3 3
>>> #define E_AVR_MACH_AVR31 31
>>> #define E_AVR_MACH_AVR35 35
>>> #define E_AVR_MACH_AVR4 4
>>> #define E_AVR_MACH_AVR5 5
>>> #define E_AVR_MACH_AVR51 51
>>> #define E_AVR_MACH_AVR6 6
>>> #define E_AVR_MACH_AVRTINY 100
>>> #define E_AVR_MACH_XMEGA1 101
>>> #define E_AVR_MACH_XMEGA2 102
>>> #define E_AVR_MACH_XMEGA3 103
>>> #define E_AVR_MACH_XMEGA4 104
>>> #define E_AVR_MACH_XMEGA5 105
>>> #define E_AVR_MACH_XMEGA6 106
>>> #define E_AVR_MACH_XMEGA7 107
>>>
>>> That you also need to insert in qemu's include/elf.h, probably at the
>>> end of tge foke or elsewhere.
>>>
>>> Perhaps something more you need to insert into that file, you'll see.
>>>
>>> Than, you need to modify the file where load_elf() resides with AVR
>>> support, take a look at other architectures' support, and adjust to what
>>> you need.
>>>
>>> I know it will be contrieved at times, but, personally, similar ELF
>>> support must be done for any upcoming platform. Only if there is some
>>> unsourmantable obstacle, that support can be omitted.
>>>
>>> I am on vacation next 10 days.
>>>
>>>
>> In the source of readelf utility:
>>
>>
>> static void
>> decode_AVR_machine_flags (unsigned e_flags, char buf[], size_t size)
>> {
>>   --size; /* Leave space for null terminator.  */
>>
>>   switch (e_flags & EF_AVR_MACH)
>> {
>> case E_AVR_MACH_AVR1:
>>   strncat (buf, ", avr:1", size);
>>   break;
>> case E_AVR_MACH_AVR2:
>>   strncat (buf, ", avr:2", size);
>>   break;
>> case E_AVR_MACH_AVR25:
>>   strncat (buf, ", avr:25", size);
>>   break;
>> case E_AVR_MACH_AVR3:
>>   strncat (buf, ", avr:3", size);
>>   break;
>> case E_AVR_MACH_AVR31:
>>   strncat (buf, ", avr:31", size);
>>   break;
>> case E_AVR_MACH_AVR35:
>>   strncat (buf, ", avr:35", size);
>>   break;
>> case E_AVR_MACH_AVR4:
>>   strncat (buf, ", avr:4", size);
>>   break;
>> case E_AVR_MACH_AVR5:
>>   strncat (buf, ", avr:5", size);
>>   break;
>> case E_AVR_MACH_AVR51:
>>   strncat (buf, ", avr:51", size);
>>   break;
>> case E_AVR_MACH_AVR6:
>>   strncat (buf, ", avr:6", size);
>>   break;
>> case E_AVR_MACH_AVRTINY:
>>   strncat (buf, ", avr:100", size);
>>   break;
>> case E_AVR_MACH_XMEGA1:
>>   strncat (buf, ", avr:101", size);
>>   break;
>> case E_AVR_MACH_XMEGA2:
>>   strncat (buf, ", avr:102", size);
>>   break;
>> case E_AVR_MACH_XMEGA3:
>>   strncat (buf, ", avr:103", size);
>>   break;
>> case E_AVR_MACH_XMEGA4:
>>   strncat (buf, ", avr:104", size);
>>   break;
>> case E_AVR_MACH_XMEGA5:
>>   strncat (buf, ", avr:105", s