I did a bit more digging. With this change, the trampoline code changed too.
I have no idea why linux payloads work for anyone past this ref. It may just be you get the right config options and get lucky.
The bigger problem is lots of us took the bzimage format as constant, in some sense, and it's clearly possible for it to change in ways that break coreboot (and u-boot, in this case, and an arm chromebook as you can see from the discussion).
good times.
tpearson and Tram, are you running with CONFIG_RELOCATABLE? I expect Tram has to be, since he uses kexec. tpearson? Because the coreboot trampoline makes assumptions that don't work with CONFIG_RELOCATABLE AFAICT.
Overall, a problem I see is that the coreboot trampoline code is built with the assumption that a trampoline can function apart from the kernel, i.e. that there is indepedence. I don't believe that is true any more.
See this in newer 4.x linuxes:
#ifdef CONFIG_RELOCATABLE
i.e. the trampoline code is now parameterized by the configuration. Our trampoline assumes the kernel starts at 0x100000.
I think the fix will be to remove the coreboot trampolilne code for bzimage and extract the needed trampoline code from the bzimage. I'll try that.
ron
I've been trying to find a problem in linux that makes it not boot when used as the payload in the KGPE-D16. The symptom is that I get no output at all on serial when linux starts.
I finally got it down to 1 commit today in linux.
commit 974f221c84b05b1dc2f5ea50dc16d2a9d1e95eda
Date: Thu Apr 28 17:09:04 2016 -0700
x86/boot: Move compressed kernel to the end of the decompression buffer
If I build a linux kernel up to but not including this commit, all is well. If I build with this commit, Linux is silent -- no serial output.
Anyway, I will be looking at this, but if you have solved it let me know.
thanks