[coreboot] Upstream coreboot/SeaBIOS on google/ninja -- no emmc, video

[Matt DeVillier]

Hi Zoran,

appreciate the offer, and I'll try to clarify things:

On 5/16/2016 5:07 AM, Zoran Stojsavljevic wrote:
> Hello Matt,
>
> 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.
I'm trying to get the board google/ninja (a Baytrail-based Chromebox) 
working with upstream coreboot.  Original google source here:
https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/firmware-ninja-5216.383.B
I've already upstreamed several other google boards so I'm familiar with 
the process :)
>
> This step: 2) video output works properly for SeaBIOS and 
> grub/syslinux, but output is disabled once the OS / kernel driver loads.
> _______
>
> 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 (?).
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
>
> 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?!
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).
>
> 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?
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.
>
> 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).
>
> Thank you,
> Zoran
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.

thanks,
Matt
>
> On Sun, May 15, 2016 at 12:19 AM, Matt DeVillier 
> <matt.devillier at gmail.com <mailto:matt.devillier at gmail.com>> wrote:
>
>     Greetings all!  Currently I'm working on getting upstream coreboot
>     + SeaBIOS working on a Baytrail-based ChromeOS device (NINJA /
>     AOpen Chromebox commerical).  After resolving some config issues
>     which prevented the board from booting, I'm left with two issues
>     on which I'm stuck:
>
>     1) the internal emmc / sdhci controller fails to initialize, and
>     is unavailable for boot or OS installation
>     2) video output works properly for SeaBIOS and grub/syslinux, but
>     output is disabled once the OS / kernel driver loads
>
>     For the emmc, cbmem shows that the sdhci controller is timing out
>     after setting the initial frequency, somewhere after line 410 of
>     seabios/src/hw/sdcard.c.  Since the same exact SeaBIOS payload
>     works properly with the stock ChromeOS firmware (in both the
>     RW_LEGACY and BOOT_STUB slots), I suspect that the issue is with
>     coreboot, but the SoC init is pretty much identical between
>     upstream and NINJA's CrOS branch (save for a few base addresses
>     and offset calculations), so not sure where to start looking. 
>     I've also tried putting the sdhci controller back into PCI mode
>     (vs ACPI) which had no effect.
>
>     For the video output, the same vgabios file is being used as stock
>     CrOS, and same SeaBIOS payload.  The i915 kernel driver reports
>     that no displays are connected, and there are some errors in the
>     drm module just prior.  I tested with a few different flavors of
>     linux as well as Windows 10, to be certain it wasn't driver-related.
>
>     Attached are the cbmem and kernel logs from both working (stock
>     CroS firmware + upstream SeaBIOS/BOOT_STUB) and non-working
>     (upstream coreboot+SeaBIOS) cases.
>
>     As the board hasn't been officially upstreamed yet (something I
>     will do once these issues are resolved), source can be found in my
>     github repo here (it's just 3 commits on top of the current master
>     branch): https://github.com/MattDevo/coreboot/tree/ninja_upstream
>
>     Hopefully someone can point me in the right direction here :)
>
>     cheers,
>     Matt
>
>     --
>     coreboot mailing list: coreboot at coreboot.org
>     <mailto:coreboot at coreboot.org>
>     https://www.coreboot.org/mailman/listinfo/coreboot
>
>