Project

General

Profile

Actions

Bug #659

open
GT

Port of Dell Latitude 7480

Bug #659: Port of Dell Latitude 7480

Added by Gabriel Turlea 23 days ago. Updated 9 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
07/14/2026
Due date:
% Done:

0%

Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
Affected OS:

Description

I have had success porting coreboot to the Dell Latitude 7480 based on work done by Nicholas Chin. Everything works great except the Keyboard. Once linux boots the keyboard works but has sporatic input/output lags. I am not sure what supporting documentation would help in tracking down the issue.

Thank you


Files

latitude_7480_cbmem.log (100 KB) latitude_7480_cbmem.log Gabriel Turlea, 07/20/2026 12:00 AM

GT Updated by Gabriel Turlea 17 days ago Actions #1

placeholder

Motherboard: LA-E131P Dell latitude 7480
CPU: (7th generation (Kaby Lake family) Core Processor (Mobile))
Southbridge: (Sunrise Point-LP U iHDCP 2.2 Premium/Kabylake)
Coreboot: change-90685
Payload: Seabios 17.0

WS Updated by Walter Sonius 15 days ago · Edited Actions #2

From what I remember about the Latitude 5490 CB:90685 is that except for the missing EC/ACPI/BATTERY support the trackpad was detected as a mouse and the Speakers worked fine after patching EC with CB:91120 most other things worked. I see a note that if the accu was still inside the machine (bad /poor health in my case) it triggers occasional stalls, which may explain your keyboard input not working all the time? However I did test it mostly with EDK2 (MrChromeBox).

Perhaps not a solution but can you remove the battery and boot without it for me that fixed stalls 100%. This may also happen on other brands and even OEM bios if accu's are not great and or when running Linux. Could you also try EDK2 as payload and perhaps mention the Linux distro/kernel version you tested?

GT Updated by Gabriel Turlea 12 days ago Actions #3

Hi Walter,

Thank you for your suggestions. I have tried EDK2, and the keyboard issue persists. It is not usable during payload use either Seabios/EDK2 and gives the following error:
[ERROR] Keyboard Interface test failed: 0x8

I suspect it has something to do with the i8042 PS/2 Controller. Here is the difference between OEM:
i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
i8042: Warning: Keylock active
serio: i8042 KBD port at 0x60,0x64 irq 1
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0

Here is the output of my coreboot port:

i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
i8042: Warning: Keylock active
i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input3

On a positive note removing the battery seems to have reduced the input lag, I will keep testing.

All the best,
Gabriel

WS Updated by Walter Sonius 11 days ago · Edited Actions #4

Good to know the lagging reduced, by looking at older logs I did have the same OEM/CB firmware PS/2 dmesg situation. As in latitude 5490 OEM firmware won't list PS/2 mouse since some OEM BIOS foo moves over the PS/2 to the i2c bus during the boot. Since we lack howto impliment this with coreboot it may explaine why the trackpad works but detected as a mouse not a trackpad. Touchscreen also worked fine on the lat5490 since it was USB not i2c, does your machine came with one?

Looking at your cbmem.log it also seems your running the whole coreboot codebase from 8 feb coreboot-25.12-408-gf0678e3639e2-dirty Sun Feb 08, can you pull a new clean coreboot build build environment and only copy over the mb/dell/sklkbl_latitude folder from your older (edited) CB:90685 build? If you know howto use git it should also work with a cherry-pick command but otherwise just copy over only that single folder onto the new code base.

BTW have you applied your own gpio.h/c derived from running util/inteltool -g on the OEM firmware with secureboot disabled and booting linux using kernel parameter iomem=relaxed or are you running CB:90685 as is with only some edits to devicetree.cb and other files?
You'll get a gpio.h/c file from the inteltool -g > x.log if you run it through util/intelp2m/intelp2m -u x.log make sure you have golang-go build tools working otherwise it won't work. You may need to do some minimal extra edits before the gpio.h can be used as a gpio.c.

GT Updated by Gabriel Turlea 9 days ago Actions #5

Touchscreen also worked fine on the lat5490 since it was USB not i2c, does your machine came with one?
Yes mine does have a touchscreen and it does work.
I will try and do what you suggest with a new clean build.
I did create my own gpio.c using both coreboot Documenation and the 38c3 corebooting intel-based systems

Thank you Walter

Actions

Also available in: PDF Atom