rootfs image/recovery?

Hi,
I have a general question concerning development on embedded linux systems.

I have my mini2440 compiled kernel and rootfs with buildroot.

Now the question, what's the right way and how to do it?

I mean after creating rootfs with buildroot I have a jffs2 file system,
which is flashed in the NAND.

The system still isn't complete, I will have to do some additonal things, 
for example configur ip adreess, load websites on it, configure user,
passwords, addional self compiled software etc..... this is all stored on
the flash file system in the nand. 

The question is now, how make an image of this ready configured  system,
for deploying it to other mini2440 board, or only in order to have a backup
copy, in case of any problem.

Or do I have to integrate all this things already in the buildprocess of
buildroot?

What's the rigth way and how do you generate your images ready for shipping
and deployment? How do you make it reproducable?

Thanks a lot

How are you loading the initial JFFS2 file into NAND?

At the moment I write it with linux pc to a sd card and load it with uboot
in the ram and write it with uboot to the nand.

why is this of interest?

I think this is a general question, concerning all embedded systems running
linux, therefore this should be independent of the method of flashing the
jffs2?

what is the method?

- integrating everything in buildroot? so every time a complete image
including all settings is generated. this maybe would be the best
reproducable process?

- creating with buildroot, customising the file system on the linux pc, and
then flashing

- creating with buildroot, flashing, customizing the file system on the
target, and then making a backup image of the file system. Would mean
booting with uboot, reading fs into ram and store it to disk?

For projects in industry, this seems to be an essential question for me, to
have reproducable "firmware" from sources, but how can this achieved here
including kernel, rootfs, custom software which is not in buildroot, own
software and any sort of configuration.

Anyway, how do you save/backup your buildroot environment, sources  and
toolchain on your working pc, in order to reproduce this, on another pc or
your own in case of system crash.

Is it sufficient to make a tarball of the buildroot directory and store
this?

> Anyway, how do you save/backup your buildroot environment, sources  and
> toolchain on your working pc, in order to reproduce this, on another pc >
or your own in case of system crash.

We'll wait for people with real industry experience to answer these.

But, my 2 cents worth . . .

From an non-professional point of view I just make copies of my root
directory, root config file (I am using a BSP) and kernel config files.  A
copy of the toolchain saved to a backup disc MARKED for a specific host
machine.

I believe that you should not copy toolchains across to another brand or
model of PC.  Evidently, a specific toolchain can behave differently on
another machine. I am not smart enough to know when you can get away with
it!  

> Is it sufficient to make a tarball of the buildroot directory and store
> this?

I understand that you need to keep everything associated with a particular
build.  The toolchain, with its libraries, the kernel source and how you
built everything.  In my case the version of the BSP.

"For projects in industry, this seems to be an essential question for me,
to have reproducable "firmware" from sources, but how can this achieved
here including kernel, rootfs, custom software which is not in buildroot,
own software and any sort of configuration."

The programming from SD card has tremendous advantages in production. You
make as many SD cards as you need to keep up with production, depending on
loading time. When the first one finishes you put the SD card in the next
one to be programmed. In the Chinese plants you will see a long row of PCs
set to program embedded boards. The Mini6410/210 do this automatically. The
bottleneck is testing. You could have 3 or 30 in process.  

The bottleneck is testing, if it is needed.