coreboot December 2016

coreboot@coreboot.org

57 participants
121 discussions

Re: [coreboot] T430s or T430 (Was: latest greatest thinkpad with coreboot)
by Nico Huber 03 Dec '16

03 Dec '16

On 02.12.2016 19:53, ron minnich wrote: > yeah I'm similarly confused about the t430 state but nico is giving me hope. Um, I was just comparing specs, sorry. The T430 seems to be unsupported. Also I guess, it would only be one or two days of work, I wouldn't con- sider to buy it. It's basically just heavier than the T430s (and some come with the shitty NVIDIA Optimus graphics). > > On Fri, Dec 2, 2016 at 9:15 AM Sam Kuper <sam.kuper(a)uclmail.net> wrote: > >> On 01/12/2016, Nico Huber <nico.h(a)gmx.de> wrote: >>> On 01.12.2016 18:50, Klemens Nanni wrote: >>>> On Thu, Dec 01, 2016 at 05:04:36PM +0000, ron minnich wrote: >>>>> what's the latest best one? >>>>> >>>> X230 if you'd ask me: 16G RAM, 12M ROM. runs fine with reduced >>>> (830K) ME >>>> >>> Everything Klemens said about the X230 should also apply to the >>> T430s. It's just 14" instead of 12". >> >> Has anyone here actually tried running Coreboot with a reduced ME on a >> T430 or T430s? I haven't tried (don't even have the system), but I wouldn't expect any trouble with a reduced ME image. It's more chipset than board specific, FWIW. >> >> The Coreboot wiki does not even have pages for those models... >> >> https://www.coreboot.org/Board:lenovo/t430 >> >> https://www.coreboot.org/Board:lenovo/t430s Perfect, I think you found the first board without outdated information in the wiki :-D Nico

2 1

Re: [coreboot] latest greatest thinkpad with coreboot
by Klemens Nanni 02 Dec '16

02 Dec '16

On Thu, Dec 01, 2016 at 05:04:36PM +0000, ron minnich wrote: >what's the latest best one? What's the battery life like (can't be worse >than this mac pro that's always hot and now seems to have a life of 90 >minutes, always). How much dram/ssd can I jam in it? X230 if you'd ask me: 16G RAM, 12M ROM. runs fine with reduced (830K) ME and has a powerful Ivy Bridge CPU. USB3.0, miniDisplayPort as well as docking station has been working just fine for me although handling suspend/resume as well as mounted external storage *can* be somewhat tricky (in some scenarios the X230 would instantly resume from suspend after having been docked once). Battery life under linux has been somewhere around 8 hours for me, OpenBSD gets about 5-6 out of it but YMMV. The X series never features more than one disk bay, but this again depends on your use case: I'm totally fine with an 120G SSD, other people prefer a RAID on their W/T model ThinkPads. Best regards, kl3

6 8

Re: [coreboot] Anyone have a experence the u-boot on coreboot?(Rangeley platform)
by David Hendricks 02 Dec '16

02 Dec '16

Yep, probably more relevant to the U-Boot mailing list but nice to see it here as well! On Thu, Dec 1, 2016 at 11:43 PM, Yaroslav K. <yar444(a)gmail.com> wrote: > Hello! > > I'm successfully using U-boot with Coreboot on the Rangeley platform > with the attached dts file. I'm not sure if everything in it is needed > and/or correct, but it works fine. > serial1.dtsi was needed so that the second UART is used as stdout. > > Although, this question looks like more relevant to the U-boot mailing > list than the Coreboot one. > > -- > Yaroslav > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.

1 0

xHCI support for x86
by Pitrolle Jean-Jacques 02 Dec '16

02 Dec '16

