[coreboot] Execute Linux on AMD DB-FT3b-LC through GRUB2

Fri Dec 2 16:24:29 CET 2016

Hi Zoran,

Thanks for your suggestions - it may not be vBIOS but it's most likely
somewhere around there.

I updated the VBIOS from Coreboot (~2014) with the newest one from AMD
(~2015) with no impact on the behavior.
At this point I think the Coreboot settings for the platform may cause this
i.e. for some reason *vga_text* is chosen over *gfxterm* which is not even
configured but barely exists.

I have though managed to improve the status of the *vga_text* mode. So
GRUB2 was restarting when reaching the end of the screen. I traced this to
the *screen_read_char* which is issued when the *inc_y* == ROWS (this call
would break GRUB2). I didn't go even further with the debug though. I just
clear the screen and set grub_curr_pos.y to 0 and by using set pager=1 I
can browse with enter through all the output page by page. It's not ideal
but it was fast and practical.

Linux though still doesn't boot. I am currently looking why the vga_text
mode is selected over gfxterm which is not even configured properly.

Thanks,
Grigore

On Wed, Nov 30, 2016 at 7:15 PM, Zoran Stojsavljevic <
zoran.stojsavljevic at gmail.com> wrote:

> Hello Grigore,
>
> Did not abandon you ("Dr. House" lookalike, same age, same attitude). I
> though about the issue... Gave it hard try/thought! At least, I have tried.
> And here is what I came with...
>
> > Differences on GRUB2 environment:
> > AMI BIOS + *GRUB2.02beta2-36ubuntu3.1* => terminal_output=*gfxterm*,
> see USB-SATA SSD as (*hd0*), (*hd0*, gpt0).., works
> > both on USB2.0 and USB3.0.
> > Coreboot + *GRUB2.02beta3* => terminal_output=*vga_text*, see USB-SATA
> SSD as (*usb0*), (*usb0*, gpt0).., works only on USB2.0.
>
> So... Here are bullet points:
> [1] Above: you are telling/writing to me that Coreboot has newest GRUB2 SW
> than Ubuntu 16.04 LTS, Linux ft3b-lc 4.4.0-31-generic??? Question to you:
> are you sure? Please, check again?
> [2] *VERY/CRITICALLY important:* Are you sure that in BOTH cases above
> you are using *THE SAME vBIOS *component?
> In other words, you should go to:  https://ami.com/products/
> bios-uefi-tools-and-utilities/bios-uefi-utilities/... And try to extract
> vBIOS out of your AMI BIOS you are alternately using to test... And
> replace/swap one (you are using currently) in Coreboot.
>
> Good luck! :-)
> Zoran
> _______
>
> On Tue, Nov 29, 2016 at 2:44 PM, Grigore Lupescu <grigore at arista.com>
> wrote:
>
>> Hello Zoran,
>> First of all thank you very much for your feedback - any idea would be
>> worth trying.
>>
>> I am sorry about the mixup by putting the 3.13 commands there (it was 4.4
>> actually). I use TAB press to get the actual version on the SSD drive
>> (4.4.0-31) and those exact commands. So my bad on the last email, these are
>> the actual ones:
>>
>> grub> set root=(hd0,gpt2)
>> grub> linux /boot/vmlinuz-4.4...-generic root=/dev/sda2
>> grub> initrd /boot/initrd.img-4.4...-generic
>> grub> boot
>>
>> So I am trying to boot from an SSD with Linux connected to a USB port -
>> why I am doing this ? :) because the board has a dedicated embedded style
>> power supply and 1 SATA cable, hence even though I can connect the SSD
>> directly I cannot power it - so I use a USB to SATA drive where I have the
>> SSD plugged in (and legacy Ubuntu Linux x64 4.4 on it).
>>
>> Below are the full details of the AMI BIOS, Linux OS, Coreboot I am
>> trying to boot over Coreboot (latest). So looking at these ++ previous ones
>> it looks like vBIOS is in both.
>>
>> AMI BIOS 2.17.1246 Copyright 2015
>> Core Version 4.6.5.4
>> UEFI 2.3.1; PI 1.2
>> Project Version 1ASNG 0.02 x64
>> Chipset->GFX Configuration
>> IGD VBIOS Version ATOMBIOSBK-AMD VERO15.042.000.002.0000000
>> Advanced->CPU Configuration
>> AGESA Version 1.0.0.5
>> terminal_output: *gfxterm*
>>
>> Ubuntu 16.04 LTS, Linux ft3b-lc 4.4.0-31-generic #50 Ubuntu SMP Wed Jul
>> 13 UTC 2016 x86_64
>> GNU GRUB 2.02~beta2-36ubuntu3.1
>>
>> Coreboot (latest branch)
>> 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.
>> terminal_output: *vga_text*
>> GRUB 2.02 beta3
>>
>> Differences on GRUB2 environment:
>> AMI BIOS + GRUB2.02beta2-36ubuntu3.1 => terminal_output=*gfxterm*, see
>> USB-SATA SSD as (*hd0*), (*hd0*, gpt0).., works both on USB2.0 and
>> USB3.0.
>> Coreboot + GRUB2.02beta3 => terminal_output=*vga_text*, see USB-SATA SSD
>> as (*usb0*), (*usb0*, gpt0).., works only on USB2.0.
>>
>> Thank you,
>> Grigore
>>
>> On Mon, Nov 28, 2016 at 10:40 PM, Zoran Stojsavljevic <
>> zoran.stojsavljevic at gmail.com> wrote:
>>
>>> Grigore,
>>>
>>> Here are my comments to what you wrote to me:
>>>
>>> On Mon, Nov 28, 2016 at 7:59 PM, Grigore Lupescu <grigore at arista.com>
>>> 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,
>>> Zoran
>>>
>>>
>>>> Thank you,
>>>> Grigore
>>>>
>>>> On Mon, Nov 28, 2016 at 6:31 PM, Zoran Stojsavljevic <
>>>> zoran.stojsavljevic at gmail.com> 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,
>>>>> Zoran
>>>>>
>>>>> On Mon, Nov 28, 2016 at 7:13 PM, Grigore Lupescu via coreboot <
>>>>> coreboot at coreboot.org> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> 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,
>>>>>> Grigore
>>>>>>
>>>>>> --
>>>>>> coreboot mailing list: coreboot at coreboot.org
>>>>>> https://www.coreboot.org/mailman/listinfo/coreboot
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161202/723198c3/attachment.html>