coreboot April 2018

coreboot@coreboot.org

68 participants
128 discussions

Problem with tianocore compilation in coreboot-sdk:1.50
by Piotr Król 04 Apr '18

04 Apr '18

Hi all, I can't compile tianocore payload using coreboot-sdk:1.50 and coreboot 4.7. VfrUtilityLib.cpp: In member function 'CHAR8* CVfrStringDB::GetVarStoreNameFormStringId(EFI_STRING_ID)': VfrUtilityLib.cpp:3375:26: error: ISO C++ forbids comparison between pointer and integer [-fpermissive] if (mStringFileName == '\0' ) { I think this is not a single issue. Key problem is that tianocore do not support modern toolchains - it requires GCC5. I have no problem when compiling with 3mdeb/edk2-docker container which use GCC5. I can workaround that problem by including payload as elf file, but if we have integration we should make sure it works. I'm not sure how coexistence of 3 toolchain should be solved to serve stable build environment. In coreboot-sdk we have 2 toolchains native Debian GCC7.2 and coreboot toolchain GCC6.3. If we want stable build environment for tianocore payload we should have 3rd - GCC5. Options to solve that problem: 1. Add another toolchain, which would be selected somehow through Makefile logic when tianocore payload selected 2. Add patches in coreboot to support GCC7 or GCC6 - this may cause unexpected behavior and maintaining this support out of edk2 can be problematic 3. Add patches in edk2 to support GCC7 or GCC6 - I think this is long and hard road 4. Any other that I'm missing ? In light of coreboot-sdk I have one question that bugs me for long time. Why we use Debian sid? Each build using moving target can be different what means it is hard to build 2 the same coreboot-sdk containers. Best Regards, -- Piotr Król Embedded Systems Consultant http://3mdeb.com | @3mdeb_com

2 1

Problems with NVidia on Lenovo ThinkPad T430
by Tobias Dausend 04 Apr '18

04 Apr '18

Hello everybody! I have problems with getting coreboot running on a Lenovo ThinkPad T430. Better to say: Running with the integrated second graphics adapter NVS 5400M. The Intel HD 4000 is working fine and from the wiki I know that NVidia Optimus is not supported for now. So what to do exactly getting the graphics adapter running? Even only NVidia only would be great. Both adapters are not needed on GNU-Linux for my usecase. I have two VGA-ROMs extracted and compiled this using the concurrent stable-version 4.7. Is this wrong? Some help and hints would be appreciated. Best regards, Tobias.

2 4

Re: [coreboot] Problems with NVidia on Lenovo ThinkPad T430
by Michał Kopeć 04 Apr '18

04 Apr '18

> > Hello Tobias, > > > > You can switch between GPUs by changing the value of the > > hybrid_graphics_mode CMOS setting using nvramcui or nvramtool. > > Currently, for the T430 this field can be set to either Integrated > only > > or Dedicated only. Make sure you are using CMOS for configuration > > values. Unfortunately, I was unable to switch the power for the dGPU > > off at all, which resulted in rather high power consumption even if > > only the integrated GPU is enabled. > > > > Regards, > > Micha? Kope? > > > Hello, > > thanks for the feedback. What version of Coreboot did you use? Is the > stable 4.7 enough or should I use a snapshot from the git-repository? > Also the question how to include the VGA-bios for the NVidia-card. I > did > a compilation with the VGA-bios for Intel and included the rom > afterwards with cbfstool. Is this the correct way to do as "optional > rom"? > > Thanks! > > Regards, > Tobias. Hello, I'm currently using the latest Git snapshot on my machine. I also compiled with the Intel option rom and added the nvidia option rom using cbfstool after, like you did. I haven't tried 4.7, so I couldn't tell you how it works there. Regards, Michał Kopeć

1 0

Re: [coreboot] VbTryLoadKernel restriction on 512 byte sector size
by mturney＠codeaurora.org 04 Apr '18

04 Apr '18

