[coreboot] Rebuilding coreboot image generation
Patrick Georgi
pgeorgi at google.com
Fri Nov 20 16:55:42 CET 2015
Let's extend your example so it becomes somewhat comparable to my proposal:
HOST_FIRMWARE at 0xff800000 8M {
SI_ALL 2M {
SI_DESC 4K
SI_ME 0x1ff000
}
SI_BIOS {
RW_A 0xf0000 {
VBLOCK_A 64K
RW_MAIN_A CBFS {
add-payload -n fallback/payload -f
/path/to/whereever/the/payload/resides.elf
add-stage -n fallback/ramstage -f $(obj)/cbfs/fallback/ramstage.elf
add-stage -n fallback/romstage -f
$(obj)/cbfs/fallback/romstage.elf --xip --align 0x1000
}
RW_FWID_A 0x40
}
RW_B 0xf0000 {
VBLOCK_B 64K
RW_MAIN_B CBFS {
add-payload -n fallback/payload -f
/path/to/whereever/the/payload/resides.elf
add-stage -n fallback/ramstage -f $(obj)/cbfs/fallback/ramstage.elf
add-stage -n fallback/romstage -f
$(obj)/cbfs/fallback/romstage.elf --xip --align 0x1000
}
RW_FWID_B 0x40
}
RO at 4M {
RO_VPD 16K
FMAP at 0x10000 2K
RO_FRID 0x40
GBB at 0x11000
RO_MAIN CBFS {
add-payload -n fallback/payload -f
/path/to/whereever/the/payload/resides.elf
add-stage -n fallback/ramstage -f $(obj)/cbfs/fallback/ramstage.elf
add-stage -n fallback/romstage -f
$(obj)/cbfs/fallback/romstage.elf --xip --align 0x1000
add-stage -n fallback/verstage -f
$(obj)/cbfs/fallback/romstage.elf --xip --align 0x1000
add -n bootblock -f $(obj)/cbfs/fallback/bootblock.bin --base
-$(filesize $(obj)/cbfs/fallback/bootblock.bin)
}
}
}
}
And that for every mainboard, and not transferable to other flash
layout schemes.
I don't think this is looking better (or even just as good) as my
proposal, simple because of maintenance reasons.
Patrick
2015-11-06 6:55 GMT+01:00 Julius Werner <jwerner at chromium.org>:
>> What I'd like to see come out of this is a dts-like set of flash
>> descriptors, with the rules left in the makefiles. At the very least,
>> dts is not a new language.
>
> Just wanted to point out (without trying to usurp any of the ongoing
> discussion in that doc) that we already have an FMAP descriptor
> language that was implemented in cbfstool half a year ago, because I
> don't think that got much visibility upstream when it was merged.
> That's the FMD (flash map descriptor) format some of us are talking
> about in those comments, which was developed in anticipation of a
> build system redesign like this. It's aiming to describe FMAPs in a
> clean, flexible way without the cruft of a format (dts) that was never
> really meant for that purpose, and has some nice features (like
> variable-sized sections) built-in. The parser can be seen in
> util/cbfstool/fmd.c, and a sample file would look something like this
> (in general, '@offset' is the base offset to the parent section and
> the number after the space is the size):
>
> HOST_FIRMWARE at 0xff800000 8M {
> SI_ALL 2M {
> SI_DESC 4K
> SI_ME 0x1ff000
> }
> SI_BIOS {
> RW_A 0xf0000 {
> VBLOCK_A 64K
> RW_MAIN_A
> RW_FWID_A 0x40
> }
> RW_B 0xf0000 {
> VBLOCK_B 64K
> RW_MAIN_B
> RW_FWID_B 0x40
> }
> RO at 4M {
> RO_VPD 16K
> FMAP at 0x10000 2K
> RO_FRID 0x40
> GBB at 0x11000
> RO_MAIN 1M
> }
> }
> }
--
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
More information about the coreboot
mailing list