Dear Branden,

Am 26.05.21 um 04:25 schrieb Branden Waldner:
On 5/25/21, Paul Menzel wrote:

Am 22.05.21 um 20:03 schrieb Branden Waldner:
On 5/21/21, Arthur Heymans <art...@aheymans.xyz> 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             0x0        cbfs header        32 none
fallback/romstage              0x80       stage           17336 none
cpu_microcode_blob.bin         0x44c0     microcode       83968 none
fallback/ramstage              0x18d00    stage           53376 LZMA (112168 
decompressed)
build_info                     0x25e00    raw                89 none
fallback/dsdt.aml              0x25e80    raw              5514 none
cmos_layout.bin                0x27440    cmos_layout       704 none
fallback/postcar               0x27740    stage           16888 none
fallback/payload               0x2b980    simple elf      69886 none
(empty)                        0x3cac0    null             1956 none
bootblock                      0x3d280    bootblock       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             0x0        cbfs header        32 none
fallback/romstage              0x80       stage           14752 none
cpu_microcode_blob.bin         0x3ac0     microcode       83968 none
fallback/ramstage              0x18300    stage           46277 LZMA (95496 
decompressed)
build_info                     0x23840    raw                89 none
fallback/dsdt.aml              0x238c0    raw              5514 none
cmos_layout.bin                0x24e80    cmos_layout       704 none
fallback/postcar               0x25180    stage           14872 none
fallback/payload               0x28c00    simple elf      69886 none
(empty)                        0x39d40    null            15012 none
bootblock                      0x3d800    bootblock        9664 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.

No hurry.

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.

Sorry, I only noted “(whole series)” below at the reference. You need the changes listed on the right side in Gerrit. Gerrit’s download options allow you to fetch those with one command.

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?

More tests are always welcome, but coreboot’s crossgcc should work.

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.

Speaking from experience, three chips would be better. ;-) But, I used the same method for years, and there are worse methods (if no socket is there).

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.

Sorry, I do not know anything about that.

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.

Yes, it probably depends on the board. I just remember Alexandru Gagniuc’ VultureProg [2].


Kind regards,

Paul


[1]: https://review.coreboot.org/c/coreboot/+/40815/
(whole series)[2]:
https://blogs.coreboot.org/blog/2013/07/25/vultureprog-equipped-for-galactic-travel/
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Reply via email to