Hi All,
I am a freshman to linaro. I found people sent some patches to
linaro-dev(a)lists.linaro.org. Here I have 2 questions:
1. Whether will linaro send those patches based on newest tree to
Linus' mainline or not? Or developers need to send those patches to
mainline by themselves?
Is there any document to describe how linaro contribute patches to mainline?
2. If other SoC companies work based on linaro's
linux-linaro-next.git, whether it will not need to work based on
Linus' tree since linux-linaro-next.git will sync with mainline?
Thanks
Barry
On 21 March 2011 21:08, Alex Deucher <alexdeucher(a)gmail.com> wrote:
> On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven
> <geert(a)linux-m68k.org> wrote:
>> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes <jbarnes(a)virtuousgeek.org> wrote:
>>> On Mon, 21 Mar 2011 19:19:43 +0000
>>> timofonic timofonic <timofonic(a)gmail.com> wrote:
>>>> So if KMS is so cool and provides many advantages over fbdev and
>>>> such... Why isn't more widely used intead of still relying on fbdev?
>>>> Why still using fbdev emulation (that is partial and somewhat broken,
>>>> it seems) instead using KMS directly?
>>>
>>> Used by what? All three major GPU device classes have KMS support
>>> (Intel, ATI, and nVidia). If you want it for a particular device, you
>>> can always port it over.
>>
>> The three major GPU device classes on PC...
>
> Sadly it gets worse. A lot of the SoC vendors are adding an fbdev
> emulation layer on top of v4l rather than using fbdev directly or
> using KMS and v4l has grown it's own edid, hdmi, and cec handling.
>
I agree, it is sad that as a SoC vendor there are different
kernel/user API's(v4l2/fbdev/drm) to choose from when implementing say
a Display controller driver. One must also remember that there are big
differences between a desktop/PC multimedia/graphics system and the
ones present on an embedded SoC. It is two very different cultures and
HW designs now trying to merge into one Linux Kernel. Of course there
will be some overlaps but I believe it can be sorted out as soon as we
understand each others different possibilities/limitations. Doing
duplicate work like HDMI will not benefit any party.
Just to list some of the differences.
- Developments within V4L2 has mainly been driven by embedded devices
while DRM is a result of desktop Graphics cards. And for some extent
also solving different problems.
- Embedded devices usually have several different hw IP's managing
displays, hdmi, camera/ISP, video codecs(h264 accellerators), DSP's,
2D blitters, Open GL ES hw, all of which have a separate device/driver
in the kernel, while on a desktop nowadays all this functionality
usually resides on ONE graphics card, hence one DRM device for all.
- DRM is closely developed in conjunction with desktop/Xorg, while X11
on an embedded device is not very 2011...wayland on the other hand is
:-), but do wayland really need the full potential of DRM/DRI or just
parts of it.
- Copying buffers is really bad for embedded devices due to lower
memory bandwidth and power consumption while on a Desktop memory
bandwidth is from an other galaxy (copying still bad but accepted it
seems), AND embedded devices of today records and plays/displays 1080p
content as well.
- Not all embedded devices have MMU's for each IP requiring physical
contiguous memory, while on a desktop MMU's have been present for
ages.
- Embedded devices are usually ARM based SoCs while x86 dominates the
Desktop/Laptop market, and functionality provided is soon the very
same.
- yada yada....The list can grow very long....There are also
similarities of course.
The outcome is that SoC vendors likes the embedded friendliness of
v4l2 and fbdev while "we" also glance at the DRM part due to its
de-facto standard on desktop environments. But from an embedded point
of view DRM lacks the support for interconnecting multiple
devices/drivers mentioned above, GEM/TTM is valid within a DRM device,
the execution/context management is not needed,, no overlays(or
similar), the coupling to DRI/X11 not wanted. SoCs like KMS/GEM but
the rest of DRM will likely not be heavily used on SoCs unless running
X11 as well. Most likely this worked on as well within the DRI
community. I can see good features all over the place(sometimes
duplicated) but not find one single guideline/API that solves all the
embedded SoC problems (which involves use-cases optimized for no-copy
cross media/drivers).
Last but not least...
On Linaro there is already discussions ongoing to solve one of the
biggest issues from a SoC point of view and that is a "System Wide
Memory manager" which manages buffer sharing and resolves no-copy use
cases between devices/drivers. Read more on the following thread:
http://lists.linaro.org/pipermail/linaro-dev/2011-March/003053.html.
BR
/Robert Fekete
st-ericsson
On Mon, 21 Mar 2011 09:55:26 +0100
Raphael Hertzog <hertzog(a)debian.org> wrote:
(Trimming the CC: feel free to drop patches(a)l.o if linaro-dev(a)l.l.o is
more useful. Please keep debian-embedded in CC to reach me.)
> Not knowing much about cross-compilation I had started with a sligthly
> different approach than you, mimicking exactly what was done for
> cross-compilation support.
09:48 < codehelp> buxy: vorlon: my original query related to not so
much building a cross-compiler but building gcc-* to install and run on
cross, i.e. reverse-cross where build=amd64,host=armel,target=armel
09:48 < codehelp> cross-compiler build=amd64,host=amd64,target=armel
09:48 < codehelp> doesn't give you a libgcc1 which can be used to
satisfy dependencies of packages cross-built using the cross-compiler
Cross-building an entire distro, like Emdebian Crush, involved a long
winded process:
0: Build gcc-4.* as an arm cross-compiler (not armel in those days but
that's not important to the method)
1: Build build-dependencies of gcc using the cross-compiler
2: Build gcc-4.* as a normal package using the cross-compiler
The people who are most likely to be doing this now are Linaro.
Emdebian Crush stalled after Lenny (and used ARM not armel), so the
version of gcc-4.2 in Lenny should still build with the typical
"dpkg-buildpackage -aarm". Later versions of gcc probably have other
fixes which would cause the reverse cross build to fail, not due to the
failure of the original patches but due to changes in gcc itself.
To create a fully bootstrap-able system, gcc does need to support the
reverse cross and this will need testing in Multi-arch world.
Typically, gcc-4.* *should* be expected to build correctly just using:
$ dpkg-buildpackage -a$arch
No special target specification (except internally in debian/rules
etc.), no expectation of building a cross-compiler, just building it as
if it is any other package which needs to be cross-built.
Of course, if libgcc1 can be made available in any other way than
having to pretend that we actually want a native compiler on these
systems (99% of the time we really don't), then everyone wins.
> Neil (or anyone else knowledgable on the topic), can you review the
> patches and tell us what's really needed and most logical according to
> you?
>
> Steve's patch:
> - adds the multi-arch path at the start of the search paths
> - adds them only for stantard cross-compilation (host != build) but not
> for the special cases used to detect a cross-compiler build
Intuitively this does sound the correct way to do it, especially as
what I wanted from the original patch was a standard cross-build, not
the special case of building a cross-compiler, but:
> My patch:
> - adds the multi-arch path before the cross-arch patch but after the
> standard search path
>
> - add them in all cases where the cross-compilation paths are used
>
> Putting the multi-arch paths after the default path should not matter as
> dpkg-shlibdeps skips libraries of non-matching architecture.
This is more in line with how it actually works out when trying to
cross-build gcc itself.
I'm not sure of the benefit of putting the multiarch lib location in
front of the default lib location. I'm not sure if having some i386
libraries in a multi-arch path and the main system amd64 libraries in a
non-multi-arch path would actually matter (after all, the same libraries
*should* get updated together). That's a "traditional" Multi-Arch
question, so I'd defer to Steve on that one.
For cross-building, it's simply sufficient that the new
multi-arch-cross paths precede the old dpkg-cross paths and both
patches achieve this.
> For the case of building a cross-compiler, Steve's experience tends to
> prove that adding the multi-arch path is not needed... but I don't see why
> it should be treated differently than the cross-arch paths.
>
> Can you enlighten us?
For building a cross-compiler, Steve is correct - it doesn't matter.
For using that cross-compiler to cross-compile gcc itself, it will
matter. Multi-Arch paths will be necessary to build a version of
libgcc1 which can be installed on the target.
--
Neil Williams
=============
http://www.linux.codehelp.co.uk/
vold.fstab is the vold configuration file to tell what the device to
mount.
Signed-off-by: Jeremy Chang <jeremy.chang(a)linaro.org>
---
device.mk | 16 ++++++++++++++++
pandaboard.mk | 1 +
vold.fstab | 15 +++++++++++++++
3 files changed, 32 insertions(+), 0 deletions(-)
create mode 100644 device.mk
create mode 100644 vold.fstab
diff --git a/device.mk b/device.mk
new file mode 100644
index 0000000..79979e3
--- /dev/null
+++ b/device.mk
@@ -0,0 +1,16 @@
+# Copyright (C) 2010 The Android Open Source Project
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+PRODUCT_COPY_FILES := \
+ device/linaro/beagleboard/vold.fstab:system/etc/vold.fstab
diff --git a/pandaboard.mk b/pandaboard.mk
index b7aab1c..7c15efd 100644
--- a/pandaboard.mk
+++ b/pandaboard.mk
@@ -28,6 +28,7 @@ PRODUCT_PACKAGES := \
$(ZEROXBENCHMARK_NATIVE_APPS)
$(call inherit-product, $(SRC_TARGET_DIR)/product/core.mk)
+$(call inherit-product, device/linaro/pandaboard/device.mk)
# Overrides
PRODUCT_BRAND := pandaboard
diff --git a/vold.fstab b/vold.fstab
new file mode 100644
index 0000000..c17bb64
--- /dev/null
+++ b/vold.fstab
@@ -0,0 +1,15 @@
+## Vold 2.0 Generic fstab
+## - San Mehat (san(a)android.com)
+##
+
+#######################
+## Regular device mount
+##
+## Format: dev_mount <label> <mount_point> <part> <sysfs_path1...>
+## label - Label for the volume
+## mount_point - Where the volume will be mounted
+## part - Partition # (1 based), or 'auto' for first usable partition.
+## <sysfs_path> - List of sysfs paths to source devices
+######################
+
+dev_mount sdcard /mnt/sdcard 7 /devices/platform/mmci-omap-hs.0/mmc_host/mmc0
--
1.7.1
Hi Michael,
That wiki page[1] gave me a good overview of the build service; I have
only a couple questions.
Also, even though I didn't actually read most of the code, I saw some
shell script to configure the build slave and I'm wondering if you think
it'd be worth using something like puppet for that instead. The scripts
seem small enough at this point, so it may not worth the effort at this
point, but I'm sure they'll grow over time and we don't want to end up
with a mess similar to the old l-m-c.
> SCRIPT_NAME: Defines the name of the[...]
At first I thought it'd be nice to have a short description of the
existing scripts here, but it looks like we only have the regular one
and an extra for building with a custom toolchain, so maybe it's not
neeeded?
> To get your script into the branch used by the build system,
> submit a merge proposal to [...]
I guess that means the jenkins job created under the hoods will always
use the tip of the build-tools branch, avoiding the need for a manual
update?
Cheers,
[1]https://wiki.linaro.org/MichaelHudson/Sandbox/LinaroAndroidBuildService
--
Guilherme Salgado <https://launchpad.net/~salgado>
