178 replies to this topic

[Lost in Space]

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

Attached Files

•  enigma2-plugin-extensions-flashgordon_0.2_all.ipk   45.13KB   88 downloads

Edited by gutemine, 11 May 2013 - 19:39.

[rtzhjgg0]

I tested on my Solo2 this combinations which work all OK

PLi on Flash. Fashing ViX with FlashGordon: YES
ViX on Flash. Fashing BH with FlashGordon:  YES
BH on Flash. Fashing VTi with FlashGordon:  YES
VTi on Flash. Fashing PLi with FlashGordon:  YES

 

 

Thanks

Edited by rtzhjgg0, 11 May 2013 - 20:17.

[Lost in Space]

You are welcome, but we need also inputs from the OTHER boxes.

If flashing fails I need the the output of calling the fgwrite binary in telnet, as it does the real job:
 
/usr/lib/enigma2/python/Plugins/Extensions/FG/bin/fgwrite /hdd/backup/imagename/manufacturer/box
 
The FG Plugin simply extracts imagename.zip to an imagename directory and there should then be the manufacturer (vuplus for example) and the box (solo2 for example) as subdirectories.
 
fgwrite only needs the directory as argument, it then seacrches if kermel and root files are there.

If you only want to flash individual files there is a -k and -r option for kernel and root, but better call fgwrite without any arguments for the full help:
 
>>>>>>>>>>>> Flash Gordon write by gutemine <<<<<<<<<<<<<

  Version 0.1 Build May 11 2013 08:17:23

  Usage: iwrite [options] imagedirectory

  Flashes the image files to your receiver ...

        available options:

  -k --kernel     kernel   partition flashing
  -r --root       root     partition flashing
  -s --single     single   user mode
  -f --force      force    reboot
  -n --nowrite    no write of images
  -v --verbose    verbose  output
  -h --help       help

>>>>>>>>>>>> Flash Gordon write by gutemine <<<<<<<<<<<<<

This means if you only pass the image files directory as single argument this is equivalent to fgwrite -k -r -s -f imagedirectory

Edited by gutemine, 11 May 2013 - 20:24.

[Sjaaky]

When I think of couch flashing, I imagine a plugin which lists various images, pli, dream, bh, vix, vti, etc of various dates and allows you to download and flash them directly.
This plugin sounds promising.

[rtzhjgg0]

..lists various images, pli, dream, bh, vix, vti, etc of various dates and allows you to download and flash them directly...

...and flashing of existing backups of all this images

[pieterg]

Can we have a look at the flash script?
Just for a quick check (to help avoid the possibility that people might 'brick' their boxes, because of different mtd partition layouts etc.)

[Lost in Space]

There is NO script - it is all in a statically linked binary now

 

And I'm pretty sure that you can't brick your box, as it used the normal nandwrite and ubiformat code which does the same checks as when calling them as standalone binaries in a shellscript. I also fixed that the script was 'forgetting' to use the -m option which will mark (new) bad blocks.

 

I even tested/developed it by flashing my dm8000 with VU+ images, as the 8k has also 2k Flashchips this works nicely. Off course it doesn't boot, but I was booted from a Dumbo USB stick during development and testing so this was no problem when the flashwrite failed.

 

And yes my 8k is still alive.

 

But there is always risk, that's why I ask for testing ...

Edited by gutemine, 11 May 2013 - 21:57.

[Lost in Space]

When I think of couch flashing, I imagine a plugin which lists various images, pli, dream, bh, vix, vti, etc of various dates and allows you to download and flash them directly.
This plugin sounds promising.

 

I don't believe in downloading from Sofa, this is more a job for pannels of dubious sources ...

 

If you place all your *.zip of your favourite images and backups in the FG backup directory, you will not need to leave the sofa anymore, not matter which VU/ET/CT to you have, but as already explained this needs to be tried out, I could implement it only as good as i could without any of these boxes ...

 

And so far the testers could always recover wird an USB stick flash if something went wrong, so there is no need to be scared, but off course you have to test it extensively you want a really working and prooven solution.

Edited by gutemine, 11 May 2013 - 22:04.

[pieterg]

I said 'brick' with quotes, because you cannot really brick a box these days by erasing the flash. However, you can make things very complicated for vu+ users, because vu+ keeps the bootloader in nand... And if you erase it, the box has to go back for repairs.
But I think somebody already (bravely) put all his vu+ models to the test.

And for xtrend and maxdigital there is no risk of erasing the bootloader.
But still, I'd want to have a look at the flash routines before I'd trust my box to be fine.
Especially with untested stuff, 100 people might see more than one.

[Lost in Space]

Well, the nfiwrite code is already pretty well tested, and as I only use the same /dev/mtdX devices then the ones the script uses since more then 1 year I would NOT be too scared.

 

As I already said I only spent the 1 hour to add the box detection and the imagefile listing and all this is tested already - remember my JTR can make my Dreambox fake every enigma2 box in the market and run their images on it, so I know how to do this.

 

