Lost in Space

I'm not great, but the Python part of the plugin is really peanuts, I agree, and you can easily steal from FG Plugin, as I did it just to show that it works.

I don't even have a problem if somebody adopts the Plugin and developes is further after I release it as from then on it probably would stay as it is anyway.

And the fgwrite binary simply does what it does, no matter how and from which plugin you call it.

Actually there would be no need for fgwrite either, but it solves all the problems that I pointed out on the scripting approach in the original thread and creating it was relativley easy and straight forward for me, because besides the image selection and partition assignement part (not needed on Dreamboxes as they have a common basic partitioning layout where only the sizes differ) which I had to write from scratch all the binaries I already had wrapped and patched for klibc support of my nfiwrite binary that dFlash uses.

And nand_check binary is available now since ages too.

But probably there will be soon complaints about fgwrite not beeing Open Source - then the answer is easy - take my advice and do you own one

gutemine

There is no grail to be found in this case, as your community had all the necessary information and code since ages, and even the boxes to try it out and make it run. 

If you need a dumb programmer like me to do the job even without any such box ... your are welcome

What time do you have now - from choosing the image for flashing to booting back to the startup wizard of the new image ?

I have now made also for the et boxes the -j flash as default, as it seems to work for the xp box, solo2 and duo2.

Please use therefore the attached latest kit for your tests on all boxes.

OK, I think it is time to be pragmatic.

I removed all the boxdetection and imagechecks from the Plugin, it will simply Flash whatever ZIP file you provide in whatever subdirectories the content of the zip was packed (upt to 2 subdirectory levels as vuplus uses).

I fixed the saving of the Path in the settings menu of the Plugin.

I added the possibility to specifiy runlevel for root flashing -f 1 will go to single user mode in runlevel 1, but be aware the network is gone meaning you will not get any output during root flashing in telnet. -f 2 is the default if nothing is pecified which keeps the network running.

xp will now not NOT use jffs2 flag anymore as default as solo2 and duo2 do.

Have fun testing

gutemine

OK, I have now found the time to add the promised partition detection.

Now EVERYBODY can test and contribute usefull input WITHOUT beeing scared as with the nowrite option this will ONLY do detection but NOT write anything to Flash. So we find out which foxes are whoch flashlayouts are properly detected already.

It should look like this:

>>>>>>>>>>>>>>> Flash Gordon write by gutemine <<<<<<<<<<<<<<<<<<<
Version 0.4 Build May 13 2013 19:59:11
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
name    device            size image
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
kernel: /dev/mtd2      7340032 vuplus/solo2/kernel_cfe_auto.bin
root:   /dev/mtd0    235929600 vuplus/solo2/root_cfe_auto.bin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
flashing solo2 image files ...
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Please continue your tests ONLY with this kit, and post the output of your boxes when calling fgwrite path_to_imagefiles as explained further up in the thread for debugging purpose if it fails.

I now als added autodetection if ubiformat should be used for root*.bin, hence this should not fail anymore and there is also a -j argument that you can try optionally if flashing fails. it simply disable jffs2 freespace marking on the device format (equivalent to -j on the flash_erase command), as I don't know which boxes need this besides solo2 and duo2 where this is already difault disabled even when not specified extra.

Hopefully the instructions for testing are now clear - try Plugin to see if it succeeds to do flashing on vu+et and provice at least output of fgiwrite -n if you are scared.

If you are motivated then try flashing without the -n and post the output of a full flashing cycle.

If this fails and you have to recover with USB then try once more flashing with -j option added to the fgwrite command and report if and on what box this helps so that this can be encoded into the binary.

Have fun!

gutemine

http://openpli.org/f...ndpost&p=349705

You are welcome ...

Hi !

As we had a nice discussion in this thread

http://openpli.org/f...b-sofa-flashing

how sofa flashing should work and how to implement it the best way, I took myself the freedom to create Flash Gordon Plugin for the non-Dreamboxes (as Dreamboxes enjoy this functionality since years already with my dFlash Plugin also on PLi images).

The all-in-one flashing binary fgwrite is derived from my nfwrite binary and statically linked agains klibc, so it should run on any mipsel box with an up-to-date kernel, and the FG Plugin is derived from dFlash (without the backup part, but Flashing and Flash checking should work).

BUT as I don't have any of your 'great' boxes you will have to do some testing on your won if the work as they should.

Usage of FG is pretty simple, install the ipk, restart enigma2, then you will find the Plugin in the Pluginlist.

Then put all your *.zip files for USB flashing on /hdd/backup (path is changeable in the Plugin Configuration Menu) and choose them in FG Plugin for Flashing.

After confirming Box will flash and reboot - hopefully :-)

Input and test results are welcome, but keep your USB stick ready in case it fails as the plugin is still in an early stage of the development process and don't forget to read the Disclaimer within the Plugin too.

gutemine

I agree.

Probably somebody now will decompile some of his stuff to learn him a lesson.

But maybe nobody is interested, because there is nothing to learn  :-)

Flashing (different) Images with a script is NO Multiboot ...

yes :-)

Like this one ......

http://www.dreamboxu...e-dm8000-84.nfi

ubifs performance is not only boot time, check some nice presentations on this that you can easily find on the web - and then do your ROFL.

It saves Memory and CPU power too, and especially the small boxes beeing short of this benefit a lot due to this.

My 500HD with squeezeout and ubifs and autoswap performs almost unfeelable equally fast then my 7020hd, which has much more Memory and Flash but at least the same CPU.

And yes, I worked hard to achive this goal and it took me weeks of research, testing and development.

But gutemine is not looking for credits, applause or praisal. It is just the fun of it, and that sometimes ignorance and disbelive can be prooven wrong.

Please don't see this as critics, it is just my sense of humor.

Like naming a Plugin Flodder after the warm welcome in this board :-)

I don't have a problem with this decision as DMM did the same for their OE 2.0 on these boxes.

I only disliked the argument that only 5MB remain - which is simply not true.

And that what you call UBIFS overhead simply improves the performance. And it is NOT only boottime. That what you save Flashspace with jffs2 are structures that then need to be rebuilt in Memory. Therefore ubifs also saves some Memory when then box is running already, which improves enigma2 agility, especially for users running memory eating things like CrossEPG,...

And with dFlash the users still can covert the images on these boxes to UBIFS even when it isn't delivered out of the box.

gutemine

I already told him in the JTR thread what is wrong.

Nobody is killing anybody.

But your ubifs and block2mtd patches are still a mess

Does anybody have the time to test the attached Version 0.6.1 with the nfidump 0.9.4 with the fix for the hardlink support ?

I didn't, just replaced the binaries and re-built the ipk - hopefully it works now as it should.

gutemine