linaro-dev May 2011

linaro-dev@lists.linaro.org

122 participants
116 discussions

by Alexandros Frantzis

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

14 years

Compilation error for x86 after adding omap_gpu drm driver

by Tushar Behera

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

14 years

Linaro-cloud-buildd upgraded to Natty and other updates

by Paul Sokolovsky

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

14 years

designing the scheduler command line api

by Michael Hudson-Doyle

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

14 years

lava-dashboard and lava-server and beyond

by Zygmunt Krynicki

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

14 years

Linaro Public Plan Review - Infrastructure and Validation

by Paul Larson

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

14 years

approaching a final kernel for 11.05

by John Rigby

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

14 years

by Yang Zhang

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.

14 years

linaro-uboot: device tree without ramdisk and boot_relocate_fdt cause illegal memory access in kernel

by Barry Song

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

14 years

[ACTIVITY] Android Team 2011-05-15 to 2011-05-21

by Zach Pfeffer

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

14 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev May 2011