178 replies to this topic

[Lost in Space]

The excuse is accepted, and the rest you find in the camembert corner of the supermarket

Edited by gutemine, 14 May 2013 - 19:22.

[betacentauri]

I still have problems:

 

root@et9x00:/usr/lib/enigma2/python/Plugins/Extensions/FG/bin# ./fgwrite -n -v /hdd/backup/OpenPLi-3.0-beta-et9x00-20130513_usb/et
9x00/

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

Version 0.4 Build May 13 2013 19:59:11

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
name    device            size image
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
kernel: /dev/mtd1      6291456 /hdd/backup/OpenPLi-3.0-beta-et9x00-20130513_usb/et9x00//kernel.bin
root:   /dev/mtd2    261095424 /hdd/backup/OpenPLi-3.0-beta-et9x00-20130513_usb/et9x00//rootfs.bin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
flashing et9200 image files ...
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

nowrite kernel ...
nowrite root ...

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

root@et9x00:/usr/lib/enigma2/python/Plugins/Extensions/FG/bin# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 0ff00000 00020000 "complete"
mtd1: 00600000 00020000 "kernel"
mtd2: 0f900000 00020000 "rootfs"
root@et9x00:/usr/lib/enigma2/python/Plugins/Extensions/FG/bin# init 4
root@et9x00:/usr/lib/enigma2/python/Plugins/Extensions/FG/bin# ./fgwrite -v /hdd/backup/OpenPLi-3.0-beta-et9x00-20130513_usb/et9x0
0/

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

Version 0.4 Build May 13 2013 19:59:11

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
name    device            size image
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
kernel: /dev/mtd1      6291456 /hdd/backup/OpenPLi-3.0-beta-et9x00-20130513_usb/et9x00//kernel.bin
root:   /dev/mtd2    261095424 /hdd/backup/OpenPLi-3.0-beta-et9x00-20130513_usb/et9x00//rootfs.bin
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
flashing et9200 image files ...
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

erasing kernel ...
flashing kernel ...
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000
Writing data to block 5 at offset 0xa0000
Writing data to block 6 at offset 0xc0000
Writing data to block 7 at offset 0xe0000
Writing data to block 8 at offset 0x100000
Writing data to block 9 at offset 0x120000
Writing data to block 10 at offset 0x140000
Writing data to block 11 at offset 0x160000
Writing data to block 12 at offset 0x180000
Writing data to block 13 at offset 0x1a0000
Writing data to block 14 at offset 0x1c0000
Writing data to block 15 at offset 0x1e0000
Writing data to block 16 at offset 0x200000
Writing data to block 17 at offset 0x220000
Writing data to block 18 at offset 0x240000
Writing data to block 19 at offset 0x260000
Writing data to block 20 at offset 0x280000
Writing data to block 21 at offset 0x2a0000
Writing data to block 22 at offset 0x2c0000
Writing data to block 23 at offset 0x2e0000
Writing data to block 24 at offset 0x300000
Writing data to block 25 at offset 0x320000
Writing data to block 26 at offset 0x340000
Writing data to block 27 at offset 0x360000
Writing data to block 28 at offset 0x380000
Writing data to block 29 at offset 0x3a0000
Writing data to block 30 at offset 0x3c0000
Writing data to block 31 at offset 0x3e0000
Writing data to block 32 at offset 0x400000


single user mode ...
rebooting in 1 min  ...
erasing root ...
libmtd: error!: MEMWRITEOOB ioctl failed for mtd2, offset 2752514 (eraseblock 21)
        error 22 (Invalid argument)
/dev/mtd2: MTD writeoob failure
flashing UBI root ...
Bus error

Edited by betacentauri, 14 May 2013 - 20:28.

[pieterg]

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

I don't think any plugin uses this info nowadays. But it's probably meant for backward compatibility with dmm's dvbmediasink, which uses boxtype rather than chipset to find out which codecs it support.

[greatred]