On 2018-04-03 10:02, Aaron Durbin via coreboot wrote: > On Tue, Apr 3, 2018 at 10:26 AM, <mturney(a)codeaurora.org> wrote: >> Folks, >> Can anyone on this list expound on why VbTryLoadKernel() performs a >> sanity-check on bytes_per_lba != 512? > >> ------->-------/* >> ------->------- * Sanity-check what we can. FWIW, VbTryLoadKernel() is >> always >> ------->------- * called with only a single bit set in get_info_flags. >> ------->------- * >> ------->------- * Ensure 512-byte sectors and non-trivially sized disk >> (for >> ------->------- * cgptlib) and that we got a partition with only the >> flags we >> ------->------- * asked for. >> ------->------- */ > > Seems to do with cgptlib having a 512 byte assumption. I'm not sure > what would break if that check was removed. We'd have to look at > cgptlib and other uses. Please file a Google issue tracker bug so we > can properly drive this. https://issuetracker.google.com/77540192 > >> >> We are working on supporting a board that will require bytes_per_lba >> == 4K. >> Cheers, >> T.mike >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Upgrade the 12 years old LZMA libraries - should we do it?
by Zoran Stojsavljevic 03 Apr '18

03 Apr '18

Privet Ivan, I would say that Coreboot should go for the greatest and latest. Since everything from far back in Time is refined, mostly bug free (unless the new releases do not include some new introduced bugs, which are fixed (usually) in immediate releases). This is more matter of the right chosen strategy, which every package and/or library should follow. Zoran _______ On Tue, Apr 3, 2018 at 8:03 PM, Ivan Ivanov <qmastery16(a)gmail.com> wrote: > I have noticed that both coreboot and seabios are using the very old > versions of LZMA SDK. If we will upgrade our LZMA libraries from the > outdated-by-12-years 4.42 to the current version 18.04 , speed and > compression ratio should improve and maybe a few bugs will be fixed. > Do you think it should be done, or you are OK with using such an > outdated version? > > Best regards, > Ivan Ivanov aka qmastery > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Fwd: POST cards, I/O ports and M.2 to MiniPCIe
by Trammell Hudson 03 Apr '18

03 Apr '18

On Tue, Apr 03, 2018 at 06:32:07PM +0300, Kyösti Mälkki wrote: > [...] > > I'm dealing an early bring-up problem on a modern architecture without > > serial ports and wondering if that would a good way to debug it. > > Probably M.2 is not very useful for you... try to look for LPC > signals, some boards have TPM add-on connector with the required > signals for POST display. That's a good idea, although on this board the TPM is very hard to get to, which is nice for moderate physical security, but not great for debugging. I'm bummed that the LPC lines aren't brought out to the M.2 and MiniPCIe; perhaps I'll find an alternate use of the boards when they arrive. What ended up working for me was the PC speaker since there is no other I/O available so early. I'd really like to thank Uwe Hermann and the other devs of libpayload/speaker.c -- I was able to port their driver functions to execute very soon after the reset vector and confirm code execution with beeps and busy waiting. -- Trammell

3 2

Upgrade the 12 years old LZMA libraries - should we do it?
by Ivan Ivanov 03 Apr '18

03 Apr '18

I have noticed that both coreboot and seabios are using the very old versions of LZMA SDK. If we will upgrade our LZMA libraries from the outdated-by-12-years 4.42 to the current version 18.04 , speed and compression ratio should improve and maybe a few bugs will be fixed. Do you think it should be done, or you are OK with using such an outdated version? Best regards, Ivan Ivanov aka qmastery

1 0

VbTryLoadKernel restriction on 512 byte sector size
by mturney＠codeaurora.org 03 Apr '18

03 Apr '18

Folks, Can anyone on this list expound on why VbTryLoadKernel() performs a sanity-check on bytes_per_lba != 512? We are working on supporting a board that will require bytes_per_lba == 4K. Cheers, T.mike

