broken vexpress_defconfig (was Re: Organizing Config Fragments)
On 1 August 2013 20:46, Jon Medhurst (Tixy) wrote: > On Thu, 2013-08-01 at 17:40 +0100, Peter Maydell wrote: >> On 1 August 2013 09:30, Ryan Harkin wrote: >> > The vexpress defconfig has always been broken. >> >> ...maybe we could fix it? > > It has been suggested that should be deleted as people can use the > multiplatform defconfig (though I believe that is missing the regulator > config for mmc as well). > > People have different ideas where various configs should live, boards > specific defconfig, multiplatform defconfig or in Kconfig; and any > particular change probably would have people arguing against it. And > with vexpress we have the added complication thrown into the mix that > people use it a lot with QEMU ;-) For the kernel CI, we build all the defconfigs and boot test on available platforms in LAVA lab. Since vexpress_defconfig is known broken (https://bugs.launchpad.net/linaro-ci/+bug/1212893), what's the next step to move forward? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
M0 and M3 patches in linaro toolchains
Debconf13 (last week) considered the matter of bare-metal cross-toolchains in Debian. Ideally we would have one toolchain source package from which the existing linux native compilers, and cross-compilers are built, including bare-metal cross-compilers. There is already mechanism for adding patches for particular gcc builds, so so long as the patch set is manageable and trackable, this would be nice, and futureproof, as eventually the patch set should just evaporate as it gets upstreamed. The alternative it to simply repack the existing linaro cross-toolchain sources, but them we get to keep doing that for new releases, and we have gratuitous extra copies of gcc sources and corresponding differences between A* and M* toolchains/versions. The linaro embedded toolchains (https://launchpad.net/gcc-arm-embedded/4.7/4.7-2013-q1-update) are good, and work, both for M0 and M3. But building nominally the same thing from upstream gcc gets something where M3 works but M0 doesn't. Also they are gcc 4.7 based whilst Debian is moving to a 4.8 default. We peered at checkouts from linaro and upstream and tried to work out what the linaro patch-set for this toolchain is, and exactly where it branched off upstream, but it was confusing with a lot of noise due to version skew around some actually relevant changes. So, in order to work out if we can in fact build our bare-metal toolchains from the same sources as the existing toolchains we need to know what the actual patch-set you are maitaining looks like, and what is already upstreamed in which gcc branch/release and when the remaining patches will go upstream. Also what the 4.7 vs 4.8 status is. Knowing how this stuff is tracked might be even more useful over the longer term. Is there such info online somewhere? If not please elaborate. A mechanism for keeping the (newly-formed) Debian cross-compiler team sufficiently in the loop is probably what's needed in the longer term, unless this is all just about to get upstreamed anyway and the issue will soon become moot...? There was also discussion around the concept of making existing linux-arm cross-compilers, with M0 and M3 support included, and using spec-file jiggery-pokery to get them to DTRT for M* targets. This should be possible, but advice from anyone who's every actually tried on the gotchas would be good. cheers Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: M0 and M3 patches in linaro toolchains
On 19 August 2013 15:04, Wookey wrote: > Debconf13 (last week) considered the matter of bare-metal > cross-toolchains in Debian. Ideally we would have one toolchain source > package from which the existing linux native compilers, and > cross-compilers are built, including bare-metal cross-compilers. There > is already mechanism for adding patches for particular gcc builds, so > so long as the patch set is manageable and trackable, this would be > nice, and futureproof, as eventually the patch set should just > evaporate as it gets upstreamed. > > The alternative it to simply repack the existing linaro > cross-toolchain sources, but them we get to keep doing that for new > releases, and we have gratuitous extra copies of gcc sources and > corresponding differences between A* and M* toolchains/versions. > > The linaro embedded toolchains > (https://launchpad.net/gcc-arm-embedded/4.7/4.7-2013-q1-update) are > good, and work, both for M0 and M3. But building nominally the same > thing from upstream gcc gets something where M3 works but M0 doesn't. OK - These aren't Linaro owned tools. They are produced by ARM. We link to them to make sure people can find the tools they need. Can you expand (possibly in a separate thread) on "M3 works but M0 doesn't"? I'd expect the gcc-arm-embedded tools to support all M-profile cores out of the box. > Also they are gcc 4.7 based whilst Debian is moving to a 4.8 default. If history is anything to go by there will be a 4.8 release of that toolchain sometime in Q4 2013. > We peered at checkouts from linaro and upstream and tried to work out > what the linaro patch-set for this toolchain is, and exactly where it > branched off upstream, but it was confusing with a lot of noise due to > version skew around some actually relevant changes. > > So, in order to work out if we can in fact build our bare-metal > toolchains from the same sources as the existing toolchains we need to > know what the actual patch-set you are maitaining looks like, and what > is already upstreamed in which gcc branch/release and when the > remaining patches will go upstream. Also what the 4.7 vs 4.8 status > is. Knowing how this stuff is tracked might be even more useful over > the longer term. > > Is there such info online somewhere? If not please elaborate. A > mechanism for keeping the (newly-formed) Debian cross-compiler team > sufficiently in the loop is probably what's needed in the longer term, > unless this is all just about to get upstreamed anyway and the issue > will soon become moot...? The Linaro branch for 4.8 is in the main SVN repository for GCC: svn://gcc.gnu.org/branches/linaro/gcc-4_8-branch And we use svn merge to keep track of merge data. We work by getting patches accepted into trunk and then backporting them - so every substantive patch is a backport from trunk. There are some patches in the Linaro branch which are not also in trunk - but these all relate to release stuff - and so don't make any difference to the code generation. Personally, even if you end up just using the Debian patchset by default (which will not be a terrible starting point), you should take a look at the way the GCC ARM Embedded toolchain configures multilib for bare-metal. These are a good starting point for choosing a set of multilibs to build. Thanks, Matt -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-d...@linaro.org ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: M0 and M3 patches in linaro toolchains
+++ Matthew Gretton-Dann [2013-08-19 16:58 +0100]: > On 19 August 2013 15:04, Wookey wrote: > > Debconf13 (last week) considered the matter of bare-metal > > cross-toolchains in Debian. > > The linaro embedded toolchains > > (https://launchpad.net/gcc-arm-embedded/4.7/4.7-2013-q1-update) are > > good, and work, both for M0 and M3. But building nominally the same > > thing from upstream gcc gets something where M3 works but M0 doesn't. > > OK - These aren't Linaro owned tools. They are produced by ARM. We > link to them to make sure people can find the tools they need. Aha. I had assumed it was something linaro was now doing. I'll see if I can find some more details inside ARM then. > Can you expand (possibly in a separate thread) on "M3 works but M0 > doesn't"? I'd expect the gcc-arm-embedded tools to support all > M-profile cores out of the box. You misread (or I was unclear). The arm-provided toolchain referenced above does indeed work for M3 and M0. It's a toolchain built from debian sources that doesn't work for M0. Keithp did the tests and has the details of exactly what he tested. (are we talking 4.7 or 4.8 (or both) here keith?) > > Also they are gcc 4.7 based whilst Debian is moving to a 4.8 default. > > If history is anything to go by there will be a 4.8 release of that > toolchain sometime in Q4 2013. OK, that will be useful but another big code dump with a huge diff is only a partial solution. We really want to get to see which important bits are actually missing in Debian. > > The Linaro branch for 4.8 is in the main SVN repository for GCC: > svn://gcc.gnu.org/branches/linaro/gcc-4_8-branch OK. And do you think that should support M0 and M3 correctly already? Do we expect M0/M3 support there to be good? Or should I ask Joey these questions? Debian is currently using 4.8.1 (with a pile of packaging patches and some backported fixes). So I guess the question really is whether that is expected to work. > And we use svn merge to keep track of merge data. > > We work by getting patches accepted into trunk and then backporting > them - so every substantive patch is a backport from trunk. There are > some patches in the Linaro branch which are not also in trunk - but > these all relate to release stuff - and so don't make any difference > to the code generation. OK, that's helpful. > Personally, even if you end up just using the Debian patchset by > default (which will not be a terrible starting point), you should take > a look at the way the GCC ARM Embedded toolchain configures multilib > for bare-metal. These are a good starting point for choosing a set of > multilibs to build. Right. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Regarding full build of Ubuntu ARM with linaro toolchain
+++ Gaurang Shastri [2013-08-06 19:09 +0530]: [ I have now (as back from hols/debconf) talked to Gaurang and mailed him offline. But just a couple of things that a wider audience might find useful] >I don�t know I am in right channel to ask this question, if not then >please guide me. This is a pretty-good place to ask. debian-embed...@lists.debian.org is also sensible, and we are just in the process of creating debian-cr...@lists.debian.org as a place for general cross-build related dsicussion for Debian and derivatives. That's currently waiting for an admin to actually do it. >Currently, I am following >[1]https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/UsingXdeb for >cross compiling using xdeb. I am using �raring� as a Ubuntu distribution. In raring, you are likely to have more success using multiarch cross-building, than using xdeb. xdeb uses the older dpkg-cross -based cross-building method, which has been superceded by direct cross build-dep and building support in apt and dpkg. Raring is the first release where this works well enough to be recommended as the default method. I hope that https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/CrossbuildingQuickStart makes this sufficiently clear. Please tell me if not. >�So using above link, up to the section �Kick a build of grep and >build-deps�, everything goes perfectly. > >But, this shows how to build any single package like grep, libpng, etc.. > >�If I want to build (cross-compile) all the �raring� Ubuntu Distribution >package as one shot, how can I do?? > >Is there any tools available for cross compiling all packages ?? The short answer to this right now is 'no'. Although for a released distro something like: for package in `read packagelist` do sbuild --host=armhf -c chroot -d distro $package done should work reasonably well if you can generate a list of the packages you need, >How can I setup auto builder machine?? This is something that we have made unreasonably difficult for many years. Solutions are coming (debile and pybit are current contenders), but sadly it's not easy, and nor is it documented. I really hope this will finally get fixed soon - some progress was made at debconf and I hope to try it (and document it if it works) soonish. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Panda, Android & Bluetooth
On Sat, Aug 17, 2013 at 7:07 PM, Mike Turquette wrote: > > Anyway Nicolas may know more, but the best bet may be to find a TI > > Alumni who worked on it and get the skinny. > > Nicolas, any inputs? well, not really... i have never really paid too much attention on BT for Panda. For a while we had some support from the Connectivity team, and things 'kinda' worked. Andy spent some time fixing a bunch of issues in our TI kernel at that time. But around the same time when ICS came up, things stopped working, and we were left with no support .. and BT wasn't clearly something we cared too much about ;-( cheers nico ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Panda, Android & Bluetooth
On Sat, Aug 17, 2013 at 11:55 PM, Andy Green wrote: > On 18 August 2013 14:41, Fathi Boudra wrote: >> Hey Mike, >> >> On 17 August 2013 20:07, Mike Turquette wrote: >>> On Thu, Aug 15, 2013 at 6:02 PM, Andy Green wrote: On 16 August 2013 08:22, Mike Turquette wrote: > Hi all, > > I'm interested in looking at some Bluetooth stuff on my OMAP 4460 > Panda ES. Looking at the bug reports I don't see any Jelly Bean > releases that have BT working properly on Panda. Is this correct? > > Can you please point me to a release where BT and display/hdmi are > working for Panda? It's OK if it is ICS. > > I'm OK starting with binaries but I would much prefer to be able to > build from source and reproduce any known-good bins. I have already > built JB from the latest tip as well as the 13.07 manifest (display is > working fine but BT doesn't work, bugs already filed). I tried the > 12.07 Panda LEB (which I think was the last ICS release?) but the > binaries supplied did not have display working even after running the > install-binaries-4.0.4.sh script. Nicolas Dechesne may be able to help more directly, but mainline BT was never workable reliably on Panda. >>> >>> That's disappointing since an article on omappedia references the >>> Linaro release and says, "Note: Wifi, bluetooth, YouTube, jpeg, video >>> playback (both .mp4 and .3gp), and audio playback (both .mp3 and .aac) >>> all have been verified as working in this release." You can see it >>> here: >>> >>> http://www.omappedia.com/wiki/Android_Panda_Build_Source#Building_from_Linaro >> >> What about asking Linaro guys that actually produce this build? >> >> Looking at our test results, the bluetooth test failed in 12.07 release. >> A bug has been opened at that time: >> https://bugs.launchpad.net/linaro-android/+bug/987765 >> >> Adding Vishal in CC, who's probably know the bluetooth status in >> Linaro Android builds better than me. > > Mike's saying even video didn't work when he tried that. > > Reading that bug it sounds like a firmware issue in the image. I say > in the bug it's working on kernel side at that time. > > However like the video problem, it sort of hinges on the meaning of "working". > > HDMI and DVI on Panda have "worked" to some extent for a long while. > But they've never worked properly dual-head and in fact because they > share a PLL for the pixel clock, they'll never work outside of special > conditions like same monitor and resolution. Last I saw of it there's > a behaviour in HDMI hotlug detect handling in the driver that means > some monitors won't be seen as plugged, because they delay sending hpd > by up to 1s (I have one of these monitors). The code in the Panda > release was forward-ported from 3.0 DSS stack on omapzoom (since > that's the only thing TI had on offer with working Android SGX) and > that deviates hugely from mainline DSS, so any improvements in this > area didn't get transplanted. > > Bluetooth is similar on mainline basis, it was able to work for a > while but when hammered it fell over. Sounds like I'm out of luck for finding a build where things Just Work. Thanks for the inputs everyone. Regards, Mike > > -Andy > The p-android stuff on omapzoom was meant to have numerous patches that actually made it work. At one point we talked to some guys from TI and got some patches, however they were patches against p-android-3.0 that not only did not apply on mainline but were 100% patching code that anyway did not exist in mainline, so we got literally nowhere with it. The p-android stuff are busy history trees, so it is very hard to extract a coherent series that "fixes bluetooth". Even to do direct diffs at file level isn't easy since the files have all moved around and the 3.0 one we know worked is radically different than current mainline anyway. Some of the issues were down to PM related stuff and the p-android arrangements for that bear no relationship to mainline. Anyway Nicolas may know more, but the best bet may be to find a TI Alumni who worked on it and get the skinny. >>> >>> Nicolas, any inputs? >>> >>> Thanks, >>> Mike >>> -Andy > Thanks, > Mike >> >> Cheers, >> -- >> Fathi Boudra >> Builds and Baselines Manager | Release Manager >> Linaro.org | Open source software for ARM SoCs >> >> ___ >> linaro-dev mailing list >> linaro-dev@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: M0 and M3 patches in linaro toolchains
Wookey writes: > The alternative it to simply repack the existing linaro > cross-toolchain sources, but them we get to keep doing that for new > releases, and we have gratuitous extra copies of gcc sources and > corresponding differences between A* and M* toolchains/versions. I'm working on this process at the moment; I figure that having a stable and reliable compiler will provide a good starting point while we sort out how to unify the compiler source code bases. A simple 'diff' from the linaro q2 release from current Debian 4.7 compiler sources is something over 700k lines at present; dumping that into a package doesn't exactly seem like a good idea. -keith pgpdtMt5CxWmQ.pgp Description: PGP signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Panda, Android & Bluetooth
Hi, On 18 August 2013 12:25, Andy Green wrote: > On 18 August 2013 14:41, Fathi Boudra wrote: > > Hey Mike, > > > > On 17 August 2013 20:07, Mike Turquette wrote: > >> On Thu, Aug 15, 2013 at 6:02 PM, Andy Green > wrote: > >>> On 16 August 2013 08:22, Mike Turquette wrote: > Hi all, > > I'm interested in looking at some Bluetooth stuff on my OMAP 4460 > Panda ES. Looking at the bug reports I don't see any Jelly Bean > releases that have BT working properly on Panda. Is this correct? > Yes. This is true. We have not worked on fixing BT on JB. > > Can you please point me to a release where BT and display/hdmi are > working for Panda? It's OK if it is ICS. > Even on ICS it was partially working. File transfer resulted in crashes on 4.0.4. You can try this release which is based on 4.0.3 : http://releases.linaro.org/12.03/android/leb-panda/ It was working well on GB if you are interested: > I'm OK starting with binaries but I would much prefer to be able to > build from source and reproduce any known-good bins. I have already > built JB from the latest tip as well as the 13.07 manifest (display is > working fine but BT doesn't work, bugs already filed). I tried the > 12.07 Panda LEB (which I think was the last ICS release?) but the > binaries supplied did not have display working even after running the > install-binaries-4.0.4.sh script. > 12.07 did not need any acceleration binaries since it was based on 3.4 kernel where SGX was not ported back then. Since we were not making any progress with 3.4 kernel, we moved back to 3.2 kernel. > >>> > >>> Nicolas Dechesne may be able to help more directly, but mainline BT > >>> was never workable reliably on Panda. > >> > >> That's disappointing since an article on omappedia references the > >> Linaro release and says, "Note: Wifi, bluetooth, YouTube, jpeg, video > >> playback (both .mp4 and .3gp), and audio playback (both .mp3 and .aac) > >> all have been verified as working in this release." You can see it > >> here: > >> > >> > http://www.omappedia.com/wiki/Android_Panda_Build_Source#Building_from_Linaro > > > > What about asking Linaro guys that actually produce this build? > I am trying to get this build working again: https://android-build.linaro.org/builds/~linaro-android-archive/panda-ics-gcc47-omapzoom-stable-blob/ This build is based on 3.0 kernel which had most of the connectivity working and included MM support as well. I'll get back to you once the build is succesful again. > > > > Looking at our test results, the bluetooth test failed in 12.07 release. > > A bug has been opened at that time: > > https://bugs.launchpad.net/linaro-android/+bug/987765 > > > > Adding Vishal in CC, who's probably know the bluetooth status in > > Linaro Android builds better than me. > > Mike's saying even video didn't work when he tried that. > > Reading that bug it sounds like a firmware issue in the image. I say > in the bug it's working on kernel side at that time. > > However like the video problem, it sort of hinges on the meaning of > "working". > > HDMI and DVI on Panda have "worked" to some extent for a long while. > But they've never worked properly dual-head and in fact because they > share a PLL for the pixel clock, they'll never work outside of special > conditions like same monitor and resolution. Last I saw of it there's > a behaviour in HDMI hotlug detect handling in the driver that means > some monitors won't be seen as plugged, because they delay sending hpd > by up to 1s (I have one of these monitors). The code in the Panda > release was forward-ported from 3.0 DSS stack on omapzoom (since > that's the only thing TI had on offer with working Android SGX) and > that deviates hugely from mainline DSS, so any improvements in this > area didn't get transplanted. > > Bluetooth is similar on mainline basis, it was able to work for a > while but when hammered it fell over. > > -Andy > > >>> The p-android stuff on omapzoom was meant to have numerous patches > >>> that actually made it work. At one point we talked to some guys from > >>> TI and got some patches, however they were patches against > >>> p-android-3.0 that not only did not apply on mainline but were 100% > >>> patching code that anyway did not exist in mainline, so we got > >>> literally nowhere with it. > >>> > >>> The p-android stuff are busy history trees, so it is very hard to > >>> extract a coherent series that "fixes bluetooth". Even to do direct > >>> diffs at file level isn't easy since the files have all moved around > >>> and the 3.0 one we know worked is radically different than current > >>> mainline anyway. Some of the issues were down to PM related stuff and > >>> the p-android arrangements for that bear no relationship to mainline. > >>> > >>> Anyway Nicolas may know more, but the best bet may be to find a TI > >>> Alumni who worked on it and get the skinny. > >> > >> Nicolas, any inputs?
