Some BayTrail ChromeOS devices have the eMMC controller hidden (thus
requiring the use of etc/sdcard), while others do not, making it
problematic to have a single payload which serves all devices
properly. Therefore, if the CBFS contains etc/sdcard entries, skip
detection of
any visible PCI sd
=
KVM Forum 2016: Call For Participation
August 24-26, 2016 - Westin Harbor Castle - Toronto, Canada
(All submissions must be received before midnight May 1, 2016)
=
KVM
Hi Kevin,
I plan to have the default CBFS contain only coreboot and SeabIOS and
a few payloads (coreinfo, memtest86, PXE) that I don't intend to
change often.
That would be protected with a hash and would be kept small for
performance reasons.
ChromeOS appears to do something similar and take it a
On 3/10/2016 9:03 AM, Kevin O'Connor wrote:
On Thu, Mar 10, 2016 at 12:38:14AM -0600, Matt DeVillier wrote:
Some BayTrail ChromeOS devices have the eMMC controller hidden (thus
requiring the use of etc/sdcard), while others do not, making it problematic
to have a single payload which serves all
On Wed, Mar 09, 2016 at 12:19:43PM -0600, Ben Gardner wrote:
> ROM images with a FMAP may have multiple CBFS.
> Scan all available CBFS so that, say, a SeaBIOS bootable image doesn't
> have to be in the main CBFS.
>
> Coreboot puts the FMAP location in the BOOT_MEDIA_PARAMS entry in the
> coreboot
On Thu, Mar 10, 2016 at 12:38:14AM -0600, Matt DeVillier wrote:
> Some BayTrail ChromeOS devices have the eMMC controller hidden (thus
> requiring the use of etc/sdcard), while others do not, making it problematic
> to have a single payload which serves all devices properly. Therefore, if
> the CB
Hi,
> +if ((fm->ver_major != FMAP_VER_MAJOR) ||
> +(fm->ver_minor != FMAP_VER_MINOR)) {
> +dprintf(1, "FMAP: bad version %d.%d\n", fm->ver_major,
> fm->ver_minor);
> +return;
> +}
What is the policy on major/minor versioning?
If minor version bumps are supposed
