Hi all,
I completely missed the Linaro release process session during LDS, but
here are my thoughts on the Linaro development cycle.
Currently, the Linaro cycle lags behind the Ubuntu cycle by one month.
This is done so that the Linaro releases are based on a stable system.
Unfortunately, this scheme causes some disruption for me (and I suspect for
other engineers, too). The problem is that while the current Linaro cycle is
still ongoing, we need to start planning for next-cycle/LDS, attend LDS and
after that investigate some more and create the specifications. This is hard
and time consuming work and I am sure not many people (including me) can
continue to work effectively on their remaining work items while drafting
specifications or attending LDS. The problem is exacerbated further because the
end of cycle is usually a very strenuous period for engineers.
So my questions/suggestions are:
1. Do other engineers feel this way?
2. From people's experience, has the one-month-after-ubuntu schedule provided
concrete advantages? Could we get away with less (e.g. one week)?
3. If we don't change anything we should at least make this situation very clear
to engineers/managers, so that they can plan accordingly:
~5 months of normal work, starting two weeks after LDS and ending one week
before the next LDS. Keep the rest for planning/LDS and spec-ing, plus some
light work.
Thoughts?
Thanks,
Alexandros
Hi Rob,
The patch d795e2c "Adding omap_gpu drm display driver" introduces
following compilation warning when the kernel is compiled for x86
(i386_defconfig). Also the kernel compilation is unsuccessful because of
calls to omap specific platform header files.
warning: (VIDEO_OMAP2_VOUT && DRM_OMAP) selects OMAP2_DSS which has
unmet direct dependencies (HAS_IOMEM && ARCH_OMAP2PLUS)
In my test, following patch fixes this issue.
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 9c103b2..848312e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -168,7 +168,7 @@ config DRM_SAVAGE
config DRM_OMAP
tristate "OMAP GPU (EXPERIMENTAL)"
- depends on DRM && !CONFIG_FB_OMAP2
+ depends on DRM && ARCH_OMAP2 && !CONFIG_FB_OMAP2
select DRM_KMS_HELPER
select OMAP2_VRAM
select OMAP2_DSS
--
Tushar Behera
Hello,
Linaro-cloud-buildd is the system which utilizes EC2 cloud to build
Linaro Android releases and developments images,
https://android-build.linaro.org/
After Linaro 11.05 release is out and pre-release infrastructure freeze
is over, cloud build instances were upgraded to use Ubuntu 11.04
(Natty) images. Please let me know if there will be any issues after
the upgrade.
Other updates include better error reporting for cloud git mirror
service and initial support for building Linaro Android toolchain, as
well as other gradual improvements to reliability and flexibility.
Lianro-cloud-buildd documentation is at
https://wiki.linaro.org/Platform/Android/LinaroAndroidBuildService ,
and was recently updated with information about new features.
Currently, there're 367 builds in the archive, which took 251
machine-hours to build.
Thanks,
Paul
Hi all,
I'm working on the infrastructure that will underlie the scheduler
command line api. Zygmunt and I have the technical side understood I
think, but what I want to think aloud about is how the command line
should work for a user. In particular, I wonder how much state the
command line tool should save.
The basic command line entry point is "submit a job". For now at least,
the job will be a JSON file, so the simplest possible invocation would
be:
$ lava-tool submit-job test.json
But this doesn't specify anything about where the job should go. The
least effort solution would be to require a full specification on the
command line:
$ lava-tool submit-job --farm https://mwhudson:$token@validation.linaro.org test.json
This is clearly a bad idea though: tokens will be long and unwieldy and
passing it on the command line means they will be disclosed in ways that
we should avoid (they'll appear in ps output for all users and could
easily end up in log files).
So we need a way of storing tokens. The easiest thing to do would be to
store a token for a (username, host) pair, so you'd run a command like:
$ lava-tool auth-add --token-file token-file https://mwhudson@validation.linaro.org
Then you'd still need to specify the username and host on every
invocation:
$ lava-tool submit-job --farm https://mwhudson@validation.linaro.org test.json
Would this be too unwieldy do you think? For scripted or cronjobbed
invocations its probably fine, for the command line it might be a bit
awkward. But I don't know how much call there is for a genuinely
interactive tool here.
I guess the point I've argued myself to here is that I should implement
this long form for now, and if a need arises add more conveniences (for
example, reading from an environment variable or adding a command to set
the defaults). Does anyone disagree too strongly with that?
Cheers,
mwh
Hi
I finally made lava-dashboard run on lava-server.
The relevant code is in lp:lava-server (trunk) and in
lp:~zkrynicki/lava-dashboard/zyga (merge request). Feel free to look at
the request to see if I did some accidental edits (bzr commit
--interactive does not work for me on bzr 2.4 :-(
The next step is to make development smooth by packaging prerequisites
(a few new packages are needed both in debian and pypi) and sorting out
setup-dev-env.sh
I'm considering rewriting setup-dev-env.sh to be .py file that calls
into extensions to set themselves up properly but it may be non-trivial.
I'll see how it will work, if you have any suggestions feel free to say so.
If nothing breaks tomorrow I'll release lava-server 0.1 and
lava-dashboard 0.5 and start 11.06 cycle. Initial stories plus a few
tasks are listed here: http://fracture.suxx.pl/rb/taskboards/12 I'll be
adding more items to that as I sort out priorities with plars this evening.
Michael: when can we expect the shuffle of launchpad projects? Are we
staying with lava-server and lava-dashboard and abandoning launch-control?
Thanks
ZK
Hi everyone, the Linaro Infrastructure and Validation teams will be
conducting a public plan review Friday, June 3 at 15:00 UTC. If you have an
interest in the work being done by either of these teams, feel free to join
the call, or catch the recordings which should be posted afterwards.
Details about all the public plan reviews can be found at:
https://wiki.linaro.org/Cycles/1111/PublicPlanReview
Thanks,
Paul Larson
Thanks to the heroic efforts of rsalveti the packaged
linux-linaro-omap kernel now greatly improved omap4 display
functionality. There is a .deb in the linaro-maintainers kernel ppa.
If you have a panda board and have time to try it out your feedback
would be much appreciated:
https://launchpad.net/~linaro-maintainers/+archive/kernel/+files/linux-imag…
--john
Join the group
Yang Zhang
Home software Enabling Engineer, ARM
Phone: +86-21-6229-0729 ext. 681
Email: yang.zhang(a)arm.com<mailto:yang.zhang@arm.com>
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi all,
i am using linaro uboot(u-boot-linaro-stable.git). i have let our
prima2 board support device tree with some workaround in uboot. two
problems i have meet:
1. device tree without ramdisk
now uboot used commands like
"bootm kernel_address ramdisk_address dtb_address"
to start linux kernel.
in many cases, people have no ramdisk at all, but the following codes
will still stop people to use device tree to start kernel since it got
an illegal ramdisk:
common/cmd_bootm.c:
if (((images.os.type == IH_TYPE_KERNEL) ||
(images.os.type == IH_TYPE_MULTI)) &&
(images.os.os == IH_OS_LINUX)) {
/* find ramdisk */
ret = boot_get_ramdisk (argc, argv, &images, IH_INITRD_ARCH,
&images.rd_start, &images.rd_end);
if (ret) {
puts ("Ramdisk image is corrupt or invalid\n");
return 1;
}
#if defined(CONFIG_OF_LIBFDT)
/* find flattened device tree */
ret = boot_get_fdt (flag, argc, argv, &images,
&images.ft_addr, &images.ft_len);
if (ret) {
puts ("Could not find a valid device tree\n");
return 1;
}
then i delete the first return 1 to let uboot ignore the ramdisk checking.
2. boot_relocate_fdt in common/image.c
this function will relocate fdt to an new address by:
lmb_alloc_base(lmb, of_len, 0x1000, getenv_bootm_mapsize() + getenv_bootm_low())
but the return address is probably not in the initilized scale which
kernel will build mapping in head.S. then in the function
setup_machine_fdt() of arch/arm/kernel/devtree.c, when executing:
devtree = phys_to_virt(dt_phys);
/* check device tree validity */
if (be32_to_cpu(devtree->magic) != OF_DT_HEADER)
return NULL;
kernel will die due to illegal memory access since dt_phys was not
mapped to virtual address yet.
For problem1 , could uboot have a way to ignore ramdisk by itself?
since we need 3 param in bootm to support device tree. For problem2,
could uboot just relocate fdt to the original address of old ATAG,
OFF+ 0x100?
Thanks
Barry
Original: https://wiki.linaro.org/Platform/Android/Status/2011-05-28
== Key Points for wider discussion ==
* Debugged and enabled GFX on the Panda LEB
== Team Highlights ==
* Worked to finish the remaining Android LAVA issues
* Worked on Computex demo
* Worked on Linaro toolchain issues with Android
* Wrote job descriptions for the Android team
* Worked on Blueprints
* Cleaned up "Getting Source" and "Building Source" Platform/Android
== Risks / Issues ==
* Computex demo
* Staff
* Need for all teams to start delivering against the Android builds