Patchwork Sanitize cbfs-files-y

Hi,

attached patch inverses two arguments of cbfs-files-y and adapts its
users (one of which already used the new order). This is in reponse to
feedback that the original setup was too complicated.

New cbfs-files-y:

cbfs-files-y contains the names of files as they appear in CBFS. The
arguments describe the on-filesystem name, the type and (optionally) the
position. Example:

cbfs-files-y += foo
foo-file := bar
foo-type := splashscreen
foo-position := 0xffff8000

This configures a CBFS file called "foo" that is marked "splashscreen",
located at 0xffff8000 in flash and contains the data of the file "bar"
in the filesystem (either in the current directory, ie. where the
corresponding Makefile.inc resides, or if that doesn't exist, relative
to the toplevel directory).


Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>

* Georgi, Patrick <Patrick.Georgi@secunet.com> [110128 15:32]:
> Hi,
> 
> attached patch inverses two arguments of cbfs-files-y and adapts its
> users (one of which already used the new order). This is in reponse to
> feedback that the original setup was too complicated.
> 
> New cbfs-files-y:
> 
> cbfs-files-y contains the names of files as they appear in CBFS. The
> arguments describe the on-filesystem name, the type and (optionally) the
> position. Example:
> 
> cbfs-files-y += foo
> foo-file := bar
> foo-type := splashscreen
> foo-position := 0xffff8000
> 
> This configures a CBFS file called "foo" that is marked "splashscreen",
> located at 0xffff8000 in flash and contains the data of the file "bar"
> in the filesystem (either in the current directory, ie. where the
> corresponding Makefile.inc resides, or if that doesn't exist, relative
> to the toplevel directory).
> 
> 
> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>

nice!

Acked-by: Stefan Reinauer <stefan.reinauer@coreboot.org>

* Georgi, Patrick <Patrick.Georgi@secunet.com> [110128 15:32]:
> Hi,
> 
> attached patch inverses two arguments of cbfs-files-y and adapts its
> users (one of which already used the new order). This is in reponse to
> feedback that the original setup was too complicated.
> 
> New cbfs-files-y:
> 
> cbfs-files-y contains the names of files as they appear in CBFS. The
> arguments describe the on-filesystem name, the type and (optionally) the
> position. Example:
> 
> cbfs-files-y += foo
> foo-file := bar
> foo-type := splashscreen
> foo-position := 0xffff8000

Two questions:

Stuff like cmos.layout could arguably go into fallback/ or normal/. 

What's the right way to solve this with cbfs-files-y?

If it stays in /, what happens if an image is updated with a newer
version of cmos.layout (say, no old options move/remove so it's safe in
that regard). Will the file be ignored? Or Overwritten? Do we produce a
proper warning for that? 

Stefan

Am 28.01.2011 22:02, schrieb Stefan Reinauer:
> Stuff like cmos.layout could arguably go into fallback/ or normal/.
> What's the right way to solve this with cbfs-files-y?
Use CONFIG_CBFS_PREFIX? Like:
cbfs-files-y += $(CONFIG_CBFS_PREFIX)/cmos.layout
$(CONFIG_CBFS_PREFIX)/cmos.layout-file := #and so on

> If it stays in /, what happens if an image is updated with a newer
> version of cmos.layout (say, no old options move/remove so it's safe in
> that regard). Will the file be ignored? Or Overwritten? Do we produce a
> proper warning for that? 
good question, but probably not.
updating things is still a "you better know what you're doing" operation


Patrick