On 07/06/2016 10:11 AM, Michael Rolnik wrote:
what is the smallest range that can be allocated in io space? in the memory
space, it's a page, right?
There is a sub-page facility that can handle byte ranges. This should happen
automatically as you register the devices.
It's only page-permi
On 6 July 2016 at 18:11, Michael Rolnik wrote:
> what is the smallest range that can be allocated in io space? in the memory
> space, it's a page, right?
Both allow allocations down to byte size if you really want them
(at least I think so; possibly there's a word alignment requirement
that I've
Hi Peter,
what is the smallest range that can be allocated in io space? in the memory
space, it's a page, right?
Michael
On Wed, Jul 6, 2016 at 1:11 PM, Michael Rolnik wrote:
> thanks
>
> On Wed, Jul 6, 2016 at 1:10 PM, Peter Maydell
> wrote:
>
>> On 6 July 2016 at 11:04, Michael Rolnik wrot
On 6 July 2016 at 11:04, Michael Rolnik wrote:
> how to create io space device and how to map it?
Conceptually it's no different to handling memory mapped
devices. get_system_io() returns the memory region for the IO
space, and you add devices to it with memory_region_add_subregion().
thanks
--
how to create io space device and how to map it?
thanks,
Michael
On Wed, Jul 6, 2016 at 1:03 PM, Peter Maydell
wrote:
> On 6 July 2016 at 10:55, Michael Rolnik wrote:
> > helper_fullwr will call memory_write if it does not go to [0x -
> 0x0100)
> > range otherwise it will call cpu_outb bec
On 6 July 2016 at 10:55, Michael Rolnik wrote:
> helper_fullwr will call memory_write if it does not go to [0x - 0x0100)
> range otherwise it will call cpu_outb because this range has a dual access
> through ST and OUT instructions
OK, if you have real "OUT" instructions too then that's proba
thanks
On Wed, Jul 6, 2016 at 1:10 PM, Peter Maydell
wrote:
> On 6 July 2016 at 11:04, Michael Rolnik wrote:
> > how to create io space device and how to map it?
>
> Conceptually it's no different to handling memory mapped
> devices. get_system_io() returns the memory region for the IO
> space,
helper_fullwr will call memory_write if it does not go to [0x - 0x0100)
range otherwise it will call cpu_outb because this range has a dual access
through ST and OUT instructions
On Wed, Jul 6, 2016 at 12:52 PM, Peter Maydell
wrote:
> On 6 July 2016 at 10:36, Michael Rolnik wrote:
> > Peter
On 6 July 2016 at 10:49, Michael Rolnik wrote:
> in the range [0x - 0x0100)
> some registers are owned by the CPU and some by board devices.
> CPU registers will be accessed by helper_fullrd & helper_fullwr whereas
> device registers e.g. USB, will be handled by USB provided it's possible to
>
actually registers in the range [0x0020 - 0x0060) have dual access through
ST/LD and OUT/IN
registers in the range [0x - 0x0020) have dual access through ST/LD and
CPU
registers in the range [0x0060 - 0x0100) can be accessed by LD/ST only.
we can create memory device, however it will cover the
in the range [0x - 0x0100)
some registers are owned by the CPU and some by board devices.
CPU registers will be accessed by helper_fullrd & helper_fullwr whereas
device registers e.g. USB, will be handled by USB provided it's possible to
add rd/wr handlers for specific io addresses.
On Wed, Ju
On 6 July 2016 at 10:36, Michael Rolnik wrote:
> Peter,
>
> I think I will do the following
> 1. helper fullwr will modify CPU owned registers by itself and call cpu_outb
> for non owned registers
This doesn't sound right -- if helper_fullwr is for memory writes
it shouldn't call cpu_outb, which
Peter,
I think I will do the following
1. helper fullwr will modify CPU owned registers by itself and call
cpu_outb for non owned registers
2. I will add helper fullrd that will behave like fullwr.
3. any board/model will have to install a device in the io space for
registers not owned by the CPU.
On 6 July 2016 at 10:36, Michael Rolnik wrote:
> Peter,
>
> I think I will do the following
> 1. helper fullwr will modify CPU owned registers by itself and call cpu_outb
> for non owned registers
> 2. I will add helper fullrd that will behave like fullwr.
> 3. any board/model will have to install
On 6 July 2016 at 00:55, Richard Henderson wrote:
> On 07/05/2016 02:41 PM, Michael Rolnik wrote:
>>
>> right it accesses CPU registers but from helper context.
>> the flow is as follows
>>
>> 1. there is a write to [0x: 0x0100) region
>> 2. tlb_fill is called, it does the following
>> a.
thanks. this is a good idea.
env->fullwr is reseted after the TB is retranslated.
On Wed, Jul 6, 2016 at 2:55 AM, Richard Henderson wrote:
> On 07/05/2016 02:41 PM, Michael Rolnik wrote:
>
>> right it accesses CPU registers but from helper context.
>> the flow is as follows
>>
>> 1. there is a
On 07/05/2016 02:41 PM, Michael Rolnik wrote:
right it accesses CPU registers but from helper context.
the flow is as follows
1. there is a write to [0x: 0x0100) region
2. tlb_fill is called, it does the following
a. sets env->fullwr
b. calls cpu_loop_exit_restore.
c. the whole b
On 5 July 2016 at 22:41, Michael Rolnik wrote:
> right it accesses CPU registers but from helper context.
> the flow is as follows
>
> 1. there is a write to [0x: 0x0100) region
> 2. tlb_fill is called, it does the following
> a. sets env->fullwr
> b. calls cpu_loop_exit_restore.
>
1. AT90CAN - http://www.atmel.com/images/doc7679.pdf
4. Memories
Figure 4-2. Data Memory Map
29. Register Summary
2. AT90USB - http://www.atmel.com/images/doc7593.pdf
6. Atmel AVR AT90USB64/128 memories
33. Register summary
in the "register summary" table yo
right it accesses CPU registers but from helper context.
the flow is as follows
1. there is a write to [0x: 0x0100) region
2. tlb_fill is called, it does the following
a. sets env->fullwr
b. calls cpu_loop_exit_restore.
c. the whole block is retranslated and instead of st it genera
On 5 July 2016 at 21:31, Michael Rolnik wrote:
>
> As Richard says you have problems with trying to write
> CPU registers from a device anyway, but please consider
> trying to have some level of abstraction rather than
> just having the device code reach into the CPU object.
>
On 5 July 2016 at 21:31, Michael Rolnik wrote:
> Hi Peter,
>
>
> You're probably better off having the device in one
> patch and the board model in another, rather than combining them.
>
> Generally, device models don't live in hw/, only board
> models. Put the device model in the
Hi Peter,
*You're probably better off having the device in onepatch and the
board model in another, rather than combining them.*
*Generally, device models don't live in hw/, only board
models. Put the device model in the appropriate subdirectoryof hw/,
which is 'misc' for
On 5 July 2016 at 19:15, Michael Rolnik wrote:
> Hi Richard,
>
> Are there more pending issues with my code?
Most of the issues I raised with the board model/device
level code still seem to be present.
thanks
-- PMM
Hi Richard,
Are there more pending issues with my code?
Thanks,
Michael
On Sat, Jul 2, 2016 at 10:56 PM, Michael Rolnik wrote:
> for ADIW, SBIW instructions I modified address calculation.
>
> On Sat, Jul 2, 2016 at 9:20 PM, Michael Rolnik wrote:
>
>> Hi Richard.
>>
>> I folded all my changes
for ADIW, SBIW instructions I modified address calculation.
On Sat, Jul 2, 2016 at 9:20 PM, Michael Rolnik wrote:
> Hi Richard.
>
> I folded all my changes into prevous commits.
>
> 1. I meant EOR, which is actually XOR. Prevously it did not save the
> result into the register
> 2. my mistake I
Hi Richard.
I folded all my changes into prevous commits.
1. I meant EOR, which is actually XOR. Prevously it did not save the result
into the register
2. my mistake I meant ORI and LDS and not ADIW, SBIW
3. when there is a call to tlb_fill for [0x: 0x0100) region it
a. sets env->fullwr
On 07/01/2016 07:47 AM, Michael Rolnik wrote:
5. translation bug fixes for ADIW, SBIW, XOR instructions
6. propper handling of cpu register writes though memory
I don't see these changes in the patch set.
r~
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
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
30 matches
Mail list logo
