coreboot November 2016

coreboot@coreboot.org

66 participants
187 discussions

Re: [coreboot] Rettungsboot
by ron minnich 01 Dec '16

01 Dec '16

amusement value: The 512 bytes used for MBR is about .04% of the 8" floppy disk that shipped with the original IBM PC. For 128 MB to be that fraction of a new disk, the disk would have to be 256 GiB. That's about $40 worth of disk. Geez. On Wed, Nov 30, 2016 at 11:00 AM Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > > Or do you want to do the full EFI "let's waste 128MB of *every** disk* > on > > a special FAT32 partition" madness (which still requires bootloaders to > > include one specific FS driver they might otherwise not want)? > > YES, you do. Accent on: "every disk" . > > Zoran > On Tue, Nov 29, 2016 at 10:53 PM, Julius Werner <jwerner(a)chromium.org> > wrote: > > > To sum it up, I want something that is lean and clean enough so it could > be added to any bootloader. Even if that boot loader is not of the > let's build a tiny OS type. > > I don't really see how you could reach this goal with anything that > requires reading a file from the boot media? There are billions of > different file systems out there... do you want to require your > "minimal" bootloader to include drivers for all of them? (There are > bootloaders that don't contain any file system drivers at all, like > depthcharge.) Or do you want to do the full EFI "let's waste 128MB of > every disk on a special FAT32 partition" madness (which still requires > bootloaders to include one specific FS driver they might otherwise not > want)? > > I think if you want to do anything truly minimal and compatible with > everything, you can't rely on files (and you should try to rely on > partitions as little as possible, e.g. no full GPT parsing). Which > probably means putting it in the first sector. And once you have that, > you can create some fancy text-based format (or Go source file / > node.js script / whatever the cool kids use these days) to describe > the target sector, load address etc. of the fallback kernel... but > you're really just exemplifying the XKCD Igor mentioned because you've > just reinvented the MBR. (And let's face it... no coreboot bootloader > has the pull to sufficiently promote adoption of some completely new > fallback boot descriptor format right now, even if it doesn't require > a Go compiler in your bootloader.) > > So, really, I think what you want is just the MBR. It is the deadest > simple design possible (just load a sector and jump), it is as > infinitely flexible as code itself, and it coexists perfectly with all > partitioning schemes relevant today (MBR and GPT). Yes, it requires a > software interrupt BIOS interface, but if the recovery kernel code is > cleverly written you really only need the disk access part (and you > know your bootloader already has that driver because that's how it > loaded the MBR in the first place). And yes, on x86 it requires real > mode (for non-x86 I'd just make up an as equivalent as possible system > with your software interrupt solution of choice), but that's a small > price you pay with a few files worth of shim code in exchange for > automatic compatibility with 35 years worth of existing BIOSes. I'd > say that's a better deal than any new dead-on-arrival scheme you could > make up out of thin air. > > (If you really can't stand the idea of BIOS interrupts and real mode, > I think your next best option would be to try to cram an > as-small-as-possible binary recovery descriptor and the real mode code > to parse/load/execute it together into the 446 bytes of MBR space you > have. This way, your new payloads can just find and parse/load/execute > the descriptor itself without having to provide any BIOS interface, > but the thing is still compatible with existing legacy BIOSes as > well.) > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot > >

1 0

Re: [coreboot] Execute Linux on AMD DB-FT3b-LC through GRUB2
by Zoran Stojsavljevic 01 Dec '16

01 Dec '16

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(a)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(a)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(a)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(a)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(a)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(a)coreboot.org >>>>> https://www.coreboot.org/mailman/listinfo/coreboot >>>>> >>>> >>>> >>> >> >

1 0

Re: [coreboot] Rettungsboot
by Zoran Stojsavljevic 01 Dec '16

01 Dec '16

> Or do you want to do the full EFI "let's waste 128MB of *every** disk* on > a special FAT32 partition" madness (which still requires bootloaders to > include one specific FS driver they might otherwise not want)? YES, you do. Accent on: "every disk" . Zoran On Tue, Nov 29, 2016 at 10:53 PM, Julius Werner <jwerner(a)chromium.org> wrote: > > To sum it up, I want something that is lean and clean enough so it could > be added to any bootloader. Even if that boot loader is not of the > let's build a tiny OS type. > > I don't really see how you could reach this goal with anything that > requires reading a file from the boot media? There are billions of > different file systems out there... do you want to require your > "minimal" bootloader to include drivers for all of them? (There are > bootloaders that don't contain any file system drivers at all, like > depthcharge.) Or do you want to do the full EFI "let's waste 128MB of > every disk on a special FAT32 partition" madness (which still requires > bootloaders to include one specific FS driver they might otherwise not > want)? > > I think if you want to do anything truly minimal and compatible with > everything, you can't rely on files (and you should try to rely on > partitions as little as possible, e.g. no full GPT parsing). Which > probably means putting it in the first sector. And once you have that, > you can create some fancy text-based format (or Go source file / > node.js script / whatever the cool kids use these days) to describe > the target sector, load address etc. of the fallback kernel... but > you're really just exemplifying the XKCD Igor mentioned because you've > just reinvented the MBR. (And let's face it... no coreboot bootloader > has the pull to sufficiently promote adoption of some completely new > fallback boot descriptor format right now, even if it doesn't require > a Go compiler in your bootloader.) > > So, really, I think what you want is just the MBR. It is the deadest > simple design possible (just load a sector and jump), it is as > infinitely flexible as code itself, and it coexists perfectly with all > partitioning schemes relevant today (MBR and GPT). Yes, it requires a > software interrupt BIOS interface, but if the recovery kernel code is > cleverly written you really only need the disk access part (and you > know your bootloader already has that driver because that's how it > loaded the MBR in the first place). And yes, on x86 it requires real > mode (for non-x86 I'd just make up an as equivalent as possible system > with your software interrupt solution of choice), but that's a small > price you pay with a few files worth of shim code in exchange for > automatic compatibility with 35 years worth of existing BIOSes. I'd > say that's a better deal than any new dead-on-arrival scheme you could > make up out of thin air. > > (If you really can't stand the idea of BIOS interrupts and real mode, > I think your next best option would be to try to cram an > as-small-as-possible binary recovery descriptor and the real mode code > to parse/load/execute it together into the 446 bytes of MBR space you > have. This way, your new payloads can just find and parse/load/execute > the descriptor itself without having to provide any BIOS interface, > but the thing is still compatible with existing legacy BIOSes as > well.) > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Rettungsboot
by Peter Stuge 01 Dec '16

01 Dec '16

Julius Werner wrote: > If you really can't stand the idea of BIOS interrupts and real mode, I for one can't. > I think your next best option would be to try to cram an > as-small-as-possible binary recovery descriptor and the real mode > code to parse/load/execute it together into the 446 bytes of MBR > space you have. I like this idea a lot. Backwards compatible is hugely important. > This way, your new payloads can just find and parse/load/execute > the descriptor itself without having to provide any BIOS interface, > but the thing is still compatible with existing legacy BIOSes as > well.) I am sold. Ron, I will make you a deal: If we use Concise Binary Object Representation (CBOR, RFC 7049) for the MBR data then its working format can be JSON. I'd be interested in writing the x86 code. //Peter

2 1

Re: [coreboot] [RFC] Explicitly use C89 (was: Setting C99 by default)
by Paul Menzel 30 Nov '16

30 Nov '16

Dear Ron, Am Sonntag, den 27.11.2016, 22:44 +0000 schrieb ron minnich: > Seems reasonable, but on Harvey recently we went with c11. Any reason not > to do that instead? I am sorry, my statement about Linux was incorrect. Linux is explicitly built with C89 [1][2][3]. ``` HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89 ``` So I’d say, coreboot also stays with C89 to be compatible with Linux. Thanks, Paul [1] https://www.phoronix.com/scan.php?page=news_item&px=MTg0MTQ [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5… [3] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Makefil…

7 9

Re: [coreboot] Any one have a experence the coreboot with u-boot?
by Simon Glass 30 Nov '16

30 Nov '16

+U-Boot and Bin On 29 November 2016 at 15:25, Julius Werner <jwerner(a)chromium.org> wrote: > edit: forgot the mailing list > > On Tue, Nov 29, 2016 at 2:24 PM, Julius Werner <jwerner(a)chromium.org> wrote: >> +Simon who maintains the U-Boot x86 port and might be interested >> >> In general, this sounds like a U-Boot problem more than a coreboot >> problem (since you're clearly getting into U-Boot code execution), and >> you'd probably have better luck asking on the U-Boot mailing lists for >> help. >> >> On Mon, Nov 28, 2016 at 12:22 AM, 김유석 <poplinux0(a)gmail.com> wrote: >>> Dear Sir. >>> >>> My env is see below. >>> >>> board : Intel rangeley MOHON PEAK.(CPU is C2358) >>> >>> >>> I was success boot coreboot + SeaBIOS. >>> >>> This time, I'm try to boot coreboot + u-boot(16.05). >>> >>> But u-boot is every time fail. log is see below. >>> >>> >>> U-Boot 2016.05-rc3 (Nov 28 2016 - 17:04:31 +0900) >>> >>> CPU: x86_64, vendor Intel, device 406d8h >>> DRAM: 4 GiB >>> >>> dm_pci_hose_probe_bus: Internal error, bus 'pch@1,0' got seq 0, expected 1 This says that U-Boot is scanning a bridge and expects to to be bus number 1, but it is bus number 0. I'm not quite sure how this can happen. Try 'dm tree' to list the devices. Or put a call to dm_dump_all() in dm_pci_hose_probe_bus(). >>> Using default environment >>> >>> Video: No video mode configured in coreboot! This is because you need to enable the display in coreboot (if you want to). >>> Model: QEMU x86 (I440FX) Here you are using the qemu board. You might want to create a new device tree file. If you see qemu-x86_i440fx.dts you may need to change the PCH address? >>> >>> dm_pci_hose_probe_bus: Internal error, bus 'pch@1,0' got seq 0, expected 1 >>> initcall sequence 7fc59100 failed at call 01110185 (err=-32) >>> ### ERROR ### Please RESET the board ### You can use: grep 7fc59100 System.map to find the function that is failing. But I'm pretty sure it is because of the PCI problem, since it returns -EPIPE. >>> >>> >>> Every time occured fail on the interrupt_init(). >>> >>> But I don't have a solution. >>> >>> >>> I was attached the config of corebooe and u-boot. >>> >>> >>> Please advise to me. Can you explain why you are using coreboot first? Is it because you don't want to support this platform on U-Boot? It would be more work, at least unless you have an FSP. I talked with one of the coreboot guys about setting up a U-Boot config that reads everything it needs from coreboot, instead of requiring its own configuration. Then we would not have these problems. However I haven't actually worked on this as I don't actually have a board that fails...maybe soon. >>> >>> >>> Thank you. Regards, Simon >>> >>> >>> >>> >>> >>> >>> -- >>> coreboot mailing list: coreboot(a)coreboot.org >>> https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Any one have a experence the coreboot with u-boot?
by Julius Werner 30 Nov '16

30 Nov '16

edit: forgot the mailing list On Tue, Nov 29, 2016 at 2:24 PM, Julius Werner <jwerner(a)chromium.org> wrote: > +Simon who maintains the U-Boot x86 port and might be interested > > In general, this sounds like a U-Boot problem more than a coreboot > problem (since you're clearly getting into U-Boot code execution), and > you'd probably have better luck asking on the U-Boot mailing lists for > help. > > On Mon, Nov 28, 2016 at 12:22 AM, 김유석 <poplinux0(a)gmail.com> wrote: >> Dear Sir. >> >> My env is see below. >> >> board : Intel rangeley MOHON PEAK.(CPU is C2358) >> >> >> I was success boot coreboot + SeaBIOS. >> >> This time, I'm try to boot coreboot + u-boot(16.05). >> >> But u-boot is every time fail. log is see below. >> >> >> U-Boot 2016.05-rc3 (Nov 28 2016 - 17:04:31 +0900) >> >> CPU: x86_64, vendor Intel, device 406d8h >> DRAM: 4 GiB >> >> dm_pci_hose_probe_bus: Internal error, bus 'pch@1,0' got seq 0, expected 1 >> Using default environment >> >> Video: No video mode configured in coreboot! >> Model: QEMU x86 (I440FX) >> >> dm_pci_hose_probe_bus: Internal error, bus 'pch@1,0' got seq 0, expected 1 >> initcall sequence 7fc59100 failed at call 01110185 (err=-32) >> ### ERROR ### Please RESET the board ### >> >> >> Every time occured fail on the interrupt_init(). >> >> But I don't have a solution. >> >> >> I was attached the config of corebooe and u-boot. >> >> >> Please advise to me. >> >> >> Thank you. >> >> >> >> >> >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Rettungsboot
by Nico Huber 30 Nov '16

30 Nov '16

On 28.11.2016 20:26, David Hendricks via coreboot wrote: > On Sun, Nov 27, 2016 at 8:28 PM, ron minnich <rminnich(a)gmail.com> wrote: > >> yeah, david and nico both make very good points. I like the idea of JSON >> file, and further we're working on a Go program >> on the u-root project that would parse said file (trivial in Go to parse >> JSON, it's one statement and blam! your Go struct is all >> filled in) and then decide what to configure/what to download/how to >> validate (we have a gpgv command written in Go by >> Eric Grosse) and then how to kexec it. >> >> I think what we're doing might be useful? >> > > Now we're talkin' - A standardized data format that is human > readable/writeable that can be easily parsed and generated using small > libraries. It looks like Go can already handle it easily, for C we could > maybe use JSMN (http://zserge.com/jsmn.html) or something similar. I think > that addresses Nico's first point. > > For the other points, I imagine we'd have two varieties of the JSON file. > One would be generated along with the payload and included as a CBFS file > to specify things like capabilities and bootable device priority*. The > other would be on the bootable media and specify things like the kernel > path and parameters. A tool which is used to generate the latter would > verify the capabilities and warn the user if their coreboot payload lacks > support for something. A tool like that might have to see the whole bootable medium. You can't tell from the configuration file in which type of filesystem it's stored for example. But I really like the idea. Such a tool could tell if a boot medium only needs capabilities that are mandatory in the spec, thus, should always boot ;) > > *Stuff like boot device priority might need some more thought since CMOS > may be a preferable way of controlling something like that. However given > that CMOS might not exist on a particular platform (especially in the > non-x86 world) replacing the config file in CBFS file might not be a bad > way to go. I'd like to keep that out of scope (for the moment). Let's just start with what happens when the bootloader has found the configuration. Nico

2 1

Re: [coreboot] Execute Linux on AMD DB-FT3b-LC through GRUB2
by Zoran Stojsavljevic 30 Nov '16

30 Nov '16

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(a)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(a)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(a)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(a)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(a)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(a)coreboot.org >>>>> https://www.coreboot.org/mailman/listinfo/coreboot >>>>> >>>> >>>> >>> >> >

1 0

Re: [coreboot] Execute Linux on AMD DB-FT3b-LC through GRUB2
by Grigore Lupescu 29 Nov '16

29 Nov '16

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(a)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(a)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(a)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(a)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(a)coreboot.org >>>> https://www.coreboot.org/mailman/listinfo/coreboot >>>> >>> >>> >> >

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2016