Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
Managed to get it working with serial input now. Found a few issues with my patch. Will send a new, tested version out. On Tue, Apr 25, 2017 at 11:48 AM, Julius Werner wrote: > Did you check that all implementations use unsigned? >> > > Yes, all the ones that I'm now aware of used unsigned, 32-bit. > > >> 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 >>> >> Is it PS2 or USB? Is at_keyboard included in the payload? >> > > It's a matrixed laptop keyboard. I believe the embedded controller does > 8042 emulation, but I'm not sure honestly. I'm an ARM guy and this was the > one old x86 machine I have lying around. I can try USB if I get it to not > crash long enough to type something. > > 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?) >>> >> terminal_input serial_com0 >> terminal_output serial_com0 >> In etc/grub.cfg >> > > I don't think I have an etc/grub.cfg... is there a way to compile that in > instead? > > >> Possibly the problem is that some module hangs. Can you try minimal GRUB >> without non-essential modules? >> >>> > How do I do that? Is there some configure flag? > > For reference, I did: > > ./autogen.sh > ./configure --with-platform=coreboot > make > make default_payload.elf > > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
> > Did you check that all implementations use unsigned? > Yes, all the ones that I'm now aware of used unsigned, 32-bit. > 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 >> > Is it PS2 or USB? Is at_keyboard included in the payload? > It's a matrixed laptop keyboard. I believe the embedded controller does 8042 emulation, but I'm not sure honestly. I'm an ARM guy and this was the one old x86 machine I have lying around. I can try USB if I get it to not crash long enough to type something. 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?) >> > terminal_input serial_com0 > terminal_output serial_com0 > In etc/grub.cfg > I don't think I have an etc/grub.cfg... is there a way to compile that in instead? > Possibly the problem is that some module hangs. Can you try minimal GRUB > without non-essential modules? > >> How do I do that? Is there some configure flag? For reference, I did: ./autogen.sh ./configure --with-platform=coreboot make make default_payload.elf -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
On Tue, Apr 25, 2017, 20:15 Julius Werner wrote: > 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? > > > 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.) > Did you check that all implementations use unsigned? > > >> You mentioned having trouble building GRUB. Can you detail those? >> What do you mean by not having hardware supported by grub-coreboot? >> Grub-coreboot should work on all coreboot-supported boards. >> > > 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 > Is it PS2 or USB? Is at_keyboard included in the payload? > 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? > Arm is in separate branch due to freeze. > 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?) > terminal_input serial_com0 terminal_output serial_com0 In etc/grub.cfg Possibly the problem is that some module hangs. Can you try minimal GRUB without non-essential modules? > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
> > 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? 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.) > You mentioned having trouble building GRUB. Can you detail those? > What do you mean by not having hardware supported by grub-coreboot? > Grub-coreboot should work on all coreboot-supported boards. > 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?) -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
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? You mentioned having trouble building GRUB. Can you detail those? What do you mean by not having hardware supported by grub-coreboot? Grub-coreboot should work on all coreboot-supported boards. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
[-seabios for the GRUB part of the thread] > Could you please also check, if GRUB’s CBMEM console driver, and the > the command cbmemc to display it need any updates? > Thanks, I wasn't aware that GRUB also had a driver for this. I'm happy to write a patch for it, but unfortunately I'm having some trouble testing it. I managed to build it after some effort, but I don't have hardware that supports it. Maybe you (or Vladimir?) could double-check that it works? > PS: Where can I get your S/MIME certificate, used to sign your email? > Sorry, that wasn't supposed to be there... I accidentally sent the first mail in here from the wrong account. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
[For the GRUB folks, this is about coreboot commit d67c6876 (Turn CBMEM console into a ring buffer that can persist across reboots) [1]. Julius’ message can be find in the coreboot list archive [2].] Dear Julius, Am Montag, den 10.04.2017, 15:50 -0700 schrieb Julius Werner: […] > The change may also cause some hiccups if you're using a newer version of > coreboot with an older version of cbmem (or SeaBIOS or whatever else reads > the console): it will not crash and it will still print the whole log, but > if the log has rolled over (into "ring buffer mode") it will print lines > out of order. This is unfortunately the best I can do with the way current > readers are implemented. I'm of course also updating the code for cbmem so > as soon as you deploy the new version it will be able to display buffers > from both old and new coreboot versions correctly. (I'll send patches to > align SeaBIOS and the Linux memconsole driver in the same manner as soon as > the coreboot patch is approved.) Could you please also check, if GRUB’s CBMEM console driver, and the the command cbmemc to display it need any updates? Thanks, Paul PS: Where can I get your S/MIME certificate, used to sign your email? [1] https://review.coreboot.org/18301 [2] https://mail.coreboot.org/pipermail/coreboot/2017-April/083950.html signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
> > Is it possible to figure whenever the cbmem buffer supports rollover or > not, so a updated seabios version can work correctly with both old and > new coreboot? > Not explicitly, but it should still work fine with both versions. The old coreboot can only either not fill up the buffer or fill up the buffer. If it fills up the buffer I can make SeaBIOS detect that (it would look different from rollover with the new code) and just not append anything else, just as it would do right now. If it did not fill the buffer, SeaBIOS can just continue appending there and roll over if it needs to (the buffer format stays 100% the same before the first roll over). Then on the next boot, an old version of coreboot will just unconditionally reinitialize the buffer anyway. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
Hi, > Right, sorry, I confused something while writing the explanation > there. Nevertheless, the SeaBIOS code will require a small adjustment > (same as the libpayload driver in the patch I linked) to continue > appending correctly after the log has rolled over, and I'll provide > that patch. Is it possible to figure whenever the cbmem buffer supports rollover or not, so a updated seabios version can work correctly with both old and new coreboot? cheers, Gerd -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
> > seabios doesn't read the log, instead it'll append its own messages. > Which I expect will continue to work fine, except when it hits the end > of the log buffer, where seabios will simply stop logging instead of > rolling over. > Right, sorry, I confused something while writing the explanation there. Nevertheless, the SeaBIOS code will require a small adjustment (same as the libpayload driver in the patch I linked) to continue appending correctly after the log has rolled over, and I'll provide that patch. > Will the ability to change the 'Room allocated for console output in > CBMEM' size still be available (and functional) for those need to view the > full console output due to the addition of debugging/tracing lines? > Yes, nothing changes about where the console buffer space is allocated. You can continue to increase the size through Kconfig. I'm just changing how it gets used. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
Hello, Will the ability to change the 'Room allocated for console output in CBMEM' size still be available (and functional) for those need to view the full console output due to the addition of debugging/tracing lines? HN From: coreboot on behalf of Julius Werner via coreboot Sent: Monday, April 10, 2017 3:50 PM To: Coreboot; seab...@seabios.org Subject: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer Hi folks, I'm planning to make some changes to coreboot's CBMEM console with https://review.coreboot.org/#/c/18301 that should make it easier to debug problems spanning multiple reboots. I'm trying my best to avoid breaking previous behavior and keeping it compatible with older code, but there'll be some edge cases so Aaron suggested I announce it here. The basic idea is to turn the console into a persistent ring buffer. If coreboot finds an already initialized console in memory during boot, it will just continue appending to it rather than begin writing from the start of the buffer again. This means that if you run cbmem -c, the most recent boot will always be at the bottom of the output, and you can scroll further up to see logs from the boot before that (assuming you didn't lose DRAM power or something). It may also give some runtime firmware components (like we have on ARM64) a good place to log stuff and persist crash dumps in the future. The console buffer will fill up eventually with enough reboots, so when that happens we will start discarding the oldest lines from the log. This means the behavior if the log buffer is too small for even a single full boot will become slightly different: we'll only keep the latest lines, whereas previously we would only keep the earliest lines and a counter of dropped characters. I don't think this should be an issue though, since we normally should have enough buffer to fit a whole boot anyway (the default is currently 128KB which ought to be enough for any board). The change may also cause some hiccups if you're using a newer version of coreboot with an older version of cbmem (or SeaBIOS or whatever else reads the console): it will not crash and it will still print the whole log, but if the log has rolled over (into "ring buffer mode") it will print lines out of order. This is unfortunately the best I can do with the way current readers are implemented. I'm of course also updating the code for cbmem so as soon as you deploy the new version it will be able to display buffers from both old and new coreboot versions correctly. (I'll send patches to align SeaBIOS and the Linux memconsole driver in the same manner as soon as the coreboot patch is approved.) Let me know if you have any concerns about this. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
Hi folks, I'm planning to make some changes to coreboot's CBMEM console with https://review.coreboot.org/#/c/18301 that should make it easier to debug problems spanning multiple reboots. I'm trying my best to avoid breaking previous behavior and keeping it compatible with older code, but there'll be some edge cases so Aaron suggested I announce it here. The basic idea is to turn the console into a persistent ring buffer. If coreboot finds an already initialized console in memory during boot, it will just continue appending to it rather than begin writing from the start of the buffer again. This means that if you run cbmem -c, the most recent boot will always be at the bottom of the output, and you can scroll further up to see logs from the boot before that (assuming you didn't lose DRAM power or something). It may also give some runtime firmware components (like we have on ARM64) a good place to log stuff and persist crash dumps in the future. The console buffer will fill up eventually with enough reboots, so when that happens we will start discarding the oldest lines from the log. This means the behavior if the log buffer is too small for even a single full boot will become slightly different: we'll only keep the latest lines, whereas previously we would only keep the earliest lines and a counter of dropped characters. I don't think this should be an issue though, since we normally should have enough buffer to fit a whole boot anyway (the default is currently 128KB which ought to be enough for any board). The change may also cause some hiccups if you're using a newer version of coreboot with an older version of cbmem (or SeaBIOS or whatever else reads the console): it will not crash and it will still print the whole log, but if the log has rolled over (into "ring buffer mode") it will print lines out of order. This is unfortunately the best I can do with the way current readers are implemented. I'm of course also updating the code for cbmem so as soon as you deploy the new version it will be able to display buffers from both old and new coreboot versions correctly. (I'll send patches to align SeaBIOS and the Linux memconsole driver in the same manner as soon as the coreboot patch is approved.) Let me know if you have any concerns about this. smime.p7s Description: S/MIME Cryptographic Signature -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
