[embedded] Add QEMU-based testing configs for ARM and AVR for runtime testing

[kubamracek]

This PR adds lit test configurations that execute runtime tests inside QEMU, one at a time, in the "baremetal" mode of QEMU.

More concretely:

• A lit configuration can now be "EXTERNAL_EMBEDDED_PLATFORM", which means that compilation, linking and execution will consult a new test support tool called embedded-test-support.py and ask for compiler flags, linker flags and execution for a particular device type.
• For ARM and AVR CPUs, a super minimal baremetal runtime support is added (interrupt vectors, stack setup code, linker script, etc.) and used for building valid standalone firmwares for each lit test.
• The embedded-test-support.py script is intended to be easily extensible with new devices, CPU architectures, and even other simulators besides QEMU.
• All Embedded Swift tests (in the test/embedded/ directory) now opt-in to the new Swift Driver (as the old driver is not really maintained anymore and has unfixed bugs).

Currently, this setup is not going to run automatically anywhere. It will only be available for manual usage by (1) enabling SWIFT_SHOULD_BUILD_EMBEDDED_STDLIB_CROSS_COMPILING, and (2) running tests e.g. with:

$ ../llvm-macosx-arm64/bin/llvm-lit -v ./test-embedded-armv7 --filter embedded/

Not all the embedded tests pass under the ARM and AVR configs, but the plan is to fix them (or disable when appropriate) and eventually start running these test configurations in Swift CI.

[kubamracek]

CC @carlos4242

[carlos4242]

nit: This should work fine in QEMU although it probably wouldn't work on a device, as you need to wait for the byte to transmit through the UART, something like: https://github.com/microswift-packages/HAL/blob/develop/module/UART.swift#L472 (we got caught out by this a few times as swift often optimised this check away!)

[rauhul]

FWIW: that repo is private and access through a volatile pointer should never be optimized away. Could you share the source?

[carlos4242]

Here's an extract from our hardware library...

static var dataRegisterEmpty: Bool {
        get {
            return !((USARTControlAndStatusRegisterA & 0b00100000) == 0)
        }
}

static func write(_ byte: PortDataType) {
        while !dataRegisterEmpty { }
        USARTIODataRegister = byte
    }

[carlos4242]

(it's written in swift as we use swift for our hardware libraries these days but you get the idea)

[rauhul]

hmm you should use swift-mmio and the svd2swift code generator once more parts of the swift compiler/swiftpm build system are working

[carlos4242]

Oh drat sorry! I was sure it was public but it was forked from a private repo so I can’t make it public!I’m on my phone now so I’ll try to sort it out when I get back on my MacBook later.Don’t worry too much. I’m sure this code will work on an emulator.On 24 Jul 2024, at 18:38, Rauhul Varma ***@***.***> wrote: @rauhul commented on this pull request. In utils/embedded-test-support/avr-qemu-atmega2560/support.c:

+__attribute__((used))

+static inline void *memcpy_flash_to_sram(void *restrict dst, const void __attribute__((__address_space__(1))) *restrict src, size_t n) { + for (int i = 0; i < n; i++) { + ((char *)dst)[i] = ((char __attribute__((__address_space__(1))) *)src)[i]; + } + return dst; +} + +void copy_data_from_flash_to_sram() { + // Copy data segment from 0x200-program-space to 0x200-data-space, 7 kB in size (see linkerscript.ld) + memcpy_flash_to_sram((void *)0x200, (void __attribute__((__address_space__(1))) *)0x200, 7 * 1024); +} + +int putchar(int c) { + // AVR's UART0 DR register + *((volatile char *)0xc6) = c; FWIW: that repo is private and access through a volatile pointer should never be optimized away. Could you share the source? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[kubamracek]

I think I'm going to just hardcode the assumption that this code is only suitable for the emulator, and explain that in a comment.

[kubamracek]

@swift-ci please test

[kubamracek]

@swift-ci please test