Greetings,
So far I wasn't updating the linux-linaro tree since the 12.04 release.
(The generic topic updates were being done to the
linux-linaro-core-tracking tree)
Now it is time to move the focus to the linux-linaro tree. For one week
it will use the mainline tip as the base. Then, on next Thursday the
most recent -rc will be selected as the base, and won't be changed until
12.05 is released. Most probably it will be v3.4-rc7.
The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus
the 7 generic topics currently included into the
linux-linaro-core-tracking tree:
ufs (ufs-for-linux-linaro)
emmc (emmc-for-linux-linaro)
thermal_exynos4_imx6 (thermal_exynos4_imx6_work)
linaro-android-3.4
armlt-gator (tracking-armlt-gator)
umm-wip (umm-3.4rc4-wip)
linaro-configs-3.4
If you don't see your generic topic in this list, but you think it
should be there, please let me know ASAP. If you have a new topic to
add, please send me the request before the next Thursday, May 17; the
sooner, the better. The requirements for a topic can be found here:
https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#A…
The landing teams - please update your topic branches if needed:
ARM:
tracking-armlt-hdlcd tracking-armlt-mmc
tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes
tracking-armlt-ubuntu-config tracking-armlt-android-config
Samsung:
topic/base topic/core topic/bl topic/dt topic/fb topic/pd
topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg
topic/gadget topic/touch topic/wlan topic/audio topic/hdmi
topic/mali topic/cma_v24 topic/android_config
Thanks,
Andrey
Hi,
Thank you for your work on the dev boards. Recently i had been working
with Android. Your work saved a lot of time for me.
I request you to also consider support the raspberry pi board. Which is
quite useful for many people. Enduses as well as devs..
Thank you
Are we going to start using the config fragments we created a while ago?
(Or did we not reach consensus on that?)
If we could get them into a 'final' git location and start using them
for Ubuntu packaging, I can arrange for a mechanism to enable Android
builds to use them.
I have attached a couple of patches for the config fragments (3.5
removed the PERF_COUNTERS config).
--
Tixy
Hi all,
Some of you probably know bits about this already, but the LAVA team
has been working to implement features around privacy of test jobs and
results in LAVA.
One feature that has actually been present from the beginning but
hardly used is that bundle streams have defined access rules. Most
streams for the last year or so have been anonymous, which means that
anyone can see results in the stream, and anyone can put results in
the stream.
If a stream is not anonymous, it can either be owned by a person or a
group, and independently it can be public or private. Only the owner
(or members of the owning team) can put results into a non-anonymous
bundle and only the owner (or members of the owning team) can see the
results in a private bundle. Everyone can see the results in a public
bundle.
All this information about a bundle is encoded in its name:
public personal
/ -or- / -or- / {person-or-team name} / {bundle name} /
personal team
The reason for going on about this is that it is now possible to
create jobs for LAVA that can submit to a non-anonymous stream and
that the visibility rules for a _job_ are the same as the _stream_ it
will submit results to (also, if you try to submit a job that will
submit to a stream you cannot submit to yourself, this will be
rejected at submission time, rather than failing right at the end of
the job). So, I wanted to submit a job that would submit to a private
strteam of mine, I might put this in my LAVA job:
"command": "submit_results",
"parameters":
{
"server": "http://validation.linaro.org/lava-serverRPC2/",
"stream": "/private/personal/mwhudson/random/"
}
We've already converted most of the automatically submitted jobs over to
using private streams (visible to members of ~linaro on Launchpad) per
the new privacy policy, but this email should give you an idea of what
is possible when setting up new jobs.
Cheers,
mwh & the LAVA team
Hi
I was cross-compiling a Linux kernel 2.6.38 for a Gumstix Overo
which is a tiny ARM (TI OMAP 35xx) based single board computer.
I was using Linaro cross compiler (arm-linux-gnueabi-gcc) did not
give an uImage that gets pass the Loading uImage. My console is
ttyO2 and therefore it was not an issue. So I used Code Sourcey
G++ Lite (64 bits version without ia32 library) and the kernel image
uImage.bin built with the same configuration file (.config) but with
different cross compiler can boot up to the stage that the kernel
tries to mount ext3 partition on microSD card. So I suspect the
package gcc-linux-arm-gnueabi has some bugs. I have a working
2.6.35 kernel (although I do not have the .config file with settings
which I have used to build that) that was built with Linaro Gcc 4.3
or 4.4. I suspect the Linaro Gcc 4.5.x and above are giving me a
problem. I used the Linaro media create tool with root file system
and hardware pack but it also could not help me boot nor give me
the right config file which I can use to cross compile a working
kernel (that is booting kernel) for Overo computer.
So I tried also native compilation using Linaro GCC 4.5 but it is
not working. I wonder has anyone face the same issue like me,
I think I am wrong somewhere (the last time I cross compile the
kernel was pretty much straight forward and I dont remember I
had to patch the kernel I fetched from a git repository. But I will
be glad to hear who has faced similar problems like me. Any tips
will be appreciated. Even better, I will be glad to learn where did
you download (git fetch or git clone or wget or just http download),
your tool chain, your workstation (my original laptop was 32 bits
dual core DELL and now I am using a 64 bits Intel i7 so I am not
sure which set up is biting me). Any tip or link will be appreciated.
Sincerely
Aung