178 replies to this topic

[pieterg]

you should not write a ubi image with nandwrite, because nandwrite overwrites empty pages, causing bitflips in MLC.
Because a lot of people still think nandwrite is the easiest way to flash an UBI image, the UBI people have given up and implemented a workaround, which erases all 'empty' pages at the first mount attempt.

Vu+ happens to enable this option in their ubi image (causing a rather slow first boot).
That explains people do not get these errors with the restore script you mentioned, on vu+ boxes.
If you want to use nandwrite to flash ubi images on other boxes as well, you should build your ubi image with the -F option (applied to mkfs.ubifs)

However, in my opinion this is an ugly workaround, which should be avoided (because it needlessly erases your flash at the first rootfs mount, and makes the first boot rather slow).

On vu+ this option is required, because apparently their bootloader does not have UBI support, so they use the -F option to fixup the images which the bootloader flashed.

[Lost in Space]

Marking bad blocks is NOT the problem it actually avoids the one these scripts have. BUT ubifs has its OWN bad block handling, if you mess that up you make it worser then when using plane nanddump.

 

Check libmtd and then you know what needs to be done to use ubiformat while it is active.

 

Off course it would be nicer to add a volume and then rename and delete the old one - BUT this is also hard for a used volume and you actually would need to do it in an initramfs when root is not active at all, a chroot will only make the problem worser, unless you would boot completely from USB as I do when developing such tools as fgwrite or nfidump.

 

I could do this in my initrams but if you start from scratch debuging it in single user mode is a nightmare. It took me a couble of months to make my initramfs binary fully operational, because the typical heavy initramfs is way to big for a set top box. And using the volume switch approach would mean that the Flash always could be filled only 50% as you otherweise can't add a new volume while the old rootfs is active. Hence I dropped this approach but that doesn't mean it is not feasable and usable.

 

But now you maybe understand a little bit better why I wrote that the code is not the problem as it is all available, it is the knowledge how to use it and the understanding and testing to really make it work.

 

Dreamboxes btw. also use -F on mkfs.ubifs to fix the freespace when flashed with nandwrite. But if all the relevant patches are used it is not really that slow on first mount as only the header is written with the proper freespace marker and as you use 2k Blocks that are not that many.

 

But you are right on theat it is not the optimal way to do the job and that is the reason why I switched to ubiformat to make fgwrite also operational on other boxes.

 

gutemine

Edited by gutemine, 28 May 2013 - 22:03.

[betacentauri]

At first I tried to use ubiformat. Then because of the problems I used nandwrite, which I thought is working. I learned that it is not working the hard way

 

So thanks for the hints. I'll learn by doing (or better by flashing ).

Edited by betacentauri, 28 May 2013 - 22:08.

[pieterg]

Off course it would be nicer to add a volume and then rename and delete the old one - BUT this is also hard for a used volume and you actually would need to do it in an initramfs when root is not active at all, a chroot will only make the problem worser

use pivot_root to switch the root to it, then chroot into it (to let go of the shell in the old rootfs)

[Lost in Space]

Just chrooting out of the flashimage doesn't make the old root filesystem unused so you are still able to corrupt it. Only an initramfs would be able to really do things as it runs out of a memory based filesystem before actually the root is used. Guess what the initramfs of your boxes is probably doing as I was told they uses ubiformat also for flashing the root_cfe_auto.bin. OR you boot the root from USB or SATA then you are also save as kernel is only decompressed to memory and then runs from there, so you can replace it while running without problems. This is how I develop the stuff, because then i can flash and ubiattach and mount and detach and ubiformat as much and as often as I want until it works. And then you make it run to change the tires while the car is rolling ...

 

PS: Initramfs normally runs the other way around - after doing its job it chroots into the real root filesystem.

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

[pieterg]

I did not say chroot, I said pivot_root (followed by chroot to release the shell)

[Lost in Space]

I've read it put if you know how both are implemented the difference is marginally as still you will not get full release of the filesystem where you started your journey if it was already fully used as in our case.

 

And it is not needed either. If your binary is a statically one you can easily stay in the current root, you only have to inhibit further IO to prevent corruption.  So the trick is to remove the air pressure in the tires and not to switch to a bike, then car has to drive so slow that you can change the tires (bad explaination ... I know). fgwrite code for syncing and remounting read only and entering single user mode is only a handfull of codelines and has prooven to work.

Edited by gutemine, 29 May 2013 - 06:20.

[darkmantk]

@gutemine

 

Odin M7

 

