178 replies to this topic

[ozkaradag]

Hello,

Gutemine was so wrong about you, forgive me.
A human being who made a mistake, and I apologize.

I do not understand this FlashGordonu, what's that?

Yours...

[nietgiftig]

I do not understand this FlashGordonu, what's that?

 

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

[Lost in Space]

It is a binary for flashing images to a running box and a small plugin to simplify the process further.

 

Read the thread and try it out, then you know more ...

 

And I do mistakes all the time, if I would start apologizing I would be pretty busy

 

But that doesn't mean that I changed either ...

Edited by gutemine, 13 May 2013 - 14:40.

[nietgiftig]

Dit try it a test with my ET9000 and the zipfile from xtrendalliance .

 

After choosing the xtrendalliance-1.0-et9x00-20130513_usb.zip i've got the message

 

Not flashing, because the image is for the et9x00 and reciever is unknown.

 

FYI the directory with files for an ET9000 is called et9x00

[betacentauri]

Same message like nietgiftigs here on my et9200. Then I tried it via telnet:

./fgwrite  /hdd/backup/OpenPLi-3.0-beta-et9x00-20130513_usb/et9x00/

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

  Version 0.3 Build May 12 2013 16:02:37

flashing et9200 image files ...
erasing kernel ...
flashing kernel ...
.................................

single user mode ...
rebooting in 1 min  ...
erasing root ...
flashing root ...
Bus error
root@et9x00:/usr/lib/enigma2/python/Plugins/Extensions/FG/bin# ls /tmp
-sh: ls: Invalid argument
root@et9x00:/usr/lib/enigma2/python/Plugins/Extensions/FG/bin#

I have installed version v0.5 (log says v0.3)!!
Afterwards I had to switch off the box and to flash a backup...

[betacentauri]

Perhaps this is interesting for you:

root@et9x00:/media/hdd/backup# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 0ff00000 00020000 "complete"
mtd1: 00600000 00020000 "kernel"
mtd2: 0f900000 00020000 "rootfs"

[theparasol]

Is the XP1000 box already supported? If you need testing for this box I'm more than happy to contribute.

 

root@xp1000:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 08000000 00020000 "complete"
mtd1: 00600000 00020000 "kernel"
mtd2: 07a00000 00020000 "rootfs"
root@xp1000:~#

[Lost in Space]

If the boxtype file says et9200 and the imagedirectory says et9x00 then the compare in the pythin Plugin will not work and needs adaption.

 

Thanks for pointing this out. If a Bus error on write occures either the write failed because it is not an ubifs image or which is more likely the size of the flash is not properly read.

 

Looks like we have to stop box detection and simply read from /proc/mtd which file has to go where, because then the binary at least should work with any box.

 

It is great that you test also the other boxes, but we should finish the vu+ ones first, as they are the most likely to work as expected because I used the parameters to nandwrite and erase from the script as already explained.

 

And there are more versions of plugin the binary versions, so the numbering differs intentionally.

Edited by gutemine, 13 May 2013 - 16:40.

[nietgiftig]

t is great that you test also the other boxes, but we should finish the vu+ ones first, as they are the most likely to work as expected because I used the parameters to nandwrite and erase from the script as already explained.

 

Sorry, I thought you were asking for other box experiences

Please give a sign when you are ready for the ET boxes.

[Lost in Space]

Look I have to take the input I get - and I now already got usefull input for the et* which now needs to be intergrated into binary and plugin.

 

But instead of simply waiting you/others can continue testing the vu* boxes, as there we still lack lots of testresults.

Edited by gutemine, 13 May 2013 - 18:29.

[greatred]

VU+ Uno layout:

 

mtd0: 07200000 00020000 "rootfs"
mtd1: 00400000 00020000 "kernel"
mtd2: 00400000 00020000 "boot"
mtd3: 00200000 00020000 "splash"
mtd4: 00100000 00020000 "cfe"
mtd5: 00080000 00020000 "mac"
mtd6: 00080000 00020000 "env"
mtd7: 00100000 00020000 "nvm"