Hello *, I try to integrate coreboot *libpayload usb stack* in a custom binary for x86. I already succeed integration of *ehci* for *qemu* and *core 2 duo* platforms. But things seems to be not so easy for *xhci*. When I try to run coreboot master branch (with hash 8bf3f7a) on qemu (version 2.7.0) with following line : % qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -drive if=none,id=usbstick,file=/tmp/qemu_usb.disk -usb -device nec-usb-xhci,id=xhci -device usb-storage,bus=xhci.0,drive=usbstick I get these output lines concerning xHCI controller (nec-usb-xhci) : 8<--- [..] 00:04.0 0194:1033.0 xHCI controller xhci_init: regbase: 0xfe070000 xhci_init: caplen: 0x40 xhci_init: rtsoff: 0x1000 xhci_init: dboff: 0x2000 xhci_init: hciversion: 0.0 xhci_init: Unsupported xHCI version [..] --->8 The same result is reached with qemu-system-i386... Is it the expected result on qemu? I don't have any motherboard supported by coreboot, so I try a custom binary on a *Xeon* processor (processor D-1500). The xHCI version is supported (hciversion: 1.0) but things turn bad when starting xHCI controller i.e xhci->opreg->usbcmd |= USBCMD_RS in *xhci_start* : the program hangs... The registers usbcmd and usbsts before this command seems to have proper values (a usb key is connected.) 8<--- [..] xhci_start - usbcmd:0 - usbsts:11 [..] --->8 This seems to be related to interrupter configuration. When I comment out the two lines in *xhci_reinit* 8<--- [..] xhci->hcrreg->intrrs[0].erstba_lo = virt_to_phys(xhci->ev_ring_table); xhci->hcrreg->intrrs[0].erstba_hi = 0; [..] --->8 xhci_start works as expected i.e not hangs. But the sequence following with *NOOP* to test command ring and event ring mechanism fails. 8<--- [..] NOOP run #0 Transfer TRB (@0x8051700): PTR_L 0x00000000 PTR_H 0x00000000 STATUS 0x00000000 CNTRL 0x00005c00 TL 0x0000 TDS 0x0000 C 0x0000 ISP 0x0000 CH 0x0000 IOC 0x0000 IDT 0x0000 TT 0x0017 DIR 0x0000 Command 23 (@0x8051700) Warning: Timed out waiting for TRB_EV_CMD_CMPL. Command ring is running [..] --->8 As I understand it is mandatory to have the first interrupter configure to manage at least one event ring (4.9.4 Event Ring Management - eXtensible Host Controller Interface Revision 1.1). Does someone succeed with xHCI support for x86 board? Did I miss something concerning xHCI configuration? Thanks. Have a nice day. -- Jean-Jacques PITROLLE Phone: +33 1 30 09 12 70 SYSGO S.A.S

3 3

Re: [coreboot] T430s or T430 (Was: latest greatest thinkpad with coreboot)
by ron minnich 02 Dec '16

02 Dec '16

yeah I'm similarly confused about the t430 state but nico is giving me hope. On Fri, Dec 2, 2016 at 9:15 AM Sam Kuper <sam.kuper(a)uclmail.net> wrote: > On 01/12/2016, Nico Huber <nico.h(a)gmx.de> wrote: > > On 01.12.2016 18:50, Klemens Nanni wrote: > >> On Thu, Dec 01, 2016 at 05:04:36PM +0000, ron minnich wrote: > >>> what's the latest best one? > >>> > >> X230 if you'd ask me: 16G RAM, 12M ROM. runs fine with reduced > >> (830K) ME > >> > > Everything Klemens said about the X230 should also apply to the > > T430s. It's just 14" instead of 12". > > Has anyone here actually tried running Coreboot with a reduced ME on a > T430 or T430s? > > The Coreboot wiki does not even have pages for those models... > > https://www.coreboot.org/Board:lenovo/t430 > > https://www.coreboot.org/Board:lenovo/t430s > > Thanks! > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

T430s or T430 (Was: latest greatest thinkpad with coreboot)
by Sam Kuper 02 Dec '16

02 Dec '16

On 01/12/2016, Nico Huber <nico.h(a)gmx.de> wrote: > On 01.12.2016 18:50, Klemens Nanni wrote: >> On Thu, Dec 01, 2016 at 05:04:36PM +0000, ron minnich wrote: >>> what's the latest best one? >>> >> X230 if you'd ask me: 16G RAM, 12M ROM. runs fine with reduced >> (830K) ME >> > Everything Klemens said about the X230 should also apply to the > T430s. It's just 14" instead of 12". Has anyone here actually tried running Coreboot with a reduced ME on a T430 or T430s? The Coreboot wiki does not even have pages for those models... https://www.coreboot.org/Board:lenovo/t430 https://www.coreboot.org/Board:lenovo/t430s Thanks!

