On Thu, Jul 3, 2014 at 4:18 PM, David Hendricks <dhendrix(a)google.com> wrote:
> Necromancing this thread...
>
> Sage has a patch to *optionally* use a serial console log in
> board_status.sh: http://review.coreboot.org/#/c/6094/
>
> Earlier objections to such an approach seemed to stem from either:
> - Desire to use cbmem console instead. A fine idea, but on some platforms
> (especially those which use AGESA) a lot of information gets spit out to
> the console before cbmem is available. Re-factoring to make cbmem init
> happen earlier is unfeasible AFAICT.
>
> - Avoid confusing cbmem console log and other logs. This can be easily
> solved by using a different filename. I personally think it's best to only
> upload one log (whichever is most useful) and avoid polluting the web UI
> with redundant files. But I could live with multiple console logs if others
> feel strongly.
>
> Seeing as how only a small handful of people currently actually use this
> utility anyway, I'm inclined to think it's best to make the utility more
> useful for a major coreboot contributor get some more status reports
> uploaded.
>
>
>
Yes, please, let's just get this done. I think Sage's arguments make lots
of sense.
ron
I've added a routine to grab the boot log for the board-status database
from a serial device. I didn't realize at the time that it had already
been voted down on the mailing list - I was told that if I wanted this
to go in, I should appeal to the mailing list.
Please see the patch here: http://review.coreboot.org/#/c/6094/
Since there are currently some platforms that do not yet support the
cbmem console, I would like to be able to grab the console from a serial
device on the host side. I'm happy to mark it as coming from the serial
device, and note in the script that by preference the cbmem console log
should be used. I am fully prepared to add text to the script
belittling anyone who has to fall back to such plebian measures or any
other punishments that are deemed to be required.
Other possible alternatives I see to having the script read the console
from a serial device:
1) Add a command line option to the board_status.sh script that allows
the user to point to a file already containing the console log.
2) Add a command line option to allow the console log to just be skipped
and upload the rest of the data without it.
3) Simply wait until the boards support cbmem console log and not push
anything about those platforms until that point.
4) Collect the data manually and push it into the repo without the
board_status.sh script being used.
My thought is that having the script grab the data from the serial port
is better than any of these options, but I'm sure there are other
possibilities that I've missed.
(Apologies if my tone offends anyone - I'm told that when I try to be
funny, it comes across as condecension. I guess that's why I'm a
programmer and not a comedian.) <-- my new tagline.
Martin
On 10.02.2014 23:47, David Hendricks wrote:
> On Sun, Feb 9, 2014 at 4:50 AM, Paul Menzel
> <paulepanter(a)users.sourceforge.net
> <mailto:paulepanter@users.sourceforge.net>> wrote:
>
> Dear coreboot folks,
>
>
> currently no coreboot messages are stored for boards not supporting
> CBMEM console (or where this option is disabled (currently by default))
> or no coreboot *romstage* messages are stored for boards, where the data
> cannot be preserved (passed to ramstage).
>
> Using the serial (or USB) console all these messages can be captured
> with no problem, so I propose to just add these captured messages into
> the file `serial_console.txt`. Of course this file probably contains
> also the payload and (Linux) kernel log, but I think that is fine.
>
> SeaBIOS’ `readserial.py` should be used for capturing the messages as it
> adds time stamps.
>
> Scripting this is going to be hard, as the log is captured on a
> different system. So for now I propose to add it manually.
>
>
> I don't think the script itself should be responsible for collecting
> serial output. Instead, how about adding an argument to override the
> default behavior of running "cbmem -c" on the target so that the user
> can pass in a filename? The user will simply capture the serial output
> using whatever tool they like, dump the output to a text file, and run
> the script with an argument to use the file instead of calling "cbmem
> -c". Here is a proof-of-concept: http://review.coreboot.org/#/c/5191 .
>
This requires user to do right manipulations. While keyboard and chair
are usually fine, the space between them exhibits strong bug-inducing
properties. The idea of the script is to reduce a possibility of user
error creating strange reports. In this case the common erro I expect is
using a stale file fom some other version. It's a particularly nasty one
as at first glance in may look fine but would be almost useless to track
how details changed from one submit to the next. If we let user supply
files at all, it should be added to report, not replace files, and it
should have some prefix to clearly indicate that user was involved in
creating them. E.g. user_serial_log.txt
> But in general I think I agree with Vladimir. CBMEM console should be
> supported and if not then that should be fixed.
>
> --
> David Hendricks (dhendrix)
> Systems Software Engineer, Google Inc.
>
>
as a first pass, did you burn coreboot for the wrong board just to see if
you got anything al all on serial? I just went through this process on
a different board and that was my starting point, as it is for many.
ron
[+jiming.sun(a)intel.com]
On Wed, Jul 2, 2014 at 5:58 PM, Paul Wilcox-Baker <wilcoxbaker(a)gmail.com>
wrote:
> Dear coreboot,
>
> We have done some more research on the differences between the
> supported Haswell processors and PCH parts and what we have
> used in our design.
>
> We have designed a board with the E3-1268Lv3 device with the
> 82C226 PCH part. It appears that all Haswell devices that
> have been ported are the mobile variety where the PCH device is
> packaged with the processor.
>
> Do the files to support the parts we wish to use exist anywhere
> else? Is there a repository for non-GPL code perhaps?
>
> Can we use any of the coreboot utilities on a system with the
> same processor and PCH device to generate code for a coreboot
> that will support this CPU and PCH?
>
> Does Intel have the required files to generate coreboot for the
> processor and PCH part that we wish to use? If they do how do
> we get them? Perhaps they have some coreboot code that can be
> obtained under NDA or licence.
>
> Thanks, Paul.
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
Dear coreboot,
We have done some more research on the differences between the
supported Haswell processors and PCH parts and what we have
used in our design.
We have designed a board with the E3-1268Lv3 device with the
82C226 PCH part. It appears that all Haswell devices that
have been ported are the mobile variety where the PCH device is
packaged with the processor.
Do the files to support the parts we wish to use exist anywhere
else? Is there a repository for non-GPL code perhaps?
Can we use any of the coreboot utilities on a system with the
same processor and PCH device to generate code for a coreboot
that will support this CPU and PCH?
Does Intel have the required files to generate coreboot for the
processor and PCH part that we wish to use? If they do how do
we get them? Perhaps they have some coreboot code that can be
obtained under NDA or licence.
Thanks, Paul.
Am 02.07.2014 16:23, schrieb Charles Devereaux:
> I use linux-3.10.45 and systemd-stable v210, and you can see the result
> from a systemd-analyze - about 2.8 seconds after coreboot+grub, which
> take about 3 seconds.
An extension to this project would be to teach linux/systemd to read our
timestamps from cbmem for a full breakdown.
Patrick
While a couple of the Haswell-based ChromeBooks have been added to upstream coreboot, but have not heard of anyone with them actually running yet. I know John Lewis had tried to get the HP ChromeBook 14 (falco) going but was not successful (though he does have the Chromium/falco branch working), and I assume the same is true for the Acer C720 (peppy) too, as they are nearly identical. Looking at it briefly, I'd suspect the issues are related to the display init or Google's EC, but haven't had a chance to play with one myself yet.
I have upstream coreboot running on the Haswell-based Asus ChromeBox (panther), and have submitted patches for it, but they have not yet been accepted/merged in. Also works for the nearly-identical HP ChromeBox (zako). I can throw my branch up on github in the meantime if would be useful, but that's where I'd recommend starting (vs the ChromeBooks).
cheers,
Matt
On 7/2/2014 11:09 AM, ron minnich wrote:
> As always, when doing a new board, get a system that is known to work with coreboot and has your chipset in it. You should get several (never just one!) of the haswell chromebooks, build coreboot, make sure you can make it all work, then try the port to your board.
>
> ron
>
>
> On Wed, Jul 2, 2014 at 12:11 AM, David Hendricks <david.hendricks(a)gmail.com <mailto:david.hendricks@gmail.com>> wrote:
>
> On Tue, Jul 1, 2014 at 5:50 PM, Paul Wilcox-Baker <wilcoxbaker(a)gmail.com <mailto:wilcoxbaker@gmail.com>> wrote:
>
> Dear coreboot,
>
> We are interested in coreboot for the Intel Haswell processors.
> coreboot appears to be used in the Acer C720 and HP Chromebooks
> that use Haswell processors. I see no reference to this processor,
> or to these products in the source code that I downloaded recently.
>
>
> Are you sure? 'git grep haswell' turns up 160 references as of 931c1d.
>
>
> There is also no reference to these products in the "products
> supported" web page of coreboot.org <http://coreboot.org>.
>
>
> http://www.coreboot.org/Supported_Motherboards#Laptops
>
>
> We are developing hardware using the Haswell processor and 82C226
> PCH part. How do we port coreboot to these devices? As Acer and HP
> have done it, it's obviously possible.
>
>
> Start by grepping for NORTHBRIDGE_INTEL_HASWELL in the source tree.
>
> Note: The following URL has a codename <--> marketing name decoder for Chromebooks: http://www.chromium.org/chromium-os/developer-information-for-chrome-os-dev…
>
> Any advice gratefully received!
>
> Thanks, Paul.
>
> --
> coreboot mailing list: coreboot(a)coreboot.org <mailto:coreboot@coreboot.org>
> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> coreboot mailing list: coreboot(a)coreboot.org <mailto:coreboot@coreboot.org>
> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
>
