Nice! That's quite well organized.

Objectives

1> Create an ACPI subsystem component for AROS. Initially it must identify availability of ACPI on a system, and parse the system ACPI tables, configuring AROS's subsystems with the retrieved infos.

2> Initial configuration will consist of registering found CPUS/APICs, Ints, IRQ routing etc, and enabling AROS to correctly function using the newly probed info.

3> CPUS in SMP systems should be registered in some manor, and each set to run an idle thread except the BOOT CPU.

4> Information from tables should be stored in an Amiga like manner (using lists etc) and available via the ACPI subsystem component.

5> Tools should be provided to display the information contained within the ACPI subsystem component (list of tables etc and info on what the tables "contain") and identify which AROS components are using the probed data. Information about SMP capable systems should also be available.

NB - While ACPI governs Power Management, it will not be considered part of this bounty - neither will battery management or other system drivers using ACPI.(see Phase 2)

How does this look for the initial bounty?

Dammy
TeamAROS

Quote:

Oops! Noted and corrected, thanks Kal!

Dammy

Well, The bounty is more ACPI than APIC related, so i would use the former name not later.

Also as i mentioned before, supporting all of the drivers requires a lot more effort than enough support for IRQ routing and SMP, IMO it would be better as 2 bounties.. one for the initial acpi support (irq routing etc) then a further one to enable acpi to be more functional / useable (support for compiling acpi code to write drivers etc)

Specifically

- find and init all CPUs (1st bounty)
- control speed and power of CPUs (2nd bounty - not needed initially)
- control power of other hardware through ACPI (1st bounty - basic system config from irq table data - irq routing, ints etc. further support in 2nd bounty for external devices to use ACPI, drivers ACPI support as seperate bounties?)
- monitor battery via ACPI (support 2nd bounty, driver itself a seperate bounty?)
- monitor case and lid through ACPI (support 2nd bounty, driver itself a seperate bounty?)
- high-res timer via ACPI (2nd bounty)

Trying to do it all in one will probably just end up with a lame port of an existing and un amigaos like api ..

Thats my 2 cents

Sounds good to me.

1. The interrupt subsystem must support local APIC interrupt handling:

- find and init all CPUs
- control speed and power of CPUs
- control power of other hardware through ACPI
- monitor battery via ACPI
- monitor case and lid through ACPI
- high-res timer via ACPI

2. On multi-processor systems, it must set up all CPUs, leaving all but the first in a waiting state (for when SMP gets going).

3. Test must include inter-processor communication via ints. The test could be native AROS program which reported the other CPUs and did a test on their int subsystem.

4. The other CPUs don't have to do anything useful at this point - merely respond to ints showing their local ACPI handler is functional.

-----------

Any suggestions on how to word this better?

Dammy
TeamAROS