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

Tue Nov 29 22:48:10 CET 2016

Grigore,

I am sorry... I am late with Re:. I read what you wrote, but I need (more)
time to analyse. I am in chaos... Since I am unemployed (now), and many
agencies/companies try to get to me. Not easy for me... Too much burden.
:-((
_______

I am confused (above) about what you said... I will read AGAIN your email
(I read it/@ twice, but no ideas yet), and get to you back... When
something will pop up in my mind!

Anybody... Would you like something else to comment to this thread, U R
more than welcome! :-)

Please, Grigore... Please, be patient... I need time to reconcile, and
investigate!

Thank you,
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/20161129/439c2973/attachment.html>