Peter,
Do you still have any outstanding patches? It looks like there are still many references to romfs in src/lib/.
I also get this in the output of make:
rm -f coreboot.cbfs ./cbfstool ./coreboot.romfs create 524288 65536 ./coreboot.rom.bootblock (cbfstool) E: ./coreboot.romfs already exists - cannot create make: *** [coreboot.romfs] Error 255 make: Leaving directory `/home/myles/buildrom-devel/work/coreboot/svn/targets/emulation/qemu-x86/qemu-x86'
Thanks, Myles
Myles Watson wrote:
Peter,
Do you still have any outstanding patches?
I know of one more issue, coreboot.romfs as you mentioned.
It looks like there are still many references to romfs in src/lib/.
Hm? grep gives me .svn/text-base/romfs.c.svn-base but nothing else. What files do you see?
I also get this in the output of make:
rm -f coreboot.cbfs ./cbfstool ./coreboot.romfs create 524288 65536 ./coreboot.rom.bootblock
Yeah. This is a tricky one.
The coreboot.romfs filename is generated by the config tool for each image, by appending 'fs' to the image name: coreboot.rom becomes coreboot.romfs
I am unsure how to approach this, because I don't know the config tool well enough.
Can someone comment on whether it's simply safe to change that to a fixed coreboot.cbfs filename?
//Peter
On Wed, Apr 15, 2009 at 2:23 PM, Peter Stuge peter@stuge.se wrote:
Can someone comment on whether it's simply safe to change that to a fixed coreboot.cbfs filename?
yes.
I can do it if you want, or Patrick can.
ron
On Wed, Apr 15, 2009 at 3:23 PM, Peter Stuge peter@stuge.se wrote:
Myles Watson wrote:
Peter,
Do you still have any outstanding patches?
I know of one more issue, coreboot.romfs as you mentioned.
It looks like there are still many references to romfs in src/lib/.
Hm? grep gives me .svn/text-base/romfs.c.svn-base but nothing else. What files do you see?
myles@orangutan:svn$ grep -Ir romfs src/lib/ | grep -v svn | head src/lib/romfs.c:#include <romfs.h> src/lib/romfs.c:int romfs_decompress(int algo, void *src, void *dst, int len) src/lib/romfs.c:int romfs_check_magic(struct romfs_file *file) src/lib/romfs.c:struct romfs_header *romfs_master_header(void) src/lib/romfs.c: struct romfs_header *header; src/lib/romfs.c: header = (struct romfs_header *) ptr; src/lib/romfs.c:struct romfs_file *romfs_find(const char *name) src/lib/romfs.c: struct romfs_header *header = romfs_master_header(); src/lib/romfs.c: struct romfs_file *file = (struct romfs_file *) offset; src/lib/romfs.c: if (romfs_check_magic(file)) printk_info("Check %s\n", ROMFS_NAME(file));
I also get this in the output of make:
rm -f coreboot.cbfs ./cbfstool ./coreboot.romfs create 524288 65536 ./coreboot.rom.bootblock
Yeah. This is a tricky one.
The coreboot.romfs filename is generated by the config tool for each image, by appending 'fs' to the image name: coreboot.rom becomes coreboot.romfs
I am unsure how to approach this, because I don't know the config tool well enough.
Can someone comment on whether it's simply safe to change that to a fixed coreboot.cbfs filename?
I think we should just make it output coreboot.rom and forget the fs extension. There's no reason to confuse people with two output files based on a config option.
Thanks, Myles
On Wed, Apr 15, 2009 at 03:32:50PM -0600, Myles Watson wrote:
I think we should just make it output coreboot.rom and forget the fs extension. There's no reason to confuse people with two output files based on a config option.
Yes, please.
Thanks, Ward.
Myles Watson wrote:
It looks like there are still many references to romfs in src/lib/.
Hm? grep gives me .svn/text-base/romfs.c.svn-base but nothing else. What files do you see?
myles@orangutan:svn$ grep -Ir romfs src/lib/ | grep -v svn | head src/lib/romfs.c:#include <romfs.h>
Thanks! I had deleted but not committed the delete.
Can someone comment on whether it's simply safe to change that to a fixed coreboot.cbfs filename?
I think we should just make it output coreboot.rom and forget the fs extension. There's no reason to confuse people with two output files based on a config option.
I think there is, if the file format changes. If the contents is always the same type I agree it's better to have only one name.
//Peter
On Wed, Apr 15, 2009 at 3:41 PM, Peter Stuge peter@stuge.se wrote:
Myles Watson wrote:
It looks like there are still many references to romfs in src/lib/.
Hm? grep gives me .svn/text-base/romfs.c.svn-base but nothing else. What files do you see?
myles@orangutan:svn$ grep -Ir romfs src/lib/ | grep -v svn | head src/lib/romfs.c:#include <romfs.h>
Thanks! I had deleted but not committed the delete.
Can someone comment on whether it's simply safe to change that to a fixed coreboot.cbfs filename?
I think we should just make it output coreboot.rom and forget the fs extension. There's no reason to confuse people with two output files based on a config option.
I think there is, if the file format changes. If the contents is always the same type I agree it's better to have only one name.
In this case the difference is that one doesn't have a format. In both cases the bootblock is in the same place and the code inside the image has to know where everything else is.
Thanks, Myles
On 15.04.2009 23:50 Uhr, Myles Watson wrote:
I think there is, if the file format changes. If the contents is always the same type I agree it's better to have only one name.
In this case the difference is that one doesn't have a format. In both cases the bootblock is in the same place and the code inside the image has to know where everything else is.
Absolutely agreed. Adding another file extension will confuse the users, even though we might successfully lie to ourselves about educating them.
I agree to. I only had coreboot.romfs because for a few days I always created and tested both images. We don't need that any more.
ron
On 15.04.2009 23:41 Uhr, Peter Stuge wrote:
Can someone comment on whether it's simply safe to change that to a fixed coreboot.cbfs filename?
I think we should just make it output coreboot.rom and forget the fs extension. There's no reason to confuse people with two output files based on a config option.
I think there is, if the file format changes. If the contents is always the same type I agree it's better to have only one name.
The content is always the same type.. it's a coreboot image.
On Wed, Apr 15, 2009 at 11:41:36PM +0200, Peter Stuge wrote:
Myles Watson wrote:
It looks like there are still many references to romfs in src/lib/.
Hm? grep gives me .svn/text-base/romfs.c.svn-base but nothing else. What files do you see?
myles@orangutan:svn$ grep -Ir romfs src/lib/ | grep -v svn | head src/lib/romfs.c:#include <romfs.h>
Thanks! I had deleted but not committed the delete.
src/include/romfs.h is still in the tree.
-Kevin
We aim to please:
On Thu, Apr 16, 2009 at 6:09 PM, Kevin O'Connor kevin@koconnor.net wrote:
src/include/romfs.h is still in the tree.
-Kevin
Deleting src/include/romfs.h
Committed revision 4125.
On 15.04.2009 23:23, Peter Stuge wrote:
Hm? grep gives me .svn/text-base/romfs.c.svn-base but nothing else.
Side note: The svngrep utility is extremely helpful if you want to run a recursive grep on a source tree and ignore any subversion management files.
Regards, Carl-Daniel
On 15.04.2009 23:46 Uhr, Carl-Daniel Hailfinger wrote:
On 15.04.2009 23:23, Peter Stuge wrote:
Hm? grep gives me .svn/text-base/romfs.c.svn-base but nothing else.
Side note: The svngrep utility is extremely helpful if you want to run a recursive grep on a source tree and ignore any subversion management files.
Cool, didn't know that one! I've been using this self-made hack
alias search='find .|sed s/^/"/|sed s/$/"/ | grep -v svn | xargs grep'
On Wed, Apr 15, 2009 at 6:40 PM, Stefan Reinauer stepan@coresystems.dewrote:
On 15.04.2009 23:46 Uhr, Carl-Daniel Hailfinger wrote:
On 15.04.2009 23:23, Peter Stuge wrote:
Hm? grep gives me .svn/text-base/romfs.c.svn-base but nothing else.
Side note: The svngrep utility is extremely helpful if you want to run a recursive grep on a source tree and ignore any subversion management files.
Cool, didn't know that one! I've been using this self-made hack
alias search='find .|sed s/^/"/|sed s/$/"/ | grep -v svn | xargs grep'
svngrep isn't in the ubuntu repos, but ack-grep does the same thing, and it understands cvs too.
-Corey