<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 25, 2017, 20:15 Julius Werner <<a href="mailto:jwerner@chromium.org">jwerner@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></blockquote></div><div>Did you check that all implementations use unsigned?</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></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</div></div></blockquote></div><div>Is it PS2 or USB? Is at_keyboard included in the payload?</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"> 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?</div></div></blockquote></div><div>Arm is in separate branch due to freeze.</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"> 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></blockquote></div><div>terminal_input serial_com0</div><div>terminal_output serial_com0</div><div>In etc/grub.cfg</div><div><br></div><div>Possibly the problem is that some module hangs. Can you try minimal GRUB without non-essential modules?</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>