bacicciosat

Hallo Meo

i tested both fixed files .... it works .. really a great job ,, thak you very much
i dont know meo if you could show more than 4 multiboot images in bootmenu
it shows here (flash) + 4 multiboot images

but you have actually solved the double boot problem , and that was the main issue

But how many images do you want in your box ?

Ok increased limit to 8.

Warning is untested.

At the present time i don't see a solution about this issue. The only solution i can figure is to try to modify the loading sequence of the Vu+ drivers. But i don't like to ply with these things.

Maybe Skaman that is the author of OpenMultiBoot and it knows it much better than me could find a solution.

But he is really busy now.

 

I have to correct myself.

It seems that i found the solution.

Now Bootmenu is available in all the images with OpenGL too.

I have fixed also the issue of OBH not booting when installed in mutiboot.

All is ok now. OpenMultiBoot seems perfect.

Thanks to all the testers.

 

really bootmenu is very useful .. but the only way to use it .. when you boot from pli image

 

The bootmenu only works in OpenPLi as it does not have OpenGLes support (no animations or xbmc).

 

All other images have the later kernel that support the above.

If OpenPLi change kernels to support animations and xmbc, then the bootmenu will disappear completely.

 

Ok a little explanation about OpenMultiBoot and the issue of bootmenu.

OpenMultiBoot is at the present in my opinion the best multiboot solution for enigma2 box.

This because the other multiboot systems like meoboot always load the drivers and the kernel from the flash and later perform a chroot into the target image.

This means that if you have blackhole in flash and openpli in multiboot you will have a mixed image Openpli with kernel and drivers of BlackHole with all the relative issues.

OpenMultiBoot do something different. It backups the kernel of each installed image and store it so when you select the image to boot it flashes the kernel of the image that have to be booted and then boot it with the coorect kernel and drivers.

The only issue of this system is that at every image change, the kernel is "flashed".

This should seems not nice for the flash of the box, but you have to consider that you will never change 10 images every day and that the kernel is really smaller than a full image.

So with OpenMultiBoot we have finally the compatibility with all images and each image will works fine like it was in flash and not in multiboot. For this reason you can have in multiboot images with OpenGl and images without it or with and without Xbmc

and all the images will work fine.

The only limit of OpenMultiBoot is at the present that the bootmenu is not working with the VU+ images that use OpenGL.

So if you boot from OpenPli you will have bootmenu, if you boot from another image you have to previously select the image to boot from the plugin.

The issue of BootMenu is simply to explain. It doesn't depend by OpenGL itself but by the way that VU+ have implemented the loading of the drivers.

In all the e2 images before this Vu+ implementation, the driver for the framebuffer can be loaded at the very beginning of the boot.

You can load only the driver needed to have the framebuffer available and later, when one image is selected you can start the ordinary init procedure.

This because to show something on the screen (bootmenu) you need the framebuffer.

So this procedure to run the framebuffer was image-indipendent.

With the OpenGl implementation Vu+ have moved the load of the drivers at the end of the rcS.d in the file vuplus-platform-util. This means that the framebuffer is available only after the init procedure of the image is already started and many things image-dependents are already running so you cannot change image at that stage or you will mix things and we will have again issues.

So What's happen in meoboot and OpenMultiBoot when they boot and OpenGl image ?

They try to load the driver for the framebuffer and they try to launch the bootmenu. But the video hardware is not inizialized and the bootmenu is not showed and the procedure continue.

At the present time i don't see a solution about this issue. The only solution i can figure is to try to modify the loading sequence of the Vu+ drivers. But i don't like to ply with these things.

Maybe Skaman that is the author of OpenMultiBoot and it knows it much better than me could find a solution.

But he is really busy now.

Sorry for my english, really bad. I know that my words are not so clear.

Ok here are.

I have builded and included in OpenBlackHole a compat-module boxbranding so OBH can use OEA plugins without any patch.

OpenMultiBoot will be available in image in the next updates and OBH can boot easly OpenPli without any patch to the file volatile-media.

About this is have a little hack for you Dimitrij if you like that OpenMultiBott patches OpenPli image at installation.

file OMBManagerInstall.py

find line

os.system(OMB_RMMOD_BIN + ' nandsim')

add after

if dst_path.find('OpenPLi'):
			inme = open(dst_path + "/etc/init.d/volatile-media.sh",'r')
			out = open(dst_path + "/etc/init.d/volatile-media.tmp",'w')
			for line in inme.readlines():
				if line.find('mount -t tmpfs -o size=64k tmpfs /media') != -1:
					line = "mountpoint -q \"/media\" || mount -t tmpfs -o size=64k tmpfs /media\n"
				out.write(line)
			out.close()
			inme.close()
			os.system("mv -f " + dst_path + "/etc/init.d/volatile-media.tmp " + dst_path + "/etc/init.d/volatile-media.sh"  )
			os.system("chmod 0755 " + dst_path + "/etc/init.d/volatile-media.sh")

Ok i have found and fixed all.

The second issue was about image path.

The variable OMB_GETIMAGEFOLDER = str(box) in this value is not correct for vu+ boxes.

So you have to find line:

if BOX_MODEL == "vuplus":

and add after

OMB_GETIMAGEFOLDER = "vuplus/" + BOX_NAME

After this fix all will work. The images will be extracted and booted.

Thanks Dimitrij for the patched version, you made a great work !!

nandsim modules for zero and ultimo if you want to test with Pli in flash

You don't need nandsim modules to test with OpenBlackHole in flash.