root@vuuno:~# /usr/lib/enigma2/python/Plugins/Extensions/FG/bin/fgwrite /media/hdd/backup/vti/vuplus/uno

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

Version 0.4 Build May 13 2013 19:59:11

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
name    device            size image
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
splash: /dev/mtd3      2097152
boot:   /dev/mtd2      4194304 /media/hdd/backup/vti/vuplus/uno/boot_cfe_auto.jffs2
kernel: /dev/mtd1      4194304 /media/hdd/backup/vti/vuplus/uno/kernel_cfe_auto.bin
root:   /dev/mtd0    119537664 /media/hdd/backup/vti/vuplus/uno/root_cfe_auto.jffs2
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
flashing uno image files ...
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

no splash image file found!

root@vuuno:~# ls -la /media/hdd/backup/vti/vuplus/uno/
drwxr-xr-x    2 root     root          4096 May 12 19:20 .
drwxr-xr-x    3 root     root          4096 May 12 19:20 ..
-rwxr--r--    1 root     root           812 Feb 16 10:23 boot_cfe_auto.jffs2
-rwxr--r--    1 root     root       3613506 Feb 16 10:23 kernel_cfe_auto.bin
-rwxr--r--    1 root     root      88997888 Feb 16 10:23 root_cfe_auto.jffs2
-rwxr--r--    1 root     root       1244214 Feb 16 10:23 splash_cfe_auto.bin

 

Cannot get past this "no splash image file found". The file is not recognized.

[Lost in Space]

OK, thanks for the input. This means I have to make --splash and also an extra --boot and --kernel for supporting all variants possible and not only the kernel & boot as it is now. And you are right as I didn't know if and who uses splash files i didn#t add code for the filedetection yet, but at least the partition detection now shows them.

 

This is a little bit like a puzzle, as long as you don't have all pieces it is hard to put it together and you are offering new pieces only at slow pace :-)

 

Anyway, I'll try to put all your inputs in a new version and then we will see if we have any improvements.

 

And please don't fortget to try also the -j option as suggested when you get to actually erasing and flashing already but get these flashing errors.

 

PS: I'm stil lwaiting for the other VU boxes if they work already, just knowing the solo2 is OK is a little bit boring.

 

gutemine

Edited by gutemine, 14 May 2013 - 22:53.

[ozkaradag]

I'd like to help you for Vu boxes, but I do not know what to do, man.

I'd love can show the way.

Yours...

[betacentauri]

Hi Gutemine,

I didn't use -j switch, because I don't need it to flash a self compiled kernel (I already did it several times).
Is it possible that I need -j for rootfs and not for the kernel?

[Lost in Space]

The -j switch will only change the behaviour of flashing kernel, as this is written with nandwrite. It only controlls how the Freespace in the flashpartition will be marked on the erasing, if there is FF or 00 used as marker for empty blocks if I remember right.

 

The old VU boxes which started with jffs2 root images need it the jffs2 way the new ones which never had jffs2 support in bios don't need it.

 

Problem is that we need to find out on the et boxes if their kernel needs -j or not when writing.

 

ubifiormat which is now used for flashing the root should do the bad block handling already himself so the flash_erase with our without -j is not making a difference as it is not used for root.

 

And yes, for testing purpose flashing with fgwrite -k only the kernel is a good starting point as this doesn't need single user mode or reboot and we then don't mess up different flash writing methods.

 

I already explained, the fgwrite is just an all in one binary for flash_erase, nandwrite and ubiformat code all linked together static in a single binary, so for kernel you can try out flashing the kernel with the binaries as in the shellscript and if you ten tell me the working parameters and arguments for them I would simply pass them also to the subroutines of the wrapped binaries in fgwrite.

 

That's the reason why I repetetly ask for flashing tests on the old VU boxes and not only the solo2, as only if they work also it would proove that all routiens are properly wrapped and called from fgwrite.

 

