MrChromebox
Taeko4es with coreboot 4.20 won't boot. Can I debug it?
Hi, I have a taeko4es with i3 0000, it has a working cros. I built coreboot 4.20 with TAEKO4ES config and the 3rdparty blob is extracted from the shipped cros firmware(I backup it with suzyq) and ec.RW.flat from taeko folder. But it can not boot. The power light is on for a second and then off then on and the screen no light. Is it a problem of config or spd? Can I debug it with the suzyq cable?
remove the line # CONFIG_CONSOLE_SERIAL is not set from your config, rebuild, flash, and log using terminal on /dev/ttyUSB1 to see what's going on
looks to me like cse_fw_sync() is calling for a reset after executing, but not sure why since it's already in RW mode and up to date.
It's an ec update progress? I just not using the ec from original firmware, but that in production taeko folder(ec.RW.flat).
no, nothing to do with the EC. The ME/CSME (Intel Management Engine / Converged Security Management Engine)
Managed to compile coreboot for the taeko4es and installed win10. It works but when I use the touchpad, the cpu usage will be more than 30%. The cpu will keep up than 30% even when I stop touch the pad. It will be back to normal when I plug or unplug the ac power. Keyboard, touch screen and external mouse work ok.
I asked on discord and coolstar said "GPIO IRQ problem in coreboot, some GPIO is locked clearly"
How can I fix it?
hard to know where to look without knowing which GPIO is the issue. Does the problem exist under Linux?
I have ever installed ubuntu and it's idle cpu usage is also more than 20%. So I think it exist. If it helps, I can reinstall a ubuntu.
I think the gpio is touchpad related. If I was in ubuntu, how can I detect the bug?
IDK, maybe look at /proc/interrupts ?
github isn't the best place to try and debug this kind of issue
This was the fix for the issue on banshee (which was very similar to the issue described here): https://github.com/MrChromebox/coreboot/commit/f564c8b34abbc7010871cfa426af7ee7261c3fde
This was the fix for the issue on banshee (which was very similar to the issue described here): MrChromebox/coreboot@f564c8b
OK, I will try it. Thanks.
@junnikokuki there's nothing to try, the fix for banshee applies to all brya baseboard boards, taeko4es included. It's already done
This was the fix for the issue on banshee (which was very similar to the issue described here): MrChromebox/coreboot@f564c8b
I tried 4.19, 4.20 and 4.21, all the es alder lake chromebooks I tested(anahera4es, redrix4ex, primus4es and taeko4es) had the problem that the first p-core's first thread always has high cpu usage, whenever busy or idle. I use performace analyzer to debug and it pointed to system interrupt or acpi.sys(acpireadgpestatusregister, halpacpipmregisterreadport). But the release version alder lake cpu's chromebooks do not have this problem. So how can I debug it?
are these all pre-production devices using engineering sample (ES) CPUs? If so, then there's no telling what the issue is
I'm not a Windows guy, have no way of debugging this kind of behavior unfortunately