[coreboot] Regarding offset adjustment for building coreboot.

rajashaker Goud rajashakergoudranga at gmail.com
Tue Apr 26 07:09:20 CEST 2016


Thanks guys for help.

i have figured it out in my case. I have moved the cpu micro code
binary(cpu_microcode_blob.bin
        0xe3fc0    microcode    137232) to the empty space ((empty)
               0x150000   null         311192) by which i am able to build
the coreboot with the debug payload. for moving cpu micro code binary we
need to adjust the location of cpu micro code in the Kconfig file such that
it goes to empty space.


Name                           Offset     Type         Size
bootsplash.img                 0x0        bootsplash   37443
cmos_layout.bin                0x9280     cmos_layout  1132
fspd.bin                       0x9740     (unknown)    4608
fallback/ramstage              0xa980     stage        67423
fallback/payload               0x1b140    payload      769955
config                         0xd7140    raw          4623
(empty)                        0xd8380    null         48152
cpu_microcode_blob.bin         0xe3fc0    microcode    137232
(empty)                        0x105840   null         1880
mrc.cache                      0x105fc0   (unknown)    32768
(empty)                        0x10e000   null         8088
uefi_nvs.bin                   0x10ffc0   (unknown)    262144
(empty)                        0x150000   null         311192
fsp.bin                        0x19bfc0   (unknown)    314368
(empty)                        0x1e8c00   null         58200
fallback/romstage              0x1f6f80   stage        35253
(empty)                        0x1ff9c0   null         536

On Fri, Apr 8, 2016 at 11:32 PM, Jay Talbott <
JayTalbott at sysproconsulting.com> wrote:

> The FSP is rebased with the Intel BCT tool, not the FITC tool.
>
> > On Apr 8, 2016, at 7:38 AM, Martin Roth <gaumless at gmail.com> wrote:
> >
> > 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 at coreboot.org> wrote:
> >> 2016-04-08 11:17 GMT+02:00 Nico Huber <nico.huber at 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 at coreboot.org
> >> https://www.coreboot.org/mailman/listinfo/coreboot
> >
> > --
> > coreboot mailing list: coreboot at coreboot.org
> > https://www.coreboot.org/mailman/listinfo/coreboot
> >
>



-- 
Thanks,
Rajashaker Goud Ranga
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160426/39b57f1e/attachment.html>


More information about the coreboot mailing list