atmega2560 emulation

[systemmind]

I know it is not an issue, but it would be good to have some additional description how actually to use the tool. Is it possible to run the virtual machine with hex/bin file and communicate with it through serial port? Which chips the project supports? But the general question for me: may I emulate any 8-bit chips software like atmega2560? Thanks.

[michaelrolnik]

Hi systemmind.

This project was to add AVR 8 bit CPUs to QEMU, I had no intentions to emulate any boards or peripherals. There is only CPU and a sample/simple board.

1. here https://github.com/michaelrolnik/qemu-avr/blob/master/target/avr/cpu.c#L500-L515 is the list of all supported CPUs
2. and this https://github.com/michaelrolnik/qemu-avr/blob/master/hw/avr/sample.c is the sample board.

You can try to build it and then (assuming your code is in prog.c file)

Compile it and create a binary file

avr-gcc -O0 -mmcu=avr5 prog.c -o prog.avr5.out -g -ggdb avr-objcopy -O binary prog.avr5.out prog.avr5.bin

Then run it

qemu-system-avr -bios prog.avr5.bin

if you want to debug the test run

qemu-system-avr -bios prog.avr5.bin -s -S

and in another window run

avr-gdb prog.avr5.out

target remote :1234 (within opened gdb windows)

Regards, Michael

On Sun, Nov 18, 2018 at 10:11 PM systemmind notifications@github.com wrote:

I know it is not an issue, but it would be good to have some additional description how actually to use the tool. Is it possible to run the virtual machine with hex/bin file and communicate with it through serial port? Which chips the project supports? But the general question for me: may I emulate any 8-bit chips software like atmega2560? Thanks.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/michaelrolnik/qemu-avr/issues/2, or mute the thread https://github.com/notifications/unsubscribe-auth/AGHKok7PvZuLF0248ZAAmUmOORfM8G1Vks5uwb8PgaJpZM4YoHbE .

-- Best Regards, Michael Rolnik

[systemmind]

Hi systemmind. This project was to add AVR 8 bit CPUs to QEMU, I had no intentions to emulate any boards or peripherals. There is only CPU and a sample/simple board. 1. here https://github.com/michaelrolnik/qemu-avr/blob/master/target/avr/cpu.c#L500-L515 is the list of all supported CPUs 2. and this https://github.com/michaelrolnik/qemu-avr/blob/master/hw/avr/sample.c is the sample board. You can try to build it and then (assuming your code is in prog.c file) Compile it and create a binary file avr-gcc -O0 -mmcu=avr5 prog.c -o prog.avr5.out -g -ggdb avr-objcopy -O binary prog.avr5.out prog.avr5.bin Then run it qemu-system-avr -bios prog.avr5.bin if you want to debug the test run qemu-system-avr -bios prog.avr5.bin -s -S and in another window run avr-gdb prog.avr5.out target remote :1234 (within opened gdb windows) Regards, Michael … On Sun, Nov 18, 2018 at 10:11 PM systemmind @.***> wrote: I know it is not an issue, but it would be good to have some additional description how actually to use the tool. Is it possible to run the virtual machine with hex/bin file and communicate with it through serial port? Which chips the project supports? But the general question for me: may I emulate any 8-bit chips software like atmega2560? Thanks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2>, or mute the thread https://github.com/notifications/unsubscribe-auth/AGHKok7PvZuLF0248ZAAmUmOORfM8G1Vks5uwb8PgaJpZM4YoHbE . -- Best Regards, Michael Rolnik

Thanks Michael, your answer was very helpful. Looks like I have run the machine correctly but if I don't use -S option the monitor stuck and I cannot to do with machine any actions anymore. I even cannot stop it with Ctrl+c key combination and may just kill like that sudo killall -9 qemu-system-avr. The same situation appears if I run the qemu with -S argument but execute cont in qemu monitor. It is correct behavior of emulation?

And also what do you think about peripherals? How much efforts may it take to add some? Maybe I may do some patch for that, does it make sense at all?

[michaelrolnik]

Hi,

btw, what is your name?

1. Sorry, I don't know why qemu stucks, maybe because it just CPU and qemu is not built for this
2. Peripherals are not hard. However, peripherals on avr boards do not have separate register regions (some peripherals share same registers) so I was not sure how to implement it. But, once you know how to declare/define correct register ranges, I assume that it should take several days to implement a simple AVR board with all peripherals. It could be a student project. Actually, this was what I hoped would happen. I implement CPU and if there is an interest people will add peripherals, however it turns out there was no interest.

Michael

On Mon, Nov 19, 2018 at 1:56 AM systemmind notifications@github.com wrote:

