Lost in Space

Look, I'm the least person scared to get burnt.

But one of the secrets to be successfull is beeing efficient, which means the faster you rule out dead ends the faster you find working pathes. And this was exactly the reason why I answered originally and tried to explain the impact and consequences of their so far findings.

The point is not that I could do better, or have done better.

And I'm the last person also to cut off weird ideas.

One of the weird ideas I ever have had was how to finally solve the ubifs extraction problem AFTER I failed 3 times (taking experts advice btw.) - so I will NOT repeat this mistake from the other side here. And this is for the better of all involved parties!

Total waste of time.

With a Debian Wheezy Installation from Barry Allen on my Dreambox 7020hd it took less then 2min to do the job.

cat /proc/stb/tpm/0/serial
cat /proc/stb/tpm/0/ca/*

 

You are simply not understanding that I have to spend time and effort on supporting your image stuff, even in passive mode  - and if it is now wasted, why should I continue to spend it ?

PS: And you can have as many heros as you want - but don't ever try to put such an idiotic title on me.

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.

Are you KIDDING ?

Maybe you should first ask Meo for permission if he wants his hacked sources to be officially checked in ?

I already wrote above that VU is a special case. I only said that it is not difficult to understand why VU and others behave the way they behave - and repetitive negative comments will not change anything due to this.

And a community needs to bee (well) fed to be cheering - panem et circenses - this advice is now close to 2k years old, so I don't feel guilty to repeat it.

If you get a track record of having old drivers, kernels and Plugin Versions and blame the vendors or Plugin builders not to deliver commits ... then maybe you (not personally off course) are part of the problem.

But good advice is hard to take, even I often have problems taking it when I get it

Then read once more what I wrote. VU 'paid' Marusys to copy all the needed stuff including ho to make the camembert eatable and now that they have the code AND the knowledge they don't need us/you anymore.

But the shellscript has lots of bugs anyway, better call housekeeping.

maybe consider to use dFlash and not the sh* for clones.

First you said it is not kernel standard, then your said yes, second you said it works not with NAND flash, then you said yes, third you said it doesn't work with ubifs, then you said yes - I'm a little bit confused and hereby ask for better explainations in the first run

And nandsim has a nice file cachhing mechanism and off course you have to use this on a reciever instead of buffering everything in ram as you would do it on a PC.

And there is only 1 single patch needed to make ubifs work, you have to kick out the writesize=1 single byte parameter. All the other patches are just for memory saving on the fix freespace mount of ubifs, or for allowing also block2mtd unload of devices. The only patch I added was to specifiy writesize as an option to allow using the standard ubifs settings equal to what the flash has. I collected these patches and DMM checked them in, and I'm pretty sure that they know what they have done.

If you consider this as too complicated, I will have to accept this - even when it is hard to understand.

But then we are back to the question why the nandsim module is not avalable in Standard OpenPLi ?

I will NOT trust you on something which works since 2 months now like a charm as I had more then a look and made it work

And if you are emulating and don't have real Flash underneath there is no real need for subpages either.

But we can make a deal - you check in the same patches as you already checked in for the Dreamboxes for the other boxes too and I proove you that I'm right and ubifs works nicely

And regarding the nandsim module - for this there are 0 patches needed, you can take them as they are and they will build nicely working modules for ALL up to date kernel versions.

nfidump root_cfe.bin works nicely, so the name is a little bit misleading :-)

And I'm pretty sure that block2mtd.c doesn't need any 'strange' kernel patches, as it is part of the mainstream kernel since ages now and only uses other stuff like mtdcore which is also needed anyway or you would not boot from nandflash at all.

BTW you have the block2mtd module includes on your dreambox kernels when you added the UBIFS support so you have the patches needed already in your OE and all of them except one are even signed off by the mtd devs :-)

And the NOR Flash only story is not true since mid 2012 if i remember correctly (at least since then I use it without any troubles), since then you can easily run jffs2 on it, the patches needed are only to make ubifs happy.

Regarding the nandsim module - there is at least one imageteam which builds them in their vu image (as module) and has them also on their softwarefeed and it loads nicely also into an OpenPLi image is was told, so there the argument with strange kernel patches needed doesn't work either.

If you want I could try to download the nandsim ipk of one of these boxes and you can test if they do any harm.

Actually I have 3 different ways of using it in the meatime:

nfidump uses it to extract ubifs images with a single binary without the need to load any further modules like nandsim

rambo allows you to boot the root image with ubifs or jffs2 from an USB or SATA device by using block2mtd. In this case it is not expaneded or extracted, the box's root really runs this way via block2mtd.

A still non-public version of this allows you even to flash the ubifs images to SATA or USB rawdevices, but without block2mtd you can't mount or boot the devices.

Finally all my tools that use nfidump to extracti mages to USB or SATA, either for single or multibooting are doing this in case of UBIFS with the help of block2mtd (but nandsim can do the job also, I don't have any preferences, except that lbock2mtd is so lightweight that it even fits in the kernel nicely so you avoid the hassle of modules installing and loading)

Buiding the modules and putting them on the feed should not be any problem in my understanding, as in DMMs OE 2.0 a simple bitbake is all that is needed to get them, and I was assuming that the same applies to OpenPLi, that's why your answer that they are not needed surprises me a little bit.

Well, live is not that easy for some applications and on boxes with small flash for example.

But where is the problem to have one or both on the feed, so that people or applications can install them if needed ?

You just force people to other images with the driver(s) included, or at least on the feed, that's the simple reason why I'm asking.

gutemine