But in short words to cover also your worries - the code does the same as the script does and it uses even the same flashing code as the used binaries do, I only fixed the errors and implemented all your and mine suggestions like read only mount, syncs, reboot instead of turn off, and most important using uibformat für flashing the ubifs root filesystem, as even the bios doesn't trust nandwrite anymore on this.

 

And as I already said - the script has more bugs and dangers then the binary, due to obvious errors like not using bad block marking.

 

But let's see what the testers will find.

 

I'm looking forward which boxes it works on, because so far we have only a report from solo2, which is actually poor for > 30 downloads.

Edited by gutemine, 11 May 2013 - 23:08.

[pieterg]

But the script is only for vu+, that's why I'm offering to have a look to make sure your binary does work on other hardware as well.

[Lost in Space]

Help is always welcome and you are right, at the moment only VU boxes will work as there I had the necessary inputs.

 

Current fgwrite binary searches only for root_*.bin and kernel_*.bin imagefiles and as for the ET models it would have to search for  root.bin and kernel.bin it can't do any harm as it will not 'find' the images.

 

So the only test will be if the boxdetection via /proc/stb/info/boxtype will work.

 

If you post me the output of cat /proc/mtd of these boses and tell me where root and kernel should be written then I could allow this too.

 

Default for ET boxes is at the moment that the kernel image will go to /dev/mtd1 and root will go to /dev/mtd0 but this is easy to change if they have a different Flashlayout.

 

PS: If the mtd devices are already correct you could easily test fgwrite 0.1 to flash them too, but you would need to rename the bin files until I have added the support as explained above and produce a new binary and then I will adapt also the python Plugin.

 

PPS: But is is a little bit annoying if we now have > 40 downloads and no input is given which boxes work already.

 

gutemine
 

Edited by gutemine, 12 May 2013 - 08:30.

[pieterg]

Cannot give you proc mtd output right now, but et's have the kernel in mtdblock1, and ubi in mtdblock2.
mtd0 maps the entire flash.

[jooe]

Was flash my Vu+solo2 via FG, no any problem at all.

[Lost in Space]

Solo2 was already tested and seems to work but we urgently need input for the other VU boxes too.

 

@pieterg

 

Thanks for the input, I'll include it in fgwrite 0.2 but as this is the default layout there are not any changes needed, besides the different imagenames. So if somebody is impatient only rename the *.bin files as explained above and give it a try.

Edited by gutemine, 12 May 2013 - 14:41.

[Lost in Space]

OK, the new binary and adaptet FG Plugin is now attached, it should now (hopefully) work also on et* boxes without renaming any images.

 

Just place their ZIP file in the /hdd/backup directory as usual and give it a try.

 

And we still need input from the other VU boxes, especially the old ones ...

 

gutemine

Attached Files

•  enigma2-plugin-extensions-flashgordon_0.3_all.ipk   45.28KB   20 downloads

[Pedro_Newbie]

Tried the plugin (0.3) and ended with a frozen non responding VU+ DUO. Even after many minutes of waiting the box didn't reboot.

After flipping the powerswitch the box didn't boot anymore. Tried to boot it several times but it got no further then the message Starting... (at best)

I had to flash a (daily)back-up the "normal" way to revive it life

 

So this was my adventure with Flash Gordon, I shall stick to the stick

Edited by Pedro_Newbie, 12 May 2013 - 16:30.

[Lost in Space]

Doesn't work doesn't help me to fix it :-)

 

Guess why I wrote this:

 

If flashing fails I need the the output of calling the fgwrite binary in telnet, as it does the real job:
 /usr/lib/enigma2/python/Plugins/Extensions/FG/bin/fgwrite /hdd/backup/imagename/manufacturer/box

 

You are also dependant that others try out your backup scripts if the result is flashable, or they will not be proven to work.

 

As I don't have ANY of these boxes I'm dependant on your inputs to finish the work too.

 

But at least you have prooven what I wrote already - that if you keep your USB for Flashing ready, there is not any problem to try it out as it will be always recoverable if it fails.

Edited by gutemine, 12 May 2013 - 16:45.

[Persian Prince]

i think Pedro should provide this for vuduo :

dev:    size   erasesize  name
mtd0: 07600000 00020000 "rootfs"
mtd1: 00400000 00020000 "kernel"
mtd2: 00200000 00020000 "boot"
mtd3: 00100000 00020000 "cfe"
mtd4: 00080000 00020000 "mac"
mtd5: 00080000 00020000 "env"
mtd6: 00100000 00020000 "nvm"

[Lost in Space]

Thanks, now I know that the size of boot and kernel is different which is easy to be fixed as this means the kernel was cut off prematurely.

 

That's the reason why I asked for the output of the ET boxes too.

Edited by gutemine, 12 May 2013 - 17:02.