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

[Zoran Stojsavljevic]

Excellent, Grigore. One problem less. At least, I learned from your
practical experience handful!  :-)

Zoran

On Fri, Dec 2, 2016 at 6:04 PM, Grigore Lupescu  wrote:

> Restarting the config from scratch and setting Keep Vesa framebuffer I am
> able to enter gfxterm in GRUB2.
> Linux is also booting now, happy day :)
>
> On Fri, Dec 2, 2016 at 3:24 PM, Grigore Lupescu 
> wrote:
>
>> 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.stojsavlje...@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 
>>> 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.000
 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 + 

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

[Grigore Lupescu via coreboot]

Restarting the config from scratch and setting Keep Vesa framebuffer I am
able to enter gfxterm in GRUB2.
Linux is also booting now, happy day :)

On Fri, Dec 2, 2016 at 3:24 PM, Grigore Lupescu  wrote:

> 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.stojsavlje...@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 
>> 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.000
>>> 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 

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

[Grigore Lupescu via coreboot]

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.stojsavlje...@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 
> 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.000
>> 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.stojsavlje...@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 
>>> wrote:
>>>
 Hello Zoran,

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

>>>
>>> 

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

[Zoran Stojsavljevic]

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  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.000
> 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.stojsavlje...@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 
>> 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  or  (maybe , Lenovo 420T
>> supports , 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 

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

[Zoran Stojsavljevic]

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  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.000
> 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.stojsavlje...@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 
>> 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  or  (maybe , Lenovo 420T
>> supports , 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)

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

[Grigore Lupescu via coreboot]

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.000
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.stojsavlje...@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 
> 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  or  (maybe , Lenovo 420T
> supports , 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 

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

[Zoran Stojsavljevic]

Grigore,

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  or  (maybe , Lenovo 420T
supports , 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.stojsavlje...@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@coreboot.org> wrote:
>>
>>> Hello,
>>>
>>> I am trying to run Linux through the GRUB2 

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

[Grigore Lupescu via coreboot]

Hello Zoran,

[1-3] I am using the latest Ubuntu 16.04 LTS x64 desktop, 4.4 kernel.
[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.
[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)
[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)
[7] It's the same one referenced from Coreboot in the external payloads -
GRUB 2.02 beta3.

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

Thank you,
Grigore

On Mon, Nov 28, 2016 at 6:31 PM, Zoran Stojsavljevic <
zoran.stojsavlje...@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@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@coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

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

[Zoran Stojsavljevic]

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@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@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot