OK, I've started a page [1] where ideas can go. Once we stabilize the spec,
I'll remove the warning on top, and we can consider that to be policy.
[1] http://www.coreboot.org/ACPI/Board-EC_interaction
This is an ugly one, and we keep having to find different workarounds to make
this happen. We have the preprocessor, so why not use it?
Define a set of common ACPI method names which the mainboard code should
define, and the EC code can always use.
* MB_TOGGLE_WLAN() or MB_TOGGLE_WIRELESS()
Toggle wireless LAN on and off, or wireless LAN and bluetooth
(respectively). EC calls this on hotkey events.
* MB_INCREASE_BRIGHTNESS() and MB_DECREASE_BRIGHTNESS()
Increase or decrease screen brightness. EC calls this on hotkey events.
* MB_SWITCH_DISPLAY()
Switch the active display. EC calls this on hotkey events.
* MB_NOTIFY_POWER_EVENT()
Handle power state notifications and notify CPU device objects to re-
evaluate their _PPC and _CST tables.
Of course, we would have the mainboard #define these to an existing method, we
wouldn't really use these long method names in ASL. Another idea would be to
standardize on four letter names, but those are not as clear, and hide the
"MB_" which is there to indicate that the mainboard should provide those.
Notice that these methods are only called on hotkey events. As such, unless
the user has really fast fingers, there isn't a huge ACPI overhead as opposed
to setting/clearing the needed bits directly in the caller.
We then extend this to also include ACPI objects for different purposes.
* MB_LID_STATE
Register/GPIO bit which reads the state of the lid
And we can also define a set of ACPI variables which should always be present,
for the purpose of ACPI housekeeping.
* LIDS
Stores the lid state, so that we don't have to read it every time.
(remember, reading may involve several port IO operations)
* PWRS
AC adapter present/not present.
It seems a little convoluted, so if you didn't ACPI before, you'll WTF on this
one. The end result is that it unifies the interface rather than letting each
EC define its own interface. It also (hopefully) makes ACPI just a little more
readable by having a standardized set of pork.
If there aren't any major objections, I'll write this up on the wiki, and
we'll open the gates to refactoring. I'm interested if there are cases where
this *cough* API *cough* is not appropriate. It seems to be universally
efficient.
Alex
I took the discussion to IRC, to avoid endless back-and-forth by mail.
In summary:
The plan is to enable us to write romstage code with the expectation
that at least some RAM (through CAR) is available. (while bootblock is
expected to work without RAM of any kind, and ramstage has the full RAM
available)
If someone wants to use romcc for romstage, that means working without
other object files (since romcc never emits a "call" instruction, except
when hand-assembled). Thus reusing other .c files in romcc means
"#include *.c" as it always did.
Proposal: If someone goes that route, and things break due to the .c
files of the coreboot core being too complex for romcc to handle, they
get to keep the pieces - it's unsupported.
I expect special cases like Vortex (or old chipsets like Via C3, if
someone has the interest and time to do the port) to have a simple
enough RAM initialization that they can be implemented as standalone C
code. That's still _much_ more comfortable than writing assembly, and
it'll work: it has one entry-point (like CAR code), one exit point
(calling into common C code to load the next stage), and everything
inbetween is compiled by romcc to work without RAM.
Should we find out that all the hundred ancient ram inits we get
contributed reimplement the same things over and over, we can still
consider moving those parts to src/lib/romcc, neatly separated from
regular romstage code.
Regards,
Patrick
Am 2014-03-27 14:00, schrieb Andrew Wu:
> So if I want to get rid of romcc, maybe I have to write DRAM init code
> in assembly, That is not very easy. :(
If you can make it compile in romcc without relying on coreboot base
libraries, we could keep Vortex86 RAM init building via romcc. As I
understand Stefan, his main motivation for this push is to clean out all
the romcc related special cases in coreboot's core.
Patrick
So, in messing with this Pavilion m6_1935dx, I was able to get most of the EC
running as expected. It seems that, at least the (ACPI) register layout is the
same. We can get good battery _and_ AC indicators from it.
When we query the EC (say, doing a cat /sys/class/power/AC/online), it
responds properly with an SCI whenever the status register changes, and the
query goes well. And that's about it.
When an event happens, on the other hand, like a hotkey, or AC is removed, it
does not generate an SCI that would lead to a query call (_Qxx). Instead it
spits out an SMI. I know for a fact that the SCI and SMI GPEs are where we
expect them to be.
I see google/parrot uses the same physical EC silicon, though the EC firmware
may be a different beast. However, I'd like to ask of you gurus who have
worked on parrot... what's your take on this?
Alex
More technical details:
I've made ACPI print a debug message whenever GPE23 is triggered (_L17). This
is the EC SMI event.
I'm also using linux supermagic to get an idea of what is going on:
It's changing the ROM base (devfn 14.3, register 0x6c) from 0xffc0 to 0xff00.
The bootblock sets it up correctly, but AmdInitReset messes it up.
Any ideas? AGESA is particularly annoying to grep.
Alex
So, in messing with this Pavilion m6_1935dx, I was able to get most of the EC
running as expected. It seems that, at least the (ACPI) register layout is the
same. We can get good battery _and_ AC indicators from it.
When we query the EC (say, doing a cat /sys/class/power/AC/online), it
responds properly with an SCI whenever the status register changes, and the
query goes well. And that's about it.
When an event happens, on the other hand, like a hotkey, or AC is removed, it
does not generate an SCI that would lead to a query call (_Qxx). Instead it
spits out an SMI. I know for a fact that the SCI and SMI GPEs are where we
expect them to be.
I see google/parrot uses the same physical EC silicon, though the EC firmware
may be a different beast. However, I'd like to ask of you gurus who have
worked on parrot... what's your take on this?
Alex
More technical details:
I've made ACPI print a debug message whenever GPE23 is triggered (_L17). This
is the EC SMI event.
I'm also using linux supermagic to get an idea of what is going on:
# echo 0x88000502 > /sys/module/acpi/parameters/debug_level
# echo 0x00060006 > /sys/module/acpi/parameters/debug_layer
# echo -n 'file ec.c +p' | tee /sys/kernel/debug/dynamic_debug/control
That's how I know the GPE for SCI is correct (also same GPE in the vendor's
ACPI).
The P965/ICH8 combo is suspiciously lacking from the coreboot supported chipsets.
I have a motherboard that might be fit for development on these chipsets (Gigabyte GA-965P-DS3) and I'm curious about taking a stab at this.
However, I've never done any coreboot development nor do I have the proper insight on how to go about this.
I've see this issue was mentioned previously [1] but went unnoticed.
Any feedback on this idea would be much appreciated.
- Yuval
[1] - http://www.coreboot.org/pipermail/coreboot/2012-June/070247.html
Hi all,
I think there is OpenRadeonBios. The problem is that thhe AtomBIOS bytecode is
vendor specific blob, which cannot be in principle released by AMD because it is
written by board manufacturers for specific wireup of graphical output. This is
what I have learnt when I was interested in that way more.
Ron, if you create dummy atombios bios whithout an x86 code the radeon driver in
kernel should be able to post it. It even works now. If you include the orginal
rom in the cbfs but don't run it, the kernel driver is able to modeset it and
"post" it. I think David Hubbard was interested in the replacement BIOS as well..
I think still that graphics modesetting is only minor problem. I feel very
disturbed about AMD plans considering to go same way as Intel. I always liked
AMD for opening their systems as much as possible. There was always my goal to
have some x86 blob free at least for the x86 CPU code. This worked fine with VIA
K8M890 where in VGA bios could be replaced by QEMU bios ;) Now we are drifting
slowly away from any truly open x86 system.
I think we should put some effort making such x86 blobs runnable as kind of
userspace process isolating it as much from coreboot as possible. I mean not
only VGA BIOSes but also FSP or any other blobs.
The various other firmwares are next level problem, we should at least stick to
the primary goal, to have free system which runs on main CPU.
Thanks
Rudolf
