Here are my comments to what you wrote to me:

On Mon, Nov 28, 2016 at 7:59 PM, Grigore Lupescu <> wrote:
Hello Zoran,

[1-3] I am using the latest Ubuntu 16.04 LTS x64 desktop, 4.4 kernel. 

Perfect. Got it. Good to know. 16.04 LTS support back-ports to kernel 4.4 APIs most of the newer features exceeding 4.4 version for some time (this is very important info to/for me, never mind).
[4] I don't know exactly if it's x64 or x86. I have no control over AMI BIOS since it's just a binary I flash into the SPI ROM, which supports the board.

Even if it is a binary, you should be able to enter it (CMOS) pressing at the very beginning of the boot <esc> or <F2> (maybe <F1>, Lenovo 420T supports <F1>, as example), or simultaneously - alternately both of them, one after another (NOT both at the same time). Then you can read the BIOS version from system BIOS page. Maybe version says what is the architecture. Other that that, it is bloody hard to tell what BIOS (32 or 64) you have. It is easier if you do have UEFI BIOS, but you must have/gain access to EFI shell, which is another problem, another dimension.
[5] I boot Linux using legacy mode (in AMI, the Linux was installed for legacy boot on the HDD/SSD which connects via USB - USBtoSATA)

You see... BIOS is a beast. With BIOS, if you have already attached HDMI monitor, BIOS should/must detect this and record, and pass such info to OS, somehow (very long story). Regardless what your GRUB2 supports (or, at least, this is my naive understanding).

If your BIOS is a legacy one, guess who is doing this detection? Which part of BIOS?! I'll tell this secret (ONLY) to you: vBIOS! ;-)
[6] I'm not sure. So I have the following checked:
- Run VGA Option ROMs, Native Mode
- Add a VGA BIOS image -> 3rdparty/blobs.../VBIOS.bin
- Set framebuffer resolution (any, without this + above, I have no HDMI output)

The secret, I'll whisper only to you again... You MUST add to Coreboot vBIOS as video component, because vBIOS will pass to Linux so-called VBT (the same it does above, being part of BIOS), where these info are recorded (Coreboot, no Coreboot, does NOT matter, but for Linux video, vBIOS component extremely DOES matter).

(for UEFI boot, this works completely differently... Just tiny note)
[7] It's the same one referenced from Coreboot in the external payloads - GRUB 2.02 beta3.

I apologize. I made here a mistake. Forgot to mention - outdated Coreboot GRUB2 payload. Here is a naive exercise to be done:
Please, program back BIOS into flash and boot your system (Ubuntu 16.04). Please, stop in GRUB2, after BIOS, and inspect the Ubuntu 16.04 LTS GRUB2 data. What is the GRUB2 version?

And, as you have said: you are able (also) to execute in BIOS GRUB the following (?!):
grub> set root=(hd0,gpt2)
grub> linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda2
grub> initrd /boot/initrd.img-3.13.0-29-generic
grub> boot

Can you do this with the kernel 4.4??? Exact the same (above) commands? And from where you do have 3.13? Also as entry in grub.cfg? How/from where? Or, maybe... You use different HDD/SSD for Coreboot purposes?!

And if you use the same HDD/SSD, how do you have two different kernels you are (after all) executing:
[A] Using GRUB2 as Coreboot payload as GRUB 2.02 beta3, executing kernel 3.13???
[B] Using GRUB2 (hidden behind MBR on the HDD/SSD) executing kernel 4.4???

I did not get out of these emails the complete picture, I admit... :-(

From your view where would the overflow / boot problems come from ?

Still not able to answer this question, since I do not have clear understanding what you actually do? I am trying...

Thank you,
Thank you,

On Mon, Nov 28, 2016 at 6:31 PM, Zoran Stojsavljevic <> wrote:
Hello Grigore,

I have here some dummy questions (forgive me for my ignorance), but I need to ask them just for the sake of curiosity (maybe, after all, we can get somewhere if I articulate questions in the right direction/right format for this problem):

> If I put a proprietary AMI BIOS, GRUB2 works without issue in gfxterm mode and boots Linux without issue.

[1] What Linux architecture are you using (32 or 64)?
[2] Which Linux distro?
[3] Which kernel version?

If you put AMI BIOS, the following questions I would like to know:

[4] Are you using 32 or 64 BIOS?
[5] Which mode are you using for booting (legacy/CSM ON or UEFI/CSM OFF)?
[6] In the accordance with [5], what video component you have set with CMOS: vBIOS or GOP driver?

Not sure, but it seems to me that you are using too old/outdated GRUB2 version (or maybe I am also mistaken)?
[7] Could you tell us, which GRUB2 version you are using?

Thank you,

On Mon, Nov 28, 2016 at 7:13 PM, Grigore Lupescu via coreboot <> wrote:

I am trying to run Linux through the GRUB2 payload. I am not tied to GRUB2 but it's the only payload that gives me HDMI output (board has no serial port) using Coreboot and AMD FT3B-LC.

I have the latest Coreboot sources, have set config accordingly (e.g. CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME="DB-FT3b-LC"...), getting an image on HDMI and the GRUB2 payload is executing.
In GRUB2 payload I seem to have an overflow issue possibly related to the vga_text mode. If I put a proprietary AMI BIOS, GRUB2 works without issue in gfxterm mode and boots Linux without issue.

Using Coreboot every time the screen gets full of text, GRUB2 re-executes. If I though set the terminal_output to cbmemc then commands would execute but Linux still fails to execute - at the end GRUB2 would restart.

Also the GRUB2 payload on Coreboot does see the drive/files and attempts to execute - I looks like a GRUB2/Coreboot config/code problem.

I execute the below in GRUB2 (which work on AMI BIOS + GRUB2).
grub> set root=(hd0,gpt2)
grub> linux /boot/vmlinuz-3.13.0-29-generic root=/dev/sda2
grub> initrd /boot/initrd.img-3.13.0-29-generic
grub> boot

1. Would anyone have any recommendation about the overflow in GRUB2 payload ? - related to Coreboot.
2. Any suggestions on booting Linux given this board's limitations on output (HDMI only) ?

Thank you,

coreboot mailing list: