772 replies to this topic

[Huevos]

OpenPLi having no identifier in the image is a major headache for other images, and as the data is the same and the identifier can be created in the same .bb file I don't see why people are so resistant. All being resistant will do is make other teams lose interest.

[Persian Prince]

Ok here's what I did for multiboot flag:

 

https://github.com/O...cfs_info.c#L293 will give "0" by default to "/proc/openvision/multiboot" (recently added) so we know by default there's no multiboot.

 

https://github.com/O...rocfs_main.c#L3 could be used for global proc permission, it was 0444 read-only then I tried 0664 and now 0644

 

Enigma2 is showing multiboot status: https://github.com/O...8a73c5dea1977fb

 

Open WebIF is showing multiboot status: https://github.com/O...800adaf6e8fddf6

 

I just wrote a tiny tool called "multibootflag" which is a cpp binary: https://github.com/O...ultibootflag.bb

 

Also it has a shell script helper.

 

But I tried 0664 and 0644, multibootflag can't change the "/proc/openvision/multiboot" from 0 to 1

 

I have no idea what part is the problem so if anyone is interested in my solution please help.

 

Regards,

Persian Prince

Edited by Persian Prince, 11 December 2020 - 00:49.

[Persian Prince]

I just rebased the git, default value is NULL so not 0 and proc file is empty to be real unknown, still no luck.

[littlesat]

Multiboot flag is not required at all.... the check can be done by scanning for the STARTUP_* files like we already do.... this ‘api’ is finished.
We simplified that code earlier this year and all if box x then do y stuff is banished.
At the end when you have a good design beside vender, model, and type you actually do not need a boxbranding thing that puts static (proc) things in e2... note that the model vender and type is now a kind of hack in e2 as the dmm8000 proc is still there.
All other feature checks are done (or can be done) by already existing procs. So no need to add statically havehdmi, can transcode, etc this is not needed!!! (While some images do add it). All is done in SystemInfo.py. Maybe we need to consider to change this part to define functions or dictionary keys that should be there and find a method how to export it to shell or cpp.
Only for those where it cannot be done we could consider to add something (like procs).

Edited by littlesat, 11 December 2020 - 08:00.

[betacentauri]

A multiboot flag is ok for me. And another proc entry should be there to show the location of the startup files (the same of the device like /dev/mmcblkp1).

The current solution is not nice. It tests some pre defined locations.

Edited by betacentauri, 11 December 2020 - 09:14.

[littlesat]

And another proc entry should be there to show the location of the startup files (the same of the device like /dev/mmcblkp1).

 

Good point...

 

It would just be helpfully when there is a proc pointing to this device... but when the proc does not exist the box does not support Multiboot...

 

Then also indeed it adds value as it can also remove the scan for devices (which manufacturers have differently, what I also hate)

 

I would not go for two different procs... one say the feature is available and one contains the device with the Startup Files

 

Contra here is that when the device accidently does not exist or does not contain STARTUP files.... then the box still does not support it. But at least OpenPLi's E2 does cover that and in addition this is unexpected behavior.

 

So a check of proc exists can be a check multiboot is supported and the content points to the device of the STARTUP files would be nice for this detail.

Edited by littlesat, 11 December 2020 - 11:08.

[littlesat]

P.s. when we can get the image info in an easy way and have this proc then all work-a-rounds are out of the multiboot code and everything is straight forward here.

[Persian Prince]

A multiboot flag is ok for me. And another proc entry should be there to show the location of the startup files (the same of the device like /dev/mmcblkp1).

The current solution is not nice. It tests some pre defined locations.

I can add a proc like "startup" but where can I get information for all brands/models regarding that matter?

[Huevos]

Still can't get this to work. It just produces empty IPK files. No indication in the build logs why.

 

Some help would be appreciated.

[Persian Prince]

Still can't get this to work. It just produces empty IPK files. No indication in the build logs why.

 

Some help would be appreciated.

 

I sent you a mail, did you get it?

[betacentauri]

A multiboot flag is ok for me. And another proc entry should be there to show the location of the startup files (the same of the device like /dev/mmcblkp1).

The current solution is not nice. It tests some pre defined locations.

I can add a proc like "startup" but where can I get information for all brands/models regarding that matter?

I don’t think that such a list currently exist.
For most non hisilicon boxes it should be /dev/mmcblk0p1. Edision boxes are afaik an exception. They use mmcblk1p1 (not really sure with that).
Hisilicon boxes are more difficult. I think you need to check each box.

[Huevos]

 

Still can't get this to work. It just produces empty IPK files. No indication in the build logs why.

 

Some help would be appreciated.

 

I sent you a mail, did you get it?

 

Ok I have working IPKs now... but...

 

