Board:hp/pavilion m6 1035dx

Status

Note that this information is for my personal records keeping, and is based on the latest local patches, some of which may not have been published yet.

What works

• Succesfully booting to OS
• Keyboard and touchpad. (This touchpad is DIVINE!!!)
• Built-in Audio
• USB ports (USB 3.0 works with XHCI blob, the ports work with USB 2.0 devices without blob if XHCI controller is disabled)
• Wired and wireless networking. (Wired is a little wonky with some cables, works with others)
• Batterry status and notifications
• Batterry charging
• AC status LED next to power jack (white = charged, amber = charging)
• Power LED on power button (Not sure if it works as expected during suspend)
• Keyboard backlight and on/off control
• Hotkeys: Volume (Up/Down/Mute), Media (Prev/Play/Next), Keyboard backlight, WLAN toggle
• Caps Lock LED
• WLAN enabled/disabled LED
• Suspend/resume on lid closed/open

What doesn't work

• DVD drive. (has anyone tried HP's update for the DVD drive?)
• Power LED on the side (right above disk activity LED)
• Hotkeys: Brightess (Up/Down), Display Toggle. (We get SCIs from the EC)
• Mute LED (Note: doesn't work, even using OEM BIOS)
• Shutdown on critical battery level (We get a _Q25 SCI at 15% level, but that's also shared with insert/remove events)
• Setting Fn key mode to default on or default off. Right now it's default on.

Recommended settings

The simplest way to get a working image is to start from the board-status entry, and use the same .config file.

Suspend/resume and display

This one is a doozie. Suspend/resume generally works, if the VGA bios was run at boot, but the display will not come back on after resume. However, if coreboot sets a VESA framebuffer, and keeps the framebuffer, resume with linux produces a working display again.

Devices -> [*] Run VGA Option ROMs
Devices -> [*]   Re-run VGA Option ROMs on S3 resume
Display -> [*] Set framebuffer graphics resolution
Display -> [*] Keep VESA framebuffer

A native VGA initialization option is under investigation.

Flashing

Flashing works with flashrom, from either coreboot or the vendor BIOS.

$ flashrom -pinternal:laptop=force_I_want_a_brick,amd_imc_force=yes -w coreboot.rom

Expect this to be finicky, and be prepared to do an external flashif something fails.

GPIO layout

This information should not be considered reliable in any way, shape or form

• GPIO57 - OUT - controls WLAN (rfkill pin on minipcie slot)

Photos

• 

  First HP 1035dx to run coreboot, in its early stages of adoption

• 

  A more practical way to develop

General Purpose Events layout

• GEVENT3 -> GPE3 - EC SCI
• GEVENT8 -> PCIE WAKE -> GPE24
• GEVENT23 -> EC SMI -> Configured as GEVENT23 SMI, not GPE23 SMI/SCI
• GEVENT22 -> GPE22 - EC LID

EC headaches

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.

Switching between APM/ACPI modes

Coreboot does it in the SMI handler on request form the OS. Doing that can also be accomplished in userspace by uberawesome blackmagic:

# 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

TODO

• Check PCIe lane assignment (although PCIe devices seem to work fine)
• Check grub2 payload (Run VGA option ROM and Keep VESA framebuffer -- works)
• Check AHCI port mask
• Examine possibility of native VGA init (funfunctor has some ideas)
• WLAN hotkey does not follow OS security model
  • With vendor firmware, WLAN hotkey only works after logging in -- _Qxx handler uses device notifications rather than controlling the GPIOs directly
  • Figure out how to make coreboot's ACPI behave the same way

Detective work

Undocumented EC bits

Offsets relative to EC RAM.

• 0xb8.1 : Lid state (1 = closed, 0 = open)

Native graphics init

There is an effort by mrnuke, in conjunction with Edward from Altera Praxis, Ltd. to create native VGA init for ARUBA GPUs. Most of the work is hosted here:

• https://github.com/alterapraxisptyltd/openatom/
• https://github.com/mrnuke/radeon

Status

There are RFC patches available to POST the GPU. While this is still far from initializing the display, these patches configure the basic GPU clocks and disable CRTCs. This stop the hardware from doing DMA at boot, which allows linux to boot with, and enable the IOMMU.

So far, there is a working driver to control transactions over the AUX channel. This is also used to read the EDID. There is also code to integrate this driver into linux, but it needs a lot more polishing before coming close to being upstreamable (see above).

• https://github.com/alterapraxisptyltd/openatom/blob/master/radeon_replay/aruba/dp_aux.c

The openatom repository also a contains usermode code which, when run on a GPU POSTed by coreboot, can turn on the backlight and train the DP link. It is possible to run the usermode init, load the VGA ROM to memory, then load the radeon driver. This produces a working display without running the VGA ROM at boot. The advantage of this approach is that the realmode code in the VGA BIOS is never run.

Strategy

The idea is to run the usermode init code, then load a modified radeon driver. The radeon driver is hacked to replace individual atombios calls with native functions. For functions of interest, IO tracing is selectively enabled. The IO trace can then be compared (diff'ed) to the trace left by the native function. Thus it's possible to RE one table at a time.

Once individual functions are stable, the plan is to assemble them into a display init path. This code can then be integrated into coreboot to provide native VGA init.

More info

The integrated display is connected to a RTD2132 DP to LVDS converter, which is fed by the DisplayPort output of the APU. This chip implements the "TRAVIS" external encoder interface. While generated by the APU, the BL_ON and BL_PWM signals are passed through the DP to LVDS chip. The RTD2132 will only pass on the backlight control signals after the DP link is trained and fed by a valid video signal. There is no need to poke the EC when enabling the display.

The VGA output seems to be connected to a DP to VGA converter, which is linked via a 4-lane DisplayPort link to the APU. It is believed the DP to VGA converter is part of the FCH.

The VGA ROM is an atombios which contains a realmode ATOM interpreter, atom command/data tables. Linux needs these tables to properly operate mode-switching and initializing the display controller. Linux does not run the realmode code. The ATOM tables can be dumped with AtomDis (TODO: add link to program).

Old approach (deprecated)

There has been some initial work in this regard:

• http://www.coreboot.org/pipermail/coreboot/2013-June/076035.html

Though this approach seems doomed. The radeon driver relies on atombios tables extensively, and the rest of the code is small shims to interface with the rest of linux. This approach can only produce those shims, whereas the bulk of the code is in the atom tables.