Here's some proposed bounties... Over time with input I will be updating them.

EMU68 Bounty. (This one is set in stone as it was written with the help of mschulz).

Porting Emu68 to EFI
Overview
This bounty focuses solely on adapting Emu68 to function as an EFI binary executable, laying the foundation for future work to enable AmigaOS/AROS 68K to boot natively on ARM hardware. Since EFI handles hardware abstraction via its protocols, the scope of this bounty is limited to making Emu68 compliant with the EFI standard and ensuring basic ACPI table parsing for future use.

Objectives
1. Adapt Emu68 to function as a compliant EFI binary executable.
2. Implement basic support for:
ACPI Table Parsing: Convert Little Endian ACPI data to Big Endian for compatibility with 68K environments.
3. Lay the groundwork for AmigaOS and AROS integration in subsequent phases.


AROS Bounties
Bounty 1: Develop a GOP-Based Graphics HIDD Driver
Overview (Technical):Implement framebuffer graphics support for EFI systems using the EFI_GRAPHICS_OUTPUT_PROTOCOL (GOP). This driver enables AROS to render graphics through the GOP's static framebuffer, providing essential display functionality.

Key Objectives (Technical):

Pre-Boot Phase:
Automatically select the best available resolution using GOP before boot services terminate.
Optional: Allow users to select a resolution via the Early Startup Control menu.
Runtime Phase:
Develop a HIDD driver to use the static framebuffer provided by GOP for rendering after ExitBootServices.
Ensure compatibility with AROS's graphics subsystem.
Fallback and Compatibility:
Use the VESA ROM driver as a reference for structure.
Provide fallback options for systems without GOP support.

Capabilities (Practical):

Enables AROS to display graphics on modern UEFI-based systems using GOP.
Similar to what the VESA driver provides on PCs.
Provides automatic resolution selection or the option for manual configuration during boot.
Offers basic graphics functionality for systems lacking legacy BIOS modes.

Bounty 2: Transition EFI Input Support to AROS Input.device
Overview (Technical):Enable seamless input device functionality by transitioning from EFI input protocols during the pre-boot phase to AROS's input.device during runtime.

Key Objectives (Technical):

Use EFI_SIMPLE_TEXT_INPUT_PROTOCOL for keyboard input and EFI_SIMPLE_POINTER_PROTOCOL for mouse input during the pre-boot phase.
Ensure a smooth transition to AROS's input.device post-boot.

Capabilities (Practical):

Ensures full keyboard and mouse functionality during boot and runtime.
Enables a smooth transition from pre-boot input handling to AROS's native input system.

Bounty 3: Expand and Refine EFI ACPI Table Handling
Overview (Technical):Enhance AROS's ability to parse and utilize EFI-provided ACPI tables for hardware abstraction and initialization.

Key Features (Technical):

Parse and convert ACPI tables into a format usable by AROS.
Validate ACPI-driven hardware discovery and initialization.

Capabilities (Practical):

Allows AROS to detect and utilize hardware like storage devices, network cards, and USB ports.
Improves hardware compatibility with modern systems by leveraging ACPI.

Bounty 4: Implement EFI Storage Access for Kernel Loading
Overview (Technical):Enable AROS to load its kernel and boot files from EFI-compliant storage devices. This focuses on integrating EFI storage protocols to support kernel loading in both GRUB-based and direct EFI boot scenarios.

Key Features (Technical):

Add support for EFI_BLOCK_IO_PROTOCOL and EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.
Validate kernel and file loading from block-oriented devices.
Ensure compatibility with GRUB.

Capabilities (Practical):

Enables AROS to boot directly from modern storage devices like SSDs or USB drives.
Supports both UEFI-native and GRUB-based boot setups.

Bounty 5: Enhance AROS Bootloader for EFI Systems
Overview (Technical):Focus on broader enhancements to the AROS bootloader, leveraging EFI system features for advanced boot scenarios.

Key Features (Technical):

Integrate EFI system table and memory map handling.
Add support for EFI_DEVICE_PATH_PROTOCOL for locating devices.
Leverage GOP for display initialization during boot.

Capabilities (Practical):

Improves bootloader performance and compatibility on EFI-based systems.
Provides better hardware support during boot, enhancing the user experience.

Bounty 6: AROS Pre-Boot Networking with UEFI
Overview (Technical):Enable pre-boot networking capabilities using EFI_SIMPLE_NETWORK_PROTOCOL, supporting PXE boot and network-based kernel loading.

Key Features (Technical):

Add support for EFI_SIMPLE_NETWORK_PROTOCOL in the AROS bootloader.
Enable PXE boot functionality.
Add tools for diagnosing network connectivity during pre-boot.

Capabilities (Practical):

Enables network booting, allowing AROS to be loaded directly over a network.
Adds pre-boot networking diagnostics for troubleshooting and improved reliability.

