592 replies to this topic

[littlesat]

There is no magic here, the Vu4K receiver is setup as per any multiboot receiver with the appropriate STARTUP files.

As far I can see there is a change needed in at least one of the images to get a done as you need a modified kernel for it. And as far I can see there are changes needed in the BSP layer....

So when we introduce it we need a merge request on VU+'s bsp and then we should try if VU+ does accept it -or- someone needs a solution with e.g. a recovery image (a small image with a small menu) so no bps layer change is needed.... Then you have exactly the same as the other hardware is doing... As far I can oversee what is done here is that at least one of the images (the first slot???) is modified (the kernel) and performs as a kind of recovery image.... 

 

I still think this is a good added value as VU+ lames to create this while having sufficient flash for it... but when it is done and you have boot issues somehow there should be a mechanism that a simple image can bootup somehow where you can select slots and/or install images. I think this is a mandatory 'part' what is missing in this implementation.

At this moment I think it is a good initiative... where due to the structure depend on VU+, but somehow one thing that should part of it is still somehow missing.... It does multiboot, but a user friendly recovery mode is missing (work-a-round is flash the complete box with USB indeed).

Edited by littlesat, 10 March 2023 - 15:28.

[el bandido]

Isn't the work-a-round where you flash the complete box with USB the exact same thing you would do if the box needed to be recovered without multiboot?
In other words, wasn't flash with usb for a recovery the only option Before this multiboot was available?

[littlesat]

No…. With the other hardware you can download and flash an image or select a still working image without the need to reflash the box with an usb…. Which is more safe and quicker as you simpel select a still working image and eg reflash just the slot that is not working anymore… this functionality is here completely missing

Edited by littlesat, 10 March 2023 - 18:04.

[Ev0]

 

There is no magic here, the Vu4K receiver is setup as per any multiboot receiver with the appropriate STARTUP files.

As far I can see there is a change needed in at least one of the images to get a done as you need a modified kernel for it. And as far I can see there are changes needed in the BSP layer....

So when we introduce it we need a merge request on VU+'s bsp and then we should try if VU+ does accept it -or- someone needs a solution with e.g. a recovery image (a small image with a small menu) so no bps layer change is needed.... Then you have exactly the same as the other hardware is doing... As far I can oversee what is done here is that at least one of the images (the first slot???) is modified (the kernel) and performs as a kind of recovery image.... 

 

I still think this is a good added value as VU+ lames to create this while having sufficient flash for it... but when it is done and you have boot issues somehow there should be a mechanism that a simple image can bootup somehow where you can select slots and/or install images. I think this is a mandatory 'part' what is missing in this implementation.

At this moment I think it is a good initiative... where due to the structure depend on VU+, but somehow one thing that should part of it is still somehow missing.... It does multiboot, but a user friendly recovery mode is missing (work-a-round is flash the complete box with USB indeed).

 

 

Yes it would be nice to have a recovery menu, but we don't so to work around that, we advise you install the image as normal, but don't set it up fully or install anything into the image if you intend to use multiboot, install the vu+ multiboot, then reinstall the image you want to use into 1 of the available slots.

 

This then means that image slot is the recovery slot (slot 0), The box can always boot that slot if you manage to corrupt an image in another slot.

Slot 0 (recovery) is never used again, unless there is an issue or you select the recovery option.

 

Isn't the work-a-round where you flash the complete box with USB the exact same thing you would do if the box needed to be recovered without multiboot?
In other words, wasn't flash with usb for a recovery the only option Before this multiboot was available?

Yep

[Ev0]

No…. With the other hardware you can download and flash an image or select a still working image without the need to reflash the box with an usb…. Which is more safe and quicker as you simpel select a still working image and eg reflash just the slot that is not working anymore… this functionality is here completely missing

Not with a Vu+ box you can't.

With or without multiboot it does not and never has had that option.

[Ev0]

To correct myself, without multiboot Vu+ has never had that option.

With Multiboot installed, you can always boot recovery and chose to download a new image or flash an already downloaded image to any slot.

[Huevos]

How is a user, not a Dev, going to corrupt an image so bad that it won't boot?

[littlesat]

When you read the forum here there are multiple ways…

Edited by littlesat, 10 March 2023 - 19:58.

[rantanplan]

How is a user, not a Dev, going to corrupt an image so bad that it won't boot?

This has nothing to do with this topic directly, but you should know that the sf4008, for example, brought some unfortunately negative events in this regard.

There are certainly other examples that could be mentioned here.

[Dimitrij]

I think it's time to make a decision.

What are we waiting for?

I am for multiboot.

[Tech]

Personally, it also seems like an interesting addition that makes it very easy to switch between different images....is also known what adjustments we have to make to the recipes to make this work?

Otherwise I can try something in my own build-environment.....

[littlesat]

As it is made now changes to the bsp need to be made…

[Huevos]

As it is made now changes to the bsp need to be made…

No, they don't have to. You can just accept the enigma PR, and you will be able to fully use the facility in OpenPLi when used with an image that does have the BSP changes, which, by the way, are simple, and oe-alliance-core can be used as an example.

[Frenske]

It would be nice to be able to use Multiboot on Vu+ 4K hardware but in that case we depend on the cooperation of Vu+ which seems hardly impossible.

[Huevos]

It would be nice to be able to use Multiboot on Vu+ 4K hardware but in that case we depend on the cooperation of Vu+ which seems hardly impossible.

No, you don't depend on Vu, who are never going to do it. The patch has already been created and other distros are using it.

[Dimitrij]

So, who can update the VU+ BSP correctly?

To use the multiboot to the fullest.

[littlesat]

So there is still a patch needed in e2 so it is not compatible with the current multiboot support with the start scripts I had a lot of work with other manufacturers to get them aligned. Where can I find a clear merge/patch regarding the e2 changes…. As far I understood before no changes in e2 were needed.

[Dimitrij]

So there is still a patch needed in e2 so it is not compatible with the current multiboot support with the start scripts I had a lot of work with other manufacturers to get them aligned. Where can I find a clear merge/patch regarding the e2 changes…. As far I understood before no changes in e2 were needed.

this simple

 

python

if fileHas("/proc/cmdline", "kexec=1")

use VU+ multiboot

 

 

https://github.com/O...a3cd37d4c4a6R18

 

+

 

full support VU+ BSP

https://github.com/o...nds/meta-vuplus

[littlesat]

This is exactly how it should not be done as it is an exception and the boot partitions locations are hardcoded as exception for vu+ in enigma2. Better to put somewhere ‘startup scripts’ to obtain this.

you should at least arrange that the canMultiboot system key knows the situation for the vu+ multiboot… so the exception if vu then (the file has for kexec check) is in the systeminfo.py file. 
so I think now we go in detail and try something a structural improvement is already recommended here.

Edited by littlesat, 25 March 2023 - 13:14.

[Huevos]

This is exactly how it should not be done as it is an exception and the boot partitions locations are hardcoded as exception for vu+ in enigma2. Better to put somewhere ‘startup scripts’ to obtain this.

you should at least arrange that the canMultiboot system key knows the situation for the vu+ multiboot… so the exception if vu then (the file has for kexec check) is in the systeminfo.py file. 
so I think now we go in detail and try something a structural improvement is already recommended here.

Just don't merge it... and people who want it can migrate to images that do have it.