April 2016 - coreboot - mail.coreboot.org

A talk about coreboot
by Iru Cai April 10, 2016

April 10, 2016

Hi community, I gave a talk about coreboot in my LUG yesterday, and here's my slides. https://bdwm.net/attach/boards/Linux/M.1460223002.A/coreboot-talk.pdf Iru

3 3

Re: [coreboot] A talk about coreboot
by Ron Minnich April 9, 2016

April 9, 2016

On Sat, Apr 9, 2016 at 11:49 AM Vadim Bendebury <vbendeb(a)chromium.org> wrote: > Wow, looks like it was an excellent talk, thank you for sharing the slides! > > Should we expect an influx of contributions from China now? :) > > > but seriously :-) from the very beginning, we've had great contributions from China. This is one more fine example. Thanks very much Iru! ron

1 0

(no subject)
by Jean Reus April 9, 2016

April 9, 2016

Hello guys I ama chromebook toshiba 2 owner, and have obviously installed linux with your grate bios, but is there a way to add a overclock option to it or guide me how to compile one with it. Thanks in advence Jean Reus

1 0

Re: [coreboot] Alix 2d13 coreboot breaking source
by Reto Rayen April 8, 2016

April 8, 2016

Hi Patrick Yes i rebuild the Compilers after every coreboot build. So the steps where 1.) Git bisect start 2.) Git bisect good <commit> 3.) Git bisect bad <commit> 4.) Make crossgcc-i386 5.) Make 6.) Check the coreboot Image live on physical alix 7.) Make clean 8.) Make crossgcc-clean 9.) Git bisect bad/good 10.) Start over at step 4 again and so on… until found breaking commit. Gesendet von Mail<https://go.microsoft.com/fwlink/?LinkId=550986> für Windows 10 Von: Patrick Georgi<mailto:pgeorgi@google.com> Gesendet: Freitag, 8. April 2016 22:05 An: Reto Rayen<mailto:retorayen@hotmail.com> Cc: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org> Betreff: Re: [coreboot] Alix 2d13 coreboot breaking source Just to clarify: Did you rebuild the compilers after applying that commit? It doesn't touch anything that ends up affecting the coreboot binaries with a given toolchain. 2016-04-08 21:47 GMT+02:00 Reto Rayen <retorayen(a)hotmail.com>: > Hi guys > > > > Finally i found out, which git commit broke coreboot to build for a «Alix > 2d13». I used «git bisect» recommended by «PaulePanther» in october 2015 to > identify the commit. A doc about the different git commits and their results > can be found here: > https://file.youngsolutions.ch/index.php/s/g2cixjqepvTwJhR > > > > Commit which breaks coreboot for successfull buid: > 53c388fe6dfb4fc4ffcee6c58345d353c6ec33bf (crossgcc: Update toolchain) > > > > So what the next steps, to get coreboot working with the latest build for > Alix 2d13? > > > > Thank your guys, for your help so far. > > > > Kind regards > > Reto Rayen > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

1 0

Alix 2d13 coreboot breaking source
by Reto Rayen April 8, 2016

April 8, 2016

Hi guys Finally i found out, which git commit broke coreboot to build for a «Alix 2d13». I used «git bisect» recommended by «PaulePanther» in october 2015 to identify the commit. A doc about the different git commits and their results can be found here: https://file.youngsolutions.ch/index.php/s/g2cixjqepvTwJhR Commit which breaks coreboot for successfull buid: 53c388fe6dfb4fc4ffcee6c58345d353c6ec33bf (crossgcc: Update toolchain) So what the next steps, to get coreboot working with the latest build for Alix 2d13? Thank your guys, for your help so far. Kind regards Reto Rayen

2 1

Re: [coreboot] Cleaning up old commits in gerrit
by Alexander Couzens April 8, 2016

April 8, 2016

> We're looking at cleaning up gerrit, so we're planning on abandoning > some older commits. To keep from overwhelming people, we're going to > do it in stages. Right now we're looking at abandoning all commits > that haven't been updated in 18 Months. This is around 90 commits. nice you're doing this. -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

2 1

Re: [coreboot] ASUS KFSN4-DRE (K8) Automated Test Failure [master]
by Timothy Pearson April 8, 2016