The ".ko" file is present on the file system of the stb, but no procs. No folder "/proc/openvision". Why?

 

 ov1.jpg   131.82KB   2 downloads

 

 ov2.jpg   134.54KB   2 downloads

[Persian Prince]

 

 

Still can't get this to work. It just produces empty IPK files. No indication in the build logs why.

 

Some help would be appreciated.

 

I sent you a mail, did you get it?

 

Ok I have working IPKs now... but...

 

The ".ko" file is present on the file system of the stb, but no procs. No folder "/proc/openvision". Why?

 

ov1.jpg

 

ov2.jpg

 

 

Did you "modprobe" it?

 

What's the output of "lsmod"?

 

Keep in mind that https://github.com/O...-image.conf#L62 is doing global modprobe for us and you don't have it in OE-A

 

We manage so many parts of Open Vision with global definitions not "per-recipe" things.

 

I'm not going to say OV's OE is better than OE-A but we use current master branch of OE (GCC 10.2 on both host and bitbake) with more clean recipes.

Edited by Persian Prince, 12 December 2020 - 02:37.

[Persian Prince]

 

 

A multiboot flag is ok for me. And another proc entry should be there to show the location of the startup files (the same of the device like /dev/mmcblkp1).

The current solution is not nice. It tests some pre defined locations.

I can add a proc like "startup" but where can I get information for all brands/models regarding that matter?

I don’t think that such a list currently exist.
For most non hisilicon boxes it should be /dev/mmcblk0p1. Edision boxes are afaik an exception. They use mmcblk1p1 (not really sure with that).
Hisilicon boxes are more difficult. I think you need to check each box.

 

 

If it's always the same as "MTD_BOOTFS" like https://github.com/O...sion-4k.inc#L36

 

Then we have it and it's in our module: /proc/openvision/mtdbootfs

 

But we need to define it for all as now for examlple it's empty for sf8008

[Huevos]

"Keep in mind that https://github.com/O...-image.conf#L62 is doing global modprobe for us and you don't have it in OE-A"

 

Why is it done like that in the distro.conf file? Why not in openvision-module.bb? To me it makes sense that everything needed to make a recipe work is contained in the recipe.

Edited by Huevos, 12 December 2020 - 03:43.

[Persian Prince]

"Keep in mind that https://github.com/O...-image.conf#L62 is doing global modprobe for us and you don't have it in OE-A"

 

Why is it done like that in the distro.conf file? Why not in openvision-module.bb? To me it makes sense that everything needed to make a recipe work is contained in the recipe.

Well managing almost everything from https://github.com/O...ion/conf/distro is like having a control panel instead of going inside folders one by one

 

Also that's not distro.conf that's openvision-image.conf which keeps related things about our image

 

We have more conf files and more definitions

[Huevos]

Also what is the reason for making the proc files writable?

[Persian Prince]

Also what is the reason for making the proc files writable?

It was read-only first then I changed it for https://forums.openp...dpost&p=1284210 but still with no luck, binary can't write to the proc file ...

[Persian Prince]

Ok we needed another file like a local file for reading image information so the parent image understands what kind of image is going to be multibooted right?

 

Here's what I did: https://github.com/O...a01dd969d69090e

 

Now if you do "modinfo /path-to-the-file/openvision.ko" it gives you (example):

version:        10.2-r291
description:    Open Vision information module
model=h9
brand=airdigital
platform=zgemmahisi3798mv200
visionversion=10.2
visionrevision=r291
visionlanguage=extralanguage
developername=persianpros
feedsurl=http://openvision/feeds/openvision-develop
distro=openvision
oe=master
kernel=4.4.35
python=2.7.18
mediaservice=enigma2-plugin-systemplugins-servicehisilicon
multilib=False
architecture=cortexa15hf-neon-vfpv4
socfamily=hisi3798mv200
blindscanbinary=blindscan
rctype=28
rcname=zgemma6
rcidnum=1
smallflash=False
middleflash=False
imagedir=h9
imagefs= ubi
mtdbootfs=
mtdrootfs=mtd7
mtdkernel=mtd6
rootfile=rootfs.ubi
kernelfile=uImage
mkubifs=-m 2048 -e 126976 -c 8192
ubinize=-m 2048 -p 128KiB
forcemode=no
author:         Open Vision developers
license:        GPL
srcversion:     7330E1995E79F859959E5C6
depends:        
vermagic:       4.4.35 SMP mod_unload ARMv7 p2v8

Even without loading the module

 

Can we call this the final solution now?

 

Now we can even not rely on modprobe module, we can just read what we need with modinfo module

 

Information is static and can't be changed, I need to get rid of "multiboot" proc file and make proc files read-only again as with this we can determine what image is running.

Edited by Persian Prince, 12 December 2020 - 05:09.

[Huevos]

Is that data available irrespective of the currently running kernel?