1 0

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

02 Dec '16

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 <grigore(a)arista.com> 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.stojsavljevic(a)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 <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 02 Dec '16

02 Dec '16

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.stojsavljevic(a)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 <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

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 02 Dec '16

02 Dec '16

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 47 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 20 of 47 defect(s) ** CID 1366756: Control flow issues (DEADCODE) /src/lib/spd_bin.c: 165 in get_spd_smbus() ________________________________________________________________________________________________________ *** CID 1366756: Control flow issues (DEADCODE) /src/lib/spd_bin.c: 165 in get_spd_smbus() 159 get_spd(spd_data_ptr + i * CONFIG_DIMM_SPD_SIZE, 160 0xA0 + (i << 1)); 161 blk->spd_array[i] = spd_data_ptr + i * CONFIG_DIMM_SPD_SIZE; 162 } 163 164 for (j = i; j < CONFIG_DIMM_MAX; j++) >>> CID 1366756: Control flow issues (DEADCODE) >>> Execution cannot reach this statement: "blk->spd_array[j] = NULL;". 165 blk->spd_array[j] = NULL; 166 167 update_spd_len(blk); ** CID 1366755: Error handling issues (CHECKED_RETURN) /src/lib/spd_bin.c: 120 in get_spd_cbfs_rdev() ________________________________________________________________________________________________________ *** CID 1366755: Error handling issues (CHECKED_RETURN) /src/lib/spd_bin.c: 120 in get_spd_cbfs_rdev() 114 int get_spd_cbfs_rdev(struct region_device *spd_rdev, u8 spd_index) 115 { 116 struct cbfsf fh; 117 118 uint32_t cbfs_type = CBFS_TYPE_SPD; 119 >>> CID 1366755: Error handling issues (CHECKED_RETURN) >>> Calling "cbfs_boot_locate" without checking return value (as is done elsewhere 10 out of 11 times). 120 cbfs_boot_locate(&fh, "spd.bin", &cbfs_type); 121 cbfs_file_data(spd_rdev, &fh); 122 return rdev_chain(spd_rdev, spd_rdev, spd_index * CONFIG_DIMM_SPD_SIZE, 123 CONFIG_DIMM_SPD_SIZE); 124 } 125 ** CID 1361275: (TAINTED_SCALAR) /util/cbfstool/ifwitool.c: 838 in parse_subpart_dir() ________________________________________________________________________________________________________ *** CID 1361275: (TAINTED_SCALAR) /util/cbfstool/ifwitool.c: 831 in parse_subpart_dir() 825 memcpy(hdr.name, data + offset, sizeof(hdr.name)); 826 offset += sizeof(hdr.name); 827 828 validate_subpart_dir_without_checksum((struct subpart_dir *)&hdr, name); 829 830 assert(size > subpart_dir_size(&hdr)); >>> CID 1361275: (TAINTED_SCALAR) >>> Passing tainted variable "subpart_dir_size(&hdr)" to a tainted sink. 831 alloc_buffer(subpart_dir_buf, subpart_dir_size(&hdr), "Subpart Dir"); 832 memcpy(buffer_get(subpart_dir_buf), &hdr, SUBPART_DIR_HEADER_SIZE); 833 834 /* Read Subpart Dir entries. */ 835 struct subpart_dir *subpart_dir = buffer_get(subpart_dir_buf); 836 struct subpart_dir_entry *e = &subpart_dir->e[0]; /util/cbfstool/ifwitool.c: 838 in parse_subpart_dir() 832 memcpy(buffer_get(subpart_dir_buf), &hdr, SUBPART_DIR_HEADER_SIZE); 833 834 /* Read Subpart Dir entries. */ 835 struct subpart_dir *subpart_dir = buffer_get(subpart_dir_buf); 836 struct subpart_dir_entry *e = &subpart_dir->e[0]; 837 uint32_t i; >>> CID 1361275: (TAINTED_SCALAR) >>> Using tainted variable "hdr.num_entries" as a loop boundary. 838 for (i = 0; i < hdr.num_entries; i++) { 839 memcpy(e[i].name, data + offset, sizeof(e[i].name)); 840 offset += sizeof(e[i].name); 841 offset = read_member(data, offset, sizeof(e[i].offset), 842 &e[i].offset); 843 offset = read_member(data, offset, sizeof(e[i].length), ** CID 1361274: Insecure data handling (TAINTED_SCALAR) ________________________________________________________________________________________________________ *** CID 1361274: Insecure data handling (TAINTED_SCALAR) /util/cbfstool/ifwitool.c: 717 in alloc_bpdt_buffer() 711 { 712 struct bpdt_header bpdt_header; 713 assert((offset + BPDT_HEADER_SIZE) < size); 714 bpdt_read_header((uint8_t *)data + offset, &bpdt_header, name); 715 716 /* Buffer to read BPDT header and entries. */ >>> CID 1361274: Insecure data handling (TAINTED_SCALAR) >>> Passing tainted variable "get_bpdt_size(&bpdt_header)" to a tainted sink. 717 alloc_buffer(b, get_bpdt_size(&bpdt_header), name); 718 719 struct bpdt *bpdt = buffer_get(b); 720 memcpy(&bpdt->h, &bpdt_header, BPDT_HEADER_SIZE); 721 722 /* ** CID 1361253: Memory - illegal accesses (BUFFER_SIZE_WARNING) /util/cbfstool/ifwitool.c: 1300 in init_subpart_dir_entry() ________________________________________________________________________________________________________ *** CID 1361253: Memory - illegal accesses (BUFFER_SIZE_WARNING) /util/cbfstool/ifwitool.c: 1300 in init_subpart_dir_entry() 1294 static size_t init_subpart_dir_entry(struct subpart_dir_entry *e, 1295 struct buffer *b, size_t offset) 1296 { 1297 memset(e, 0, sizeof(*e)); 1298 1299 assert(strlen(b->name) <= sizeof(e->name)); >>> CID 1361253: Memory - illegal accesses (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 12 bytes on destination array "e->name" of size 12 bytes might leave the destination string unterminated. 1300 strncpy((char *)e->name, (char *)b->name, sizeof(e->name)); 1301 e->offset = offset; 1302 e->length = buffer_size(b); 1303 1304 return (offset + buffer_size(b)); 1305 } ** CID 1353793: Resource leaks (RESOURCE_LEAK) /util/nvidia/cbootimage/src/data_layout.c: 1096 in resign_bl() ________________________________________________________________________________________________________ *** CID 1353793: Resource leaks (RESOURCE_LEAK) /util/nvidia/cbootimage/src/data_layout.c: 1096 in resign_bl() 1090 1091 if (read_from_image(context->input_image_filename, 1092 offset, bl_length, 1093 &image, &image_actual_size, file_type_bin)) { 1094 printf("Error reading image file %s.\n", 1095 context->input_image_filename); >>> CID 1353793: Resource leaks (RESOURCE_LEAK) >>> Variable "image" going out of scope leaks the storage it points to. 1096 return -ENOMEM; 1097 } 1098 1099 pages_in_image = ICEIL(image_actual_size, page_size); 1100 1101 /* Create a local copy of the bl */ ** CID 1353781: Control flow issues (NO_EFFECT) /util/nvidia/cbootimage/src/cbootimage.c: 242 in main() ________________________________________________________________________________________________________ *** CID 1353781: Control flow issues (NO_EFFECT) /util/nvidia/cbootimage/src/cbootimage.c: 242 in main() 236 context.input_image_filename); 237 goto fail; 238 } 239 240 /* Get BCT_SIZE from input image file */ 241 bct_size = get_bct_size_from_image(&context); >>> CID 1353781: Control flow issues (NO_EFFECT) >>> This less-than-zero comparison of an unsigned value is never true. "bct_size < 0U". 242 if (bct_size < 0) { 243 printf("Error: Invalid input image file %s\n", 244 context.input_image_filename); 245 goto fail; 246 } 247 ** CID 1353028: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 341 in integrate_psp_firmwares() ________________________________________________________________________________________________________ *** CID 1353028: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 341 in integrate_psp_firmwares() 335 pspdir[4+4*i+2] = 1; 336 pspdir[4+4*i+3] = 0; 337 } else if (fw_table[i].filename != NULL) { 338 pspdir[4+4*i+0] = fw_table[i].type; 339 340 fd = open(fw_table[i].filename, O_RDONLY); >>> CID 1353028: Error handling issues (NEGATIVE_RETURNS) >>> "fd" is passed to a parameter that cannot be negative. [Note: The source code implementation of the function has been overridden by a builtin model.] 341 fstat(fd, &fd_stat); 342 pspdir[4+4*i+1] = (uint32_t)fd_stat.st_size; 343 344 pspdir[4+4*i+2] = pos + rom_base_address; 345 pspdir[4+4*i+3] = 0; 346 ** CID 1353027: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 284 in integrate_firmwares() ________________________________________________________________________________________________________ *** CID 1353027: Error handling issues (NEGATIVE_RETURNS) /util/amdfwtool/amdfwtool.c: 284 in integrate_firmwares() 278 int i; 279 uint32_t rom_base_address = 0xFFFFFFFF - rom_size + 1; 280 281 for (i = 0; fw_table[i].type != AMD_FW_INVALID; i++) { 282 if (fw_table[i].filename != NULL) { 283 fd = open(fw_table[i].filename, O_RDONLY); >>> CID 1353027: Error handling issues (NEGATIVE_RETURNS) >>> "fd" is passed to a parameter that cannot be negative. [Note: The source code implementation of the function has been overridden by a builtin model.] 284 fstat(fd, &fd_stat); 285 286 switch (fw_table[i].type) { 287 case AMD_FW_IMC: 288 pos = ALIGN(pos, 0x10000U); 289 romsig[1] = pos + rom_base_address; ** CID 1353022: Error handling issues (CHECKED_RETURN) /util/nvidia/cbootimage/src/cbootimage.c: 297 in main() ________________________________________________________________________________________________________ *** CID 1353022: Error handling issues (CHECKED_RETURN) /util/nvidia/cbootimage/src/cbootimage.c: 297 in main() 291 begin_update(&context); 292 /* Signing the bct. */ 293 e = sign_bct(&context, context.bct); 294 if (e != 0) 295 printf("Signing BCT failed, error: %d.\n", e); 296 >>> CID 1353022: Error handling issues (CHECKED_RETURN) >>> Calling "fwrite" without checking return value (as is done elsewhere 36 out of 45 times). 297 fwrite(context.bct, 1, context.bct_size, 298 context.raw_file); 299 printf("New BCT file %s has been successfully generated!\n", 300 context.output_image_filename); 301 goto fail; 302 } ** CID 1353021: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 355 in integrate_psp_firmwares() ________________________________________________________________________________________________________ *** CID 1353021: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 355 in integrate_psp_firmwares() 349 " will not fit %s. Exiting.\n", 350 rom_size, fw_table[i].filename); 351 free(base); 352 exit(1); 353 } 354 >>> CID 1353021: Error handling issues (CHECKED_RETURN) >>> "read(int, void *, size_t)" returns the number of bytes read, but it is ignored. 355 read(fd, (void *)(base + pos), (size_t)fd_stat.st_size); 356 357 pos += fd_stat.st_size; 358 close(fd); 359 pos = ALIGN(pos, 0x100U); 360 } else { ** CID 1353020: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 341 in integrate_psp_firmwares() ________________________________________________________________________________________________________ *** CID 1353020: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 341 in integrate_psp_firmwares() 335 pspdir[4+4*i+2] = 1; 336 pspdir[4+4*i+3] = 0; 337 } else if (fw_table[i].filename != NULL) { 338 pspdir[4+4*i+0] = fw_table[i].type; 339 340 fd = open(fw_table[i].filename, O_RDONLY); >>> CID 1353020: Error handling issues (CHECKED_RETURN) >>> Calling "fstat(fd, &fd_stat)" without checking return value. This library function may fail and return an error code. [Note: The source code implementation of the function has been overridden by a builtin model.] 341 fstat(fd, &fd_stat); 342 pspdir[4+4*i+1] = (uint32_t)fd_stat.st_size; 343 344 pspdir[4+4*i+2] = pos + rom_base_address; 345 pspdir[4+4*i+3] = 0; 346 ** CID 1353019: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 310 in integrate_firmwares() ________________________________________________________________________________________________________ *** CID 1353019: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 310 in integrate_firmwares() 304 " will not fit %s. Exiting.\n", 305 rom_size, fw_table[i].filename); 306 free(base); 307 exit(1); 308 } 309 >>> CID 1353019: Error handling issues (CHECKED_RETURN) >>> "read(int, void *, size_t)" returns the number of bytes read, but it is ignored. 310 read(fd, (void *)(base + pos), (size_t)fd_stat.st_size); 311 312 pos += fd_stat.st_size; 313 close(fd); 314 pos = ALIGN(pos, 0x100U); 315 } ** CID 1353018: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 284 in integrate_firmwares() ________________________________________________________________________________________________________ *** CID 1353018: Error handling issues (CHECKED_RETURN) /util/amdfwtool/amdfwtool.c: 284 in integrate_firmwares() 278 int i; 279 uint32_t rom_base_address = 0xFFFFFFFF - rom_size + 1; 280 281 for (i = 0; fw_table[i].type != AMD_FW_INVALID; i++) { 282 if (fw_table[i].filename != NULL) { 283 fd = open(fw_table[i].filename, O_RDONLY); >>> CID 1353018: Error handling issues (CHECKED_RETURN) >>> Calling "fstat(fd, &fd_stat)" without checking return value. This library function may fail and return an error code. [Note: The source code implementation of the function has been overridden by a builtin model.] 284 fstat(fd, &fd_stat); 285 286 switch (fw_table[i].type) { 287 case AMD_FW_IMC: 288 pos = ALIGN(pos, 0x10000U); 289 romsig[1] = pos + rom_base_address; ** CID 1325840: Memory - illegal accesses (OVERRUN) /util/cbfstool/cbfs_image.c: 1406 in cbfs_print_entry_info() ________________________________________________________________________________________________________ *** CID 1325840: Memory - illegal accesses (OVERRUN) /util/cbfstool/cbfs_image.c: 1406 in cbfs_print_entry_info() 1400 while ((hash = cbfs_file_get_next_hash(entry, hash)) != NULL) { 1401 unsigned int hash_type = ntohl(hash->hash_type); 1402 if (hash_type > CBFS_NUM_SUPPORTED_HASHES) { 1403 fprintf(fp, "invalid hash type %d\n", hash_type); 1404 break; 1405 } >>> CID 1325840: Memory - illegal accesses (OVERRUN) >>> Overrunning array "widths_cbfs_hash" of 4 8-byte elements at element index 4 (byte offset 32) using index "hash_type" (which evaluates to 4). 1406 size_t hash_len = widths_cbfs_hash[hash_type]; 1407 char *hash_str = bintohex(hash->hash_data, hash_len); 1408 uint8_t local_hash[hash_len]; 1409 if (vb2_digest_buffer(CBFS_SUBHEADER(entry), 1410 ntohl(entry->len), hash_type, local_hash, 1411 hash_len) != VB2_SUCCESS) { ** CID 1325836: Resource leaks (RESOURCE_LEAK) /util/cbfstool/cbfs_image.c: 1413 in cbfs_print_entry_info() ________________________________________________________________________________________________________ *** CID 1325836: Resource leaks (RESOURCE_LEAK) /util/cbfstool/cbfs_image.c: 1413 in cbfs_print_entry_info() 1407 char *hash_str = bintohex(hash->hash_data, hash_len); 1408 uint8_t local_hash[hash_len]; 1409 if (vb2_digest_buffer(CBFS_SUBHEADER(entry), 1410 ntohl(entry->len), hash_type, local_hash, 1411 hash_len) != VB2_SUCCESS) { 1412 fprintf(fp, "failed to hash '%s'\n", name); >>> CID 1325836: Resource leaks (RESOURCE_LEAK) >>> Variable "hash_str" going out of scope leaks the storage it points to. 1413 break; 1414 } 1415 int valid = memcmp(local_hash, hash->hash_data, hash_len) == 0; 1416 const char *valid_str = valid ? "valid" : "invalid"; 1417 1418 fprintf(fp, " hash %s:%s %s\n", ** CID 1323515: Error handling issues (CHECKED_RETURN) /util/broadcom/secimage/sbi.c: 112 in CreateSecureBootImage() ________________________________________________________________________________________________________ *** CID 1323515: Error handling issues (CHECKED_RETURN) /util/broadcom/secimage/sbi.c: 112 in CreateSecureBootImage() 106 } else { 107 return SBIUsage(); 108 } 109 --ac, ++av; 110 } 111 >>> CID 1323515: Error handling issues (CHECKED_RETURN) >>> Calling "stat(bl, &file_stat)" without checking return value. This library function may fail and return an error code. [Note: The source code implementation of the function has been overridden by a builtin model.] 112 stat(bl, &file_stat); 113 filesize = file_stat.st_size + MIN_SIZE; 114 buf = calloc(sizeof(uint8_t), filesize); 115 116 if (buf == NULL) { 117 puts("Memory allocation error"); ** CID 1323512: Null pointer dereferences (FORWARD_NULL) /util/broadcom/secimage/sbi.c: 112 in CreateSecureBootImage() ________________________________________________________________________________________________________ *** CID 1323512: Null pointer dereferences (FORWARD_NULL) /util/broadcom/secimage/sbi.c: 112 in CreateSecureBootImage() 106 } else { 107 return SBIUsage(); 108 } 109 --ac, ++av; 110 } 111 >>> CID 1323512: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "bl" to "stat", which dereferences it. [Note: The source code implementation of the function has been overridden by a builtin model.] 112 stat(bl, &file_stat); 113 filesize = file_stat.st_size + MIN_SIZE; 114 buf = calloc(sizeof(uint8_t), filesize); 115 116 if (buf == NULL) { 117 puts("Memory allocation error"); ** CID 1323511: Null pointer dereferences (FORWARD_NULL) /util/broadcom/secimage/sbi.c: 80 in CreateSecureBootImage() ________________________________________________________________________________________________________ *** CID 1323511: Null pointer dereferences (FORWARD_NULL) /util/broadcom/secimage/sbi.c: 80 in CreateSecureBootImage() 74 * Purpose : 75 * Input : none 76 * Output : none 77 *---------------------------------------------------------------------*/ 78 int CreateSecureBootImage(int ac, char **av) 79 { >>> CID 1323511: Null pointer dereferences (FORWARD_NULL) >>> Assigning: "privkey" = "NULL". 80 char *outfile, *configfile, *arg, *privkey = NULL, *bl = NULL; 81 int status = 0; 82 uint32_t sbiLen; 83 struct stat file_stat; 84 uint32_t add_header = 1; 85 outfile = *av; ** CID 1323510: Error handling issues (NEGATIVE_RETURNS) /util/broadcom/secimage/io.c: 81 in DataRead() ________________________________________________________________________________________________________ *** CID 1323510: Error handling issues (NEGATIVE_RETURNS) /util/broadcom/secimage/io.c: 81 in DataRead() 75 len = FileSizeGet(file); 76 if (len < *length) 77 *length = len; 78 else 79 /* Do not exceed the maximum length of the buffer */ 80 len = *length; >>> CID 1323510: Error handling issues (NEGATIVE_RETURNS) >>> "len" is passed to a parameter that cannot be negative. 81 if (fread((uint8_t *)buf, 1, len, file) != len) { 82 printf("Error reading data (%d bytes) from file: %s\n", 83 len, filename); 84 return -1; 85 } 86 fclose(file); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

Re: [coreboot] latest greatest thinkpad with coreboot
by Philipp Stanner 02 Dec '16

02 Dec '16

By the way: Is it true that coreboot consumes more power ( = shorter battery life) than vendor bios? Am 01.12.2016 um 18:04 schrieb ron minnich: > what's the latest best one? What's the battery life like (can't be > worse than this mac pro that's always hot and now seems to have a > life of 90 minutes, always). How much dram/ssd can I jam in it? > > thanks > >

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot December 2016