From wminer at linuxfoundation.org Wed Aug 2 12:53:44 2017 From: wminer at linuxfoundation.org (wminer at linuxfoundation.org) Date: Wed, 02 Aug 2017 12:53:44 +0000 Subject: [agl-discussions] Updated Invitation: App FW & Security Biweekly Call @ Every 2 weeks from 8am to 9am on Wednesday except Wed Aug 16 8am (CDT) (automotive-discussions@lists.linuxfoundation.org) Message-ID: This event has been changed. Title: App FW & Security Biweekly Call 1. Please join my meeting. https://global.gotomeeting.com/join/324926029 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. Australia: +61 2 8355 1020 Austria: +43 1 2530 22520 Belgium: +32 (0) 28 08 4368 Canada: +1 (647) 497-9353 Canada (toll-free): 1 888 455 1389 Denmark: +45 69 91 89 28 Finland: +358 (0) 942 59 7850 France: +33 (0) 170 950 594 Germany: +49 (0) 692 5736 7317 India (toll-free): 000 800 100 7855 Ireland: +353 (0) 15 360 728 Italy: +39 0 247 92 13 01 Japan (toll-free): 0 120 663 800 Korea, Republic of (toll-free): 0806150880 Netherlands: +31 (0) 208 080 219 New Zealand: +64 9 280 6302 Norway: +47 75 80 32 07 Spain: +34 911 82 9906 Sweden: +46 (0) 852 500 186 Switzerland: +41 (0) 435 0167 13 United Kingdom: +44 (0) 330 221 0088 United States: +1 (646) 749-3129 United States (toll-free): 1 877 568 4106 Access Code: 324-926-029 Audio PIN: Shown after joining the meeting Meeting ID: 324-926-029 When: Every 2 weeks from 8am to 9am on Wednesday except Wed Aug 16 8am Central Time (changed) Where: https://www.gotomeeting.com/join/324926029 Calendar: automotive-discussions at lists.linuxfoundation.org Who: * Walt Miner - creator * dcauchy at linuxfoundation.org * Noriaki Fukuyasu * automotive-discussions at lists.linuxfoundation.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MzMycnZrY2d1ODVydm9yN3UyMHVla2FvOGMgYXV0b21vdGl2ZS1kaXNjdXNzaW9uc0BsaXN0cy5saW51eGZvdW5kYXRpb24ub3Jn&tok=NzIjbGludXhmb3VuZGF0aW9uLm9yZ19pMHJzOGFta20wZmxkZTdrcTV1NGI5dGVmNEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tM2RiOWI2NGY4MDg2ZGMxMmE0MWRjMzg2MGM0YmNlOTY0ZGMwZDA1Mw&ctz=America/Chicago&hl=en Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account automotive-discussions at lists.linuxfoundation.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 3727 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 3814 bytes Desc: not available URL: From tmatsuzawa at xevo.com Thu Aug 3 02:28:05 2017 From: tmatsuzawa at xevo.com (Takashi Matsuzawa) Date: Thu, 3 Aug 2017 02:28:05 +0000 Subject: [agl-discussions] SPEC-791 Message-ID: Hello, Tanikawa-san and others. I think you are responsible for demo homescreen and windowmanager code and I am glad if you can look into below, and possibly pick the patch. I am being told that current demo homescreen/windowmanager is short-term solution, but I hate to see it is showing uglily on people's displays today. https://jira.automotivelinux.org/browse/SPEC-791 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fixed-term.Vamsinag.Gunti at de.bosch.com Thu Aug 3 13:27:37 2017 From: fixed-term.Vamsinag.Gunti at de.bosch.com (FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1)) Date: Thu, 3 Aug 2017 13:27:37 +0000 Subject: [agl-discussions] SDK newbie questions Message-ID: Hi, Is there any documentation available on the structure of a Qt QML application? The applications that are available in the demos seems to have a different structure as compared to the structure created by my Qt Creator. Additionally what type of a project is to be selected when creating an application on QtCreator? I chose a Qt Quick Controls Application and the structure was completely different from the demo apps and was not able to proceed any further. And could someone kindly direct me to any documentation on writing an application from scratch in qml/html5? I did refer the AppFramwork documentation. While it does give ample information on building an app and information about the configuration file, I don't seem to find any information on the app file/folder structure etc. Thanks in advance :) Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajmalmalib4u at gmail.com Thu Aug 3 15:03:19 2017 From: ajmalmalib4u at gmail.com (ajmalmalib4u) Date: Thu, 03 Aug 2017 20:33:19 +0530 Subject: [agl-discussions] [agl-discussion] R-Car M3 AGL QT QML Application failure References: Message-ID: An HTML attachment was scrubbed... URL: From wminer at linuxfoundation.org Thu Aug 3 15:30:07 2017 From: wminer at linuxfoundation.org (wminer at linuxfoundation.org) Date: Thu, 03 Aug 2017 15:30:07 +0000 Subject: [agl-discussions] Canceled Event: AGL Dev Meeting - Weekly @ Tue Aug 15, 2017 8am - 9am (CDT) (automotive-discussions@lists.linuxfoundation.org) Message-ID: This event has been canceled and removed from your calendar. Title: AGL Dev Meeting - Weekly When: Tue Aug 15, 2017 8am ? 9am Central Time Where: See https://wiki.automotivelinux.org/dev-call-info Calendar: automotive-discussions at lists.linuxfoundation.org Who: * Walt Miner - creator * dcauchy at linuxfoundation.org * Noriaki Fukuyasu * automotive-discussions at lists.linuxfoundation.org Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account automotive-discussions at lists.linuxfoundation.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1971 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2029 bytes Desc: not available URL: From dennisf at RADIOSOUND.com Thu Aug 3 16:23:31 2017 From: dennisf at RADIOSOUND.com (Dennis Field) Date: Thu, 3 Aug 2017 16:23:31 +0000 Subject: [agl-discussions] SDK newbie questions In-Reply-To: References: Message-ID: <6503577A-A71B-4A2B-A182-C7149A53EF1F@RADIOSOUND.com> Vamsi, Check out the AGL QML hello world app I made when I had just gotten XDS up and running. https://github.com/radiosound-com/agl-hello-qml/ The Qt project was based on the hello world QML template that Qt Creator generates when you make a new Qt Quick Controls 2 application. I made a subfolder project so that the app project could live separately from the package project that AGL uses to build the wgt file (this was just so I could build on desktop and verify the AGL styled controls worked before putting it on the board) The instructions in the readme are how to set up Qt Creator in Windows to integrate with XDS (not as elegantly as I'd like, but it worked well enough for my purposes). I haven't tried it on a Linux host yet, some of the instructions may need to be adjusted. If I get a chance this week, I'll do that. If all you need to look at is the project structure, though, this is one way to set it up. Hope that helps! Sent from Bill Gates' iPhone On Aug 3, 2017, at 9:28 AM, FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > wrote: Hi, Is there any documentation available on the structure of a Qt QML application? The applications that are available in the demos seems to have a different structure as compared to the structure created by my Qt Creator. Additionally what type of a project is to be selected when creating an application on QtCreator? I chose a Qt Quick Controls Application and the structure was completely different from the demo apps and was not able to proceed any further. And could someone kindly direct me to any documentation on writing an application from scratch in qml/html5? I did refer the AppFramwork documentation. While it does give ample information on building an app and information about the configuration file, I don?t seem to find any information on the app file/folder structure etc. Thanks in advance :) Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 _______________________________________________ automotive-discussions mailing list automotive-discussions at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmatsuzawa at xevo.com Fri Aug 4 00:46:45 2017 From: tmatsuzawa at xevo.com (Takashi Matsuzawa) Date: Fri, 4 Aug 2017 00:46:45 +0000 Subject: [agl-discussions] SDL layers Message-ID: Hello. For better tracking, I created following ticket so can yo kindly update your review to include "Bug-AGL: SPEC-805" keyword. https://jira.automotivelinux.org/browse/SPEC-805 I may ask general question about this meta layer, from personal interest. Is there any plan to upstream this (or is there upstream for it?) https://github.com/smartdevicelink/ (the sdl community) may not necessarily be responsible to provide meta layer by itself, but is there any plan to do so? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmatsuzawa at xevo.com Fri Aug 4 01:52:28 2017 From: tmatsuzawa at xevo.com (Takashi Matsuzawa) Date: Fri, 4 Aug 2017 01:52:28 +0000 Subject: [agl-discussions] inputs on qwebview? Message-ID: Hello. This maybe a Qt question, but I am playing with QWebView on my AGL target board. I load a web page (say, yahoo or google map) within QWebView (or QWebEngineView). Then I should be able to do the following wihth modification? Or some additional integration is needed? - Text inputs on web page. - Gestures like pinch zooming. This is latest master branch, with touch screen also USB connected keyboard/mouse. I can see A tags react to my touch operation (so that I can navigate through the links between the web pages), and can also select texts (they are reversed), but I do not seems to do further. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmatsuzawa at xevo.com Fri Aug 4 04:20:38 2017 From: tmatsuzawa at xevo.com (Takashi Matsuzawa) Date: Fri, 4 Aug 2017 04:20:38 +0000 Subject: [agl-discussions] SOTA boot for minnowboard? In-Reply-To: References: , Message-ID: Hello, sorry for late reply. I also tried this with latest master, clean build, with inte-corei7-64 target, wic image. The board is minnowboard turbot. I think I had things like /ostree or ostree=xxxx in kernel command line before, but following is what I can see now. (Is this normal for sota enabled build?) Is SOTA feature disabled now even if I specify agl-sota feature option for the build? (or maybe this is just with wic image and I should specify other image type?) 1) EFI partition efi/EFI/BOOT/bootx64.efi efi/bzImage efi/loader/entries/boot.conf <- looks like ordinal entry, without ostree=xxxx command line paramter. efi/loader/loader.conf 2) root (platform) partition platform/ <- looks like ordinaly rootfs, without /ostree 3) booting I needed to add ef/startup.nsh with "bootx64.efi" in it. Also I needed to add "console=ttyS0,115200". Then the board boots successfully, and showing AGL demo homesreen. 4) image I examined the wic image. agl-demo-platform-intel-corei7-64-20170804012136.rootfs.wic: 1231MB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 1049kB 25.4MB 24.4MB fat16 primary legacy_boot 2 26.2MB 1185MB 1159MB ext4 primary 3 1185MB 1231MB 46.1MB linux-swap(v1) primary ________________________________ From: automotive-discussions-bounces at lists.linuxfoundation.org on behalf of Phil Wise Sent: Wednesday, July 19, 2017 4:40 PM To: automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SOTA boot for minnowboard? Hi, I've just done a quick test of this against AGL, and the following steps produced a bootable image: . meta-agl/scripts/aglsetup.sh -m intel-corei7-64 -b build-minnowboard agl-all-features bitbake agl-demo-platform dd if=tmp/deploy/images/intel-corei7-64/agl-demo-platform-intel-corei7-64.wic of=/dev/sdX bs=32M && sync For MinnowBoard Max (and Intel in general) there are two options for booting. Either U-Boot -> Linux (which requires reflashing the Bios with U-Boot) or booting EFI -> Grub -> Linux. The default in AGL is the EFI boot, so it should work out of the box, no is reflashing required For testing, there also is a handy script that will run a Intel-compatible image inside qemu: https://github.com/advancedtelematic/meta-updater-qemux86-64/blob/morty/scripts/run-qemu [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] advancedtelematic/meta-updater-qemux86-64 github.com Contribute to meta-updater-qemux86-64 development by creating an account on GitHub. This should be run from your build directory, and will try and detect the appropriate settings automatically. The following should work: build-minnowboard$ /path/to/run-qemu --efi agl-demo-platform Hope this helps, Phil On 14.07.2017 06:58, Takashi Matsuzawa wrote: > Sorry for the excess messsage. > > > So, the updater assumes the follwing? > > > - you have /boot and cfg files in there are used for the boot > > - you can create symbolic links in /boot > > > And when it is 2 partition media (boot and rootfs), the boot partition > is expected to be mounted as /boot? > > ------------------------------------------------------------------------ > *From:* Takashi Matsuzawa > *Sent:* Friday, July 14, 2017 1:45 PM > *To:* Jon Oster > *Cc:* automotive-discussions at lists.linuxfoundation.org > *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? > > > Hello. > > OK, I could boot choosing alternate root locaation (/ostree/xxxxxx) on > my minnowboard, with grub-efi. > > > However, I think sota expects that bootloader is aware of the uEnv.txt > file for the choice of kernel, etc. to be used for boot. > > Or, latest is just /boot/loader -> loader.1/xxxx.conf files? > And the updater makes loader symbokic link point to the desired loader > configuration folder? > > ------------------------------------------------------------------------ > *From:* Takashi Matsuzawa > *Sent:* Thursday, July 13, 2017 10:01 PM > *To:* Jon Oster > *Cc:* automotive-discussions at lists.linuxfoundation.org > *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? > > > Hello, thanks. > > Yes, I have looked into xxx.rootfs.ostree.tar.bz2 image and init.sh there. > > > Maybe I should look into non-intel AGL image as a working reference > (though you maybe booting minnowboard on u-boot on your site). > > I feel completely different bootlader for non-sota and sota is not a > good idea - but intel bsp not using u-boot has reason (at least for AGL > bsp)? > In other words is it worthwhile to tweak grub boot here, or try u-boot > on intel - or just put aside intel just for now (re: sota). > > ------------------------------------------------------------------------ > *From:* Jon Oster > *Sent:* Thursday, July 13, 2017 8:21 PM > *To:* Takashi Matsuzawa > *Cc:* automotive-discussions at lists.linuxfoundation.org > *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? > > Ah, that's the problem: agl-sota needs a bootloader prepared for use > with OSTree. OSTree keeps filesystem versions in a content-addressed > object store, and allows atomic switching between versions. To do that, > it makes a directory building out the filesystem tree via hardlinks, > then instructs the bootloader to point to the new directory on next > boot. It's certainly possible to support OSTree in bootloaders other > than U-Boot, but there's some integration work required--we've only > implemented that support in U-Boot so far. Further reading: > > https://github.com/advancedtelematic/meta-updater#adding-support-for-your-board > > https://docs.atsgarage.com/bas/comparing-fullfilesystem-update-strategies.html > https://wiki.automotivelinux.org/subsystem/agl-sota/ostree > > Best, > Jon Oster > > On Thu, Jul 13, 2017 at 12:49 PM, Takashi Matsuzawa > wrote: > > Hello. > > Thank you for your comment. > > I just found that on master branch, my initial blocker was following > in agl_joule.inc (I am building with -m joule to aglsetup.sh) > > > > OSTREE_BOOTLOADER ?= "u-boot" > > > By commenting out this (so default to grub), I could avoid build > break related to u-boot provider is not found, etc. > I am yet to verify it on target but when my build copletes, I will > give a try again. > > Just for confirmation: > > - Should it be OK that I build image with -m joule and boot on > minnowboard as well (in terms of ostree boot)? > - There should be no difference beween joule and minnowboard as target? > > - I used to make SD card by mkefi-agl.sh script to have > 2-partitioned SD card (which prepares EFI boot partition). > Expectation here is that you just can copy xxx.hddimg to SD without > modification? > > ------------------------------------------------------------------------ > *From:* Jon Oster > > *Sent:* Thursday, July 13, 2017 7:33 PM > *To:* Takashi Matsuzawa > *Cc:* automotive-discussions at lists.linuxfoundation.org > > *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? > > > Hi Takashi, > > I don't have a minnowboard handy for verifying that the image > actually boots, but I just did a build of AGL master with a slightly > more up-to-date meta-updater, and it gave me a .hddimage suitable > for flashing onto an SD card. Here's what I did: > > repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo > > repo sync > cd meta-updater > git checkout github/morty > cd .. > source meta-agl/scripts/aglsetup.sh -m intel-corei7-64 agl-demo agl-appfw-smack agl-sota > bitbake agl-image-minimal > > $ ls -lh tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64* > -rw-r--r-- 2 jon jon 611M Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.hddimg > -rw-r--r-- 1 jon jon 604M Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.otaimg > -rw-r--r-- 2 jon jon 586M Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ext4 > -rw-r--r-- 2 jon jon 100K Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.manifest > -rw-r--r-- 1 jon jon 148M Jul 13 12:17 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ostree.tar.bz2 > -rw-r--r-- 2 jon jon 629M Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.wic > lrwxrwxrwx 2 jon jon 60 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.ext4 -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ext4 > lrwxrwxrwx 2 jon jon 55 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.hddimg -> agl-image-minimal-intel-corei7-64-20170713083632.hddimg > lrwxrwxrwx 2 jon jon 64 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.manifest -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.manifest > lrwxrwxrwx 1 jon jon 70 Jul 13 12:17 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.rootfs.ostree.tar.bz2 -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ostree.tar.bz2 > lrwxrwxrwx 2 jon jon 59 Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.wic -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.wic > > Best, > Jon Oster > > On Wed, Jul 12, 2017 at 11:44 PM, Takashi Matsuzawa > > wrote: > > Hello. > > And on master (DD) is it being fixed soon? > > (Can be built and do OTA for supported boards is the bar for DD > release or it is not?) > > > ------------------------------------------------------------------------ > *From:* Takashi Matsuzawa > *Sent:* Wednesday, July 12, 2017 7:04 PM > *To:* automotive-discussions at lists.linuxfoundation.org > > *Subject:* SOTA boot for minnowboard? > > > Hello. > > I played with this today, and found sota build is broken on > master (DD). > > So, I tried CC build, using x64 (MinnowBoard) target. > > > I am confused at its final stage. > > Looks like xxxx.otaimg is just rootfs ext4 image without > partition, I am trying to generate bootable SD card. > > > Maybe it is just boot scripts (grub or systemd), is there > already automated script for this? > > I just want to avoid duplicating previsous efforts. > > > Also, I also looked into DD meta-updater tree, but the > configuration seems to be different. (using u-boot, etc.) > > Just want to check which is the way to configure it is our plan. > > > > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions > > > > > > > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions > -- Phil Wise, ATS Advanced Telematic Systems GmbH Kantstrasse 162, 10623 Berlin Managing Directors: Dirk P?schl, Armin G. Schmidt Register Court: HRB 151501 B, Amtsgericht Charlottenburg _______________________________________________ automotive-discussions mailing list automotive-discussions at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -------------- next part -------------- An HTML attachment was scrubbed... URL: From hoshina0406 at gmail.com Fri Aug 4 06:02:19 2017 From: hoshina0406 at gmail.com (Takeshi Hoshina) Date: Fri, 4 Aug 2017 15:02:19 +0900 Subject: [agl-discussions] SPEC-765 Window Manager Message-ID: Hi, I responded to an indication at F2F to WindowManager. Please check it if you have time??? https://jira.automotivelinux.org/browse/SPEC-765 BR, Takeshi-Hoshina -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil at advancedtelematic.com Fri Aug 4 06:03:45 2017 From: phil at advancedtelematic.com (Phil Wise) Date: Fri, 4 Aug 2017 08:03:45 +0200 Subject: [agl-discussions] inputs on qwebview? In-Reply-To: References: Message-ID: <0bea4f39-319f-92e0-f9d8-d1e4cf1d102e@advancedtelematic.com> I'm no Qt expert, but when I tried this I found: - Pinch zoom worked without any further work - Text input required extra work For our project we used an external virtual keyboard app (matchbox), and controlled it by watching the current selection: https://github.com/openivimobility/openivi-html5/blob/b55b140655030cfd10f2f8d24befb80f57c75874/webgraphicview.cc#L67 QVariant r = page_->inputMethodQuery(Qt::ImSurroundingText); bool shouldDisplayKeyboard = r.isValid(); ... This is still not a complete solution, because it doesn't handle things like scrolling the viewport to keep the focused input on the screen when the keyboard pops up. (Note that this project wasn't using AGL as a base, so I'm talking about features available in Qt in general here, not AGL) Best Regards, Phil On 04.08.2017 03:52, Takashi Matsuzawa wrote: > Hello. > This maybe a Qt question, but I am playing with QWebView on my AGL > target board. > > I load a web page (say, yahoo or google map) within QWebView (or > QWebEngineView). > Then I should be able to do the following wihth modification? Or some > additional integration is needed? > > - Text inputs on web page. > - Gestures like pinch zooming. > > This is latest master branch, with touch screen also USB connected > keyboard/mouse. > > I can see A tags react to my touch operation (so that I can navigate > through the links between the web pages), and can also select texts > (they are reversed), but I do not seems to do further. > > > > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions > -- Phil Wise, ATS Advanced Telematic Systems GmbH Kantstrasse 162, 10623 Berlin Managing Directors: Dirk P?schl, Armin G. Schmidt Register Court: HRB 151501 B, Amtsgericht Charlottenburg From phil at advancedtelematic.com Fri Aug 4 06:24:13 2017 From: phil at advancedtelematic.com (Phil Wise) Date: Fri, 4 Aug 2017 08:24:13 +0200 Subject: [agl-discussions] SOTA boot for minnowboard? In-Reply-To: References: Message-ID: <176fcb2f-f873-8486-678f-e20d79394880@advancedtelematic.com> Hi, OK, that's odd. Which version of AGL did you try this on? Cheers, Phil On 04.08.2017 06:20, Takashi Matsuzawa wrote: > Hello, sorry for late reply. > > I also tried this with latest master, clean build, with inte-corei7-64 > target, wic image. > The board is minnowboard turbot. > > I think I had things like /ostree or ostree=xxxx in kernel command line > before, but following is what I can see now. > (Is this normal for sota enabled build?) > > Is SOTA feature disabled now even if I specify agl-sota feature option > for the build? > (or maybe this is just with wic image and I should specify other image > type?) > > 1) EFI partition > > efi/EFI/BOOT/bootx64.efi > efi/bzImage > efi/loader/entries/boot.conf <- looks like ordinal entry, without > ostree=xxxx command line paramter. > efi/loader/loader.conf > > 2) root (platform) partition > > platform/ <- looks like ordinaly rootfs, without /ostree > > 3) booting > > I needed to add ef/startup.nsh with "bootx64.efi" in it. > Also I needed to add "console=ttyS0,115200". > Then the board boots successfully, and showing AGL demo homesreen. > > 4) image > > I examined the wic image. > > agl-demo-platform-intel-corei7-64-20170804012136.rootfs.wic: > 1231MB > Sector size (logical/physical): 512B/512B > Partition Table: gpt > > Number Start End Size File system Name Flags > 1 1049kB 25.4MB 24.4MB fat16 primary legacy_boot > 2 26.2MB 1185MB 1159MB ext4 primary > 3 1185MB 1231MB 46.1MB linux-swap(v1) primary > > > ------------------------------------------------------------------------ > *From:* automotive-discussions-bounces at lists.linuxfoundation.org > on behalf of > Phil Wise > *Sent:* Wednesday, July 19, 2017 4:40 PM > *To:* automotive-discussions at lists.linuxfoundation.org > *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? > > Hi, > > I've just done a quick test of this against AGL, and the following steps > produced a bootable image: > > . meta-agl/scripts/aglsetup.sh -m intel-corei7-64 -b build-minnowboard > agl-all-features > > bitbake agl-demo-platform > > dd > if=tmp/deploy/images/intel-corei7-64/agl-demo-platform-intel-corei7-64.wic > of=/dev/sdX bs=32M && sync > > For MinnowBoard Max (and Intel in general) there are two options for > booting. Either U-Boot -> Linux (which requires reflashing the Bios with > U-Boot) or booting EFI -> Grub -> Linux. The default in AGL is the EFI > boot, so it should work out of the box, no is reflashing required > > For testing, there also is a handy script that will run a > Intel-compatible image inside qemu: > > https://github.com/advancedtelematic/meta-updater-qemux86-64/blob/morty/scripts/run-qemu > > > > advancedtelematic/meta-updater-qemux86-64 > > github.com > Contribute to meta-updater-qemux86-64 development by creating an account > on GitHub. > > > > > This should be run from your build directory, and will try and detect > the appropriate settings automatically. The following should work: > > build-minnowboard$ /path/to/run-qemu --efi agl-demo-platform > > Hope this helps, > > > Phil > > > On 14.07.2017 06:58, Takashi Matsuzawa wrote: >> Sorry for the excess messsage. >> >> >> So, the updater assumes the follwing? >> >> >> - you have /boot and cfg files in there are used for the boot >> >> - you can create symbolic links in /boot >> >> >> And when it is 2 partition media (boot and rootfs), the boot partition >> is expected to be mounted as /boot? >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Friday, July 14, 2017 1:45 PM >> *To:* Jon Oster >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hello. >> >> OK, I could boot choosing alternate root locaation (/ostree/xxxxxx) on >> my minnowboard, with grub-efi. >> >> >> However, I think sota expects that bootloader is aware of the uEnv.txt >> file for the choice of kernel, etc. to be used for boot. >> >> Or, latest is just /boot/loader -> loader.1/xxxx.conf files? >> And the updater makes loader symbokic link point to the desired loader >> configuration folder? >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Thursday, July 13, 2017 10:01 PM >> *To:* Jon Oster >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hello, thanks. >> >> Yes, I have looked into xxx.rootfs.ostree.tar.bz2 image and init.sh there. >> >> >> Maybe I should look into non-intel AGL image as a working reference >> (though you maybe booting minnowboard on u-boot on your site). >> >> I feel completely different bootlader for non-sota and sota is not a >> good idea - but intel bsp not using u-boot has reason (at least for AGL >> bsp)? >> In other words is it worthwhile to tweak grub boot here, or try u-boot >> on intel - or just put aside intel just for now (re: sota). >> >> ------------------------------------------------------------------------ >> *From:* Jon Oster >> *Sent:* Thursday, July 13, 2017 8:21 PM >> *To:* Takashi Matsuzawa >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> Ah, that's the problem: agl-sota needs a bootloader prepared for use >> with OSTree. OSTree keeps filesystem versions in a content-addressed >> object store, and allows atomic switching between versions. To do that, >> it makes a directory building out the filesystem tree via hardlinks, >> then instructs the bootloader to point to the new directory on next >> boot. It's certainly possible to support OSTree in bootloaders other >> than U-Boot, but there's some integration work required--we've only >> implemented that support in U-Boot so far. Further reading: >> >> https://github.com/advancedtelematic/meta-updater#adding-support-for-your-board >> >> https://docs.atsgarage.com/bas/comparing-fullfilesystem-update-strategies.html >> https://wiki.automotivelinux.org/subsystem/agl-sota/ostree >> >> Best, >> Jon Oster >> >> On Thu, Jul 13, 2017 at 12:49 PM, Takashi Matsuzawa > > wrote: >> >> Hello. >> >> Thank you for your comment. >> >> I just found that on master branch, my initial blocker was following >> in agl_joule.inc (I am building with -m joule to aglsetup.sh) >> >> >> > OSTREE_BOOTLOADER ?= "u-boot" >> >> >> By commenting out this (so default to grub), I could avoid build >> break related to u-boot provider is not found, etc. >> I am yet to verify it on target but when my build copletes, I will >> give a try again. >> >> Just for confirmation: >> >> - Should it be OK that I build image with -m joule and boot on >> minnowboard as well (in terms of ostree boot)? >> - There should be no difference beween joule and minnowboard as target? >> >> - I used to make SD card by mkefi-agl.sh script to have >> 2-partitioned SD card (which prepares EFI boot partition). >> Expectation here is that you just can copy xxx.hddimg to SD without >> modification? >> >> ------------------------------------------------------------------------ >> *From:* Jon Oster > > >> *Sent:* Thursday, July 13, 2017 7:33 PM >> *To:* Takashi Matsuzawa >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hi Takashi, >> >> I don't have a minnowboard handy for verifying that the image >> actually boots, but I just did a build of AGL master with a slightly >> more up-to-date meta-updater, and it gave me a .hddimage suitable >> for flashing onto an SD card. Here's what I did: >> >> repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo >> >> repo sync >> cd meta-updater >> git checkout github/morty >> cd .. >> source meta-agl/scripts/aglsetup.sh -m intel-corei7-64 agl-demo agl-appfw-smack agl-sota >> bitbake agl-image-minimal >> >> $ ls -lh tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64* >> -rw-r--r-- 2 jon jon 611M Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.hddimg >> -rw-r--r-- 1 jon jon 604M Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.otaimg >> -rw-r--r-- 2 jon jon 586M Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ext4 >> -rw-r--r-- 2 jon jon 100K Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.manifest >> -rw-r--r-- 1 jon jon 148M Jul 13 12:17 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ostree.tar.bz2 >> -rw-r--r-- 2 jon jon 629M Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.wic >> lrwxrwxrwx 2 jon jon 60 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.ext4 -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ext4 >> lrwxrwxrwx 2 jon jon 55 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.hddimg -> agl-image-minimal-intel-corei7-64-20170713083632.hddimg >> lrwxrwxrwx 2 jon jon 64 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.manifest -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.manifest >> lrwxrwxrwx 1 jon jon 70 Jul 13 12:17 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.rootfs.ostree.tar.bz2 -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ostree.tar.bz2 >> lrwxrwxrwx 2 jon jon 59 Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.wic -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.wic >> >> Best, >> Jon Oster >> >> On Wed, Jul 12, 2017 at 11:44 PM, Takashi Matsuzawa >> > wrote: >> >> Hello. >> >> And on master (DD) is it being fixed soon? >> >> (Can be built and do OTA for supported boards is the bar for DD >> release or it is not?) >> >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Wednesday, July 12, 2017 7:04 PM >> *To:* automotive-discussions at lists.linuxfoundation.org >> >> *Subject:* SOTA boot for minnowboard? >> >> >> Hello. >> >> I played with this today, and found sota build is broken on >> master (DD). >> >> So, I tried CC build, using x64 (MinnowBoard) target. >> >> >> I am confused at its final stage. >> >> Looks like xxxx.otaimg is just rootfs ext4 image without >> partition, I am trying to generate bootable SD card. >> >> >> Maybe it is just boot scripts (grub or systemd), is there >> already automated script for this? >> >> I just want to avoid duplicating previsous efforts. >> >> >> Also, I also looked into DD meta-updater tree, but the >> configuration seems to be different. (using u-boot, etc.) >> >> Just want to check which is the way to configure it is our plan. >> >> >> >> _______________________________________________ >> automotive-discussions mailing list >> automotive-discussions at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions >> >> >> >> >> >> >> _______________________________________________ >> automotive-discussions mailing list >> automotive-discussions at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions >> > > -- > Phil Wise, ATS Advanced Telematic Systems GmbH > Kantstrasse 162, 10623 Berlin > Managing Directors: Dirk P?schl, Armin G. Schmidt > Register Court: HRB 151501 B, Amtsgericht Charlottenburg > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -- Phil Wise, ATS Advanced Telematic Systems GmbH Kantstrasse 162, 10623 Berlin Managing Directors: Dirk P?schl, Armin G. Schmidt Register Court: HRB 151501 B, Amtsgericht Charlottenburg From tmatsuzawa at xevo.com Fri Aug 4 06:53:32 2017 From: tmatsuzawa at xevo.com (Takashi Matsuzawa) Date: Fri, 4 Aug 2017 06:53:32 +0000 Subject: [agl-discussions] SOTA boot for minnowboard? In-Reply-To: <176fcb2f-f873-8486-678f-e20d79394880@advancedtelematic.com> References: , <176fcb2f-f873-8486-678f-e20d79394880@advancedtelematic.com> Message-ID: Hello. This is the master branch (synched today with repo init AGL-repo without branch/manifest names). And I am specifying agl-sota to aglsetup.sh and building agl-demo-platform. ________________________________ From: Phil Wise Sent: Friday, August 4, 2017 3:24 PM To: Takashi Matsuzawa; automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SOTA boot for minnowboard? Hi, OK, that's odd. Which version of AGL did you try this on? Cheers, Phil On 04.08.2017 06:20, Takashi Matsuzawa wrote: > Hello, sorry for late reply. > > I also tried this with latest master, clean build, with inte-corei7-64 > target, wic image. > The board is minnowboard turbot. > > I think I had things like /ostree or ostree=xxxx in kernel command line > before, but following is what I can see now. > (Is this normal for sota enabled build?) > > Is SOTA feature disabled now even if I specify agl-sota feature option > for the build? > (or maybe this is just with wic image and I should specify other image > type?) > > 1) EFI partition > > efi/EFI/BOOT/bootx64.efi > efi/bzImage > efi/loader/entries/boot.conf <- looks like ordinal entry, without > ostree=xxxx command line paramter. > efi/loader/loader.conf > > 2) root (platform) partition > > platform/ <- looks like ordinaly rootfs, without /ostree > > 3) booting > > I needed to add ef/startup.nsh with "bootx64.efi" in it. > Also I needed to add "console=ttyS0,115200". > Then the board boots successfully, and showing AGL demo homesreen. > > 4) image > > I examined the wic image. > > agl-demo-platform-intel-corei7-64-20170804012136.rootfs.wic: > 1231MB > Sector size (logical/physical): 512B/512B > Partition Table: gpt > > Number Start End Size File system Name Flags > 1 1049kB 25.4MB 24.4MB fat16 primary legacy_boot > 2 26.2MB 1185MB 1159MB ext4 primary > 3 1185MB 1231MB 46.1MB linux-swap(v1) primary > > > ------------------------------------------------------------------------ > *From:* automotive-discussions-bounces at lists.linuxfoundation.org > on behalf of > Phil Wise > *Sent:* Wednesday, July 19, 2017 4:40 PM > *To:* automotive-discussions at lists.linuxfoundation.org > *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? > > Hi, > > I've just done a quick test of this against AGL, and the following steps > produced a bootable image: > > . meta-agl/scripts/aglsetup.sh -m intel-corei7-64 -b build-minnowboard > agl-all-features > > bitbake agl-demo-platform > > dd > if=tmp/deploy/images/intel-corei7-64/agl-demo-platform-intel-corei7-64.wic > of=/dev/sdX bs=32M && sync > > For MinnowBoard Max (and Intel in general) there are two options for > booting. Either U-Boot -> Linux (which requires reflashing the Bios with > U-Boot) or booting EFI -> Grub -> Linux. The default in AGL is the EFI > boot, so it should work out of the box, no is reflashing required > > For testing, there also is a handy script that will run a > Intel-compatible image inside qemu: > > https://github.com/advancedtelematic/meta-updater-qemux86-64/blob/morty/scripts/run-qemu [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] advancedtelematic/meta-updater-qemux86-64 github.com Contribute to meta-updater-qemux86-64 development by creating an account on GitHub. > > [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] advancedtelematic/meta-updater-qemux86-64 github.com Contribute to meta-updater-qemux86-64 development by creating an account on GitHub. > > advancedtelematic/meta-updater-qemux86-64 > [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] advancedtelematic/meta-updater-qemux86-64 github.com Contribute to meta-updater-qemux86-64 development by creating an account on GitHub. > github.com > Contribute to meta-updater-qemux86-64 development by creating an account > on GitHub. > > > > > This should be run from your build directory, and will try and detect > the appropriate settings automatically. The following should work: > > build-minnowboard$ /path/to/run-qemu --efi agl-demo-platform > > Hope this helps, > > > Phil > > > On 14.07.2017 06:58, Takashi Matsuzawa wrote: >> Sorry for the excess messsage. >> >> >> So, the updater assumes the follwing? >> >> >> - you have /boot and cfg files in there are used for the boot >> >> - you can create symbolic links in /boot >> >> >> And when it is 2 partition media (boot and rootfs), the boot partition >> is expected to be mounted as /boot? >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Friday, July 14, 2017 1:45 PM >> *To:* Jon Oster >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hello. >> >> OK, I could boot choosing alternate root locaation (/ostree/xxxxxx) on >> my minnowboard, with grub-efi. >> >> >> However, I think sota expects that bootloader is aware of the uEnv.txt >> file for the choice of kernel, etc. to be used for boot. >> >> Or, latest is just /boot/loader -> loader.1/xxxx.conf files? >> And the updater makes loader symbokic link point to the desired loader >> configuration folder? >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Thursday, July 13, 2017 10:01 PM >> *To:* Jon Oster >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hello, thanks. >> >> Yes, I have looked into xxx.rootfs.ostree.tar.bz2 image and init.sh there. >> >> >> Maybe I should look into non-intel AGL image as a working reference >> (though you maybe booting minnowboard on u-boot on your site). >> >> I feel completely different bootlader for non-sota and sota is not a >> good idea - but intel bsp not using u-boot has reason (at least for AGL >> bsp)? >> In other words is it worthwhile to tweak grub boot here, or try u-boot >> on intel - or just put aside intel just for now (re: sota). >> >> ------------------------------------------------------------------------ >> *From:* Jon Oster >> *Sent:* Thursday, July 13, 2017 8:21 PM >> *To:* Takashi Matsuzawa >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> Ah, that's the problem: agl-sota needs a bootloader prepared for use >> with OSTree. OSTree keeps filesystem versions in a content-addressed >> object store, and allows atomic switching between versions. To do that, >> it makes a directory building out the filesystem tree via hardlinks, >> then instructs the bootloader to point to the new directory on next >> boot. It's certainly possible to support OSTree in bootloaders other >> than U-Boot, but there's some integration work required--we've only >> implemented that support in U-Boot so far. Further reading: >> >> https://github.com/advancedtelematic/meta-updater#adding-support-for-your-board [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] GitHub - advancedtelematic/meta-updater: OTA Software ... github.com This layer enables over-the-air updates (OTA) with OSTree and RVI SOTA client. OSTree is a tool for atomic full file system upgrades with rollback capability. OSTree ... >> >> https://docs.atsgarage.com/bas/comparing-fullfilesystem-update-strategies.html >> https://wiki.automotivelinux.org/subsystem/agl-sota/ostree >> >> Best, >> Jon Oster >> >> On Thu, Jul 13, 2017 at 12:49 PM, Takashi Matsuzawa > > wrote: >> >> Hello. >> >> Thank you for your comment. >> >> I just found that on master branch, my initial blocker was following >> in agl_joule.inc (I am building with -m joule to aglsetup.sh) >> >> >> > OSTREE_BOOTLOADER ?= "u-boot" >> >> >> By commenting out this (so default to grub), I could avoid build >> break related to u-boot provider is not found, etc. >> I am yet to verify it on target but when my build copletes, I will >> give a try again. >> >> Just for confirmation: >> >> - Should it be OK that I build image with -m joule and boot on >> minnowboard as well (in terms of ostree boot)? >> - There should be no difference beween joule and minnowboard as target? >> >> - I used to make SD card by mkefi-agl.sh script to have >> 2-partitioned SD card (which prepares EFI boot partition). >> Expectation here is that you just can copy xxx.hddimg to SD without >> modification? >> >> ------------------------------------------------------------------------ >> *From:* Jon Oster > > >> *Sent:* Thursday, July 13, 2017 7:33 PM >> *To:* Takashi Matsuzawa >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hi Takashi, >> >> I don't have a minnowboard handy for verifying that the image >> actually boots, but I just did a build of AGL master with a slightly >> more up-to-date meta-updater, and it gave me a .hddimage suitable >> for flashing onto an SD card. Here's what I did: >> >> repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo >> >> repo sync >> cd meta-updater >> git checkout github/morty >> cd .. >> source meta-agl/scripts/aglsetup.sh -m intel-corei7-64 agl-demo agl-appfw-smack agl-sota >> bitbake agl-image-minimal >> >> $ ls -lh tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64* >> -rw-r--r-- 2 jon jon 611M Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.hddimg >> -rw-r--r-- 1 jon jon 604M Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.otaimg >> -rw-r--r-- 2 jon jon 586M Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ext4 >> -rw-r--r-- 2 jon jon 100K Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.manifest >> -rw-r--r-- 1 jon jon 148M Jul 13 12:17 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ostree.tar.bz2 >> -rw-r--r-- 2 jon jon 629M Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.wic >> lrwxrwxrwx 2 jon jon 60 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.ext4 -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ext4 >> lrwxrwxrwx 2 jon jon 55 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.hddimg -> agl-image-minimal-intel-corei7-64-20170713083632.hddimg >> lrwxrwxrwx 2 jon jon 64 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.manifest -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.manifest >> lrwxrwxrwx 1 jon jon 70 Jul 13 12:17 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.rootfs.ostree.tar.bz2 -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ostree.tar.bz2 >> lrwxrwxrwx 2 jon jon 59 Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.wic -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.wic >> >> Best, >> Jon Oster >> >> On Wed, Jul 12, 2017 at 11:44 PM, Takashi Matsuzawa >> > wrote: >> >> Hello. >> >> And on master (DD) is it being fixed soon? >> >> (Can be built and do OTA for supported boards is the bar for DD >> release or it is not?) >> >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Wednesday, July 12, 2017 7:04 PM >> *To:* automotive-discussions at lists.linuxfoundation.org >> >> *Subject:* SOTA boot for minnowboard? >> >> >> Hello. >> >> I played with this today, and found sota build is broken on >> master (DD). >> >> So, I tried CC build, using x64 (MinnowBoard) target. >> >> >> I am confused at its final stage. >> >> Looks like xxxx.otaimg is just rootfs ext4 image without >> partition, I am trying to generate bootable SD card. >> >> >> Maybe it is just boot scripts (grub or systemd), is there >> already automated script for this? >> >> I just want to avoid duplicating previsous efforts. >> >> >> Also, I also looked into DD meta-updater tree, but the >> configuration seems to be different. (using u-boot, etc.) >> >> Just want to check which is the way to configure it is our plan. >> >> >> >> _______________________________________________ >> automotive-discussions mailing list >> automotive-discussions at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions >> >> >> >> >> >> >> _______________________________________________ >> automotive-discussions mailing list >> automotive-discussions at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions >> > > -- > Phil Wise, ATS Advanced Telematic Systems GmbH > Kantstrasse 162, 10623 Berlin > Managing Directors: Dirk P?schl, Armin G. Schmidt > Register Court: HRB 151501 B, Amtsgericht Charlottenburg > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -- Phil Wise, ATS Advanced Telematic Systems GmbH Kantstrasse 162, 10623 Berlin Managing Directors: Dirk P?schl, Armin G. Schmidt Register Court: HRB 151501 B, Amtsgericht Charlottenburg -------------- next part -------------- An HTML attachment was scrubbed... URL: From fixed-term.Vamsinag.Gunti at de.bosch.com Fri Aug 4 07:11:34 2017 From: fixed-term.Vamsinag.Gunti at de.bosch.com (FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1)) Date: Fri, 4 Aug 2017 07:11:34 +0000 Subject: [agl-discussions] SDK newbie questions In-Reply-To: <6503577A-A71B-4A2B-A182-C7149A53EF1F@RADIOSOUND.com> References: <6503577A-A71B-4A2B-A182-C7149A53EF1F@RADIOSOUND.com> Message-ID: Hi Dennis, Thank you very much. I shall try this and get back to you. Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 From: Dennis Field [mailto:dennisf at RADIOSOUND.com] Sent: Thursday, August 3, 2017 6:24 PM To: FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) Cc: automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SDK newbie questions Vamsi, Check out the AGL QML hello world app I made when I had just gotten XDS up and running. https://github.com/radiosound-com/agl-hello-qml/ The Qt project was based on the hello world QML template that Qt Creator generates when you make a new Qt Quick Controls 2 application. I made a subfolder project so that the app project could live separately from the package project that AGL uses to build the wgt file (this was just so I could build on desktop and verify the AGL styled controls worked before putting it on the board) The instructions in the readme are how to set up Qt Creator in Windows to integrate with XDS (not as elegantly as I'd like, but it worked well enough for my purposes). I haven't tried it on a Linux host yet, some of the instructions may need to be adjusted. If I get a chance this week, I'll do that. If all you need to look at is the project structure, though, this is one way to set it up. Hope that helps! Sent from Bill Gates' iPhone On Aug 3, 2017, at 9:28 AM, FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > wrote: Hi, Is there any documentation available on the structure of a Qt QML application? The applications that are available in the demos seems to have a different structure as compared to the structure created by my Qt Creator. Additionally what type of a project is to be selected when creating an application on QtCreator? I chose a Qt Quick Controls Application and the structure was completely different from the demo apps and was not able to proceed any further. And could someone kindly direct me to any documentation on writing an application from scratch in qml/html5? I did refer the AppFramwork documentation. While it does give ample information on building an app and information about the configuration file, I don't seem to find any information on the app file/folder structure etc. Thanks in advance :) Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 _______________________________________________ automotive-discussions mailing list automotive-discussions at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmatsuzawa at xevo.com Fri Aug 4 07:19:59 2017 From: tmatsuzawa at xevo.com (Takashi Matsuzawa) Date: Fri, 4 Aug 2017 07:19:59 +0000 Subject: [agl-discussions] SOTA boot for minnowboard? In-Reply-To: References: , <176fcb2f-f873-8486-678f-e20d79394880@advancedtelematic.com>, Message-ID: Hello Looks like following line not found for intel agl_${MACHINE}.inc file? >DISTRO_FEATURES_append = " sota" ________________________________ From: automotive-discussions-bounces at lists.linuxfoundation.org on behalf of Takashi Matsuzawa Sent: Friday, August 4, 2017 3:53 PM To: Phil Wise; automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SOTA boot for minnowboard? Hello. This is the master branch (synched today with repo init AGL-repo without branch/manifest names). And I am specifying agl-sota to aglsetup.sh and building agl-demo-platform. ________________________________ From: Phil Wise Sent: Friday, August 4, 2017 3:24 PM To: Takashi Matsuzawa; automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SOTA boot for minnowboard? Hi, OK, that's odd. Which version of AGL did you try this on? Cheers, Phil On 04.08.2017 06:20, Takashi Matsuzawa wrote: > Hello, sorry for late reply. > > I also tried this with latest master, clean build, with inte-corei7-64 > target, wic image. > The board is minnowboard turbot. > > I think I had things like /ostree or ostree=xxxx in kernel command line > before, but following is what I can see now. > (Is this normal for sota enabled build?) > > Is SOTA feature disabled now even if I specify agl-sota feature option > for the build? > (or maybe this is just with wic image and I should specify other image > type?) > > 1) EFI partition > > efi/EFI/BOOT/bootx64.efi > efi/bzImage > efi/loader/entries/boot.conf <- looks like ordinal entry, without > ostree=xxxx command line paramter. > efi/loader/loader.conf > > 2) root (platform) partition > > platform/ <- looks like ordinaly rootfs, without /ostree > > 3) booting > > I needed to add ef/startup.nsh with "bootx64.efi" in it. > Also I needed to add "console=ttyS0,115200". > Then the board boots successfully, and showing AGL demo homesreen. > > 4) image > > I examined the wic image. > > agl-demo-platform-intel-corei7-64-20170804012136.rootfs.wic: > 1231MB > Sector size (logical/physical): 512B/512B > Partition Table: gpt > > Number Start End Size File system Name Flags > 1 1049kB 25.4MB 24.4MB fat16 primary legacy_boot > 2 26.2MB 1185MB 1159MB ext4 primary > 3 1185MB 1231MB 46.1MB linux-swap(v1) primary > > > ------------------------------------------------------------------------ > *From:* automotive-discussions-bounces at lists.linuxfoundation.org > on behalf of > Phil Wise > *Sent:* Wednesday, July 19, 2017 4:40 PM > *To:* automotive-discussions at lists.linuxfoundation.org > *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? > > Hi, > > I've just done a quick test of this against AGL, and the following steps > produced a bootable image: > > . meta-agl/scripts/aglsetup.sh -m intel-corei7-64 -b build-minnowboard > agl-all-features > > bitbake agl-demo-platform > > dd > if=tmp/deploy/images/intel-corei7-64/agl-demo-platform-intel-corei7-64.wic > of=/dev/sdX bs=32M && sync > > For MinnowBoard Max (and Intel in general) there are two options for > booting. Either U-Boot -> Linux (which requires reflashing the Bios with > U-Boot) or booting EFI -> Grub -> Linux. The default in AGL is the EFI > boot, so it should work out of the box, no is reflashing required > > For testing, there also is a handy script that will run a > Intel-compatible image inside qemu: > > https://github.com/advancedtelematic/meta-updater-qemux86-64/blob/morty/scripts/run-qemu [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] advancedtelematic/meta-updater-qemux86-64 github.com Contribute to meta-updater-qemux86-64 development by creating an account on GitHub. > > [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] advancedtelematic/meta-updater-qemux86-64 github.com Contribute to meta-updater-qemux86-64 development by creating an account on GitHub. > > advancedtelematic/meta-updater-qemux86-64 > [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] advancedtelematic/meta-updater-qemux86-64 github.com Contribute to meta-updater-qemux86-64 development by creating an account on GitHub. > github.com > Contribute to meta-updater-qemux86-64 development by creating an account > on GitHub. > > > > > This should be run from your build directory, and will try and detect > the appropriate settings automatically. The following should work: > > build-minnowboard$ /path/to/run-qemu --efi agl-demo-platform > > Hope this helps, > > > Phil > > > On 14.07.2017 06:58, Takashi Matsuzawa wrote: >> Sorry for the excess messsage. >> >> >> So, the updater assumes the follwing? >> >> >> - you have /boot and cfg files in there are used for the boot >> >> - you can create symbolic links in /boot >> >> >> And when it is 2 partition media (boot and rootfs), the boot partition >> is expected to be mounted as /boot? >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Friday, July 14, 2017 1:45 PM >> *To:* Jon Oster >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hello. >> >> OK, I could boot choosing alternate root locaation (/ostree/xxxxxx) on >> my minnowboard, with grub-efi. >> >> >> However, I think sota expects that bootloader is aware of the uEnv.txt >> file for the choice of kernel, etc. to be used for boot. >> >> Or, latest is just /boot/loader -> loader.1/xxxx.conf files? >> And the updater makes loader symbokic link point to the desired loader >> configuration folder? >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Thursday, July 13, 2017 10:01 PM >> *To:* Jon Oster >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hello, thanks. >> >> Yes, I have looked into xxx.rootfs.ostree.tar.bz2 image and init.sh there. >> >> >> Maybe I should look into non-intel AGL image as a working reference >> (though you maybe booting minnowboard on u-boot on your site). >> >> I feel completely different bootlader for non-sota and sota is not a >> good idea - but intel bsp not using u-boot has reason (at least for AGL >> bsp)? >> In other words is it worthwhile to tweak grub boot here, or try u-boot >> on intel - or just put aside intel just for now (re: sota). >> >> ------------------------------------------------------------------------ >> *From:* Jon Oster >> *Sent:* Thursday, July 13, 2017 8:21 PM >> *To:* Takashi Matsuzawa >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> Ah, that's the problem: agl-sota needs a bootloader prepared for use >> with OSTree. OSTree keeps filesystem versions in a content-addressed >> object store, and allows atomic switching between versions. To do that, >> it makes a directory building out the filesystem tree via hardlinks, >> then instructs the bootloader to point to the new directory on next >> boot. It's certainly possible to support OSTree in bootloaders other >> than U-Boot, but there's some integration work required--we've only >> implemented that support in U-Boot so far. Further reading: >> >> https://github.com/advancedtelematic/meta-updater#adding-support-for-your-board [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] GitHub - advancedtelematic/meta-updater: OTA Software ... github.com This layer enables over-the-air updates (OTA) with OSTree and RVI SOTA client. OSTree is a tool for atomic full file system upgrades with rollback capability. OSTree ... >> >> https://docs.atsgarage.com/bas/comparing-fullfilesystem-update-strategies.html >> https://wiki.automotivelinux.org/subsystem/agl-sota/ostree >> >> Best, >> Jon Oster >> >> On Thu, Jul 13, 2017 at 12:49 PM, Takashi Matsuzawa > > wrote: >> >> Hello. >> >> Thank you for your comment. >> >> I just found that on master branch, my initial blocker was following >> in agl_joule.inc (I am building with -m joule to aglsetup.sh) >> >> >> > OSTREE_BOOTLOADER ?= "u-boot" >> >> >> By commenting out this (so default to grub), I could avoid build >> break related to u-boot provider is not found, etc. >> I am yet to verify it on target but when my build copletes, I will >> give a try again. >> >> Just for confirmation: >> >> - Should it be OK that I build image with -m joule and boot on >> minnowboard as well (in terms of ostree boot)? >> - There should be no difference beween joule and minnowboard as target? >> >> - I used to make SD card by mkefi-agl.sh script to have >> 2-partitioned SD card (which prepares EFI boot partition). >> Expectation here is that you just can copy xxx.hddimg to SD without >> modification? >> >> ------------------------------------------------------------------------ >> *From:* Jon Oster > > >> *Sent:* Thursday, July 13, 2017 7:33 PM >> *To:* Takashi Matsuzawa >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hi Takashi, >> >> I don't have a minnowboard handy for verifying that the image >> actually boots, but I just did a build of AGL master with a slightly >> more up-to-date meta-updater, and it gave me a .hddimage suitable >> for flashing onto an SD card. Here's what I did: >> >> repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo >> >> repo sync >> cd meta-updater >> git checkout github/morty >> cd .. >> source meta-agl/scripts/aglsetup.sh -m intel-corei7-64 agl-demo agl-appfw-smack agl-sota >> bitbake agl-image-minimal >> >> $ ls -lh tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64* >> -rw-r--r-- 2 jon jon 611M Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.hddimg >> -rw-r--r-- 1 jon jon 604M Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.otaimg >> -rw-r--r-- 2 jon jon 586M Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ext4 >> -rw-r--r-- 2 jon jon 100K Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.manifest >> -rw-r--r-- 1 jon jon 148M Jul 13 12:17 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ostree.tar.bz2 >> -rw-r--r-- 2 jon jon 629M Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.wic >> lrwxrwxrwx 2 jon jon 60 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.ext4 -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ext4 >> lrwxrwxrwx 2 jon jon 55 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.hddimg -> agl-image-minimal-intel-corei7-64-20170713083632.hddimg >> lrwxrwxrwx 2 jon jon 64 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.manifest -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.manifest >> lrwxrwxrwx 1 jon jon 70 Jul 13 12:17 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.rootfs.ostree.tar.bz2 -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ostree.tar.bz2 >> lrwxrwxrwx 2 jon jon 59 Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.wic -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.wic >> >> Best, >> Jon Oster >> >> On Wed, Jul 12, 2017 at 11:44 PM, Takashi Matsuzawa >> > wrote: >> >> Hello. >> >> And on master (DD) is it being fixed soon? >> >> (Can be built and do OTA for supported boards is the bar for DD >> release or it is not?) >> >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Wednesday, July 12, 2017 7:04 PM >> *To:* automotive-discussions at lists.linuxfoundation.org >> >> *Subject:* SOTA boot for minnowboard? >> >> >> Hello. >> >> I played with this today, and found sota build is broken on >> master (DD). >> >> So, I tried CC build, using x64 (MinnowBoard) target. >> >> >> I am confused at its final stage. >> >> Looks like xxxx.otaimg is just rootfs ext4 image without >> partition, I am trying to generate bootable SD card. >> >> >> Maybe it is just boot scripts (grub or systemd), is there >> already automated script for this? >> >> I just want to avoid duplicating previsous efforts. >> >> >> Also, I also looked into DD meta-updater tree, but the >> configuration seems to be different. (using u-boot, etc.) >> >> Just want to check which is the way to configure it is our plan. >> >> >> >> _______________________________________________ >> automotive-discussions mailing list >> automotive-discussions at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions >> >> >> >> >> >> >> _______________________________________________ >> automotive-discussions mailing list >> automotive-discussions at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions >> > > -- > Phil Wise, ATS Advanced Telematic Systems GmbH > Kantstrasse 162, 10623 Berlin > Managing Directors: Dirk P?schl, Armin G. Schmidt > Register Court: HRB 151501 B, Amtsgericht Charlottenburg > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -- Phil Wise, ATS Advanced Telematic Systems GmbH Kantstrasse 162, 10623 Berlin Managing Directors: Dirk P?schl, Armin G. Schmidt Register Court: HRB 151501 B, Amtsgericht Charlottenburg -------------- next part -------------- An HTML attachment was scrubbed... URL: From wang_zhiqiang at dl.cn.nexty-ele.com Fri Aug 4 07:33:25 2017 From: wang_zhiqiang at dl.cn.nexty-ele.com (wang_zhiqiang) Date: Fri, 4 Aug 2017 15:33:25 +0800 Subject: [agl-discussions] why homescreen doesn't use the icon in app's wgt Message-ID: <000f01d30cf3$f5ba2640$e12e72c0$@dl.cn.nexty-ele.com> Hi everyone I am trying to add a sample app in homescreen, but I found homescreen doesn?t use my app?s icon.svg, It used png icons in ?${workdir}/git/homescreen/qml/images/Home?. this design maked some troubles to me , likes below: 1) I just want to add a sample app,but I must change homescreen sourcecode(changed home.qrc). 2) png icon can?t added to patch, so I can?t distribute my sample easily I thought this design is not convenient, maybe homescreen use app?s icon.svg is a good idea. But work is work, could anyone tell me how to add an app?s icon easily? Thanks in advance. BestRegards! ==================================== NEXTY ELECTRONICS CORPORATION(Dalian) ??Wang ZhiQiang E-MAIL:wang_zhiqiang at dl.cn.nexty-ele.com ==================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmatsuzawa at xevo.com Fri Aug 4 08:23:52 2017 From: tmatsuzawa at xevo.com (Takashi Matsuzawa) Date: Fri, 4 Aug 2017 08:23:52 +0000 Subject: [agl-discussions] SOTA boot for minnowboard? In-Reply-To: References: , <176fcb2f-f873-8486-678f-e20d79394880@advancedtelematic.com>, , Message-ID: Hello. After adding below to local.conf, I could generate xxx.wic file that can boot as it is. I can see boot partition grub.cfg search for "otaroot" disk, and I can see in efi/rootfs partitions, following trees among others. efi part: /boot/ostree/xxxx/ (w/ initramfs, vmlinuz) rootfs part: /ostree/yyyy/... (w/ boot.1/poky/xxxx) So, this is the expected disk geometry for sota? ________________________________ From: automotive-discussions-bounces at lists.linuxfoundation.org on behalf of Takashi Matsuzawa Sent: Friday, August 4, 2017 4:19 PM To: Phil Wise; automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SOTA boot for minnowboard? Hello Looks like following line not found for intel agl_${MACHINE}.inc file? >DISTRO_FEATURES_append = " sota" ________________________________ From: automotive-discussions-bounces at lists.linuxfoundation.org on behalf of Takashi Matsuzawa Sent: Friday, August 4, 2017 3:53 PM To: Phil Wise; automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SOTA boot for minnowboard? Hello. This is the master branch (synched today with repo init AGL-repo without branch/manifest names). And I am specifying agl-sota to aglsetup.sh and building agl-demo-platform. ________________________________ From: Phil Wise Sent: Friday, August 4, 2017 3:24 PM To: Takashi Matsuzawa; automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SOTA boot for minnowboard? Hi, OK, that's odd. Which version of AGL did you try this on? Cheers, Phil On 04.08.2017 06:20, Takashi Matsuzawa wrote: > Hello, sorry for late reply. > > I also tried this with latest master, clean build, with inte-corei7-64 > target, wic image. > The board is minnowboard turbot. > > I think I had things like /ostree or ostree=xxxx in kernel command line > before, but following is what I can see now. > (Is this normal for sota enabled build?) > > Is SOTA feature disabled now even if I specify agl-sota feature option > for the build? > (or maybe this is just with wic image and I should specify other image > type?) > > 1) EFI partition > > efi/EFI/BOOT/bootx64.efi > efi/bzImage > efi/loader/entries/boot.conf <- looks like ordinal entry, without > ostree=xxxx command line paramter. > efi/loader/loader.conf > > 2) root (platform) partition > > platform/ <- looks like ordinaly rootfs, without /ostree > > 3) booting > > I needed to add ef/startup.nsh with "bootx64.efi" in it. > Also I needed to add "console=ttyS0,115200". > Then the board boots successfully, and showing AGL demo homesreen. > > 4) image > > I examined the wic image. > > agl-demo-platform-intel-corei7-64-20170804012136.rootfs.wic: > 1231MB > Sector size (logical/physical): 512B/512B > Partition Table: gpt > > Number Start End Size File system Name Flags > 1 1049kB 25.4MB 24.4MB fat16 primary legacy_boot > 2 26.2MB 1185MB 1159MB ext4 primary > 3 1185MB 1231MB 46.1MB linux-swap(v1) primary > > > ------------------------------------------------------------------------ > *From:* automotive-discussions-bounces at lists.linuxfoundation.org > on behalf of > Phil Wise > *Sent:* Wednesday, July 19, 2017 4:40 PM > *To:* automotive-discussions at lists.linuxfoundation.org > *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? > > Hi, > > I've just done a quick test of this against AGL, and the following steps > produced a bootable image: > > . meta-agl/scripts/aglsetup.sh -m intel-corei7-64 -b build-minnowboard > agl-all-features > > bitbake agl-demo-platform > > dd > if=tmp/deploy/images/intel-corei7-64/agl-demo-platform-intel-corei7-64.wic > of=/dev/sdX bs=32M && sync > > For MinnowBoard Max (and Intel in general) there are two options for > booting. Either U-Boot -> Linux (which requires reflashing the Bios with > U-Boot) or booting EFI -> Grub -> Linux. The default in AGL is the EFI > boot, so it should work out of the box, no is reflashing required > > For testing, there also is a handy script that will run a > Intel-compatible image inside qemu: > > https://github.com/advancedtelematic/meta-updater-qemux86-64/blob/morty/scripts/run-qemu [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] advancedtelematic/meta-updater-qemux86-64 github.com Contribute to meta-updater-qemux86-64 development by creating an account on GitHub. > > [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] advancedtelematic/meta-updater-qemux86-64 github.com Contribute to meta-updater-qemux86-64 development by creating an account on GitHub. > > advancedtelematic/meta-updater-qemux86-64 > [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] advancedtelematic/meta-updater-qemux86-64 github.com Contribute to meta-updater-qemux86-64 development by creating an account on GitHub. > github.com > Contribute to meta-updater-qemux86-64 development by creating an account > on GitHub. > > > > > This should be run from your build directory, and will try and detect > the appropriate settings automatically. The following should work: > > build-minnowboard$ /path/to/run-qemu --efi agl-demo-platform > > Hope this helps, > > > Phil > > > On 14.07.2017 06:58, Takashi Matsuzawa wrote: >> Sorry for the excess messsage. >> >> >> So, the updater assumes the follwing? >> >> >> - you have /boot and cfg files in there are used for the boot >> >> - you can create symbolic links in /boot >> >> >> And when it is 2 partition media (boot and rootfs), the boot partition >> is expected to be mounted as /boot? >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Friday, July 14, 2017 1:45 PM >> *To:* Jon Oster >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hello. >> >> OK, I could boot choosing alternate root locaation (/ostree/xxxxxx) on >> my minnowboard, with grub-efi. >> >> >> However, I think sota expects that bootloader is aware of the uEnv.txt >> file for the choice of kernel, etc. to be used for boot. >> >> Or, latest is just /boot/loader -> loader.1/xxxx.conf files? >> And the updater makes loader symbokic link point to the desired loader >> configuration folder? >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Thursday, July 13, 2017 10:01 PM >> *To:* Jon Oster >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hello, thanks. >> >> Yes, I have looked into xxx.rootfs.ostree.tar.bz2 image and init.sh there. >> >> >> Maybe I should look into non-intel AGL image as a working reference >> (though you maybe booting minnowboard on u-boot on your site). >> >> I feel completely different bootlader for non-sota and sota is not a >> good idea - but intel bsp not using u-boot has reason (at least for AGL >> bsp)? >> In other words is it worthwhile to tweak grub boot here, or try u-boot >> on intel - or just put aside intel just for now (re: sota). >> >> ------------------------------------------------------------------------ >> *From:* Jon Oster >> *Sent:* Thursday, July 13, 2017 8:21 PM >> *To:* Takashi Matsuzawa >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> Ah, that's the problem: agl-sota needs a bootloader prepared for use >> with OSTree. OSTree keeps filesystem versions in a content-addressed >> object store, and allows atomic switching between versions. To do that, >> it makes a directory building out the filesystem tree via hardlinks, >> then instructs the bootloader to point to the new directory on next >> boot. It's certainly possible to support OSTree in bootloaders other >> than U-Boot, but there's some integration work required--we've only >> implemented that support in U-Boot so far. Further reading: >> >> https://github.com/advancedtelematic/meta-updater#adding-support-for-your-board [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] GitHub - advancedtelematic/meta-updater: OTA Software ... github.com This layer enables over-the-air updates (OTA) with OSTree and RVI SOTA client. OSTree is a tool for atomic full file system upgrades with rollback capability. OSTree ... >> >> https://docs.atsgarage.com/bas/comparing-fullfilesystem-update-strategies.html >> https://wiki.automotivelinux.org/subsystem/agl-sota/ostree >> >> Best, >> Jon Oster >> >> On Thu, Jul 13, 2017 at 12:49 PM, Takashi Matsuzawa > > wrote: >> >> Hello. >> >> Thank you for your comment. >> >> I just found that on master branch, my initial blocker was following >> in agl_joule.inc (I am building with -m joule to aglsetup.sh) >> >> >> > OSTREE_BOOTLOADER ?= "u-boot" >> >> >> By commenting out this (so default to grub), I could avoid build >> break related to u-boot provider is not found, etc. >> I am yet to verify it on target but when my build copletes, I will >> give a try again. >> >> Just for confirmation: >> >> - Should it be OK that I build image with -m joule and boot on >> minnowboard as well (in terms of ostree boot)? >> - There should be no difference beween joule and minnowboard as target? >> >> - I used to make SD card by mkefi-agl.sh script to have >> 2-partitioned SD card (which prepares EFI boot partition). >> Expectation here is that you just can copy xxx.hddimg to SD without >> modification? >> >> ------------------------------------------------------------------------ >> *From:* Jon Oster > > >> *Sent:* Thursday, July 13, 2017 7:33 PM >> *To:* Takashi Matsuzawa >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hi Takashi, >> >> I don't have a minnowboard handy for verifying that the image >> actually boots, but I just did a build of AGL master with a slightly >> more up-to-date meta-updater, and it gave me a .hddimage suitable >> for flashing onto an SD card. Here's what I did: >> >> repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo >> >> repo sync >> cd meta-updater >> git checkout github/morty >> cd .. >> source meta-agl/scripts/aglsetup.sh -m intel-corei7-64 agl-demo agl-appfw-smack agl-sota >> bitbake agl-image-minimal >> >> $ ls -lh tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64* >> -rw-r--r-- 2 jon jon 611M Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.hddimg >> -rw-r--r-- 1 jon jon 604M Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.otaimg >> -rw-r--r-- 2 jon jon 586M Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ext4 >> -rw-r--r-- 2 jon jon 100K Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.manifest >> -rw-r--r-- 1 jon jon 148M Jul 13 12:17 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ostree.tar.bz2 >> -rw-r--r-- 2 jon jon 629M Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.wic >> lrwxrwxrwx 2 jon jon 60 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.ext4 -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ext4 >> lrwxrwxrwx 2 jon jon 55 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.hddimg -> agl-image-minimal-intel-corei7-64-20170713083632.hddimg >> lrwxrwxrwx 2 jon jon 64 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.manifest -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.manifest >> lrwxrwxrwx 1 jon jon 70 Jul 13 12:17 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.rootfs.ostree.tar.bz2 -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ostree.tar.bz2 >> lrwxrwxrwx 2 jon jon 59 Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.wic -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.wic >> >> Best, >> Jon Oster >> >> On Wed, Jul 12, 2017 at 11:44 PM, Takashi Matsuzawa >> > wrote: >> >> Hello. >> >> And on master (DD) is it being fixed soon? >> >> (Can be built and do OTA for supported boards is the bar for DD >> release or it is not?) >> >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Wednesday, July 12, 2017 7:04 PM >> *To:* automotive-discussions at lists.linuxfoundation.org >> >> *Subject:* SOTA boot for minnowboard? >> >> >> Hello. >> >> I played with this today, and found sota build is broken on >> master (DD). >> >> So, I tried CC build, using x64 (MinnowBoard) target. >> >> >> I am confused at its final stage. >> >> Looks like xxxx.otaimg is just rootfs ext4 image without >> partition, I am trying to generate bootable SD card. >> >> >> Maybe it is just boot scripts (grub or systemd), is there >> already automated script for this? >> >> I just want to avoid duplicating previsous efforts. >> >> >> Also, I also looked into DD meta-updater tree, but the >> configuration seems to be different. (using u-boot, etc.) >> >> Just want to check which is the way to configure it is our plan. >> >> >> >> _______________________________________________ >> automotive-discussions mailing list >> automotive-discussions at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions >> >> >> >> >> >> >> _______________________________________________ >> automotive-discussions mailing list >> automotive-discussions at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions >> > > -- > Phil Wise, ATS Advanced Telematic Systems GmbH > Kantstrasse 162, 10623 Berlin > Managing Directors: Dirk P?schl, Armin G. Schmidt > Register Court: HRB 151501 B, Amtsgericht Charlottenburg > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -- Phil Wise, ATS Advanced Telematic Systems GmbH Kantstrasse 162, 10623 Berlin Managing Directors: Dirk P?schl, Armin G. Schmidt Register Court: HRB 151501 B, Amtsgericht Charlottenburg -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmatsuzawa at xevo.com Fri Aug 4 11:27:49 2017 From: tmatsuzawa at xevo.com (Takashi Matsuzawa) Date: Fri, 4 Aug 2017 11:27:49 +0000 Subject: [agl-discussions] SOTA boot for minnowboard? In-Reply-To: References: , <176fcb2f-f873-8486-678f-e20d79394880@advancedtelematic.com>, , , Message-ID: Hello. By the way, though it boots successfully, there is no demo app icons on homescreen... ________________________________ From: automotive-discussions-bounces at lists.linuxfoundation.org on behalf of Takashi Matsuzawa Sent: Friday, August 4, 2017 5:23 PM To: Phil Wise; automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SOTA boot for minnowboard? Hello. After adding below to local.conf, I could generate xxx.wic file that can boot as it is. I can see boot partition grub.cfg search for "otaroot" disk, and I can see in efi/rootfs partitions, following trees among others. efi part: /boot/ostree/xxxx/ (w/ initramfs, vmlinuz) rootfs part: /ostree/yyyy/... (w/ boot.1/poky/xxxx) So, this is the expected disk geometry for sota? ________________________________ From: automotive-discussions-bounces at lists.linuxfoundation.org on behalf of Takashi Matsuzawa Sent: Friday, August 4, 2017 4:19 PM To: Phil Wise; automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SOTA boot for minnowboard? Hello Looks like following line not found for intel agl_${MACHINE}.inc file? >DISTRO_FEATURES_append = " sota" ________________________________ From: automotive-discussions-bounces at lists.linuxfoundation.org on behalf of Takashi Matsuzawa Sent: Friday, August 4, 2017 3:53 PM To: Phil Wise; automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SOTA boot for minnowboard? Hello. This is the master branch (synched today with repo init AGL-repo without branch/manifest names). And I am specifying agl-sota to aglsetup.sh and building agl-demo-platform. ________________________________ From: Phil Wise Sent: Friday, August 4, 2017 3:24 PM To: Takashi Matsuzawa; automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SOTA boot for minnowboard? Hi, OK, that's odd. Which version of AGL did you try this on? Cheers, Phil On 04.08.2017 06:20, Takashi Matsuzawa wrote: > Hello, sorry for late reply. > > I also tried this with latest master, clean build, with inte-corei7-64 > target, wic image. > The board is minnowboard turbot. > > I think I had things like /ostree or ostree=xxxx in kernel command line > before, but following is what I can see now. > (Is this normal for sota enabled build?) > > Is SOTA feature disabled now even if I specify agl-sota feature option > for the build? > (or maybe this is just with wic image and I should specify other image > type?) > > 1) EFI partition > > efi/EFI/BOOT/bootx64.efi > efi/bzImage > efi/loader/entries/boot.conf <- looks like ordinal entry, without > ostree=xxxx command line paramter. > efi/loader/loader.conf > > 2) root (platform) partition > > platform/ <- looks like ordinaly rootfs, without /ostree > > 3) booting > > I needed to add ef/startup.nsh with "bootx64.efi" in it. > Also I needed to add "console=ttyS0,115200". > Then the board boots successfully, and showing AGL demo homesreen. > > 4) image > > I examined the wic image. > > agl-demo-platform-intel-corei7-64-20170804012136.rootfs.wic: > 1231MB > Sector size (logical/physical): 512B/512B > Partition Table: gpt > > Number Start End Size File system Name Flags > 1 1049kB 25.4MB 24.4MB fat16 primary legacy_boot > 2 26.2MB 1185MB 1159MB ext4 primary > 3 1185MB 1231MB 46.1MB linux-swap(v1) primary > > > ------------------------------------------------------------------------ > *From:* automotive-discussions-bounces at lists.linuxfoundation.org > on behalf of > Phil Wise > *Sent:* Wednesday, July 19, 2017 4:40 PM > *To:* automotive-discussions at lists.linuxfoundation.org > *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? > > Hi, > > I've just done a quick test of this against AGL, and the following steps > produced a bootable image: > > . meta-agl/scripts/aglsetup.sh -m intel-corei7-64 -b build-minnowboard > agl-all-features > > bitbake agl-demo-platform > > dd > if=tmp/deploy/images/intel-corei7-64/agl-demo-platform-intel-corei7-64.wic > of=/dev/sdX bs=32M && sync > > For MinnowBoard Max (and Intel in general) there are two options for > booting. Either U-Boot -> Linux (which requires reflashing the Bios with > U-Boot) or booting EFI -> Grub -> Linux. The default in AGL is the EFI > boot, so it should work out of the box, no is reflashing required > > For testing, there also is a handy script that will run a > Intel-compatible image inside qemu: > > https://github.com/advancedtelematic/meta-updater-qemux86-64/blob/morty/scripts/run-qemu [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] advancedtelematic/meta-updater-qemux86-64 github.com Contribute to meta-updater-qemux86-64 development by creating an account on GitHub. > > [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] advancedtelematic/meta-updater-qemux86-64 github.com Contribute to meta-updater-qemux86-64 development by creating an account on GitHub. > > advancedtelematic/meta-updater-qemux86-64 > [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] advancedtelematic/meta-updater-qemux86-64 github.com Contribute to meta-updater-qemux86-64 development by creating an account on GitHub. > github.com > Contribute to meta-updater-qemux86-64 development by creating an account > on GitHub. > > > > > This should be run from your build directory, and will try and detect > the appropriate settings automatically. The following should work: > > build-minnowboard$ /path/to/run-qemu --efi agl-demo-platform > > Hope this helps, > > > Phil > > > On 14.07.2017 06:58, Takashi Matsuzawa wrote: >> Sorry for the excess messsage. >> >> >> So, the updater assumes the follwing? >> >> >> - you have /boot and cfg files in there are used for the boot >> >> - you can create symbolic links in /boot >> >> >> And when it is 2 partition media (boot and rootfs), the boot partition >> is expected to be mounted as /boot? >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Friday, July 14, 2017 1:45 PM >> *To:* Jon Oster >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hello. >> >> OK, I could boot choosing alternate root locaation (/ostree/xxxxxx) on >> my minnowboard, with grub-efi. >> >> >> However, I think sota expects that bootloader is aware of the uEnv.txt >> file for the choice of kernel, etc. to be used for boot. >> >> Or, latest is just /boot/loader -> loader.1/xxxx.conf files? >> And the updater makes loader symbokic link point to the desired loader >> configuration folder? >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Thursday, July 13, 2017 10:01 PM >> *To:* Jon Oster >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hello, thanks. >> >> Yes, I have looked into xxx.rootfs.ostree.tar.bz2 image and init.sh there. >> >> >> Maybe I should look into non-intel AGL image as a working reference >> (though you maybe booting minnowboard on u-boot on your site). >> >> I feel completely different bootlader for non-sota and sota is not a >> good idea - but intel bsp not using u-boot has reason (at least for AGL >> bsp)? >> In other words is it worthwhile to tweak grub boot here, or try u-boot >> on intel - or just put aside intel just for now (re: sota). >> >> ------------------------------------------------------------------------ >> *From:* Jon Oster >> *Sent:* Thursday, July 13, 2017 8:21 PM >> *To:* Takashi Matsuzawa >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> Ah, that's the problem: agl-sota needs a bootloader prepared for use >> with OSTree. OSTree keeps filesystem versions in a content-addressed >> object store, and allows atomic switching between versions. To do that, >> it makes a directory building out the filesystem tree via hardlinks, >> then instructs the bootloader to point to the new directory on next >> boot. It's certainly possible to support OSTree in bootloaders other >> than U-Boot, but there's some integration work required--we've only >> implemented that support in U-Boot so far. Further reading: >> >> https://github.com/advancedtelematic/meta-updater#adding-support-for-your-board [https://avatars0.githubusercontent.com/u/7944633?v=4&s=400] GitHub - advancedtelematic/meta-updater: OTA Software ... github.com This layer enables over-the-air updates (OTA) with OSTree and RVI SOTA client. OSTree is a tool for atomic full file system upgrades with rollback capability. OSTree ... >> >> https://docs.atsgarage.com/bas/comparing-fullfilesystem-update-strategies.html >> https://wiki.automotivelinux.org/subsystem/agl-sota/ostree >> >> Best, >> Jon Oster >> >> On Thu, Jul 13, 2017 at 12:49 PM, Takashi Matsuzawa > > wrote: >> >> Hello. >> >> Thank you for your comment. >> >> I just found that on master branch, my initial blocker was following >> in agl_joule.inc (I am building with -m joule to aglsetup.sh) >> >> >> > OSTREE_BOOTLOADER ?= "u-boot" >> >> >> By commenting out this (so default to grub), I could avoid build >> break related to u-boot provider is not found, etc. >> I am yet to verify it on target but when my build copletes, I will >> give a try again. >> >> Just for confirmation: >> >> - Should it be OK that I build image with -m joule and boot on >> minnowboard as well (in terms of ostree boot)? >> - There should be no difference beween joule and minnowboard as target? >> >> - I used to make SD card by mkefi-agl.sh script to have >> 2-partitioned SD card (which prepares EFI boot partition). >> Expectation here is that you just can copy xxx.hddimg to SD without >> modification? >> >> ------------------------------------------------------------------------ >> *From:* Jon Oster > > >> *Sent:* Thursday, July 13, 2017 7:33 PM >> *To:* Takashi Matsuzawa >> *Cc:* automotive-discussions at lists.linuxfoundation.org >> >> *Subject:* Re: [agl-discussions] SOTA boot for minnowboard? >> >> >> Hi Takashi, >> >> I don't have a minnowboard handy for verifying that the image >> actually boots, but I just did a build of AGL master with a slightly >> more up-to-date meta-updater, and it gave me a .hddimage suitable >> for flashing onto an SD card. Here's what I did: >> >> repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo >> >> repo sync >> cd meta-updater >> git checkout github/morty >> cd .. >> source meta-agl/scripts/aglsetup.sh -m intel-corei7-64 agl-demo agl-appfw-smack agl-sota >> bitbake agl-image-minimal >> >> $ ls -lh tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64* >> -rw-r--r-- 2 jon jon 611M Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.hddimg >> -rw-r--r-- 1 jon jon 604M Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.otaimg >> -rw-r--r-- 2 jon jon 586M Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ext4 >> -rw-r--r-- 2 jon jon 100K Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.manifest >> -rw-r--r-- 1 jon jon 148M Jul 13 12:17 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ostree.tar.bz2 >> -rw-r--r-- 2 jon jon 629M Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64-20170713083632.rootfs.wic >> lrwxrwxrwx 2 jon jon 60 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.ext4 -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ext4 >> lrwxrwxrwx 2 jon jon 55 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.hddimg -> agl-image-minimal-intel-corei7-64-20170713083632.hddimg >> lrwxrwxrwx 2 jon jon 64 Jul 13 12:16 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.manifest -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.manifest >> lrwxrwxrwx 1 jon jon 70 Jul 13 12:17 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.rootfs.ostree.tar.bz2 -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.ostree.tar.bz2 >> lrwxrwxrwx 2 jon jon 59 Jul 13 12:18 tmp/deploy/images/intel-corei7-64/agl-image-minimal-intel-corei7-64.wic -> agl-image-minimal-intel-corei7-64-20170713083632.rootfs.wic >> >> Best, >> Jon Oster >> >> On Wed, Jul 12, 2017 at 11:44 PM, Takashi Matsuzawa >> > wrote: >> >> Hello. >> >> And on master (DD) is it being fixed soon? >> >> (Can be built and do OTA for supported boards is the bar for DD >> release or it is not?) >> >> >> ------------------------------------------------------------------------ >> *From:* Takashi Matsuzawa >> *Sent:* Wednesday, July 12, 2017 7:04 PM >> *To:* automotive-discussions at lists.linuxfoundation.org >> >> *Subject:* SOTA boot for minnowboard? >> >> >> Hello. >> >> I played with this today, and found sota build is broken on >> master (DD). >> >> So, I tried CC build, using x64 (MinnowBoard) target. >> >> >> I am confused at its final stage. >> >> Looks like xxxx.otaimg is just rootfs ext4 image without >> partition, I am trying to generate bootable SD card. >> >> >> Maybe it is just boot scripts (grub or systemd), is there >> already automated script for this? >> >> I just want to avoid duplicating previsous efforts. >> >> >> Also, I also looked into DD meta-updater tree, but the >> configuration seems to be different. (using u-boot, etc.) >> >> Just want to check which is the way to configure it is our plan. >> >> >> >> _______________________________________________ >> automotive-discussions mailing list >> automotive-discussions at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions >> >> >> >> >> >> >> _______________________________________________ >> automotive-discussions mailing list >> automotive-discussions at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions >> > > -- > Phil Wise, ATS Advanced Telematic Systems GmbH > Kantstrasse 162, 10623 Berlin > Managing Directors: Dirk P?schl, Armin G. Schmidt > Register Court: HRB 151501 B, Amtsgericht Charlottenburg > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -- Phil Wise, ATS Advanced Telematic Systems GmbH Kantstrasse 162, 10623 Berlin Managing Directors: Dirk P?schl, Armin G. Schmidt Register Court: HRB 151501 B, Amtsgericht Charlottenburg -------------- next part -------------- An HTML attachment was scrubbed... URL: From wminer at linuxfoundation.org Fri Aug 4 21:35:45 2017 From: wminer at linuxfoundation.org (Walt Miner) Date: Fri, 4 Aug 2017 16:35:45 -0500 Subject: [agl-discussions] This Week in AGL #4 - August 7, 2017 Message-ID: This is the fourth edition of the new weekly AGL newsletter to highlight work going on around the AGL Community. Feedback and comments welcome. wminer at linuxfoundation.org I am sending this out a little early this week because I will be on vacation for a fortnight. There will be no newsletter next week and we have canceled many of the usual meetings during this time. If you are also on vacation these two weeks, enjoy yourself. Otherwise have a productive couple of weeks and make AGL better while I am gone! Walt *Highlights* 1) Daring Dab 4.0.0 was released on Monday. Thanks to everyone who pitched in to make this happen. Thanks especially to our Release Manager, Jan-Simon Moeller, who made sure everything was in its right place. https://lists.linuxfoundation.org/pipermail/automotive-discussions/2017-July/004730.html 2) The final planned Charming Chinook release (3.0.5) is coming up at the end of next week. The merge window for any proposed patches closes on Wednesday Aug 9. 3) The CFP for the Dresden All Member Meeting closes on Monday Aug 7. 4) Toyota posted version 0.2.4 of the Window Manager architecture document on the wiki that will be reviewed by the Graphics and UI EG. https://wiki.automotivelinux.org/_media/eg-ui-graphics/170802_agl_hmi-fw_arch_0_2_4.pdf 5) AGL has passed the 100-member milestone! https://www.automotivelinux.org/announcements/2017/08/02/automotive-grade-linux-momentum-continues-with-membership-growth-unified-code-base-4-0-and-new-technical-projects *Upcoming Face-to-Face Meeting Opportunities * 1) App FW and Audio Architecture Deep Dive ? Aug 30 ? 31 in Yokohama, Japan https://wiki.automotivelinux.org/agl-distro/aug2017-f2f 2) Vehicle Messaging and CAN ? Sep 5 ? 7 in Vannes, France https://wiki.automotivelinux.org/agl-distro/sep2017-can-f2f 3) Audio Workshop ? Sep 13 ? 14 in Montreal, Canada https://wiki.automotivelinux.org/agl-distro/sep2017-audio-f2f *AGL All Member Meeting* Event web site: http://events.linuxfoundation.org/events/agl-member-meeting-fall 1) This is the final week to submit a presentation proposal. *The CFP closes on August 7.* 2) The hotel block is now available for booking. If you need to check out after Friday, please contact events at automotivelinux.org to help with arrangement. 3) There will be face-to-face System Architecture Team and Expert Group meetings on October 20. Please plan to stay for this if you are a member of these teams and add your name to attendee list on the wiki. https://wiki.automotivelinux.org/agl-distro/oct2017-f2f 4) Look for announcements next week about training classes to be held on Friday, October 20. *Meetings during the next two weeks:* *Monday Aug 7* 13:00 UTC ? Graphics and UI Expert Group Conference Info: https://wiki.automotivelinux.org/eg-ui-graphics#weekly_call *Tuesday Aug 8* 13:00 UTC - Weekly developer call Open to anyone with questions about AGL code or issues they may be having. Conference Info: *https://wiki.automotivelinux.org/dev-call-info * *Thursday Aug 10* 13:00 UTC ? Connectivity Expert Group Conference Info: https://wiki.automotivelinux.org/eg-connectivity/meetings *Tuesday Aug 15* 12:00 pm UTC - Continuous Integration and Test Expert Group. Details at https://wiki.automotivelinux.org/eg-ciat/meetings The full AGL calendar can always be found at *https://calendar.google.com/calendar/embed?src=linuxfoundation.org_i0rs8amkm0flde7kq5u4b9tef4%40group.calendar.google.com * -- Walt Miner Engineering Project Manager The Linux Foundation mobile: +1.847.502.7087 Visit us at: automotive.linuxfoundation.org www.linuxfoundation.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmatsuzawa at xevo.com Sat Aug 5 02:27:54 2017 From: tmatsuzawa at xevo.com (Takashi Matsuzawa) Date: Sat, 5 Aug 2017 02:27:54 +0000 Subject: [agl-discussions] inputs on qwebview? In-Reply-To: <0bea4f39-319f-92e0-f9d8-d1e4cf1d102e@advancedtelematic.com> References: , <0bea4f39-319f-92e0-f9d8-d1e4cf1d102e@advancedtelematic.com> Message-ID: Hello. Thank you for your hint on keyboard. Pinch did not work for me but it is reacting to touch. I may want to check if it has default gesture recoginizer and how it is expected to work. (I can see grabGesture method may be it can be used to register my own, but I just use what it is there as much as possible.) ________________________________ From: automotive-discussions-bounces at lists.linuxfoundation.org on behalf of Phil Wise Sent: Friday, August 4, 2017 3:03 PM To: automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] inputs on qwebview? I'm no Qt expert, but when I tried this I found: - Pinch zoom worked without any further work - Text input required extra work For our project we used an external virtual keyboard app (matchbox), and controlled it by watching the current selection: https://github.com/openivimobility/openivi-html5/blob/b55b140655030cfd10f2f8d24befb80f57c75874/webgraphicview.cc#L67 [https://avatars2.githubusercontent.com/u/14327394?v=4&s=400] openivimobility/openivi-html5 github.com openivi-html5 - An HTML5 environment for openivi QVariant r = page_->inputMethodQuery(Qt::ImSurroundingText); bool shouldDisplayKeyboard = r.isValid(); ... This is still not a complete solution, because it doesn't handle things like scrolling the viewport to keep the focused input on the screen when the keyboard pops up. (Note that this project wasn't using AGL as a base, so I'm talking about features available in Qt in general here, not AGL) Best Regards, Phil On 04.08.2017 03:52, Takashi Matsuzawa wrote: > Hello. > This maybe a Qt question, but I am playing with QWebView on my AGL > target board. > > I load a web page (say, yahoo or google map) within QWebView (or > QWebEngineView). > Then I should be able to do the following wihth modification? Or some > additional integration is needed? > > - Text inputs on web page. > - Gestures like pinch zooming. > > This is latest master branch, with touch screen also USB connected > keyboard/mouse. > > I can see A tags react to my touch operation (so that I can navigate > through the links between the web pages), and can also select texts > (they are reversed), but I do not seems to do further. > > > > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions automotive-discussions Info Page - Linux Foundation lists.linuxfoundation.org To see the collection of prior postings to the list, visit the automotive-discussions Archives. Using automotive-discussions > -- Phil Wise, ATS Advanced Telematic Systems GmbH Kantstrasse 162, 10623 Berlin Managing Directors: Dirk P?schl, Armin G. Schmidt Register Court: HRB 151501 B, Amtsgericht Charlottenburg _______________________________________________ automotive-discussions mailing list automotive-discussions at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions automotive-discussions Info Page - Linux Foundation lists.linuxfoundation.org To see the collection of prior postings to the list, visit the automotive-discussions Archives. Using automotive-discussions -------------- next part -------------- An HTML attachment was scrubbed... URL: From undefined.111001 at gmail.com Mon Aug 7 08:27:59 2017 From: undefined.111001 at gmail.com (=?UTF-8?B?0JDQvdC00YDQtdC5INCT0LDRgNCw0LXQsg==?=) Date: Mon, 7 Aug 2017 11:27:59 +0300 Subject: [agl-discussions] Wi-Fi on Raspberry Pi 3 Message-ID: Hello. I built AGL with demo interface and apps, everything's fine here. (agl-demo feature & agl-demo-platform target) But I found out Wi-Fi doesn't work. Is it known problem? It's powered on successfully. But while network is being scanned it crashes. Here's the log: Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Wifi set to > true > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Raw > response: [3,"9999",{"jtype":"afb-reply","request":{"status":"success"}}] > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: > qrc:/wifi/Wifi.qml:112: JSON.parse: Parse error > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Raw > response: [3,"9999",{"jtype":"afb-reply","request":{"status":"success"}}] > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: > qrc:/wifi/Wifi.qml:112: JSON.parse: Parse error > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Raw > response: [3,"9999",{"jtype":"afb-reply","request":{"status":"success"}}] > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: > qrc:/wifi/Wifi.qml:112: JSON.parse: Parse error > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Raw > response: [3,"9999",{"jtype":"afb-reply","request":{"status":"success"}}] > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: > qrc:/wifi/Wifi.qml:112: JSON.parse: Parse error > Jul 22 02:21:06 raspberrypi3 daemon.notice afb-daemon[913]: NOTICE: [API > wifi-manager] Power ON succeeded > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[913]: > [../../git/binding-wifi/wifi-connman.c:173,do_wifiActivate] > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Raw > response: > [3,"9999",{"response":{"activation":"on"},"jtype":"afb-reply","request":{"status":"success","info":"Wi-Fi > - Activated"}}] > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Raw > response: > [3,"9999",{"response":[],"jtype":"afb-reply","request":{"status":"success","info":"Wi-Fi > - Scan Result is Displayed"}}] > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Raw > response: > [5,"wifi-manager/networkListUpdated",{"event":"wifi-manager\/networkListUpdated","data":{"data1":1,"data2":"PropertiesChanged"},"jtype":"afb-event"}] > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Received > EVENT: wifi-manager/networkListUpdated > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Event > data:1, PropertiesChanged > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Network > List was updated, sending scan_result request > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Raw > response: > [5,"wifi-manager/networkListUpdated",{"event":"wifi-manager\/networkListUpdated","data":{"data1":1,"data2":"PropertiesChanged"},"jtype":"afb-event"}] > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Received > EVENT: wifi-manager/networkListUpdated > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Event > data:1, PropertiesChanged > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Raw > response: > [3,"9999",{"response":[],"jtype":"afb-reply","request":{"status":"success","info":"Wi-Fi > - Scan Result is Displayed"}}] > Jul 22 02:21:06 raspberrypi3 daemon.info afb-daemon[908]: qml: Raw > response: > [3,"9999",{"response":[],"jtype":"afb-reply","request":{"status":"success","info":"Wi-Fi > - Scan Result is Displayed"}}] > Jul 22 02:21:07 raspberrypi3 daemon.info afb-daemon[908]: qml: Raw > response: > [5,"wifi-manager/networkListUpdated",{"event":"wifi-manager\/networkListUpdated","data":{"data1":2,"data2":"BSSAdded"},"jtype":"afb-event"}] > Jul 22 02:21:07 raspberrypi3 daemon.info afb-daemon[908]: qml: Received > EVENT: wifi-manager/networkListUpdated > Jul 22 02:21:07 raspberrypi3 daemon.info afb-daemon[908]: qml: Event > data:2, BSSAdded > Jul 22 02:21:07 raspberrypi3 daemon.info afb-daemon[908]: qml: Network > List was updated, sending scan_result request > Jul 22 02:21:07 raspberrypi3 daemon.info afb-daemon[908]: qml: Raw > response: > [5,"wifi-manager/networkListUpdated",{"event":"wifi-manager\/networkListUpdated","data":{"data1":2,"data2":"BSSAdded"},"jtype":"afb-event"}] > Jul 22 02:21:07 raspberrypi3 daemon.info afb-daemon[908]: qml: Received > EVENT: wifi-manager/networkListUpdated > Jul 22 02:21:07 raspberrypi3 daemon.info afb-daemon[908]: qml: Event > data:2, BSSAdded > Jul 22 02:21:07 raspberrypi3 daemon.info afb-daemon[908]: qml: Network > List was updated, sending scan_result request > Jul 22 02:21:07 raspberrypi3 daemon.info afb-daemon[908]: qml: Raw > response: > [5,"wifi-manager/networkListUpdated",{"event":"wifi-manager\/networkListUpdated","data":{"data1":2,"data2":"BSSAdded"},"jtype":"afb-event"}] ............. > Jul 22 02:21:07 raspberrypi3 daemon.info afb-daemon[908]: qml: Received > EVENT: wifi-manager/networkListUpdated > Jul 22 02:21:07 raspberrypi3 daemon.info afb-daemon[908]: qml: Event > data:1, PropertiesChanged > Jul 22 02:21:07 raspberrypi3 daemon.info afb-daemon[908]: qml: Network > List was updated, sending scan_result request > Jul 22 02:21:07 raspberrypi3 daemon.warn afb-daemon[913]: WARNING: [API > wifi-manager] unhandled signal :1.9 /fi/w1/wpa_supplicant1/Interfaces/1 > fi.w1.wpa_supplicant1.Interface, ScanDone > [../../git/binding-wifi/agent.c:161,test_signal_handler] > Jul 22 02:21:07 raspberrypi3 daemon.info afb-daemon[913]: *** Error in > `/usr/bin/afb-daemon': realloc(): invalid next size: 0x75b036f8 *** > Jul 22 02:21:07 raspberrypi3 daemon.err afb-daemon[913]: ERROR: > Terminating signal 6 received: Aborted > [/usr/src/debug/af-binder/dab+gitAUTOINC+b2a1f5f40e-r0/git/src/sig-monitor.c:132,on_signal_terminate] > Jul 22 02:21:07 raspberrypi3 daemon.notice systemd[718]: > afm-service-agl-service-wifi at 1.0.service: Main process exited, > code=exited, status=1/FAILURE ............. Jul 22 02:21:07 raspberrypi3 daemon.notice systemd[718]: > afm-service-agl-service-wifi at 1.0.service: Unit entered failed state. > Jul 22 02:21:07 raspberrypi3 daemon.warn systemd[718]: > afm-service-agl-service-wifi at 1.0.service: Failed with result 'exit-code'. P.S.: I tested Wi-Fi on nogfx minimal AGL build for Raspberry Pi 3, Wi-Fi is fully working. Did it manually with connmanctl. I've started researching agl-service-wifi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fixed-term.Vamsinag.Gunti at de.bosch.com Mon Aug 7 08:46:50 2017 From: fixed-term.Vamsinag.Gunti at de.bosch.com (FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1)) Date: Mon, 7 Aug 2017 08:46:50 +0000 Subject: [agl-discussions] SDK newbie questions In-Reply-To: <6503577A-A71B-4A2B-A182-C7149A53EF1F@RADIOSOUND.com> References: <6503577A-A71B-4A2B-A182-C7149A53EF1F@RADIOSOUND.com> Message-ID: <6f31e48fa72442cf89e4959e046fb074@FE-MBX1021.de.bosch.com> Hi Dennis, A small clarification while creating the Kit in QtCreator. Where and how did you add these two environment variables? XDS_SERVER_URL=http://xds.server.url:8000 XDS_SDK_ID=poky-agl_armv7vehf_3.99.1+snapshot Did you add them in the Qtcreator itself? Thanks in advance. Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 From: Dennis Field [mailto:dennisf at RADIOSOUND.com] Sent: Thursday, August 3, 2017 6:24 PM To: FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) Cc: automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SDK newbie questions Vamsi, Check out the AGL QML hello world app I made when I had just gotten XDS up and running. https://github.com/radiosound-com/agl-hello-qml/ The Qt project was based on the hello world QML template that Qt Creator generates when you make a new Qt Quick Controls 2 application. I made a subfolder project so that the app project could live separately from the package project that AGL uses to build the wgt file (this was just so I could build on desktop and verify the AGL styled controls worked before putting it on the board) The instructions in the readme are how to set up Qt Creator in Windows to integrate with XDS (not as elegantly as I'd like, but it worked well enough for my purposes). I haven't tried it on a Linux host yet, some of the instructions may need to be adjusted. If I get a chance this week, I'll do that. If all you need to look at is the project structure, though, this is one way to set it up. Hope that helps! Sent from Bill Gates' iPhone On Aug 3, 2017, at 9:28 AM, FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > wrote: Hi, Is there any documentation available on the structure of a Qt QML application? The applications that are available in the demos seems to have a different structure as compared to the structure created by my Qt Creator. Additionally what type of a project is to be selected when creating an application on QtCreator? I chose a Qt Quick Controls Application and the structure was completely different from the demo apps and was not able to proceed any further. And could someone kindly direct me to any documentation on writing an application from scratch in qml/html5? I did refer the AppFramwork documentation. While it does give ample information on building an app and information about the configuration file, I don't seem to find any information on the app file/folder structure etc. Thanks in advance :) Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 _______________________________________________ automotive-discussions mailing list automotive-discussions at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.bollo at iot.bzh Mon Aug 7 09:09:21 2017 From: jose.bollo at iot.bzh (=?UTF-8?B?Sm9zw6k=?= Bollo) Date: Mon, 7 Aug 2017 11:09:21 +0200 Subject: [agl-discussions] Wi-Fi on Raspberry Pi 3 In-Reply-To: References: Message-ID: <20170807110921.77fb0579@d-jobol.iot.bzh> On Mon, 7 Aug 2017 11:27:59 +0300 ?????? ?????? wrote: > Hello. Hello ?????? (Andrei?), > I built AGL with demo interface and apps, everything's fine here. > (agl-demo feature & agl-demo-platform target) > But I found out Wi-Fi doesn't work. Is it known problem? First time I ear about this problem. (snip) > > Jul 22 02:21:07 raspberrypi3 daemon.warn afb-daemon[913]: WARNING: > > [API wifi-manager] unhandled > > signal :1.9 /fi/w1/wpa_supplicant1/Interfaces/1 > > fi.w1.wpa_supplicant1.Interface, ScanDone > > [../../git/binding-wifi/agent.c:161,test_signal_handler] Is it linked to the issue? I don't know. > > Jul 22 02:21:07 raspberrypi3 daemon.info afb-daemon[913]: *** Error in > > `/usr/bin/afb-daemon': realloc(): invalid next size: 0x75b036f8 *** > > Jul 22 02:21:07 raspberrypi3 daemon.err afb-daemon[913]: ERROR: > > Terminating signal 6 received: Aborted > > [/usr/src/debug/af-binder/dab+gitAUTOINC+b2a1f5f40e-r0/git/src/sig-monitor.c:132,on_signal_terminate] I note that I must include a stackdump on signal ABRT. It had helped here. > > Jul 22 02:21:07 raspberrypi3 daemon.notice systemd[718]: > > afm-service-agl-service-wifi at 1.0.service: Main process exited, > > code=exited, status=1/FAILURE (snip) > P.S.: I tested Wi-Fi on nogfx minimal AGL build for Raspberry Pi 3, > Wi-Fi is fully working. Did it manually with connmanctl. I've started > researching agl-service-wifi. That's great! I think that you are searching the right piece of code. But because there is no realloc in sources, it is probably in how are used libraries. Best regards Jos? Bollo From fixed-term.Vamsinag.Gunti at de.bosch.com Mon Aug 7 09:25:00 2017 From: fixed-term.Vamsinag.Gunti at de.bosch.com (FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1)) Date: Mon, 7 Aug 2017 09:25:00 +0000 Subject: [agl-discussions] SDK newbie questions In-Reply-To: <6503577A-A71B-4A2B-A182-C7149A53EF1F@RADIOSOUND.com> References: <6503577A-A71B-4A2B-A182-C7149A53EF1F@RADIOSOUND.com> Message-ID: <92675f5427b8488b81a6d2b81a18db8a@FE-MBX1021.de.bosch.com> Hi Dennis, Additionally, were the build steps mentioned here: https://github.com/radiosound-com/agl-hello-qml added to QtCreator? Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 From: Dennis Field [mailto:dennisf at RADIOSOUND.com] Sent: Thursday, August 3, 2017 6:24 PM To: FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) Cc: automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SDK newbie questions Vamsi, Check out the AGL QML hello world app I made when I had just gotten XDS up and running. https://github.com/radiosound-com/agl-hello-qml/ The Qt project was based on the hello world QML template that Qt Creator generates when you make a new Qt Quick Controls 2 application. I made a subfolder project so that the app project could live separately from the package project that AGL uses to build the wgt file (this was just so I could build on desktop and verify the AGL styled controls worked before putting it on the board) The instructions in the readme are how to set up Qt Creator in Windows to integrate with XDS (not as elegantly as I'd like, but it worked well enough for my purposes). I haven't tried it on a Linux host yet, some of the instructions may need to be adjusted. If I get a chance this week, I'll do that. If all you need to look at is the project structure, though, this is one way to set it up. Hope that helps! Sent from Bill Gates' iPhone On Aug 3, 2017, at 9:28 AM, FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > wrote: Hi, Is there any documentation available on the structure of a Qt QML application? The applications that are available in the demos seems to have a different structure as compared to the structure created by my Qt Creator. Additionally what type of a project is to be selected when creating an application on QtCreator? I chose a Qt Quick Controls Application and the structure was completely different from the demo apps and was not able to proceed any further. And could someone kindly direct me to any documentation on writing an application from scratch in qml/html5? I did refer the AppFramwork documentation. While it does give ample information on building an app and information about the configuration file, I don't seem to find any information on the app file/folder structure etc. Thanks in advance :) Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 _______________________________________________ automotive-discussions mailing list automotive-discussions at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -------------- next part -------------- An HTML attachment was scrubbed... URL: From fulup.arfoll at iot.bzh Mon Aug 7 11:08:42 2017 From: fulup.arfoll at iot.bzh (Fulup Ar Foll) Date: Mon, 7 Aug 2017 13:08:42 +0200 Subject: [agl-discussions] AAAA (AGL Advance Audio Agent) Architecture Message-ID: FYI, Here attached the latest version of AAAA, if you want to look at source code see Fulup-Dev branch at [1] Update since since San-Jose - ALSA-Hook-Plugin: It enforces automatically AAAA control/policy for ALSA legacy applications. You may check a sample of ALSA asound.conf[2] on how to enforce AAAA policy on legacy ALSA. To make a long story short, each time an ALSA application open a virtual channel (eg: Navigation, Emergency, ...) the HookPlugin intercept the request and sends control/policy request to AAAA through standard AGL application framework. The plugin also support basic controls that allow AAAA to notify legacy application through ALSA PCM (pause/resume+stop) - Controller binding, it was the key missing component at SantaClara. You may find the draft version of control config at [3]. Unfortunately I may not push my new version on git before the end of the week (I'm on vacation on my boat, and connectivity is not optimal). The controller config is very similar to the HOOK-PLUGIN, for each action you defined a suite of API(s) to call (eg: navigation: call Alsa/UCM(NAV), ...). Same thing for events (eg: event(reverse-engage) --> call Prevent-Telephonie-Call+Reduce 50% Multimedia Volume). Technically an action is either a call to a binding API (alsa, signaling, ...) or a callback to a custom share library. I also included a LUA interpreter to handle more dynamic cases directly from a script (eg: event(speed) --> LUA(compute-volume[speed]). - HAL, since San Jose I added an volume ramping as a sample of integration of non ALSA feature. The HAL is now working for both set/get value and provides a linear normalisation model for volume. My goal is to also provide a JSON config file to generate automatically HAL (at least for simple case) before Japan meeting. - Unicens: Tobias from Microchip made very good progress, the binding now support a low level I2C API which allow to fully control MOST network from directly from the HAL [4]. If I get enough connectivity, I will try to join this afternoon call. In worse case, I will present a Japon a RC that hopefully will address all the concerns we talk about in Santa Clara. Fulup [1] https://github.com/iotbzh/audio-bindings/tree/fulup-dev [2] https://github.com/iotbzh/audio-bindings/tree/fulup-dev/Alsa-Plugin/Alsa-Policy-Hook [3] https://github.com/iotbzh/audio-bindings/blob/fulup-dev/PolicyCtl-afb/polctl-apidef.json [4] https://github.com/iotbzh/unicens2-binding -------------- next part -------------- A non-text attachment was scrubbed... Name: AAAA-architecture.pdf Type: application/pdf Size: 36595 bytes Desc: not available URL: From tranmanphong at gmail.com Mon Aug 7 18:44:07 2017 From: tranmanphong at gmail.com (Phong Tran) Date: Mon, 7 Aug 2017 20:44:07 +0200 Subject: [agl-discussions] SDL layers In-Reply-To: References: Message-ID: <3d2a113b-5ccc-9f80-799e-4f0cd6344597@gmail.com> Hi Matsuzawa-san, On 08/04/2017 02:46 AM, Takashi Matsuzawa wrote: > Hello. > For better tracking, I created following ticket so can yo kindly update > your review to include "Bug-AGL: SPEC-805" keyword. > > https://jira.automotivelinux.org/browse/SPEC-805 > > I may ask general question about this meta layer, from personal interest. > Is there any plan to upstream this (or is there upstream for it?) > The sdl_core recipe is developed from scratch. log4cxx & bluez-tools recipes are re-used (geting from other layer meta-ros [1] and meta-arago-extras [2]). > https://github.com/smartdevicelink/ (the sdl community) may not > necessarily be responsible to provide meta layer by itself, but is there > any plan to do so? > AFAIK, there is a sdl_core branch for support AGL cross compiling [3] but I don't know will they support for recipe or not? [1] http://layers.openembedded.org/layerindex/recipe/2964/ [2] https://layers.openembedded.org/layerindex/recipe/9989/ [3] https://github.com/smartdevicelink/sdl_core/commits/feature/agl_port Regards, Phong. From mkelly at xevo.com Wed Aug 9 00:37:47 2017 From: mkelly at xevo.com (Martin Kelly) Date: Tue, 8 Aug 2017 17:37:47 -0700 Subject: [agl-discussions] Kernel console boot settings Message-ID: <1faf0f6b-6111-b000-8c38-ebeeaeade968@xevo.com> Hi all, Today I tried booting the Minnowboard Turbot and noticed that, by default, we end up with the following kernel boot command-line: options root=PARTUUID=bbd9488d-02 console=ttyS2,115200n8 video=efifb maxcpus=4 noxsave reboot=efi kmemleak=off rootwait console=ttyS0,115200 console=tty0 Note we have three different console= settings! For the Minnowboard Turbot, the correct setting is the second one, console=ttyS0,115200. I see that in meta-agl-bsp, we have conf/include/agl_joule.inc with this line: APPEND += "console=ttyS2,115200n8 video=efifb maxcpus=4 noxsave reboot=efi kmemleak=off" This is probably correct for the Joule but wrong for the Turbot. Additionally, there are two other erroneous console settings being thrown in by various other scripts I presume. I believe the active entry is just whichever one ends up being last. There must be a better way to do this. It seems to me we should: - Create a separate build target for the Turbot that inherits from some common Intel code (Joule and Turbot would still use the same settings for other cmdline args like kmemleak=off) but changes the console setting. - Figure out where the other console= settings are coming from and eliminate them, retesting other boards in the process. I haven't yet grepped through the bitbake code to determine the source of all of it. Anyone else have ideas about how to handle this in a less error-prone way? Thanks, Martin From jsmoeller at linuxfoundation.org Wed Aug 9 07:19:02 2017 From: jsmoeller at linuxfoundation.org (Jan-Simon Moeller) Date: Wed, 09 Aug 2017 07:19:02 +0000 Subject: [agl-discussions] Einladung: Join Fuego/AGL CIAT call (one-time reschedule) - Mo 14. Aug. 2017 14:00 - 14:50 (MESZ) (automotive-discussions@lists.linuxfoundation.org) Message-ID: <001a11405474f6953c05564ce42d@google.com> Sie wurden f?r den folgenden Termin eingeladen. Titel: Join Fuego/AGL CIAT call (one-time reschedule) EG CIAT bi-weekly call Please join my meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/997304269 You can also dial in using your phone. United States (Toll Free): 1 877 568 4106 United States: +1 (571) 317-3129 Access Code: 997-304-269 More phone numbers France (Toll Free): 0 805 541 047 France: +33 170 950 594 Germany (Toll Free): 0 800 723 5270 Germany: +49 692 5736 7210 First GoToMeeting? Try a test session: https://care.citrixonline.com/g2m/getready Wann: Mo 14. Aug. 2017 14:00 ? 14:50 Berlin Wo: https://global.gotomeeting.com/join/997304269 Kalender: automotive-discussions at lists.linuxfoundation.org Wer * Jan-Simon Moeller - Organisator * tim.bird at sony.com * automotive-discussions at lists.linuxfoundation.org * fuego at lists.linuxfoundation.org Termininformationen: https://www.google.com/calendar/event?action=VIEW&eid=MmltODFwYnU5NXZtdTlqNTg4Z2FlODNkZzggYXV0b21vdGl2ZS1kaXNjdXNzaW9uc0BsaXN0cy5saW51eGZvdW5kYXRpb24ub3Jn&tok=MjkjanNtb2VsbGVyQGxpbnV4Zm91bmRhdGlvbi5vcmcwYTZkYzliMjhmODI2OGFlNjZlNDA2OTUzNTNjYzg1YWU3MzM2ZjM1&ctz=Europe/Berlin&hl=de Einladung von Google Kalender: https://www.google.com/calendar/ Sie erhalten diese E-Mail unter automotive-discussions at lists.linuxfoundation.org, da Sie ein Gast bei diesem Termin sind. Lehnen Sie diesen Termin ab, um keine weiteren Informationen zu diesem Termin zu erhalten. Sie k?nnen auch unter https://www.google.com/calendar/ ein Google-Konto erstellen und Ihre Benachrichtigungseinstellungen f?r Ihren gesamten Kalender steuern. Wenn Sie diese Einladung weiterleiten, kann jeder Empf?nger Ihre Antwort auf die Einladung ?ndern. Weitere Informationen finden Sie unter https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2112 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2154 bytes Desc: not available URL: From jsmoeller at linuxfoundation.org Wed Aug 9 07:22:33 2017 From: jsmoeller at linuxfoundation.org (Jan-Simon =?ISO-8859-1?Q?M=F6ller?=) Date: Wed, 09 Aug 2017 09:22:33 +0200 Subject: [agl-discussions] Kernel console boot settings In-Reply-To: <1faf0f6b-6111-b000-8c38-ebeeaeade968@xevo.com> References: <1faf0f6b-6111-b000-8c38-ebeeaeade968@xevo.com> Message-ID: <7757907.KQl8xOdvHq@elrond> Hi Martin, AFAIK the console= kernel boot settings are additive. Thus although console=ttyS2,115200n8 comes from the joule - and we should not see it for the minnow - it does not hurt. The console=tty0 is the hdmi display, btw. Best, Jan-Simon Am Mittwoch, 9. August 2017, 02:37:47 CEST schrieb Martin Kelly: > Hi all, > > Today I tried booting the Minnowboard Turbot and noticed that, by > default, we end up with the following kernel boot command-line: > > options root=PARTUUID=bbd9488d-02 console=ttyS2,115200n8 video=efifb > maxcpus=4 noxsave reboot=efi kmemleak=off rootwait console=ttyS0,115200 > console=tty0 > > Note we have three different console= settings! For the Minnowboard > Turbot, the correct setting is the second one, console=ttyS0,115200. I > see that in meta-agl-bsp, we have conf/include/agl_joule.inc with this line: > > APPEND += "console=ttyS2,115200n8 video=efifb maxcpus=4 noxsave > reboot=efi kmemleak=off" > > This is probably correct for the Joule but wrong for the Turbot. > Additionally, there are two other erroneous console settings being > thrown in by various other scripts I presume. I believe the active entry > is just whichever one ends up being last. > > There must be a better way to do this. It seems to me we should: > > - Create a separate build target for the Turbot that inherits from some > common Intel code (Joule and Turbot would still use the same settings > for other cmdline args like kmemleak=off) but changes the console setting. > > - Figure out where the other console= settings are coming from and > eliminate them, retesting other boards in the process. I haven't yet > grepped through the bitbake code to determine the source of all of it. > > Anyone else have ideas about how to handle this in a less error-prone way? > > Thanks, > Martin From fixed-term.Vamsinag.Gunti at de.bosch.com Wed Aug 9 07:58:34 2017 From: fixed-term.Vamsinag.Gunti at de.bosch.com (FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1)) Date: Wed, 9 Aug 2017 07:58:34 +0000 Subject: [agl-discussions] SDK newbie questions References: <6503577A-A71B-4A2B-A182-C7149A53EF1F@RADIOSOUND.com> Message-ID: <23deae015d8b4826912fef62d5032444@FE-MBX1021.de.bosch.com> Hi Dennis, I managed to get it working. And as you suggested, the app does not show up once it is started. But it is interesting to note that even if the app is started, we do not find it in the list of running apps. And there is no log of what happened to the app that started. Have any of you or anyone at AGL, seen this behavior before? I have attached a snapshot of it for your reference. Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 From: FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) Sent: Monday, August 7, 2017 11:25 AM To: 'Dennis Field' Cc: automotive-discussions at lists.linuxfoundation.org Subject: RE: [agl-discussions] SDK newbie questions Hi Dennis, Additionally, were the build steps mentioned here: https://github.com/radiosound-com/agl-hello-qml added to QtCreator? Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 From: Dennis Field [mailto:dennisf at RADIOSOUND.com] Sent: Thursday, August 3, 2017 6:24 PM To: FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > Cc: automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SDK newbie questions Vamsi, Check out the AGL QML hello world app I made when I had just gotten XDS up and running. https://github.com/radiosound-com/agl-hello-qml/ The Qt project was based on the hello world QML template that Qt Creator generates when you make a new Qt Quick Controls 2 application. I made a subfolder project so that the app project could live separately from the package project that AGL uses to build the wgt file (this was just so I could build on desktop and verify the AGL styled controls worked before putting it on the board) The instructions in the readme are how to set up Qt Creator in Windows to integrate with XDS (not as elegantly as I'd like, but it worked well enough for my purposes). I haven't tried it on a Linux host yet, some of the instructions may need to be adjusted. If I get a chance this week, I'll do that. If all you need to look at is the project structure, though, this is one way to set it up. Hope that helps! Sent from Bill Gates' iPhone On Aug 3, 2017, at 9:28 AM, FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > wrote: Hi, Is there any documentation available on the structure of a Qt QML application? The applications that are available in the demos seems to have a different structure as compared to the structure created by my Qt Creator. Additionally what type of a project is to be selected when creating an application on QtCreator? I chose a Qt Quick Controls Application and the structure was completely different from the demo apps and was not able to proceed any further. And could someone kindly direct me to any documentation on writing an application from scratch in qml/html5? I did refer the AppFramwork documentation. While it does give ample information on building an app and information about the configuration file, I don't seem to find any information on the app file/folder structure etc. Thanks in advance :) Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 _______________________________________________ automotive-discussions mailing list automotive-discussions at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2017-08-09 09-50-24.png Type: image/png Size: 11548 bytes Desc: Screenshot from 2017-08-09 09-50-24.png URL: From sebastien.douheret at iot.bzh Wed Aug 9 08:40:30 2017 From: sebastien.douheret at iot.bzh (Sebastien Douheret) Date: Wed, 9 Aug 2017 10:40:30 +0200 Subject: [agl-discussions] SDK newbie questions In-Reply-To: <23deae015d8b4826912fef62d5032444@FE-MBX1021.de.bosch.com> References: <6503577A-A71B-4A2B-A182-C7149A53EF1F@RADIOSOUND.com> <23deae015d8b4826912fef62d5032444@FE-MBX1021.de.bosch.com> Message-ID: <857f399a-04bb-5430-b8e1-da4892db4305@iot.bzh> Hello Vamsinag, Did you have look to systemd log to get more info about why your app fails to start ? Before executing "afm-util start ..." command, just open another terminal on the target and execute "journalctl -f" Anyway, do you successfully build your app using XDS ? I'm sorry to not answered you previous emails but I only read message you sent this morning. I'm developing XDS, so I'll be happy to help you if you have some trouble to use it and any feedback about XDS is also welcome. Best Regards, Seb. On 09/08/2017 09:58, FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) wrote: > > Hi Dennis, > > I managed to get it working. And as you suggested, the app does not > show up once it is started. But it is interesting to note that even if > the app is started, we do not find it in the list of running apps. And > there is no log of what happened to the app that started. > > Have any of you or anyone at AGL, seen this behavior before? I have > attached a snapshot of it for your reference. > > Mit freundlichen Gr??en / Best regards > > *Vamsinag Gunti > CDG-SMT/ESM1 > * > Mobil +49 17623350414 > > *From:* FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > *Sent:* Monday, August 7, 2017 11:25 AM > *To:* 'Dennis Field' > *Cc:* automotive-discussions at lists.linuxfoundation.org > *Subject:* RE: [agl-discussions] SDK newbie questions > > Hi Dennis, > > Additionally, were the build steps mentioned here: > https://github.com/radiosound-com/agl-hello-qml added to QtCreator? > > Mit freundlichen Gr??en / Best regards > > *Vamsinag Gunti > CDG-SMT/ESM1 > * > Mobil +49 17623350414 > > *From:* Dennis Field [mailto:dennisf at RADIOSOUND.com] > *Sent:* Thursday, August 3, 2017 6:24 PM > *To:* FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > > > *Cc:* automotive-discussions at lists.linuxfoundation.org > > *Subject:* Re: [agl-discussions] SDK newbie questions > > Vamsi, > > Check out the AGL QML hello world app I made when I had just gotten > XDS up and running. > > https://github.com/radiosound-com/agl-hello-qml/ > > > The Qt project was based on the hello world QML template that Qt > Creator generates when you make a new Qt Quick Controls 2 application. > I made a subfolder project so that the app project could live > separately from the package project that AGL uses to build the wgt > file (this was just so I could build on desktop and verify the AGL > styled controls worked before putting it on the board) > > The instructions in the readme are how to set up Qt Creator in Windows > to integrate with XDS (not as elegantly as I'd like, but it worked > well enough for my purposes). I haven't tried it on a Linux host yet, > some of the instructions may need to be adjusted. If I get a chance > this week, I'll do that. > > If all you need to look at is the project structure, though, this is > one way to set it up. > > Hope that helps! > > Sent from Bill Gates' iPhone > > > On Aug 3, 2017, at 9:28 AM, FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > > wrote: > > Hi, > > Is there any documentation available on the structure of a Qt QML > application? The applications that are available in the demos > seems to have a different structure as compared to the structure > created by my Qt Creator. > > Additionally what type of a project is to be selected when > creating an application on QtCreator? I chose a Qt Quick Controls > Application and the structure was completely different from the > demo apps and was not able to proceed any further. > > And could someone kindly direct me to any documentation on writing > an application from scratch in qml/html5? I did refer the > AppFramwork documentation. While it does give ample information on > building an app and information about the configuration file, I > don?t seem to find any information on the app file/folder > structure etc. > > Thanks in advance J > > Mit freundlichen Gr??en / Best regards > > *Vamsinag Gunti > CDG-SMT/ESM1 > * > Mobil +49 17623350414 > > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions > > > > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -- sebastien.douheret at iot.bzh - www.iot.bzh - Mobile +33 602 326 355 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fixed-term.Vamsinag.Gunti at de.bosch.com Wed Aug 9 09:29:33 2017 From: fixed-term.Vamsinag.Gunti at de.bosch.com (FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1)) Date: Wed, 9 Aug 2017 09:29:33 +0000 Subject: [agl-discussions] SDK newbie questions In-Reply-To: <857f399a-04bb-5430-b8e1-da4892db4305@iot.bzh> References: <6503577A-A71B-4A2B-A182-C7149A53EF1F@RADIOSOUND.com> <23deae015d8b4826912fef62d5032444@FE-MBX1021.de.bosch.com> <857f399a-04bb-5430-b8e1-da4892db4305@iot.bzh> Message-ID: <8ff78e8023724eb5a40b268d0508db5e@FE-MBX1021.de.bosch.com> Hi Sebastian, I just checked and the problem is because of an invalid binding path. Attached the screen shot of the same. Can you please guide me to some documentation that helps me understand the error and try to resolve it? Regarding XDS, I was able to build the app on command line and configure it to work with Qt Creator. Although this came at the cost. I was able to build and test the app only on the target but was not able to see how the app looked on the desktop. Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 From: Sebastien Douheret [mailto:sebastien.douheret at iot.bzh] Sent: Wednesday, August 9, 2017 10:41 AM To: FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) ; Dennis Field Cc: automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SDK newbie questions Hello Vamsinag, Did you have look to systemd log to get more info about why your app fails to start ? Before executing "afm-util start ..." command, just open another terminal on the target and execute "journalctl -f" Anyway, do you successfully build your app using XDS ? I'm sorry to not answered you previous emails but I only read message you sent this morning. I'm developing XDS, so I'll be happy to help you if you have some trouble to use it and any feedback about XDS is also welcome. Best Regards, Seb. On 09/08/2017 09:58, FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) wrote: Hi Dennis, I managed to get it working. And as you suggested, the app does not show up once it is started. But it is interesting to note that even if the app is started, we do not find it in the list of running apps. And there is no log of what happened to the app that started. Have any of you or anyone at AGL, seen this behavior before? I have attached a snapshot of it for your reference. Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 From: FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) Sent: Monday, August 7, 2017 11:25 AM To: 'Dennis Field' Cc: automotive-discussions at lists.linuxfoundation.org Subject: RE: [agl-discussions] SDK newbie questions Hi Dennis, Additionally, were the build steps mentioned here: https://github.com/radiosound-com/agl-hello-qml added to QtCreator? Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 From: Dennis Field [mailto:dennisf at RADIOSOUND.com] Sent: Thursday, August 3, 2017 6:24 PM To: FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > Cc: automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] SDK newbie questions Vamsi, Check out the AGL QML hello world app I made when I had just gotten XDS up and running. https://github.com/radiosound-com/agl-hello-qml/ The Qt project was based on the hello world QML template that Qt Creator generates when you make a new Qt Quick Controls 2 application. I made a subfolder project so that the app project could live separately from the package project that AGL uses to build the wgt file (this was just so I could build on desktop and verify the AGL styled controls worked before putting it on the board) The instructions in the readme are how to set up Qt Creator in Windows to integrate with XDS (not as elegantly as I'd like, but it worked well enough for my purposes). I haven't tried it on a Linux host yet, some of the instructions may need to be adjusted. If I get a chance this week, I'll do that. If all you need to look at is the project structure, though, this is one way to set it up. Hope that helps! Sent from Bill Gates' iPhone On Aug 3, 2017, at 9:28 AM, FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > wrote: Hi, Is there any documentation available on the structure of a Qt QML application? The applications that are available in the demos seems to have a different structure as compared to the structure created by my Qt Creator. Additionally what type of a project is to be selected when creating an application on QtCreator? I chose a Qt Quick Controls Application and the structure was completely different from the demo apps and was not able to proceed any further. And could someone kindly direct me to any documentation on writing an application from scratch in qml/html5? I did refer the AppFramwork documentation. While it does give ample information on building an app and information about the configuration file, I don't seem to find any information on the app file/folder structure etc. Thanks in advance :) Mit freundlichen Gr??en / Best regards Vamsinag Gunti CDG-SMT/ESM1 Mobil +49 17623350414 _______________________________________________ automotive-discussions mailing list automotive-discussions at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions _______________________________________________ automotive-discussions mailing list automotive-discussions at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -- sebastien.douheret at iot.bzh - www.iot.bzh - Mobile +33 602 326 355 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2017-08-09 11-01-10.png Type: image/png Size: 37817 bytes Desc: Screenshot from 2017-08-09 11-01-10.png URL: From jose.bollo at iot.bzh Wed Aug 9 10:10:01 2017 From: jose.bollo at iot.bzh (=?UTF-8?B?Sm9zw6k=?= Bollo) Date: Wed, 9 Aug 2017 12:10:01 +0200 Subject: [agl-discussions] SDK newbie questions In-Reply-To: <8ff78e8023724eb5a40b268d0508db5e@FE-MBX1021.de.bosch.com> References: <6503577A-A71B-4A2B-A182-C7149A53EF1F@RADIOSOUND.com> <23deae015d8b4826912fef62d5032444@FE-MBX1021.de.bosch.com> <857f399a-04bb-5430-b8e1-da4892db4305@iot.bzh> <8ff78e8023724eb5a40b268d0508db5e@FE-MBX1021.de.bosch.com> Message-ID: <20170809121001.3a3f2db7@d-jobol.iot.bzh> On Wed, 9 Aug 2017 09:29:33 +0000 "FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1)" wrote: > Hi Sebastian, > > I just checked and the problem is because of an invalid binding path. > Attached the screen shot of the same. Can you please guide me to some > documentation that helps me understand the error and try to resolve > it? Hi Vamsi, From the image I can say that you are using CC (charming chinook) or an other build that might not be compatible with recent developpement. We are all focused today on DD (Daring Dab) [1]. IIRC Sebastian started its development of XDS using CC and its framework organisation. But he switched 2 month ago. I recommend, if possible, to switch too. With DD I fixed a bug in error messages that was always "Inappropriate ioctl for device". Not of much help. Best regards Jos? [1] https://download.automotivelinux.org/AGL/release/dab/4.0.0 > Regarding XDS, I was able to build the app on command line and > configure it to work with Qt Creator. Although this came at the cost. > I was able to build and test the app only on the target but was not > able to see how the app looked on the desktop. > Mit freundlichen Gr??en / Best regards > > Vamsinag Gunti > CDG-SMT/ESM1 > > Mobil +49 17623350414 > From: Sebastien Douheret [mailto:sebastien.douheret at iot.bzh] > Sent: Wednesday, August 9, 2017 10:41 AM > To: FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > ; Dennis Field > Cc: > automotive-discussions at lists.linuxfoundation.org Subject: Re: > [agl-discussions] SDK newbie questions > > > Hello Vamsinag, > > Did you have look to systemd log to get more info about why your app > fails to start ? Before executing "afm-util start ..." command, just > open another terminal on the target and execute "journalctl -f" > Anyway, do you successfully build your app using XDS ? I'm sorry to > not answered you previous emails but I only read message you sent > this morning. I'm developing XDS, so I'll be happy to help you if you > have some trouble to use it and any feedback about XDS is also > welcome. > > Best Regards, > Seb. > > On 09/08/2017 09:58, FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) wrote: > Hi Dennis, > > I managed to get it working. And as you suggested, the app does not > show up once it is started. But it is interesting to note that even > if the app is started, we do not find it in the list of running apps. > And there is no log of what happened to the app that started. > > Have any of you or anyone at AGL, seen this behavior before? I have > attached a snapshot of it for your reference. > > > Mit freundlichen Gr??en / Best regards > > Vamsinag Gunti > CDG-SMT/ESM1 > > Mobil +49 17623350414 > From: FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > Sent: Monday, August 7, 2017 11:25 AM > To: 'Dennis Field' > Cc: > automotive-discussions at lists.linuxfoundation.org > Subject: RE: [agl-discussions] SDK newbie questions > > Hi Dennis, > > Additionally, were the build steps mentioned here: > https://github.com/radiosound-com/agl-hello-qml added to QtCreator? > > > Mit freundlichen Gr??en / Best regards > > Vamsinag Gunti > CDG-SMT/ESM1 > > Mobil +49 17623350414 > From: Dennis Field [mailto:dennisf at RADIOSOUND.com] > Sent: Thursday, August 3, 2017 6:24 PM > To: FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > > > Cc: > automotive-discussions at lists.linuxfoundation.org > Subject: Re: [agl-discussions] SDK newbie questions > > Vamsi, > > Check out the AGL QML hello world app I made when I had just gotten > XDS up and running. > > https://github.com/radiosound-com/agl-hello-qml/ > > The Qt project was based on the hello world QML template that Qt > Creator generates when you make a new Qt Quick Controls 2 > application. I made a subfolder project so that the app project could > live separately from the package project that AGL uses to build the > wgt file (this was just so I could build on desktop and verify the > AGL styled controls worked before putting it on the board) > > The instructions in the readme are how to set up Qt Creator in > Windows to integrate with XDS (not as elegantly as I'd like, but it > worked well enough for my purposes). I haven't tried it on a Linux > host yet, some of the instructions may need to be adjusted. If I get > a chance this week, I'll do that. > > If all you need to look at is the project structure, though, this is > one way to set it up. > > Hope that helps! > Sent from Bill Gates' iPhone > > On Aug 3, 2017, at 9:28 AM, FIXED-TERM Gunti Vamsinag (CDG-SMT/ESM1) > > > wrote: Hi, > > Is there any documentation available on the structure of a Qt QML > application? The applications that are available in the demos seems > to have a different structure as compared to the structure created by > my Qt Creator. > > Additionally what type of a project is to be selected when creating > an application on QtCreator? I chose a Qt Quick Controls Application > and the structure was completely different from the demo apps and was > not able to proceed any further. > > And could someone kindly direct me to any documentation on writing an > application from scratch in qml/html5? I did refer the AppFramwork > documentation. While it does give ample information on building an > app and information about the configuration file, I don't seem to > find any information on the app file/folder structure etc. > > Thanks in advance :) > > Mit freundlichen Gr??en / Best regards > > Vamsinag Gunti > CDG-SMT/ESM1 > > Mobil +49 17623350414 > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions > > > > > _______________________________________________ > > automotive-discussions mailing list > > automotive-discussions at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions > > > > -- > > sebastien.douheret at iot.bzh - > www.iot.bzh - Mobile +33 602 326 355 From dominig.arfoll at fridu.net Wed Aug 9 13:34:36 2017 From: dominig.arfoll at fridu.net (Dominig Ar Foll) Date: Wed, 9 Aug 2017 15:34:36 +0200 Subject: [agl-discussions] Kernel console boot settings In-Reply-To: <1faf0f6b-6111-b000-8c38-ebeeaeade968@xevo.com> References: <1faf0f6b-6111-b000-8c38-ebeeaeade968@xevo.com> Message-ID: Martin, that look like someone who has used the joule setting not the one listed in the documentation for Minnow. the correct option in the source statement is "-m intel-corei7-64". More details at http://docs.automotivelinux.org/docs/getting_started/en/dev/reference/machines/intel.html Joule and Turbo do not (yet) share the same configuration because the kernel are different. Hoping to resolve that after the move to Pyro and unification on kernel 4.9. Regards Dominig 2017-08-09 2:37 GMT+02:00 Martin Kelly : > Hi all, > > Today I tried booting the Minnowboard Turbot and noticed that, by default, > we end up with the following kernel boot command-line: > > options root=PARTUUID=bbd9488d-02 console=ttyS2,115200n8 video=efifb > maxcpus=4 noxsave reboot=efi kmemleak=off rootwait console=ttyS0,115200 > console=tty0 > > Note we have three different console= settings! For the Minnowboard Turbot, > the correct setting is the second one, console=ttyS0,115200. I see that in > meta-agl-bsp, we have conf/include/agl_joule.inc with this line: > > APPEND += "console=ttyS2,115200n8 video=efifb maxcpus=4 noxsave reboot=efi > kmemleak=off" > > This is probably correct for the Joule but wrong for the Turbot. > Additionally, there are two other erroneous console settings being thrown in > by various other scripts I presume. I believe the active entry is just > whichever one ends up being last. > > There must be a better way to do this. It seems to me we should: > > - Create a separate build target for the Turbot that inherits from some > common Intel code (Joule and Turbot would still use the same settings for > other cmdline args like kmemleak=off) but changes the console setting. > > - Figure out where the other console= settings are coming from and eliminate > them, retesting other boards in the process. I haven't yet grepped through > the bitbake code to determine the source of all of it. > > Anyone else have ideas about how to handle this in a less error-prone way? > > Thanks, > Martin -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre From manuvivek at tataelxsi.co.in Wed Aug 9 14:33:26 2017 From: manuvivek at tataelxsi.co.in (manuvivek) Date: Wed, 9 Aug 2017 20:03:26 +0530 Subject: [agl-discussions] M3 Starter Kit AGL 4.0 Build - Qt application failure in IVI Shell Message-ID: Hi all, Below explains the steps followed for R-Car M3 Starter kit AGL build . _Step1 : _ $ repo init -b dab -m dab_4.0.0.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo $ repo sync _Step2 :_ $ source meta-agl/scripts/aglsetup.sh -h From the list of supported board m3ulcb was there. Downloaded R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20170427.zip and R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20170427.zip in Downloads folder _Step3 :_ $ source meta-agl/scripts/aglsetup.sh -m m3ulcb agl-demo agl-netboot agl-appfw-smack _Step4 :_ $ bitbake agl-demo-platform I was able to bring up m3ulcb board with AGL and tested with weston, Qt applications in desktop shell. QT webkitwidget application were working fine, at the same time QT webkitqml applications were flickering. I modified the weston.ini file to run QT webkitqml/webkitwidget applications in IVI Shell. I was able to create layer using Layermanagement and checked the created layer ID also. But while running the application in IVI Shell the result was failure for both webkitqml/webkitwidget applications. _PFB the error log_ root at m3ulcb:~/ICView# ./ICView -layerid 1000 Using Wayland-EGL libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile libpng warning: iCCP: known incorrect sRGB profile Failed to load s[ 1705.003001] audit: type=1701 audit(1502196979.837:6): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=System pid=5774 comm="ICView" exe="/home/root/ICView/ICView" sig=6 hell integration Could not create a shell surface object. Aborted (core dumped) -- Tata Elxsi Signature Best Regards Manu Vivek TATA ELXSI Technopark Campus KariyavattomTrivandrum 695 581India Tel +91 802297 9209Cell +91 949529 4721 _www.tataelxsi.com _ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkelly at xevo.com Wed Aug 9 16:14:50 2017 From: mkelly at xevo.com (Martin Kelly) Date: Wed, 9 Aug 2017 09:14:50 -0700 Subject: [agl-discussions] Kernel console boot settings In-Reply-To: <7757907.KQl8xOdvHq@elrond> References: <1faf0f6b-6111-b000-8c38-ebeeaeade968@xevo.com> <7757907.KQl8xOdvHq@elrond> Message-ID: <10999a59-81c8-df3f-8d81-6629d803a2f4@xevo.com> On 08/09/2017 12:22 AM, Jan-Simon M?ller wrote: > Hi Martin, > > AFAIK the console= kernel boot settings are additive. > Thus although console=ttyS2,115200n8 comes from the joule - and we should not > see it for the minnow - it does not hurt. > The console=tty0 is the hdmi display, btw. > > Best, > Jan-Simon > It seems like the situation is a bit more nuanced than this. According to: http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/configure-kernel.html specifying multiple console= referring to different devices does not work. This agrees with my observations that I see no output on the Minnowboard Turbot using the default console settings, while if I remove all but one console= setting (ttyS2, the one I listed), then it works just fine. IMO, we should have exactly one console= setting for every board, rather than appending to an existing console. In other words, we should have something like: - Each recipe sets CONSOLE_SETTING= - The recipe that generates the boot cmdline generates it via: BOOT_CMDLINE="root= ro ... ${CONSOLE_SETTING}" Note the variable names are entirely made-up, but you can probably see what I mean. An approach like this is going to be much more reliable than appending console= setting from multiple recipes. From mkelly at xevo.com Wed Aug 9 16:15:27 2017 From: mkelly at xevo.com (Martin Kelly) Date: Wed, 9 Aug 2017 09:15:27 -0700 Subject: [agl-discussions] Kernel console boot settings In-Reply-To: References: <1faf0f6b-6111-b000-8c38-ebeeaeade968@xevo.com> Message-ID: <1c1a9e3e-c8ce-989a-e327-7268300f8d26@xevo.com> On 08/09/2017 06:34 AM, Dominig Ar Foll wrote: > Martin, > > that look like someone who has used the joule setting not the one > listed in the documentation for Minnow. > the correct option in the source statement is "-m intel-corei7-64". > More details at > http://docs.automotivelinux.org/docs/getting_started/en/dev/reference/machines/intel.html > > Joule and Turbo do not (yet) share the same configuration because the > kernel are different. Hoping to resolve that after the move to Pyro > and unification on kernel 4.9. > > Regards > > Dominig > I tried both methods (Joule and corei7) but both hit the same issue and did not boot. They both also had the same console issues. From jsmoeller at linuxfoundation.org Thu Aug 10 08:34:56 2017 From: jsmoeller at linuxfoundation.org (jsmoeller at linuxfoundation.org) Date: Thu, 10 Aug 2017 08:34:56 +0000 Subject: [agl-discussions] Termin gestrichen: EG-CIAT Biweekly Call - Di 15. Aug. 2017 14:00 - 15:00 (MESZ) (automotive-discussions@lists.linuxfoundation.org) Message-ID: <94eb2c0d93c2411ba3055662128b@google.com> Dieser Termin wurde gestrichen und aus Ihrem Kalender entfernt. Titel: EG-CIAT Biweekly Call Please join my meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/997304269 You can also dial in using your phone. United States (Toll Free): 1 877 568 4106 United States: +1 (571) 317-3129 Access Code: 997-304-269 More phone numbers France (Toll Free): 0 805 541 047 France: +33 170 950 594 Germany (Toll Free): 0 800 723 5270 Germany: +49 692 5736 7210 First GoToMeeting? Try a test session: http://help.citrix.com/getready Wann: Di 15. Aug. 2017 14:00 ? 15:00 Berlin Wo: https://global.gotomeeting.com/join/997304269 Kalender: automotive-discussions at lists.linuxfoundation.org Wer * Walt Miner- Veranstalter * automotive-discussions at lists.linuxfoundation.org * Noriaki Fukuyasu * dcauchy at linuxfoundation.org Einladung von Google Kalender: https://www.google.com/calendar/ Sie erhalten diese E-Mail unter automotive-discussions at lists.linuxfoundation.org, da Sie ein Gast bei diesem Termin sind. Lehnen Sie diesen Termin ab, um keine weiteren Informationen zu diesem Termin zu erhalten. Sie k?nnen auch unter https://www.google.com/calendar/ ein Google-Konto erstellen und Ihre Benachrichtigungseinstellungen f?r Ihren gesamten Kalender steuern. Wenn Sie diese Einladung weiterleiten, kann jeder Empf?nger Ihre Antwort auf die Einladung ?ndern. Weitere Informationen finden Sie unter https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2347 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2405 bytes Desc: not available URL: From dominig.arfoll at fridu.net Thu Aug 10 11:20:16 2017 From: dominig.arfoll at fridu.net (Dominig Ar Foll) Date: Thu, 10 Aug 2017 13:20:16 +0200 Subject: [agl-discussions] Master broken with nav application building Message-ID: Hello, I see that from this morning, master is broken (at least for Intel). The error is trigger by the Nav application but seems more related to the packaging of lib in a widget. See log bellow. -- Dominig ar Foll Senior Software Architect Intel Open Source Technology Centre ------------------- log extract ------------- NOTE: Executing RunQueue Tasks WARNING: lsof-4.89-r0 do_fetch: Failed to fetch URL ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_4.89.tar.bz2, attempting MIRRORS if available ERROR: navigation-git-r0 do_aglwgt_deploy: Function failed: do_aglwgt_deploy (log file is located at /home/dominig/AGL/build/tmp/work/corei7-64-agl-linux/navigation/git-r0/temp/log.do_aglwgt_deploy.285 08) ERROR: Logfile of failure stored in: /home/dominig/AGL/build/tmp/work/corei7-64-agl-linux/navigation/git-r0/temp/log.do_aglwgt_deploy.28508 Log data follows: | DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 'bit-64', 'x86_64-linux', 'common'] | DEBUG: Executing shell function do_aglwgt_deploy | install: cannot stat '/home/dominig/AGL/build/tmp/work/corei7-64-agl-linux/navigation/git-r0/build/package/*.wgt': No such file or directory | WARNING: /home/dominig/AGL/build/tmp/work/corei7-64-agl-linux/navigation/git-r0/temp/run.do_aglwgt_deploy.28508:1 exit 1 from 'install -m 0644 /home/dominig/AGL/build/tmp/work/corei7-64-agl-linux/nav igation/git-r0/build/package/*.wgt /home/dominig/AGL/build/tmp/work/corei7-64-agl-linux/navigation/git-r0/image/usr/AGL/apps/autoinstall' | ERROR: Function failed: do_aglwgt_deploy (log file is located at /home/dominig/AGL/build/tmp/work/corei7-64-agl-linux/navigation/git-r0/temp/log.do_aglwgt_deploy.28508) ERROR: Task (/home/dominig/AGL/meta-agl-demo/recipes-demo-hmi/navigation/navigation_git.bb:do_aglwgt_deploy) failed with exit code '1' NOTE: Tasks Summary: Attempted 4099 tasks of which 2740 didn't need to be rerun and 1 failed. Summary: 1 task failed: /home/dominig/AGL/meta-agl-demo/recipes-demo-hmi/navigation/navigation_git.bb:do_aglwgt_deploy Summary: There were 3 WARNING messages shown. Summary: There was 1 ERROR message shown, returning a non-zero exit code. dominig at dominig-t460:~/AGL/build> From jose.bollo at iot.bzh Thu Aug 10 12:30:50 2017 From: jose.bollo at iot.bzh (=?UTF-8?B?Sm9zw6k=?= Bollo) Date: Thu, 10 Aug 2017 14:30:50 +0200 Subject: [agl-discussions] Master broken with nav application building In-Reply-To: References: Message-ID: <20170810143050.4068d7ef@d-jobol.iot.bzh> On Thu, 10 Aug 2017 13:20:16 +0200 Dominig Ar Foll wrote: > Hello, > > I see that from this morning, master is broken (at least for Intel). > The error is trigger by the Nav application but seems more related to > the packaging of lib in a widget. > See log bellow. > I pulled master this noon and rebuilt it without the issue for m3ulcb Best regards Jos? From jsmoeller at linuxfoundation.org Thu Aug 10 14:04:20 2017 From: jsmoeller at linuxfoundation.org (Jan-Simon =?ISO-8859-1?Q?M=F6ller?=) Date: Thu, 10 Aug 2017 16:04:20 +0200 Subject: [agl-discussions] Master broken with nav application building In-Reply-To: References: Message-ID: <2867944.TLjcZGgodQ@elrond> Am Donnerstag, 10. August 2017, 13:20:16 CEST schrieb Dominig Ar Foll: > Hello, > > I see that from this morning, master is broken (at least for Intel). > The error is trigger by the Nav application but seems more related to > the packaging of lib in a widget. repo manifest -r ? I'll run a build ... Best, Jan-Simon From gandersson at genivi.org Mon Aug 14 19:36:15 2017 From: gandersson at genivi.org (Gunnar Andersson) Date: Mon, 14 Aug 2017 21:36:15 +0200 Subject: [agl-discussions] Idea for bbappend / layer organization and naming convention Message-ID: <1502739375.26251.126.camel@genivi.org> Yocto community, Triggered by the previous email request to yocto@ about best practices for layer organization I'm finally firing off this email for (hopefully) some feedback on an idea we first kicked around, discussed for rough consensus and then decided to implement in the Yocto based GDP project [1]. You can see it as a trial, anything can be changed, but so far so good... We adopted a somewhat novel (but actually not really unique, see inside) naming convention [2] for all modifications to components that belong to other layers. This convention shows what layers are being modified by the .bbappends by actually naming the layer it is (intending to**) modify.? The initiative also aims to highlight and separate .bbappends (modifications) from uniquely added components in our project (new .bb files) in GDP. **Note that we are well aware this does NOT control bitbake behavior (as neither does the recipe-xxx/ directory convention), and is therefore just a guide. If the project is misconfigured, bitbake could do something different than the naming convention implies and it could even be misleading, but at least the *programmer intent* is shown clearly. I think it also makes .bbappends more explicitly visible and might trigger the idea: Do we really need this? Are we really modifying *that* adopted layer, and if so, why? To Russel who wrote the previous request for guidance - feel free to consider, but I won't recommend this directly since it's by no means an agreed best practice in all of the community.??I'm rather asking for other experienced OE developers to consider and comment on the idea.?? For oldtimers it's probably easy to find this odd and just be negative against it since well, "standard practice", inertia, NIH and all that, but I'll stick my neck out anyway because it seems to solve some issues of organization and understanding at least for us (and I'm a sucker for some flamebait ;) If the intro is too formal and long, just look at the final examples. I think you'll get it. Feel free to ask. - Gunnar --? Gunnar Andersson Development Lead GENIVI Alliance [1] https://github.com/GENIVI/genivi-dev-platform [2] Naming strategy for bitbake extension layers: https://at.projects.genivi.org/wiki/x/w4Xk From dl9pf at gmx.de Tue Aug 15 20:27:03 2017 From: dl9pf at gmx.de (Jan-Simon =?ISO-8859-1?Q?M=F6ller?=) Date: Tue, 15 Aug 2017 22:27:03 +0200 Subject: [agl-discussions] Charming Chinook 3.0.5 release candidate available Message-ID: <93939520.RKcsHPXOKp@samweis.auenland.lan> Hi ! A release candidate is available for the charming chinook 3.0.5 release under: https://download.automotivelinux.org/AGL/upload/ci/chinook/3.0.5/ The corresponding sources are tagged and available with: repo init -b chinook -m chinook_3.0.5.xml -u https:// gerrit.automotivelinux.org/gerrit/AGL/AGL-repo.git Please test thre release candidate. If no blockers come up it will become the last and final release of the chinook branch by the end of this week. -- Dipl.-Ing. Jan-Simon M?ller jansimon.moeller at gmx.de From xp21987 at aliyun.com Wed Aug 16 02:14:11 2017 From: xp21987 at aliyun.com (xp21987) Date: Wed, 16 Aug 2017 10:14:11 +0800 Subject: [agl-discussions] =?utf-8?q?_wayland_ivi_layer?= Message-ID: Hello?I'm a newer to develop applpication on AGL.I'm going to develop a window manager with Wayland ivi shell. AGL integrate wayland and Genivi wayland-ivi-extension. After system start up, I can get three layers by command ./LayerManagerControl get layers. Their id are 101,102,103. I want to know what are they? I think the layer 103 is the HomeScreen layer, because I can see the HomeScreen, If I want to show other applications, I need set HomnScreen invisible. Second, what is wl-shell-emulator.so?? What found is? if I enable wl-shell-emulator.so, then play video with waylandsink, a surface ID will gernerate, then I can control this video with this ID by ivi shell, I can put the video on top,so we can see the video.If I disable it, video cannot be played with waylandsink,error will happen,no surface ID gernerate, the video surface cannot be controlled by ivi shell. One more thing, when I run demo application weston-simple-egl, whatever layer/surface region I set, there're nine triangle will be shown on screen, why?And I run my own application based on ivi shell, I found two surface ID ,one is? I set in application, aonther is 2147483648 (0x80000000), I don't know what it is. like below:./LayerManagerControl get surfaces???????????????? ? 2 Surface(s): - Surface 2147483648 (0x80000000)---------------------what is this? - Surface 12 (0xc)????????????????????????????---------------------- This is my application surface id. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fulup.arfoll at iot.bzh Thu Aug 17 00:00:44 2017 From: fulup.arfoll at iot.bzh (Fulup Ar Foll) Date: Thu, 17 Aug 2017 02:00:44 +0200 Subject: [agl-discussions] AAAA (AGL Advance Audio Agent) Controller Binding. Message-ID: FYI, I pushed on Github an Alpha version of the Controller Application Framework Binding for AAAA As discussed in San Jose, the controller was the missing part in AAAA architecture, and it was decided to put resources to fix that issue before October AMM. You may find on github current work in progress. As today, I hope that I implements every needed features (let me know if I miss something). Integration with AAAA is still cooking, nevertheless as Microchip made good progress, we should have a version integrated with Unicens HALs before the end of the month. On the other hand the high level API is still under heavy work by Audiokenetics and we may have to wait September before playing with it. You may find my README on https://github.com/iotbzh/audio-bindings/blob/master/Controler-afb/README.md The controller as well as the rest of AAAA should compile almost strait forward on any recent Linux desktop. It used standard AppFW binder packages available from https://en.opensuse.org/LinuxAutomotive (Note that on Github my code is still under Fulup-Dev branch, I should merge in Master my branch with the one from Tobias in the next couple of days). While the controller was initially designed to address AAAA requirements, it is built in a generic manner and should be usable in many other contexts (eg: small business logic for demo app, glue to agglomerate vehicle signal, fake generator of signals, events, application agglomeration of data from multiple sources, ...). Global concept should hopefully be natural to everyone. The JSON configuration file defines a set of controls. As the controller is a standard AGL binding, all features are accessible directly from standard AppFw/API. The controller leverage every standard AppFw features: security, monitoring, log, ... Technically a control is a set of action(s) that are executed in order. Those actions can be implemented in LUA(script), in native-C(plugin) or through sub-service calls to an other AppFw/Binding (eg: ALSA/UCM, Vehicle Signalling, ...). The controller also support events handling. It may fire a set of action when a given signal is received (eg: adjust volume when speed change, prevent phone from rigging when reverse gear is engage, ...) The LUA interface is pretty complete and provides access to most of AppFw API (afb_reply, event, timer, notice, ...). User may also extend Lua with its own set of commands through a plugin mechanism. The controller handle transparently the conversion from LUA data internal representation to JSON-C object as used by AppFw API. This integration model might be useful to interface proprietary technologies with controls, or to fasten operations that require a higher level of performance that would be incompatible with scripting language. Please provide feedback. Fulup From gandersson at genivi.org Fri Aug 18 14:46:19 2017 From: gandersson at genivi.org (Gunnar Andersson) Date: Fri, 18 Aug 2017 16:46:19 +0200 Subject: [agl-discussions] [yocto] Idea for bbappend / layer organization and naming convention In-Reply-To: References: <1502739375.26251.126.camel@genivi.org> Message-ID: <1503067579.6972.4.camel@genivi.org> On Mon, 2017-08-14 at 23:02 -0400, Bruce Ashfield wrote: > On 2017-08-14 3:36 PM, Gunnar Andersson wrote: > > > > Yocto community, > > > > Triggered by the previous email request to yocto@ about best practices > > for layer organization I'm finally firing off this email for (hopefully) > > some feedback on an idea we first kicked around, discussed for rough > > consensus and then decided to implement in the Yocto based GDP project > > [1].??You can see it as a trial, anything can be changed, but so far so > > good... > > > > We adopted a somewhat novel (but actually not really unique, see inside) > > naming convention [2] for all modifications to components that belong to > > other layers. > > > > I've been using a similar naming/sorting mechanism in layers that > I maintain for several years now. Great. ?Is it similar, or /exactly/ like this? I'm only asking because I think it would be useful to have some written down rules and if there are additional tweaks that will improve this proposal, I'd like to hear them. I suspected it might actually be somewhat of a common practice. > When you have a single layer that is carrying bbappends to many other > layers, I find that it really helps keep everything separated and aids > finding the original recipe. Yes, that is the idea. > > (that being said, recent work with layer index, etc, make it > easier to locate the original recipe and any bbappends .. but that > doesn't preclude keeping things organized in a layer). ... but I didn't get any more feedback than yours, so I'll just leave it where it is for now. Maybe this is not something the other Yocto community cares about, or similar practices are actually done in practice, but not written down. Or maybe everyone is OK with the state of mixing .bb and .bbappend files within the layers... So far I think the initial experience on our side is positive. It's something that needs to be looked after a bit (we have a few mistakes to fix). But since some directories will only have .bb files, and others only .bbappend files, it's therefore easy to script a warning system for anything that is out of place. Best Regards - Gunnar > Cheers, > > Bruce > [trimmed] > > --? > > Gunnar Andersson > > Development Lead > > GENIVI Alliance > > > > [1] https://github.com/GENIVI/genivi-dev-platform > > [2] Naming strategy for bitbake extension layers: > > https://at.projects.genivi.org/wiki/x/w4Xk From stephane.desneux at iot.bzh Sun Aug 20 19:02:27 2017 From: stephane.desneux at iot.bzh (Stephane Desneux) Date: Sun, 20 Aug 2017 21:02:27 +0200 Subject: [agl-discussions] [yocto] Idea for bbappend / layer organization and naming convention In-Reply-To: <74383aef-827f-44d8-630e-310e42f6667a@windriver.com> References: <1502739375.26251.126.camel@genivi.org> <1503067579.6972.4.camel@genivi.org> <7d9c1bc9-648f-d5af-508e-089682e702e0@windriver.com> <74383aef-827f-44d8-630e-310e42f6667a@windriver.com> Message-ID: <51be8a03-0609-9bc6-ed7f-a35b896884f7@iot.bzh> Hi all, I've followed this thread with interest. I'll try to bring here some ideas we had in parallel on Automotive Grade Linux (AGL) side. What we plan to do with backports on AGL is still WIP (see https://jira.automotivelinux.org/browse/SPEC-802). It's still cooking, but we're going to adopt a solution close to the one proposed by Gunnar in GENIVI: I mean: we agree on the same goal, but what we end up with differs slightly. The scheme we're thinking about would be typically something like this: meta-agl/meta-agl-backports/////.bbappend Where: * the first meta-agl is our main git repo (not a meta in fact): the real meta is meta-agl/meta-agl :) * meta-agl/meta-agl-backports is a layer * is the name of the layer on which the backport is applied * is the origin folder name for recipes in the origin layer * is the name of the recipe which is backported/amended * is something that defines why we have a backport here (bug id, quick desc...) And finally, in the folder where we put the bbappend, we want to add a README.backport in YAML, similar to this one: ? Origin: Origin-Url: Origin-Ref: Destination: Expiration: (if known) Bug-AGL: Upstream-Status: Reason: ? With that model, we expect to smooth the workflow and make the alignment on Yocto/OE/Poky versions easier. HTH Best regards, --- Stephane Desneux - CTO - IoT.bzh stephane.desneux at iot.bzh - www.iot.bzh On 18/08/17 21:35, Mark Hatle wrote: > On 8/18/17 1:47 PM, Bruce Ashfield wrote: >> On 08/18/2017 10:46 AM, Gunnar Andersson wrote: >>> >>> On Mon, 2017-08-14 at 23:02 -0400, Bruce Ashfield wrote: >>>> On 2017-08-14 3:36 PM, Gunnar Andersson wrote: >>>>> >>>>> Yocto community, >>>>> >>>>> Triggered by the previous email request to yocto@ about best practices >>>>> for layer organization I'm finally firing off this email for (hopefully) >>>>> some feedback on an idea we first kicked around, discussed for rough >>>>> consensus and then decided to implement in the Yocto based GDP project >>>>> [1]. You can see it as a trial, anything can be changed, but so far so >>>>> good... >>>>> >>>>> We adopted a somewhat novel (but actually not really unique, see inside) >>>>> naming convention [2] for all modifications to components that belong to >>>>> other layers. >>>>> >>>> >>>> I've been using a similar naming/sorting mechanism in layers that >>>> I maintain for several years now. >>> >>> Great. Is it similar, or /exactly/ like this? I'm only asking because I >>> think it would be useful to have some written down rules and if there are >>> additional tweaks that will improve this proposal, I'd like to hear them. >>> > > I suspect suggestions for best practices along with examples are what people > would like to see. This may be reasonable to do with both the Yocto Project and > OpenEmbedded communities. > > Obviously there are currently a large number of existing layers. So showing how > this works, and examples of how it makes it easier to maintain and manage the > work over the longer term is a really good idea. > > (Keep in mind, many of the current layers were originally designed/updated > before there was a large ecosystem of layers. So a lot of poor examples, of > this kind of maintenance, may exist. It is a good idea to steer people away > from using these as examples, and even a way to potentially help the maintainers > of those layers evolve into a better and more efficient format.) > > --Mark > >> Exactly. The layer name and recipe-* structure is nested in a layer >> that is carrying bbappends. That way there's zero confusion about where >> the main recipe can be found. >> >> Bruce >> >>> I suspected it might actually be somewhat of a common practice. >>> >>>> When you have a single layer that is carrying bbappends to many other >>>> layers, I find that it really helps keep everything separated and aids >>>> finding the original recipe. >>> >>> Yes, that is the idea. >>> >>>> >>>> (that being said, recent work with layer index, etc, make it >>>> easier to locate the original recipe and any bbappends .. but that >>>> doesn't preclude keeping things organized in a layer). >>> >>> ... but I didn't get any more feedback than yours, so I'll just leave it >>> where it is for now. Maybe this is not something the other Yocto community >>> cares about, or similar practices are actually done in practice, but not >>> written down. Or maybe everyone is OK with the state of mixing .bb and >>> .bbappend files within the layers... >>> >>> So far I think the initial experience on our side is positive. It's >>> something that needs to be looked after a bit (we have a few mistakes to >>> fix). But since some directories will only have .bb files, and others only >>> .bbappend files, it's therefore easy to script a warning system for anything >>> that is out of place. >>> >>> Best Regards >>> - Gunnar >>> >>>> Cheers, >>>> >>>> Bruce >>>> >>> [trimmed] >>> >>>>> -- >>>>> Gunnar Andersson >>>>> Development Lead >>>>> GENIVI Alliance >>>>> >>>>> [1] https://github.com/GENIVI/genivi-dev-platform >>>>> [2] Naming strategy for bitbake extension layers: >>>>> https://at.projects.genivi.org/wiki/x/w4Xk >>> >>> >> > From wminer at linuxfoundation.org Mon Aug 21 13:36:37 2017 From: wminer at linuxfoundation.org (Walt Miner) Date: Mon, 21 Aug 2017 13:36:37 +0000 Subject: [agl-discussions] Invitation: [AG-SAT] SAT Meeting @ Thu Aug 24, 2017 7am - 8am (CDT) (automotive-discussions@lists.linuxfoundation.org) Message-ID: <001a11437c746c0150055743919f@google.com> You have been invited to the following event. Title: [AG-SAT] SAT Meeting AGL-SAT Meeting to discuss XDG Protocol and ivi-application-protocol support. Presentation by ADIT. Please join my meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/796425741 You can also dial in using your phone. United States (Toll Free): 1 877 309 2070 United States: +1 (312) 757-3119 Access Code: 796-425-741 More phone numbers Australia: +61 2 8355 1034 Austria: +43 7 2088 0716 Belgium: +32 28 93 7002 Canada (Toll Free): 1 877 777 3281 Canada: +1 (647) 497-9372 Denmark: +45 69 91 84 58 Finland: +358 923 17 0556 France: +33 170 950 590 Germany: +49 692 5736 7206 India (Toll Free): 000 800 100 8227 Ireland: +353 19 030 053 Italy: +39 0 699 26 68 65 Japan (Toll Free): 0 120 242 200 Korea, Republic of (Toll Free): 0806180880 Netherlands: +31 208 080 759 New Zealand: +64 9 974 9579 Norway: +47 21 04 30 59 Spain: +34 931 76 1534 Sweden: +46 852 500 691 Switzerland: +41 435 0026 89 United Kingdom: +44 20 3713 5011 First GoToMeeting? Try a test session: https://care.citrixonline.com/g2m/getready When: Thu Aug 24, 2017 7am ? 8am Central Time Where: https://global.gotomeeting.com/join/796425741 Calendar: automotive-discussions at lists.linuxfoundation.org Who: * Walt Miner - organizer * automotive-discussions at lists.linuxfoundation.org * dcauchy at linuxfoundation.org * Noriaki Fukuyasu * Jan-Simon Moeller Event details: https://www.google.com/calendar/event?action=VIEW&eid=NnVuYTZxN29nZTF1YTdwOTl0Zm9wc2xoMHYgYXV0b21vdGl2ZS1kaXNjdXNzaW9uc0BsaXN0cy5saW51eGZvdW5kYXRpb24ub3Jn&tok=MjYjd21pbmVyQGxpbnV4Zm91bmRhdGlvbi5vcmdjY2EyMTVkNjJlYTgxZjY2NTlmNjdmOWFkOTk3Nzc5ODFjYmVmYWVk&ctz=America/Chicago&hl=en Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account automotive-discussions at lists.linuxfoundation.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2795 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2847 bytes Desc: not available URL: From xp21987 at aliyun.com Mon Aug 21 15:46:59 2017 From: xp21987 at aliyun.com (xp21987) Date: Mon, 21 Aug 2017 23:46:59 +0800 Subject: [agl-discussions] =?utf-8?b?5Zue5aSN77yaIHdheWxhbmQgaXZpIGxheWVy?= In-Reply-To: f8206b14-0607-448f-9284-63e4c6381d8b.xp21987@aliyun.com References: f8206b14-0607-448f-9284-63e4c6381d8b.xp21987@aliyun.com Message-ID: <0fd3196f-5635-4359-8a1c-1a9facc8dae5.xp21987@aliyun.com> Hello?I'm a newer to develop applpications on AGL.I'm going to develop a window manager with Wayland ivi shell. AGL has integrated wayland and Genivi wayland-ivi-extension. After system start up, I can get three layers by command ./LayerManagerControl get layers. Their id are 101,102,103. I want to know what are they? I think the layer 103 is the HomeScreen layer, because I can see the HomeScreen, If I want to show other applications, I need set HomnScreen invisible. Second, what is wl-shell-emulator.so?? What found is? if I enable wl-shell-emulator.so, then play video with waylandsink, a surface ID will gernerate, then I can control this video with this ID by ivi shell, I can put the video on top,so we can see the video.If I disable it, video cannot be played with waylandsink,error will happen,no surface ID gernerate, the video surface cannot be controlled by ivi shell. One more thing, when I run demo application weston-simple-egl, whatever layer/surface region I set, there're nine triangle will be shown on screen, why?And I run my own application based on ivi shell, I found two surface ID ,one is? I set in application, aonther is 2147483648 (0x80000000), I don't know what it is. like below:./LayerManagerControl get surfaces???????????????? ? 2 Surface(s): - Surface 2147483648 (0x80000000)---------------------what is this? - Surface 12 (0xc)????????????????????????????---------------------- This is my application surface id. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmatsuzawa at xevo.com Tue Aug 22 03:25:26 2017 From: tmatsuzawa at xevo.com (Takashi Matsuzawa) Date: Tue, 22 Aug 2017 03:25:26 +0000 Subject: [agl-discussions] weston 2.0 with fbdev? Message-ID: I wonder if this also has impact on VM? > https://community.nxp.com/thread/451590 >The reason for this is that Weston 2.0 has dropped EGL support from FBDev I think it was suggested to run AGL image with fbdev-backend on virtualbox. (But using vboxvideo driver we can use drm-backend on virtualbox, so the potential issue can be avoided?) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryuohno at hagiwara.co.jp Tue Aug 22 04:31:30 2017 From: ryuohno at hagiwara.co.jp (=?iso-2022-jp?B?GyRCQmdMbhsoQiAbJEJONTBsTzohd0drODYbKEI=?=) Date: Tue, 22 Aug 2017 04:31:30 +0000 Subject: [agl-discussions] Repo Tool[Renesas R-Car Porter] Message-ID: Hi all, I build AGL for Renesas R-Car Porter with reference to https://wiki.automotivelinux.org/start/building_for_the_renesas_r-car_m2. I prepared the Repo tool at curl https://storage.googleapis.com/git-repo-downloads/repo> ~ / bin / repo, but "curl: (22) The requested URL returned error: 404 Not Found "message will be displayed. If you say "curl http://commondatastorage.googleapis.com/git-repo-downloads/repo> ~ / bin / repo", it seems to be successful. Is my procedure correct? From ryuohno at hagiwara.co.jp Tue Aug 22 04:32:39 2017 From: ryuohno at hagiwara.co.jp (=?iso-2022-jp?B?GyRCQmdMbhsoQiAbJEJONTBsTzohd0drODYbKEI=?=) Date: Tue, 22 Aug 2017 04:32:39 +0000 Subject: [agl-discussions] AGL Build[Renesas R-Car Porter] Message-ID: I build AGL for Renesas R-Car Porter with reference to https://wiki.automotivelinux.org/start/building_for_the_renesas_r-car_m2. When you download the code from "Download Master Branch", you will see a message "curl: (22) The requested URL returned error: 404 Not Found" in part. After running "bitbake agl-demo-platform", srec file is generated, but the root file system is not created. Would you give me advice for building AGL? From tanikawa.tadao at jp.panasonic.com Tue Aug 22 05:16:29 2017 From: tanikawa.tadao at jp.panasonic.com (tanikawa.tadao at jp.panasonic.com) Date: Tue, 22 Aug 2017 05:16:29 +0000 Subject: [agl-discussions] Repo Tool[Renesas R-Car Porter] In-Reply-To: References: Message-ID: Hi, curl https://storage.googleapis.com/git-repo-downloads/repo works fine for me. Please check your network environment especially around firewall or https proxy. Regards, Tadao Tanikawa > -----Original Message----- > From: automotive-discussions-bounces at lists.linuxfoundation.org > [mailto:automotive-discussions-bounces at lists.linuxfoundation.org] On Behalf Of ?? ?????? > Sent: Tuesday, August 22, 2017 1:32 PM > To: automotive-discussions at lists.linuxfoundation.org > Subject: [agl-discussions] Repo Tool[Renesas R-Car Porter] > > Hi all, > > I build AGL for Renesas R-Car Porter with reference to > https://wiki.automotivelinux.org/start/building_for_the_renesas_r-car_m2. > > I prepared the Repo tool at curl https://storage.googleapis.com/git-repo-downloads/repo> ~ / bin / repo, but "curl: > (22) The requested URL returned error: 404 Not Found "message will be displayed. > > If you say "curl http://commondatastorage.googleapis.com/git-repo-downloads/repo> ~ / bin / repo", it seems to be > successful. > > Is my procedure correct? > > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions From tmatsuzawa at xevo.com Tue Aug 22 06:02:02 2017 From: tmatsuzawa at xevo.com (Takashi Matsuzawa) Date: Tue, 22 Aug 2017 06:02:02 +0000 Subject: [agl-discussions] AAAA (AGL Advance Audio Agent) Controller Binding. In-Reply-To: References: Message-ID: Hello. I am looking into the AAAA architecture diagram. Just for my better understanding, how e.g. an iPod expected to fit to this diagram? It might be primarily audio source device, with several available media (bluetooth, USB, etc.). Do we have just one "iPod" binding and corresponding HAL, or it is better just hidden below ALSA, etc. APIs? Also how about microphone input (for voice commands) - such input should also be routed by this AAAA and apps should be using the AAAA APIs to obtain data (there may be additional module in between audio data API and application logic for speech recognition, etc.?) ________________________________ From: automotive-discussions-bounces at lists.linuxfoundation.org on behalf of Fulup Ar Foll Sent: Thursday, August 17, 2017 9:00 AM To: automotive-discussions at lists.linuxfoundation.org Subject: [agl-discussions] AAAA (AGL Advance Audio Agent) Controller Binding. FYI, I pushed on Github an Alpha version of the Controller Application Framework Binding for AAAA As discussed in San Jose, the controller was the missing part in AAAA architecture, and it was decided to put resources to fix that issue before October AMM. You may find on github current work in progress. As today, I hope that I implements every needed features (let me know if I miss something). Integration with AAAA is still cooking, nevertheless as Microchip made good progress, we should have a version integrated with Unicens HALs before the end of the month. On the other hand the high level API is still under heavy work by Audiokenetics and we may have to wait September before playing with it. You may find my README on https://github.com/iotbzh/audio-bindings/blob/master/Controler-afb/README.md The controller as well as the rest of AAAA should compile almost strait forward on any recent Linux desktop. It used standard AppFW binder packages available from https://en.opensuse.org/LinuxAutomotive (Note that on Github my code is still under Fulup-Dev branch, I should merge in Master my branch with the one from Tobias in the next couple of days). While the controller was initially designed to address AAAA requirements, it is built in a generic manner and should be usable in many other contexts (eg: small business logic for demo app, glue to agglomerate vehicle signal, fake generator of signals, events, application agglomeration of data from multiple sources, ...). Global concept should hopefully be natural to everyone. The JSON configuration file defines a set of controls. As the controller is a standard AGL binding, all features are accessible directly from standard AppFw/API. The controller leverage every standard AppFw features: security, monitoring, log, ... Technically a control is a set of action(s) that are executed in order. Those actions can be implemented in LUA(script), in native-C(plugin) or through sub-service calls to an other AppFw/Binding (eg: ALSA/UCM, Vehicle Signalling, ...). The controller also support events handling. It may fire a set of action when a given signal is received (eg: adjust volume when speed change, prevent phone from rigging when reverse gear is engage, ...) The LUA interface is pretty complete and provides access to most of AppFw API (afb_reply, event, timer, notice, ...). User may also extend Lua with its own set of commands through a plugin mechanism. The controller handle transparently the conversion from LUA data internal representation to JSON-C object as used by AppFw API. This integration model might be useful to interface proprietary technologies with controls, or to fasten operations that require a higher level of performance that would be incompatible with scripting language. Please provide feedback. Fulup _______________________________________________ automotive-discussions mailing list automotive-discussions at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -------------- next part -------------- An HTML attachment was scrubbed... URL: From wminer at linuxfoundation.org Tue Aug 22 13:19:16 2017 From: wminer at linuxfoundation.org (wminer at linuxfoundation.org) Date: Tue, 22 Aug 2017 13:19:16 +0000 Subject: [agl-discussions] Updated Invitation: AGL Dev Meeting - Weekly @ Weekly from 8am to 9am on Tuesday (CDT) (automotive-discussions@lists.linuxfoundation.org) Message-ID: <001a1142c5062fbbcc055757717f@google.com> This event has been changed. Title: AGL Dev Meeting - Weekly When: Weekly from 8am to 9am on Tuesday Central Time (changed) Where: See https://wiki.automotivelinux.org/dev-call-info Calendar: automotive-discussions at lists.linuxfoundation.org Who: * Walt Miner - creator * dcauchy at linuxfoundation.org * automotive-discussions at lists.linuxfoundation.org * Noriaki Fukuyasu Event details: https://www.google.com/calendar/event?action=VIEW&eid=dDlscDkxMGFjZGMwOTdkMDdmNDJhNjVrcTQgYXV0b21vdGl2ZS1kaXNjdXNzaW9uc0BsaXN0cy5saW51eGZvdW5kYXRpb24ub3Jn&tok=NzIjbGludXhmb3VuZGF0aW9uLm9yZ19pMHJzOGFta20wZmxkZTdrcTV1NGI5dGVmNEBncm91cC5jYWxlbmRhci5nb29nbGUuY29tNmIwODE4YmNkZDllNThjY2RjODc0MWVlNTFkNDVmNmRhNzExZjRkOQ&ctz=America/Chicago&hl=en Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account automotive-discussions at lists.linuxfoundation.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2673 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2746 bytes Desc: not available URL: From wminer at linuxfoundation.org Tue Aug 22 15:25:01 2017 From: wminer at linuxfoundation.org (Walt Miner) Date: Tue, 22 Aug 2017 10:25:01 -0500 Subject: [agl-discussions] Charming Chinook 3.0.5 Patch Release Available Message-ID: A patch release (3.0.5) has been made to Charming Chinook and is now available on the Chinook branch. Everyone using the Chinook release should update to this release. Release notes, information on downloading the source code, pre-built binaries, or setting up git can be found at [1]. Build instructions were updated on the wiki and the README.md files in meta-agl and meta-agl-demo. There are no plans for further patch releases to the Chinook branch. It is recommended that all users switch to the Daring Dab release as soon as possible. If an issue arises that requires a new release for Chinook, please submit patches to be considered for a release and create a Jira ticket indicating that a critical issue has been found that requires a new Chinook release. We would consider security defects or any further Yocto releases on the morty branch to be critical enough to warrant a further Chinook release. Regards, Walt [1] https://wiki.automotivelinux.org/agl-distro/release-notes#chinook_305 Regards, Walt -- Walt Miner Engineering Project Manager The Linux Foundation mobile: +1.847.502.7087 Visit us at: automotive.linuxfoundation.org www.linuxfoundation.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fulup.arfoll at iot.bzh Tue Aug 22 17:31:11 2017 From: fulup.arfoll at iot.bzh (Fulup Ar Foll) Date: Tue, 22 Aug 2017 19:31:11 +0200 Subject: [agl-discussions] AAAA (AGL Advance Audio Agent) Controller Binding. In-Reply-To: References: Message-ID: Hi, Quick answer: -They are many options to integrate external devices or services - Application may leverage AAAA without even knowing it exit. More detail response Mobile device scenarios: 1) you choose bluethooth for your mobile device. Then bluez create an A2DP Alsa device. AAAA processes the event sent by ALSA and register a new HAL (in this case a generic one for A2DP). When your source is ready AAAA can send the right control to connect source and destination. The same scenario would apply for mobile headsets (eg: bluetooth headset for children on back seats) 2) you connect your phone by USB. In this case your phone is view as a storage (or somehow equivalent). You should then notify your Music Player Deamon that a new input source is present. (obviously your MPD should understand your device protocol). 3) you stream audio from your device, in this case your phone is equivalent to an internet radio. The easiest way to declare your mobile stream URI to your MPD. If you run an heavy applications (QT, GTK, ...) you may also prefer to stream audio thought your application. Nevertheless at least with HTML5 MPD is the preferred option. It allows to process input stream directly without going through the browser. Voice Input is mostly a control issue to find which source end point your want to connect to. In this case ALSA/UCM is probably your best friend, but you may also process event directly at AAAA controller level. Independently of the model you choose, when you connect an input device, you should notify AAAA of the new source, then AAAA should dispatch the right control(s) (eg: Alsa/uCM) to connect endpoints. Note that applications MAY or MAY NOT known about AAAA. Application may access ALSA PCM (capture/output) directly, without even knowing AAAA exist. However even if application access ALSA directly, they still maintains under AAAA authorisation/policy rules. In this scenario: - An application requests an Alsa resource bypassing AAAA. The call is intercepted at Alsalib level by the HookPlugin. - the hook plugin sends a control request to the AAAA controller - if control is granted by AAAA, then application may access PCM otherwise PCM remains close (control to apply depend on requested resource+SMACK label) - when application close the PCM AlsaLib notify AAAA controller that application release the resource. AAAA may then send a control to Alsa/UCM or any other AGL application (ex: send a notification to the homescreen to display something) In parallel when the AAAA controller access or refuses a request it generates an AGL-event. Those events can be subscribed by any application. This allows for example the homescreen to keep track of Audio on top pannel. On the opposite AAAA controller also accept input events coming from external services (eg: vehicle signalling agent). This second model allows for example to adjust master volume to car speed, or to prevent the phone from ringing when reverse gear is engaged. Fulup On 22/08/17 08:02, Takashi Matsuzawa wrote: > Hello. > I am looking into the AAAA architecture diagram. > > Just for my better understanding, how e.g. an iPod expected to fit to > this diagram? > > It might be primarily audio source device, with several available media > (bluetooth, USB, etc.). > Do we have just one "iPod" binding and corresponding HAL, or it is > better just hidden below ALSA, etc. APIs? > > Also how about microphone input (for voice commands) - such input should > also be routed by this AAAA and apps should be using the AAAA APIs to > obtain data (there may be additional module in between audio data API > and application logic for speech recognition, etc.?) > > > ------------------------------------------------------------------------ > *From:* automotive-discussions-bounces at lists.linuxfoundation.org > on behalf of > Fulup Ar Foll > *Sent:* Thursday, August 17, 2017 9:00 AM > *To:* automotive-discussions at lists.linuxfoundation.org > *Subject:* [agl-discussions] AAAA (AGL Advance Audio Agent) Controller > Binding. > FYI, > > I pushed on Github an Alpha version of the Controller Application > Framework Binding for AAAA > > As discussed in San Jose, the controller was the missing part in AAAA > architecture, and it was decided to put resources to fix that issue > before October AMM. You may find on github current work in progress. As > today, I hope that I implements every needed features (let me know if I > miss something). Integration with AAAA is still cooking, nevertheless as > Microchip made good progress, we should have a version integrated with > Unicens HALs before the end of the month. On the other hand the high > level API is still under heavy work by Audiokenetics and we may have to > wait September before playing with it. > > You may find my README on > https://github.com/iotbzh/audio-bindings/blob/master/Controler-afb/README.md > > The controller as well as the rest of AAAA should compile almost strait > forward on any recent Linux desktop. It used standard AppFW binder > packages available from https://en.opensuse.org/LinuxAutomotive (Note > that on Github my code is still under Fulup-Dev branch, I should merge > in Master my branch with the one from Tobias in the next couple of days). > > While the controller was initially designed to address AAAA > requirements, it is built in a generic manner and should be usable in > many other contexts (eg: small business logic for demo app, glue to > agglomerate vehicle signal, fake generator of signals, events, > application agglomeration of data from multiple sources, ...). > > Global concept should hopefully be natural to everyone. The JSON > configuration file defines a set of controls. As the controller is a > standard AGL binding, all features are accessible directly from standard > AppFw/API. The controller leverage every standard AppFw features: > security, monitoring, log, ... Technically a control is a set of > action(s) that are executed in order. Those actions can be implemented > in LUA(script), in native-C(plugin) or through sub-service calls to an > other AppFw/Binding (eg: ALSA/UCM, Vehicle Signalling, ...). The > controller also support events handling. It may fire a set of action > when a given signal is received (eg: adjust volume when speed change, > prevent phone from rigging when reverse gear is engage, ...) > > The LUA interface is pretty complete and provides access to most of > AppFw API (afb_reply, event, timer, notice, ...). User may also extend > Lua with its own set of commands through a plugin mechanism. The > controller handle transparently the conversion from LUA data internal > representation to JSON-C object as used by AppFw API. This integration > model might be useful to interface proprietary technologies with > controls, or to fasten operations that require a higher level of > performance that would be incompatible with scripting language. > > Please provide feedback. > > Fulup > > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions From fulup.arfoll at iot.bzh Tue Aug 22 23:45:18 2017 From: fulup.arfoll at iot.bzh (Fulup Ar Foll) Date: Wed, 23 Aug 2017 01:45:18 +0200 Subject: [agl-discussions] AAAA-Controller Binder as a standalone Controller Message-ID: <4aee1bb0-1ae7-1e55-deee-02f3a06c2e08@iot.bzh> FYI, As we started to use the AAAA-controller independently of AAAA we moved it out of AAAA and made a lot of cleanup in audio development repositories. In this process of cleaning development repositories we change few names. - AGL Advance Audio Agent (AAAA)? is now at https://github.com/iotbzh/afb-aaaa - Controller https://github.com/iotbzh/afb-controller The controller is not specific to AAAA? and we already use it for quick prototyping of demos. From AAAA point of view only controller config is specific. - Share binding utilities https://github.com/iotbzh/afb-utilities As today the tools from Jose to wrap/unwrap JSON object and a small utility to search config files in directories. - Music Daemon Player Client Binding at https://github.com/iotbzh/afb-mpdc We still have some work to skim down the audio agent. Next step is to move HALs (eg: Unicens Binding) outside of AAAA to make maintenance of specific components easier (but this will wait until next month). Fulup From tmatsuzawa at xevo.com Wed Aug 23 00:50:03 2017 From: tmatsuzawa at xevo.com (Takashi Matsuzawa) Date: Wed, 23 Aug 2017 00:50:03 +0000 Subject: [agl-discussions] AAAA (AGL Advance Audio Agent) Controller Binding. In-Reply-To: References: , Message-ID: Hello. Thank you for your explanation. In iPod connection case it has a requirement of allowing only one audio transport at most at any time. So I imagined headunit side must either 1) recognize the audio transports associated with an iPod and manage to shutdown them when switching source or 2) apply this rule of "one audio source at most" to everything so when it switches audio source, it makes sure previous source is shutdown. (The latter may be simpler but may make ducking or other fancier audio processing complex? I am not sure.) ________________________________ From: Fulup Ar Foll Sent: Wednesday, August 23, 2017 2:31 AM To: Takashi Matsuzawa; automotive-discussions at lists.linuxfoundation.org Subject: Re: [agl-discussions] AAAA (AGL Advance Audio Agent) Controller Binding. Hi, Quick answer: -They are many options to integrate external devices or services - Application may leverage AAAA without even knowing it exit. More detail response Mobile device scenarios: 1) you choose bluethooth for your mobile device. Then bluez create an A2DP Alsa device. AAAA processes the event sent by ALSA and register a new HAL (in this case a generic one for A2DP). When your source is ready AAAA can send the right control to connect source and destination. The same scenario would apply for mobile headsets (eg: bluetooth headset for children on back seats) 2) you connect your phone by USB. In this case your phone is view as a storage (or somehow equivalent). You should then notify your Music Player Deamon that a new input source is present. (obviously your MPD should understand your device protocol). 3) you stream audio from your device, in this case your phone is equivalent to an internet radio. The easiest way to declare your mobile stream URI to your MPD. If you run an heavy applications (QT, GTK, ...) you may also prefer to stream audio thought your application. Nevertheless at least with HTML5 MPD is the preferred option. It allows to process input stream directly without going through the browser. Voice Input is mostly a control issue to find which source end point your want to connect to. In this case ALSA/UCM is probably your best friend, but you may also process event directly at AAAA controller level. Independently of the model you choose, when you connect an input device, you should notify AAAA of the new source, then AAAA should dispatch the right control(s) (eg: Alsa/uCM) to connect endpoints. Note that applications MAY or MAY NOT known about AAAA. Application may access ALSA PCM (capture/output) directly, without even knowing AAAA exist. However even if application access ALSA directly, they still maintains under AAAA authorisation/policy rules. In this scenario: - An application requests an Alsa resource bypassing AAAA. The call is intercepted at Alsalib level by the HookPlugin. - the hook plugin sends a control request to the AAAA controller - if control is granted by AAAA, then application may access PCM otherwise PCM remains close (control to apply depend on requested resource+SMACK label) - when application close the PCM AlsaLib notify AAAA controller that application release the resource. AAAA may then send a control to Alsa/UCM or any other AGL application (ex: send a notification to the homescreen to display something) In parallel when the AAAA controller access or refuses a request it generates an AGL-event. Those events can be subscribed by any application. This allows for example the homescreen to keep track of Audio on top pannel. On the opposite AAAA controller also accept input events coming from external services (eg: vehicle signalling agent). This second model allows for example to adjust master volume to car speed, or to prevent the phone from ringing when reverse gear is engaged. Fulup On 22/08/17 08:02, Takashi Matsuzawa wrote: > Hello. > I am looking into the AAAA architecture diagram. > > Just for my better understanding, how e.g. an iPod expected to fit to > this diagram? > > It might be primarily audio source device, with several available media > (bluetooth, USB, etc.). > Do we have just one "iPod" binding and corresponding HAL, or it is > better just hidden below ALSA, etc. APIs? > > Also how about microphone input (for voice commands) - such input should > also be routed by this AAAA and apps should be using the AAAA APIs to > obtain data (there may be additional module in between audio data API > and application logic for speech recognition, etc.?) > > > ------------------------------------------------------------------------ > *From:* automotive-discussions-bounces at lists.linuxfoundation.org > on behalf of > Fulup Ar Foll > *Sent:* Thursday, August 17, 2017 9:00 AM > *To:* automotive-discussions at lists.linuxfoundation.org > *Subject:* [agl-discussions] AAAA (AGL Advance Audio Agent) Controller > Binding. > FYI, > > I pushed on Github an Alpha version of the Controller Application > Framework Binding for AAAA > > As discussed in San Jose, the controller was the missing part in AAAA > architecture, and it was decided to put resources to fix that issue > before October AMM. You may find on github current work in progress. As > today, I hope that I implements every needed features (let me know if I > miss something). Integration with AAAA is still cooking, nevertheless as > Microchip made good progress, we should have a version integrated with > Unicens HALs before the end of the month. On the other hand the high > level API is still under heavy work by Audiokenetics and we may have to > wait September before playing with it. > > You may find my README on > https://github.com/iotbzh/audio-bindings/blob/master/Controler-afb/README.md > > The controller as well as the rest of AAAA should compile almost strait > forward on any recent Linux desktop. It used standard AppFW binder > packages available from https://en.opensuse.org/LinuxAutomotive (Note > that on Github my code is still under Fulup-Dev branch, I should merge > in Master my branch with the one from Tobias in the next couple of days). > > While the controller was initially designed to address AAAA > requirements, it is built in a generic manner and should be usable in > many other contexts (eg: small business logic for demo app, glue to > agglomerate vehicle signal, fake generator of signals, events, > application agglomeration of data from multiple sources, ...). > > Global concept should hopefully be natural to everyone. The JSON > configuration file defines a set of controls. As the controller is a > standard AGL binding, all features are accessible directly from standard > AppFw/API. The controller leverage every standard AppFw features: > security, monitoring, log, ... Technically a control is a set of > action(s) that are executed in order. Those actions can be implemented > in LUA(script), in native-C(plugin) or through sub-service calls to an > other AppFw/Binding (eg: ALSA/UCM, Vehicle Signalling, ...). The > controller also support events handling. It may fire a set of action > when a given signal is received (eg: adjust volume when speed change, > prevent phone from rigging when reverse gear is engage, ...) > > The LUA interface is pretty complete and provides access to most of > AppFw API (afb_reply, event, timer, notice, ...). User may also extend > Lua with its own set of commands through a plugin mechanism. The > controller handle transparently the conversion from LUA data internal > representation to JSON-C object as used by AppFw API. This integration > model might be useful to interface proprietary technologies with > controls, or to fasten operations that require a higher level of > performance that would be incompatible with scripting language. > > Please provide feedback. > > Fulup > > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -------------- next part -------------- An HTML attachment was scrubbed... URL: From fulup.arfoll at iot.bzh Wed Aug 23 06:22:47 2017 From: fulup.arfoll at iot.bzh (Fulup Ar Foll) Date: Wed, 23 Aug 2017 08:22:47 +0200 Subject: [agl-discussions] AAAA (AGL Advance Audio Agent) Controller Binding. In-Reply-To: References: Message-ID: Yes you should obviously understand the protocol of your 'alien' hot plug device and build rules in such a way that all resources are release even when the device is 'badly' disconnected. On 23/08/17 02:50, Takashi Matsuzawa wrote: > Hello. > Thank you for your explanation. > > In iPod connection case it has a requirement of allowing only one audio > transport at most at any time. > So I imagined headunit side must either 1) recognize the audio > transports associated with an iPod and manage to shutdown them when > switching source or 2) apply this rule of "one audio source at most" to > everything so when it switches audio source, it makes sure previous > source is shutdown. > (The latter may be simpler but may make ducking or other fancier audio > processing complex? ?I am not sure.) > > ------------------------------------------------------------------------ > *From:* Fulup Ar Foll > *Sent:* Wednesday, August 23, 2017 2:31 AM > *To:* Takashi Matsuzawa; automotive-discussions at lists.linuxfoundation.org > *Subject:* Re: [agl-discussions] AAAA (AGL Advance Audio Agent) > Controller Binding. > Hi, > > Quick answer: > > ? -They are many options to integrate external devices or services > ? - Application may leverage AAAA without even knowing it exit. > > More detail response > > Mobile device scenarios: > > 1) you choose bluethooth for your mobile device. Then bluez create an > A2DP Alsa device. AAAA processes the event sent by ALSA and register a > new HAL (in this case a generic one for A2DP). When your source is ready > AAAA can send the right control to connect source and destination. The > same scenario would apply for mobile headsets (eg: bluetooth headset for > children on back seats) > > 2) you connect your phone by USB. In this case your phone is view as > a storage (or somehow equivalent). You should then notify your Music > Player Deamon that a new input source is present. (obviously your MPD > should understand your device protocol). > > 3) you stream audio from your device, in this case your phone is > equivalent to an internet radio. The easiest way to declare your mobile > stream URI to your MPD. If you run an heavy applications (QT, GTK, ...) > you may also prefer to stream audio thought your application. > Nevertheless at least with HTML5 MPD is the preferred option. It allows > to process input stream directly without going through the browser. > > Voice Input is mostly a control issue to find which source end point > your want to connect to. In this case ALSA/UCM is probably your best > friend, but you may also process event directly at AAAA controller > level. Independently of the model you choose, when you connect an input > device, you should notify AAAA of the new source, then AAAA should > dispatch the right control(s) (eg: Alsa/uCM) to connect endpoints. > > Note that applications MAY or MAY NOT known about AAAA. Application may > access ALSA PCM (capture/output) directly, without even knowing AAAA > exist. However even if application access ALSA directly, they still > maintains under AAAA authorisation/policy rules. > > In this scenario: > -? An application requests an Alsa resource bypassing AAAA. The call is > intercepted at Alsalib level by the HookPlugin. > ? - the hook plugin sends a control request to the AAAA controller > ? - if control is granted by AAAA, then application may access PCM > otherwise PCM remains close (control to apply depend on requested > resource+SMACK label) > ? - when application close the PCM AlsaLib notify AAAA controller that > application release the resource. AAAA may then send a control to > Alsa/UCM or any other AGL application (ex: send a notification to the > homescreen to display something) > > In parallel when the AAAA controller access or refuses a request it > generates an AGL-event. Those events can be subscribed by any > application. This allows for example the homescreen to keep track of > Audio on top pannel. On the opposite AAAA controller also accept input > events coming from external services (eg: vehicle signalling agent). > This second model allows for example to adjust master volume to car > speed, or to prevent the phone from ringing when reverse gear is engaged. > > Fulup > > On 22/08/17 08:02, Takashi Matsuzawa wrote: >> Hello. >> I am looking into the AAAA architecture diagram. >> >> Just for my better understanding, how e.g. an iPod expected to fit to >> this diagram? >> >> It might be primarily audio source device, with several available media >> (bluetooth, USB, etc.). >> Do we have just one "iPod" binding and corresponding HAL, or it is >> better just hidden below ALSA, etc. APIs? >> >> Also how about microphone input (for voice commands) - such input should >> also be routed by this AAAA and apps should be using the AAAA APIs to >> obtain data (there may be additional module in between audio data API >> and application logic for speech recognition, etc.?) >> >> >> ------------------------------------------------------------------------ >> *From:* automotive-discussions-bounces at lists.linuxfoundation.org >> on behalf of >> Fulup Ar Foll >> *Sent:* Thursday, August 17, 2017 9:00 AM >> *To:* automotive-discussions at lists.linuxfoundation.org >> *Subject:* [agl-discussions] AAAA (AGL Advance Audio Agent) Controller >> Binding. >> FYI, >> >> I pushed on Github an Alpha version of the Controller Application >> Framework Binding for? AAAA >> >> As discussed in San Jose, the controller was the missing part in AAAA >> architecture, and it was decided to put resources to fix that issue >> before October AMM. You may find on github current work in progress. As >> today, I hope that I implements every needed features (let me know if I >> miss something). Integration with AAAA is still cooking, nevertheless as >> Microchip made good progress, we should have a version integrated with >> Unicens HALs before the end of the month. On the other hand the high >> level API is still under heavy work by Audiokenetics and we may have to >> wait September before playing with it. >> >> You may find my README on >> https://github.com/iotbzh/audio-bindings/blob/master/Controler-afb/README.md > >> >> The controller as well as the rest of AAAA should compile almost strait >> forward on any recent Linux desktop. It used standard AppFW binder >> packages available from https://en.opensuse.org/LinuxAutomotive (Note >> that on Github my code is still under Fulup-Dev branch, I should merge >> in Master my branch with the one from Tobias in the next couple of days). >> >> While the controller was initially designed to address AAAA >> requirements, it is built in a generic manner and should be usable in >> many other contexts (eg: small business logic for demo app, glue to >> agglomerate vehicle signal, fake generator of signals, events, >> application agglomeration of data from multiple sources, ...). >> >> Global concept should hopefully be natural to everyone. The JSON >> configuration file defines a set of controls. As the controller is a >> standard AGL binding, all features are accessible directly from standard >> AppFw/API. The controller leverage every standard AppFw features: >> security, monitoring, log, ... Technically a control is a set of >> action(s) that are executed in order. Those actions can be implemented >> in LUA(script), in native-C(plugin) or through sub-service calls to an >> other AppFw/Binding (eg: ALSA/UCM, Vehicle Signalling, ...). The >> controller also support events handling. It may fire a set of action >> when a given signal is received (eg: adjust volume when speed change, >> prevent phone from rigging when reverse gear is engage, ...) >> >> The LUA interface is pretty complete and provides access to most of >> AppFw API (afb_reply, event, timer, notice, ...). User may also extend >> Lua with its own set of commands through a plugin mechanism. The >> controller handle transparently the conversion from LUA data internal >> representation to JSON-C object as used by AppFw API. This integration >> model might be useful to interface proprietary technologies with >> controls, or to fasten operations that require a higher level of >> performance that would be incompatible with scripting language. >> >> Please provide feedback. >> >> Fulup >> >> _______________________________________________ >> automotive-discussions mailing list >> automotive-discussions at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions > From ryuohno at hagiwara.co.jp Wed Aug 23 06:17:47 2017 From: ryuohno at hagiwara.co.jp (=?iso-2022-jp?B?GyRCQmdMbhsoQiAbJEJONTBsTzohd0drODYbKEI=?=) Date: Wed, 23 Aug 2017 06:17:47 +0000 Subject: [agl-discussions] Repo Tool[Renesas R-Car Porter] In-Reply-To: References: Message-ID: Tanikawa-san, Thank you. I will check my network environment. Regards, R.Ohno > > Hi, > > curl https://storage.googleapis.com/git-repo-downloads/repo works fine for me. > > Please check your network environment especially around firewall or https proxy. > > Regards, > Tadao Tanikawa > > > Hi all, > > > > I build AGL for Renesas R-Car Porter with reference to > > https://wiki.automotivelinux.org/start/building_for_the_renesas_r-car_m2. > > > > I prepared the Repo tool at curl https://storage.googleapis.com/git-repo-downloads/repo> ~ / bin / repo, but "curl: > > (22) The requested URL returned error: 404 Not Found "message will be displayed. > > > > If you say "curl > > http://commondatastorage.googleapis.com/git-repo-downloads/repo> ~ / bin / repo", it seems to be successful. > > > > Is my procedure correct? > > From christian.gromm at microchip.com Wed Aug 23 10:22:09 2017 From: christian.gromm at microchip.com (Christian Gromm) Date: Wed, 23 Aug 2017 12:22:09 +0200 Subject: [agl-discussions] master is broken for rcar gen3 Message-ID: Hi, building master currently fails on my machine with | /home/chris/prj/agl/master/m3_build/tmp/work/aarch64-agl-linux/gstreamer1.0-libav/1.6.3-r0/gst-libav-1.6.3/gst-libs/ext/libav/libavutil/log.c:51:31: fatal error: valgrind/valgrind.h: No such file or directory | #include | ^ | compilation terminated. | I had to apply this patch [1] to /meta-agl/meta-agl-bsp/meta-rcar-gen3/recipes-backport/gstreamer_bp_krogoth/gstreamer1.0-libav.inc to get things going again. Anyone familiar with this issue? thanks, Chris [1] http://lists.openembedded.org/pipermail/openembedded-core/2016-September/126807.html From christian.gromm at microchip.com Thu Aug 24 08:29:02 2017 From: christian.gromm at microchip.com (Christian Gromm) Date: Thu, 24 Aug 2017 10:29:02 +0200 Subject: [agl-discussions] [Rcar gen3] boot stalls Message-ID: <2557575f-d892-8fb5-8879-1bdc100a79de@microchip.com> I've successfully built the Rcar Gen3 master yesterday. However, the boot process stalls (no login, no HDMI output) with these messages: [ OK ] Reached target System Initialization. Starting PowerVR consumer services... [ OK ] Started PowerVR consumer services. [ OK ] Started Weston Wayland Compositor. [ 13.910398] random: crng init done [ 14.135352] audit: type=1400 audit(1503394216.083:2): lsm=SMACK fn=smack_inode_setattr action=denied subject="System" object="_" requested=w pid=3325 comm="weston-keyboard" name="fontconfig" dev="mmcblk1p1" ino=278005 [ 14.154751] audit: type=1300 audit(1503394216.083:2): arch=c00000b7 syscall=53 success=no exit=-13 a0=ffffffffffffff9c a1=aaaac9d82e20 a2=1ed a3=d items=0 ppid=3278 pid=3325 auid=4294967295 uid=200 gid=200 euid=200 suid=200 fsuid=200 egid=200 sgid=200 fsgid=200 tty=tty1 ses=4294967295 comm="weston-keyboard" exe="/usr/libexec/weston-keyboard" subj=System key=(null) [ 14.187020] audit: type=1327 audit(1503394216.083:2): proctitle="/usr/libexec/weston-keyboard" [ 14.294179] audit: type=1400 audit(1503394216.243:3): lsm=SMACK fn=smack_inode_setattr action=denied subject="System" object="_" requested=w pid=3325 comm="weston-keyboard" name="fontconfig" dev="mmcblk1p1" ino=278005 [ 14.313559] audit: type=1300 audit(1503394216.243:3): arch=c00000b7 syscall=53 success=no exit=-13 a0=ffffffffffffff9c a1=aaaac9d7e4e0 a2=1ed a3=d items=0 ppid=3278 pid=3325 auid=4294967295 uid=200 gid=200 euid=200 suid=200 fsuid=200 egid=200 sgid=200 fsgid=200 tty=tty1 ses=4294967295 comm="weston-keyboard" exe="/usr/libexec/weston-keyboard" subj=System key=(null) [ 14.345821] audit: type=1327 audit(1503394216.243:3): proctitle="/usr/libexec/weston-keyboard" thanks, Chris From wminer at linuxfoundation.org Thu Aug 24 12:53:57 2017 From: wminer at linuxfoundation.org (Walt Miner) Date: Thu, 24 Aug 2017 07:53:57 -0500 Subject: [agl-discussions] EG-Connectivity Call delayed 30 minutes today only Message-ID: The SAT call is running long today so they EG Connectivity call will be delayed 30 minutes. -- Walt Miner Engineering Project Manager The Linux Foundation mobile: +1.847.502.7087 Visit us at: automotive.linuxfoundation.org www.linuxfoundation.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wmizuno at jp.adit-jv.com Fri Aug 25 01:10:12 2017 From: wmizuno at jp.adit-jv.com (Mizuno, Wataru (ADITJ/SWG)) Date: Fri, 25 Aug 2017 01:10:12 +0000 Subject: [agl-discussions] ivi-wm protocol Message-ID: <3AF4192FBB4D2C458558336708E9099302982DB5@ky0exch01.adit-jv.com> Hello AGL members, Let me inform you the ivi-wm protocol. This protocol is introduced to latest version of wayland-ivi-extension as replacement of ivi-controller protocol. *ivi-controller protocol is used to communicate between ivi-shell and Window manager/HMI controller. The ivi-wm protocol is introduced to reduce complexity of communication and objects creation. The ivi-controller protocol created ivi-controller surface/layer for every ivi-surface/layer. That made protocol and clients side object creation complicated. On the other hand, the ivi-wm protocol maintains ivi-surface/layer by its ID, so we can avoid them. Further information, you can find here: https://github.com/GENIVI/wayland-ivi-extension/commit/debca0cf621cac85696326f10ecdb844ff5fe6f2 Best regards, ---------------------------------------------------------- ?? ? / Wataru Mizuno Advanced Driver Information Technology Tel: +81-(0)566-56-0946 Extension: (551)43639 ---------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.bollo at iot.bzh Fri Aug 25 09:51:11 2017 From: jose.bollo at iot.bzh (=?UTF-8?B?Sm9zw6k=?= Bollo) Date: Fri, 25 Aug 2017 11:51:11 +0200 Subject: [agl-discussions] [Rcar gen3] boot stalls In-Reply-To: <2557575f-d892-8fb5-8879-1bdc100a79de@microchip.com> References: <2557575f-d892-8fb5-8879-1bdc100a79de@microchip.com> Message-ID: <20170825115111.2fd219ee@d-jobol.iot.bzh> On Thu, 24 Aug 2017 10:29:02 +0200 Christian Gromm wrote: > I've successfully built the Rcar Gen3 master yesterday. > > However, the boot process stalls (no login, no HDMI output) > with these messages: Hello Christian Gromm, It looks like you hadn't copied extended attributes. You should check http://docs.automotivelinux.org/docs/getting_started/en/dev/reference/troubleshooting.html#extended-attributes-must-be-copied Best regards Jos? Bollo > > [ OK ] Reached target System Initialization. > Starting PowerVR consumer services... > [ OK ] Started PowerVR consumer services. > [ OK ] Started Weston Wayland Compositor. > [ 13.910398] random: crng init done > [ 14.135352] audit: type=1400 audit(1503394216.083:2): lsm=SMACK > fn=smack_inode_setattr action=denied subject="System" object="_" > requested=w pid=3325 comm="weston-keyboard" name="fontconfig" > dev="mmcblk1p1" ino=278005 > [ 14.154751] audit: type=1300 audit(1503394216.083:2): > arch=c00000b7 syscall=53 success=no exit=-13 a0=ffffffffffffff9c > a1=aaaac9d82e20 a2=1ed a3=d items=0 ppid=3278 pid=3325 > auid=4294967295 uid=200 gid=200 euid=200 suid=200 fsuid=200 egid=200 > sgid=200 fsgid=200 tty=tty1 ses=4294967295 comm="weston-keyboard" > exe="/usr/libexec/weston-keyboard" subj=System key=(null) > [ 14.187020] audit: type=1327 audit(1503394216.083:2): > proctitle="/usr/libexec/weston-keyboard" > [ 14.294179] audit: type=1400 audit(1503394216.243:3): lsm=SMACK > fn=smack_inode_setattr action=denied subject="System" object="_" > requested=w pid=3325 comm="weston-keyboard" name="fontconfig" > dev="mmcblk1p1" ino=278005 > [ 14.313559] audit: type=1300 audit(1503394216.243:3): > arch=c00000b7 syscall=53 success=no exit=-13 a0=ffffffffffffff9c > a1=aaaac9d7e4e0 a2=1ed a3=d items=0 ppid=3278 pid=3325 > auid=4294967295 uid=200 gid=200 euid=200 suid=200 fsuid=200 egid=200 > sgid=200 fsgid=200 tty=tty1 ses=4294967295 comm="weston-keyboard" > exe="/usr/libexec/weston-keyboard" subj=System key=(null) > [ 14.345821] audit: type=1327 audit(1503394216.243:3): > proctitle="/usr/libexec/weston-keyboard" > > > thanks, > > Chris > > > > > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions From christian.gromm at microchip.com Fri Aug 25 11:22:31 2017 From: christian.gromm at microchip.com (Christian Gromm) Date: Fri, 25 Aug 2017 13:22:31 +0200 Subject: [agl-discussions] [Rcar gen3] boot stalls In-Reply-To: <20170825115111.2fd219ee@d-jobol.iot.bzh> References: <2557575f-d892-8fb5-8879-1bdc100a79de@microchip.com> <20170825115111.2fd219ee@d-jobol.iot.bzh> Message-ID: On 25.08.2017 11:51, Jos? Bollo wrote: > On Thu, 24 Aug 2017 10:29:02 +0200 > Christian Gromm wrote: > >> I've successfully built the Rcar Gen3 master yesterday. >> >> However, the boot process stalls (no login, no HDMI output) >> with these messages: > > Hello Christian Gromm, > > It looks like you hadn't copied extended attributes. You should check > http://docs.automotivelinux.org/docs/getting_started/en/dev/reference/troubleshooting.html#extended-attributes-must-be-copied Actually, I did. Here is how I copied the image sudo tar --extract --xz --numeric-owner --preserve-permissions --preserve-order --totals --xattrs-include='*' --directory=$SDCARD --file=./agl-demo-platform-m3ulcb.tar.xz Something wrong with it? thanks, Chris From wminer at linuxfoundation.org Fri Aug 25 12:12:32 2017 From: wminer at linuxfoundation.org (wminer at linuxfoundation.org) Date: Fri, 25 Aug 2017 12:12:32 +0000 Subject: [agl-discussions] Canceled Event: EG Virtualization @ Fri Sep 8, 2017 7am - 8am (CDT) (automotive-discussions@lists.linuxfoundation.org) Message-ID: <001a114b74dc0df6cd055792dc99@google.com> This event has been canceled and removed from your calendar. Title: EG Virtualization 1. Please join my meeting. https://global.gotomeeting.com/join/728365005 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. Australia: +61 2 9091 7603 Austria: +43 1 2530 22500 Belgium: +32 (0) 27 00 6375 Canada (toll-free): 1 888 299 1889 Canada: +1 (647) 497-9373 Denmark: +45 32 72 03 69 Finland: +358 (0) 923 17 0555 France: +33 (0) 170 950 585 Germany: +49 (0) 692 5736 7208 India (toll-free): 000 800 852 1424 Ireland: +353 (0) 15 255 598 Italy: +39 0 699 26 68 65 Japan (toll-free): 0 120 352 900 Korea, Republic of (toll-free): 0806180880 Netherlands: +31 (0) 707 709 520 New Zealand: +64 9 887 3469 Norway: +47 23 96 01 18 Spain: +34 932 75 1230 Sweden: +46 (0) 853 527 817 Switzerland: +41 (0) 225 4599 60 United Kingdom: +44 (0) 20 3713 5010 United States (toll-free): 1 866 899 4679 United States: +1 (571) 317-3117 Access Code: 728-365-005 Audio PIN: Shown after joining the meeting Meeting ID: 728-365-005 When: Fri Sep 8, 2017 7am ? 8am Central Time Where: https://www.gotomeeting.com/join/728365005 Calendar: automotive-discussions at lists.linuxfoundation.org Who: * Walt Miner - creator * dcauchy at linuxfoundation.org * Jan-Simon Moeller * Noriaki Fukuyasu * Michele Paolino * automotive-discussions at lists.linuxfoundation.org Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account automotive-discussions at lists.linuxfoundation.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 3258 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 3332 bytes Desc: not available URL: From jose.bollo at iot.bzh Fri Aug 25 12:24:44 2017 From: jose.bollo at iot.bzh (=?UTF-8?B?Sm9zw6k=?= Bollo) Date: Fri, 25 Aug 2017 14:24:44 +0200 Subject: [agl-discussions] master is broken for rcar gen3 In-Reply-To: References: Message-ID: <20170825142444.0162718b@d-jobol.iot.bzh> On Wed, 23 Aug 2017 12:22:09 +0200 Christian Gromm wrote: > Hi, > > building master currently fails on my machine with > > | > /home/chris/prj/agl/master/m3_build/tmp/work/aarch64-agl-linux/gstreamer1.0-libav/1.6.3-r0/gst-libav-1.6.3/gst-libs/ext/libav/libavutil/log.c:51:31: > fatal error: valgrind/valgrind.h: No such file or directory > | #include > | ^ > | compilation terminated. > | > > I had to apply this patch [1] to > > /meta-agl/meta-agl-bsp/meta-rcar-gen3/recipes-backport/gstreamer_bp_krogoth/gstreamer1.0-libav.inc > > to get things going again. > > Anyone familiar with this issue? I had not the issue just now but I had the issue sometime ago. I don't remember what was the resolution. Best regards Jos? Bollo > > thanks, > Chris > > > [1] > http://lists.openembedded.org/pipermail/openembedded-core/2016-September/126807.html > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions From jose.bollo at iot.bzh Fri Aug 25 12:37:05 2017 From: jose.bollo at iot.bzh (=?UTF-8?B?Sm9zw6k=?= Bollo) Date: Fri, 25 Aug 2017 14:37:05 +0200 Subject: [agl-discussions] [Rcar gen3] boot stalls In-Reply-To: <2557575f-d892-8fb5-8879-1bdc100a79de@microchip.com> References: <2557575f-d892-8fb5-8879-1bdc100a79de@microchip.com> Message-ID: <20170825143705.7162773b@d-jobol.iot.bzh> On Thu, 24 Aug 2017 10:29:02 +0200 Christian Gromm wrote: > I've successfully built the Rcar Gen3 master yesterday. > > However, the boot process stalls (no login, no HDMI output) > with these messages: After rebuilding, I can see the same errors issued by /usr/libexec/weston-keyboard but it isn't blocking. I have a fully functionnal AGL image running. Best regards Jos? Bollo > > [ OK ] Reached target System Initialization. > Starting PowerVR consumer services... > [ OK ] Started PowerVR consumer services. > [ OK ] Started Weston Wayland Compositor. > [ 13.910398] random: crng init done > [ 14.135352] audit: type=1400 audit(1503394216.083:2): lsm=SMACK > fn=smack_inode_setattr action=denied subject="System" object="_" > requested=w pid=3325 comm="weston-keyboard" name="fontconfig" > dev="mmcblk1p1" ino=278005 > [ 14.154751] audit: type=1300 audit(1503394216.083:2): > arch=c00000b7 syscall=53 success=no exit=-13 a0=ffffffffffffff9c > a1=aaaac9d82e20 a2=1ed a3=d items=0 ppid=3278 pid=3325 > auid=4294967295 uid=200 gid=200 euid=200 suid=200 fsuid=200 egid=200 > sgid=200 fsgid=200 tty=tty1 ses=4294967295 comm="weston-keyboard" > exe="/usr/libexec/weston-keyboard" subj=System key=(null) > [ 14.187020] audit: type=1327 audit(1503394216.083:2): > proctitle="/usr/libexec/weston-keyboard" > [ 14.294179] audit: type=1400 audit(1503394216.243:3): lsm=SMACK > fn=smack_inode_setattr action=denied subject="System" object="_" > requested=w pid=3325 comm="weston-keyboard" name="fontconfig" > dev="mmcblk1p1" ino=278005 > [ 14.313559] audit: type=1300 audit(1503394216.243:3): > arch=c00000b7 syscall=53 success=no exit=-13 a0=ffffffffffffff9c > a1=aaaac9d7e4e0 a2=1ed a3=d items=0 ppid=3278 pid=3325 > auid=4294967295 uid=200 gid=200 euid=200 suid=200 fsuid=200 egid=200 > sgid=200 fsgid=200 tty=tty1 ses=4294967295 comm="weston-keyboard" > exe="/usr/libexec/weston-keyboard" subj=System key=(null) > [ 14.345821] audit: type=1327 audit(1503394216.243:3): > proctitle="/usr/libexec/weston-keyboard" > > > thanks, > > Chris > > > > > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions From christian.gromm at microchip.com Fri Aug 25 13:00:20 2017 From: christian.gromm at microchip.com (Christian Gromm) Date: Fri, 25 Aug 2017 15:00:20 +0200 Subject: [agl-discussions] [Rcar gen3] boot stalls In-Reply-To: <20170825143705.7162773b@d-jobol.iot.bzh> References: <2557575f-d892-8fb5-8879-1bdc100a79de@microchip.com> <20170825143705.7162773b@d-jobol.iot.bzh> Message-ID: On 25.08.2017 14:37, Jos? Bollo wrote: > On Thu, 24 Aug 2017 10:29:02 +0200 > Christian Gromm wrote: > >> I've successfully built the Rcar Gen3 master yesterday. >> >> However, the boot process stalls (no login, no HDMI output) >> with these messages: > > After rebuilding, I can see the same errors issued > by /usr/libexec/weston-keyboard but it isn't blocking. I have a fully > functionnal AGL image running. > Hmm. Lucky you :) Any idea what might be the problem that my board refuses to continue booting after these messages are thrown? thanks, Chris From m.paolino at virtualopensystems.com Fri Aug 25 13:31:13 2017 From: m.paolino at virtualopensystems.com (Michele Paolino) Date: Fri, 25 Aug 2017 15:31:13 +0200 Subject: [agl-discussions] [EG-VIRT] telephonic conference report, August 25th 2017, 2PM CEST Message-ID: Hello AGL folks, Please find here below the report of the last EG-VIRT meeting, which has been updated on the wiki as well. Points of interest: - During the last month, quite an intensive work has been done in the direction of the EG-VIRT yocto layer and KVM on ARMv8. - EG-VIRT Yocto layer - A new agl-egvirt MACHINE_FEATURE has been created. - two patches merged: the first in meta-agl (change 10507 ) and the other one meta-agl-devel (change 10476 ) - the eg-virt layer is in the meta-agl-devel repository - to enable it, add the argument "agl-egvirt" when running the aglsetup.sh script - KVM on Renesas R-Car M3 - one patch merged in meta-agl-devel (change 10547 ) - one patch under review in meta-agl (change 10597 ) - EG-VIRT next steps: - finalize the support for KVM on the M3 - Add virtualization/KVM support for Renesas R-Car H3 - Integrate meta-virtualization functions in AGL - The EG-VIRT BoF session has been accepted for AGL AMM Fall meeting, you are all invited - EG-VIRT in the news!! The project has been mentioned by an official AGL press release , which has been mentioned/commented/described by several other websites - Next EG-VIRT meeting: September 22nd, 2017 Regards, -- Michele Paolino Virtualization Architect Virtual Open Systems -------------- next part -------------- An HTML attachment was scrubbed... URL: From toshikazu_ohiwa at mail.toyota.co.jp Fri Aug 25 17:08:39 2017 From: toshikazu_ohiwa at mail.toyota.co.jp (TOSHIKAZU OHIWA) Date: Fri, 25 Aug 2017 17:08:39 +0000 Subject: [agl-discussions] Application guide of the Sound Manager Message-ID: <71973DB6B28D024E9B14A69F0B05E57F7CBD9994@APLQDTD1028MB14.tmc03.twfr.toyota.co.jp> Hi We have pushed document based on the architecture of Genivi Audio Management proposed in San Jose. And the sound manager binding is going to be pushed soon. There are document, source code and some samples. Sample applications are based on CES applications and they are following the sequence of audio management sequence at the slide 14 in the following (This is proposed in San Jose) We are welcome for any feedbacks Best Regards Toshikazu Ohiwa From wminer at linuxfoundation.org Fri Aug 25 22:28:50 2017 From: wminer at linuxfoundation.org (wminer at linuxfoundation.org) Date: Fri, 25 Aug 2017 22:28:50 +0000 Subject: [agl-discussions] Canceled Event: App FW & Security Biweekly Call @ Wed Aug 30, 2017 8am - 9am (CDT) (automotive-discussions@lists.linuxfoundation.org) Message-ID: <94eb2c0e6ab81d7b3605579b7864@google.com> This event has been canceled and removed from your calendar. Title: App FW & Security Biweekly Call 1. Please join my meeting. https://global.gotomeeting.com/join/324926029 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. Australia: +61 2 8355 1020 Austria: +43 1 2530 22520 Belgium: +32 (0) 28 08 4368 Canada: +1 (647) 497-9353 Canada (toll-free): 1 888 455 1389 Denmark: +45 69 91 89 28 Finland: +358 (0) 942 59 7850 France: +33 (0) 170 950 594 Germany: +49 (0) 692 5736 7317 India (toll-free): 000 800 100 7855 Ireland: +353 (0) 15 360 728 Italy: +39 0 247 92 13 01 Japan (toll-free): 0 120 663 800 Korea, Republic of (toll-free): 0806150880 Netherlands: +31 (0) 208 080 219 New Zealand: +64 9 280 6302 Norway: +47 75 80 32 07 Spain: +34 911 82 9906 Sweden: +46 (0) 852 500 186 Switzerland: +41 (0) 435 0167 13 United Kingdom: +44 (0) 330 221 0088 United States: +1 (646) 749-3129 United States (toll-free): 1 877 568 4106 Access Code: 324-926-029 Audio PIN: Shown after joining the meeting Meeting ID: 324-926-029 When: Wed Aug 30, 2017 8am ? 9am Central Time Where: https://www.gotomeeting.com/join/324926029 Calendar: automotive-discussions at lists.linuxfoundation.org Who: * Walt Miner - creator * Noriaki Fukuyasu * dcauchy at linuxfoundation.org * automotive-discussions at lists.linuxfoundation.org Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account automotive-discussions at lists.linuxfoundation.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2964 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 3034 bytes Desc: not available URL: From wminer at linuxfoundation.org Fri Aug 25 22:28:57 2017 From: wminer at linuxfoundation.org (wminer at linuxfoundation.org) Date: Fri, 25 Aug 2017 22:28:57 +0000 Subject: [agl-discussions] Canceled Event: [AGL-SAT] Biweekly Call @ Thu Aug 31, 2017 8am - 9am (CDT) (automotive-discussions@lists.linuxfoundation.org) Message-ID: <001a1141194a91052a05579b788e@google.com> This event has been canceled and removed from your calendar. Title: [AGL-SAT] Biweekly Call AGL-SAT Biweekly Meeting Please join my meeting from your computer, tablet or smartphone. https://global.gotomeeting.com/join/796425741 You can also dial in using your phone. United States (Toll-free) 1 877 309 2070 United States +1 (312) 757-3119 Access Code: 796-425-741 More phone numbers Australia +61 2 8355 1034 Austria +43 7 2088 0716 Belgium +32 (0) 28 93 7002 Canada (Toll-free) 1 877 777 3281 Canada +1 (647) 497-9372 Denmark +45 69 91 84 58 Finland +358 (0) 923 17 0556 France +33 (0) 170 950 590 Germany +49 (0) 692 5736 7206 India (Toll-free) 000 800 100 8227 Ireland +353 (0) 19 030 053 Italy +39 0 699 26 68 65 Japan (Toll-free) 0 120 242 200 Korea, Republic of (Toll-free) 0806180880 Netherlands +31 (0) 208 080 759 New Zealand +64 9 974 9579 Norway +47 21 04 30 59 Spain +34 931 76 1534 Sweden +46 (0) 852 500 691 Switzerland +41 (0) 435 0026 89 United Kingdom +44 (0) 20 3713 5011 First GoToMeeting? Try a test session: http://help.citrix.com/getready When: Thu Aug 31, 2017 8am ? 9am Central Time Where: https://global.gotomeeting.com/join/796425741 Calendar: automotive-discussions at lists.linuxfoundation.org Who: * Walt Miner - creator * automotive-discussions at lists.linuxfoundation.org * Noriaki Fukuyasu * dcauchy at linuxfoundation.org Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account automotive-discussions at lists.linuxfoundation.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 3009 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 3080 bytes Desc: not available URL: From wminer at linuxfoundation.org Fri Aug 25 22:46:29 2017 From: wminer at linuxfoundation.org (Walt Miner) Date: Fri, 25 Aug 2017 17:46:29 -0500 Subject: [agl-discussions] This Week in AGL #5 Message-ID: The newsletter is back after a two-week vacation. This is the fifth edition of the weekly AGL newsletter to highlight work going on around the AGL Community. Feedback and comments welcome. wminer at linuxfoundation.org Wednesday and Thursday of this week is the face-to-face meeting in Yokohama, Japan. If you are attending in person or on the phone please bring your questions about how to create an AGL Application or using Service Binders. Fulup Le Foll from IoT.bzh will walk through the creation of an AGL Application in a hands-on session. Scott Murray and Matt Porter from Konsulko will be on hand to discuss the latest service binders they have created using API V2. We really want these sessions to be interactive so bring your questions and we can help get you on the path to success. https://wiki.automotivelinux.org/agl-distro/aug2017-f2f See you in Yokohama! Walt *Highlights* 1) Charming Chinook 3.0.5 was released on Tuesday. Thanks to everyone who pitched in to make this happen. Thanks especially to our Release Manager, Jan-Simon Moeller, who made sure everything was in its right place, and Changhyeok Bae who made the update to Yocto Project 2.1.3 happen. https://lists.linuxfoundation.org/pipermail/automotive-discussions/2017-August/004786.html 2) The first step to opening the master branch for the Electric Eel release is updating to the upstream Yocto project pyro branch. We have had some obstacles getting this functional for all of the boards, so the merge to master has been delayed to the first week in September. For more information on the progress Jira issue SPEC-646. https://jira.automotivelinux.org/browse/SPEC-646 3) After getting pyro merged to master we complete the Yocto layer reorganization. See Jira issue SPEC-145 for the major work and SPEC-802 for information on keeping track of backports in the future. https://jira.automotivelinux.org/browse/SPEC-145 https://jira.automotivelinux.org/browse/SPEC-802 4) The merge window for the first Daring Dab patch (4.0.1) release closes September 1. 5) The schedule for the Dresden All Member Meeting was posted. We will have more information on keynote speakers in a few weeks. Also, we will make an announcement about some training opportunities on Friday shortly. This is shaping up to be our best AMM yet. http://events.linuxfoundation.org/events/agl-member-meeting-fall/program/schedule *Upcoming Face-to-Face Meeting Opportunities * 1) App FW and Audio Architecture Deep Dive ? Aug 30 ? 31 in Yokohama, Japan https://wiki.automotivelinux.org/agl-distro/aug2017-f2f 2) Vehicle Messaging and CAN ? Sep 5 ? 7 in Vannes, France https://wiki.automotivelinux.org/agl-distro/sep2017-can-f2f 3) Audio Workshop ? Sep 13 ? 14 in Montreal, Canada https://wiki.automotivelinux.org/agl-distro/sep2017-audio-f2f *AGL All Member Meeting* Event web site: http://events.linuxfoundation.org/events/agl-member-meeting-fall 1) The schedule is now posted. http://events.linuxfoundation.org/events/agl-member-meeting-fall/program/schedule 2) The hotel block is now available for booking. If you need to check out after Friday, please contact events at automotivelinux.org to help with arrangement. 3) There will be face-to-face System Architecture Team and Expert Group meetings on October 20. Please plan to stay for this if you are a member of these teams and add your name to attendee list on the wiki. https://wiki.automotivelinux.org/agl-distro/oct2017-f2f 4) Look for announcements next week about training classes to be held on Friday, October 20. *This week?s meetings:* *Tuesday Aug 29* 13:00 UTC - Weekly developer call Open to anyone with questions about AGL code or issues they may be having. Conference Info: *https://wiki.automotivelinux.org/dev-call-info * *Wednesday - Thursday Aug 30 ? 31* Face to face meeting in Yokohama https://wiki.automotivelinux.org/agl-distro/aug2017-f2f The full AGL calendar can always be found at *https://calendar.google.com/calendar/embed?src=linuxfoundation.org_i0rs8amkm0flde7kq5u4b9tef4%40group.calendar.google.com * -- Walt Miner Engineering Project Manager The Linux Foundation mobile: +1.847.502.7087 Visit us at: automotive.linuxfoundation.org www.linuxfoundation.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.desneux at iot.bzh Fri Aug 25 23:04:17 2017 From: stephane.desneux at iot.bzh (Stephane Desneux) Date: Sat, 26 Aug 2017 01:04:17 +0200 Subject: [agl-discussions] [Rcar gen3] boot stalls In-Reply-To: References: <2557575f-d892-8fb5-8879-1bdc100a79de@microchip.com> <20170825143705.7162773b@d-jobol.iot.bzh> Message-ID: <3d922eb1-3ad2-a64b-25a4-953a27ccc790@iot.bzh> Hi Chris, Just to confirm: is it ok with a DD image ? ATM we're not "far" from DD, so it should be fairly easy to check/bisect on the master branch between DD and now... Also, I wonder why your issue is so unique (I mean: you seem lucky with Murphy's law :)) Nothing special in your environment ? At the end, does disabling weston-keyboard help ? (a way to disable the keyboard seems to be here: https://github.com/GENIVI/meta-genivi-dev/commit/b63507a35b1b3156c4aa30201994210ab9f4bacd ) Best regards, --- Stephane Desneux - CTO - IoT.bzh stephane.desneux at iot.bzh - www.iot.bzh On 25/08/17 15:00, Christian Gromm wrote: > On 25.08.2017 14:37, Jos? Bollo wrote: >> On Thu, 24 Aug 2017 10:29:02 +0200 >> Christian Gromm wrote: >> >>> I've successfully built the Rcar Gen3 master yesterday. >>> >>> However, the boot process stalls (no login, no HDMI output) >>> with these messages: >> >> After rebuilding, I can see the same errors issued >> by /usr/libexec/weston-keyboard but it isn't blocking. I have a fully >> functionnal AGL image running. >> > > Hmm. Lucky you :) > > Any idea what might be the problem that my board > refuses to continue booting after these messages > are thrown? > > thanks, > Chris > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions From stephane.desneux at iot.bzh Fri Aug 25 23:21:18 2017 From: stephane.desneux at iot.bzh (Stephane Desneux) Date: Sat, 26 Aug 2017 01:21:18 +0200 Subject: [agl-discussions] Application guide of the Sound Manager In-Reply-To: <71973DB6B28D024E9B14A69F0B05E57F7CBD9994@APLQDTD1028MB14.tmc03.twfr.toyota.co.jp> References: <71973DB6B28D024E9B14A69F0B05E57F7CBD9994@APLQDTD1028MB14.tmc03.twfr.toyota.co.jp> Message-ID: <541c5c3a-8b6b-1ae8-e1f8-838621ad2f9d@iot.bzh> Hi Ohiwa-san, I was unable to find any content in https://gerrit.automotivelinux.org/gerrit/gitweb?p=staging%2Fsoundmanager.git;a=summary (empty repo) Is there a mistake in url or git push ? Was some content pushed somewhere else ? Best regards, --- Stephane Desneux - CTO - IoT.bzh stephane.desneux at iot.bzh - www.iot.bzh On 25/08/17 19:08, TOSHIKAZU OHIWA wrote: > Hi > > We have pushed document based on the architecture of Genivi Audio Management proposed in San Jose. > > > And the sound manager binding is going to be pushed soon. > There are document, source code and some samples. > Sample applications are based on CES applications and they are following the sequence of audio management sequence at the slide 14 in the following > (This is proposed in San Jose) > > We are welcome for any feedbacks > > Best Regards > Toshikazu Ohiwa > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions > From knimitz at witz-inc.co.jp Sun Aug 27 11:37:32 2017 From: knimitz at witz-inc.co.jp (Kazumasa Mitsunari) Date: Sun, 27 Aug 2017 20:37:32 +0900 Subject: [agl-discussions] Application guide of the Sound Manager In-Reply-To: <541c5c3a-8b6b-1ae8-e1f8-838621ad2f9d@iot.bzh> References: <71973DB6B28D024E9B14A69F0B05E57F7CBD9994@APLQDTD1028MB14.tmc03.twfr.toyota.co.jp> <541c5c3a-8b6b-1ae8-e1f8-838621ad2f9d@iot.bzh> Message-ID: Hi Stephane I pushed but change request had not been submitted in that time, sorry. I pushed again and you can find it with the same uri now. Would you clone the repository and browse ApplicationGuide.md? Best Regards Kazumasa Mitsunari On 2017?08?26? 08:21, Stephane Desneux wrote: > Hi Ohiwa-san, > > I was unable to find any content in > https://gerrit.automotivelinux.org/gerrit/gitweb?p=staging%2Fsoundmanager.git;a=summary > (empty repo) > > Is there a mistake in url or git push ? Was some content pushed somewhere else ? > > Best regards, > --- > Stephane Desneux - CTO - IoT.bzh > stephane.desneux at iot.bzh - www.iot.bzh > > On 25/08/17 19:08, TOSHIKAZU OHIWA wrote: >> Hi >> >> We have pushed document based on the architecture of Genivi Audio Management proposed in San Jose. >> >> >> And the sound manager binding is going to be pushed soon. >> There are document, source code and some samples. >> Sample applications are based on CES applications and they are following the sequence of audio management sequence at the slide 14 in the following >> (This is proposed in San Jose) >> >> We are welcome for any feedbacks >> >> Best Regards >> Toshikazu Ohiwa >> _______________________________________________ >> automotive-discussions mailing list >> automotive-discussions at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions >> > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions From christian.gromm at microchip.com Mon Aug 28 10:28:14 2017 From: christian.gromm at microchip.com (Christian Gromm) Date: Mon, 28 Aug 2017 12:28:14 +0200 Subject: [agl-discussions] [Rcar gen3] boot stalls In-Reply-To: <3d922eb1-3ad2-a64b-25a4-953a27ccc790@iot.bzh> References: <2557575f-d892-8fb5-8879-1bdc100a79de@microchip.com> <20170825143705.7162773b@d-jobol.iot.bzh> <3d922eb1-3ad2-a64b-25a4-953a27ccc790@iot.bzh> Message-ID: On 26.08.2017 01:04, Stephane Desneux wrote: > Hi Chris, > > Just to confirm: is it ok with a DD image ? I did repo init -b dab -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo + repo sync --force-sync + source ./meta-agl/scripts/aglsetup.sh -m m3ulcb -b m3_build agl-devel agl-localdev agl-demo agl-appfw-smack --force + bitbake agl-demo-platform Problem is still there... > > ATM we're not "far" from DD, so it should be fairly easy to check/bisect on the > master branch between DD and now... > > Also, I wonder why your issue is so unique (I mean: you seem lucky with Murphy's > law :)) Nothing special in your environment ? I've absolutely no idea; seems like I'm the lucky one :) And no, nothing special on my system. Just a regular Ubuntu 16.04 > > At the end, does disabling weston-keyboard help ? > (a way to disable the keyboard seems to be here: > https://github.com/GENIVI/meta-genivi-dev/commit/b63507a35b1b3156c4aa30201994210ab9f4bacd > ) I'll give this a try... thanks, Chris From knimitz at witz-inc.co.jp Tue Aug 29 12:49:27 2017 From: knimitz at witz-inc.co.jp (Kazumasa Mitsunari) Date: Tue, 29 Aug 2017 21:49:27 +0900 Subject: [agl-discussions] Application guide of the Sound Manager In-Reply-To: <71973DB6B28D024E9B14A69F0B05E57F7CBD9994@APLQDTD1028MB14.tmc03.twfr.toyota.co.jp> References: <71973DB6B28D024E9B14A69F0B05E57F7CBD9994@APLQDTD1028MB14.tmc03.twfr.toyota.co.jp> Message-ID: <455a221d-a82e-84de-d5c8-7c647d37fec2@witz-inc.co.jp> Hi everyone, I pushed source code (sound manager binding) to the staging repository. We are going to introduce it tomorrow afternoon based on Genivi Audio Architecture proposed in San Jose. https://wiki.automotivelinux.org/agl-distro/aug2017-f2f Best Regards Kazumasa Mitsunari On 2017?08?26? 02:08, TOSHIKAZU OHIWA wrote: > Hi > > We have pushed document based on the architecture of Genivi Audio Management proposed in San Jose. > > > And the sound manager binding is going to be pushed soon. > There are document, source code and some samples. > Sample applications are based on CES applications and they are following the sequence of audio management sequence at the slide 14 in the following > (This is proposed in San Jose) > > We are welcome for any feedbacks > > Best Regards > Toshikazu Ohiwa > _______________________________________________ > automotive-discussions mailing list > automotive-discussions at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/automotive-discussions -- ******************************* WITZ Corporation ??????? ??????? Base Technology Development Dept. ?Advanced Basic Technology Sect. ?Kazumasa Mitsunari Mail:knimitz at witz-inc.co.jp ******************************* From takehiro.ushijima at itage.co.jp Wed Aug 30 13:55:14 2017 From: takehiro.ushijima at itage.co.jp (Takehiro Ushijima) Date: Wed, 30 Aug 2017 22:55:14 +0900 Subject: [agl-discussions] Vaapi doesn't work with gstreamer on Intel board Message-ID: <034001d32197$9adf9a80$d09ecf80$@itage.co.jp> Hi all, I have created a new ticket about gstreamer on Intel's Joule or Minnow board. https://jira.automotivelinux.org/projects/SPEC/issues/SPEC-843?filter=allopenissues My expectation is to use vaapi for encoder as hardware accerelation, but encodebin was used instead of vappi. CPU usage is high at any time while using encodebin. If you have any solutions, please let me know. Best Regards, Takehiro Ushijima From penggang.wei at cn.alps.com Thu Aug 31 02:04:25 2017 From: penggang.wei at cn.alps.com (Penggang Wei) Date: Thu, 31 Aug 2017 02:04:25 +0000 Subject: [agl-discussions] phone qml can not add a websocket(unhandled http status code:500) Message-ID: Hi all: When I add a websocket in the ContactsView.qml, when the ContactsView.qml push or popup , I transfer the message to the websocket, In the first eight times is ok, but the http status error will be appeared in the ninth, just like this, could you give me some advice Picture 1: ERROR???? Picture 2:the server code Picture 3:websocket in qml Log: Aug 31 01:29:17 porter afm-system-daemon[343]: NOTICE: -- INSTALLING widget /usr/AGL/apps/phone.wgt to /var/local/lib/afm/applications -- [/usr/src/debug/af-main/master+gitAUTOINC+92736672c9-r0/git/src/wgtpkg-install.c:466] Aug 31 01:29:19 porter systemd[389]: Reloading. Aug 31 01:29:19 porter systemd[389]: [/usr/local/lib/systemd/user/afm-appli-settings at 0.1.service:26] Failed to add dependency on afm-api-ws-wifi-manager, ignoring: Invalid argument Aug 31 01:29:19 porter systemd[389]: [/usr/local/lib/systemd/user/afm-appli-settings at 0.1.service:27] Failed to add dependency on afm-api-ws-wifi-manager, ignoring: Invalid argument Aug 31 01:29:19 porter systemd[389]: [/usr/local/lib/systemd/user/afm-appli-settings at 0.1.service:28] Failed to add dependency on afm-api-ws-Bluetooth-Manager, ignoring: Invalid argument Aug 31 01:29:19 porter systemd[389]: [/usr/local/lib/systemd/user/afm-appli-settings at 0.1.service:29] Failed to add dependency on afm-api-ws-Bluetooth-Manager, ignoring: Invalid argument Aug 31 01:29:19 porter systemd[389]: Started AGL user config. Aug 31 01:29:19 porter systemd[389]: Stopped target Sockets. Aug 31 01:29:19 porter systemd[389]: Stopping Sockets. Aug 31 01:29:19 porter systemd[389]: Reached target Sockets. Aug 31 01:29:25 porter systemd[1]: Starting Cleanup of Temporary Directories... Aug 31 01:29:25 porter systemd-tmpfiles[7431]: Failed to open directory /var/tmp: Too many levels of symbolic links Aug 31 01:29:25 porter systemd[1]: Started Cleanup of Temporary Directories. Aug 31 01:29:29 porter HomeScreen[492]: launch "phone at 0.1" Aug 31 01:29:29 porter systemd[389]: Starting This is a demo phone application... Aug 31 01:29:29 porter systemd[389]: Started This is a demo phone application. Aug 31 01:29:29 porter HomeScreen[492]: pid: 7459 Aug 31 01:29:29 porter HomeScreen[492]: makeMeVisible 7459 Aug 31 01:29:29 porter WindowManager[431]: -=[showAppLayer]=- Aug 31 01:29:29 porter WindowManager[431]: id= "phone at 0.1" , pid= 7459 Aug 31 01:29:29 porter WindowManager[431]: New app 7459 Aug 31 01:29:29 porter WindowManager[431]: No layer to show for app(pid=7459) Aug 31 01:29:29 porter WindowManager[431]: Layer render order (ivi-layer-id), 0 bgApps: Aug 31 01:29:29 porter WindowManager[431]: m_showLayers[3]=103 Aug 31 01:29:29 porter WindowManager[431]: Screen render order 0, 1 layers Aug 31 01:29:30 porter afb-daemon[7459]: NOTICE: API monitor added [/usr/src/debug/af-binder/master+gitAUTOINC+b2114e0f62-r0/git/src/afb-apiset.c:252,afb_apiset_add] Aug 31 01:29:30 porter afb-daemon[7459]: NOTICE: API auth added [/usr/src/debug/af-binder/master+gitAUTOINC+b2114e0f62-r0/git/src/afb-apiset.c:252,afb_apiset_add] Aug 31 01:29:30 porter afb-daemon[7459]: NOTICE: API dbus added [/usr/src/debug/af-binder/master+gitAUTOINC+b2114e0f62-r0/git/src/afb-apiset.c:252,afb_apiset_add] Aug 31 01:29:30 porter afb-daemon[7459]: NOTICE: API telephony added [/usr/src/debug/af-binder/master+gitAUTOINC+b2114e0f62-r0/git/src/afb-apiset.c:252,afb_apiset_add] Aug 31 01:29:30 porter afb-daemon[7459]: NOTICE: API auth starting... [/usr/src/debug/af-binder/master+gitAUTOINC+b2114e0f62-r0/git/src/afb-apiset.c:362,start_api] Aug 31 01:29:30 porter afb-daemon[7459]: NOTICE: API auth started [/usr/src/debug/af-binder/master+gitAUTOINC+b2114e0f62-r0/git/src/afb-apiset.c:377,start_api] Aug 31 01:29:30 porter afb-daemon[7459]: NOTICE: API dbus starting... [/usr/src/debug/af-binder/master+gitAUTOINC+b2114e0f62-r0/git/src/afb-apiset.c:362,start_api] Aug 31 01:29:30 porter afb-daemon[7459]: NOTICE: API dbus started [/usr/src/debug/af-binder/master+gitAUTOINC+b2114e0f62-r0/git/src/afb-apiset.c:377,start_api] Aug 31 01:29:30 porter afb-daemon[7459]: NOTICE: API monitor starting... [/usr/src/debug/af-binder/master+gitAUTOINC+b2114e0f62-r0/git/src/afb-apiset.c:362,start_api] Aug 31 01:29:30 porter afb-daemon[7459]: NOTICE: API monitor started [/usr/src/debug/af-binder/master+gitAUTOINC+b2114e0f62-r0/git/src/afb-apiset.c:377,start_api] Aug 31 01:29:30 porter afb-daemon[7459]: NOTICE: API telephony starting... [/usr/src/debug/af-binder/master+gitAUTOINC+b2114e0f62-r0/git/src/afb-apiset.c:362,start_api] Aug 31 01:29:30 porter afb-daemon[7459]: ERROR: [API telephony] obex client init Aug 31 01:29:30 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_client.c:66,?] Aug 31 01:29:30 porter afb-daemon[7459]: ERROR: [API telephony] obex signal-finish Aug 31 01:29:30 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_client.c:98,?] Aug 31 01:29:30 porter afb-daemon[7459]: ERROR: [API telephony] obex deal file init Aug 31 01:29:30 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_deal_pb_file.c:228,?] Aug 31 01:29:30 porter afb-daemon[7459]: ERROR: [API telephony] modem_path: /hfp/001BEBCA0F00_D855A34C5EB6 Aug 31 01:29:30 porter afb-daemon[7459]: [../../telephony-binding/telephony-binding.c:285,?] Aug 31 01:29:30 porter afb-daemon[7459]: ERROR: [API telephony] dialing_call signal enter Aug 31 01:29:30 porter afb-daemon[7459]: [../../telephony-binding/gdbus/ofono_voicecallmanager.c:137,?] Aug 31 01:29:30 porter afb-daemon[7459]: NOTICE: API telephony started [/usr/src/debug/af-binder/master+gitAUTOINC+b2114e0f62-r0/git/src/afb-apiset.c:377,start_api] Aug 31 01:29:30 porter afb-daemon[7459]: NOTICE: Waiting port=1026 rootdir=/var/local/lib/afm/applications/phone/0.1 [/usr/src/debug/af-binder/master+gitAUTOINC+b2114e0f62-r0/git/src/main.c:267,start_http_server] Aug 31 01:29:30 porter afb-daemon[7459]: NOTICE: Browser URL= http://localhost:1026 [/usr/src/debug/af-binder/master+gitAUTOINC+b2114e0f62-r0/git/src/main.c:268,start_http_server] Aug 31 01:29:30 porter afb-daemon[7459]: Using Wayland-EGL Aug 31 01:29:31 porter afb-daemon[7459]: Using the 'ivi-shell' shell integration Aug 31 01:29:31 porter afb-daemon[7459]: qrc:/Dialer.qml:493:31: Unable to assign int to QQuickAnchorLine Aug 31 01:29:31 porter afb-daemon[7459]: qrc:/Dialer.qml:604:31: Unable to assign int to QQuickAnchorLine Aug 31 01:29:31 porter afb-daemon[7459]: qrc:/Dialer.qml:710:31: Unable to assign int to QQuickAnchorLine Aug 31 01:29:31 porter WindowManager[431]: -=[notificationFunc_non_static]=- Aug 31 01:29:31 porter WindowManager[431]: Notification from weston! Aug 31 01:29:31 porter WindowManager[431]: retrieved for pid=7464 gpid=7459 spid=7459 Aug 31 01:29:31 porter WindowManager[431]: translate pid 7464 to Gpid 7459 Aug 31 01:29:31 porter WindowManager[431]: This surface (7464) is 1st one for app (7459) Aug 31 01:29:31 porter WindowManager[431]: retrieved for pid=7464 gpid=7459 spid=7459 Aug 31 01:29:31 porter WindowManager[431]: translate pid 7464 to Gpid 7459 Aug 31 01:29:31 porter WindowManager[431]: -=[surfaceCallbackFunction_non_static]=- Aug 31 01:29:31 porter WindowManager[431]: surfaceCallbackFunction_non_static changes for surface 7464 Aug 31 01:29:31 porter WindowManager[431]: ILM_NOTIFICATION_CONTENT_AVAILABLE Aug 31 01:29:31 porter WindowManager[431]: retrieved for pid=7464 gpid=7459 spid=7459 Aug 31 01:29:31 porter WindowManager[431]: translate pid 7464 to Gpid 7459 Aug 31 01:29:31 porter WindowManager[431]: -=[surfaceCallbackFunction_non_static]=- Aug 31 01:29:31 porter WindowManager[431]: surfaceCallbackFunction_non_static changes for surface 7464 Aug 31 01:29:31 porter WindowManager[431]: ILM_NOTIFICATION_CONFIGURED Aug 31 01:29:31 porter WindowManager[431]: surfaceProperties 7464 Aug 31 01:29:31 porter WindowManager[431]: surfaceProperties.origSourceWidth: 1080 Aug 31 01:29:31 porter WindowManager[431]: surfaceProperties.origSourceHeight: 1487 Aug 31 01:29:31 porter WindowManager[431]: -=[addSurfaceToAppLayer]=- Aug 31 01:29:31 porter WindowManager[431]: surfaceId 7464 Aug 31 01:29:31 porter WindowManager[431]: No layer found, create new for app(pid=7459) Aug 31 01:29:31 porter WindowManager[431]: -=[createNewLayer]=- Aug 31 01:29:31 porter WindowManager[431]: layerId 10207459 Aug 31 01:29:31 porter WindowManager[431]: -=[notificationFunc_non_static]=- Aug 31 01:29:31 porter WindowManager[431]: Notification from weston! Aug 31 01:29:31 porter WindowManager[431]: retrieved for pid=7464 gpid=7459 spid=7459 Aug 31 01:29:31 porter WindowManager[431]: translate pid 7464 to Gpid 7459 Aug 31 01:29:31 porter WindowManager[431]: -=[surfaceCallbackFunction_non_static]=- Aug 31 01:29:31 porter WindowManager[431]: surfaceCallbackFunction_non_static changes for surface 7464 Aug 31 01:29:31 porter WindowManager[431]: ILM_NOTIFICATION_SOURCE_RECT Aug 31 01:29:31 porter WindowManager[431]: retrieved for pid=7464 gpid=7459 spid=7459 Aug 31 01:29:31 porter WindowManager[431]: translate pid 7464 to Gpid 7459 Aug 31 01:29:31 porter WindowManager[431]: -=[surfaceCallbackFunction_non_static]=- Aug 31 01:29:31 porter WindowManager[431]: surfaceCallbackFunction_non_static changes for surface 7464 Aug 31 01:29:31 porter WindowManager[431]: ILM_NOTIFICATION_DEST_RECT Aug 31 01:29:31 porter WindowManager[431]: retrieved for pid=7464 gpid=7459 spid=7459 Aug 31 01:29:31 porter WindowManager[431]: translate pid 7464 to Gpid 7459 Aug 31 01:29:31 porter WindowManager[431]: -=[surfaceCallbackFunction_non_static]=- Aug 31 01:29:31 porter WindowManager[431]: surfaceCallbackFunction_non_static changes for surface 7464 Aug 31 01:29:31 porter WindowManager[431]: ILM_NOTIFICATION_VISIBILITY Aug 31 01:29:31 porter WindowManager[431]: -=[updateScreen]=- Aug 31 01:29:31 porter WindowManager[431]: show pending app (7459) Aug 31 01:29:31 porter WindowManager[431]: -=[showAppLayer]=- Aug 31 01:29:31 porter WindowManager[431]: pid 7459 Aug 31 01:29:31 porter WindowManager[431]: Found layer(0) to show for app(pid=7459) Aug 31 01:29:31 porter WindowManager[431]: Layer render order (ivi-layer-id), 0 bgApps: Aug 31 01:29:31 porter WindowManager[431]: m_showLayers[3]=103 Aug 31 01:29:31 porter WindowManager[431]: m_showLayers[2]=10207459 Aug 31 01:29:31 porter WindowManager[431]: Screen render order 0, 2 layers Aug 31 01:29:31 porter WindowManager[431]: -=[updateScreen]=- Aug 31 01:29:31 porter WindowManager[431]: Layer render order (ivi-layer-id), 0 bgApps: Aug 31 01:29:31 porter WindowManager[431]: m_showLayers[3]=103 Aug 31 01:29:31 porter WindowManager[431]: m_showLayers[2]=10207459 Aug 31 01:29:31 porter WindowManager[431]: Screen render order 0, 2 layers Aug 31 01:29:32 porter afb-daemon[7459]: qml: stack.push Aug 31 01:29:32 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:29:32 porter afb-daemon[7459]: qml: 1 Aug 31 01:29:33 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:29:33 porter afb-daemon[7459]: qml: 1 Aug 31 01:29:33 porter afb-daemon[7459]: qml: count: 1 Aug 31 01:29:33 porter afb-daemon[7459]: qml: qml send_contacts Aug 31 01:29:33 porter afb-daemon[7459]: ERROR: [API telephony] obex_send_data: pb_data is NULL Aug 31 01:29:33 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_deal_pb_file.c:172,?] Aug 31 01:29:33 porter afb-daemon[7459]: ERROR: [API telephony] start init contacts binding 3 Aug 31 01:29:33 porter afb-daemon[7459]: [../../telephony-binding/telephony-binding.c:190,?] Aug 31 01:29:40 porter afb-daemon[7459]: qml: cancel ,clear Aug 31 01:29:40 porter afb-daemon[7459]: qml: WebSocket.Closing Aug 31 01:29:40 porter afb-daemon[7459]: qml: WebSocket.Closed Aug 31 01:29:40 porter afb-daemon[7459]: qml: false Aug 31 01:29:40 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:29:40 porter afb-daemon[7459]: qml: 1 Aug 31 01:29:40 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:29:40 porter afb-daemon[7459]: qml: 1 Aug 31 01:29:57 porter afb-daemon[7459]: qml: stack.push Aug 31 01:29:57 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:29:57 porter afb-daemon[7459]: qml: 1 Aug 31 01:29:57 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:29:57 porter afb-daemon[7459]: qml: 1 Aug 31 01:29:57 porter afb-daemon[7459]: qml: count: 1 Aug 31 01:29:57 porter afb-daemon[7459]: qml: qml send_contacts Aug 31 01:29:57 porter afb-daemon[7459]: ERROR: [API telephony] obex_send_data: pb_data is NULL Aug 31 01:29:57 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_deal_pb_file.c:172,?] Aug 31 01:29:57 porter afb-daemon[7459]: ERROR: [API telephony] start init contacts binding 3 Aug 31 01:29:57 porter afb-daemon[7459]: [../../telephony-binding/telephony-binding.c:190,?] Aug 31 01:30:02 porter WindowManager[431]: -=[hideLayer]=- Aug 31 01:30:02 porter WindowManager[431]: layer 2 Aug 31 01:30:02 porter WindowManager[431]: Layer render order (ivi-layer-id), 0 bgApps: Aug 31 01:30:02 porter WindowManager[431]: m_showLayers[3]=103 Aug 31 01:30:02 porter WindowManager[431]: Screen render order 0, 1 layers Aug 31 01:30:03 porter HomeScreen[492]: launch "settings at 0.1" Aug 31 01:30:03 porter HomeScreen[492]: pid: 753 Aug 31 01:30:03 porter HomeScreen[492]: makeMeVisible 753 Aug 31 01:30:03 porter WindowManager[431]: -=[showAppLayer]=- Aug 31 01:30:03 porter WindowManager[431]: id= "settings at 0.1" , pid= 753 Aug 31 01:30:03 porter WindowManager[431]: Found layer(0) to show for app(pid=753) Aug 31 01:30:03 porter WindowManager[431]: Layer render order (ivi-layer-id), 0 bgApps: Aug 31 01:30:03 porter WindowManager[431]: m_showLayers[3]=103 Aug 31 01:30:03 porter WindowManager[431]: m_showLayers[2]=10200753 Aug 31 01:30:03 porter WindowManager[431]: Screen render order 0, 2 layers Aug 31 01:30:04 porter afb-daemon[7459]: ERROR: [API telephony] address:D8:55:A3:4C:5E:B6, session:/org/bluez/obex/client/session3, instance:(null), uuid:00001132-0000-1000-8000-00805f9b34fb Aug 31 01:30:04 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_client.c:56,?] Aug 31 01:30:04 porter afb-daemon[7459]: ERROR: [API telephony] obex session_removed out Aug 31 01:30:04 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_client.c:58,?] Aug 31 01:30:04 porter afb-daemon[7459]: ERROR: [API telephony] address:D8:55:A3:4C:5E:B6, session:/org/bluez/obex/client/session2, instance:(null), uuid:0000112f-0000-1000-8000-00805f9b34fb Aug 31 01:30:04 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_client.c:56,?] Aug 31 01:30:04 porter afb-daemon[7459]: ERROR: [API telephony] obex session_removed out Aug 31 01:30:04 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_client.c:58,?] Aug 31 01:30:05 porter afb-daemon[753]: qml: {"jtype":"afb-reply","request":{"status":"success"}} Aug 31 01:30:05 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:05 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:05 porter afb-daemon[753]: qml: True Aug 31 01:30:05 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:05 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:05 porter afb-daemon[753]: qml: True Aug 31 01:30:05 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:05 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:05 porter afb-daemon[753]: qml: True Aug 31 01:30:05 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:05 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:05 porter afb-daemon[753]: qml: True Aug 31 01:30:05 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:05 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:05 porter afb-daemon[753]: qml: True Aug 31 01:30:05 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:05 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:05 porter afb-daemon[753]: qml: True Aug 31 01:30:05 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:05 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:05 porter afb-daemon[753]: qml: False Aug 31 01:30:07 porter WindowManager[431]: -=[hideLayer]=- Aug 31 01:30:07 porter WindowManager[431]: layer 2 Aug 31 01:30:07 porter WindowManager[431]: Layer render order (ivi-layer-id), 0 bgApps: Aug 31 01:30:07 porter WindowManager[431]: m_showLayers[3]=103 Aug 31 01:30:07 porter WindowManager[431]: Screen render order 0, 1 layers Aug 31 01:30:08 porter dbus-daemon[398]: Rejected send message, 0 matched rules; type="method_return", sender=":1.9" (uid=0 pid=613 comm="/opt/alps/evolution/evo_genivi_bt ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.9" (uid=0 pid=613 comm="/opt/alps/evolution/evo_genivi_bt ") privilege="(n/a)" Aug 31 01:30:08 porter afb-daemon[7459]: ERROR: [API telephony] address:D8:55:A3:4C:5E:B6, session:/org/bluez/obex/client/session4, instance:(null), uuid:0000112f-0000-1000-8000-00805f9b34fb Aug 31 01:30:08 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_client.c:40,?] Aug 31 01:30:08 porter afb-daemon[7459]: ERROR: [API telephony] obex phonebookaccess init Aug 31 01:30:08 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_phonebookaccess.c:34,?] Aug 31 01:30:08 porter afb-daemon[7459]: ERROR: [API telephony] get_size: 28 Aug 31 01:30:08 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_phonebookaccess.c:139,?] Aug 31 01:30:08 porter afb-daemon[7459]: ERROR: [API telephony] obex :transfer: /org/bluez/obex/client/session4/transfer5 Aug 31 01:30:08 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_phonebookaccess.c:117,?] Aug 31 01:30:08 porter afb-daemon[7459]: ERROR: [API telephony] obex transfer init Aug 31 01:30:08 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_transfer.c:65,?] Aug 31 01:30:08 porter afb-daemon[7459]: ERROR: [API telephony] phonebookaccess init Aug 31 01:30:08 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_client.c:44,?] Aug 31 01:30:08 porter afb-daemon[7459]: ERROR: [API telephony] address:D8:55:A3:4C:5E:B6, session:/org/bluez/obex/client/session5, instance:(null), uuid:00001132-0000-1000-8000-00805f9b34fb Aug 31 01:30:08 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_client.c:40,?] Aug 31 01:30:08 porter dbus-daemon[398]: Rejected send message, 0 matched rules; type="method_return", sender=":1.9" (uid=0 pid=613 comm="/opt/alps/evolution/evo_genivi_bt ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.9" (uid=0 pid=613 comm="/opt/alps/evolution/evo_genivi_bt ") privilege="(n/a)" Aug 31 01:30:08 porter HomeScreen[492]: launch "phone at 0.1" Aug 31 01:30:08 porter HomeScreen[492]: pid: 7459 Aug 31 01:30:08 porter HomeScreen[492]: makeMeVisible 7459 Aug 31 01:30:08 porter WindowManager[431]: -=[showAppLayer]=- Aug 31 01:30:08 porter WindowManager[431]: id= "phone at 0.1" , pid= 7459 Aug 31 01:30:08 porter WindowManager[431]: Found layer(0) to show for app(pid=7459) Aug 31 01:30:08 porter WindowManager[431]: Layer render order (ivi-layer-id), 0 bgApps: Aug 31 01:30:08 porter WindowManager[431]: m_showLayers[3]=103 Aug 31 01:30:08 porter WindowManager[431]: m_showLayers[2]=10207459 Aug 31 01:30:08 porter WindowManager[431]: Screen render order 0, 2 layers Aug 31 01:30:08 porter afb-daemon[753]: qml: {"jtype":"afb-reply","request":{"status":"success"}} Aug 31 01:30:08 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:08 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:08 porter afb-daemon[753]: qml: True Aug 31 01:30:08 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:08 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:08 porter afb-daemon[753]: qml: True Aug 31 01:30:08 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:08 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:08 porter afb-daemon[753]: qml: True Aug 31 01:30:08 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:08 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:08 porter afb-daemon[7459]: ERROR: [API telephony] status: Complete Aug 31 01:30:08 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_transfer.c:55,?] Aug 31 01:30:08 porter afb-daemon[7459]: qml: contacts status Aug 31 01:30:08 porter afb-daemon[7459]: qml: Complete Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter complete Aug 31 01:30:08 porter afb-daemon[7459]: qml: init contacts Aug 31 01:30:08 porter afb-daemon[7459]: qml: qml init_contacts Aug 31 01:30:08 porter afb-daemon[7459]: ERROR: [API telephony] enter read data 1 Aug 31 01:30:08 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_deal_pb_file.c:39,?] Aug 31 01:30:08 porter afb-daemon[7459]: ERROR: [API telephony] start init contacts binding 2 Aug 31 01:30:08 porter afb-daemon[7459]: [../../telephony-binding/telephony-binding.c:182,?] Aug 31 01:30:08 porter afb-daemon[7459]: ERROR: [API telephony] obex_send_data Aug 31 01:30:08 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_deal_pb_file.c:176,?] Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 10 Aug 31 01:30:08 porter afb-daemon[753]: qml: True Aug 31 01:30:08 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:08 porter afb-daemon[7459]: ERROR: [API telephony] start init contacts binding 3 Aug 31 01:30:08 porter afb-daemon[7459]: [../../telephony-binding/telephony-binding.c:184,?] Aug 31 01:30:08 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:08 porter afb-daemon[753]: qml: True Aug 31 01:30:08 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:08 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 100 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 102 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 105 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 106 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 11 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 114 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 118 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 89 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 9 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 90 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 91 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 92 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 92 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 93 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 94 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 94 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 95 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 95 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 96 Aug 31 01:30:08 porter afb-daemon[753]: qml: True Aug 31 01:30:08 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:08 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 97 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: alps 98 Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: mako Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: wu Aug 31 01:30:08 porter afb-daemon[7459]: qml: enter changed: yy Aug 31 01:30:08 porter afb-daemon[753]: qml: True Aug 31 01:30:08 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:08 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:09 porter afb-daemon[753]: qml: True Aug 31 01:30:09 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:09 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:09 porter afb-daemon[753]: qml: True Aug 31 01:30:09 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:09 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:09 porter afb-daemon[753]: qml: True Aug 31 01:30:09 porter afb-daemon[753]: qml: connectButton undefined Aug 31 01:30:09 porter afb-daemon[753]: qml: iamhereD8:55:A3:4C:5E:B6True Aug 31 01:30:09 porter afb-daemon[753]: qml: True Aug 31 01:30:13 porter afb-daemon[7459]: qml: cancel ,clear Aug 31 01:30:13 porter afb-daemon[7459]: qml: WebSocket.Closing Aug 31 01:30:13 porter afb-daemon[7459]: qml: WebSocket.Closed Aug 31 01:30:13 porter afb-daemon[7459]: qml: false Aug 31 01:30:13 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:13 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:13 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:13 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:14 porter afb-daemon[7459]: qml: stack.push Aug 31 01:30:14 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:14 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:14 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:14 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:14 porter afb-daemon[7459]: qml: count: 1 Aug 31 01:30:14 porter afb-daemon[7459]: qml: qml send_contacts Aug 31 01:30:14 porter afb-daemon[7459]: ERROR: [API telephony] obex_send_data Aug 31 01:30:14 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_deal_pb_file.c:176,?] Aug 31 01:30:14 porter afb-daemon[7459]: ERROR: [API telephony] start init contacts binding 3 Aug 31 01:30:14 porter afb-daemon[7459]: [../../telephony-binding/telephony-binding.c:190,?] Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 10 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 100 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 102 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 105 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 106 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 11 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 114 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 118 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 89 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 9 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 90 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 91 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 92 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 92 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 93 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 94 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 94 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 95 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 95 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 96 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 97 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: alps 98 Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: mako Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: wu Aug 31 01:30:14 porter afb-daemon[7459]: qml: enter changed: yy Aug 31 01:30:25 porter afb-daemon[7459]: qml: cancel ,clear Aug 31 01:30:25 porter afb-daemon[7459]: qml: WebSocket.Closing Aug 31 01:30:25 porter afb-daemon[7459]: qml: WebSocket.Closed Aug 31 01:30:25 porter afb-daemon[7459]: qml: false Aug 31 01:30:25 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:25 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:25 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:25 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:28 porter afb-daemon[7459]: qml: stack.push Aug 31 01:30:28 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:28 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:29 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:29 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:29 porter afb-daemon[7459]: qml: count: 1 Aug 31 01:30:29 porter afb-daemon[7459]: qml: qml send_contacts Aug 31 01:30:29 porter afb-daemon[7459]: ERROR: [API telephony] obex_send_data Aug 31 01:30:29 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_deal_pb_file.c:176,?] Aug 31 01:30:29 porter afb-daemon[7459]: ERROR: [API telephony] start init contacts binding 3 Aug 31 01:30:29 porter afb-daemon[7459]: [../../telephony-binding/telephony-binding.c:190,?] Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 10 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 100 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 102 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 105 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 106 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 11 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 114 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 118 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 89 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 9 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 90 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 91 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 92 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 92 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 93 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 94 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 94 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 95 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 95 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 96 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 97 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: alps 98 Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: mako Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: wu Aug 31 01:30:29 porter afb-daemon[7459]: qml: enter changed: yy Aug 31 01:30:30 porter afb-daemon[7459]: qml: cancel ,clear Aug 31 01:30:30 porter afb-daemon[7459]: qml: WebSocket.Closing Aug 31 01:30:30 porter afb-daemon[7459]: qml: WebSocket.Closed Aug 31 01:30:30 porter afb-daemon[7459]: qml: false Aug 31 01:30:30 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:30 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:31 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:31 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:32 porter afb-daemon[7459]: qml: stack.push Aug 31 01:30:32 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:32 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:33 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:33 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:33 porter afb-daemon[7459]: qml: count: 1 Aug 31 01:30:33 porter afb-daemon[7459]: qml: qml send_contacts Aug 31 01:30:33 porter afb-daemon[7459]: ERROR: [API telephony] obex_send_data Aug 31 01:30:33 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_deal_pb_file.c:176,?] Aug 31 01:30:33 porter afb-daemon[7459]: ERROR: [API telephony] start init contacts binding 3 Aug 31 01:30:33 porter afb-daemon[7459]: [../../telephony-binding/telephony-binding.c:190,?] Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 10 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 100 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 102 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 105 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 106 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 11 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 114 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 118 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 89 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 9 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 90 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 91 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 92 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 92 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 93 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 94 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 94 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 95 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 95 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 96 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 97 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: alps 98 Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: mako Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: wu Aug 31 01:30:33 porter afb-daemon[7459]: qml: enter changed: yy Aug 31 01:30:34 porter afb-daemon[7459]: qml: cancel ,clear Aug 31 01:30:34 porter afb-daemon[7459]: qml: WebSocket.Closing Aug 31 01:30:34 porter afb-daemon[7459]: qml: WebSocket.Closed Aug 31 01:30:34 porter afb-daemon[7459]: qml: false Aug 31 01:30:34 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:34 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:34 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:34 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:35 porter afb-daemon[7459]: qml: stack.push Aug 31 01:30:35 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:35 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:35 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:35 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:35 porter afb-daemon[7459]: qml: count: 1 Aug 31 01:30:35 porter afb-daemon[7459]: qml: qml send_contacts Aug 31 01:30:35 porter afb-daemon[7459]: ERROR: [API telephony] obex_send_data Aug 31 01:30:35 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_deal_pb_file.c:176,?] Aug 31 01:30:35 porter afb-daemon[7459]: ERROR: [API telephony] start init contacts binding 3 Aug 31 01:30:35 porter afb-daemon[7459]: [../../telephony-binding/telephony-binding.c:190,?] Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 10 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 100 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 102 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 105 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 106 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 11 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 114 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 118 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 89 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 9 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 90 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 91 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 92 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 92 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 93 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 94 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 94 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 95 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 95 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 96 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 97 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: alps 98 Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: mako Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: wu Aug 31 01:30:35 porter afb-daemon[7459]: qml: enter changed: yy Aug 31 01:30:37 porter afb-daemon[7459]: qml: cancel ,clear Aug 31 01:30:37 porter afb-daemon[7459]: qml: WebSocket.Closing Aug 31 01:30:37 porter afb-daemon[7459]: qml: WebSocket.Closed Aug 31 01:30:37 porter afb-daemon[7459]: qml: false Aug 31 01:30:37 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:37 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:37 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:37 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:38 porter afb-daemon[7459]: qml: stack.push Aug 31 01:30:38 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:38 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:38 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:38 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:38 porter afb-daemon[7459]: qml: count: 1 Aug 31 01:30:38 porter afb-daemon[7459]: qml: qml send_contacts Aug 31 01:30:38 porter afb-daemon[7459]: ERROR: [API telephony] obex_send_data Aug 31 01:30:38 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_deal_pb_file.c:176,?] Aug 31 01:30:38 porter afb-daemon[7459]: ERROR: [API telephony] start init contacts binding 3 Aug 31 01:30:38 porter afb-daemon[7459]: [../../telephony-binding/telephony-binding.c:190,?] Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 10 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 100 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 102 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 105 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 106 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 11 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 114 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 118 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 89 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 9 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 90 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 91 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 92 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 92 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 93 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 94 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 94 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 95 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 95 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 96 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 97 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: alps 98 Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: mako Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: wu Aug 31 01:30:38 porter afb-daemon[7459]: qml: enter changed: yy Aug 31 01:30:40 porter afb-daemon[7459]: qml: cancel ,clear Aug 31 01:30:40 porter afb-daemon[7459]: qml: WebSocket.Closing Aug 31 01:30:40 porter afb-daemon[7459]: qml: WebSocket.Closed Aug 31 01:30:40 porter afb-daemon[7459]: qml: false Aug 31 01:30:40 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:40 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:41 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:41 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:41 porter afb-daemon[7459]: qml: stack.push Aug 31 01:30:41 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:41 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:42 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:42 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:42 porter afb-daemon[7459]: qml: count: 1 Aug 31 01:30:42 porter afb-daemon[7459]: qml: qml send_contacts Aug 31 01:30:42 porter afb-daemon[7459]: ERROR: [API telephony] obex_send_data Aug 31 01:30:42 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_deal_pb_file.c:176,?] Aug 31 01:30:42 porter afb-daemon[7459]: ERROR: [API telephony] start init contacts binding 3 Aug 31 01:30:42 porter afb-daemon[7459]: [../../telephony-binding/telephony-binding.c:190,?] Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 10 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 100 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 102 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 105 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 106 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 11 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 114 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 118 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 89 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 9 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 90 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 91 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 92 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 92 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 93 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 94 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 94 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 95 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 95 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 96 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 97 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: alps 98 Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: mako Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: wu Aug 31 01:30:42 porter afb-daemon[7459]: qml: enter changed: yy Aug 31 01:30:42 porter afb-daemon[7459]: qml: cancel ,clear Aug 31 01:30:42 porter afb-daemon[7459]: qml: WebSocket.Closing Aug 31 01:30:42 porter afb-daemon[7459]: qml: WebSocket.Closed Aug 31 01:30:42 porter afb-daemon[7459]: qml: false Aug 31 01:30:42 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:42 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:43 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:43 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:44 porter afb-daemon[7459]: qml: stack.push Aug 31 01:30:44 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:44 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:44 porter afb-daemon[7459]: qml: WebSocket.Error Aug 31 01:30:44 porter afb-daemon[7459]: qml: WebSocket error: QWebSocketPrivate::processHandshake: Unhandled http status code: 500 (Internal Server Error Aug 31 01:30:44 porter afb-daemon[7459]: ). Aug 31 01:30:44 porter afb-daemon[7459]: qml: WebSocket.Closed Aug 31 01:30:44 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:30:44 porter afb-daemon[7459]: qml: 1 Aug 31 01:30:44 porter afb-daemon[7459]: qml: count: 1 Aug 31 01:30:44 porter afb-daemon[7459]: qml: qml send_contacts Aug 31 01:30:44 porter afb-daemon[7459]: ERROR: [API telephony] obex_send_data Aug 31 01:30:44 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_deal_pb_file.c:176,?] Aug 31 01:30:44 porter afb-daemon[7459]: ERROR: [API telephony] start init contacts binding 3 Aug 31 01:30:44 porter afb-daemon[7459]: [../../telephony-binding/telephony-binding.c:190,?] Aug 31 01:31:25 porter afb-daemon[7459]: qml: cancel ,clear Aug 31 01:31:25 porter afb-daemon[7459]: qml: false Aug 31 01:31:25 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:31:25 porter afb-daemon[7459]: qml: 1 Aug 31 01:31:25 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:31:25 porter afb-daemon[7459]: qml: 1 Aug 31 01:31:28 porter afb-daemon[7459]: qml: stack.push Aug 31 01:31:28 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:31:28 porter afb-daemon[7459]: qml: 1 Aug 31 01:31:28 porter afb-daemon[7459]: qml: WebSocket.Error Aug 31 01:31:28 porter afb-daemon[7459]: qml: WebSocket error: QWebSocketPrivate::processHandshake: Unhandled http status code: 500 (Internal Server Error Aug 31 01:31:28 porter afb-daemon[7459]: ). Aug 31 01:31:28 porter afb-daemon[7459]: qml: WebSocket.Closed Aug 31 01:31:29 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:31:29 porter afb-daemon[7459]: qml: 1 Aug 31 01:31:29 porter afb-daemon[7459]: qml: count: 1 Aug 31 01:31:29 porter afb-daemon[7459]: qml: qml send_contacts Aug 31 01:31:29 porter afb-daemon[7459]: ERROR: [API telephony] obex_send_data Aug 31 01:31:29 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_deal_pb_file.c:176,?] Aug 31 01:31:29 porter afb-daemon[7459]: ERROR: [API telephony] start init contacts binding 3 Aug 31 01:31:29 porter afb-daemon[7459]: [../../telephony-binding/telephony-binding.c:190,?] Aug 31 01:31:36 porter afb-daemon[7459]: qml: cancel ,clear Aug 31 01:31:36 porter afb-daemon[7459]: qml: false Aug 31 01:31:36 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:31:36 porter afb-daemon[7459]: qml: 1 Aug 31 01:31:36 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:31:36 porter afb-daemon[7459]: qml: 1 Aug 31 01:31:37 porter afb-daemon[7459]: qml: stack.push Aug 31 01:31:37 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:31:37 porter afb-daemon[7459]: qml: 1 Aug 31 01:31:37 porter afb-daemon[7459]: qml: WebSocket.Error Aug 31 01:31:37 porter afb-daemon[7459]: qml: WebSocket error: QWebSocketPrivate::processHandshake: Unhandled http status code: 500 (Internal Server Error Aug 31 01:31:37 porter afb-daemon[7459]: ). Aug 31 01:31:37 porter afb-daemon[7459]: qml: WebSocket.Closed Aug 31 01:31:37 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:31:37 porter afb-daemon[7459]: qml: 1 Aug 31 01:31:37 porter afb-daemon[7459]: qml: count: 1 Aug 31 01:31:37 porter afb-daemon[7459]: qml: qml send_contacts Aug 31 01:31:37 porter afb-daemon[7459]: ERROR: [API telephony] obex_send_data Aug 31 01:31:37 porter afb-daemon[7459]: [../../telephony-binding/pbap_gdbus/obex_deal_pb_file.c:176,?] Aug 31 01:31:37 porter afb-daemon[7459]: ERROR: [API telephony] start init contacts binding 3 Aug 31 01:31:37 porter afb-daemon[7459]: [../../telephony-binding/telephony-binding.c:190,?] Aug 31 01:31:41 porter connmand[336]: ntp: time slew -0.042392 s Aug 31 01:31:44 porter afb-daemon[7459]: qml: cancel ,clear Aug 31 01:31:44 porter afb-daemon[7459]: qml: false Aug 31 01:31:44 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:31:44 porter afb-daemon[7459]: qml: 1 Aug 31 01:31:45 porter afb-daemon[7459]: qml: onBusyChanged Aug 31 01:31:45 porter afb-daemon[7459]: qml: 1 Aug 31 01:34:50 porter systemd-timesyncd[216]: Timed out waiting for reply from 216.239.35.0:123 (time1.google.com). Aug 31 01:35:00 porter systemd-timesyncd[216]: Timed out waiting for reply from 216.239.35.4:123 (time2.google.com). Aug 31 01:35:11 porter systemd-timesyncd[216]: Timed out waiting for reply from 216.239.35.8:123 (time3.google.com). Aug 31 01:35:21 porter systemd-timesyncd[216]: Timed out waiting for reply from 216.239.35.12:123 (time4.google.com). Aug 31 01:48:45 porter connmand[336]: ntp: time slew +0.001265 s Aug 31 01:52:25 porter connmand[336]: Error with UDP server 10.25.11.6 Aug 31 01:52:25 porter connmand[336]: Error with UDP server 10.25.11.6 Aug 31 01:52:35 porter systemd-timesyncd[216]: Timed out waiting for reply from 216.239.35.0:123 (time1.google.com). Aug 31 01:52:46 porter systemd-timesyncd[216]: Timed out waiting for reply from 216.239.35.4:123 (time2.google.com). Aug 31 01:52:56 porter systemd-timesyncd[216]: Timed out waiting for reply from 216.239.35.8:123 (time3.google.com). Aug 31 01:53:06 porter systemd-timesyncd[216]: Timed out waiting for reply from 216.239.35.12:123 (time4.google.com). -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpjday at crashcourse.ca Thu Aug 31 09:48:28 2017 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Thu, 31 Aug 2017 05:48:28 -0400 (EDT) Subject: [agl-discussions] couple observations related to online doc/info pages Message-ID: new to AGL, a couple questions/observations about what i'm seeing online. first, at this page: http://docs.automotivelinux.org/contact/ one is told, "If you are AGL user looking for help, use the AGL tag on Stack Overflow." but following that link, one sees not a single submission to stack overflow with the tag "agl". is that really where one is supposed to ask AGL-related questions? also, here: http://docs.automotivelinux.org/docs/getting_started/en/dev/reference/source-code.html#download-source that page still refers to chinook as the "Latest Stable Release"; should that not be updated to Dab? i'm sure i saw at least one other page that continued to refer to chinook as the latest official release. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== From jsmoeller at linuxfoundation.org Thu Aug 31 11:08:10 2017 From: jsmoeller at linuxfoundation.org (Jan-Simon =?ISO-8859-1?Q?M=F6ller?=) Date: Thu, 31 Aug 2017 13:08:10 +0200 Subject: [agl-discussions] couple observations related to online doc/info pages In-Reply-To: References: Message-ID: <3397351.P1V6fFttD1@samweis.auenland.lan> Hi Robert, Am Donnerstag, 31. August 2017, 11:48:28 CEST schrieb Robert P. J. Day: > new to AGL, a couple questions/observations about what i'm seeing > online. > > first, at this page: > > http://docs.automotivelinux.org/contact/ > > one is told, "If you are AGL user looking for help, use the AGL tag on > Stack Overflow." but following that link, one sees not a single > submission to stack overflow with the tag "agl". is that really where > one is supposed to ask AGL-related questions? Yes, its fresh. But we should better point to https://ask.automotivelinux.org > also, here: > > http://docs.automotivelinux.org/docs/getting_started/en/dev/reference/source > -code.html#download-source > > that page still refers to chinook as the "Latest Stable Release"; > should that not be updated to Dab? i'm sure i saw at least one other > page that continued to refer to chinook as the latest official > release. Those need indeed an update to dab. The docs use the markdown template files in git. Best, Jan-Simon -- Sincerely yours, Jan-Simon M?ller jsmoeller at linuxfoundation.org From rpjday at crashcourse.ca Thu Aug 31 12:39:02 2017 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Thu, 31 Aug 2017 08:39:02 -0400 (EDT) Subject: [agl-discussions] couple observations related to online doc/info pages In-Reply-To: <3397351.P1V6fFttD1@samweis.auenland.lan> References: <3397351.P1V6fFttD1@samweis.auenland.lan> Message-ID: On Thu, 31 Aug 2017, Jan-Simon M?ller wrote: > Hi Robert, > Am Donnerstag, 31. August 2017, 11:48:28 CEST schrieb Robert P. J. Day: > > new to AGL, a couple questions/observations about what i'm seeing > > online. > > > > first, at this page: > > > > http://docs.automotivelinux.org/contact/ > > > > one is told, "If you are AGL user looking for help, use the AGL tag on > > Stack Overflow." but following that link, one sees not a single > > submission to stack overflow with the tag "agl". is that really where > > one is supposed to ask AGL-related questions? > > Yes, its fresh. But we should better point to > https://ask.automotivelinux.org so the https://ask.automotivelinux.org page is now the officially-endorsed place to ask AGL-related questions? then, yes, that contact page above needs to be updated. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================