Board:hp/pavilion m6 1035dx
The wiki is being retired!
Documentation is now handled by the same processes we use for code: Add something to the Documentation/ directory in the coreboot repo, and it will be rendered to https://doc.coreboot.org/. Contributions welcome!
Hello. I'll have some more info soon enough. For now, remember this:
$ flashrom -pinternal:amd_imc_force=yes -w coreboot.rom
Now chances are that will brick your system if you're not already booting coreboot. Expect to do an external flash initially.
This information should not be considered reliable in any way, shape or form
- GPIO57 - OUT - controls WLAN (rfkill pin on minipcie slot)
GPIO54 - OUT - seems to control bluetoothThere is no bluetooth dummy!!!!
General Purpose Events layout
- GEVENT3 -> GPE3 - EC SCI
- GEVENT23 -> GPE23 - EC SMI
- GEVENT22 -> GPE22 - Lid (Output fro EC. Readable, but only triggers GPE on lid open; probably a wake signal)
To ACPI or not to ACPI
The EC likes to start up in APM mode. In APM mode, it will generate an SMI whenever an external event occurs. To make it generate SCIs instead, and play nicely with ACPI, we need to tell it to go to ACPI mode.
The MMIO dilemma
The EC RAM, which contains the batterry/AC etc information is normally accessed by read commands on the EC index I/O ports (0x62 and 0x66). The EC will also respond to LPC memory read/write cycles in the address range 0xff000000 + 0x1000. In order for this to work, the chipset must pass MMIO accesses in this range to the LPC bridge, which in turn, must decode them to the LPC bus.
This can't work if there is something else using that address range, so any system with 16MiB is out of the question. Luckily, the 1035dx uses a 4 MiB chip, so that's a non-issue. As a bonus, the LPC bridge can map a 4 KiB MMIO window on the LPC bus (or two, I can't remember).
The following script enables the needed MMIO window:
# iotools pci_write32 0 0x14 3 0x4c 0xff000000 # iotools pci_write32 0 0x14 3 0x48 0x00b0ff07
The EC RAM is at an offset of 0x800 from the MMIO base address. The current compal/ene932 ACPI implementation does not handle MMIO. This should be easily fixable with some preprocessor love.
The Caps Lock LED
<mrnuke> roxfan (and you too carldani): If I take the EC out of ACPI mode and put it back in, it works <mrnuke> turns out the EC has this "OS not responding, oh shit, gotta blink Caps Lock feature" <patrickg> hah <carldani> mrnuke: ah. hardware. I'm lovin' it <mrnuke> So I can't put it in ACPI mode before OS loads <mrnuke> I'll deal with that "feature" later, I guess <mrnuke> It works on parrot because they handle this stuff (ACPI mode on/off) using SMM <mrnuke> it would be sick if we needed SMM just to get the caps lock LED to function <patrickg> activating SMM is a good idea anyhow, if only to make sure there's some sane code doing the lock down <mrnuke> patrickg: I'll deal with SMM later <mrnuke> I'll make a note on the wiki though so that I don't forget
Doing that can be accomplished in userspace by uberawesome blackmagic. I also have a local patch to do this within coreboot:
# iotools io_write8 0x66 0x59 && iotools io_write8 0x62 0xe9 # Put EC in APM mode # iotools io_write8 0x66 0x59 && iotools io_write8 0x62 0xe8 # Put EC in ACPI mode
- Check PCIe lane assignment
Check grub2 payload(Run VGA option ROM and Keep VESA framebuffer -- works)
- Check AHCI port mask
- Make Suspend/resume (ACPI)
- Implement SMI handler. Reason: EC likes to work with SMIs until OS enables ACPI
Fix GPIO mapI have a local patch which enables WLAN control pin WLAN hotkey controls GPIO57 (ACPI)I have a local patch which fixes this
Undocumented EC bits
Offsets relative to EC RAM.
- 0xb8.1 : Lid state (1 = closed, 0 = open)