OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 5:04 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 10 posts ] 
Author Message
 Post subject: ACPI Shutdown doesn't work
PostPosted: Mon Jun 19, 2017 11:52 pm 
Offline

Joined: Tue Apr 19, 2016 2:11 am
Posts: 18
Recently I implemented code for the acpi subsystem. I got this code from http://forum.osdev.org/viewtopic.php?t=16990.

After some several testing I tested this on real hardware. But instead of shutting down the PC performed a boot after the ending of shutdown.

Another problem is that I have the same problem as discribed in http://f.osdev.org/viewtopic.php?t=30623 but I do not get what "PM1_EN" is or where I can find it.

So I am asking for help.


Top
 Profile  
 
 Post subject: Re: ACPI Shutdown doesn't work
PostPosted: Tue Jun 20, 2017 12:09 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

cklie97 wrote:
Recently I implemented code for the acpi subsystem. I got this code from http://forum.osdev.org/viewtopic.php?t=16990.

After some several testing I tested this on real hardware. But instead of shutting down the PC performed a boot after the ending of shutdown.

Another problem is that I have the same problem as discribed in http://f.osdev.org/viewtopic.php?t=30623 but I do not get what "PM1_EN" is or where I can find it.

So I am asking for help.


On a scale from 1 to 10, where 1 represents "works sometimes on some computers if you're extremely lucky" and where 10 represents "complies with all relevant standards, avoids all possible pitfalls, and is guaranteed to always work on any computer that has ACPI if the firmware isn't buggy", the code in that topic should never be used. :roll:

There are only 4 possible choices:
  • don't touch anything that involves ACPI's AML at all (and let firmware handle everything itself)
  • implement a full AML interpreter for everything including power management and fan control, IRQ routing, sleep states, button management, etc (which can mean porting ACPICA)
  • implement a motherboard driver for every motherboard you support, which does everything that a full AML interpreter would've done
  • suffer consequences ranging from unreliability/instability to hardware damage


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: ACPI Shutdown doesn't work
PostPosted: Tue Jun 20, 2017 9:54 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
...or forget about messy ACPICA, and use a small and clean implementation instead. At least that's what OpenBSD does:
https://github.com/openbsd/src/blob/master/sys/dev/acpi/acpi.c
https://github.com/openbsd/src/blob/master/sys/dev/acpi/dsdt.c
Code:
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.


Top
 Profile  
 
 Post subject: Re: ACPI Shutdown doesn't work
PostPosted: Tue Jun 20, 2017 10:10 am 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 999
I wonder what the better choice is: Porting 10000+ SLOC of "small and clean" (aka undocumented) OpenBSD code or using an library that is written by Intel and actually has documentation. NIH syndrome?

(I don't think that ACPICA is great and I plan to eventually get rid of it and write an own AML interpreter but it is still probably the best solution that exists today.)

_________________
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].


Top
 Profile  
 
 Post subject: Re: ACPI Shutdown doesn't work
PostPosted: Tue Jun 20, 2017 1:45 pm 
Offline
Member
Member
User avatar

Joined: Sun Sep 19, 2010 10:05 pm
Posts: 1074
I'm using the quick and dirty, scan the AML for the appropriate values method, and it works on every VM and every physical machine I've tried it on. I would consider it an adequate temporary solution until you have time to do a full AML interpreter implementation.

You could dump the AML byte codes from your ACPI table, and decompile it, or just walk through it step by step and see what it does. Then check your code and make sure it makes the correct OUT calls with the correct values.

EDIT: Who has two thumbs, and five stars?? THIS GUY!!!

_________________
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott


Top
 Profile  
 
 Post subject: Re: ACPI Shutdown doesn't work
PostPosted: Wed Jun 21, 2017 5:28 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

SpyderTL wrote:
I'm using the quick and dirty, scan the AML for the appropriate values method, and it works on every VM and every physical machine I've tried it on. I would consider it an adequate temporary solution until you have time to do a full AML interpreter implementation.

You could dump the AML byte codes from your ACPI table, and decompile it, or just walk through it step by step and see what it does. Then check your code and make sure it makes the correct OUT calls with the correct values.

EDIT: Who has two thumbs, and five stars?? THIS GUY!!!


Now that you've finally reached 5 stars; it's time to ask the important question: How long has your "adequate temporary solution" been permanently "temporary" so far? :roll:


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: ACPI Shutdown doesn't work
PostPosted: Wed Jun 21, 2017 9:12 am 
Offline
Member
Member

Joined: Thu Aug 13, 2015 4:57 pm
Posts: 384
Brendan wrote:
SpyderTL wrote:
I'm using the quick and dirty, scan the AML for the appropriate values method, and it works on every VM and every physical machine I've tried it on. I would consider it an adequate temporary solution until you have time to do a full AML interpreter implementation.


Now that you've finally reached 5 stars; it's time to ask the important question: How long has your "adequate temporary solution" been permanently "temporary" so far? :roll:

