How to build Pli image no need of password public.

Rat

VIP Member
VIP Member
Joined
Aug 29, 2001
Messages
41,825
Reaction score
12,523
No idea how long this will be available so if you fancy a go :)

Code:
You don't have permission to view the code content. Log in or register now.

Also Check Post #5
 

Attachments

  • how to build Pli image.rar
    3.6 MB · Views: 23
Last edited:
Do we just fallow ABC?

Sent from my Xperia X10 using Tapatalk 2
 
this 'sounds' like some questions i answered yesterday lmao

right, first off, you will need a full on linux build environment, then you will need to be able to create, and check, a complete OpenPLi Vu+ build, all of this is the hard bit, once you can do this, and create a booting, working, OpenPLi image for the Vu+ duo, then this is of use to you, as long as you have a tm-twin

the next stage is to basicly 'fallow A-B-C' as pointed out in the attached file

download the TM-twin staging drivers
extract the script to specified location
run the script

and it spits out a fully 'booting' openpli tm-twin image

simples, right?

now when you boot the image, youll notice that all the way through, it refers to dreambox in the wizard, itll show the dreambox remote, then when you go to the about screen, itll report the hardware as a Vu+ Duo

but it boots, and for the majority of functions, works, a few 'extra' buttons on the remote dont function as standard, but if you got this far, you can fix this in the next step

now you have a working image, you next need to edit your source files, get rid of the dreambox stuff, change the scripts that say Vu+ duo, rebuild the image, and test it again

after a few passes and edits (i generally create a minimum of 10-15 images while editing stuff) youll end up with something more personalised

a good place to start, is here https://www.digitalworldz.co.uk/index.php?threads/285646/

untill you can create a fully working Duo image though, this is of no use to you
 
Last edited by a moderator:
It only makes the oe_rootfs.bin
The images that are released by tm contain

cfe.bin
oe_kernel.bin
oe_rootfs.bin

So once again no real access to the code just a way to rebuild the rootsfs system.
Better than nothing but not exactly full access ?
I hope the pli boys were being offered more than this last week as I don't think they would have thought much of it to be honest.
 
UpDate........................

Code:
You don't have permission to view the code content. Log in or register now.
 

Attachments

  • 1-build-4tm-PLi.tar.gz
    3.6 MB · Views: 4
  • 2-Makefile-2.1.tar.gz
    1.6 KB · Views: 5
Last edited by a moderator:
It only makes the oe_rootfs.bin
The images that are released by tm contain

cfe.bin
oe_kernel.bin
oe_rootfs.bin

this is something ive asked about, in quite a lot of detail, as in different TM beta releases, theres been anything from just one, to all 3, of these files present

the rootfs is exactly that, just the rootfs file system, which contains just about everything you need to get an image working on a box that already works, its a simple 'update'

the kernel one is an update to the linux kernel itself, and while it IS a very important part of the receiver running, this is a deeper level update, which doesnt need updating as often as the rootfs would when changing images

the cfe is even deeper again, this deals with the way the receiver boots from the very begining, this will need even less changing than the kernel one would

the last change to the cfe, was to ensure people couldnt 'accidentally' flash their receivers by leaving in a usb device with an update on it, it used to just update, and start the wizard if an update was found, since the last cfe update, about 9 weeks ago, if an update is found on a connected usb device, it now informs you onscreen that an update has been found, and prompts you to 'PRESS OK' to start the update process, otherwise, it ignores the update, and boots as normal

the kernel will next need updating when the driver files are sorted out to use the latest linux kernel (3.1.2 i think? not too sure)

untill then, the rootfs is all thats needed to 'make' youre own working image boot on the twin
 
I don't know where your getting them from as the makefile is for a dm8000
I have attached it edited for the vuduo
You won't compile from just that without setting the build environment.
To be honest bad information is as bad as no information.

Sorry to be the bearer of bad news.

@digi I havn't had a play but I'm pretty sure with what is here you can't even change the 1st boot screen. I will have a play this weekend, the fact the kernel isn't changed very often shouldn't deny us access surely ?
 

Attachments

  • 2-Makefile-2.1(2).tar.gz
    1.6 KB · Views: 2
Last edited:
I'm getting the files from Tech no mates download centre mate
I'm uploading them here direct in case they pull the files

I can assure you it's not me giving wrong files knowingly


Sent from my iPhone
 
I was only saying as if we post their information and it's wrong we will get the blame :(
I thought you was getting it from a special source, they need to update their download centre then.
 
ive created god knows how many twin images over the last 2 weeks trying different things out, heres how

first off, you MUST follow ellies post, and create a full build environment

ive not looked at the makefile attached, but im assuming that its for openpli, which can make for a lot of different receiver, so edit it to make for Vu-duo (or use ellies edited one)

next is the hard bit

create a WORKING vu+ duo image

now, its a HUGE help if you have a vu+ duo to test this on, or at least know someone who can test the file you create for you

getting the openpli image working is the hardest bit, once this is done, you then have everything in place to create (if you really want to, lol) a twin image

really speaking, the ONLY file you need, is the build-4tm-PLi file

once you have a working duo image, and the file system setup that the duo image was created FROM, extract the TM file as directed

when you execute the script in this folder, it will copy the entire vu+ duo rootfs filesystem to another location, it will modify the new copy, and spit out a working, booting, TM-twin image

the image WILL have the usual openpli DMM references, as well as Duo references, but, itll work

but this new file system, you can now edit away untill the cows come home, rebuild each time, and reflash your twin, and see the changes happen on the receiver after each reflash

after creating the first image, an edit, rebuild and reflash, can be done in less than 20 mins

after first creating the openpli image that has been released, we to make the DW one in less than 24 hours, including completley fooking it all up to the point that i had to erase everything and start over

