178 replies to this topic

[Lost in Space]

Please try this Version, maybe this works better

 

If not then I need the fgwrite output as already written.

Attached Files

•  enigma2-plugin-extensions-flashgordon_0.4_all.ipk   45.3KB   39 downloads

[Taykun345]

Here is info for ET-5000 receiver. Hope it helps.

 

mtd0: 07f00000 00020000 "complete"
mtd1: 00600000 00020000 "kernel"  
mtd2: 07900000 00020000 "rootfs"

[offnow]

Probiers doch mal einfacher - das zu flashende image auf den schon in der Box befindlichen usb-stick schreiben und reboot in die Konsole hämmern...

Den Rest machen die jeweiligen Bootloader besser selber - badblocks von denen die User was mitbekommen gibts bis jetzt nur auf Dreamboxen und es wäre Nett, wenn das auch so bleibt...

[haegaz]

here is a bootlog from Solo2

 

 flashgordon.log   63.56KB   15 downloads

[Lost in Space]

Probiert einfach mal das nandcheck im FG Plugin aus - zu finden auf Blau und dann Gelb. Dann weist du das fast jeder Flash Bad Blocks hat weil das Teil des Hardwaredesigns ist, und wenn du nandwrite benutzt OHNE die ggf. zu markieren wenn sie bad sind beim schreiben dann ist das nicht gescheit. Und ja das Bios macht das, das script aber nicht, FG schon.

 

Simply try our the nandcheck in FG Plugin - you find it at Blue and then Yellow. Then you will see that every Flash as bad blocks, as this is part of the Hardwaredesign, and when you use nandwrite WITHOUT marking them, if they are showing to be bad on writing  then this is not very clever. And the Bios does this, the script doesn't and FG does it too.

 

Thanks for bootlog, please check the root /dev/mtd0 device with Checking in FG to see if these Blocks are really bad or just went bad on writing with ubiformat, as we try to find out if the parameters I used for ubiformat are correct.

Edited by gutemine, 12 May 2013 - 18:56.

[haegaz]

check /dev/mtd0 and 4 B at the end

and 4 B between

[Lost in Space]

OK, read the legend in the Plugin, Bs at the end are not really Bad ones, in the middle they are and were marked by the Bios as BAD.

 

These blocks will not be used when flashing as they are already marked, but if during write with nandwrite without markbad option a NEW bad block will occure this will not be marked as bad and hence the resulting flashimage will be corrupt and it only depends on which file is written if and how long it will work. It is nothing bad either, then simply the kernel when he tries to re-write this block will mark it as bad or the Bios when flashing with USB if the box suddenly doesn't boot.

 

But this means you are allowing the possibility of undetected corruption just bei using nandwrite without the markbad option.

 

With ubifs this problem is not that big as ubifs uses its own bad block handling, BUT then you should use ubiformat to flash ubifs images not nandwrite to correctly handle this as nandwrite is not knowing anything about ubifs bad block handling.

 

But I start to explain what you can learn easily from mtd and ubifs FAQs - check there how it works.

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

[Lost in Space]

Do we play here Mikado - who moves first has lost ?

 

It doesn't help if > 20 people download the ipk and the feedback is close to 0.

 

Either you are trying out and provide usefull input or we cancel the project and Flash Godon continues to play polo and you continue to play/flash with your USB sticks

 

And yes, I'm patient ...

[Persian Prince]

for vuultimo :

dev:    size   erasesize  name
mtd0: 1f200000 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"
mtd8: 1fc00000 00020000 "data"

[Lost in Space]

This leads to an interresting question, should I include also the flashing of splash images, as the script doesn't to this either ?

 

And yes, I will add also 7&8 as mtd to be checked by nand_check binary in next version.

[Persian Prince]

also it's not just  /proc/stb/info/boxtype

 

/proc/stb/info/vumodel (VuPlus)

/proc/stb/info/azmodel (AZBox)

/proc/stb/info/gbmodel (GigaBlue)

/proc/stb/info/hwmodel (Technomate)

 

or even /proc/stb/info/model

 

[Lost in Space]

It would be easy to add all these, but as so far nobody really tested if it works on all the VU+ and et* models that are already supported, WHY should I add them now ?

 

And lots of them don't have any official PLi support either.

 

We will see what the time brings ...

Edited by gutemine, 12 May 2013 - 23:33.

[Lost in Space]

Here's at least a version which reads the mtd partitions for nand check from /proc/mtd itself.

 

But there will be NO further version UNLESS we get testreports for ALL the vu* and et* boxes which should work already.

 

And ONLY if this task is finished any further features or boxes will be added.

 

 

[Lost in Space]

Here's at least a version which reads the mtd partitions for nand check from /proc/mtd itself.

 

But there will be NO further version UNLESS we get testreports for ALL the vu* and et* boxes which should work already.

 

And ONLY if this task is finished any further features or boxes will be added.

 

 

Attached Files

•  enigma2-plugin-extensions-flashgordon_0.5_all.ipk   45.33KB   17 downloads

[Persian Prince]

i think it's a good idea to add support for all brands/models because there is at least one unofficial image based on PLi' sources for them

 

more brands/models more tests

 

up to you

[Lost in Space]

I'm well known to do only what I want anyway.

 

And if people are not even interested in the mainstream boxes, the discussion is useless.

 

As fgwrite is just an elegant all-in-one binary for the shellscript approach you can always extend it on your own.

 

Actually the approach to do boxtype detection is not really sensemaking either.

 

Correct implementation would be to read the devices from /dev/mtd and read from there which one is kernel and which one is root as the parition labels are also used by the bios when flashing.

 

Then it would work on any box without any changes as the nandwrite and ubiformat are already reading the flash geometry themselves and only need the correct /dev/mtdX and the correct one should come from /proc/mtd

 

But as already explained, if nobody wants it nobody will do it

[betacentauri]

The image files must be in a zip file? Must it have the same structure (I mean with et9x00 folder in my case) like the image download zip files from openpli? Is using a unzipped folder also possible?

If there's no recording running this afternoon I'll give it a try.

[Lost in Space]

You are welcome

 

fgwrite uses just a directory with all the unpacked *.bin files as argument.

 

Only the FG Plugin takes *.zip at /media/hdd/backup as source of his journey to make the users live easier, but it unpacks the zip also

to /media/hdd/backup/imagename and then the structure it finds within the zip with vendor box subdirectories (or just box for the et*).

 

Please read the example for the fgwrite command which I posted to get debugging output on the first page of this thread. The Plugin ist just a wrapper for nand_check and fgwrite binary.

Edited by gutemine, 13 May 2013 - 09:19.

[rtzhjgg0]

Just integrated Flash Gordon to Sofa Flashing 

[Lost in Space]

fine when you are already happy on your solo2, but I need inputs on the other boxes too or fgwrite will stay as it is.

Edited by gutemine, 13 May 2013 - 11:55.