Hi systemmind. This project was to add AVR 8 bit CPUs to QEMU, I had no intentions to emulate any boards or peripherals. There is only CPU and a sample/simple board. 1. here https://github.com/michaelrolnik/qemu-avr/blob/master/target/avr/cpu.c#L500-L515 is the list of all supported CPUs 2. and this https://github.com/michaelrolnik/qemu-avr/blob/master/hw/avr/sample.c is the sample board. You can try to build it and then (assuming your code is in prog.c file) Compile it and create a binary file avr-gcc -O0 -mmcu=avr5 prog.c -o prog.avr5.out -g -ggdb avr-objcopy -O binary prog.avr5.out prog.avr5.bin Then run it qemu-system-avr -bios prog.avr5.bin if you want to debug the test run qemu-system-avr -bios prog.avr5.bin -s -S and in another window run avr-gdb prog.avr5.out target remote :1234 (within opened gdb windows) Regards, Michael … <#m-4016278844835622279> On Sun, Nov 18, 2018 at 10:11 PM systemmind @.***> wrote: I know it is not an issue, but it would be good to have some additional description how actually to use the tool. Is it possible to run the virtual machine with hex/bin file and communicate with it through serial port? Which chips the project supports? But the general question for me: may I emulate any 8-bit chips software like atmega2560? Thanks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2 https://github.com/michaelrolnik/qemu-avr/issues/2>, or mute the thread https://github.com/notifications/unsubscribe-auth/AGHKok7PvZuLF0248ZAAmUmOORfM8G1Vks5uwb8PgaJpZM4YoHbE . -- Best Regards, Michael Rolnik

Thanks Michael, your answer was very helpful. Looks like I have run the machine correctly but if I don't use -S option the monitor stuck and I cannot to do with machine any actions anymore. I even cannot stop it with Ctrl+c key combination and may just kill like that sudo killall -9 qemu-system-avr. The same situation appears if I run the qemu with -S argument but execute cont in qemu monitor. It is correct behavior of emulation?

And also what do you think about peripherals? How much efforts may it take to add some? Maybe I may do some patch for that, does it make sense at all?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/michaelrolnik/qemu-avr/issues/2#issuecomment-439737946, or mute the thread https://github.com/notifications/unsubscribe-auth/AGHKorBc2IAt-mkXirycfR6JmpCiPphdks5uwfPDgaJpZM4YoHbE .

-- Best Regards, Michael Rolnik

[systemmind]

Hi, again. My name is Illia (Elias is english variant, so you may ask me by this name too if you want).

I have built this project on macOs and I think it would be good for me to test it on some another machine. Maybe it would work better on it.

I am interesting by this project because I am working remotely and now I am modifying some arduino project with atmega2560 cpu and I am looking any funny solution to make some regression/integration automation tests for the project. There actually some another ways how to do this (including simulation with simavr) but I would want to have some independent framework that allows to test the compiled hex/bin/elf file and qemu with peripherals corresponds my requirements I guess.

It is interesting for me to understand how does the qemu works and I think I may have some extra time to spend it to work on peripherals features. I also have some working background with atmega series and I have a junior developer assistant that may also be included to perform some tasks.

So, maybe you can describe the actual problem with register mapping more detailed and point some references (if they exist) where I may read about qemu architecture and how to expand its features. Maybe do you have some another ideas how we may do this?

I believe if qemu will have full support of avr architecture it will be more popular between another developers.

Regards.

P.S. how do you fold the quote?:)

Hi, btw, what is your name? 1. Sorry, I don't know why qemu stucks, maybe because it just CPU and qemu is not built for this 2. Peripherals are not hard. However, peripherals on avr boards do not have separate register regions (some peripherals share same registers) so I was not sure how to implement it. But, once you know how to declare/define correct register ranges, I assume that it should take several days to implement a simple AVR board with all peripherals. It could be a student project. Actually, this was what I hoped would happen. I implement CPU and if there is an interest people will add peripherals, however it turns out there was no interest. Michael … On Mon, Nov 19, 2018 at 1:56 AM systemmind @.> wrote: Hi systemmind. This project was to add AVR 8 bit CPUs to QEMU, I had no intentions to emulate any boards or peripherals. There is only CPU and a sample/simple board. 1. here https://github.com/michaelrolnik/qemu-avr/blob/master/target/avr/cpu.c#L500-L515 is the list of all supported CPUs 2. and this https://github.com/michaelrolnik/qemu-avr/blob/master/hw/avr/sample.c is the sample board. You can try to build it and then (assuming your code is in prog.c file) Compile it and create a binary file avr-gcc -O0 -mmcu=avr5 prog.c -o prog.avr5.out -g -ggdb avr-objcopy -O binary prog.avr5.out prog.avr5.bin Then run it qemu-system-avr -bios prog.avr5.bin if you want to debug the test run qemu-system-avr -bios prog.avr5.bin -s -S and in another window run avr-gdb prog.avr5.out target remote :1234 (within opened gdb windows) Regards, Michael … <#m-4016278844835622279> On Sun, Nov 18, 2018 at 10:11 PM systemmind @.> wrote: I know it is not an issue, but it would be good to have some additional description how actually to use the tool. Is it possible to run the virtual machine with hex/bin file and communicate with it through serial port? Which chips the project supports? But the general question for me: may I emulate any 8-bit chips software like atmega2560? Thanks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2 <#2>>, or mute the thread https://github.com/notifications/unsubscribe-auth/AGHKok7PvZuLF0248ZAAmUmOORfM8G1Vks5uwb8PgaJpZM4YoHbE . -- Best Regards, Michael Rolnik Thanks Michael, your answer was very helpful. Looks like I have run the machine correctly but if I don't use -S option the monitor stuck and I cannot to do with machine any actions anymore. I even cannot stop it with Ctrl+c key combination and may just kill like that sudo killall -9 qemu-system-avr. The same situation appears if I run the qemu with -S argument but execute cont in qemu monitor. It is correct behavior of emulation? And also what do you think about peripherals? How much efforts may it take to add some? Maybe I may do some patch for that, does it make sense at all? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AGHKorBc2IAt-mkXirycfR6JmpCiPphdks5uwfPDgaJpZM4YoHbE . -- Best Regards, Michael Rolnik

