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 <[email protected]> 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 <[email protected]> > 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 < >> [email protected]> 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 <[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
