Steps to reproduce the Deluge problem for MICAz motes.
1. First program all the client motes with the golden image
application under apps/tests/deluge. Every mote having a unique ID.
2. Program one mote with the base station application.
3. Inject a new image in the basestation: % tos-deluge
I would like to verify a theory. Can you please try the following volume XML
file?
volume_table
volume name=GOLDENIMAGE size=65536 base=0/
volume name=DELUGE1 size=65536 base=65536/
volume name=DELUGE2 size=65536 base=131072/
volume name=DELUGE3 size=65536 base=196608/
volume
I too was working on a similar approachThe following was the XML
file for MICAz motes.
volume_table
volume name=DYMODATA size=131072 /
volume name=GOLDENIMAGE size=65536 base=327680 /
volume name=DELUGE1 size=65536/
volume name=DELUGE2 size=65536/
volume name=DELUGE3 size=65536/
It is in the way TOS generates the volume XML for at45db. There is a notion of
unmovable (with the base attribute) volume. Deluge volumes should be
unmovable. This way, when we refer to image x, it will always be pointing to
the same volume.
Mike
On Jan 25, 2010, at 11:14 PM, Vikram vik76
I would specify the base attribute for all deluge volumes.
Gold image is a guaranteed-to-work image with minimal support for network
programming. It allows for node recovery in the worst case. Deluge expects the
first volume to contain the gold image (hence base=0).
Mike
On Jan 25, 2010, at
Hello,
I have an additional entry in the volumes-at45db.xml file for my application.
volume_table
volume name=GOLDENIMAGE size=65536 base=0 /
volume name=DELUGE1 size=65536/
volume name=DELUGE2 size=65536/
volume name=DELUGE3 size=65536/
volume name=DYMODATA size=131072 /
/volume_table