[michaelrolnik]

Hi Illia.

Look at this sparc32_dma device

1. it is defined as bus device (here)
2. it has a read and write which are called whenever CPU writes into dma registers
3. here this functions are registered with the device
4. here the defice assignes its read/write function to a piece of memory addresses
5. here the device is instantiated
6. here it is assined address in the physical memory

this basically mean that a device is assigned a range of memory addresses and this range cannot be shared between several devices.

[michaelrolnik]

following is my question to QEMU community some time ago

Hi all,

I want to partially implement AT STK500 board in order to run [FreeRTOS AVR / ATMegaAVR](AVR / ATMegaAVR) demo. if you look into ATmega32 documentation you will see that, for example, Timer/Countet1 registers > are held together at memory addresses [0x46 .. 0xff], but interrupt masks and enable bits are at some other place, actually 0x58 .. 0x59. Every board has its own interrupt masks and enable registers, because number of devices and their types may vary.

what is the right solution?

A: create every device as a true memory mapped QEMU device, which will expose all its interrupts as gpio lines create architecture specific "interrupt controller", which will consume all interrupts and aggregate them.

unless there is no device with registers/bits scattered between different locations.

B: create non memory mapped devices. Each device will export the following functions avr-[device]-init avr-[device]-read-[register] avr-[device]-write-[register] create "big" memory mapped device, which will cover the whole IO space and it will call read/write functions of the devices when there is an access to specific address in the IO memory space.

[michaelrolnik]

and the following is the answer I got from Peter Maydell

I want to partially implement AT STK500 board in order to run FreeRTOS AVR / ATMegaAVR demo. if you look into ATmega32 documentation you will see that, for example, Timer/Countet1 registers are held together at memory addresses [0x46 .. 0xff], but interrupt masks and enable bits are at some other place, actually 0x58 .. 0x59.

(0x58..0x59 is a subset of 0x46..0xff -- I think from the docs that you meant 0x46..0x4f.)

I think I would treat this set of timers as a single device that implements all the timers, and which implements also the timer interrupt mask/enable registers. Where there are multiple disjoint register sets you can do this by having the device provide multiple MemoryRegions, which the SoC container device then maps into the memory space at the right places.

If you plan to support multiple CPUs which reuse some of the individual timer modules but not all of them, you can structure the code to allow convenient reuse, but that is an internal detail of the overall "timers" device.

create non memory mapped devices. Each device will export the following functions

avr-[device]-init avr-[device]-read-[register] avr-[device]-write-[register]

create "big" memory mapped device, which will cover the whole IO space and it will call read/write functions of the devices when there is an access to specific address in the IO memory space.

You can do all this with the memory region API. Your various devices can provide multiple memory regions (implementing the bits of memory space that they care about), and then a higher level SoC container device can map those into the right places in a container memory region which it then exports to the board level. You don't need to invent a new API for having devices provide registers.

[systemmind]

then a higher level SoC container device can map those into the right places

This solution looks more acceptable and logical for me too. I will investigate how it may be implemented in qemu.

[michaelrolnik]

right.

On Tue, Nov 20, 2018 at 3:20 PM systemmind notifications@github.com wrote:

then a higher level SoC container device can map those into the right places

This solution looks more acceptable and logical for me too. I will investigate how it may be implemented in qemu.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/michaelrolnik/qemu-avr/issues/2#issuecomment-440271026, or mute the thread https://github.com/notifications/unsubscribe-auth/AGHKok2clYFgRVtrCUhhbIYTzyfWQHTNks5uxAG1gaJpZM4YoHbE .

-- Best Regards, Michael Rolnik

[michaelrolnik]

Please have a look at the patch by S.E.Harris@kent.ac.uk (https://patchwork.kernel.org/project/qemu-devel)