Had this "bus error" mentioned by betacentauri and some additional message I cannot recall right now.

Sorry no logs this time box is busy.

Worth mentioning is, that one flashing operation worked and I was able to fgwrite my backup PLi while being on VIX...

 

[Lost in Space]

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

Attached Files

•  enigma2-plugin-extensions-flashgordon_0.6_all.ipk   45.87KB   35 downloads

Edited by gutemine, 13 May 2013 - 21:16.

[Lost in Space]

You should not just download, you should test and confirm if and on what boxes it runs and if it doesn't, then provide the input and feedback as described above.

 

I'm patient, but supporting so many different boxes which I don't own (and don't want to own either) depends on the contribution of the owners.

 

If you don't see it this way, then you should do it yourself ...

 

gutemine

Edited by gutemine, 14 May 2013 - 13:00.

[theparasol]

Right now I'm @work, but soon as I'm at home I'll backup the xp1000 image and give you prompt feedback (!)

 

I know patience is sometimes hard. I also do some "hard" codings investing too much time and I'm always glad I get prompt reports from the crowd

[Lost in Space]

I have plenty of other things to do, so for me it is the other way around. If no, or too less input comes you have to be patient until I include it in the code.

 

The XP detection part of the binary should now show at least which images he found and to what partitions he would flash them. And if he finds an ubi header on the root image he will write it with ubiformat, if not with nanddump. And with the -j you can hontrol how he erases the other partitions. I'm not sure if this is suffient already for a sucessfull flash, but you should be able to test this now yourself.

 

The 'flashing XXX image files' output comes from the /proc/stb/info/xxxx files, which is only included for vu+et boxes, but if you give input what /proc/stb/info/xxxx file contains what model string I could add this too.

 

And if it works in the binary I can change it also in the Plugin.

Edited by gutemine, 14 May 2013 - 14:17.

[theparasol]

Here are the results from Slagharen / The Netherlands for my XP1000 box:

 

root@xp1000:/proc/stb/info# ls

board_revision  boxtype         chipset         model           release         version

root@xp1000:/proc/stb/info# cat *

12

xp1000

bcm7358

dm800se

1468

2

root@xp1000:/proc/stb/info#

 

Think my model string isnt in the plugin already!

 

Attached Files

•  Not flashing.jpg   55.26KB   42 downloads

[Lost in Space]

Thanks, I'll include it in next version. And yes, I wrote already that the plugin will currently only accept vu and et, so you will have to use the fgwrite binary directly as explaied on first page to see if the partition detection and image assignment works already as it should.

 

And really great that it thinks that it is a dm800se

Edited by gutemine, 14 May 2013 - 15:52.

[theparasol]

And really great that it thinks that it is a dm800se

 

This is done for compatibility with (older) plugins, real box name is always in boxtype.

 

Anyway, here a screenshot for fgwrite, it seems to write ok only thing is after reboot screen is locked at bootlogo of manufacturer.

Attached Files

•  fgwritev04xp1000.jpg   84.01KB   44 downloads

[Lost in Space]

Thanks. Now after flashing with USB strick try fgwrite once more with the additional -j option as i explained above and let's see if the situation changes as the complaining about OOB points in this direction.

 

If not I would need a bootlog to see at what state the box fails on booting (if kernel is started and just root is unusable or if kernel is already bad)

 

Then I will add the xp to the Plugin and maybe change fgwrite :-)

 

And I better don't comment on 'compatibility for old plugins' ...

Edited by gutemine, 14 May 2013 - 16:26.

[theparasol]

I dont think I can test it this evening, busy recoding on dvbapi and the WAF for this evening is: I want to see the Eurovision Songfestival Contest

 

And I better don't comment on 'compatibility for old plugins' ...

 

Plz do comment: I also find this setting rather strange but its seems to be needed if I remember correctly

 

@PieterG/Openpli: Why is this setting stating DM800SE instead of XP1000?