On Mon, Jun 16, 2014 at 11:29 AM, Dominig ar Foll <[email protected]> wrote > > Le 16/06/2014 09:28, Jeremiah Foster a écrit : > > > > That list doesn't seem to get much traffic -- June is half over and > > there have been no posts. Shouldn't mail be sent here to ensure the > > largest number of people see it and move to the other list once there > > is too much traffic on this list? > > Sorry the correct list to be used is : > [email protected] > https://lists.tizen.org/listinfo/dev
Okay, thanks! > > > > > > The source used to build the ARM repo in Common are all public. > > > > There doesn't seem to be an agreed upon approach, or if there is, its > > unclear. Let's take the Renesas request for > > example: https://lists.tizen.org/pipermail/ivi/2014-June/002636.html > > They'd like some help in porting Tizen Common to their hardware, but > > how would one even approach this? It is unclear from Tizen's side in > > contrast to other distros which provide ARM kernels in multiple > > flavors (i.e. hardfloat, softfloat) for multiple machines, (i.e. ARM > > v7 ARM v8, etc.) > So far we have no refrence ARM platform for IVI. The proposal is to add > Renesas as our initial ARM platform and that is what we are working to > acheive with them. > We will add more build option if needed when other reference platform > commit to work for IVI. > I think it needs to be the other way around. Tizen IVI has to be shown to work on production-quality ARM silicon before silicon vendors will commit resources. Currently there is nothing in Tizen IVI that can't be found elsewhere with significantly better support for ARM. Debian, for example, has a working ARM v8 software stack, Linaro creates LTSI kernels, etc. > > > If Tizen had a small team that tested Tizen Common against an ARM > > kernel, then they could at least guide on suitable approaches. > > Currently, one would have to; > > > > 1. Identify a kernel that fits Tizen common and your hardware > > 2. Compile that kernel, with toolchain, to test on the hardware > > 3. Build Tizen common from source in a build system suitable and > > widely used for ARM hardware. > That is exaclty what we have agreed to do using the Odroid reference > platform. We are wainting for HW to be delivered to enable the Auto test > on Common for ARM. While I'm sure the Odroid platform is awesome, does it have automotive connectivity and peripherals? Of course, we want something easy to buy and inexpensive so that a whole lot of people can buy one, but even there Odroid seems a bit of strange choice, wouldn't the Beagle Bone Black be better? > > > > Just identifying a kernel is a non-trivial step -- are you going to go > > with a LTSI kernel (hardware in automotive needs long-term support)? > > Are you going to use Linaro's LTS kernel? It may have features you > > need. Are those kernels going to bring in the needed features for > > Tizen common? Has someone identified the needed functionality in the > > kernel that the Tizen common userland will need so that one doesn't > > spend a lot of time wondering why certain features don't work? > That is an other topic which deserve a thread by itself. :-) > As Tizen we do > not enforce a specific version of the Kernel but rather the provision > for specific feature (e.g. Smack and SystemD boot). This begs the question: who's in charge of architecting Tizen Common? And how strong is the preference for SMACK? What about projects like TOMOYO: http://en.wikipedia.org/wiki/TOMOYO_Linux How would one go about removing SMACK in favor of TOMOYO and would it still be "Tizen"? > People maintaining > the Kernel of each reference platform have the duty to provide a Kernel > with the needed features. Getting it based on LTSi is certainly an > interresting approach but not a requirement. > > > > There seems to be a lot missing before a suitable public port to ARM > > can be done repeatedly in a manner consistent with production systems. > > Is there a goal to add this type of support? Or is the ARM port of > > Tizen something that the community will fund and build in their spare > > time? > Today we are strongly limited by the lack of publicly available > reference platforms. On Common Odroid should fix the issue by end of > June. For IVI, it will be up to the reference platform providers to fix > the issue of availability. > I suspect the lack of available hardware to be a bottleneck, especially when a key deliverable for success is an ADK or SDK. Isn't it much faster if we use something like the BBB? Cheers, Jeremiah
_______________________________________________ IVI mailing list [email protected] https://lists.tizen.org/listinfo/ivi