2 1

Re: [coreboot] [RFC] Fix undefined behavior with left shifts in whole code base
by ron minnich 03 Apr '18

03 Apr '18

I refer you to the following code: https://github.com/hephaex/unix-v6/blob/daa355109625a50e6b1080184dee30c9136… It's this: /* * structure to access an * integer in bytes */ struct { char lobyte; char hibyte; }; What's the point? The point is code linke this: lpr = (tp->t_speeds.hibyte<<10) ... note how we're treating t_speeds like it's that anon struct above. how's that happen? What's t_speeds? int t_speeds; /* output+input line speed */ Wait, what? I could just take an int variable, then use an anon struct to break it into bits? Yes, I could. This is C, 1976. The point is, C changes over time, and so does how you use it. At some point people realized this model was kind of dangerous, and over the objections of many people, the inconvenience of type checking came in. The changes in C are so pervasive that when Dennis checked, years later, the original C compilers ... were no longer C. They would not compile. The rule over the years is that you should always err in favor of compiler level checking of your code, even when it adds lots of inconvenience, as people make mistakes. So I would actually be in favor of what paul is advocating, but not the inconistency. To keep it consistent, I don't see that just using 1U everywhere is that huge a deal. C is not that pretty any more, so this little bit of ugliness doesn't strike me as a big deal. Bugs from stuff like 3<<31 scare me more. Just my $.02 ron On Fri, Feb 16, 2018 at 2:38 PM Julius Werner <jwerner(a)chromium.org> wrote: > I’d really like to *enable as much warnings* as possible to let the >> build tools *catch as much errors as possible*, and having to adapt the >> code to work with this is in my opinion worth the effort. >> > > This is not just a question of whether we want to spend the one-time > effort to adapt the code. It will be a constant readability issue going > forward. Almost no project out there writes shifts like that and almost no > programmer is used to reading them like that. I agree that automated > sanitizer coverage is a very good thing, but it is not the only thing that > matters. If a sanitizer tool forces us two rewrite code in a way that > creates serious friction for day-to-day development, then maybe we need to > wait until the authors of that tool add options to make it less aggressive > in that regard. GCC has already recognized the insanity of reporting that > construct as an error every time and thus given us the -Wshift-overflow=1 / > -Wshift-overflow=2 distinction, so I hope the UBSAN guys may eventually get > there as well. > > For now, I think we should deactivate the whole shift test (I'm not an > UBSAN expert but from the documentation it sounds like > -fno-sanitize=shift-base should work), and then we'll still get the vast > majority of coverage without imposing excessive hoops to jump through onto > developers. > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Fwd: POST cards, I/O ports and M.2 to MiniPCIe
by Kyösti Mälkki 03 Apr '18

03 Apr '18

Hi On Tue, Apr 3, 2018 at 5:36 PM, Trammell Hudson <hudson(a)trmm.net> wrote: > How soon after reset are port 0x80 messages available on a MiniPCIe > attached POST card? And would the POST card be expected to work with > a M.2 to MiniPCIe adapter? How is the ISA bus' I/O address space mapped > to PCIe devices? > First read this: https://mail.coreboot.org/pipermail/coreboot/2018-February/086178.html So those POST displays are not PCIe at all but LPC. Some bits to route IO port 0x80 to LPC is typically set early in romstage but it could be done in bootblock if needed. The low end of IO range 0x0..0x1000 is usually reserved for integrated devices within SoC or PCH with fixed assignments. > I'm dealing an early bring-up problem on a modern architecture without > serial ports and wondering if that would a good way to debug it. Probably M.2 is not very useful for you... try to look for LPC signals, some boards have TPM add-on connector with the required signals for POST display. Certain mini-PCI-e serial port cards and usbdebug are better alternatives and can work for early romstage. But I guess you no longer have EHCI controller and the tree does not have xHCI debugging in production quality at least. HTH Kyösti

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot April 2018