But it isn ot not a problem to test also the other boxes but then you have to provide the necessary input to make it run.

 

PS: the splash image flashing is already included in the next version of fgwrite - hopefully I can post it in the evening.

 

gutemine

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

[ColinB]

XP1000 with FG v6 seems to be working fine from putty but I can't work out how to use the GUI without it going greenscreen.

 

I've tried zipping the folder, the individual files and files and folder. Gui see any *.zip file. Can you help ?

 

 

Attached Files

•  FG 2.png   26.58KB   23 downloads

[ColinB]

XP1000 FG v6

 

This is the crash log I got when trying to install via the GUI, maybe its of some help

 

 

 

 

Attached Files

•  enigma2_crash_1368631942.log   16.98KB   6 downloads

[Lost in Space]

Attached is the Version 0.7 of Flash Gordon Plugin including fgwrite 0.5 binary

 

The fgwrite 0.5 now hopefully also is able to identify and flash splash*.bin files - please test if they are now properly deteced and the mtd partition where they should be written is properly recognized - in case your box has such an option.

 

xp* is now also included in the Plugin and the Plugin hopefully it will not crash anymore on any 'unknown' box.

 

fgwrite binary is now linked from the bin directory of the FG Plugin to /usr/bin/fgwrite so you can execute it in telnet without fill path or by going to .../FG/bin.

 

Instead now simply typing fgwrite ... should be sufficient - hopefully this makes testing easier.

 

-s is now used for --splash option, and only -f force reboot remains (no more extra single user mode option, as -s -r was useless).

 

Have fun testin

 

gutemine

Attached Files

•  enigma2-plugin-extensions-flashgordon_0.7_all.ipk   45.94KB   18 downloads

Edited by gutemine, 15 May 2013 - 18:46.

[ColinB]

Just tried via GUI (FGv6 Flaming Torture)  on   XP1000

 

"Not flashing, because image is for kernel.bin and receiver unknown!"

Edited by ColinB, 15 May 2013 - 19:11.

[Lost in Space]

Buggy :-)

 

Does the flashing via fgwrite in telnet work with the current binary ?

 

And have you tried if the formatting errors dissapear if you use -j option too ?

Edited by gutemine, 15 May 2013 - 19:26.

[Lost in Space]

I just checked the code - it is done the way PLi packages the images for the xp - eg in a xp1000 subdirectory and there the rootfs.bin and kernel.bin

 

In your case the ZIP seems to contain no subdirectory at all . Did an imageteam package it this way or you yourself ?

 

Please try with the PLl Image in /hdd/backup too

Edited by gutemine, 15 May 2013 - 19:42.

[ColinB]

edit: (FGv7 Flaming Torture)

[Lost in Space]

FG has lots of episodes, so we will not run out before it is done :-)

Edited by gutemine, 15 May 2013 - 20:25.

[ColinB]

FG has lots of episodes, so we will not run out before it is done :-)

Cool

 

fgwrite from root@xp1000:/#  

 

also GUI wont save changed path in Configuration. Reverts to default /media/hdd/backup

[Lost in Space]

Please answer my question, does the fgwrite -j /hdd/backup/your_image_directory... prevent the errors and the box still boots after flashing, or doesn't it make any difference ?

 

What subdirectories does your zip have ?

 

If you don't know post me the output of unzip -l /media/hdd/backup/you_image.zip

 

I can only fix the Plugin with this input. If nobody is helping then I will remove the box checking completely from the plugin as nobody seems to care anyway.

Edited by gutemine, 15 May 2013 - 20:37.

[theparasol]

I can only fix the Plugin with this input. If nobody is helping then I will remove the box checking completely from the plugin as nobody seems to care anyway.

 

I do care, but the XP1000 is our livingroom tuner and the wife isnt in for a long or short break of her favorite programs... I'll report later this evening for sure!

[Lost in Space]

an unzip -l on your linux PC will not do any harm :-)

 

But I'm patient ...