if you want, over the weekend, ill type a full guide on how to make one :)
 
To be honest there is no reason assuming the mkfs.jffs2 can be run from the twin (it should be able to) that all this can't be done on the twin box itself, you are in effect only playing with the image as it is on the box, if it had a backup facility then wouldn't need to go to all this aggro if your a newbie and want to customise your box.

It was done this way on the dbox2 5 years ago. Seems a waste of computer space in my book for the average user.

If I get a chance I will have a play this weekend.

https://www.digitalworldz.co.uk/index.php?threads/221836/#post1643334 if you look in /var/bin at the ops file it will show you how it was done then, it can easily be simplified just for the twin (or the duo using the correct mkfs.jffs2).

Could just release regular blank pli backup for general users to play with.

But leave the build information for people who want to delve a little deeper.

Havn't used this method for a few years (since I skipped my dbox2) as the dm500 was squashfs and never had the memory or space to cope, but in theory with the twin being jffs2 so long as the box has enough memory it should work. Space shouldn't be a problem on the twin it's just if there is enough memory. If not there is no reason the lot could not be mounted, tarballed and then played with using linux in a vm window and turned into oe_rootfs.bin there without the need for the full build environment as we used to do on the dm500.

Any big changes will always be in the hands of iq as they are holding onto the kernel :( but we get to play a bit.
 
Last edited by a moderator:
This is how we used to do the squashedfs on the dm500 boxes
to edit the squashfs partition

Code:
You don't have permission to view the code content. Log in or register now.

Copy that file via FTP to your linux distro using gftp which is the icon after the system tab (you can make the tar file from the blue, extra's, dev section, tar/backup/flash (local), green)
open a terminal window (last icon)

Code:
You don't have permission to view the code content. Log in or register now.

Leave the terminal open.

This will give you folder called root edit the contents as if they were on the box itself.
When finished go back to terminal and

Code:
You don't have permission to view the code content. Log in or register now.

the ftp it to the box and
menu
service
image upgrade/backup
flash one partition
Dreambox SquashedFS

So you need to find what mtdblock the jffs2 is on
Code:
You don't have permission to view the code content. Log in or register now.
mount it to say /tmp/root
tarball it

copy to a linux desktop and untar it.

have a play then
./mkfs.jffs2 --disable-compressor=lzo --compression-mode=size --eraseblock=0x20000 -p -n -l --pagesize=0x800 --root=$DEST_ROOT --output=update/tmtwin/cfe/oe_rootfs.bin

The --root=$DEST_ROOT would depend but following this as a rough guide it would be --root=./root the ./root means where I am and I can see /root with an ls you could put --root=/tmp/root
So long as the mkfs.jffs2 supplied by tm is on the desktop it will work without any need for a build environment.

To be honest it should work on the box without the need to tarball it up at all unless there is not enough memory, you could put the mkfs.jffs2 file in the /bin directory on the box and leave it there.
 
Last edited:
i have the mkfs.jffs2, and the scripts, so what youre saying then, is that we should be able to create a small 'addon' which when installed on the twin, will give full backup abilities to the end user?

by playing with the script then, we could create a 'backup tool' that when run, will allow the user to create an 'as is' copy of their receiver, to USB, as a full recovery backup in case they break things as well?

i can see how itd all work, ill have a play with this and make an ipk of it
 
Need to test it on the box as it wouldn't work on the dm500s due to memory issues, worked fine on the dbox2.
In theory it should work on the twin and the duo (duo needs a different mkfs.jffs2 file but will be in the build environment for the duo somewhere)
Will most probably work on most boxes but never really bothered to look as normally do the whole image not just part of it.
I started on the dbox2 using cryogenics scripts before I learnt to compile.

With this if it works they don't need the whole build environment as should be able to just do the playing live on the box.
 
Last edited:
i have the mkfs.jffs2, and the scripts, so what youre saying then, is that we should be able to create a small 'addon' which when installed on the twin, will give full backup abilities to the end user?

by playing with the script then, we could create a 'backup tool' that when run, will allow the user to create an 'as is' copy of their receiver, to USB, as a full recovery backup in case they break things as well?

i can see how itd all work, ill have a play with this and make an ipk of it

ok ive just woke up so forgive me if this is a stupid question but have you tried using the backup suite plugin to make a full USB backup of the image ? cant try it my self as i dont have a twin but i cant see whay it would not work.
 

Attachments

  • enigma2-plugin-extensions-backupsuite_9.4_mipsel.ipk
    48.9 KB · Views: 4
ok ive just woke up so forgive me if this is a stupid question but have you tried using the backup suite plugin to make a full USB backup of the image ? cant try it my self as i dont have a twin but i cant see whay it would not work.

ive tried this ;)

it makes a ~245Mb file for the Vu+ duo
 
I'm on the works lappy so can't look at it but in theory if it works on the duo it can work on the twin.
Will look at it when I get in or over the weekend, not worth reinventing the wheel if this will work with a few tweaks.
Hope they havn't deleted the .py files.
 
To be honest there is no reason assuming the mkfs.jffs2 can be run from the twin (it should be able to) that all this can't be done on the twin box itself, you are in effect only playing with the image as it is on the box

so this is not the source that say coders like PLi would be interested in then ?
playing with it as you would on the box ? so no pc is needed for this code ? but you cant save changes

are these files that TM are giving out to public of much use ?
 
No pli would not be interested in this, they want full source
Code:
You don't have permission to view the code content. Log in or register now.
I don't think what we have been given meets the above requirements, I don't think it gets anywhere near.

We have to be happy with the bone we have been thrown even if it is insufficient it is all we have and are likely to get.
 
Back
Top