That's all.

It is better to wait for a working version of OpenMultiboot that should be a better solution.

Ok i setup the organization OBH-Skins @ github

@littlesat & @Matrix10 you are invited. Please accept the invite and i will made you admins so you can add other members.

Git created and skin uploaded:

https://github.com/O...kins/MX-HQ7-Pli

Then VU+ should fix the issues instead of relying on us to workaround them.

There are various commits in Vu+ enigma2 git about scansetup and Turbo

 

2015-04-22     hschang    [ScanSetup] Fix error on complete scan with T2 tuners. vuplus_experimental     commit | commitdiff | tree | snapshot
2015-04-16     hschang    [ScanSetup] fix TT3L10 automatic scan problem.     commit | commitdiff | tree | snapshot
2015-02-17     hschang    [ScanSetup] Fix DVB-T2 Scan when tuner does not have...     commit | commitdiff | tree | snapshot
2015-02-16     hschang    [ScanSetup] Support VUPLUS TURBO automatic scan.     commit | commitdiff | tree | snapshot

I have not Cvb-C and cannot test but Ev0 have it and it seems that the changes doesn't fix the issues.

The problem with Vu+ is that they are too much slow in updating and fixing for this reason we don't use their meta-vuplus module in OBH

It is much better to fix and update by yourself than to wait and wait and wait and become old and frustrating....

If you need any kind of test i can ask to Ev0 to help.

Bacicciosat please don't go away. Don't be offended by those that are not in the know. You ask to punish them, but that will not help a bit. We tried to deal with that in the past but it just doesn't work. The best way is to count to ten and ignore the post (and poster if needed). Responding to it will make things worse.

We found that other forum members probably will dealwith the could-be-trolls.

So instead of saying goodbye, lets cooperate on development. That's what we all image builders like to do, don't we?

Dear mirakles,

i ask only to be not offenced every time i post in this board.

About the story i always remember the beginning of Pli team, the posts of hemerje on Sat Industry, the first patch that Pli sent in OE dmm, the frustration because of dmm developers not cooperation.

About cooperation,  all people that have seen here the born of OpenWebIf know that i am for cooperation and demostrated it in all the ways.

Again, about sources, the Black Hole sources are going into Open Black Hole public gits but if there are parts not yet public that you have interest to know i will send to you any source you need.

And finally if you like to play with us and cooperate togheter i can provide to you the write access to Open Black Hole git and will be happy to work togheter.

Meo.

Sure, enigma2 interface is a bit old-fashioned.

Uhmm if we look at graphic library of enigma2 we see that it looks like a quite incomplete. It seems that nobody has never take care about this side.

Maybe this is because the reason to be always back compatible with the old models with their poor processors and resources.

But latest broadcomm generation chipset start to be capable to run opengl 3d graphics.

So the latest box that are running enigma2 seems to be more powerful and ready to make a jump in graphic interface side and pheraps it is time for enigma2 to think to graphic evolution too.

But I´m now talking about Linux Set top box!!! And till now it doesn´t support XBMC. Maybe E2MBC has something new.

You are wrong again.

I have here PrismCube that is a pure Linux Stb running XBMC.

The only negaive side of this nice box is that is not fully opened and for this reason i am worried that this

box will have not success.

At the present there are many good box in the market with very good hardware.

The problem is that companies seems that are going to forget what was the reason

for the success of the linux stb. 1) Linux. 2) Open sources and open platforms.

So i agree with Milo and pieterg. Before to think to propose something on the market, you should take care

of this.

Blackhole has an Enigma2 image too. On top of the closed source (i.e. binary only) image from DMM. Doesn't say anything...

The old e2 image is old code and worst written.

Too much work to clean code and port into public gits.

But Black Hole have switched to open source for the new projects.

So Black Pole is open source

and so Black Hole PrismCube will be open source and all the gits availables.

the PrismCube firm is essentially composed by these repositories:

setup-script.git -> that build the system env and the sources tree

frodo.git -> the Xbmc part

meta-angstrom.git -> that is the linux OE distro used for PrismCube

meta-elmo.git -> that include all the oe bb module additions to the angstrom distro

script.module.beautifulsoap.git -> you know it

script.module.elementtree -> you know too

script.module.elisinterface -> this is an important module because include all the api for the communications between the gui and maruapp

script.mbox.git -> this is the xbmc addon that is the gui used in Xbmc for pvr part and include all the gui additions to Xbmc.

All these repository are open source.

The dvb part is all closed inside the executable maruapp that is a module of meta-elmo.git

I don't think that in this way there is a violation of open source licenses. But i think that the system is too much closed and i hope that it will be be more open in the future.

I'm not familiar with the XMBC project at all, so it might be a pointless question / thought based on my wrong knowledge, but:

didn't Marusys have a lot of work over the last two years by porting the XMBC sources to the ARM architecture? If there were no sources for the ARM plattform already and they had all this work, then it would be "understandable" in some way, if they don't want to make it public, becuase this would allow other commercial companies just to use their work without any contribution. They most likely wouldn't have any problems with making it public for the open source, non commercial parties.

 

That's based on the assumption, that XBMC sources are / were not available for the ARM plattform yet. If they were / are, then my thought is irrelevant of course.

 

As has been said many times: we will see...

Please don't make the same error and confusion like gorsky.

I am sure that The Xbmc part in Prismcube is fully open source  and xbmc license is respected.

Xbmc sources will be public and will be public too the sources of Marusys Xbmc additions.