Bounty 7: Cross-Architecture EFI Compatibility
Overview (Technical):Extend AROS's EFI implementation to support multiple architectures, such as ARM and MC68K.

Key Features (Technical):

Adapt EFI protocols for cross-platform compatibility.
Validate EFI functionality on ARM, MC68K, and x86 platforms.

Capabilities (Practical):

Broadens AROS's compatibility with modern hardware architectures, including ARM and retro-inspired 68K systems.
Ensures AROS can run on diverse hardware platforms.

Bounty 8: Implement Secure Boot Compatibility
Overview (Technical):Adapt AROS to work with EFI Secure Boot to ensure compatibility with modern security standards.

Key Features (Technical):

Add support for authenticated boot processes using signed kernels.
Validate Secure Boot workflow on EFI platforms.

Capabilities (Practical):

Enables AROS to boot securely on systems with Secure Boot enabled.
Ensures compatibility with security requirements on modern PCs.

Bounty 9: Develop a Modular EFI Management Framework
Overview (Technical):Create a centralized framework within AROS to manage EFI interactions and diagnostics.

Key Features (Technical):

Provide tools for accessing EFI protocols (storage, graphics, input, networking).
Implement diagnostics for troubleshooting EFI-related issues.

Capabilities (Practical):

Simplifies managing EFI features on AROS systems.
Provides tools for diagnosing EFI hardware and improving system stability.

update to Stage 1

Porting Emu68 to EFI

Overview

This project is focused on adapting Emu68 to function in an EFI environment by splitting it into two distinct applications: a loader and the emulator itself. The loader will handle EFI compliance and initialization, while Emu68 will operate as a standalone 68K emulator. Additionally, a test program will be developed to validate ACPI data under Emu68.

Objectives

Develop an EFI Loader.

Create a compliant EFI application responsible for initializing and loading Emu68.

Ensure the loader handles hardware abstraction and passes necessary configuration data to Emu68.

Implement Basic Support for ACPI Table Parsing.

Parse ACPI tables provided by EFI.

Convert Little Endian ACPI data to Big Endian for compatibility with the 68K environment.

Split Emu68 and Loader into Two Applications.

Develop a standalone EFI loader to initialize and load Emu68.

Keep Emu68 focused solely on emulation tasks, with no direct hardware initialization.

Develop a Test Program for ACPI Data Validation.

Create a 68K-compatible program that runs under Emu68.

Validate ACPI table parsing and endian conversion.

Ensure compatibility and correctness of ACPI data for future use by AmigaOS/AROS.

Implementation Plan

Step 1: Develop an EFI Loader

Loader Responsibilities:

Create a standalone EFI loader responsible for:

Locating and loading the Emu68 binary.

Setting up the execution environment, including memory allocation and passing necessary configuration data to Emu68.

Use EFI protocols to handle hardware abstraction, such as accessing ACPI tables.

Basic System Initialization:

Ensure the loader initializes system resources like memory and storage using EFI services.

Set up a mechanism to pass ACPI and other hardware details to Emu68.

Debugging Support:

Include debug outputs in the loader to verify the correct setup of the execution environment.

Step 2: Refactor Emu68 for EFI Integration

Standalone Emulator:

Remove any bare-metal initialization tasks from Emu68, delegating these to the loader.

Ensure Emu68 operates solely as a 68K emulator, relying on the loader for execution context and data.

ACPI Table Parsing in Emu68:

Add support for parsing ACPI tables passed by the loader.

Implement endian conversion for compatibility with the 68K environment.

Ensure parsed ACPI data can be utilized by future AmigaOS/AROS 68K integration.

Execution Environment:

Verify Emu68 functions correctly within the environment established by the loader.

Step 3: Develop a Test Program for ACPI Validation

68K Test Program:

Create a test program compatible with Emu68 to validate ACPI data parsing and endian conversion.

Include routines to check the integrity and correctness of ACPI tables.

Integration Testing:

Run the test program under Emu68 in the EFI environment.

Log results for debugging and verification.

Deliverables

A standalone EFI loader application.

A refactored Emu68 emulator.

A 68K test program for ACPI validation.

Documentation for:

EFI loader and Emu68 integration.

ACPI table parsing and endian conversion routines.

Test program usage and expected outputs.

Hi, i am not sure if this fits in this topic, but if the objective is to run aros under emu68, maybe a better start would be to modularise the graphics support of the 68k port.

as from this link https://github.com/aros-development-team/AROS/blob/master/boot/modular_kickstart.txt

These modules are not allowed to have machine-specific code because it
violates portability convention. As of 12.09.2011, m68k-amiga
(chipset-specific code in graphics.library) and PowerPC-native (display
driver setup kludge in dos.library boot code) ports do not conform to this rule.

Kind regards,