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 <[email protected]> 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 < > [email protected]> wrote: > >> Grigore, >> >> Here are my comments to what you wrote to me: >> >> On Mon, Nov 28, 2016 at 7:59 PM, Grigore Lupescu <[email protected]> >> 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 < >>> [email protected]> 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 < >>>> [email protected]> 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: [email protected] >>>>> https://www.coreboot.org/mailman/listinfo/coreboot >>>>> >>>> >>>> >>> >> >
-- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