root@odinm7:~# cat /proc/stb/info/boxtype
odinm7

root@odinm7:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 20000000 00020000 "complete"
mtd1: 10000000 00020000 "os1"
mtd2: 00800000 00020000 "backup"
mtd3: 00600000 00020000 "kernel"
mtd4: 0f200000 00020000 "rootfs"

 

Thanks!

[Lost in Space]

as root and kernel seem to be properly named the fgwrite binary should work. Please try out yoursefl as explained here in the thread.

[rtzhjgg0]

FlashGordon don't works here (from today) - can someone confirm this ?

 

expired ?

[betacentauri]

It may very well be expired. It's not the first time that gutemine has added an expiration date...

You can call the tool from telnet (goto plugin directory and start fgwrite). Maybe you see a log message there. 

 

As alternative you can try my tool:

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

It should work with duo2, but afaik it's not tested with a duo2 until now (with solo2 it works). If you want to test it, put the zip file on your box (at best on your harddisk). Then login via telnet and do the following:

cd /media/hdd
unzip ofgwrite.zip
chmod 755 ofgwrite
./ofgwrite -n -r -k <path to image files>

This doesn't start flashing. It only shows some informations. There should be at least 2 lines for rootfs and kernel and both should contain the correct filenames.

You can post the output here or in the ofg thread. Then I take a look. Without -n switch, flashing starts.

Warning: Use at your own risk!

 

Afterwards you can use dima73 plugin to flash images:

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

Edited by betacentauri, 1 September 2013 - 11:21.

[radxnl]

FlashGordon don't works here (from today) - can someone confirm this ?

 

expired ?

 

as i said here http://openpli.org/f...ndpost&p=351129

 

so yes... better use the one from betacentauri, it's opensource

[rtzhjgg0]

... better use the one from betacentauri, it's opensource

 

...and it works

[Happysat]

Owh noes Dflash < 9.26 dito

[Lost in Space]

It is fun when people complain that they have to upgrade who didn't contribute to make the new versions.

 

So your next homework is to write a working open source user space ubifs extraction tool which doesn't use block2mtd or nandsim or mtdram

 

And hence it works under Windows too ... and extracts a complete PLi ubifs Image in 2 Seconds on a Linux PC:

 

>>> Extracting of OpenPLi-3.0-beta-dm7020hd-20130824.nfi
>>>  found 5361 files and was finished in 2 seconds
 

Edited by gutemine, 1 September 2013 - 18:47.

[Happysat]

Yea right you know what nowadays happens with people who drop bombs   even if there cargo is loaded with time

 

Edited by Happysat, 1 September 2013 - 19:09.

[Lost in Space]

Well, it is well known that I ONLY support latest versions of my Plugins, and as this was ignored too often you (not in person) have to live with the result.

 

But as the FG Plugin was done to proove that it is possible to have an all-in-one binary for flashing instead of using multiple binaries and shellscripts the purpose is now fullfilled, so why should I maintain it any further ?

 

dFlash and the nfiwrite binary for Dreamboxes are available and supported from my side, as nobody of your community was willing to make your great Open Source tools work on Dreamboxes - strange, isn't it ?

 

So I think it is not your part to judge. But somebody could close this thread now that it has served its purpose and its time.

 

And don't forget your homework

Edited by gutemine, 1 September 2013 - 19:18.

[betacentauri]

Your homework is not very interesting for me   But perhaps when I have time ... (not very likely. I have other projects in mind...).

 

And I have no dreambox, so I don't know how they work and that's the reason why it don't run on dreamboxes. That's the only reason. If somebody is willing to help me, I'll adapt my code. In the meantime dreambox users can use your tools

[Lost in Space]

I was not putting the critics on you personally - as you wrote yourself, if people would test it and give the needed inputs it would be easy adaptable - as I did fpr VU when I produced fgwrite without even owning one.

 

BUT people which are not doing this kind of contribution should not complain if they run out of alternatives or have to follow the rules the author implies.

 

PS. ubidump is not a 2h job, I already spend 4 man-weeks on it. But I'm a VERY poor programmer and too dumb to understand the UBIFS Filesystem documentation- so I decided to ignore it   And I wrote it completely from scratch without ANY libubi, mtd-util code, I'm not even using their include files. Hence it doesn't fall under GPL - as it only needs C-lib and unchanged minimal lzo and zlib code - otherwise it would not work on Windows too. But from complexits and skills needed it was my personal Mons Olympus, so I decided to go for it.

Edited by gutemine, 1 September 2013 - 19:59.