[coreboot] [RFC] coreboot for businesses
Dear coreboot community members: Marc, Ron, Patrick, Aaron and I have been discussing for a while about how to make coreboot more accessible for businesses. We would like to found a business organization (a.k.a. a coreboot consortium) that helps commercial players out there to become a part of the coreboot community, share marketing materials, and other efforts to promote the use of coreboot in the market place and be successful with coreboot based solutions. If you work for an organization that is using coreboot, developing coreboot, or is just interested in coreboot, please help us learn about your needs and wishes and fill out the following form: http://goo.gl/glhNh5 If you know someone who might be interested, but is not on this mailing list, please forward this message to them. Best regards, Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] FILO 0.6.0 payload bootloader - Bug Reports!
On Tue, Jun 13, 2017 at 10:33 AM Ivan Ivanov wrote: > === If you have some ideas about one or more of FILO problems, please tell > === > > %%% 1st problem - FILO is impossible to build on the modern x86_64 > system (Ubuntu 16.04.2 LTS with gcc 5.4.0) : > ... > CC build/x86/context.o > AS build/x86/switch.S.o > /bin/sh: 1: --32: not found > Makefile:177: error while executing receipt for target > «/home/owner/filo/build/x86/switch.S.o» > make: *** [/home/owner/filo/build/x86/switch.S.o] Error 127 > > No matter what crosscompiling stuff I am trying or what edits I do to > Makefile - it always fails with this error. However it compiles fine > at the 32-bit version of the same OS with the same versions of > packages except for a different architecture > > FILO is probably the only payload which has this problem - and this is > indeed a major problem, because all the major Linux distributions are > abandoning 32-bit soon. To fix this error, most likely the edits of > Makefile are needed, but sadly looks like my skills are not enough to > fix it (spent the whole day without a success) ... > Look at the xcompile script. It seems to not detect your assembler correctly. Your xcompile output should look like this: ~/git/filo/ > sh util/xcompile/xcompile # x86 TARCH_SEARCH= /git/filo/util/crossgcc/xgcc/bin/i386-elf- i386-elf- /git/filo/util/crossgcc/xgcc/bin/i386-eabi- i386-eabi- /git/filo/util/crossgcc/xgcc/bin/x86_64-elf- x86_64-elf- /git/filo/util/crossgcc/xgcc/bin/x86_64-eabi- x86_64-eabi- # elf32-i386 toolchain (i386-elf-gcc) CC_i386:=i386-elf-gcc -Wno-unused-but-set-variable -Wa,--divide -fno-stack-protector -Wl,--build-id=none -fuse-ld=bfd -march=i686 AS_i386:=i386-elf-as LD_i386:=i386-elf-ld.bfd NM_i386:=i386-elf-nm OBJCOPY_i386:=i386-elf-objcopy OBJDUMP_i386:=i386-elf-objdump READELF_i386:=i386-elf-readelf STRIP_i386:=i386-elf-strip AR_i386:=i386-elf-ar # arm TARCH_SEARCH= /git/filo/util/crossgcc/xgcc/bin/armv7a-elf- armv7a-elf- /git/filo/util/crossgcc/xgcc/bin/armv7a-eabi- armv7a-eabi- Warning: no suitable GCC for arm. IASL:=iasl # native toolchain HOSTCC:=gcc > %%% 2nd problem: There are only three "tested" SATA controllers in > FILO built-in "approved" list - and FILO does not even try to > initialize the not-listed controllers, despite that the attempt could > have been successful if tried! By default, FILO just outputs "ahci: > Not using untested SATA controller" message, without any option for a > user to try forcing its usage... The only currently available > workaround for this is to manually edit > *./coreboot/payloads/libpayload/drivers/storage/ahci.c * and remove > two " #if > IS_ENABLED(CONFIG_LP_STORAGE_AHCI_ONLY_TESTED) ... #endif " parts, > > Just disable CONFIG_LP_STORAGE_AHCI_ONLY_TESTED in your libpayload config. > %%% 3rd problem: while trying to access hard drive with commands like > filo> kernel hda:/vmlinuz I am getting the following errors: > > Disk read error dev=1 drive=0 sector=0 > Disk read error dev=1 drive=0 sector=2 > Disk read error dev=1 drive=0 sector=2 > Disk read error dev=1 drive=0 sector=128 > Disk read error dev=1 drive=0 sector=16 > Disk read error dev=1 drive=0 sector=64 > Disk read error dev=1 drive=0 sector=0 > Disk read error dev=1 drive=0 sector=64 > Disk read error dev=1 drive=0 sector=0 > Disk read error dev=1 drive=0 sector=0 > Unknown filesystem type. > > > Error 15: File not found. > > Is there any workaround for this? Or maybe I am using the wrong > commands? If so, please tell - what are the correct FILO real-hardware > commands for trying to boot a Linux kernel thats stored on FAT16 > partition at the beginning of DOS-partitioned MBR hard drive? Or this > is a problem with my hardware? > It seems you would have to look inside of a partition, not just on the raw disk. e.g. hda1:/... > > Best regards, > qmastery > Stefan smime.p7s Description: S/MIME Cryptographic Signature -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Re: coreboot leadership meeting minutes for May 8 & May 22
Guys, it is a bit tricky to prevent discussions in a call when someone brings up a topic, and I'm not sure that blocking that is useful. The meetings are open and particularly people commenting here have been invited to the calls. Please make use of that opportunity and join, if you think that you have a strong opinion. In this case, I made the suggestion to look at what is located in each heater file and cone up with clear interfaces, rather than jumping into the next "let's make coreboot source more similar to go by removing headset file guards" discussion. On Thu, 23 May 2019, 16:43 Julius Werner, wrote: > > >* We should be more strict about how we define our blocks’ APIs. > > > > Ok, but.. I just don't understand this proposal? Can someone explain? > > I second this... this sounds like another code style > discussion/change. Can we please keep all code style discussions on > the mailing list? Or if there really needs to be a VC meeting for such > a discussion, can it be pre-announced so everyone interested can > participate? > smime.p7s Description: S/MIME Cryptographic Signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: More coding style change proposals
On 20 Jun 2019 08:26, ron minnich wrote:clang-format is not a textual preprocessor. It is basically the ast
builder of followed by output.
So in your case, I just tried it
main() {
if (foo)
bar();
baz();
}
and got the right thing, i.e. braces around bar but not baz.
The right thing (e.g. the obviously intended thing) would be too have braces around both. clang-format in this case masks the problem and makes it harder to identify by expanding the syntax of the unwanted behavior to look intentional.Stefan
The history of reviewers looking at code is they miss this kind of
error. Constantly. I'm in favor of as much automation as we can get.
ron
On Thu, Jun 20, 2019 at 5:25 AM Nico Huber wrote:
>
> On 20.06.19 06:01, Jacob Garber wrote:
> > On Wed, Jun 19, 2019 at 08:38:14PM -0700, ron minnich wrote:
> >> Given the number of serious problems that lack of braces causes, I
> >> like this proposal. It's indicative that both Rust and Go require the
> >> {}, for reasons of safety.
> >
> > There was a famous vulnerability in Apple's SSL code several years ago
> > because of lack of braces. clang-format can also reformat old code to have
> > mandatory braces if I'm not mistaken.
>
> What will clang-format do if it encounters?
>
> if (foo)
> bar();
> baz();
>
> a)
> if (foo) {
> bar();
> }
> baz();
>
> or b)
> if (foo) {
> bar();
> baz();
> }
>
> Will it spit out a warning? If not, this shows how dangerous automatic
> formatting can be. Because after the formatter run, it's much less ob-
> vious for the reviewer that something is wrong.
>
> Nico
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Does NSA contribute to Coreboot?
Remember that the project was started by Los Alamos National Labs (LANL), the guys that also brought you the Manhattan Project.Contributions have also been made by the BSI (German version of the NSA) and their contractors.On 22 Jun 2019 21:30, Anac wrote:Dear all, Is it true that there's code provided by the NSA implemented in Coreboot? https://www.tomshardware.com/news/nsa-contributes-low-level-stm-coreboot,39704.html Any thoughts? Cheers ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
