add gitlab issues in toml format

4 files changed, 243 insertions, 0 deletions

diff --git a/gitlab/issues/target_avr/host_missing/accel_TCG/1118.toml b/gitlab/issues/target_avr/host_missing/accel_TCG/1118.toml
new file mode 100644
index 00000000..ecec061b
--- /dev/null
+++ b/gitlab/issues/target_avr/host_missing/accel_TCG/1118.toml
@@ -0,0 +1,83 @@
+id = 1118
+title = "[AVR] Interrupt skips to incorrect handler when raised after skipping instruction"
+state = "closed"
+created_at = "2022-07-24T11:16:33.943Z"
+closed_at = "2022-09-02T17:18:21.342Z"
+labels = ["Closed::Fixed", "accel: TCG", "target: avr"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/1118"
+host-os = "Windows 10"
+host-arch = "AVR, Bare metal"
+qemu-version = "7.0.50 (v7.0.0-11902-g1d935f4a02-dirty)"
+guest-os = "n/a"
+guest-arch = "AVR, Bare metal"
+description = """If interrupt is raised after instruction that can skip following instruction (for example `CPSE`), and skip condition is active, instead of correct vector, one after it is executed. 
+
+This can happen only if CPSE instruction is at the end of translation block. Usually it is somewhere inside block and very rare arrangement of code is required to get into that error."""
+reproduce = """Real world scenario is waiting in busy loop for `std::atomic<bool>` set by interrupt, in bigger application, with optimized code and rare chance of code arrangement. Effect usually is landing in `__bad_interrupt` and reset, but can also be executing other interrupt handler.
+
+Synthetic example is:
+
+1. There must be instruction that can skip following instruction (for example `CPSE`), with always-active condition for skip
+2. It must be placed in way, that it will be at the end of translation block.
+
+\tExample (addresses matter):
+```
+     ff8:\t81 e0       \tldi\tr24, 0x01\t; 1
+     ffa:\t88 13       \tcpse\tr24, r24
+     ffc:\t01 c0       \trjmp\t.+2      \t; 0x1000
+     ffe:\t80 e0       \tldi\tr24, 0x00\t; 0
+    1000:\t00 00       \tnop
+```
+
+3. It should be busy-looped to raise chances of encountering that code
+4. Any external interrupt should be generated
+\t- the simplest is UART RX on stdin raised by key presses
+
+Fully working example attached, with ELF file, annotated C code, ASM dump, and Makefile that allows compiling and running this scenario (but I don't guarantee that self-compiling would always generate this error - it can move code a bit). 
+
+(please adjust paths to GCC and QEMU in Makefile before using)
+
+[avr-irq-fail.zip](/uploads/b702104098a31754d544d6ae6e60e074/avr-irq-fail.zip)
+
+Running by command:
+
+    ./qemu-system-avr -machine arduino-uno -nographic -monitor null -serial stdio -bios fail.elf
+
+And then press any key until error happens.
+
+It is largely machine independent, I originally encountered that on custom Atmega644 machine."""
+additional = """Annotated execution log output of `in_asm`, real-world example:
+
+```
+----------------
+IN: _ZNKSt6atomicIbEcvbEv
+0x00000ff4:  MOVW      r31:r30, r25:r24
+0x00000ff6:  LDDZ      r25, Z+0
+0x00000ff8:  LDI       r24, 1
+0x00000ffa:  CPSE      r25, r1            // <-------------------- it must looks like that, with CPSE at the end
+
+----------------
+IN: _ZNKSt6atomicIbEcvbEv
+0x00000ffc:  RJMP      .+2
+
+----------------
+IN: _ZNKSt6atomicIbEcvbEv
+0x00001000:  RET
+...
+```
+and then:
+```
+// <-------------------- INT 20 raised
+...
+----------------
+IN:
+0x00000050:  JMP       0x1002  // <-- correct vector loaded...
+
+----------------
+IN:
+0x00000054:  JMP       0x1012  // <-- ...but skipping to one after that...
+
+----------------
+IN: __vector_21     // <-- ...and executing incorrect handler
+...
+```"""
diff --git a/gitlab/issues/target_avr/host_missing/accel_TCG/489.toml b/gitlab/issues/target_avr/host_missing/accel_TCG/489.toml
new file mode 100644
index 00000000..0eb02757
--- /dev/null
+++ b/gitlab/issues/target_avr/host_missing/accel_TCG/489.toml
@@ -0,0 +1,45 @@
+id = 489
+title = "Assertion raised when hitting gdb break point in qemu-system-avr"
+state = "closed"
+created_at = "2021-07-18T08:23:54.027Z"
+closed_at = "2021-07-22T15:10:34.268Z"
+labels = ["Closed::Fixed", "GDB", "accel: TCG", "kind::Bug", "target: avr"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/489"
+host-os = "Linux Mint 20.2"
+host-arch = "x86_64"
+qemu-version = "QEMU emulator version 6.0.50 (v6.0.0-2825-ga97fca4ceb)"
+guest-os = "Embedded"
+guest-arch = "AVR"
+description = """An assertion is triggered when inserting a break point via gdb and continuing from gdb until hitting the break point:
+```
+./qemu-system-avr -nographic -machine uno -s -S -bios simpletest.bin 
+Starting up...
+qemu-system-avr: ../accel/tcg/translate-all.c:1476: tb_gen_code: Assertion `tb->size != 0' failed.
+Aborted (core dumped)
+```
+The matching gdb session:
+```
+~/gdb/gdb-10.1-OK/gdb/avr-gdb 
+GNU gdb (GDB) 10.1
+[snipped copyright notice ]
+(gdb) tar rem :1234
+Remote debugging using :1234
+warning: Target-supplied registers are not supported by the current architecture
+warning: No executable has been specified and target does not support
+determining executable automatically.  Try using the "file" command.
+0x00000000 in ?? ()
+(gdb) b *0xb2
+Breakpoint 1 at 0xb2
+(gdb) c
+Continuing.
+Remote connection closed
+(gdb) 
+```"""
+reproduce = """1. Start qemu with command line given in description above
+2. Connect to qemu session using avr-gdb, also given in description.
+3. From avr-gdb, place a break point somewhere in code, then continue
+4. When qemu reaches break point, an assertion is raised"""
+additional = """1. When running without a break point there is no assertion
+2. Problem appears to be triggered only when inserted break point is hit.
+3. Stepping in gdb works
+4. This problem isn't evident in qemu 6.0.0"""
diff --git a/gitlab/issues/target_avr/host_missing/accel_TCG/869.toml b/gitlab/issues/target_avr/host_missing/accel_TCG/869.toml
new file mode 100644
index 00000000..18141d17
--- /dev/null
+++ b/gitlab/issues/target_avr/host_missing/accel_TCG/869.toml
@@ -0,0 +1,29 @@
+id = 869
+title = "Qemu-system-avr working example"
+state = "closed"
+created_at = "2022-02-12T20:36:39.246Z"
+closed_at = "2022-02-15T09:55:08.782Z"
+labels = ["accel: TCG", "target: avr"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/869"
+host-os = "Arch Linux"
+host-arch = "x86_64"
+qemu-version = "`"
+guest-os = "Bare Metal"
+guest-arch = "AVR 8bit"
+description = """I'm trying to get an Arduino board emulated with QEMU. Unfortunately, I can't get it to work.
+I tried the commands, given in [https://qemu.readthedocs.io/en/latest/system/target-avr.html](https://qemu.readthedocs.io/en/latest/system/target-avr.html) and also downloaded and used the example elf file.
+
+
+I then tried some more basic commands and used`qemu-system-avr -machine uno`. This should
+run without any problems or? I also tried `2009` and `mega2560`.
+
+I also searched on the internet about working examples as well as further usage information, but I couldn't really find much.
+Therefore, I hope someone can help me out or point me to additional material."""
+reproduce = """1. run `qemu-system-avr -machine uno`
+2. wait around 5-10 seconds
+3. on the terminal the following message appears with the qemu window crashing
+```
+$ qemu-system-avr -machine uno
+  qemu-system-avr: execution left flash memory
+```"""
+additional = """I'm fairly new to this, so please excuse me if I forgot something to post or made a mistake while posting."""
diff --git a/gitlab/issues/target_avr/host_missing/accel_missing/1525.toml b/gitlab/issues/target_avr/host_missing/accel_missing/1525.toml
new file mode 100644
index 00000000..4ebbc8b7
--- /dev/null
+++ b/gitlab/issues/target_avr/host_missing/accel_missing/1525.toml
@@ -0,0 +1,86 @@
+id = 1525
+title = "Wrong initial value of stack pointer on AVR devices"
+state = "closed"
+created_at = "2023-03-01T15:03:46.130Z"
+closed_at = "2023-11-28T23:12:55.240Z"
+labels = ["target: avr"]
+url = "https://gitlab.com/qemu-project/qemu/-/issues/1525"
+host-os = "Windows 11 22H2"
+host-arch = "AMD64"
+qemu-version = "v7.2.0-11948-ge6523b71fc-dirty"
+guest-os = "None"
+guest-arch = "AVR"
+description = """The initial value of stack pointer of AVR MCUs should be RAMEND (address of the end of their RAM), but QEMU initialize them to 0.
+
+`qemu-system-avr -machine help` lists 4 flavors of MCUs which are ATmega168, ATmega2560, ATmega1280, ATmega328P. According to their datasheets, the stack pointer should be initialized as follows on reset.
+
+- [ATmega168](https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-9365-Automotive-Microcontrollers-ATmega88-ATmega168_Datasheet.pdf#page=12): RAMEND (which is 0x04FF)
+- [ATmega2560 and ATmega1280](https://ww1.microchip.com/downloads/en/devicedoc/atmel-2549-8-bit-avr-microcontroller-atmega640-1280-1281-2560-2561_datasheet.pdf#page=15): RAMEND (which is 0x21FF)
+- [ATmega328P](https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061B.pdf#page=22): RAMEND (which is 0x08FF)"""
+reproduce = """1. Assemble the assembly code below: `avrasm2 -fI test.asm`
+
+    ```asm
+    ;; test.asm
+    .INCLUDE "m328Pdef.inc"
+
+    .EQU F_CPU = 16000000
+    .EQU BAUD_RATE = 9600
+    .EQU PRESCALE = (F_CPU / (16 * BAUD_RATE)) - 1
+
+    .CSEG
+    start:
+    \t;; initialize USART (serial port)
+    \tLDI R16, LOW(PRESCALE)
+    \tLDI R17, HIGH(PRESCALE)
+    \tSTS UBRR0L, R16
+    \tSTS UBRR0H, R17
+    \tLDI R16, (1 << RXEN0) | (1 << TXEN0)
+    \tSTS UCSR0B, R16
+
+    \t;; Get stack pointer low byte and print it in ASCII
+    \tIN R16, SPL
+    \tLDI R17, 0x30
+    \tADD R16, R17
+    print1:
+    \tLDS r17, UCSR0A
+    \tSBRS r17, UDRE0
+    \tRJMP print1
+    \tSTS UDR0, r16
+
+    \t;; Get stack pointer high byte and print it in ASCII
+    \tIN R16, SPH
+    \tLDI R17, 0x30
+    \tADD R16, R17
+    print2:
+    \tLDS r17, UCSR0A
+    \tSBRS r17, UDRE0
+    \tRJMP print2
+    \tSTS UDR0, r16
+
+    end:
+    \tRJMP end
+    ```
+
+2. Convert it to bin file: `avr-objcopy --input-target=ihex --output-target=binary test.hex test.bin`
+
+3. Run it with QEMU: `qemu-system-avr -machine uno -bios test.bin -serial stdio`
+
+This should print 00 which means that the stack pointer is initialized to 0."""
+additional = """I examined the source code and I think that editing the function `avr_cpu_reset_hold` in `/target/avr/cpu.c` might fix this issue. This is my first time seeing QEMU source code, so I might be wrong, though.
+
+```c
+// in /target/avr/cpu.c line 70
+static void avr_cpu_reset_hold(Object *obj)
+{
+    // ...
+
+    env->rampD = 0;
+    env->rampX = 0;
+    env->rampY = 0;
+    env->rampZ = 0;
+    env->eind = 0;
+    env->sp = 0;    // <-- change this value in accordance with board type?
+
+    //...
+}
+```"""