83 replies to this topic

[Persian Prince]

Hi everyone,

We're working on https://github.com/DMM-PLi/dmm-bsp but I need some help with dm7020hdv2.

As far as I know the only extra thing dm7020hdv2 has is how it packed am I right?

dreambox-nand-1024mb-2k.inc https://github.com/D...d-1024mb-2k.inc instead of dreambox-nand-1024mb.inc https://github.com/D...nand-1024mb.inc so could we delete all dm7020hdv2 stuff and do:

1- Compile dm7020hd nfi image then zip it.
2- Remove the nfi as we have the zip.
3- Compile dm7020hd nfi but with dreambox-nand-1024mb-2k.inc this time.
4- Zip the new image with v2 at the end of it then delete the nfi.
5- Now we have both images zipped in same folder and less time.

If it's ok how can I do it via bitbake recipe?

[athoik]

The approach you are mentioning above used originally from DMM to produce two versions of nfi using "shared" feeds.

Create an openpli-enigma2-image-dm7020hdv2.bb with something like the following... Then use bitbake -c openpli-enigma2-image-dm7020hdv2 to build.
 

require ../../../meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb

#require ../../../meta-dream/conf/machine/include/dreambox-nand-1024mb-2k.inc
DREAMBOX_ERASE_BLOCK_SIZE = "0x20000"
DREAMBOX_SECTOR_SIZE = "2048"
MKUBIFS_ARGS = "-m 2048 -e 124KiB -c 3320 -x favor_lzo -F"
UBINIZE_ARGS = "-m 2048 -p 128KiB -s 2048"
UBINIZE_VOLSIZE = "402MiB"
UBINIZE_DATAVOLSIZE = "1MiB"

export IMAGE_BASENAME = "openpli-dm7020hdv2"

Edited by athoik, 11 July 2017 - 19:07.

[Persian Prince]

It seems that we need those configs for dreambox-secondstage.inc https://github.com/D...secondstage.inc too

[Persian Prince]

No worry, Solved: https://github.com/D...f6b688e4c6bd272 

Edited by Persian Prince, 12 July 2017 - 18:05.

[zeros]

Plans for Dreambox DM 900 Ultra HD 4K also?

[Beeker]

You can build for dm900 now.

Just do

MACHINE=dm900 make image

But we don't know if the box does boot.

[Beeker]

And change MACHINE in the site.conf file in openpli-oe-core/. if needed.

[MastaG]

Regarding the dm800, the kernel does build, but binaries built with glibc 2.2x will say: "kernel too old"
Thats why I have a patched glibc 2.19 in my local tree, which will build with recent oe-core versions.

Together with the gcc 6 patches for the 2.6.18 kernel it can get me a working image.

However specifying GLIBCVERSION="2.19" will get us mixed results in the mips32el-nf repository (e.g. other receivers building glibc 2.23)

Edited by MastaG, 13 July 2017 - 09:47.

[Beeker]

Yep

 

https://github.com/b...4ccfe843e537374

 

https://github.com/b...eb8dfdc9c607231

 

So if it's possible to update kernel to patch level 32, there is a chance ???

 

On the other side, dm800 is old..And it takes a lot of time..Is it worth it?

 

Priority one (personally), is solve boot problem DM7080

Edited by Beeker, 13 July 2017 - 10:20.

[Beeker]

As i don't own a dm7080, it's really hard to test.

 

I have OpenPLi 6.0 for Goliath, But I can not do anything about it.

 

Home builders with a dm7080 who wants to experiment and take e.g. open alliance build-env as example are welcome.

 

One person has build image and reported error:

 

Fatal: Boot image is too big
Fatal: Failed to run dreambox-secondstage.postinst

[MastaG]

Thank you for pointing me to the glibc patches Beeker.

 

The problem is, we can't just use older kernel headers for glibc on one machine and newer headers for other machines when they share the same mipsel repository.

 

This means we have a few options:

 

1. We'll patch glibc (which is a shared component for all mips32el-nf receivers) reverting the two commits you mention (and a few other patches from oe-a) for supporting the dm800.

This needs to be done globally in meta-openpli.

e.g.

- setting OLDEST_KERNEL="2.6.18" for mips32el-nf

- reverting those two commits you mention for glibc for mips32el-nf

- using kernel-headers version 2.6.18 for all mips32el-nf

Only then you can have a shared mips32el-nf feed for all receivers without getting conflicts in shared packages.

But the team will never agree on this, since using such old kernel headers will break many packages relying on newer dvbapi stacks.

 

2. Look into getting the 2.6.32 kernel on the dm800.

Here's the dm800 drivers for 2.6.30:

http://sources.dream...0090723.tar.bz2

So there should be a 2.6.30 kernel patch-set as well.

Maybe we can apply the patch-set on top of 2.6.32 and patch the driver VERMAGIC strings.

 

3. Just go with point 1 but decide just apply the glibc patches only for the dm800, also use the 2.6.18 kernel headers and set OLDEST_KERNEL only for the dm800.

And decide we build the dm800 image in a separate build directory.

This way other mips32el-nf receivers will keep on using recent kernel headers.

But the dm800 feed will have it's own mips32el-nf repository.

 

4. Just forget about the dm800.

[WanWizard]

1. It is one of the reasons support for the DM800 was dropped in the first place.

[Beeker]

+1 for option 4.

 

Indeed it's too complicated.

 

Users must create a separate build-environment with modified meta-openpli and openembedded-core.

 

Feel free to send PR's for meta-dream layer anyway.

[MastaG]

Well point 3 is the option where we apply the glibc patches and using the older headers only for the dm800.
But we just use another build directory e.g. 'build800' instead.
This way we wont break other receivers.

Anyways just go with 4.

I'll fork your thing and look into 2.6.32 when I have some time

[Beeker]

I  must push some commits to github regarding dm800. Patches doesn't apply.

Perhaps i can update kernel.To give option 2/3 a chance.

Edited by Beeker, 13 July 2017 - 11:41.

[zeros]

I tried MACHINE=dm900 make image, but NO GO: too  much errors

In fact this box is beautiful, but for trying I do not have it.

[MastaG]

@Beeker for 2.6.18 I already created the patches for gcc 6.x and reworked the asm-code for recent binutils.

I can submit a PR if you want to.

So I have that fully working already.. but I don't like the fact we need to modify glibc and build in a separate environment.

I'd rather spent time looking at the 2.6.30 kernel patches to see whether we can integrate those into 2.6.32 and have something that should still be compatible.

[Beeker]

PR is welcome.

 

Great!

 

For dm8000 i did tricky way to use patch level 90. 

Copy the dreambox-kernel from source dir and make it local, just as the other patches.

I had to remove 2 hunks in that mega patch because. 

1) The code was too much changed. I could not merge it.

2) Patch was already applied in the source.

 

I hope you can make it

 

I'm too busy with Goliath at the moment.

[MastaG]

np, will do this in the following days.

 

I've also been looking at the DMM 2.6.30 patchset.

I could successfully merge it into linux 2.6.32.27 by fixing the rejects manually (not so many).

Funny thing is that for the dvb-stack they already had upstream code from linux-media which was eventually merged into 2.6.32.

 

So I think I can create a booting 2.6.32 kernel for the dm800.. only thing is that DMM never finished porting the dm800 NAND driver.

There's one for the dm8000 though and it isn't very big as well.

So maybe I can backport the dm800 NAND driver from 2.6.18 by comparing the dm8000 NAND driver from 2.6.18 and 2.6.30

[Beeker]

Ok..that would be great for dm800.

 

If you ready send PR