[PATCH] ARM: device-tree: Add basic device tree support for Beagleboad
Note, no corresponding U-Boot changes to U-Boot are required as the
Linaro version already has these.
Hi there,
i have seen what you've started to implement with the Android Build service.
I am wondering if:
- all the source code / tools you've put in place is available (source code)
- how easy (or not) would that be to deploy this infrastructure 'internally'
so that we can use it for private builds for example?
- what are the requirements on the 'server/host' to be able to replicate
this setup?
thx,
nicolas
Hello everyone,
As I've been working on the integration of the latest developments and
fixes from upstream into the linaro-2.6.38 kernel lately, it became
quickly evident that major merge conflicts were to be expected. The
problem stems from the fact that we opened the 2.6.38 branch early i.e.
around the 2.6.38-rc5 kernel. Many patches that were merged into the
Linaro kernel have been subsequently modified by their respective
maintainers until they were merged upstream, meaning that what we have
now in mainline is different from what the Linaro kernel tree has. This
creates several issues:
- It is hard to verify that what is in the Linaro tree is actually the
latest and the best version of a patch.
- Merging additional fixes from upstream often ends up in merge
conflicts requiring manual resolution, sometimes non-trivial ones,
which is in itself a bug hazard.
- People wanting to contribute patches to the Linaro kernel potentially
have to create a different patch than what they would submit
upstream.
Given those issues, I decided to rebuild the linaro-2.6.38 branch from
scratch to see where that would bring me. And as could be expected, the
result looks nicer and it is much easier to work with than the current
tree. For example, this allowed me to merge the latest OMAP support
from mainline as is, including the latest fixes, without any need for
backport work nor major conflict resolution. Another advantage is that
the commit SHA1 references are now identical in most cases to what can
be found into mainline.
So... my question is: should we switch to this rebuilt tree or not?
There are drawbacks with such a move of course:
- All the testing done so far would be void. This is however not as
bad as this may look as the rebuilt kernel contains fixes for existing
bugs in the current tree, and the rebuilt kernel is using patches
that have and still are being tested by a wider community.
- I didn't forward port a couple series of patches that are available
in the current Linaro tree and not in mainline yet, including:
* DT support (Grant Likely)
* DVFS and PM for OMAP (Vishwanath Sripathy, Vishwanath BS)
* Some ux500 fixups (Linus Walleij)
* clock debug information (Yong Shen)
* Samsung CPUIDLE (Amit Kachhap)
So I would prefer if the people responsible for those patches did
resubmit their patches once they apply to the new tree (that should
be even easier now to apply patches that were meant for mainline).
- The history of the rebuilt tree is obviously different from the
current tree's. This means special care when updating to the new
tree with Git.
But overall I think there are more advantages than disadvantages for
such a move. What other people think?
The current rebuilt tree can be seen at:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.38.git;a=shortlog;h=…
or obtained from:
git://git.linaro.org/kernel/linux-linaro-2.6.38.git (the "rebuilt" branch)
Nicolas
Hi,
We are looking for volunteers who could run demos and short tutorials at
the technical showcase we are organizing at LDS.
In particular, we hope that the landing teams will be able to show the
newest community boards in action, which almost nobody has seen in real
life yet. Here are suggestions:
* Power management demos, showing suspend/resume/hibernation and the
time they take, measuring power on the board, using powerdebug...
* Debugging quick tutorial
* perf demos
* Toolchain performance benchmarks
* Video codec performance benchmarks
* Demos of new QEMU targets
* linaro-media-create quick tutorial
* Device tree demo
* Linaro Android Build Service
* ... and anything useful you could think of, typically advertising
for your contributions to Linaro!
The main goal would be to advertise our work, both internally and
externally, and then start interesting discussions, and hopefully end up
with improvements and new ideas.
We will try to videotape some demos and publish them on YouTube if
appropriate. There should also be a vote for the best demos and prizes
will be given away.
I let Kiko and others add their own suggestions.
See https://wiki.linaro.org/Events/2011-05-LDS/Showcase/ for details
about the event.
Thanks in advance,
Cheers,
Michael.
--
Michael Opdenacker, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
+ 33 621 604 642
Hi Folks,
As some of you may remember, Linaro engineers have access to free DS-5
licenses.
If you don't know what DS-5 is, you can stop reading now ;-)
If you know what DS-5 is, you may also use it, either on daily basis or
just occasionally? I'd be most grateful for letting me know about it.
It's nearly 5 months since I presented it at UDS, so I'd love to know
whether you found it useful by now.
I know that at least some of you tried it, so simple "yes, use it every
day, love it" or "well, sometimes, if there's nothing better to do" or
maybe "naaah, it's absolutely rubbish" will do. Of course don't hesitate
to elaborate more :-)
Cheers!
Paweł
Hi,
Kiko requested that we mass rename Releases to Cycles. This makes
sense since a release is a point in time event and we operate under a
larger cycle.
This is now done and a redirect has been put into place. As you see
references which are incorrect in wiki pages, please consider doing
some drive-by clean-up/gardening.
Thanks,
Joey
[cc'ing linaro-dev mailing list; other people will probably have the
same question]
On Mon, Mar 28, 2011 at 4:40 AM, Tixy <tixy(a)yxit.co.uk> wrote:
> On Mon, 2011-03-21 at 03:25 -0600, Grant Likely wrote:
>> For each board, I need an engineer to do the following:
>>
> [...]
>> 2) Enable CONFIG_OF and CONFIG_PROC_DEVICETREE in the kernel
> [...]
>
> Do we want these enabled by default when a supported platform is
> configured?. From someone else's example[1] I guess this would be done
> by editing arch/arm/mach-omap2/Kconfig like
>
> config MACH_OMAP3_BEAGLE
> bool "OMAP3 BEAGLE board"
> depends on ARCH_OMAP3
> default y
> select OMAP_PACKAGE_CBB
> + select USE_OF
> + select PROC_DEVICETREE
>
> Though I guess we could get PROC_DEVICETREE selected at a higher level
> if USE_OF is selected? (I'm new to Linux and its configuration methods).
I would omit these two lines. Device tree support is an optional feature.
g.
Hi,
notes and actions from our Wednesday graphics working group call are
available on the wiki:
+ https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2011-03-23
Details about when and where of this meeting can be found here:
+ https://wiki.linaro.org/WorkingGroups/Middleware/Graphics#Weekly%20Public%2…
Summary
=======
* Kernel tree for UMP and Mali device driver awaiting landing team approval.
* Benchmark/validation: cairo and Qt traces created, packaged and on developer PPA.
* cairo-gles2
* Patchset "Add r8g8b8a8 and r8g8b8x8 formats" sent to upstream Pixman for review.
* Key driver bugs affecting current work (may have been fixed, but not yet in archive):
* cairo-gles2
* eglInitialize performance on OMAP4 (LP #690821)
* color component swapping on efikamx (LP #736869)
* No GL_OES_texture_npot extension on OMAP4.
* glcompbench
* EGL_KHR_image_pixmap functionality flaky on efikamx (LP #733403)
* glcompbench rendering is not presented on screen on efikamx (LP #736811)
Risks / Issues
==============
* Aforementioned bugs may impact validation effort and release of work.
* Skia runtime detection of NEON work stalled in upstream apathy.
Thanks,
--
- Alexandros
