Re: Boot sanity testing of release candidate kernel
Panda Testing update:
Booting on panda seems to be fine but sd/mmc dumps lot of I/O errors on
console.
Tested with device tree enabled and disabled. With device tree enable, the
MMC I/O
errors are more. Tried with multiple SD cards with different brands.
Not sure if there is any bug already listed for this issue.
Log:
Texas Instruments X-Loader 1.5.0 (Apr 11 2011 - 09:48:22)
Reading boot sector
Loading u-boot.bin from mmc
U-Boot 2011.03 (May 25 2011 - 17:23:48)
CPU : OMAP4430
Board: OMAP4 Panda
I2C: ready
DRAM: 1 GiB
MMC: OMAP SD/MMC: 0
Using default environment
In:serial
Out: serial
Err: serial
Hit any key to stop autoboot: 3 0
Panda #
Panda # mmc rescan 0
Panda # setenv dtbaddr 0x8160
Panda # setenv bootcmd 'fatload mmc 0:1 0x8000 uImage; fatload mmc 0:1
0x8170 uInitrd; fatload mmc 0:1 ${dtbaddr} panda.dtb; fdt addr
${dtbaddr}; fdt resize; bootm 0x8000 0x8170 ${dtbaddr}'
Panda # setenv bootargs ' console=tty0 console=ttyO2,115200n8 root=/init
rootwait ro earlyprintk'
Panda # boot
reading uImage
8230292 bytes read
reading uInitrd
4761795 bytes read
reading panda.dtb
344 bytes read
## Booting kernel from Legacy Image at 8000 ...
Image Name: Linux-2.6.38.7
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:8230228 Bytes = 7.8 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 8170 ...
Image Name: initramfs
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size:4761731 Bytes = 4.5 MiB
Load Address:
Entry Point:
Verifying Checksum ... OK
## Flattened Device Tree blob at 8160
Booting using the fdt blob at 0x8160
Loading Kernel Image ... OK
OK
reserving fdt memory region: addr=9d00 size=300
reserving fdt memory region: addr=b000 size=1000
reserving fdt memory region: addr=8160 size=1000
Loading Ramdisk to afb75000, end a883 ... OK
Loading Device Tree to afb71000, end afb74fff ... OK
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
[0.00] Linux version 2.6.38.7 (linaro@linaro-pc) (gcc version 4.5.2
(Ubuntu/Linaro 4.5.2-8ubuntu3) ) #5 SMP Thu May 26 11:47:07 IST 2011
[0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7),
cr=10c5387f
[0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction
cache
[0.00] Machine: OMAP4 Panda board, model: TI OMAP4 PandaBoard
[0.00] Reserving 33554432 bytes SDRAM for VRAM
[0.00] Memory policy: ECC disabled, Data cache writealloc
[0.00] OMAP_TAP_DIE_ID_0: 0x0100
[0.00] OMAP_TAP_DIE_ID_1: 0x0612d687
[0.00] OMAP_TAP_DIE_ID_2: 0x0001
[0.00] OMAP_TAP_DIE_ID_3: 0x1d620003
[0.00] OMAP4430 ES2.1
[0.00] SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000
[0.00] powerdomain: waited too long for powerdomain dss_pwrdm to
complete transition
[0.00] PERCPU: Embedded 8 pages/cpu @c2077000 s10336 r8192 d14240
u32768
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 251904
[0.00] Kernel command line: console=tty0 console=ttyO2,115200n8
root=/init rootwait ro earlyprintk
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes)
[0.00] Memory: 730MB 262MB = 992MB total
[0.00] Memory: 665744k/665744k available, 382832k reserved, 0K
highmem
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB)
[0.00] DMA : 0xffc0 - 0xffe0 ( 2 MB)
[0.00] vmalloc : 0xf080 - 0xf800 ( 120 MB)
[0.00] lowmem : 0xc000 - 0xf000 ( 768 MB)
[0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
[0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB)
[0.00] .init : 0xc0008000 - 0xc0c56000 (12600 kB)
[0.00] .text : 0xc0c56000 - 0xc12993e4 (6413 kB)
[0.00] .data : 0xc129a000 - 0xc1309550 ( 446 kB)
[0.00] Hierarchical RCU implementation.
[0.00] RCU-based detection of stalled CPUs is disabled.
[0.00] NR_IRQS:410
[0.00] omap_hwmod: dpll_mpu_m2_ck: missing clockdomain for
dpll_mpu_m2_ck.
[0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz
[0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps
every 131071999ms
[0.00] Console: colour dummy device 80x30
[0.00] console [tty0] enabled
[0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc.,
Ingo Molnar
[0.00] ... MAX_LOCKDEP_SUBCLASSES: 8
[0.00] ... MAX_LOCK_DEPTH: 48
[
Re: Boot sanity testing of release candidate kernel
On 05/26/2011 08:15 AM, Somebody in the thread at some point said: Hi - Panda Testing update: Booting on panda seems to be fine but sd/mmc dumps lot of I/O errors on console. Tested with device tree enabled and disabled. With device tree enable, the MMC I/O errors are more. Tried with multiple SD cards with different brands. Not sure if there is any bug already listed for this issue. ## Flattened Device Tree blob at 8160 Booting using the fdt blob at 0x8160 Loading Kernel Image ... OK Not using DT but... [5.139984] mmcblk0: mmc0:c71c SD01G 982 MiB [5.146911] mmcblk0: retrying using single block read [5.147186] mmcblk0: error -84 transferring data, sector 0, nr 8, card status 0x900 ...not seeing this at all on an 8GB class 4 microSDHC, brand Veho I am using. Is your card really 1GB SD Card? Were any of the other cards SDHC? -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
proposal for reorganization of releases.linaro.org hierarchy
Hi,
Here's the following rationale:
1. as a user, I would like to easily find the released Linaro components:
* Linaro Evaluation Build (Android and Ubuntu LEB)
* Tools (linaro-image-tools)
* Working Groups (kernel, u-boot, gcc, gdb, qemu, powerdebug, powertop, etc...)
2. as a user, I would like to download the release for my ${board} in
one central place.
3. as a release manager on the road to monthly releases, I would like
to adjust the current layout to match the release process.
The current layout has some issues:
- a user should go through several paths to get a rootfs and a hardware pack.
- a user should go through several websites to find Linaro goods
(releases.l.o, launchpad.net)
- newcomers like Android doesn't fit well
- every team has a different release process
To resolve these user stories, we came up with 2 layouts proposal.
Please, see the document attached.
Feebdacks/suggestions on the proposals are welcome!
Note: we planned to start with platform directory only.
The working-groups could come later when we agree on the approach.
Cheers,
Fathi
--
Linaro Release Manager | Platform Project Manager
releases.linaro.org current layout
platform/linaro-n
|-- platform/linaro-n/alip
| |-- platform/linaro-n/alip/beta-2
| `-- platform/linaro-n/alip/latest - beta-2
|-- platform/linaro-n/android
| |-- platform/linaro-n/android/11.04
| | |-- platform/linaro-n/android/11.04/beaglexm
| | `-- platform/linaro-n/android/11.04/panda
| `-- platform/linaro-n/android/latest - 11.04/
|-- platform/linaro-n/developer
| |-- platform/linaro-n/developer/beta-2
| `-- platform/linaro-n/developer/latest - beta-2
|-- platform/linaro-n/hwpacks
| |-- platform/linaro-n/hwpacks/beta-2
| `-- platform/linaro-n/hwpacks/latest - beta-2
|-- platform/linaro-n/nano
| |-- platform/linaro-n/nano/beta-2
| `-- platform/linaro-n/nano/latest - beta-2
`-- platform/linaro-n/ubuntu-desktop
|-- platform/linaro-n/ubuntu-desktop/alpha-3
|-- platform/linaro-n/ubuntu-desktop/beta
|-- platform/linaro-n/ubuntu-desktop/beta-2
`-- platform/linaro-n/ubuntu-desktop/latest - beta-2
releases.linaro.org layout proposal 1
platform
|-- platform/11.05
| |-- platform/11.05/android
| | |-- platform/11.05/android/beaglexm
| | |-- platform/11.05/android/ndk
| | |-- platform/11.05/android/panda
| | |-- platform/11.05/android/sdk
| | `-- platform/11.05/android/toolchain
| |-- platform/11.05/tools
| | |-- platform/11.05/tools/linaro-image-tools
| `-- platform/11.05/ubuntu
| |-- platform/11.05/ubuntu/panda
| | |-- platform/11.05/ubuntu/panda
| | `-- platform/11.05/ubuntu/snowball
| `-- platform/11.05/ubuntu/snowball
[-- platform/11.06
`-- platform/latest - 11.06
working-groups
|-- working-groups/11.05
| |-- working-groups/11.05/graphics
| |-- working-groups/11.05/kernel
| |-- working-groups/11.05/multimedia
| |-- working-groups/11.05/power-management
| `-- working-groups/11.05/toolchain
|-- working-groups/11.06
| |-- working-groups/11.06/graphics
| |-- working-groups/11.06/kernel
| |-- working-groups/11.06/multimedia
| |-- working-groups/11.06/power-management
| |-- working-groups/11.06/toolchain
`-- working-groups/latest - 11.06
releases.linaro.org layout proposal 2
platform
|-- platform/android
| |-- platform/android/11.05
| | |-- platform/android/11.05/beaglexm
| | `-- platform/android/11.05/panda
| |-- platform/android/11.06
| | |-- platform/android/11.06/beaglexm
| | `-- platform/android/11.06/panda
| `-- platform/android/latest - 11.06
|-- tools/linaro-image-tools
||-- tools/linaro-image-tools/0.4.7
||-- tools/linaro-image-tools/0.4.8
|`-- tools/linaro-image-tools/latest - 0.4.8
`-- platform/ubuntu
|-- platform/ubuntu/11.05
| |-- platform/ubuntu/11.06/panda
| `-- platform/ubuntu/11.06/snowball
|-- platform/ubuntu/11.06
| |-- platform/ubuntu/11.06/panda
| `-- platform/ubuntu/11.06/snowball
`-- platform/ubuntu/latest - 11.06
working-groups
|-- working-groups/graphics
| |-- working-groups/graphics/11.05
| |-- working-groups/graphics/11.06
| `-- working-groups/graphics/latest - 11.06
|-- working-groups/kernel
| |-- working-groups/kernel/11.05
| |-- working-groups/kernel/11.06
| `-- working-groups/kernel/latest - 11.06
|-- working-groups/multimedia
| |-- working-groups/multimedia/11.05
| |-- working-groups/multimedia/11.06
| `-- working-groups/multimedia/latest - 11.06
|-- working-groups/power-management
| |-- working-groups/power-management/11.05
| |-- working-groups/power-management/11.06
| `-- working-groups/power-management/latest - 11.06
`-- working-groups/toolchain
|-- working-groups/toolchain/11.05
|-- working-groups/toolchain/11.06
`-- working-groups/toolchain/latest - 11.06
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
Re: [U-Boot] [PATCH v5 2/2] ARMV7: MMC SPL Boot support for SMDKV310 board
Dear Chander Kashyap, On 25 May 2011 15:02, Chander Kashyap chander.kash...@linaro.org wrote: Added MMC SPL boot support for SMDKV310. This framework design is based on nand_spl support. Signed-off-by: Chander Kashyap chander.kash...@linaro.org --- Changes for v3: - spl file renamed to u-boot-mmc-spl.bin - spl directory renamed to mmc_spl - comments added in mkv310_image.c file Changes for v5: - Compilation warning mmc_boot.c: In function 'board_init_r': mmc_boot.c:51: warning: 'noreturn' function does return fixed. Makefile | 11 ++ mmc_spl/board/samsung/smdkv310/Makefile | 105 ++ mmc_spl/board/samsung/smdkv310/mmc_boot.c | 85 ++ .../board/samsung/smdkv310/tools/mkv310_image.c | 116 mmc_spl/board/samsung/smdkv310/u-boot.lds | 86 +++ 5 files changed, 403 insertions(+), 0 deletions(-) create mode 100644 mmc_spl/board/samsung/smdkv310/Makefile create mode 100644 mmc_spl/board/samsung/smdkv310/mmc_boot.c create mode 100644 mmc_spl/board/samsung/smdkv310/tools/mkv310_image.c create mode 100644 mmc_spl/board/samsung/smdkv310/u-boot.lds applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [PATCH v5 1/2] ARMV7: Add support for Samsung SMDKV310 Board
Dear Chander Kashyap, On 25 May 2011 15:02, Chander Kashyap chander.kash...@linaro.org wrote: SMDKV310 board is based on Samsung S5PV310 SOC. This SOC is very much similar to S5PC210. Signed-off-by: Chander Kashyap chander.kash...@linaro.org Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- Changes for v2: - Coding Style Cleanup - Removed unwanted macros from board config file. - Ethernet controllor configuration is done using gpio structures. - MMC Controllor gpio configuration corrected. - Added MAINTAINERS entry. - Removed unwanted code from mem_setup.S. Changes for v3: - Comment style fixed - Added New macro in board config file. Changes for v4: - Fixed line with more than 80 characters in board config file MAINTAINERS | 4 + board/samsung/smdkv310/Makefile | 46 +++ board/samsung/smdkv310/lowlevel_init.S | 470 board/samsung/smdkv310/mem_setup.S | 365 + board/samsung/smdkv310/smdkv310.c | 136 + boards.cfg | 1 + include/configs/smdkv310.h | 169 7 files changed, 1191 insertions(+), 0 deletions(-) create mode 100644 board/samsung/smdkv310/Makefile create mode 100644 board/samsung/smdkv310/lowlevel_init.S create mode 100644 board/samsung/smdkv310/mem_setup.S create mode 100644 board/samsung/smdkv310/smdkv310.c create mode 100644 include/configs/smdkv310.h applied to u-boot-samsung Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Boot sanity testing of release candidate kernel
Hi Andy, On Thu, May 26, 2011 at 2:04 PM, Andy Green a...@warmcat.com wrote: On 05/26/2011 08:15 AM, Somebody in the thread at some point said: Hi - Panda Testing update: Booting on panda seems to be fine but sd/mmc dumps lot of I/O errors on console. Tested with device tree enabled and disabled. With device tree enable, the MMC I/O errors are more. Tried with multiple SD cards with different brands. Not sure if there is any bug already listed for this issue. ## Flattened Device Tree blob at 8160 Booting using the fdt blob at 0x8160 Loading Kernel Image ... OK Not using DT but... it happens without DT also [5.139984] mmcblk0: mmc0:c71c SD01G 982 MiB [5.146911] mmcblk0: retrying using single block read [5.147186] mmcblk0: error -84 transferring data, sector 0, nr 8, card status 0x900 ...not seeing this at all on an 8GB class 4 microSDHC, brand Veho I am using. Tried with Sandisk SDHC Card 4GB(class 4) but with this card, it fails to load kernel image from SD to RAM log: Panda # fatls mmc 0:1 mmc_send_cmd: timedout waiting for cmddis! ** Can't read from device 0 ** ** Unable to use mmc 0:1 for fatls ** Panda # Is your card really 1GB SD Card? Were any of the other cards SDHC? yeah...it's Kingston 1GB card. I have only two cards with me now. I can try with some other cards also. -M ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: proposal for reorganization of releases.linaro.org hierarchy
Hey On Thu, May 26, 2011, Fathi Boudra wrote: releases.linaro.org layout proposal 1 Jamie, Alexander and myself once had a long and relatively painful discussion about the ideal layout; my main argument in the discussion was that the names and contents of our releases will keep changing, we will rebrand the names we use for our outputs (e.g. LEB or platform images), we will add and remove outputs, so my proposal was for the toplevel to be the date of the release, much like the http://releases.ubuntu.com/ toplevel. For a similar discussion on snapshots.linaro.org, http://cdimage.ubuntu.com/ might be a good example where there's only a toplevel by project, then subdirs by date or arch, or whatever. The main advantage of having a /$year-$month/ toplevel is that you magically historize the old product names; people will want the latest release anyway. Back when Alexander, Jamie and I had this discussion, there was an area of confusion for the end-user because we had 6-monthly outputs and monthly outputs, and monthly outputs were not on releases.linaro.org. But interestingly your argument is about user experience, not about the best layout. I don't think browsing a file hierarchy over http is a particularly friendly user experience, nor reading multiple web pages, downloading multiple bits. A better user experience is if we can provide pre-built consumable images as we discussed at Budapest, or if we can provide a tool to download the right hwpack + rootfs for your board and then run linaro-media-create automatically; James Tunnicliffe is working on such a TestDrive tool. It's fair to say that we could make the web user experience better, but instead of changing the layout, could we simply provide entry points to browse related things together? For instance we could offer a search page to find all OMAP related downloads. Or we could generate a page per board with all the latest files related to this board. As part of TestDrive, James Tunnicliffe wrote a tool to scan images on releases.linaro.org and generate a sqlite3 db. We could use this tool or this db, or a similar approach, as the source of information for everything related to beagleboard or latest images for all platforms. Integration with Launchpad could we done via launchpadlib; no need to copy the tarballs around, or change existing practices or hosting locations. Cheers, -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: proposal for reorganization of releases.linaro.org hierarchy
Hi,Fathi Boudra IT is a good idea and Thanks for the work. On 26 May 2011 17:24, Loïc Minier loic.min...@linaro.org wrote: Hey On Thu, May 26, 2011, Fathi Boudra wrote: releases.linaro.org layout proposal 1 Jamie, Alexander and myself once had a long and relatively painful discussion about the ideal layout; my main argument in the discussion was that the names and contents of our releases will keep changing, we will rebrand the names we use for our outputs (e.g. LEB or platform images), we will add and remove outputs, so my proposal was for the toplevel to be the date of the release, much like the http://releases.ubuntu.com/ toplevel. For a similar discussion on snapshots.linaro.org, http://cdimage.ubuntu.com/ might be a good example where there's only a toplevel by project, then subdirs by date or arch, or whatever. The main advantage of having a /$year-$month/ toplevel is that you magically historize the old product names; people will want the latest release anyway. Back when Alexander, Jamie and I had this discussion, there was an area of confusion for the end-user because we had 6-monthly outputs and monthly outputs, and monthly outputs were not on releases.linaro.org. But interestingly your argument is about user experience, not about the best layout. I don't think browsing a file hierarchy over http is a particularly friendly user experience, nor reading multiple web pages, downloading multiple bits. A better user experience is if we can provide pre-built consumable images as we discussed at Budapest, or if we can provide a tool to download the right hwpack + rootfs for your board and then run linaro-media-create automatically; James Tunnicliffe is working on such a TestDrive tool. It's fair to say that we could make the web user experience better, but instead of changing the layout, could we simply provide entry points to browse related things together? For instance we could offer a search page to find all OMAP related downloads. Or we could generate a page per board with all the latest files related to this board. As part of TestDrive, James Tunnicliffe wrote a tool to scan images on releases.linaro.org and generate a sqlite3 db. We could use this tool or this db, or a similar approach, as the source of information for everything related to beagleboard or latest images for all platforms. Integration with Launchpad could we done via launchpadlib; no need to copy the tarballs around, or change existing practices or hosting locations. Cheers, -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- JUST DO IT,NOTHING IS IMPOSSIBLE ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Boot sanity testing of release candidate kernel
On Thu, May 26, 2011 at 3:08 PM, Jassi Brar jassisinghb...@gmail.comwrote: On Thu, May 26, 2011 at 2:50 PM, G, Manjunath Kondaiah manj...@ti.com wrote: Is your card really 1GB SD Card? Were any of the other cards SDHC? yeah...it's Kingston 1GB card. I have only two cards with me now. I can try with some other cards also. Most probably it's card issue. I have been using 4 and 8GB cards and never saw any problem. It happens with multiple cards both with SD and SDHC. I can check with other panda board BTW, SDHC cards are SD cards with 2GB capacity. it's SD and not SDHC card. I will bring some more SDHC cards and test again. -M ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Boot sanity testing of release candidate kernel
On 25 May 2011 23:23, Deepak Saxena dsax...@linaro.org wrote: On 25 May 2011 03:29, Tixy t...@yxit.co.uk wrote: On Tue, 2011-05-24 at 19:42 -0700, Deepak Saxena wrote: The Kernel Working Group is getting ready to release the first of our new monthly development snapshot in a few days and we would like folks to do some quick sanity boot testing on their boards. Please grab or update the kernel from git://git.linaro.org/kernel/linux-linaro-2.6.38.git, and checkout the linaro-11.05-2.6.38 tag (which happens to be same as master at this moment) and give it a quick spin. Note that this is just the stock Linaro kernel and does not include any binary graphics drivers or other bits provided by Linaro's landing team kernels, so we just need the basic build and boot tested along with some simple testing of devices that can be used w/o extra drivers. Is there anywhere to report results of testing? I think it would be useful for us to know what has and what hasn't been tested. For this release, email is what we'll use and I'll collate all the info into a wiki page and maybe the release notes. - Blocked kworker thread issue manifests [2] This needs a bug opened and assigned to one of the TI engineers in the KWG. Thanks, ~Deepak Boots fine on Samsung's smdkv310 board with dt and non-dt. Tested basic features of sdhci and ethernet drivers. Thanks, Thomas. ___ linaro-kernel mailing list linaro-ker...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: proposal for reorganization of releases.linaro.org hierarchy
On 11 May 26, Fathi Boudra wrote:
Hi,
Here's the following rationale:
1. as a user, I would like to easily find the released Linaro components:
* Linaro Evaluation Build (Android and Ubuntu LEB)
* Tools (linaro-image-tools)
* Working Groups (kernel, u-boot, gcc, gdb, qemu, powerdebug, powertop,
etc...)
2. as a user, I would like to download the release for my ${board} in
one central place.
3. as a release manager on the road to monthly releases, I would like
to adjust the current layout to match the release process.
The current layout has some issues:
- a user should go through several paths to get a rootfs and a hardware pack.
- a user should go through several websites to find Linaro goods
(releases.l.o, launchpad.net)
- newcomers like Android doesn't fit well
- every team has a different release process
+1
The current layout assumes that outsiders know exactly what all our codenames
mean - alip, nano, headless, developer, hwpack, etc. (!)
Hell, even I don't know what the differences are.
To resolve these user stories, we came up with 2 layouts proposal.
Please, see the document attached.
Feebdacks/suggestions on the proposals are welcome!
Note: we planned to start with platform directory only.
The working-groups could come later when we agree on the approach.
Cheers,
Fathi
--
Linaro Release Manager | Platform Project Manager
releases.linaro.org current layout
platform/linaro-n
|-- platform/linaro-n/alip
| |-- platform/linaro-n/alip/beta-2
| `-- platform/linaro-n/alip/latest - beta-2
|-- platform/linaro-n/android
| |-- platform/linaro-n/android/11.04
| | |-- platform/linaro-n/android/11.04/beaglexm
| | `-- platform/linaro-n/android/11.04/panda
| `-- platform/linaro-n/android/latest - 11.04/
|-- platform/linaro-n/developer
| |-- platform/linaro-n/developer/beta-2
| `-- platform/linaro-n/developer/latest - beta-2
|-- platform/linaro-n/hwpacks
| |-- platform/linaro-n/hwpacks/beta-2
| `-- platform/linaro-n/hwpacks/latest - beta-2
|-- platform/linaro-n/nano
| |-- platform/linaro-n/nano/beta-2
| `-- platform/linaro-n/nano/latest - beta-2
`-- platform/linaro-n/ubuntu-desktop
|-- platform/linaro-n/ubuntu-desktop/alpha-3
|-- platform/linaro-n/ubuntu-desktop/beta
|-- platform/linaro-n/ubuntu-desktop/beta-2
`-- platform/linaro-n/ubuntu-desktop/latest - beta-2
releases.linaro.org layout proposal 1
platform
|-- platform/11.05
| |-- platform/11.05/android
| | |-- platform/11.05/android/beaglexm
| | |-- platform/11.05/android/ndk
| | |-- platform/11.05/android/panda
| | |-- platform/11.05/android/sdk
| | `-- platform/11.05/android/toolchain
| |-- platform/11.05/tools
| | |-- platform/11.05/tools/linaro-image-tools
| `-- platform/11.05/ubuntu
| |-- platform/11.05/ubuntu/panda
| | |-- platform/11.05/ubuntu/panda
| | `-- platform/11.05/ubuntu/snowball
| `-- platform/11.05/ubuntu/snowball
[-- platform/11.06
`-- platform/latest - 11.06
working-groups
|-- working-groups/11.05
| |-- working-groups/11.05/graphics
| |-- working-groups/11.05/kernel
| |-- working-groups/11.05/multimedia
| |-- working-groups/11.05/power-management
| `-- working-groups/11.05/toolchain
You're again forcing people to know the difference between platform and
working groups' output. None of the upstreams that we invited to Budapest
knew the difference (or cared for that matter). I suspect the same is true
for some of our consumers.
|-- working-groups/11.06
| |-- working-groups/11.06/graphics
| |-- working-groups/11.06/kernel
| |-- working-groups/11.06/multimedia
| |-- working-groups/11.06/power-management
| |-- working-groups/11.06/toolchain
`-- working-groups/latest - 11.06
releases.linaro.org layout proposal 2
platform
|-- platform/android
| |-- platform/android/11.05
| | |-- platform/android/11.05/beaglexm
| | `-- platform/android/11.05/panda
| |-- platform/android/11.06
| | |-- platform/android/11.06/beaglexm
| | `-- platform/android/11.06/panda
| `-- platform/android/latest - 11.06
|-- tools/linaro-image-tools
||-- tools/linaro-image-tools/0.4.7
||-- tools/linaro-image-tools/0.4.8
|`-- tools/linaro-image-tools/latest - 0.4.8
`-- platform/ubuntu
|-- platform/ubuntu/11.05
| |-- platform/ubuntu/11.06/panda
| `-- platform/ubuntu/11.06/snowball
|-- platform/ubuntu/11.06
| |-- platform/ubuntu/11.06/panda
| `-- platform/ubuntu/11.06/snowball
`-- platform/ubuntu/latest - 11.06
working-groups
|-- working-groups/graphics
| |-- working-groups/graphics/11.05
| |-- working-groups/graphics/11.06
| `-- working-groups/graphics/latest - 11.06
|-- working-groups/kernel
| |-- working-groups/kernel/11.05
| |-- working-groups/kernel/11.06
| `-- working-groups/kernel/latest - 11.06
|--
Re: proposal for reorganization of releases.linaro.org hierarchy
On Thu, May 26, 2011, Alexander Sack wrote: Lets move step by step and focus in this thread on the layout of releases.linaro.org. We can discuss the big download future picture outside of this thread ;). Linaro strives to be transparent and open, but design by committee or by vote suck, and discussing the layout of files on a server with the whole world doesn't make sense if we already agree we want to provide an UI to abstract it this layout away. I agree the current layout isn't the best; what I believe is a more sustainable layout where we wont have to maintain URL redirections over time would be: /$year-$month/$project/ with project being an ouput of a team; either a platform output, or a working output; project could be android, or powerdebug. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Boot sanity testing of release candidate kernel
On Thu, May 26, 2011 at 2:50 PM, G, Manjunath Kondaiah manj...@ti.com wrote: Is your card really 1GB SD Card? Were any of the other cards SDHC? yeah...it's Kingston 1GB card. I have only two cards with me now. I can try with some other cards also. Most probably it's card issue. I have been using 4 and 8GB cards and never saw any problem. BTW, SDHC cards are SD cards with 2GB capacity. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: proposal for reorganization of releases.linaro.org hierarchy
On Thu, May 26, 2011 at 12:40 PM, Loïc Minier loic.min...@linaro.org wrote: On Thu, May 26, 2011, Alexander Sack wrote: Lets move step by step and focus in this thread on the layout of releases.linaro.org. We can discuss the big download future picture outside of this thread ;). Linaro strives to be transparent and open, but design by committee or by vote suck, and discussing the layout of files on a server with the whole world doesn't make sense if we already agree we want to provide an UI to abstract it this layout away. I agree the current layout isn't the best; what I believe is a more sustainable layout where we wont have to maintain URL redirections over time would be: /$year-$month/$project/ with project being an ouput of a team; either a platform output, or a working output; project could be android, or powerdebug. yes, thats the other option we discussed ... see here: http://releases.linaro.org/.11.04/ for an example ... I am fine with either keeping platform and working groups split or merging them as you suggest. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Boot sanity testing of release candidate kernel
On czw, 2011-05-26 at 15:08 +0530, Jassi Brar wrote: BTW, SDHC cards are SD cards with 2GB capacity. There are 4GB SD cards on market - very popular in WinCE based car navigation systems with lack of SDHC support. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: proposal for reorganization of releases.linaro.org hierarchy
On Thu, May 26, 2011 at 12:44 PM, Dave Martin dave.mar...@linaro.org wrote: People do expect releases.linaro.org to be an archive of old releases, as well as a repository of new releases. Can I ask that the URIs of all components of old releases should continue to work (i.e., we either don't move that stuff ever, or we provide aliases)? I've had complaints from people that their old scripts, or their attempts to reproduce old releases were broken by the most recent rearrangement. Yes, this was a one time mistake (oversight) and we reverted that change quickly afterwards. All changes we do here should have proper redirects etc. in place to keep the old URLs working -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Usefulness of GCC's 64bit __sync_* ops on ARM
On Wed, May 25, 2011 at 10:21:43AM -0400, Nicolas Pitre wrote: On Wed, 25 May 2011, Dave Martin wrote: On Tue, May 24, 2011 at 11:45:04PM -0400, Nicolas Pitre wrote: + * typedef int (__kernel_cmpxchg64_t)(const int64_t *oldval, + * const int64_t *newval, + * volatile int64_t *ptr); + * #define __kernel_cmpxchg64 (*(__kernel_cmpxchg64_t *)0x0f60) + * + * Atomically store newval in *ptr if *ptr is equal to oldval for user space. + * Return zero if *ptr was changed or non-zero if no exchange happened. + * The C flag is also set if *ptr was changed to allow for assembly + * optimization in the calling code. * Do not attempt to call this function unless __kernel_helper_version = 5. * Yep. I will queue your other patch prior to this one and make this blurb consistent with the rest. Oh, OK. I hadn't feedback on that yet, so I wasn't sure whether anyone was picking it up. I will repost to alkml, but I was waiting for the merge window to close since this was just a tidyup rather than something urgent. This warning is more important for the new helper than for the existing ones (where really we could omit it without much risk). +kuser_cmpxchg64_fixup: + @ Called from kuser_cmpxchg_fixup. + @ r2 = address of interrupted insn (must be preserved). + @ sp = saved regs. r7 and r8 are clobbered. + @ 1b = first critical insn, 2b = last critical insn. + @ If r2 = 1b and r2 = 2b then saved pc_usr is set to 1b. + mov r7, #0x0fff + sub r7, r7, #(0x0fff - (0x0f60 + (1b - __kuser_cmpxchg64))) + subsr8, r2, r7 + rsbcss r8, r8, #(2b - 1b) + strcs r7, [sp, #S_PC] +#if __LINUX_ARM_ARCH__ 6 + b kuser_cmpxchg32_fixup Can we just have movcs pc,lr here, and put kuser_cmpxchg32_fixup immediately after? This would allow us to skip the branch, and the initial mov r7 in the kuser_cmpxchg32_fixup code. The 'mov r7' is still needed unless the second instruction uses another target register. What I meant is that at the end of the above sequence, r7 = 1b. So we can just fall through in to the 32-bit fixup code and add the appropriate small offset to r7 so that it now points to the corresponding 1b label for __kuser_cmpxchg32, without needing to re-derive the address using mov+sub. It's a pretty minor tweak though. I thought about the possibility of movcs pc, lr, especially since the .text segments are simply concatenated and therefore the branch is effectively branching to the very next instruction. So there could be like a common preamble, then a list of concatenated fixup segments (only two of them now) and finally a postamble which would simply be mov pc, lr. This would all be put contigous at link time. However I'm not sure yet if this is worth optimizing that far since this code is far from being hot, and clarity would also be affected. Also, probably the number of fixups is never going to grow very large. There's a fair amount of duplicated logic from the 32-bit case. Is it worth trying to merge the two? The core logic spans 5 instructions. Only 3 of them are actually the same in both cases i.e. those with no references to 1b or 2b, and they're perfectly interlaced in between the others. Trying to make this into common runtime code would result in even bigger code I'm afraid. This could be made into common source code via a macro though. Fair enough -- a macro might be worth a try _if_ it simplifies things in the source, but I think you're right that merging the actual code probably isn't worth it just to save a few words in the vectors page (which eats up 4K regardless of what we put in it) and a few cycles per fault (which already costs many, many cycles). Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: proposal for reorganization of releases.linaro.org hierarchy
On 26 May 2011 11:56, Alexander Sack a...@linaro.org wrote: On Thu, May 26, 2011 at 12:44 PM, Dave Martin dave.mar...@linaro.org wrote: People do expect releases.linaro.org to be an archive of old releases, as well as a repository of new releases. Can I ask that the URIs of all components of old releases should continue to work (i.e., we either don't move that stuff ever, or we provide aliases)? I've had complaints from people that their old scripts, or their attempts to reproduce old releases were broken by the most recent rearrangement. Yes, this was a one time mistake (oversight) and we reverted that change quickly afterwards. All changes we do here should have proper redirects etc. in place to keep the old URLs working 1. My vote is to leave the layout as it is for what is up (so we don't break anything) 2. I don't care about the layout for future releases, provided I can index it using simple rules. 3. Once I have finished the TestDrive GUI, see if we can use the same principles to create a simple to use web page, that doesn't expose the storage file system. We should be able to query the server with a board type and some data about what release/shapshot you want and be provided with a download page with both the hardware pack and the OS image to download (and probably with a linaro-media-create line as well). I am sure this could be refined so that a page could be prodded by a user or script to return a tar ball of both (gzipped inside). -- James Tunnicliffe ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] SMDKV310: CPU fequency and mmc_pre_ratio modified
Modifies CPU Frequency to 1GHz and removes hard coding of mmc_pre_ratio for MMC Channel2 in FSYS2 register. Signed-off-by: Chander Kashyap chander.kash...@linaro.org --- board/samsung/smdkv310/lowlevel_init.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/board/samsung/smdkv310/lowlevel_init.S b/board/samsung/smdkv310/lowlevel_init.S index 359cff4..04f6579 100644 --- a/board/samsung/smdkv310/lowlevel_init.S +++ b/board/samsung/smdkv310/lowlevel_init.S @@ -170,7 +170,7 @@ system_clock_init: * COREM1_RATIO[8] 0x7 * COREM0_RATIO[4] 0x3 */ - ldr r1, =0x01133730 + ldr r1, =0x0133730 ldr r2, =0x14500@CLK_DIV_CPU0_OFFSET str r1, [r0, r2] @@ -245,7 +245,7 @@ system_clock_init: str r1, [r0, r2] /* MMC[2:3] */ - ldr r1, =0x000f020f /* 800(MPLL) / (15 + 1) */ + ldr r1, =0x000f000f /* 800(MPLL) / (15 + 1) */ ldr r2, =0x0C548@ CLK_DIV_FSYS2 str r1, [r0, r2] -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Boot sanity testing of release candidate kernel
On czw, 2011-05-26 at 16:52 +0530, Jassi Brar wrote: On Thu, May 26, 2011 at 4:24 PM, Marcin Juszkiewicz marcin.juszkiew...@linaro.org wrote: On czw, 2011-05-26 at 15:08 +0530, Jassi Brar wrote: BTW, SDHC cards are SD cards with 2GB capacity. There are 4GB SD cards on market - very popular in WinCE based car navigation systems with lack of SDHC support. IIRC official maximum size of SD was specified to be 2GB Who cares about specifications... ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: proposal for reorganization of releases.linaro.org hierarchy
Hi,
I'd like to add an extra constraint on the design if possible. As
everyone has pointed out we want an index in to this stuff that users
will use, so I think my constraint has a place. It has been complained
about many times, but it's not going to go away without some work on our
part.
Currently we require sysadmin intervention when we add a new
image/hwpack so that they can be synced to snapshots.linaro.org. I would
like to remove this restriction, but one of the issues is that the
hierarchy we have on snapshots.linaro.org is nothing like the one that
is produced by offspring.
We can obviously change offspring, but the current hierarchy doesn't
obey simple rules that we can code in to the tool.
This affects snapshots more than releases. However, releases can be done
with a click from within offspring now, rather than by someone copying
files around. If we want to use that feature the releases should use the
same hierarchy as snapshots.
Thefore my request is that there be a set of simple rules used to place
the results of a build that uses information available to
offspring.linaro.org.
Thanks,
James
On Thu, 26 May 2011 08:54:59 +, Fathi Boudra fathi.bou...@linaro.org
wrote:
Hi,
Here's the following rationale:
1. as a user, I would like to easily find the released Linaro components:
* Linaro Evaluation Build (Android and Ubuntu LEB)
* Tools (linaro-image-tools)
* Working Groups (kernel, u-boot, gcc, gdb, qemu, powerdebug, powertop,
etc...)
2. as a user, I would like to download the release for my ${board} in
one central place.
3. as a release manager on the road to monthly releases, I would like
to adjust the current layout to match the release process.
The current layout has some issues:
- a user should go through several paths to get a rootfs and a hardware pack.
- a user should go through several websites to find Linaro goods
(releases.l.o, launchpad.net)
- newcomers like Android doesn't fit well
- every team has a different release process
To resolve these user stories, we came up with 2 layouts proposal.
Please, see the document attached.
Feebdacks/suggestions on the proposals are welcome!
Note: we planned to start with platform directory only.
The working-groups could come later when we agree on the approach.
Cheers,
Fathi
--
Linaro Release Manager | Platform Project Manager
releases.linaro.org current layout
platform/linaro-n
|-- platform/linaro-n/alip
| |-- platform/linaro-n/alip/beta-2
| `-- platform/linaro-n/alip/latest - beta-2
|-- platform/linaro-n/android
| |-- platform/linaro-n/android/11.04
| | |-- platform/linaro-n/android/11.04/beaglexm
| | `-- platform/linaro-n/android/11.04/panda
| `-- platform/linaro-n/android/latest - 11.04/
|-- platform/linaro-n/developer
| |-- platform/linaro-n/developer/beta-2
| `-- platform/linaro-n/developer/latest - beta-2
|-- platform/linaro-n/hwpacks
| |-- platform/linaro-n/hwpacks/beta-2
| `-- platform/linaro-n/hwpacks/latest - beta-2
|-- platform/linaro-n/nano
| |-- platform/linaro-n/nano/beta-2
| `-- platform/linaro-n/nano/latest - beta-2
`-- platform/linaro-n/ubuntu-desktop
|-- platform/linaro-n/ubuntu-desktop/alpha-3
|-- platform/linaro-n/ubuntu-desktop/beta
|-- platform/linaro-n/ubuntu-desktop/beta-2
`-- platform/linaro-n/ubuntu-desktop/latest - beta-2
releases.linaro.org layout proposal 1
platform
|-- platform/11.05
| |-- platform/11.05/android
| | |-- platform/11.05/android/beaglexm
| | |-- platform/11.05/android/ndk
| | |-- platform/11.05/android/panda
| | |-- platform/11.05/android/sdk
| | `-- platform/11.05/android/toolchain
| |-- platform/11.05/tools
| | |-- platform/11.05/tools/linaro-image-tools
| `-- platform/11.05/ubuntu
| |-- platform/11.05/ubuntu/panda
| | |-- platform/11.05/ubuntu/panda
| | `-- platform/11.05/ubuntu/snowball
| `-- platform/11.05/ubuntu/snowball
[-- platform/11.06
`-- platform/latest - 11.06
working-groups
|-- working-groups/11.05
| |-- working-groups/11.05/graphics
| |-- working-groups/11.05/kernel
| |-- working-groups/11.05/multimedia
| |-- working-groups/11.05/power-management
| `-- working-groups/11.05/toolchain
|-- working-groups/11.06
| |-- working-groups/11.06/graphics
| |-- working-groups/11.06/kernel
| |-- working-groups/11.06/multimedia
| |-- working-groups/11.06/power-management
| |-- working-groups/11.06/toolchain
`-- working-groups/latest - 11.06
releases.linaro.org layout proposal 2
platform
|-- platform/android
| |-- platform/android/11.05
| | |-- platform/android/11.05/beaglexm
| | `-- platform/android/11.05/panda
| |-- platform/android/11.06
| | |-- platform/android/11.06/beaglexm
| | `-- platform/android/11.06/panda
| `-- platform/android/latest - 11.06
|-- tools/linaro-image-tools
||--
Re: Boot sanity testing of release candidate kernel
On Thu, May 26, 2011 at 4:24 PM, Marcin Juszkiewicz marcin.juszkiew...@linaro.org wrote: On czw, 2011-05-26 at 15:08 +0530, Jassi Brar wrote: BTW, SDHC cards are SD cards with 2GB capacity. There are 4GB SD cards on market - very popular in WinCE based car navigation systems with lack of SDHC support. IIRC official maximum size of SD was specified to be 2GB ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Usefulness of GCC's 64bit __sync_* ops on ARM
On Thu, 26 May 2011, Dave Martin wrote: The core logic spans 5 instructions. Only 3 of them are actually the same in both cases i.e. those with no references to 1b or 2b, and they're perfectly interlaced in between the others. Trying to make this into common runtime code would result in even bigger code I'm afraid. This could be made into common source code via a macro though. Fair enough -- a macro might be worth a try _if_ it simplifies things in the source, but I think you're right that merging the actual code probably isn't worth it just to save a few words in the vectors page (which eats up 4K regardless of what we put in it) and a few cycles per fault (which already costs many, many cycles). In the normal cases, there is no additional cycles per fault as the inline check remains unchanged, and it goes like this: @ Make sure our user space atomic helper is restarted @ if it was interrupted in a critical region. Here we @ perform a quick test inline since it should be false @ 99.% of the time. The rest is done out of line. cmp r2, #TASK_SIZE blhskuser_cmpxchg_fixup In most cases the branch is not taken. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Usefulness of GCC's 64bit __sync_* ops on ARM
On Thu, May 26, 2011 at 09:29:51AM -0400, Nicolas Pitre wrote: On Thu, 26 May 2011, Dave Martin wrote: The core logic spans 5 instructions. Only 3 of them are actually the same in both cases i.e. those with no references to 1b or 2b, and they're perfectly interlaced in between the others. Trying to make this into common runtime code would result in even bigger code I'm afraid. This could be made into common source code via a macro though. Fair enough -- a macro might be worth a try _if_ it simplifies things in the source, but I think you're right that merging the actual code probably isn't worth it just to save a few words in the vectors page (which eats up 4K regardless of what we put in it) and a few cycles per fault (which already costs many, many cycles). In the normal cases, there is no additional cycles per fault as the inline check remains unchanged, and it goes like this: @ Make sure our user space atomic helper is restarted @ if it was interrupted in a critical region. Here we @ perform a quick test inline since it should be false @ 99.% of the time. The rest is done out of line. cmp r2, #TASK_SIZE blhskuser_cmpxchg_fixup In most cases the branch is not taken. True! ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Boot sanity testing of release candidate kernel
On 05/24/2011 08:42 PM, Deepak Saxena wrote: Hi all, The Kernel Working Group is getting ready to release the first of our new monthly development snapshot in a few days and we would like folks to do some quick sanity boot testing on their boards. Please grab or update the kernel from git://git.linaro.org/kernel/linux-linaro-2.6.38.git, and checkout the linaro-11.05-2.6.38 tag (which happens to be same as master at this moment) and give it a quick spin. Note that this is just the stock Linaro kernel and does not include any binary graphics drivers or other bits provided by Linaro's landing team kernels, so we just need the basic build and boot tested along with some simple testing of devices that can be used w/o extra drivers. Tested and passed on the ARM Versatile Express Thanks! ~Deepak ___ linaro-kernel mailing list linaro-ker...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-kernel ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro development cycle thoughts
On Tue, 17 May 2011 11:54:18 +0300, Alexandros Frantzis alexandros.frant...@linaro.org wrote: 1. Do other engineers feel this way? I can certainly say that trying to have a release in the same week as the deadline for drafting specs/workitems and creating slides for the public plan reviews has been a strain. At the very least we should ensure that they don't line up in exactly that way again. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH android/toolchain/build] Fix host-libbfd installation problem caused by undefined $(INSTALL)
While executing target install-host-libbfd, the build system complains: make -C libbfd-binutils-2.20.1/bfd install \ bfdlibdir=/tmp/android-toolchain-eabi/lib bfdincludedir=/tmp/android-toolchain-eabi/include \ -m 644 libbfd-binutils-2.20.1/intl/libintl.a \ /tmp/android-toolchain-eabi/lib \ -m 644 libbfd-binutils-2.20.1/libiberty/libiberty.a \ /tmp/android-toolchain-eabi/lib /bin/sh: line 2: -m: command not found The problem was caused by undefined $(INSTALL). The patch attempts to configure `install' program by autotool in order to set $(INSTALL) properly and replace $(INSTALL) -m 644 with multi-platform friendly $(INSTALL_DATA). Code Review: https://review.source.android.com/#change,23179 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[CALL FOR TESTING] Linaro 11.05 Candidate
Hi, In preparation for the release of Linaro 11.05 images on 2011-05-28, a suitable candidate has been selected for testing. The release is expected to be tested heavily and provide the most stable and feature-rich images to date this cycle. If you have supported hardware, as found at: http://releases.linaro.org/platform/linaro-n/hwpacks/latest/ please help our initiative by testing the official Linaro Evaluation Build (LEB): Ubuntu Desktop: http://releases.linaro.org/platform/linaro-n/ubuntu-desktop/latest/ Android: http://releases.linaro.org/platform/linaro-n/android/latest/ and our Developer images: Nano: http://releases.linaro.org/platform/linaro-n/nano/latest/ ALIP: http://releases.linaro.org/platform/linaro-n/alip/latest/ Developer: http://releases.linaro.org/platform/linaro-n/developer/latest/ As a side note, hwpacks that have an -lt- in their name are outputs from the Linaro Landing teams, using some of their components. Make your way to: https://wiki.linaro.org/Cycles/MilestoneBuilds For an explanation of how to test and submit your results to the QA tracker at: http://qatracker.linaro.org For an explanation of how to use the qatracker please see: https://wiki.linaro.org/QA/QATracker Issues == [Bug 788765] linaro-image-tools bootargs broke panda LEB in revision 342 linaro-media-create generates a boot.scr that contains too many arguments to setenv bootargs. To workaround the issue until next l-i-t release, please use: lp:~james-w/linaro-image-tools/fix-panda [Bug XX] Vexpress hardware pack 20110526 failed to build. Please use: hwpack_linaro-vexpress_20110524-0_armel_supported.tar.gz Cheers, Fathi -- Linaro Release Manager | Platform Project Manager ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: ST-E STM Driver Review
Philippe, So from your comments it seems to me there is nothing controversial. Do you have spec for the trace framework you have coded and sent in the patches? Regards, Doug From: Philippe Langlais [mailto:philippe.langl...@linaro.org] Sent: Thursday, May 26, 2011 10:20 AM To: Deao, Douglas; Linus Walleij; Lee Jones Cc: Arvind Chauhan; Michael Hope; linaro-dev@lists.linaro.org; pierre.peif...@stericsson.com; loic.palla...@stericsson.com Subject: Re: ST-E STM Driver Review Hi Doug, I initiate the work to build a hardware trace framework in the kernel, I'm not started the study to have a common userspace API for STM, thanks to this email we can start such a work, but it may be long (next week I'm in vacation till June 7th). See my detailed response for all your interrogations and my thoughts about STE STM implementation below: On 25 May 2011 23:54, Deao, Douglas d-d...@ti.commailto:d-d...@ti.com wrote: Sorry it took a while to get back to you guys. I was visiting customers last week. Most of my comments are just highlighting the differences between TI's STM 1.0 driver and ST-E's STM 1.0 driver, but there are a few questions, observations and suggestions. At the end I included some discussion on TI's meta data and OST header requirements. I have not had a chance to look at your actual implementation yet. Did you do anything to abstract the actual HW transport ports and control registers from the higher level driver functions? Yes, partially I think through IOCTLs debugfs (see our stm.h userspace API) I realize there is a lot here to work through so if you would rather schedule a conference call to talk through the differences I can do that. I would like to start work on a Linaro (Unified) STM Spec next week if I can get feedback from everybody over the next few days. I will be out of the office on 5/27 and 5/31. I hope this email is enough. I am especially interested in details of what you guys have in mind for a common trace framework to receive STM drivers. If by framework you mean well defined APIs that are implemented for specific devices, then I think we are in agreement. What Michael and I have talked about is a common STM user mode experience across all Linaro supported devices, making Linux user mode code 100% portable between our devices. For my point of view, the trace device framework must ease the integration of new hardware trace drivers in the kernel (not only STM MIPI) to present standard hooks in current trace infrastructure, but it can cover a common STM userspace API too. ST-E STM Driver stm-trace.txt review: 1. Software Overview In your Software Overview it states: The end of data packet is marked by a time stamp on latest byte(s) only. I assume that user messages can be made up of any number of bytes, half-words, words or longs (what ever is most efficient) and you simply terminate the last element of the message with a time-stamp - right? Yes, the message buffer can be mis aligned In the TI STM implementation a message can be any number and combination of bytes, half-words, or word transfers terminated with a time-stamp on the last element. In addition to that we also add an OST header to a message. (See below for discussion on OST header). In our case the OST header is added by the external capture probe. 2. Lossless/Lossy modes. TI only supports lossless mode for sw generated messages and is enforced in our hw implementation. Lossy mode is reserved for true hw messages. For STE, hw messages are always lossy, but sw generated messages could be configured in lossless (default) or lossy mode. I did not notice that you documented a way to modify this through the debugfs API or IOCTLS. I have 2 IOCTLs (STM_SET_MODE STM_GET_MODE) and debugfs (masters_modes) interfaces for that. I am kind of thinking that may be ok since this is really a hw configuration choice in your case, but in the TI case the user does not get to make that choice. OK 3. Channel Assignment TI makes the assignment with mknod using the minor number to assign a fixed channel. This allows the user mode application to overload the channel usage for categorizing data (not my idea). I think we see the error of our ways here and will be ok with a dynamic channel allocation. If we are agree with dynamic channel allocation then a common STM userspace API is possible I think and perhaps common STM driver. I am thinking that for each unique pid a channel should be assigned when the device is opened. I would guess you are keeping a channel table around and write() just checks the table for a pid assignment (no time to look at your implementation yet), if none is found the first free channel is used. If you moved this function back to open then you could do the IOCTL STM_GET_CHANNEL_NO anytime, not just after the first write. The reason behind this behavior is for our current STM user lib which open /dev/stm and alloc/free channels
Re: [CALL FOR TESTING] Linaro 11.05 Candidate
For people who don't want to look around for stuff and want to run are super fantastic Android build do: wget http://releases.linaro.org/platform/linaro-n/android/latest/leb-panda/boot.tar.bz2 wget http://releases.linaro.org/platform/linaro-n/android/latest/leb-panda/system.tar.bz2 wget http://releases.linaro.org/platform/linaro-n/android/latest/leb-panda/userdata.tar.bz2 bzr branch lp:~james-w/linaro-image-tools/fix-panda insert sd card and type dmesg ./fix-panda/linaro-android-media-create --mmc /dev/sdc --dev panda --system system.tar.bz2 --userdata userdata.tar.bz2 --boot boot.tar.bz2 This was build from: https://android-build.linaro.org/builds/~linaro-android/leb-panda-11.05-release/ To build from source do: (https://wiki.linaro.org/Platform/Android/GetSource) mkdir LEB-panda cd LEB-panda repo init -u git://git.linaro.org/android/platform/manifests.git -b linaro-android-11.05-release -m LEB-panda.xml repo sync Then (https://wiki.linaro.org/Platform/Android/BuildSource) cd LEB-panda make TARGET_PRODUCT=pandaboard TARGET_TOOLS_PREFIX=prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- To use the super cool gcc 4.5/4.6 preview you need a special branch of android: dev_toolchain_preview_1104. mkdir android cd android repo init -u git://git.linaro.org/android/platform/manifests.git -b dev_toolchain_preview_1104 repo sync and build with cd android make TARGET_PRODUCT=pandaboard TARGET_TOOLS_PREFIX=/opt/android-toolchain-eabi/bin/arm-eabi- -Zach On 26 May 2011 15:23, Fathi Boudra fathi.bou...@linaro.org wrote: Hi, In preparation for the release of Linaro 11.05 images on 2011-05-28, a suitable candidate has been selected for testing. The release is expected to be tested heavily and provide the most stable and feature-rich images to date this cycle. If you have supported hardware, as found at: http://releases.linaro.org/platform/linaro-n/hwpacks/latest/ please help our initiative by testing the official Linaro Evaluation Build (LEB): Ubuntu Desktop: http://releases.linaro.org/platform/linaro-n/ubuntu-desktop/latest/ Android: http://releases.linaro.org/platform/linaro-n/android/latest/ and our Developer images: Nano: http://releases.linaro.org/platform/linaro-n/nano/latest/ ALIP: http://releases.linaro.org/platform/linaro-n/alip/latest/ Developer: http://releases.linaro.org/platform/linaro-n/developer/latest/ As a side note, hwpacks that have an -lt- in their name are outputs from the Linaro Landing teams, using some of their components. Make your way to: https://wiki.linaro.org/Cycles/MilestoneBuilds For an explanation of how to test and submit your results to the QA tracker at: http://qatracker.linaro.org For an explanation of how to use the qatracker please see: https://wiki.linaro.org/QA/QATracker Issues == [Bug 788765] linaro-image-tools bootargs broke panda LEB in revision 342 linaro-media-create generates a boot.scr that contains too many arguments to setenv bootargs. To workaround the issue until next l-i-t release, please use: lp:~james-w/linaro-image-tools/fix-panda [Bug XX] Vexpress hardware pack 20110526 failed to build. Please use: hwpack_linaro-vexpress_20110524-0_armel_supported.tar.gz Cheers, Fathi -- Linaro Release Manager | Platform Project Manager ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [CALL FOR TESTING] Linaro 11.05 Candidate
On Thu, 26 May 2011 20:23:40 +, Fathi Boudra fathi.bou...@linaro.org wrote: Issues == [Bug 788765] linaro-image-tools bootargs broke panda LEB in revision 342 linaro-media-create generates a boot.scr that contains too many arguments to setenv bootargs. To workaround the issue until next l-i-t release, please use: lp:~james-w/linaro-image-tools/fix-panda Any of lp:linaro-image-tools http://launchpad.net/linaro-image-tools/trunk/0.4.8/+download/linaro-image-tools-0.4.8.tar.gz the linaro tools ppa: https://launchpad.net/~linaro-maintainers/+archive/tools Should work for this now. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [CALL FOR TESTING] Linaro 11.05 Candidate
On Thu, May 26, 2011 at 5:23 PM, Fathi Boudra fathi.bou...@linaro.org wrote: Issues == [Bug XX] Vexpress hardware pack 20110526 failed to build. Please use: hwpack_linaro-vexpress_20110524-0_armel_supported.tar.gz This is fixed now with the 1003.4 kernel available at the Linaro Overlay. You can find the hwpack build at: http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/vexpress/20110526/2/images/hwpack/ Cheers -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [CALL FOR TESTING] Linaro 11.05 Candidate
On Thu, 26 May 2011 19:17:55 -0300, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Thu, May 26, 2011 at 5:23 PM, Fathi Boudra fathi.bou...@linaro.org wrote: Issues == [Bug XX] Vexpress hardware pack 20110526 failed to build. Please use: hwpack_linaro-vexpress_20110524-0_armel_supported.tar.gz This is fixed now with the 1003.4 kernel available at the Linaro Overlay. You can find the hwpack build at: http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/vexpress/20110526/2/images/hwpack/ When entering Vexpress testing results at qatracker.linaro.org please ensure you state which hwpack you tested. Ricardo, are you recommending people test this new version as that is what we want to release? Thanks, James P.S. only two results entered in to qatracker.linaro.org so far and we are but hours from release. *You* need to test on the supported hardware you have available if you want to have a quality release. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [CALL FOR TESTING] Linaro 11.05 Candidate
On Thu, May 26, 2011 at 9:09 PM, James Westby james.wes...@canonical.com wrote: On Thu, 26 May 2011 19:17:55 -0300, Ricardo Salveti ricardo.salv...@linaro.org wrote: On Thu, May 26, 2011 at 5:23 PM, Fathi Boudra fathi.bou...@linaro.org wrote: Issues == [Bug XX] Vexpress hardware pack 20110526 failed to build. Please use: hwpack_linaro-vexpress_20110524-0_armel_supported.tar.gz This is fixed now with the 1003.4 kernel available at the Linaro Overlay. You can find the hwpack build at: http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/vexpress/20110526/2/images/hwpack/ When entering Vexpress testing results at qatracker.linaro.org please ensure you state which hwpack you tested. Ricardo, are you recommending people test this new version as that is what we want to release? Yes, please, sorry it wasn't that clear. P.S. only two results entered in to qatracker.linaro.org so far and we are but hours from release. *You* need to test on the supported hardware you have available if you want to have a quality release. Yeah, *PLEASE* find at least some minutes today and tomorrow to test our images with all hardware we're targeting. Thanks, -- Ricardo Salveti de Araujo ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [CALL FOR TESTING] Linaro 11.05 Candidate
On Thu, 2011-05-26 at 16:36 -0500, Zach Pfeffer wrote: For people who don't want to look around for stuff and want to run are super fantastic Android build do: wget http://releases.linaro.org/platform/linaro-n/android/latest/leb-panda/boot.tar.bz2 wget http://releases.linaro.org/platform/linaro-n/android/latest/leb-panda/system.tar.bz2 wget http://releases.linaro.org/platform/linaro-n/android/latest/leb-panda/userdata.tar.bz2 bzr branch lp:~james-w/linaro-image-tools/fix-panda insert sd card and type dmesg ./fix-panda/linaro-android-media-create --mmc /dev/sdc --dev panda --system system.tar.bz2 --userdata userdata.tar.bz2 --boot boot.tar.bz2 I tried to use the command above to burn an SD card for my beaglexm (with the tarballs from .../latest/beaglexm/ and --dev beagle) but it crashed halfway through: mkfs.vfat 3.0.9 (31 Jan 2010) Image Name: boot script Created: Thu May 26 22:21:56 2011 Image Type: ARM Linux Script (uncompressed) Data Size:325 Bytes = 0.32 kB = 0.00 MB Load Address: Entry Point: Contents: Image 0: 317 Bytes = 0.31 kB = 0.00 MB mv: missing destination file operand after `/tmp/tmpBKxAwJ/userdata-disc' Try `mv --help' for more information. Traceback (most recent call last): File /home/salgado/devel/linaro-image-tools/trunk/linaro-android-media-create, line 146, in module populate_partition(DATA_DIR + /data, DATA_DISK, data_partition) File /home/salgado/devel/linaro-image-tools/trunk/linaro_image_tools/media_create/rootfs.py, line 29, in populate_partition move_contents(content_dir, root_disk) File /home/salgado/devel/linaro-image-tools/trunk/linaro_image_tools/media_create/rootfs.py, line 120, in move_contents cmd_runner.run(mv_cmd, as_root=True).wait() File /home/salgado/devel/linaro-image-tools/trunk/linaro_image_tools/cmd_runner.py, line 87, in wait raise SubcommandNonZeroReturnValue(self._my_args, returncode) linaro_image_tools.cmd_runner.SubcommandNonZeroReturnValue: Sub process ['sudo', '-E', 'mv', '/tmp/tmpBKxAwJ/userdata-disc'] returned a non-zero value: 1 -- Guilherme Salgado https://launchpad.net/~salgado signature.asc Description: This is a digitally signed message part ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: proposal for reorganization of releases.linaro.org hierarchy
Hi Michael, On 27 May 2011 02:00, Michael Hope michael.h...@linaro.org wrote: I'm quite happy with hosting our releases on Launchpad. It ties everything related to that product together quite well. I would like some type of landing page though especially when we start doing binary releases and if we do a toolchain stable branch. I don't want to change your current workflow. I'm fine if you continue to release as you do on Launchpad, I'll take care to copy your released code to releases.linaro.org host. Cheers, Fathi -- Linaro Release Manager | Platform Project Manager ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [CALL FOR TESTING] Linaro 11.05 Candidate
On Fri, May 27, 2011 at 3:35 AM, Guilherme Salgado guilherme.salg...@linaro.org wrote: On Thu, 2011-05-26 at 16:36 -0500, Zach Pfeffer wrote: For people who don't want to look around for stuff and want to run are super fantastic Android build do: wget http://releases.linaro.org/platform/linaro-n/android/latest/leb-panda/boot.tar.bz2 wget http://releases.linaro.org/platform/linaro-n/android/latest/leb-panda/system.tar.bz2 wget http://releases.linaro.org/platform/linaro-n/android/latest/leb-panda/userdata.tar.bz2 bzr branch lp:~james-w/linaro-image-tools/fix-panda insert sd card and type dmesg ./fix-panda/linaro-android-media-create --mmc /dev/sdc --dev panda --system system.tar.bz2 --userdata userdata.tar.bz2 --boot boot.tar.bz2 I tried to use the command above to burn an SD card for my beaglexm (with the tarballs from .../latest/beaglexm/ and --dev beagle) but it crashed halfway through: mkfs.vfat 3.0.9 (31 Jan 2010) Image Name: boot script Created: Thu May 26 22:21:56 2011 Image Type: ARM Linux Script (uncompressed) Data Size: 325 Bytes = 0.32 kB = 0.00 MB Load Address: Entry Point: Contents: Image 0: 317 Bytes = 0.31 kB = 0.00 MB mv: missing destination file operand after `/tmp/tmpBKxAwJ/userdata-disc' Try `mv --help' for more information. Traceback (most recent call last): File /home/salgado/devel/linaro-image-tools/trunk/linaro-android-media-create, line 146, in module populate_partition(DATA_DIR + /data, DATA_DISK, data_partition) File /home/salgado/devel/linaro-image-tools/trunk/linaro_image_tools/media_create/rootfs.py, line 29, in populate_partition move_contents(content_dir, root_disk) File /home/salgado/devel/linaro-image-tools/trunk/linaro_image_tools/media_create/rootfs.py, line 120, in move_contents cmd_runner.run(mv_cmd, as_root=True).wait() File /home/salgado/devel/linaro-image-tools/trunk/linaro_image_tools/cmd_runner.py, line 87, in wait raise SubcommandNonZeroReturnValue(self._my_args, returncode) linaro_image_tools.cmd_runner.SubcommandNonZeroReturnValue: Sub process ['sudo', '-E', 'mv', '/tmp/tmpBKxAwJ/userdata-disc'] returned a non-zero value: 1 I saw this with a broken SD card also try udisks --inhibit to see if that's caused by automount for you. -- - Alexander ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
