772 replies to this topic

[WanWizard]

HAL = Hardware Abstraction Layer?

[Abu Baniaz]

HAL = Hardware Abstraction Layer?

 

Yes. See post 609.

[Huevos]

 

Please don’t spend 1000 post regarding a name.

As i don't belong to any team, I can solve your name issue in a single post instead of a 1000 posts 

 

Nomenclature has been decided, ALL TEAMS shall follow this decision and continue with other api spec discussion!

 

The OpenHAL API specs for version 1.0 of this hardware abstraction layer (HAL) shall be as follows:

 

common ground repo for openhal will be here: https://github.com/E...Plugins/OpenHAL

 

kernel module will be called: openhal.ko

 

proc path will be here: /proc/openhal/

 

Merry Xmas 

 

What have you got in mind for data collection?

 

Also, who are the admins of that repo?

Edited by Huevos, 15 December 2020 - 15:54.

[Abu Baniaz]

Also, who has got write access to that repo?

 

 

https://github.com/o...nPlugins/people

[WanWizard]

There is a long list, but not everyone has rights to commit in every repo.

 

As mentioned before, every image maker should appoint a delegate to "the HAL API governance group" (for lack of another name), which should have write access to the repo.

[Huevos]

And who is the "the HAL API governance group"?

 

I'm really confused now because up to this point the API was just a spec and all teams were to make their own implementation.

Edited by Huevos, 15 December 2020 - 16:42.

[LraiZer]

What have you got in mind for data collection?

 

 

 

Also, who are the admins of that repo?

 

I guess it does not matter where your data is collected from during the build, as long as your running image outputs correct data to each /proc while following the rules that have been defined in api spec. Just add and collect relevant data from each machine .conf during build if you want, or don't if you don't want.

 

I'm sure a repo with a trusted admin member from each team will get an invited to a dedicated write access team with relevant privileges in due course, maybe once a proper list of required specs has been decided and signed off by all.

[Persian Prince]

https://github.com/E2OpenPlugins is definitely not the right place.

 

This is not a plugin and we need developers with kernel knowledge as there's no python code in this module.

[WanWizard]

And who is the "the HAL API governance group"?

 

I'm really confused now because up to this point the API was just a spec and all teams were to make their own implementation.

That hasn't been decided yet, as said before every team should appoint someone to govern the spec, and to make sure updates to the spec are implemented in the image.

 

And yes, that is still the case. But you need a place to publish and maintain the spec, and ideally have some skeleton code so everyone can get started with it (i.e. the basis of the C code for the module will be the same for everyone).

[Persian Prince]

I think all hardware features are now covered: https://github.com/O...077b4f400da376d

 

Result:

version:        10.2-r295
description:    Open Vision information module
model=h9
brand=airdigital
platform=zgemmahisi3798mv200
visionversion=10.2
visionrevision=r295
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
compiledate=20201215
fpu=hard
displaytype=             
transcoding=False
multitranscoding=True
hdmi=True
yuv=False
rca=False
avjack=False
scart=False
dvi=False
svideo=False
hdmihdin=False
hdmifhdin=False
wol=True
ci=True
vfdsymbol=False
fhdskin=True
author:         Open Vision developers
license:        GPL
srcversion:     F654FDF64B250DAFDF017D5
depends:        
vermagic:       4.4.35 SMP mod_unload ARMv7 p2v8 

 

[betacentauri]

What means forcemode?
Is small flash/middleflash a good idea? And how is the definition? Why not just add flash size? Then every image builder can decide whether that is small or not.

I miss PiP, multiboot (only that the box is capable or not) and which device is used for the multiboot start up files and maybe which box modes the box support (for e.g hd51, h7,...).

[Persian Prince]

What means forcemode?
Is small flash/middleflash a good idea? And how is the definition? Why not just add flash size? Then every image builder can decide whether that is small or not.

I miss PiP, multiboot (only that the box is capable or not) and which device is used for the multiboot start up files and maybe which box modes the box support (for e.g hd51, h7,...).

 

Some values are for Open Vision only (for example we use forcemode in Backup Suite), ignore them.

 

Flash size could be added although we don't need/use it.

 

What do you need for PiP? Where's the data about it?

 

Is there a MACHINE_FEATURE or something for multiboot?

 

I need those data to analyze ...

[betacentauri]

Afaik not all boxes support PiP. And some can show up to 4 PiP “windows”. You can get the data on the fly like you can see it here: https://github.com/O...stemInfo.py#L17

MACHINE_FEATURE not that I know.

[WanWizard]

What also should be there:

 

box image, FQFN

remote image(s): rctype:FQFN, if the box supports more, a comma separated list

[Huevos]

https://github.com/E2OpenPlugins is definitely not the right place.

 

This is not a plugin and we need developers with kernel knowledge as there's no python code in this module.

Why? It is just the name of a neutral git. All repos on it are stand alone. What is the problem?

[littlesat]

Some lines there have ":".... shouln't we make it '=' at all places?

 

Some boxes have PIP yes/no depended on the boot mode... (mode 12 has it mode 1 not)... ? PIP is now arrange correctly via SystemInfo.py.

Edited by littlesat, 16 December 2020 - 11:59.

[Persian Prince]

Afaik not all boxes support PiP. And some can show up to 4 PiP “windows”. You can get the data on the fly like you can see it here: https://github.com/O...stemInfo.py#L17

MACHINE_FEATURE not that I know.

I think what SystemInfo.py is doing for that is easier so lets keep the module less complicated.

 

You need this variable as flash size: https://github.com/o...timo4k.conf#L12 ?

[Persian Prince]

What also should be there:

 

box image, FQFN

remote image(s): rctype:FQFN, if the box supports more, a comma separated list

You need the path as well or just the picture name?

 

Give me an example of what you need.

[Persian Prince]

Some lines there have ":".... shouln't we make it '=' at all places?

 

Some boxes have PIP yes/no depended on the boot mode... (mode 12 has it mode 1 not)... ? PIP is now arrange correctly via SystemInfo.py.

 

Lines with = are what we need

 

Lines with : are module standards for its information

 

Yes SystemInfo.py is better for that in my opinion too

[Persian Prince]

 

https://github.com/E2OpenPlugins is definitely not the right place.

 

This is not a plugin and we need developers with kernel knowledge as there's no python code in this module.

Why? It is just the name of a neutral git. All repos on it are stand alone. What is the problem?

 

It's not just about the name, even access is not what it should be.

 

There are people there who will have access to the module as the organization's owner/member which should not.