[coreboot] Re: cgit on review.coreboot.org
Hi Julius, Appending "?format=TEXT" to the file link in Gitiles (the "txt" link at the bottom of the page) will give a base64-encoded copy of the file. Regards, Benjamin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: link time optimization testing - Was: Re: asus/p2b - not enough space in cbfs for default build since i440bx bootblock console enable
On 5/25/21, Paul Menzel wrote: > Dear Branden, > > > Am 22.05.21 um 20:03 schrieb Branden Waldner: >> On 5/21/21, Arthur Heymans wrote: > >>> Thanks for sharing your findings. The flash is 256K big, which is quite >>> small these days. >>> When building coreboot with default settings but without a payload I >>> find >>> that there is 69K empty space left for payloads. >>> >>> Some future developments I have been working on might give a bit more >>> breathing space. >>> - I want to make romstage optional and include the sources in the >>> bootblock: That should shave off roughly 10K of romstage. >>> - I have compressing postcar working (maybe you can also disable the >>> postcar console to reduce size). That's also 2-3k size gains >>> at likely the const of a tiny bit of boot performance on this platform. >>> - I also have some WIP code to merge postcar into ramstage which would >>> save >>> 15k. >>> >>> Maybe on coreboot release 4.15 you will have a better time building a >>> fully >>> working image with the default configuration. > >> I didn't realize there was development going on to save rom space, >> that's good to know. > > I just built the asus/p2b from commit d981c490 (mb/google/mancomb: > Enable some PCIe power saving features) with the Debian sid/unstable > toolchain (gcc (Debian 10.2.1-6) 10.2.1 20210110). > > There, wasn’t enough space to add SeaBIOS’ configuration file to CBFS. > Not setting `INCLUDE_CONFIG_FILE`, there wasn’t any error, the coreboot > image built fine. > > ``` > FMAP REGION: COREBOOT > Name Offset Type Size Comp > cbfs master header 0x0cbfs header32 none > fallback/romstage 0x80 stage 17336 none > cpu_microcode_blob.bin 0x44c0 microcode 83968 none > fallback/ramstage 0x18d00stage 53376 LZMA > (112168 decompressed) > build_info 0x25e00raw89 none > fallback/dsdt.aml 0x25e80raw 5514 none > cmos_layout.bin0x27440cmos_layout 704 none > fallback/postcar 0x27740stage 16888 none > fallback/payload 0x2b980simple elf 69886 none > (empty)0x3cac0null 1956 none > bootblock 0x3d280bootblock 11088 none > ``` > > Building with Jacob’s link time optimization changes [1], which he > thankfully rebased, saved 13 kB, so the configuration file would fit in > too. > > ``` > FMAP REGION: COREBOOT > Name Offset Type Size Comp > cbfs master header 0x0cbfs header32 none > fallback/romstage 0x80 stage 14752 none > cpu_microcode_blob.bin 0x3ac0 microcode 83968 none > fallback/ramstage 0x18300stage 46277 LZMA > (95496 decompressed) > build_info 0x23840raw89 none > fallback/dsdt.aml 0x238c0raw 5514 none > cmos_layout.bin0x24e80cmos_layout 704 none > fallback/postcar 0x25180stage 14872 none > fallback/payload 0x28c00simple elf 69886 none > (empty)0x39d40null15012 none > bootblock 0x3d800bootblock9664 none > ``` > > (If you have a recovery option and some spare time, it’d be great if you > tested the LTO patches.) I could probably test them out, though I'm not sure I'll get around to it right away. Does the patch set require anything special? It looks like it just uses a Kconfig to add the choice to use the LTO compiler options. Does it work with the coreboot crossgcc or should I try using the system compiler on the build machine like you did (Debian sid x86_64), or maybe it would be best to try both? My recovery method isn't very good right now though. If I've got a boot failure I change the rom to a known good one and hot swap back to the chip with the bad rom to reflash it. It's pretty annoying, but I haven't messed up yet. I did try to get some (cheap) zif adapter sockets, but they didn't work out for me - not enough space and they don't seat in a socket, they seem to be meant to be soldered to a board, not used in a socket. I haven't had much luck in finding options for recovery. Ideally I'd like something like the dual switched bios in the old wiki but toggle-able electronically ie. gpio pin from spare router w/ Openwrt. That sounds like a lot of work though and I never managed to find much online as examples. > > Kind regards, > > Paul > > > [1]: https://review.coreboot.org/c/coreboot/+/40815/ > (whole series) > Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] cgit on review.coreboot.org
Hi Patrick, Martin, I just noticed that we seem to have dropped support for cgit on the coreboot Gerrit. I don't exactly remember how it worked, but I seem to have been able to get a link like https://review.coreboot.org/cgit/qc_blobs.git/plain/sc7180/qtiseclib/libqtisec.a some time last year. Now that just redirects to Gitiles. The problem with Gitiles is it's impossible to just get a direct download link to a file -- you can only see source files in the browser view (with the Gitiles UI on the side), but you can't download the raw file exactly as it is in the repo. This is especially problematic for binary files where there is (as far as I can tell? Maybe I just can't find it...) no way to get their contents at all without downloading a whole tarball of a directory and extracting it (which is pretty cumbersome). Do you guys know why this happened and is there any chance we could get cgit back? Thanks, Julius ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: What should we do about freenode IRC services?
Patrick Georgi via coreboot wrote: > So, what should we do? I don't think it's a horrible idea to just chill and see what happens. I find it interesting that christel seems invested in the Handshake project. //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: failure cherry-picking patches from https://review.coreboot.org/coreboot
Hi Selma, Bensaid, Selma wrote: > FYI, we are observing the same issue today on chromium coreboot repo > https://chromium-review.googlesource.com/admin/repos/chromiumos/third_party/coreboot > I think we need to figure out a proper solution. Thanks for providing the debug output! So since the issue does stem from a large distance between branches and hitting network communication limits maybe an effective workaround would be to maintain a local clone of the upstream repo (in a separate repo) and using a file:// URL pointing to that repo for the origin remote in your working repo? The upstream clone must be on the same machine, so it's more overhead, but file:// should be reliable. HTTP, regardless of version, is really inappropriate for applications. //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: What should we do about freenode IRC services?
On Tue, May 25, 2021 at 03:00:51PM +0200, Patrick Georgi via coreboot wrote: > Hi everybody, > > you might have heard that freenode.org recently changed management under > weird circumstances. Given that we use their services for our project chat, > this concerns us as well. > > In last week's leadership meeting we had a wide variety of opinions: To go > for libera.chat (a network created by former freenode staff), some other IRC > network, to leave IRC behind and go for something newer and Matrix and > Mattermost have been brought up as examples of where this might lead. Of > course, we could also decide to stay on freenode, although from what > transpires that option seems less and less attractive every day. > > So, what should we do? I want some sort of IRC still, but not on freenode. I'm comfortable with either libera or OFTC, but would also tolerate a coreboot & friends IRC server if required to bridge to some sort of more complicated system that others may want more than IRC. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: google/sarien (Dell Chromebook): Recovery options
On Tue, May 25, 2021 at 4:40 AM Paul Menzel wrote: > > Dear coreboot folks, > > > In a few days I am going to get my hands on a Dell Latitude 5400 > Chromebook Enterprise (google/sarien) [1][2], and my goal is to install > upstream coreboot on it. > > According to *Developer Information for Chrome OS Devices* [1], Case > Closed Debugging (CCD) [3] is not supported, which is unfortunate, as > the flash ROM chip is a WSON-8 package, which I do not have equipment > for to flash externally. > > Do you have some tips what options there are in case of a bad flash? > There are pads for a legacy Servo v2 header on the board, but the header itself may be unstuffed by default in production devices. -duncan ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: ec/google/wilco: Details on EC firmware
On Tue, May 25, 2021 at 4:57 AM Paul Menzel wrote: > Dear coreboot folks, > > > Some Google Chromebooks come with a Google Wilco EC (EC_GOOGLE_WILCO) > instead of Google Chrome EC. coreboot implements the interface for the > Google Wilco EC. > > Unfortunately, I was unable to find more details on the firmware. > Phoronix claims is “open-source firmware” [1]. > > It’d be great if somebody could provide some details. > > The Wilco EC firmware is a modified version of Dell's typical Latitude EC that implements a custom mailbox protocol similar to the one we use in the Chromium EC. This particular EC firmware is not open source unfortunately, just the host-side interfaces (kernel and firmware drivers). -duncan ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: What should we do about freenode IRC services?
On Tue, 25 May 2021 15:08:23 +0200 Jonathan Neuschäfer wrote: > As far as other IRC networks go, OFTC is another popular choice among > those leaving Freenode. > > Matrix sounds good, especially because it can be bridged to an IRC > channel. I'd be sad to see coreboot disappear from IRC entirely, but > I think a combined Matrix/IRC channel is a good way forward. +1 The important thing (for myself anyway) is that the bridge can be part of an existing network. Mattermost supports a bridge directly but you have to connect your irc client to that bridge instead of the bridge joining a channel. I am using that for one project but it's not ideal from my PoV. IIRC there was already another bridge to some MM server that worked differently in the past. What's the status of that, Patrick? I personally am already on libera and OFTC so I don't really care which of those two. AFAICT the vast majority of my channels has moved to libera. Some have not decided yet, and 0 went to OFTC. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: What should we do about freenode IRC services?
On Tue, May 25, 2021 at 03:00:51PM +0200, Patrick Georgi via coreboot wrote: > Hi everybody, > > you might have heard that freenode.org recently changed management under > weird circumstances. Given that we use their services for our project chat, > this concerns us as well. > > In last week's leadership meeting we had a wide variety of opinions: To go > for libera.chat (a network created by former freenode staff), some other IRC > network, to leave IRC behind and go for something newer and Matrix and > Mattermost have been brought up as examples of where this might lead. Of > course, we could also decide to stay on freenode, although from what > transpires that option seems less and less attractive every day. > > So, what should we do? As far as other IRC networks go, OFTC is another popular choice among those leaving Freenode. Matrix sounds good, especially because it can be bridged to an IRC channel. I'd be sad to see coreboot disappear from IRC entirely, but I think a combined Matrix/IRC channel is a good way forward. Best regards, Jonathan Neuschäfer signature.asc Description: PGP signature ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] What should we do about freenode IRC services?
Hi everybody, you might have heard that freenode.org recently changed management under weird circumstances. Given that we use their services for our project chat, this concerns us as well. In last week's leadership meeting we had a wide variety of opinions: To go for libera.chat (a network created by former freenode staff), some other IRC network, to leave IRC behind and go for something newer and Matrix and Mattermost have been brought up as examples of where this might lead. Of course, we could also decide to stay on freenode, although from what transpires that option seems less and less attractive every day. So, what should we do? Regards, Patrick ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: asus/p2b - not enough space in cbfs for default build since i440bx bootblock console enable
Dear Branden, Am 22.05.21 um 20:03 schrieb Branden Waldner: On 5/21/21, Arthur Heymans wrote: Thanks for sharing your findings. The flash is 256K big, which is quite small these days. When building coreboot with default settings but without a payload I find that there is 69K empty space left for payloads. Some future developments I have been working on might give a bit more breathing space. - I want to make romstage optional and include the sources in the bootblock: That should shave off roughly 10K of romstage. - I have compressing postcar working (maybe you can also disable the postcar console to reduce size). That's also 2-3k size gains at likely the const of a tiny bit of boot performance on this platform. - I also have some WIP code to merge postcar into ramstage which would save 15k. Maybe on coreboot release 4.15 you will have a better time building a fully working image with the default configuration. I didn't realize there was development going on to save rom space, that's good to know. I just built the asus/p2b from commit d981c490 (mb/google/mancomb: Enable some PCIe power saving features) with the Debian sid/unstable toolchain (gcc (Debian 10.2.1-6) 10.2.1 20210110). There, wasn’t enough space to add SeaBIOS’ configuration file to CBFS. Not setting `INCLUDE_CONFIG_FILE`, there wasn’t any error, the coreboot image built fine. ``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0cbfs header32 none fallback/romstage 0x80 stage 17336 none cpu_microcode_blob.bin 0x44c0 microcode 83968 none fallback/ramstage 0x18d00stage 53376 LZMA (112168 decompressed) build_info 0x25e00raw89 none fallback/dsdt.aml 0x25e80raw 5514 none cmos_layout.bin0x27440cmos_layout 704 none fallback/postcar 0x27740stage 16888 none fallback/payload 0x2b980simple elf 69886 none (empty)0x3cac0null 1956 none bootblock 0x3d280bootblock 11088 none ``` Building with Jacob’s link time optimization changes [1], which he thankfully rebased, saved 13 kB, so the configuration file would fit in too. ``` FMAP REGION: COREBOOT Name Offset Type Size Comp cbfs master header 0x0cbfs header32 none fallback/romstage 0x80 stage 14752 none cpu_microcode_blob.bin 0x3ac0 microcode 83968 none fallback/ramstage 0x18300stage 46277 LZMA (95496 decompressed) build_info 0x23840raw89 none fallback/dsdt.aml 0x238c0raw 5514 none cmos_layout.bin0x24e80cmos_layout 704 none fallback/postcar 0x25180stage 14872 none fallback/payload 0x28c00simple elf 69886 none (empty)0x39d40null15012 none bootblock 0x3d800bootblock9664 none ``` (If you have a recovery option and some spare time, it’d be great if you tested the LTO patches.) […] Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/40815/ (whole series) ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] ec/google/wilco: Details on EC firmware
Dear coreboot folks, Some Google Chromebooks come with a Google Wilco EC (EC_GOOGLE_WILCO) instead of Google Chrome EC. coreboot implements the interface for the Google Wilco EC. Unfortunately, I was unable to find more details on the firmware. Phoronix claims is “open-source firmware” [1]. It’d be great if somebody could provide some details. Kind regards, Paul [1]: https://www.phoronix.com/scan.php?page=news_item=ChromeOS-Wilco-EC-Linux ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] google/sarien (Dell Chromebook): Recovery options
Dear coreboot folks, In a few days I am going to get my hands on a Dell Latitude 5400 Chromebook Enterprise (google/sarien) [1][2], and my goal is to install upstream coreboot on it. According to *Developer Information for Chrome OS Devices* [1], Case Closed Debugging (CCD) [3] is not supported, which is unfortunate, as the flash ROM chip is a WSON-8 package, which I do not have equipment for to flash externally. Do you have some tips what options there are in case of a bad flash? Kind regards, Paul [1]: https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices [2]: https://www.dell.com/en-us/work/shop/dell-laptops-and-notebooks/dell-latitude-5400-chromebook-enterprise/spd/latitude-14-5400-chrome-laptop/xctolc540014us1 [3]: https://chromium.googlesource.com/chromiumos/platform/ec/+/cr50_stab/docs/case_closed_debugging.md ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
