592 replies to this topic

[Abu Baniaz]

Surely the package should be pre-installed? If not, can we install it when the option is toggled?

[neo]

It is now, but you have to wait for the current build to be completed.

 

Problem was that it wasn't added as a DEPENDS in the BSP, fixed here: https://github.com/O...fd35deb40a2e889

[dpeddi]

 

 

I installed in fles openpli Nightly builds, after installing the image I installed vuplus-kexec and in the Shutdown / Restart option I selected and disabled  Vu+ Multiboot, but after the restart the receiver cannot start the image. The receiver is vu solo+ 4k. Have you tried it on solo+ 4k?

I thought I would enable Vu+ Multiboot

 

As per discussion in OpenBH forum, there is a problem with Solo 4K. Looks like no fix yet. 

 

Hereby to confirm that the Multiboot is working fine on Ultimo 4K, just in Menu-Settings-Flash Image i see only the OpenPLi images. Those from other teams are not available, so i had to manually put them in media/hdd/downloaded_images, and then to install them from the menu in to desired slot.

 

it seems that bsp for vusolo4k needs this patch:

https://github.com/o...4.28-1.10.patch

 

This patch have been generated by me 4 years ago by comparing broadcom stblinux kernel on their git with the one used by vuplus. 

 

I wrote to vuplus but they said ok... but never added into their git...

 

from me to vuplus on Wed, Mar 20, 2019, 10:41 PM

"Hi J*******y,

how are you?

i'm going forward with multiboot functionality using kexec. Now i have a patched openmultiboot and now i'm working to incorporate into our image.

 

I haven't got any feedback about the patch ****/fix_mmc.patch i've prepared for solo4k. If you don't plan to upgrade solo4k to the same kernel level of other first gen arm boxes, this patch seems necessary both for "host" and "guest" kernel...

I think it may be a good idea if all the team would include such patch, so probably you should add into your git repository..

 

-----

 

Mar 25, 2019, 7:24 AM

to me, 

 

Dear Dpeddi,

 

Thanks for the patch and relevant information.

 

We will check it and include in the official OE when verification is done.

Edited by dpeddi, 15 April 2023 - 11:54.

[neo]

I'll have a look this weekend.

[Dimitrij]

I'll have a look this weekend.

vusolo4k: backport mmc patch from 3.14.28-1.10

not tested

[cobus]

On the commandline,

opkg install vuplus-kexec

or install it via package management (in software management).
 

Thanks works great with this installed.

[neo]

vusolo4k: backport mmc patch from 3.14.28-1.10

 

not tested

 

How can it be tested? The kernel builds fine with this patch.
 

[dpeddi]

 

vusolo4k: backport mmc patch from 3.14.28-1.10

 

not tested

 

How can it be tested? The kernel builds fine with this patch.
 

 

Someone reported that after installing pli on solo4k and activating multiboot pli doesn't boot any more.

 

So:

Flash the image with the patch on solo4k and activate multiboot

Or, since the slot0 doesn't boot you can restore the non multiboot kernel:

- Recover the previous installation by flashing the new kernel with usb.

- copy the new kernel into /usr/bin/kernel_auto.bin and overwrite the old one

- reactivate kexec multiboot 

[littlesat]

For the multiboot selection I think the recovery slot 0 zero should be shown on top instead of the bottom…

I’m also thinking that the setup for multiboot should be moved from the menu to Flashimage as eg blue button.

Edited by littlesat, 16 April 2023 - 14:59.

[cobus]

For the multiboot selection I think the recovery slot 0 zero should be shown on top instead of the bottom…

I’m also thinking that the setup for multiboot should be moved from the menu to Flashimage as eg blue button.

+1

[Abu Baniaz]

For other boxes, Recovery and Android mode are at bottom. There is obviously a difference of opinion as to the functionality/purpose of that image. OBH team originally said that not to use it. If you think that it should be used, then put it at the top.

[Dimitrij]

Simple

set cursor current image

[dpeddi]

For other boxes, Recovery and Android mode are at bottom. There is obviously a difference of opinion as to the functionality/purpose of that image. OBH team originally said that not to use it. If you think that it should be used, then put it at the top.

The primary image shouldn't be used except for recovery because if you mess it you might loose all the other image. Flashing a non-multiboot kernel won't allow you to recovery the image on the slot.. so you will have to erase the flash.

But do whatever you want

[littlesat]

It is not a real recovery it is more a main ‘host’ image.

[Dimitrij]

 

Flashing a non-multiboot kernel won't allow you to recovery the image on the slot.. so you will have to erase the flash.

Erase the flash used only mkpart.update file exists.

echo "rename this file to 'mkpart.update' for forces create partition and kernel update." > "$MAINDEST/nomkpart.update"

 

[Ev0]

It is not a real recovery it is more a main ‘host’ image.

It is still the only image guaranteed to boot if you mess up any other slot, so why use it as the "daily" image ?

[littlesat]

Sounds we still need a real recovery image which is short and only has an image selecter with flash capability….

[neo]

It is not a real recovery it is more a main ‘host’ image.

 

But if you break that, you break the entire multiboot system, so for end-users I think it is good advice not to use slot 0 and treat it as a recovery image.

[neo]

Sounds we still need a real recovery image which is short and only has an image selecter with flash capability….

 

That was already suggested.

 

Making a minimal image is not a problem, but someone with the correct skills need to make a small footprint recovery GUI (assuming we can't get our hands on the source of the HiSil recovery GUI).
 

[Ev0]

Sounds we still need a real recovery image which is short and only has an image selecter with flash capability….

I still don't really understand why you think this is a "must have" ?

I get that having a full image as a recovery only image (not used daily) is a waste of free space.

However it takes up what 250mb max ? of the 3.5GB available in eMMC.

Previous to multiboot there was somewhere between 2.5 - 3GB of free space being wasted, so in the grand scheme of things it's not a big deal is it ?