April 8, 2016

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/08/2016 11:29 AM, Raptor Engineering Automated Coreboot Test Stand wrote: > The ASUS KFSN4-DRE (K8) fails verification for branch master as of commit 5a577251263369d259bee033e41584d7c562ca6d > > The following tests failed: > BOOT_FAILURE This is a false positive; please ignore. The K8 hardware is aging and has some sporadic reliability issues at this point. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) http://www.raptorengineeringinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJXB96uAAoJEK+E3vEXDOFbrBMIAJz+RGn5iYmzvsJo8I2ZKIP7 PMjBw1/bf/wSSV1Io22r9nQqLNnjtU21ElA57ifvPiO4JL0IxOh1SIWIimvo9pr9 e0NCun4irjVgTLiXdLKQivxLaSCINhwbkvDUpVWDOi6UpWmOiJiZQux1/pa0T9WA noMumDblqST41SacedxZlqU7Ila1SBAAc8kbJDg0d7kN6+cnCBtXoh7QkyUKf3m9 Cz5ULp2qNu7pf5Xi5BVjNvRcKDz7xOpB24VKBAVFJv6m12w75P0WcAq80Kfmf/b/ ImaPaSXPchYQ9Is0GQm6Qg8wLrjoAh/URmHIQFzZhkQInq3Swu/tGwi8xxaDams= =BKwB -----END PGP SIGNATURE-----

1 0

Re: [coreboot] Linux as payload
by Patrick Rudolph April 8, 2016

April 8, 2016

On 2016-04-07 06:31 PM, daoud yessine wrote: > Hi > > how to build coreboot with linux as payload ? > I need Bzimage only ? > what about the file system ? > > thanks > ᐧ Hello, I'm using a linux payload. Here are a few pitfalls you should mind: * Fedora's prebuild kernel doesn't work any more. You likely want to compile it yourself. * Self compiled kernel does work. Tested versions are: Linux 4.1, 4.2, 4.3, 4.4 * I don't enable pre kernel GPU initialization The screen is black until the drm kernel module is started. * Make sure to add support for your root filesystem (ext2/3/4 is default) Others need to be compiled in, or you need to provide a initramfs containing the kernel modules for the filesystem. I compiled them in, instead of using a initramfs. * Make sure to give a working root path (PARTUUID is fine, too) * Initramfs isn't used by me, so I can't tell if it's working, but it should. Kind Regards, Patrick

2 1

Re: [coreboot] Linux as payload
by Martin Roth April 8, 2016

April 8, 2016

You'll want both. The file system is what goes in the initrd config option Add a payload (A Linux payload) ---> (bzImage) Linux path and filename () Linux command line () Linux initrd Martin On Thu, Apr 7, 2016 at 10:31 AM, daoud yessine <yessine.daoud.92(a)gmail.com> wrote: > Hi > > how to build coreboot with linux as payload ? > I need Bzimage only ? > what about the file system ? > > thanks > ᐧ > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Regarding offset adjustment for building coreboot.
by Martin Roth April 8, 2016

April 8, 2016

Not knowing which platform this is makes it a little harder to determine what's locked in place. We'd also need to know if this is getting built from the top of the coreboot.org tree, an old coreboot.org commit or an private repo with many changes from coreboot.org. Microcode should be able to be placed in any area for most of the FSP platforms, but it might need to be changed in Kconfig or the Makefile so that the system knows where it is. You might also want to look at just including the necessary microcode patches for your particular board if possible. Many of the FSP platforms include all available microcode back to some pre-production parts by default. The mrc cache can be moved at build time, but needs to be on the correct boundary, and CANNOT have anything else in the same sector on the flash. The cache gets erased, so moving it to an odd boundary or putting other things in the same sector will cause interesting issues. The FSP itself can also be moved, but it needs to be rebased with intel's FITC tool, and coreboot needs to know the location at build time. Finally, you might want to look at leaving out the small or non-essential files, and add them after the build completes to make sure that there is contiguous space for your essential components: bootsplash.img, config, fspd.bin and cmos_layout.bin Martin On Fri, Apr 8, 2016 at 4:29 AM, Patrick Georgi via coreboot <coreboot(a)coreboot.org> wrote: > 2016-04-08 11:17 GMT+02:00 Nico Huber <nico.huber(a)secunet.com>: >> you also stripped: >> >> fallback/payload 0x1b140 payload 769955 >> >> I guess he means that a fresh build with a bigger (865KiB instead of >> 752KiB) payload fails. > Of course you're right. I misunderstood the original issue. > > It's hard to tell how locked down various files are. There's at least > some alignment going on for cpu_microcode_blob.bin, mrc.cache, > uefi_nvs.bin and fsp.bin, but there may be more to it. > > Tweaking -position and -align values for mrc.cache and uefi_nvs.bin > should provide enough space for a larger payload. > Given that uefi_nvs.bin is not mentioned in current master, I have no > idea how that came to be. > > > Patrick > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0