aboutsummaryrefslogtreecommitdiffstats
path: root/README.md
blob: 792132b66b8ed12f9d281c28112c9b107d13470f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
meta-ivi, the Yocto layer for In-Vehicle Infotainment
=====================================================

This layer's purpose is to add In-Vehicle Infotainment (IVI) support when
used with Poky.  The goal is to make the Yocto Project reference system
Poky GENIVI compliant.

Please see the
[MAINTAINERS](http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/MAINTAINERS)
file for information on contacting the maintainers
of this layer, as well as instructions for submitting patches.

The meta-ivi project welcomes contributions. You can contribute code,
submit patches, report bugs, answer questions on our mailing lists and
review and edit our documentation and much more.

Subscribe to the mailing list
    [here](https://lists.genivi.org/mailman/listinfo/genivi-meta-ivi).  
View or Report bugs
    [here](https://at.projects.genivi.org/jira/secure/RapidBoard.jspa?rapidView=10&projectKey=BASE).
Read or Edit the wiki
    [here](https://at.projects.genivi.org/wiki/display/PROJ/meta-ivi).
For information about the Yocto Project, see the
    [Yocto Project website](https://www.yoctoproject.org).  
For information about the Yocto GENIVI Baseline, see the
    [Yocto GENIVI Baseline website](http://projects.genivi.org/GENIVI_Baselines/meta-ivi).

Layer Dependencies
------------------

URI: git://git.yoctoproject.org/poky
> branch:   krogoth
> revision: 856f0648d6ff17088986977fd2414408474090b5

URI: git://git.openembedded.org/meta-openembedded
> layer:    meta-oe
> branch:   krogoth
> revision: e027caff5b2476e150eacbb49e57321b6f78a096

Using the above git sha's and the master meta-ivi branch, bitbaking miranda-image
is known to work (the miranda-image build should be aligned with GENIVI 11.0).

For creating a specific GENIVI compliant image version, please make sure you
git checkout the related meta-ivi branch and follow the build instructions
located in the README.md file of that branch.  So for example, to build
an image that should be GENIVI 6.0 compliant, checkout the meta-ivi 6.0 branch,
and follow the README.md part of that branch.  As does the GENIVI Alliance
we only support the current and the previous version.  Any version older
than that is not supported any more, and therefore may not build or run.

Supported Machines
------------------

We do smoke test the builds of the three machines that we currently support:

* QEMU (ARMv7) - emulated machine: vexpressa9
* QEMU (IA-32) - emulated machine: qemux86
* QEMU (x86-64) - emulated machine: qemux86-64

Please check on our [wiki](http://wiki.projects.genivi.org/index.php/meta-ivi)
regarding any community supported machines.
For example there Renesas provides a public Board Support Package (BSP)
available for use with meta-ivi.

Build a QEMU image that contains GENIVI components
--------------------------------------------------

You can build a QEMU image that should be GENIVI compliant using the
following steps:

1. Export TEMPLATECONF to pick up correct configuration for the build
export TEMPLATECONF=/full/path/to/meta-ivi/meta-ivi/conf

2. Run the following command:
   > $ source poky/oe-init-build-env

3. Build s/w image including GENIVI 11.0 compliance components
   > $ bitbake miranda-image

4. Run the emulator:
   > for qemu vexpressa9:  
   > $ PATH_TO_META_IVI/meta-ivi/scripts/runqemu miranda-image vexpressa9
   >
   > for qemu x86:  
   > $ PATH_TO_META_IVI/meta-ivi/scripts/runqemu miranda-image qemux86
   >
   > for qemu x86-64:  
   > $ PATH_TO_META_IVI/meta-ivi/scripts/runqemu miranda-image qemux86-64

5. To login use these credentials:
   > User - root
   > Password - root


talk about using SRCREV instead of branch or tag at SRC_URI
-----------------------------------------------------------
Sent: Tuesday, April 05, 2016 11:33 PM
To: James Thomas
Cc: genivi-meta-ivi@lists.genivi.org
Subject: Re: [meta-ivi] Building with local source mirror

On Tue, Mar 29, 2016 at 10:51 PM, James Thomas <james.thomas@codethink.co.uk> wrote:
> One thing I noticed is that simply providing the SRCREV works as long 
> as that sha exists within master, if it doesn't then you have a build 
> error, so being able to use tags is useful.
>
> I think using git://...;tag=foo is not sufficient, because tags *can* 
> change (i.e there's no guarantee that the tag you're using is going to 
> be the same as the one you used yesterday).
>
> What would be nice is if you could go tag=foo, and have it verified 
> against SRCREV (in my testing this resulted in a build error *when* 
> the tag and sha matched)
>
> However, something like
>
> SRC_URI = "git://mygitrepo/foo.git;nobranch=1;branch=v0.2"
> SRCREV  = "7654321"
>
> does enforce that check (v0.2 is actually a tag in this case), which 
> seems to be pretty useful (the recipe provides something human 
> readable, and something a machine can understand, and will always 
> check they match)

I completely understand the reasoning behind this. The point I'm trying to make is that the automotive industry has a strong need for reproducible offline builds and any kind of mandatory online checks break this requirement. And like Federico said, using SRCREV is also the Yocto project practice.

If we want meta-ivi to be widely used in the industry I believe it should support it's needs. In my opinion the same should go for the whole GENIVI stack to work nicely, which in particular means tags of the projects should not change. But the easiest solution would be for meta-ivi to not use tags. That way it supports offline builds and it is also possible to track bugfixes in the projects instead of pinning to the tag and then getting the bugfixes in patch by patch until next release.

How do the others on this list feel about this proposal?

Regards,
--
Igor Socec
Software Engineer