Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
19 years ago

altera_ro_zipfs bypassing flash

We would like to use Altera's readonly ZIP filesystem, but the model for applying it seems awkward -- you specify the ZIP file in the system library (not in the project), and there is a separate flash programming step that must be done to some fixed offset.

Would it make sense, instead, to include the ZIP file in the .data segment by converting it to a .o via objcopy, then include that object file in the link, and then somehow redirect the zipfs routines to use it rather than a flash image? Such an approach might be nice during development because changes to the ZIP file would make their way into the running code just like any other compiled segment.

One can make the object file manually using something like:

nios2-elf-objcopy -I binary -O elf32-littlenios2 -B nios2 <ZIP-FILE> zipfile.o

but in the strange realm of managed makefiles I&#39;m unsure how to:

* Add the above command to create zipfile.o whenever ZIP-FILE changes

* Include the zipfile.o object in the final link

and then:

* fool the altera_ro_zipfs routines into using it.

Any suggestions would be *really* appreciated -- Thanks!

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    --- Quote Start ---

    originally posted by alan.siggia@Sep 24 2006, 09:03 PM

    we would like to use altera&#39;s readonly zip filesystem, but the model for applying it seems awkward -- you specify the zip file in the system library (not in the project), and there is a separate flash programming step that must be done to some fixed offset.

    would it make sense, instead, to include the zip file in the .data segment by converting it to a .o via objcopy, then include that object file in the link, and then somehow redirect the zipfs routines to use it rather than a flash image? such an approach might be nice during development because changes to the zip file would make their way into the running code just like any other compiled segment.

    one can make the object file manually using something like:

    nios2-elf-objcopy -i binary -o elf32-littlenios2 -b nios2 <zip-file> zipfile.o

    but in the strange realm of managed makefiles i&#39;m unsure how to:

    * add the above command to create zipfile.o whenever zip-file changes

    * include the zipfile.o object in the final link

    and then:

    * fool the altera_ro_zipfs routines into using it.

    any suggestions would be *really* appreciated -- thanks!

    <div align='right'><{post_snapback}> (index.php?act=findpost&pid=18430)

    --- quote end ---

    --- Quote End ---

    Yes it&#39;s perfectly possible to do this, it is how the zipFS was developped. The changes to make it work are simple. If you look in the source of the roZipFS you will find a makefile fragment. Add the objcopy command in here, and add the .o file to the list of object files in this makefile snippet.

    To "fool" the zipfs into using it, you will have to modify the init function.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    --- Quote Start ---

    originally posted by alan.siggia@Sep 24 2006, 09:03 PM

    we would like to use altera&#39;s readonly zip filesystem, but the model for applying it seems awkward -- you specify the zip file in the system library (not in the project), and there is a separate flash programming step that must be done to some fixed offset.

    would it make sense, instead, to include the zip file in the .data segment by converting it to a .o via objcopy, then include that object file in the link, and then somehow redirect the zipfs routines to use it rather than a flash image? such an approach might be nice during development because changes to the zip file would make their way into the running code just like any other compiled segment.

    one can make the object file manually using something like:

    nios2-elf-objcopy -i binary -o elf32-littlenios2 -b nios2 <zip-file> zipfile.o

    but in the strange realm of managed makefiles i&#39;m unsure how to:

    * add the above command to create zipfile.o whenever zip-file changes

    * include the zipfile.o object in the final link

    and then:

    * fool the altera_ro_zipfs routines into using it.

    any suggestions would be *really* appreciated -- thanks!

    <div align='right'><{post_snapback}> (index.php?act=findpost&pid=18430)

    --- quote end ---

    --- Quote End ---

    Yes it&#39;s perfectly possible to do this, it is how the zipFS was developped. The changes to make it work are simple. If you look in the source of the roZipFS you will find a makefile fragment. Add the objcopy command in here, and add the .o file to the list of object files in this makefile snippet.

    To "fool" the zipfs into using it, you will have to modify the init function.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    19 years ago

    Thanks R.B. Your suggestion got me pointed in the right direction.

    I didn&#39;t really want to modify any original NIOS files for one particular project, so I ended up adding a builder to run ZIP on the zipfile first, then do the objcopy to create a .o file, then include that in the linker script. The following trivial test program then worked fine and printed out one of the files in the original zip tree. 

    #include <stdio.h>
# include "../../../altera_ro_zipfs/HAL/inc/altera_ro_zipfs.h"
extern char _binary_web_zip_start, _binary_web_zip_end,
  _binary_web_zip_size;
# define WEB_BASE   ((int)_binary_web_zip_start)# define WEB_NAME   "/mnt/web"# define WEB_OFFSET 0
ALTERA_RO_ZIPFS_INSTANCE( WEB, web );
int main()
{
  FILE *fd; int ch;
  printf( "ZIP File - Start:%X  End:%X  Size:%d\n",
   (int)_binary_web_zip_start,
   (int)_binary_web_zip_end,
   (int)_binary_web_zip_size );
  ALTERA_RO_ZIPFS_INIT( WEB, web );
  fd = fopen( WEB_NAME "/web/index.html", "r" );
  if( fd ) { while( (ch = getc(fd)) != EOF ) putchar( ch ); }
  return 0;
}

    There&#39;s a bit of hackery in the include file using ../../, as I did not know how to specify the HAL include directory symbolically (without using an absolute pathname)