<div dir="ltr"><div><span style="font-size:12.8px">Hello Matt,</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I would like to thank you for the reply. I learned something out of it, indeed. So far, I need to think more on your answers, since immediately I do not have any thoughts (I am blank). Old dummy cat... Need some time. :-)</span></div><span style="font-size:12.8px"><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">But I can answer on the last one comment... This one:</span></div><div><span style="font-size:12.8px"><br></span></div>> I'm not quite sure what you're saying here. If you mean that I did not have coreboot perform the video init, then</span><div><span style="font-size:12.8px">> I did try it both ways. On all the other boxes (ie, no built-in display) I've upstreamed, it's not been necessary to</span></div><div><span style="font-size:12.8px">> have coreboot run the vbios, only SeaBIOS.</span><br><div><span style="font-size:12.8px"><br></span></div></div><div><span style="font-size:12.8px">Here is what you perfectly explained, and I did not know (at least, I know now): I suggested to you to use vBIOS with Coreboot, and make vBIOS init there, but you denied my thoughts, saying that you just need to integrate vBIOS into SeaBIOS (excuse me for my ignorance, I did not know that).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">In other words, SeaBIOS is one, enough to do vBIOS init, so vBIOS INT 0x15 and VBT will be passed accordingly to Linux. Am I right in my thoughts?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Why it does not work, namely:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> For the video output, the same vgabios file is being used as stock CrOS, and same SeaBIOS payload. The i915</span></div><div><span style="font-size:12.8px">> kernel driver reports that no displays are connected, and there are some errors in the drm module just prior. I</span></div><div><span style="font-size:12.8px">> tested with a few different flavors of linux as well as Windows 10, to be certain it wasn't driver-related.</span><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Again... I need to think about this. I will come to you back!</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thank you,</span></div><div><span style="font-size:12.8px">Zoran</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 16, 2016 at 4:17 PM, Matt DeVillier <span dir="ltr"><<a href="mailto:matt.devillier@gmail.com" target="_blank">matt.devillier@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Zoran,<br>
<br>
appreciate the offer, and I'll try to clarify things:<span class=""><br>
<br>
On 5/16/2016 5:07 AM, Zoran Stojsavljevic wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Matt,<br>
<br>
I'll try to help you... Please, do understand that I did not get well what really you are trying to do. Let us do one step at the time.<br>
</blockquote></span>
I'm trying to get the board google/ninja (a Baytrail-based Chromebox) working with upstream coreboot. Original google source here:<br>
<a href="https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-ninja-5216.383.B" rel="noreferrer" target="_blank">https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-ninja-5216.383.B</a><br>
I've already upstreamed several other google boards so I'm familiar with the process :)<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This step: 2) video output works properly for SeaBIOS and grub/syslinux, but output is disabled once the OS / kernel driver loads.<br>
_______<br>
<br>
What I am getting from this email is the following (correct me if I am wrong): BYT-FSP -> Coreboot -> (payload) SeaBIOS -> grub (2.0???) -> Linux kernel 3/4.x.y (?).<br>
</blockquote></span>
I'm not using FSP, using soc/intel/baytrail (not fsp_baytrail) since the board was not originally set up to do so, and would require a bit of reworking (without any obvious benefit). So coreboot->SeaBIOS (running vbios)->grub/syslinux->linux kernel 3/4.x<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Now. If you use as payload SeaBIOS, my best understanding is that you'll use CSM (Compatibility Support Mode). So, in other words, you'll use (if you will?) in Coreboot vBIOS (not GOP driver). Now, furthermore, you MUST use vBIOS, since you are using SeaBIOS. And Linux will use vBIOS (not GOP driver), since you'll pass INT 0x15 mechanisms for Linux GFX (using mandatory vBIOS passed from Coreboot), enforced from SeaBIOS - CSM?!<br>
</blockquote></span>
CSM mode is only needed when Tianocore is the primary payload, since SeaBIOS is primary it is simply set up as a coreboot payload. I plan to use Tiancore + SeaBIOS/CSM eventually, but wanted SeaBIOS alone working first (since that's all my firmware releases to date have been). coreboot isn't running the vbios, just SeaBIOS (though I tried it both ways, with coreboot running the vbios first; there was no change).<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The question here is the following: why, for the change, you do not use as payload TianoCore? This one is UEFI compatible, and very well suits UEFI compliant Linux? In other words, you will use Linux as UEFI compliant/compatible OS. Compliant to Tiano Core, which brings to you UEFI features (initialized by default with Linux). Simply and plain... And see what will happen?<br>
</blockquote></span>
I actually did try Tianocore as the primary payload and had the exact same issues, so I went back to SeaBIOS since I know that works in conjunction with the factory firmware.<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Final line: I suspect, you did not built-in in Coreboot vBIOS package and vBIOS init (just serial output), which is, using SeaBIOS payload (CSM mechanism), I guess, mandatory (for Linux to overtake/inherit legacy, to work with GFX).<br>
<br>
Thank you,<br>
Zoran<br>
</blockquote></span>
I'm not quite sure what you're saying here. If you mean that I did not have coreboot perform the video init, then I did try it both ways. On all the other boxes (ie, no built-in display) I've upstreamed, it's not been necessary to have coreboot run the vbios, only SeaBIOS.<br>
<br>
thanks,<br>
Matt<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
On Sun, May 15, 2016 at 12:19 AM, Matt DeVillier <<a href="mailto:matt.devillier@gmail.com" target="_blank">matt.devillier@gmail.com</a> <mailto:<a href="mailto:matt.devillier@gmail.com" target="_blank">matt.devillier@gmail.com</a>>> wrote:<br>
<br>
Greetings all! Currently I'm working on getting upstream coreboot<br>
+ SeaBIOS working on a Baytrail-based ChromeOS device (NINJA /<br>
AOpen Chromebox commerical). After resolving some config issues<br>
which prevented the board from booting, I'm left with two issues<br>
on which I'm stuck:<br>
<br>
1) the internal emmc / sdhci controller fails to initialize, and<br>
is unavailable for boot or OS installation<br>
2) video output works properly for SeaBIOS and grub/syslinux, but<br>
output is disabled once the OS / kernel driver loads<br>
<br>
For the emmc, cbmem shows that the sdhci controller is timing out<br>
after setting the initial frequency, somewhere after line 410 of<br>
seabios/src/hw/sdcard.c. Since the same exact SeaBIOS payload<br>
works properly with the stock ChromeOS firmware (in both the<br>
RW_LEGACY and BOOT_STUB slots), I suspect that the issue is with<br>
coreboot, but the SoC init is pretty much identical between<br>
upstream and NINJA's CrOS branch (save for a few base addresses<br>
and offset calculations), so not sure where to start looking. I've also tried putting the sdhci controller back into PCI mode<br>
(vs ACPI) which had no effect.<br>
<br>
For the video output, the same vgabios file is being used as stock<br>
CrOS, and same SeaBIOS payload. The i915 kernel driver reports<br>
that no displays are connected, and there are some errors in the<br>
drm module just prior. I tested with a few different flavors of<br>
linux as well as Windows 10, to be certain it wasn't driver-related.<br>
<br>
Attached are the cbmem and kernel logs from both working (stock<br>
CroS firmware + upstream SeaBIOS/BOOT_STUB) and non-working<br>
(upstream coreboot+SeaBIOS) cases.<br>
<br>
As the board hasn't been officially upstreamed yet (something I<br>
will do once these issues are resolved), source can be found in my<br>
github repo here (it's just 3 commits on top of the current master<br>
branch): <a href="https://github.com/MattDevo/coreboot/tree/ninja_upstream" rel="noreferrer" target="_blank">https://github.com/MattDevo/coreboot/tree/ninja_upstream</a><br>
<br>
Hopefully someone can point me in the right direction here :)<br>
<br>
cheers,<br>
Matt<br>
<br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br></div></div>
<mailto:<a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a>><br>
<a href="https://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://www.coreboot.org/mailman/listinfo/coreboot</a><br>
<br>
<br>
</blockquote>
<br>
</blockquote></div><br></div>