Please try this Version, maybe this works better
If not then I need the fgwrite output as already written.
Posted 12 May 2013 - 17:50
Here is info for ET-5000 receiver. Hope it helps.
mtd0: 07f00000 00020000 "complete"
mtd1: 00600000 00020000 "kernel"
mtd2: 07900000 00020000 "rootfs"
Posted 12 May 2013 - 17:51
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...
hab keine Lust mehr...
Viel Spaß allen und lebt wohl
Posted 12 May 2013 - 18:55
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.
Posted 12 May 2013 - 19:19
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.
Posted 12 May 2013 - 20:15
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 ...
Posted 12 May 2013 - 23:10
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"
Open Vision sources: https://github.com/OpenVisionE2
Posted 12 May 2013 - 23:26
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
Open Vision sources: https://github.com/OpenVisionE2
Posted 12 May 2013 - 23:29
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.
Posted 12 May 2013 - 23:44
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.
Posted 12 May 2013 - 23:44
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.
Posted 13 May 2013 - 00:33
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
Open Vision sources: https://github.com/OpenVisionE2
Posted 13 May 2013 - 08:35
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
Posted 13 May 2013 - 09:07
Posted 13 May 2013 - 09:16
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.
Posted 13 May 2013 - 10:36
Just integrated Flash Gordon to Sofa Flashing
USB drive flashing & FTP + TelnetStarted by Kuanyi, 30 Sep 2020 Flashing |
|
|||
Flashing a Dreambox 500HD errorStarted by Tvile, 22 Mar 2013 flashing |
|
0 members, 24 guests, 0 anonymous users