Isn't it the same solution you suggested, MoBo driver? Just slightly different terminology and needed encapsulation. I plan on using MoBo drivers as well, simply because it means I can bypass certain things that aren't interesting and provide no direct benefit now, only provide wider hardware support.

Also, it has the nice feature of allowing easy way out once/if I ever get to around implementing ACPI/AML/ACPICA, since those would effectively make for a generic MoBo driver..


Top
 Profile  
 
 Post subject: Re: ACPI Shutdown doesn't work
PostPosted: Wed Jun 21, 2017 10:05 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

LtG wrote:
Brendan wrote:
SpyderTL wrote:
I'm using the quick and dirty, scan the AML for the appropriate values method, and it works on every VM and every physical machine I've tried it on. I would consider it an adequate temporary solution until you have time to do a full AML interpreter implementation.


Now that you've finally reached 5 stars; it's time to ask the important question: How long has your "adequate temporary solution" been permanently "temporary" so far? :roll:

Isn't it the same solution you suggested, MoBo driver? Just slightly different terminology and needed encapsulation. I plan on using MoBo drivers as well, simply because it means I can bypass certain things that aren't interesting and provide no direct benefit now, only provide wider hardware support.

Also, it has the nice feature of allowing easy way out once/if I ever get to around implementing ACPI/AML/ACPICA, since those would effectively make for a generic MoBo driver..


In general (potentially excluding learning); I go with the "nothing is better than something not done right" theory. The idea is that temporary code ("good enough for now") removes most of the incentive to find/create a correct solution and ends up becoming "permanently temporary" because there's always something more urgent or more interesting; and as time passes you end up just adding more temporary code, hacks and work-arounds until you reach a point where the slightest breeze causes the entire tower to crumble.

My "motherboard drivers, no ACPI" plan means that there's a lot of incentive to create motherboard drivers (no IO APIC or MSI, no power management, no software power off, no fan control, no temperature sensors, etc). It's also idealistic and not necessarily practical (and not something I'd recommend to others), but does give me the option of allowing/using a generic motherboard driver that implements "full ACPI done right" if sacrifices must be made.

Of course part of the reason for the "motherboard drivers, no ACPI" plan is that it allows me to require support for things that ACPI doesn't have (being able to prevent malicious tampering via. digital signatures, including "SMBIOS like" information to get rid of another firmware mess, having 3D models so maintenance people can see where parts are before/without opening the case, etc) and then be able to claim that for supported computers (computers that have a motherboard driver) the OS is superior to every other OS that can't do any of these things because they're limited to what Microsoft wanted added to the ACPI specs.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: ACPI Shutdown doesn't work
PostPosted: Wed Jun 21, 2017 2:27 pm 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 999
Brendan wrote:
In general (potentially excluding learning); I go with the "nothing is better than something not done right" theory. The idea is that temporary code ("good enough for now") removes most of the incentive to find/create a correct solution and ends up becoming "permanently temporary" because there's always something more urgent or more interesting; and as time passes you end up just adding more temporary code, hacks and work-arounds until you reach a point where the slightest breeze causes the entire tower to crumble.

I think this is just a project management issue. My usual workflow is: Designing a new feature (this takes up most of the time) -> looking at the old code that is affected by it -> refactoring the old code until it is good enough to add the new feature without major hacks/workarounds -> actually implement the feature -> test the feature and its interactions with existing stuff -> refactor the new code until it passes code review. I rarely if ever run into a "slightest breeze that cause the entire tower to crumble", neither at work nor at my hobby projects.

Always getting it right on the first try is not a viable strategy.

_________________
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].


Top
 Profile  
 
 Post subject: Re: ACPI Shutdown doesn't work
PostPosted: Thu Jun 22, 2017 11:59 am 
Offline
Member
Member

Joined: Thu Aug 13, 2015 4:57 pm
Posts: 384
Brendan wrote:
In general (potentially excluding learning); I go with the "nothing is better than something not done right" theory. The idea is that temporary code ("good enough for now") removes most of the incentive to find/create a correct solution and ends up becoming "permanently temporary" because there's always something more urgent or more interesting; and as time passes you end up just adding more temporary code, hacks and work-arounds until you reach a point where the slightest breeze causes the entire tower to crumble.

Hardcoding stuff into the MoBo/CPU/Platform/etc drivers is fine for me, since it means I can proceed with the more important/interesting stuff, but does mean that each device will need a driver to function. Later, if there's reason for it, I can create generic versions as well and nothing else will need to be changed.

So as long as the functionality is encapsulated in the right place there's no problem. Putting hacks all over the code is of course a bad idea and will lead to the "entire tower crumbling".

Note also that you mentioned "done right", of course what I'm suggesting is assuming that what the driver does is "right", even if not generic, so using "magic numbers" such as knowledge of specific IO ports for specific MoBo is fine, doing random stuff and hoping for best obviously isn't. But as said, such MoBo driver isn't generic and will require a separate driver for each MoBo I want to support, but also means that I can postpone ACPI/AML until I need it for generic MoBo's, because generic is less effort than adding yet another specific MoBo driver, and that might never happen =)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot] and 83 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group