April 2014 - coreboot - mail.coreboot.org

[RFH] Reviewers wanted for HP Pavillion patch sets in Gerrit
by Paul Menzel April 9, 2014

April 9, 2014

Dear coreboot folks, Alexandru is almost done with the HP Pavillion port and he submitted a lot of patch sets waiting for review [1]. It would be great if you could review them, so they can be submitted soon. Thanks, Paul [1] http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+t…

1 0

Re: [coreboot] [proposal] EC-mainboard interaction at ASL level
by mrnuke April 8, 2014

April 8, 2014

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

1 0

[proposal] EC-mainboard interaction at ASL level
by mrnuke April 8, 2014

April 8, 2014

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

3 2

Re: [coreboot] [announce] coreboot for the 21st century
by Patrick Georgi April 7, 2014

April 7, 2014

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

2 1

Re: [coreboot] [announce] coreboot for the 21st century
by Patrick Georgi April 7, 2014

April 7, 2014

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

4 4

[HELP!!!] Pavilion EC (similar to compal/ene932) and its woes
by mrnuke April 7, 2014

April 7, 2014

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:

3 5

AGESA (f15tn) AmdInitReset doing nasty things
by mrnuke April 7, 2014

April 7, 2014

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

2 2

[HELP!!!] Pavilion EC (similar to compal/ene932) and its woes
by mrnuke April 5, 2014

April 5, 2014

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).

1 0

P965/ICH8 support revisited
by Yuval Adam April 5, 2014

April 5, 2014

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

3 2

Re: [coreboot] AMD doesn't get it either in some ways
by Rudolf Marek April 5, 2014

April 5, 2014

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

3 2