<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>I'm very concerned with compatibility. You can't guarantee that coreboot and payload match. And in case of mismatch you get a memory corruption that is very hard to trace. Can we please change signature of cbmem entry?</span></blockquote><div><br></div><div>I would rather allow older implementations to continue working as best as possible. Changing the signature would mean that an old payload (or 'cbmem' command line tool, etc.) couldn't interoperate at all with the console. The changes I made are as backwards-compatible as possible: in many cases (e.g. before the console rolled over once) the old payload will continue working just fine. If the console did roll over, the old payload can no longer append lines and may print existing contents out of order. It will never access invalid memory, though. (You may have been worried about bit 31 I'm setting in the "cursor" field, but all existing implementations were already required to check (cursor < size) before trusting the cursor to be accessible since the old console would continue counting characters even after the buffer filled up.) </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>You mentioned having trouble building GRUB. Can you detail those?</div><div>What do you mean by not having hardware supported by grub-coreboot? Grub-coreboot should work on all coreboot-supported boards.</div>
</blockquote></div><br></div><div class="gmail_extra">I am able to build it, I just had to figure out how and install some dependencies. But I tried booting it on an HP Chromebook 14 2013 (falco) and it doesn't seem to recognize my keyboard and will reboot a few seconds after displaying the GRUB console. (Most of the devices I have are ARM unfortunately, which I'm assuming it doesn't support since all the coreboot code is in i386 directories? And even if it did, it probably wouldn't have a keyboard driver for them either. I assume there's no way to make it run over the UART instead?)</div></div>