1177 replies to this topic

[Beeker]

I never had that error, Well not yet. The build runs flawless for me.

 

So for me it's hard to test.

 

But applying this patch is harmless so far.

diff --git a/meta-dream/recipes-bsp/drivers/dreambox-secondstage.inc b/meta-dream/recipes-bsp/drivers/dreambox-secondstage.inc
index f32d5fa..97f4678 100644
--- a/meta-dream/recipes-bsp/drivers/dreambox-secondstage.inc
+++ b/meta-dream/recipes-bsp/drivers/dreambox-secondstage.inc
@@ -13,6 +13,8 @@ SRC_URI = "http://sources.dreamboxupdate.com/download/7020/secondstage-${MACHINE
 
 PACKAGES = "${PN}"
 
+do_populate_sysroot[depends] = "dreambox-secondstage-${MACHINE}:do_package"
+
 S = "${WORKDIR}"
 
 do_install() {

Edited by Beeker, 2 December 2016 - 13:24.

[Beeker]

Can someone confirm if this fix the problem..Because i don't have that issue.

[Erik Slagter]

Indeed it won't hurt, I'll apply it and we'll see.

[Erik Slagter]

 DEBUG: Executing python function set_image_size
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_ubinfi
| ubinize: volume size was not specified in section "root", assume minimum to fit image "/data_ssd/openpli/oe/garden-5/build/tmp/deploy/images/dm8000/openpli-enigma2-5-dm8000.rootfs.ubifs"77672448 bytes (74.1 MiB)
| .../build/tmp/deploy/images/dm8000/secondstage-dm8000.bin: No such file or directory
| Invalid boot partition!
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_image_ubinfi (log file is located at .../build/tmp/work/dm8000-oe-linux/openpli-enigma2-image/1.0-r0/temp/log.do_image_ubinfi.2602)

Same error...

[Erik Slagter]

Did you add this to your local.conf

IMGDEPLOYDIR_forcevariable = "${DEPLOY_DIR_IMAGE}"

Which is needed to build for other machines?

[Beeker]

Did you add this to your local.conf

IMGDEPLOYDIR_forcevariable = "${DEPLOY_DIR_IMAGE}"

Which is needed to build for other machines?

 

A few weeks ago, but without 'forcevariable'. That was no problem as far as i remember.

 

No i have to add

IMGDEPLOYDIR_forcevariable = "" 

to meta-openpli/classes/image_types_nfi.bbclass (yes that file again) To prevent bitbake ereasing the entire deploy/images/dm8000 directory. That's causing :

.../build/tmp/deploy/images/dm8000/secondstage-dm8000.bin: No such file or directory

Now dm8000 and vuduo2 building both ok with all files present.

 

But need more time for testing.

[Beeker]

Not working...

[MMajoor]

FYI:

Building master-next for the 'hd2400' (and most likely all 'meta-hd' boxes) fails at the 'do_image_ubi' point that is already mentioned earlier in this post.

There is also a fix mentioned (http://forums.openpl...ndpost&p=612715) which changes IMGDEPLOYDIR.

I can confirm that with this fix the 'hd2400' build no longer fails.

[Beeker]

If all boxes build ok with just

IMGDEPLOYDIR = "${DEPLOY_DIR_IMAGE}"

That would be nice. Because

IMGDEPLOYDIR_forcevariable = "${DEPLOY_DIR_IMAGE}"

Ereasing everthing in deploy-dir.. vmlinux,secondstage-dm8000.bin, openpli-enigma2-5-dm8000.rootfs.ubi, The whole nine yards.

 

I gave it an one way ticket to a galaxy far far away...

 

Both options are not in openpli master-next-branch yet.

 

Replacing   "DEPLOY_DIR_IMAGE" by  "IMGDEPLOYDIR" in meta-openpli/classes/image_types_nfi.bbclass is not really needed, but a good option.

 

But then still still failed for secondstage-dm8000.bin for some other reason.

/build/tmp/deploy/images/dm8000/secondstage-dm8000.bin: No such file or directory

Line 56 in image_types_nfi.bbclass must be then still:

		--boot-partition ${DREAMBOX_PART0_SIZE}:${DEPLOY_DIR_IMAGE}/secondstage-${MACHINE}.bin \

Or:

		--boot-partition ${DREAMBOX_PART0_SIZE}:${DEPLOY_DIR}/images/${MACHINE}/secondstage-${MACHINE}.bin \

Edited by Beeker, 4 December 2016 - 14:59.

[blzr]

 

If all boxes build ok with just

IMGDEPLOYDIR = "${DEPLOY_DIR_IMAGE}"

That would be nice. Because

IMGDEPLOYDIR_forcevariable = "${DEPLOY_DIR_IMAGE}"

Ereasing everthing in deploy-dir.. vmlinux,secondstage-dm8000.bin, openpli-enigma2-5-dm8000.rootfs.ubi, The whole nine yards.

 

I gave it an one way ticket to a galaxy far far away...

 

it'd make no difference at all if variable is forced or not AFAIK

image.bbclass:

...
do_rootfs[cleandirs] += "${S} ${IMGDEPLOYDIR}"

it looks that assigning IMGDEPLOYDIR and DEPLOY_DIR_IMAGE to the same directory, as a 'fix' after latest OE changes is simply not a good idea...

Edited by blzr, 4 December 2016 - 18:11.

[MiLo]

Experimented with the et9x00 image, and this is basically what I came up with. You need both IMGDEPLOYDIR and DEPLOY_DIR_IMAGE during image creation,
so bluntly setting one or the other won't work.

This patch for "meta-xtrend" however should fix the build and work well for both the newer and older OE versions. Only build-tested it, but seems to generate something that makes sense (e.g. no "0" sized kernel)

Attached Files

•  0001-For-OE-morty-use-IMGDEPLOYDIR-for-deployment.patch   3.61KB   39 downloads

Edited by MiLo, 5 December 2016 - 09:43.

[Erik Slagter]

And there really isn't a generic workaround, like we did earlier, that don't need adjustments to the BSP modules?

[MiLo]

I'd love to have one too, but from the looks of it, it's not possible to do so.

[Erik Slagter]

So we can go and do a round of BSP PR's again? Volunteers?

 

Is the patch the same for all/most BSP's, actually?

Edited by Erik Slagter, 5 December 2016 - 10:57.

[Persian Prince]

So we can go and do a round of BSP PR's again? Volunteers?

 

Is the patch the same for all/most BSP's, actually?

Just wait, I'm doing it for all BSPs

[mirakels]

Experimented with the et9x00 image, and this is basically what I came up with. You need both IMGDEPLOYDIR and DEPLOY_DIR_IMAGE during image creation,
so bluntly setting one or the other won't work.

This patch for "meta-xtrend" however should fix the build and work well for both the newer and older OE versions. Only build-tested it, but seems to generate something that makes sense (e.g. no "0" sized kernel)

 

This is a similar patch I used and posted for vuduo2 and friends.

So Indeed as Erik mentioned, this probably is the best way to go.

[Erik Slagter]

Okay, I guess we'll see the PR's coming then

 

Please inform use whenever a BSP is done, we'll review it and add a note from one of us to make sure the PR is recognised as legitimate.

Edited by Erik Slagter, 5 December 2016 - 13:27.

[Persian Prince]

https://github.com/X...-xtrend/pull/15

https://github.com/o...a-xpeedc/pull/5

https://github.com/p...-xsarius/pull/5

https://github.com/v...-vuplus/pull/23

https://github.com/X.../meta-xp/pull/5

https://github.com/o...a-spycat/pull/1

https://github.com/m...raclebox/pull/4 (Merged, Test it please)

https://github.com/H.../meta-hd/pull/6

https://github.com/g.../meta-gi/pull/1

https://github.com/f...ormuler/pull/12

https://github.com/z...a-zgemma/pull/4

https://github.com/o...edision/pull/16

https://github.com/w...ta-wetek/pull/1

 

As I can't test all of them please test what you can

Edited by Persian Prince, 5 December 2016 - 13:49.

[blzr]

I'm pretty sure that this will break all OpenPLi4 builds...

[mirakels]

those patches might not give the expected results as for example the

zip ${IMAGE_NAME}_sdcard.zip ${IMAGEDIR}/*;  
will create the image file he ${IMAGEDEPLOYDIR} so won't end up in the tmp/deploy/image/$MACHINE location.

Earlier I proposed this simple fix for vuduo2:

IMAGE_CMD_ubi_append = " \
+ [ -f ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubi ]  || cp ${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.ubi ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.ubi; \

which seems to work too for some other machines and similar patches could be build for again other machines. Note this solution more or less is openpl-4 save...