[coreboot] Upstream coreboot/SeaBIOS on google/ninja -- no emmc, video
Matt DeVillier
matt.devillier at gmail.com
Mon May 16 16:17:14 CEST 2016
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
>
>
More information about the coreboot
mailing list