linaro-omap kernel 1003.6 boot failure
Hi, To perform some systemtap checking, I needed kernel package with debug symbols, which is available in 1003.6 version from http://ddebs.ubuntu.com/pool/universe/l/linux-linaro-omap/ So I did some apt-get update, install linux-image-2.6.37-1003-linaro-omap followed by flash-kernel 2.6.37-1003-linaro-omap. Boot fails at some point (before setting up omap_hsuart in an OK log from 2.6.37-1002) Any known issue or thing I am doing wrong ? U-Boot 2010.12 (Jan 27 2011 - 17:59:04) 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: 0 reading boot.scr 381 bytes read Running bootscript from mmc0 ... ## Executing script at 8200 reading uImage 4000628 bytes read reading uInitrd 4154752 bytes read ## Booting kernel from Legacy Image at 8020 ... Image Name: Ubuntu Kernel Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4000564 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 8160 ... Image Name: Ubuntu Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size:4154688 Bytes = 4 MiB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.37-1003-linaro-omap (buildd@gourd) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-2ubuntu2) ) #6-Ubuntu SMP Fri Feb 11 18:49:17 UTC 2011 (Ubuntu 2.6.37-1003.6-linaro-omap 2.6.37) [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4 Panda board [0.00] bootconsole [earlycon0] enabled [0.00] Reserving 33554432 bytes SDRAM for VRAM [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] OMAP4430 ES2.0 [0.00] SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000 [0.00] FIXME: omap44xx_sram_init not implemented [0.00] PERCPU: Embedded 7 pages/cpu @c0c5b000 s7680 r8192 d12800 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 109410 [0.00] Kernel command line: console=tty0 console=ttyO2,115200n8 root=UUID=dfc5a269-1ede-4174-b52a-02a1297a52f7 rootwait ro earlyprintk fixrtc nocompcache vram=32M omapfb.vram=0:8M mem=463M ip=none [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] allocated 2370560 bytes of page_cgroup [0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [0.00] Memory: 430MB 1MB = 431MB total [0.00] Memory: 421860k/421860k available, 52252k 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 : 0xdd00 - 0xf800 ( 432 MB) [0.00] lowmem : 0xc000 - 0xdcf0 ( 463 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .init : 0xc0008000 - 0xc0053000 ( 300 kB) [0.00] .text : 0xc0053000 - 0xc078a32c (7389 kB) [0.00] .data : 0xc078c000 - 0xc07f04e0 ( 402 kB) [0.00] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] RCU-based detection of stalled CPUs is disabled. [0.00] NR_IRQS:402 [0.00] clockdomain: l3_dma_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: emu_sys_clkdm: OMAP4 wakeup/sleep dependency support: not yet implemented [0.00] clockdomain: emu_sys_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: l4_wkup_clkdm: OMAP4 wakeup/sleep dependency support: not yet implemented [0.00] clockdomain: l4_wkup_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: l3_dss_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: iss_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: l3_d2d_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: l3_1_clkdm: OMAP4 wakeup/sleep dependency support: not yet implemented [0.00] clockdomain: l3_1_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: l3_2_clkdm: OMAP4 wakeup/sleep dependency
[GIT PULL] omap[34] Thumb-2 support for linux-linaro-2.6.38
The following changes since commit 1bae4ce27c9c90344f23c65ea6966c50ffeae2f5: Linux 2.6.38-rc2 (2011-01-21 19:01:34 -0800) are available in the git repository at: git://git.linaro.org/people/dmart/linux-2.6-arm.git dirty/arm/omap-thumb2+merged Dave Martin (9): ARM: omap4: Provide do_wfi() for Thumb-2 ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL ARM: omap3: Remove hand-encoded SMC instructions ARM: omap3: Thumb-2 compatibility for sram34xx.S ARM: omap3: Thumb-2 compatibility for sleep34xx.S ARM: Thumb-2: Symbol manipulation macros for function body copying ARM: Correct WFE() in asm/spinlock.h for Thumb-2 ARM: Add local symbols in relocate_kernel.S to work around gas bugs ARM: omap3: Work around assembler errors in sleep34xx.S Jean Pihet (2): omap: use fncpy to copy the PM code functions to SRAM OMAP: fix fncpy API call Ming Lei (1): arm: fix oops in sched_clock_poll Russell King (3): ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer ARM: bitops: switch set/clear/change bitops to use ldrex/strex ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h arch/arm/include/asm/bitops.h | 60 +- arch/arm/include/asm/fncpy.h| 94 +++ arch/arm/include/asm/spinlock.h | 53 ++--- arch/arm/kernel/armksyms.c | 18 ++--- arch/arm/kernel/relocate_kernel.S | 12 ++- arch/arm/kernel/sched_clock.c |4 +- arch/arm/lib/bitops.h | 46 +++- arch/arm/lib/changebit.S| 10 +-- arch/arm/lib/clearbit.S | 11 +-- arch/arm/lib/setbit.S | 11 +-- arch/arm/lib/testchangebit.S|9 +-- arch/arm/lib/testclearbit.S |9 +-- arch/arm/lib/testsetbit.S |9 +-- arch/arm/mach-omap1/pm.h|6 +- arch/arm/mach-omap1/sleep.S |3 + arch/arm/mach-omap1/sram.S |1 + arch/arm/mach-omap2/include/mach/omap4-common.h |4 + arch/arm/mach-omap2/omap-headsmp.S |2 +- arch/arm/mach-omap2/omap44xx-smc.S |8 +- arch/arm/mach-omap2/pm.h|2 +- arch/arm/mach-omap2/sleep24xx.S |2 + arch/arm/mach-omap2/sleep34xx.S | 71 ++ arch/arm/mach-omap2/sram242x.S |3 + arch/arm/mach-omap2/sram243x.S |3 + arch/arm/mach-omap2/sram34xx.S | 37 +++-- arch/arm/plat-omap/include/plat/sram.h | 14 +++- arch/arm/plat-omap/sram.c | 14 ++- 27 files changed, 350 insertions(+), 166 deletions(-) create mode 100644 arch/arm/include/asm/fncpy.h ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Emdebian sprint - flash-kernel discussion
Hi there flash-kernel is this place where we add support for a lot of weird boards of various architectures. flash-kernel because it used to just write a kernel to Flash memory, but that's not always true anymore. Because it's integrated in d-i and with initramfs-tools / linux packages, it is the easiest way to add support for one new board. But flash-kernel isn't in the happiest state right now, as new boards were added by copy-pasting the installation logic of other boards over and over. Also, Ubuntu added more and more boards and features to its flash-kernel package, and the delta is really big now (I will take part of the blame for allowing this to happen). In the light of this situation, and because I think Debian and derivatives will support more and more boards via flash-kernel in the future (for instance modern ARM boards in the armel/armhf ports), I'm interested in improving flash-kernel's code, architecture and scalability (in fact, I started working on it [1]). I'm at the Emdebian sprint in Cambridge this week and I wanted to pursue work on flash-kernel this week, but a lot of people here would like to have a discussion on this work, and other people seem to be interested in solving the same problems in flash-kernel. So in the interest of avoiding work duplication and in the hope to come up with a good roadmap and target architecture for flash-kernel, I'll be hosting a discussion on flash-kernel development tomorrow morning at 11am UK time. (Sorry for the late notice!) If you're interested in flash-kernel, if you have ideas, patches, etc. consider dialing in! Of course, email works too. I'll work on a wiki page summarizing tomorrow's discussion and the plans around flash-kernel. Dial-in details: Access code:52386 86884# UK Local+44 207 630 2405 UK Freephone0800 026 0166 US Local+1 781 761 9450 US Toll Free1 866 352 2709 Brazil 0800 881 0038 Canada 1 866 352 2710 Finland 800 523 103 France 0 805 980 044 Germany 800 589 0993 New Zealand 800 452 290 Taiwan 0800 265 855 China (North) 10 800 152 1873 China (South) 10 800 852 1873 India 000 800 100 7944 Poland 800 331 1398 Anybody is welcome to dial-in. I'd welcome if you would notify me of your presence so that we can expect you on the call. We'll be using #emdebian as back-channel. Cheers, [1] branch at http://git.debian.org/?p=users/lool/d-i/flash-kernel.git * adds a testsuite * consolidates code into functions * moves board support data into a database (currently inline for convenience of testing, but will be split out in its own file) -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/3] arm/dt: add very basic dts file for babbage board
Hi Grant,
Thanks for the explanation in details.
One more minor doubt below ...
On Mon, Feb 21, 2011 at 10:10:24AM -0700, Grant Likely wrote:
On Mon, Feb 21, 2011 at 2:46 AM, Shawn Guo shawn@linaro.org wrote:
[...]
+ };
+ };
+
+ clocks {
+ #address-cells = 1;
+ #size-cells = 0;
+
Can we use hex value here to keep the consistency throughout the file?
For #address-cells and #size-cells use decimal integers.
If I run 'dtc -I dts -O dts -o babbage-dtc.dts babbage.dts', I see
babbage-dtc.dts have these two decimal values written into the hex.
--
Regards,
Shawn
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro-omap kernel 1003.6 boot failure
On Tue, Feb 22, 2011 at 7:09 AM, Frederic Turgis frederic.tur...@linaro.org wrote: Hi, To perform some systemtap checking, I needed kernel package with debug symbols, which is available in 1003.6 version from http://ddebs.ubuntu.com/pool/universe/l/linux-linaro-omap/ So I did some apt-get update, install linux-image-2.6.37-1003-linaro-omap followed by flash-kernel 2.6.37-1003-linaro-omap. Boot fails at some point (before setting up omap_hsuart in an OK log from 2.6.37-1002) Any known issue or thing I am doing wrong ? Hi Fred, this is a known bug. You can track the progress of it here: https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/720055 Thanks, Paul Larson ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Emdebian sprint - flash-kernel discussion
On Tue, Feb 22, 2011 at 3:59 PM, Loïc Minier loic.min...@linaro.org wrote: [1] branch at http://git.debian.org/?p=users/lool/d-i/flash-kernel.git * adds a testsuite * consolidates code into functions * moves board support data into a database (currently inline for convenience of testing, but will be split out in its own file) Does it make sense to move this 'database' out to /etc/boards/ ? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
linaro-omap kernel 1003.6 boot failure
Hi, (writing from my work address as frederic.tur...@linaro.org lost password is still not reset ;-) ) To perform some systemtap checking, I need kernel package with debug symbols, which is available in 1003.6 version from http://ddebs.ubuntu.com/pool/universe/l/linux-linaro-omap/ So I did some apt-get update, install linux-image-2.6.37-1003-linaro-omap followed by flash-kernel 2.6.37-1003-linaro-omap. Boot fails at some point (before setting up omap_hsuart in an OK log from 2.6.37-1002) Any known issue or thing I am doing wrong ? U-Boot 2010.12 (Jan 27 2011 - 17:59:04) 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: 0 reading boot.scr 381 bytes read Running bootscript from mmc0 ... ## Executing script at 8200 reading uImage 4000628 bytes read reading uInitrd 4154752 bytes read ## Booting kernel from Legacy Image at 8020 ... Image Name: Ubuntu Kernel Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4000564 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 8160 ... Image Name: Ubuntu Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size:4154688 Bytes = 4 MiB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.37-1003-linaro-omap (buildd@gourd) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-2ubuntu2) ) #6-Ubuntu SMP Fri Feb 11 18:49:17 UTC 2011 (Ubuntu 2.6.37-1003.6-linaro-omap 2.6.37) [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4 Panda board [0.00] bootconsole [earlycon0] enabled [0.00] Reserving 33554432 bytes SDRAM for VRAM [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] OMAP4430 ES2.0 [0.00] SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000 [0.00] FIXME: omap44xx_sram_init not implemented [0.00] PERCPU: Embedded 7 pages/cpu @c0c5b000 s7680 r8192 d12800 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 109410 [0.00] Kernel command line: console=tty0 console=ttyO2,115200n8 root=UUID=dfc5a269-1ede-4174-b52a-02a1297a52f7 rootwait ro earlyprintk fixrtc nocompcache vram=32M omapfb.vram=0:8M mem=463M ip=none [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] allocated 2370560 bytes of page_cgroup [0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [0.00] Memory: 430MB 1MB = 431MB total [0.00] Memory: 421860k/421860k available, 52252k 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 : 0xdd00 - 0xf800 ( 432 MB) [0.00] lowmem : 0xc000 - 0xdcf0 ( 463 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .init : 0xc0008000 - 0xc0053000 ( 300 kB) [0.00] .text : 0xc0053000 - 0xc078a32c (7389 kB) [0.00] .data : 0xc078c000 - 0xc07f04e0 ( 402 kB) [0.00] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] RCU-based detection of stalled CPUs is disabled. [0.00] NR_IRQS:402 [0.00] clockdomain: l3_dma_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: emu_sys_clkdm: OMAP4 wakeup/sleep dependency support: not yet implemented [0.00] clockdomain: emu_sys_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: l4_wkup_clkdm: OMAP4 wakeup/sleep dependency support: not yet implemented [0.00] clockdomain: l4_wkup_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: l3_dss_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: iss_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: l3_d2d_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: l3_1_clkdm: OMAP4 wakeup/sleep dependency support: not yet implemented [0.00] clockdomain:
Re: cc'ing patc...@linaro.org
On Tue, Feb 22, 2011 at 05:02:41PM +, Dave Martin wrote: Do we need a policy on whether or not to use Bcc here? One argument for using Bcc is that it avoids replies from subscribers to the destination mailing lists from also being CC'd to patc...@linaro.org. Can your analysis cope with patc...@linaro.org receiving a whole thread, or do we need to be careful about this? Use CC, not BCC. There is no issue with people replying to patc...@linaro.org; we will use the headers to ensure we're not double-counting, and having the whole thread actually helps us hint if the patches were upstreamed or not. -- Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: cc'ing patc...@linaro.org
On Tue, Feb 22, 2011 at 5:15 PM, Christian Robottom Reis k...@linaro.org wrote: On Tue, Feb 22, 2011 at 05:02:41PM +, Dave Martin wrote: Do we need a policy on whether or not to use Bcc here? One argument for using Bcc is that it avoids replies from subscribers to the destination mailing lists from also being CC'd to patc...@linaro.org. Can your analysis cope with patc...@linaro.org receiving a whole thread, or do we need to be careful about this? Use CC, not BCC. There is no issue with people replying to patc...@linaro.org; we will use the headers to ensure we're not double-counting, and having the whole thread actually helps us hint if the patches were upstreamed or not. OK-- if you're confident that the analysis won't break, and that no bounces will come from patches@linaro, then I agree -- there's no other reason for the CC to be secret Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linaro-omap kernel 1003.6 boot failure
Is this the same as : https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/720055 Regards, Tom On Mon, Feb 21, 2011 at 11:49 AM, Turgis, Frederic f-tur...@ti.com wrote: Hi, (writing from my work address as frederic.tur...@linaro.org lost password is still not reset ;-) ) To perform some systemtap checking, I need kernel package with debug symbols, which is available in 1003.6 version from http://ddebs.ubuntu.com/pool/universe/l/linux-linaro-omap/ So I did some apt-get update, install linux-image-2.6.37-1003-linaro-omap followed by flash-kernel 2.6.37-1003-linaro-omap. Boot fails at some point (before setting up omap_hsuart in an OK log from 2.6.37-1002) Any known issue or thing I am doing wrong ? U-Boot 2010.12 (Jan 27 2011 - 17:59:04) 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: 0 reading boot.scr 381 bytes read Running bootscript from mmc0 ... ## Executing script at 8200 reading uImage 4000628 bytes read reading uInitrd 4154752 bytes read ## Booting kernel from Legacy Image at 8020 ... Image Name: Ubuntu Kernel Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4000564 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 8160 ... Image Name: Ubuntu Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 4154688 Bytes = 4 MiB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [ 0.00] Initializing cgroup subsys cpuset [ 0.00] Initializing cgroup subsys cpu [ 0.00] Linux version 2.6.37-1003-linaro-omap (buildd@gourd) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-2ubuntu2) ) #6-Ubuntu SMP Fri Feb 11 18:49:17 UTC 2011 (Ubuntu 2.6.37-1003.6-linaro-omap 2.6.37) [ 0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7f [ 0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.00] Machine: OMAP4 Panda board [ 0.00] bootconsole [earlycon0] enabled [ 0.00] Reserving 33554432 bytes SDRAM for VRAM [ 0.00] Memory policy: ECC disabled, Data cache writealloc [ 0.00] OMAP4430 ES2.0 [ 0.00] SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000 [ 0.00] FIXME: omap44xx_sram_init not implemented [ 0.00] PERCPU: Embedded 7 pages/cpu @c0c5b000 s7680 r8192 d12800 u32768 [ 0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 109410 [ 0.00] Kernel command line: console=tty0 console=ttyO2,115200n8 root=UUID=dfc5a269-1ede-4174-b52a-02a1297a52f7 rootwait ro earlyprintk fixrtc nocompcache vram=32M omapfb.vram=0:8M mem=463M ip=none [ 0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [ 0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.00] allocated 2370560 bytes of page_cgroup [ 0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [ 0.00] Memory: 430MB 1MB = 431MB total [ 0.00] Memory: 421860k/421860k available, 52252k 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 : 0xdd00 - 0xf800 ( 432 MB) [ 0.00] lowmem : 0xc000 - 0xdcf0 ( 463 MB) [ 0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [ 0.00] .init : 0xc0008000 - 0xc0053000 ( 300 kB) [ 0.00] .text : 0xc0053000 - 0xc078a32c (7389 kB) [ 0.00] .data : 0xc078c000 - 0xc07f04e0 ( 402 kB) [ 0.00] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [ 0.00] Hierarchical RCU implementation. [ 0.00] RCU-based detection of stalled CPUs is disabled. [ 0.00] NR_IRQS:402 [ 0.00] clockdomain: l3_dma_clkdm: clkdm_clear_all_wkdeps: not yet implemented [ 0.00] clockdomain: emu_sys_clkdm: OMAP4 wakeup/sleep dependency support: not yet implemented [ 0.00] clockdomain: emu_sys_clkdm: clkdm_clear_all_wkdeps: not yet implemented [ 0.00] clockdomain: l4_wkup_clkdm: OMAP4 wakeup/sleep dependency support: not yet implemented [ 0.00] clockdomain: l4_wkup_clkdm: clkdm_clear_all_wkdeps: not yet implemented [ 0.00] clockdomain: l3_dss_clkdm: clkdm_clear_all_wkdeps: not yet implemented [ 0.00] clockdomain:
Re: cc'ing patc...@linaro.org
On Tue, Feb 22, 2011, Dave Martin wrote: Do we need a policy on whether or not to use Bcc here? One argument for using Bcc is that it avoids replies from subscribers to the destination mailing lists from also being CC'd to patc...@linaro.org. Can your analysis cope with patc...@linaro.org receiving a whole thread, or do we need to be careful about this? The tool will likely have to cope no matter what, but I would think it's best to use Bcc: just to keep most issues away. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: cc'ing patc...@linaro.org
I've been using the sendemail.cc config as well, but unfortunately it is not used by stgit. If you use stgit to send patches you'll have to copy /usr/share/stgit/templates/patchmail.tmpl to ~/.stgit and add a 'CC: patc...@linaro.org' line to it. I guess we should add these two tips to one of the pages under https://wiki.linaro.org/Mentoring/Git/. Any suggestions? Cheers, On Tue, 2011-02-22 at 18:38 +0200, Amit Kucheria wrote: Hi, We're required to cc patc...@linaro.org for all patches that we send upstream. bzr/launchpad users are already covered or will be shortly. For those using git-send-email to send patches (and you really should be), it might make sense to use the following command so you don't forget $ git config --global --add sendemail.bcc patc...@linaro.org Check $HOME/.gitconfig to make sure you see bcc = patc...@linaro.org under the [sendemail] section. WARNING - this will bcc patc...@linaro.org on all patches from that machine sent using git-send-email. If you want more control, and your linaro work happens in a single git tree, you could do the following: $ cd your linaro git tree $ git config --add sendemail.bcc patc...@linaro.org Check your linaro git tree/.git/config for the bcc entry as above. Now patches send from that tree will be bcc'ed to patches@linaro. /Amit p.s. There is also a sendemail.cc instead of sendemail.bcc in case you want to use that. -- 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: cc'ing patc...@linaro.org
On Tue, 2011-02-22 at 15:59 -0300, Guilherme Salgado wrote: I've been using the sendemail.cc config as well, but unfortunately it is not used by stgit. If you use stgit to send patches you'll have to copy /usr/share/stgit/templates/patchmail.tmpl to ~/.stgit and add a 'CC: patc...@linaro.org' line to it. Actually, a custom patchmail.tmpl has to be under ~/.stgit/templates and not ~/.stgit. I guess we should add these two tips to one of the pages under https://wiki.linaro.org/Mentoring/Git/. Any suggestions? Cheers, On Tue, 2011-02-22 at 18:38 +0200, Amit Kucheria wrote: Hi, We're required to cc patc...@linaro.org for all patches that we send upstream. bzr/launchpad users are already covered or will be shortly. For those using git-send-email to send patches (and you really should be), it might make sense to use the following command so you don't forget $ git config --global --add sendemail.bcc patc...@linaro.org Check $HOME/.gitconfig to make sure you see bcc = patc...@linaro.org under the [sendemail] section. WARNING - this will bcc patc...@linaro.org on all patches from that machine sent using git-send-email. If you want more control, and your linaro work happens in a single git tree, you could do the following: $ cd your linaro git tree $ git config --add sendemail.bcc patc...@linaro.org Check your linaro git tree/.git/config for the bcc entry as above. Now patches send from that tree will be bcc'ed to patches@linaro. /Amit p.s. There is also a sendemail.cc instead of sendemail.bcc in case you want to use that. -- 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: cc'ing patc...@linaro.org
On Tue, Feb 22, 2011 at 06:58:28PM +, Dave Martin wrote: OK, we have a tie ;) Who wins? On Tue, Feb 22, 2011 at 5:15 PM, Christian Robottom Reis k...@linaro.org wrote: On Tue, Feb 22, 2011 at 05:02:41PM +, Dave Martin wrote: [...] Use CC, not BCC. [...] ME! :) -- Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: cc'ing patc...@linaro.org
On 02/22/2011 10:59 AM, Guilherme Salgado wrote: I've been using the sendemail.cc config as well, but unfortunately it is not used by stgit. If you use stgit to send patches you'll have to copy /usr/share/stgit/templates/patchmail.tmpl to ~/.stgit and add a 'CC: patc...@linaro.org' line to it. I guess we should add these two tips to one of the pages under https://wiki.linaro.org/Mentoring/Git/. Any suggestions? We have a link: https://wiki.linaro.org/Mentoring/Git/GitSendEmail I was going to update it with CC/BCC info once its decided which one is correct. I suppose we can also add your StGit information there as well. Ironically, as much as I promote the usage of StGit, I've always used git-send-email instead :) -andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: cc'ing patc...@linaro.org
On Tue, 2011-02-22 at 16:41 -0300, Christian Robottom Reis wrote: On Tue, Feb 22, 2011 at 06:58:28PM +, Dave Martin wrote: OK, we have a tie ;) Who wins? On Tue, Feb 22, 2011 at 5:15 PM, Christian Robottom Reis k...@linaro.org wrote: On Tue, Feb 22, 2011 at 05:02:41PM +, Dave Martin wrote: [...] Use CC, not BCC. [...] ME! :) Yea. Since I still send out patches from both my employer and linaro address, I can't utilize fixed git config values. I already put the effort in to make sure my linaro work has my linaro.org address as the author on a patch by patch basis. And similarly I can add a CC: line to the patch commit log to make sure patc...@linaro.org gets the mail. But BCC isn't easy to do on a patch-by-patch basis. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL] omap[34] Thumb-2 support for linux-linaro-2.6.38
On Tue, 22 Feb 2011, Dave Martin wrote: The following changes since commit 1bae4ce27c9c90344f23c65ea6966c50ffeae2f5: Linux 2.6.38-rc2 (2011-01-21 19:01:34 -0800) are available in the git repository at: git://git.linaro.org/people/dmart/linux-2.6-arm.git dirty/arm/omap-thumb2+merged Dave Martin (9): ARM: omap4: Provide do_wfi() for Thumb-2 ARM: omap4: Convert END() to ENDPROC() for correct linkage with CONFIG_THUMB2_KERNEL ARM: omap3: Remove hand-encoded SMC instructions ARM: omap3: Thumb-2 compatibility for sram34xx.S ARM: omap3: Thumb-2 compatibility for sleep34xx.S ARM: Thumb-2: Symbol manipulation macros for function body copying ARM: Correct WFE() in asm/spinlock.h for Thumb-2 I have that one from mainline already. ARM: Add local symbols in relocate_kernel.S to work around gas bugs ARM: omap3: Work around assembler errors in sleep34xx.S Jean Pihet (2): omap: use fncpy to copy the PM code functions to SRAM OMAP: fix fncpy API call Ming Lei (1): arm: fix oops in sched_clock_poll This is the wrong fix. A better fix exists in mainline and linaro-2.6.38 now. Russell King (3): ARM: bitops: ensure set/clear/change bitops take a word-aligned pointer ARM: bitops: switch set/clear/change bitops to use ldrex/strex ARM: v6k: remove CPU_32v6K dependencies in asm/spinlock.h Got those from RMK's tree too. In general I prefer keeping original commit IDs when possible. May I ask you to rebase on top of the latest linaro-2.6.38 (which acquired a bunch of patches today) so to filter out the unneeded patches please? You could include the module signature patch as well. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Emdebian sprint - flash-kernel discussion
On Tue, 22 Feb 2011 14:59:05 +0100, Loïc Minier loic.min...@linaro.org wrote: [1] branch at http://git.debian.org/?p=users/lool/d-i/flash-kernel.git * adds a testsuite * consolidates code into functions * moves board support data into a database (currently inline for convenience of testing, but will be split out in its own file) I ask mostly from a position of ignorance, but is the information in this database related to the information linaro-media-create keeps about each board? If so, could it be shared somehow? Cheers, mwh ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.38 kernel is now open
On 22 February 2011 05:40, Nicolas Pitre nicolas.pi...@linaro.org wrote: But as you should know already, the feature freeze is due this Thursday February 24th. So now is the time to consider the linaro-2.6.38 tree, put on top all the patches you want to see in the upcoming Linaro release, and ask me to merge them in. If you need some subsystem tree such as MMC to be included as well then now is the time to say so as well. I have some work ongoing in MMC but it will not be ready for this cycle. Hopefully, if I manage to get more hardware to run test on I can have patches going upstream before the end of this cycle and hit 2.6.30. Per __ 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: cc'ing patc...@linaro.org
On Tue, Feb 22, 2011, john stultz wrote: Yea. Since I still send out patches from both my employer and linaro address, I can't utilize fixed git config values. I already put the effort in to make sure my linaro work has my linaro.org address as the author on a patch by patch basis. And similarly I can add a CC: line to the patch commit log to make sure patc...@linaro.org gets the mail. But BCC isn't easy to do on a patch-by-patch basis. That's fair enough; could you explain how you're doing this patch by patch? I personally set author via the EMAIL env var and I have aliases like: linaro='EMAIL=loic.min...@linaro.org' debian='EMAIL=l...@debian.org' etc. and then I run: linaro git commit -av I wonder how you set Cc: though -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Emdebian sprint - flash-kernel discussion
On Wed, Feb 23, 2011, Michael Hudson-Doyle wrote: I ask mostly from a position of ignorance, but is the information in this database related to the information linaro-media-create keeps about each board? If so, could it be shared somehow? It's completely related and I envisioned we could share it some time ago: http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg00254.html even before linaro-image-tools existed ;-) But thanks for bringing this up, it's a good thing to put on the goals for the rework: that the data be usage-agnostic and self-contained as to allow reuse in other places. -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: cc'ing patc...@linaro.org
On Tue, 2011-02-22 at 22:18 +0100, Loïc Minier wrote: On Tue, Feb 22, 2011, john stultz wrote: Yea. Since I still send out patches from both my employer and linaro address, I can't utilize fixed git config values. I already put the effort in to make sure my linaro work has my linaro.org address as the author on a patch by patch basis. And similarly I can add a CC: line to the patch commit log to make sure patc...@linaro.org gets the mail. But BCC isn't easy to do on a patch-by-patch basis. That's fair enough; could you explain how you're doing this patch by patch? I personally set author via the EMAIL env var and I have aliases like: linaro='EMAIL=loic.min...@linaro.org' debian='EMAIL=l...@debian.org' etc. and then I run: linaro git commit -av I wonder how you set Cc: though Add to the commit log: CC: Loïc Minier loic.min...@linaro.org CC: patc...@linaro.org And git-send-email will add those entries to the outgoing mail. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: cc'ing patc...@linaro.org
On Tue, Feb 22, 2011, john stultz wrote: Add to the commit log: CC: Loïc Minier loic.min...@linaro.org CC: patc...@linaro.org And git-send-email will add those entries to the outgoing mail. Ah, so it's in the commit forever; I thought you were adding that at send-email time; ok, thanks! -- Loïc Minier ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/2] Add virtual battery driver
From 7784102e184c134eaa11b5986f31c892748f1604 Mon Sep 17 00:00:00 2001
From: Masashi YOKOTA yok...@pylone.jp
Date: Sat, 19 Feb 2011 02:40:56 +0900
Subject: [PATCH 1/2] Add virtual battery driver
This patch adds virtual battery driver.
This is based on
git://git.linaro.org/people/jstultz/linux.git dev/linaro.android
Signed-off-by: Akihiro MAEDA sola.198...@gmail.com
---
drivers/power/Kconfig |5 +
drivers/power/Makefile |1 +
drivers/power/virtual_battery.c | 349 +++
3 files changed, 355 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/virtual_battery.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 60d83d9..7258bc9 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -185,4 +185,9 @@ config CHARGER_TWL4030
help
Say Y here to enable support for TWL4030 Battery Charge Interface.
+config BATTERY_VIRTUAL
+ tristate Virtual Battery Driver
+ help
+ Say Y to include support for Virtual Battery.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index c75772e..71f8b36 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_BATTERY_JZ4740) += jz4740-battery.o
obj-$(CONFIG_BATTERY_INTEL_MID)+= intel_mid_battery.o
obj-$(CONFIG_CHARGER_ISP1704) += isp1704_charger.o
obj-$(CONFIG_CHARGER_TWL4030) += twl4030_charger.o
+obj-$(CONFIG_BATTERY_VIRTUAL) += virtual_battery.o
diff --git a/drivers/power/virtual_battery.c b/drivers/power/virtual_battery.c
new file mode 100644
index 000..9e455ad
--- /dev/null
+++ b/drivers/power/virtual_battery.c
@@ -0,0 +1,349 @@
+/*
+ * drivers/power/virtual_battery.c
+ *
+ * Virtual battery driver
+ *
+ * Copyright (C) 2008 Pylone, Inc.
+ * Author: Masashi YOKOTA yok...@pylone.jp
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/kernel.h
+#include linux/types.h
+#include linux/err.h
+#include linux/string.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/power_supply.h
+
+
+/* module parameters */
+static int ac_status= 1; /* online */
+static int battery_status = POWER_SUPPLY_STATUS_CHARGING;
+static int battery_health = POWER_SUPPLY_HEALTH_GOOD;
+static int battery_present = 1; /* true */
+static int battery_technology = POWER_SUPPLY_TECHNOLOGY_LION;
+static int battery_capacity = 50;
+
+
+static struct platform_device *bat_pdev;
+
+static enum power_supply_property virtual_ac_props[] = {
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+static enum power_supply_property virtual_battery_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_HEALTH,
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_TECHNOLOGY,
+ POWER_SUPPLY_PROP_CAPACITY,
+};
+
+static int virtual_ac_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ int ret = 0;
+
+ dev_dbg(bat_pdev-dev, %s: psp=%d\n, __func__, psp);
+ switch (psp) {
+ case POWER_SUPPLY_PROP_ONLINE:
+ val-intval = ac_status;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ return ret;
+}
+
+static int virtual_battery_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ int ret = 0;
+
+ dev_dbg(bat_pdev-dev, %s: psp=%d\n, __func__, psp);
+ switch (psp) {
+ case POWER_SUPPLY_PROP_STATUS:
+ val-intval = battery_status;
+ break;
+ case POWER_SUPPLY_PROP_HEALTH:
+ val-intval = battery_health;
+ break;
+ case POWER_SUPPLY_PROP_PRESENT:
+ val-intval = battery_present;
+ break;
+ case POWER_SUPPLY_PROP_TECHNOLOGY:
+ val-intval = battery_technology;
+ break;
+ case POWER_SUPPLY_PROP_CAPACITY:
+ val-intval = battery_capacity;
+ break; default: ret = -EINVAL;
+ break;
+ }
+
+ return ret;
+}
+
+static struct power_supply power_supply_ac = {
+ .properties = virtual_ac_props,
+ .num_properties = ARRAY_SIZE(virtual_ac_props),
+ .get_property = virtual_ac_get_property,
+
[PATCH 2/2] virtual battery driver changed for linux kernel 2.6.37 or later
From 8eab2223b35024e56fd8868626b2fc1958eada47 Mon Sep 17 00:00:00 2001
From: Akihiro MAEDA sola.198...@gmail.com
Date: Sat, 19 Feb 2011 02:44:31 +0900
Subject: [PATCH 2/2] virtual battery driver changed for linux kernel
2.6.37 or later
This patch adds virtual battery driver.
This is based on
git://git.linaro.org/people/jstultz/linux.git dev/linaro.android
Signed-off-by: Akihiro MAEDA sola.198...@gmail.com
---
drivers/power/virtual_battery.c | 53 ++
1 files changed, 42 insertions(+), 11 deletions(-)
diff --git a/drivers/power/virtual_battery.c b/drivers/power/virtual_battery.c
index 9e455ad..e4fa9e5 100644
--- a/drivers/power/virtual_battery.c
+++ b/drivers/power/virtual_battery.c
@@ -5,6 +5,7 @@
*
* Copyright (C) 2008 Pylone, Inc.
* Author: Masashi YOKOTA yok...@pylone.jp
+ * Modified by: Akihiro MAEDA sola.198...@gmail.com
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
@@ -190,7 +191,7 @@ static const char * map_get_key(struct
battery_property_map * map, int value, co
return def_key;
}
-static int param_set_ac_status(const char *key, struct kernel_param *kp)
+static int param_set_ac_status(const char *key, const struct kernel_param *kp)
{
dev_dbg(bat_pdev-dev, %s: name=%s, key=%s\n, __func__, kp-name,
key);
ac_status = map_get_value( map_ac_online, key, ac_status);
@@ -198,14 +199,14 @@ static int param_set_ac_status(const char *key,
struct kernel_param *kp)
return 0;
}
-static int param_get_ac_status(char *buffer, struct kernel_param *kp)
+static int param_get_ac_status(char *buffer, const struct kernel_param *kp)
{
dev_dbg(bat_pdev-dev, %s: name=%s\n, __func__, kp-name);
strcpy(buffer, map_get_key( map_ac_online, ac_status, unknown));
return strlen(buffer);
}
-static int param_set_battery_status(const char *key, struct kernel_param *kp)
+static int param_set_battery_status(const char *key, const struct
kernel_param *kp)
{
dev_dbg(bat_pdev-dev, %s: name=%s, key=%s.\n, __func__, kp-name,
key);
battery_status = map_get_value( map_status, key, battery_status);
@@ -213,14 +214,14 @@ static int param_set_battery_status(const char
*key, struct kernel_param *kp)
return 0;
}
-static int param_get_battery_status(char *buffer, struct kernel_param *kp)
+static int param_get_battery_status(char *buffer, const struct
kernel_param *kp)
{
dev_dbg(bat_pdev-dev, %s: name=%s\n, __func__, kp-name);
strcpy(buffer, map_get_key( map_status, battery_status, unknown));
return strlen(buffer);
}
-static int param_set_battery_health(const char *key, struct kernel_param *kp)
+static int param_set_battery_health(const char *key, const struct
kernel_param *kp)
{
dev_dbg(bat_pdev-dev, %s: name=%s, key=%s\n, __func__, kp-name,
key);
battery_health = map_get_value( map_health, key, battery_health);
@@ -228,14 +229,14 @@ static int param_set_battery_health(const char
*key, struct kernel_param *kp)
return 0;
}
-static int param_get_battery_health(char *buffer, struct kernel_param *kp)
+static int param_get_battery_health(char *buffer, const struct
kernel_param *kp)
{
dev_dbg(bat_pdev-dev, %s: name=%s\n, __func__, kp-name);
strcpy(buffer, map_get_key( map_health, battery_health, unknown));
return strlen(buffer);
}
-static int param_set_battery_present(const char *key, struct kernel_param *kp)
+static int param_set_battery_present(const char *key, const struct
kernel_param *kp)
{
dev_dbg(bat_pdev-dev, %s: name=%s, key=%s\n, __func__, kp-name,
key);
battery_present = map_get_value( map_present, key, battery_present);
@@ -243,14 +244,14 @@ static int param_set_battery_present(const char
*key, struct kernel_param *kp)
return 0;
}
-static int param_get_battery_present(char *buffer, struct kernel_param *kp)
+static int param_get_battery_present(char *buffer, const struct
kernel_param *kp)
{
dev_dbg(bat_pdev-dev, %s: name=%s\n, __func__, kp-name);
strcpy(buffer, map_get_key( map_present, battery_present, unknown));
return strlen(buffer);
}
-static int param_set_battery_technology(const char *key, struct
kernel_param *kp)
+static int param_set_battery_technology(const char *key, const struct
kernel_param *kp)
{
dev_dbg(bat_pdev-dev, %s: name=%s, key=%s\n, __func__, kp-name,
key);
battery_technology = map_get_value( map_technology, key,
battery_technology);
@@ -258,14 +259,14 @@ static int param_set_battery_technology(const
char *key, struct kernel_param *kp
return 0;
}
-static int param_get_battery_technology(char *buffer, struct kernel_param *kp)
+static int param_get_battery_technology(char *buffer, const struct
kernel_param *kp)
{
dev_dbg(bat_pdev-dev, %s: name=%s\n, __func__, kp-name);
strcpy(buffer, map_get_key(
[git pull] Basic device tree support for ARM
Hi Nicolas, Here's the branch implementing basic device tree support based on the linaro-2.6.38 tree. Should be good to go. g. The following changes since commit f60e8ccbfce6b40a112bddef5b4926b7416b4f92: ARM: fix build failure (2011-02-22 15:49:23 -0500) are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 devicetree/arm-linaro-2.6.38 Grant Likely (5): arm/dt: Make __vet_atags also accept a dtb image arm/dt: consolidate atags setup into setup_machine_atags arm/dt: probe for platforms via the device tree arm/dt: Basic versatile devicetree support arm/dt: Basic tegra devicetree support Jeremy Kerr (1): arm/dt: Allow CONFIG_OF on ARM arch/arm/Kconfig |7 ++ arch/arm/include/asm/mach/arch.h |9 ++ arch/arm/include/asm/prom.h| 37 arch/arm/include/asm/setup.h |5 + arch/arm/kernel/Makefile |1 + arch/arm/kernel/devtree.c | 147 arch/arm/kernel/head-common.S | 24 -- arch/arm/kernel/head.S |8 +- arch/arm/kernel/setup.c| 90 arch/arm/mach-tegra/board-harmony.c|6 ++ arch/arm/mach-versatile/versatile_ab.c |6 ++ arch/arm/mach-versatile/versatile_pb.c |6 ++ arch/arm/mm/init.c | 11 +++ 13 files changed, 312 insertions(+), 45 deletions(-) create mode 100644 arch/arm/include/asm/prom.h create mode 100644 arch/arm/kernel/devtree.c -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: cc'ing patc...@linaro.org
Just a thought in the other way: will it be useful to to have some web crawler to collect those activities as long as we all use linaro email addresses? For mails like patch within, there should be some thing we can identify. On Wed, Feb 23, 2011 at 10:09 AM, Jammy Zhou jammy.z...@linaro.org wrote: Hi All, For some upstream projects, we don't use git-send-mail to send patch for review. Take KDE/Kwin project for example, post-review and the reviewboard[1] are used for patch review. How shall we handle such kind of cases? [1] https://git.reviewboard.kde.org/ Regards, Jammy On Wed, Feb 23, 2011 at 6:19 AM, Loïc Minier loic.min...@linaro.org wrote: On Tue, Feb 22, 2011, john stultz wrote: Add to the commit log: CC: Loïc Minier loic.min...@linaro.org CC: patc...@linaro.org And git-send-email will add those entries to the outgoing mail. Ah, so it's in the commit forever; I thought you were adding that at send-email time; ok, thanks! -- Loïc Minier ___ 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 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Booting problem on Panda board
Hi Andy, On Monday 21 February 2011 08:21 PM, Andy Green wrote: On 02/21/2011 02:26 PM, Somebody in the thread at some point said: Hi - Also, pressing the PWRON_RESET button does not reboot the system. Hi Avik, I suspect you are now hitting the power off bug [1]. It seems to strike at random places in the boot for different people/images. [1] https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/708883 This sounds like the right diagnosis... in which case you should be able to work around it using the patch I added to #37 on that bug. After applying your patch to the latest linux-linaro-2.6.37 kernel, I'm again hitting bug #720055 (https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/720055). Regards, Avik -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Booting problem on Panda board
Hi Avik, yes, agreed. Problem described with bug #720055 (which appears to remain unresolved) is a different beast than what Andy's patch is addressing. If you pull the kernel mentioned in #39 of bug #70883, apply the patch, you'll have better luck booting panda board. On 02/22/2011 11:37 PM, Avik Sil wrote: Hi Andy, On Monday 21 February 2011 08:21 PM, Andy Green wrote: On 02/21/2011 02:26 PM, Somebody in the thread at some point said: Hi - Also, pressing the PWRON_RESET button does not reboot the system. Hi Avik, I suspect you are now hitting the power off bug [1]. It seems to strike at random places in the boot for different people/images. [1] https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/708883 This sounds like the right diagnosis... in which case you should be able to work around it using the patch I added to #37 on that bug. After applying your patch to the latest linux-linaro-2.6.37 kernel, I'm again hitting bug #720055 (https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/720055). Regards, Avik -Andy ___ 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: linaro-omap kernel 1003.6 boot failure
-Original Message- From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev- boun...@lists.linaro.org] On Behalf Of Turgis, Frederic Sent: Monday, February 21, 2011 11:20 PM To: linaro-dev@lists.linaro.org Subject: linaro-omap kernel 1003.6 boot failure Hi, (writing from my work address as frederic.tur...@linaro.org lost password is still not reset ;-) ) To perform some systemtap checking, I need kernel package with debug symbols, which is available in 1003.6 version from http://ddebs.ubuntu.com/pool/universe/l/linux-linaro-omap/ So I did some apt-get update, install linux-image-2.6.37-1003- linaro-omap followed by flash-kernel 2.6.37-1003-linaro-omap. Boot fails at some point (before setting up omap_hsuart in an OK log from 2.6.37-1002) Any known issue or thing I am doing wrong ? Try this series and see if you can locate the offending module ? http://www.mail-archive.com/linux-omap@vger.kernel.org/msg45021.html U-Boot 2010.12 (Jan 27 2011 - 17:59:04) 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: 0 reading boot.scr 381 bytes read Running bootscript from mmc0 ... ## Executing script at 8200 reading uImage 4000628 bytes read reading uInitrd 4154752 bytes read ## Booting kernel from Legacy Image at 8020 ... Image Name: Ubuntu Kernel Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4000564 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 8160 ... Image Name: Ubuntu Initrd Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size:4154688 Bytes = 4 MiB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.37-1003-linaro-omap (buildd@gourd) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-2ubuntu2) ) #6-Ubuntu SMP Fri Feb 11 18:49:17 UTC 2011 (Ubuntu 2.6.37-1003.6-linaro-omap 2.6.37) [0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7f [0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP4 Panda board [0.00] bootconsole [earlycon0] enabled [0.00] Reserving 33554432 bytes SDRAM for VRAM [0.00] Memory policy: ECC disabled, Data cache writealloc [0.00] OMAP4430 ES2.0 [0.00] SRAM: Mapped pa 0x4030 to va 0xfe40 size: 0xe000 [0.00] FIXME: omap44xx_sram_init not implemented [0.00] PERCPU: Embedded 7 pages/cpu @c0c5b000 s7680 r8192 d12800 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 109410 [0.00] Kernel command line: console=tty0 console=ttyO2,115200n8 root=UUID=dfc5a269-1ede-4174-b52a- 02a1297a52f7 rootwait ro earlyprintk fixrtc nocompcache vram=32M omapfb.vram=0:8M mem=463M ip=none [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] allocated 2370560 bytes of page_cgroup [0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [0.00] Memory: 430MB 1MB = 431MB total [0.00] Memory: 421860k/421860k available, 52252k 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 : 0xdd00 - 0xf800 ( 432 MB) [0.00] lowmem : 0xc000 - 0xdcf0 ( 463 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .init : 0xc0008000 - 0xc0053000 ( 300 kB) [0.00] .text : 0xc0053000 - 0xc078a32c (7389 kB) [0.00] .data : 0xc078c000 - 0xc07f04e0 ( 402 kB) [0.00] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] RCU-based detection of stalled CPUs is disabled. [0.00] NR_IRQS:402 [0.00] clockdomain: l3_dma_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: emu_sys_clkdm: OMAP4 wakeup/sleep dependency support: not yet implemented [0.00] clockdomain: emu_sys_clkdm: clkdm_clear_all_wkdeps: not yet implemented [0.00] clockdomain: l4_wkup_clkdm: OMAP4 wakeup/sleep dependency support:
Re: Booting problem on Panda board
On 02/23/2011 05:49 AM, Somebody in the thread at some point said: Hi - yes, agreed. Problem described with bug #720055 (which appears to remain unresolved) is a different beast than what Andy's patch is addressing. If you pull the kernel mentioned in #39 of bug #70883, apply the patch, you'll have better luck booting panda board. Right the patch from #37 of 708883 successfully worked around the turning off bug allowing you to continue along to what seems to be a display initialization issue with the tree you're using. That bug is getting attention and patches at the moment... https://bugs.launchpad.net/bugs/720055 -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [st-ericsson] v4l2 vs omx for camera
Hi All, Just wanted to add one last point in this discussion. The imaging coprocessor in today's platforms have a general purpose DSP attached to it I have seen some work being done to use this DSP for graphics/audio processing in case the camera use case is not being tried or also if the camera usecases does not consume the full bandwidth of this dsp.I am not sure how v4l2 would fit in such an architecture, I am not sure if that is the case with all the platforms today but my feeling is that this is going to be excercised more in future architectures where a single dedicated dsp/arm processor is used to control the video/imaging specific hardware blocks and there could be some other tasks offloaded to this dedicated dsp/arm processor in case it has free bandwidth to support those tasks. Thanks Sachin On Tue, Feb 22, 2011 at 8:14 AM, Clark, Rob r...@ti.com wrote: On Fri, Feb 18, 2011 at 10:39 AM, Robert Fekete robert.fek...@linaro.org wrote: Hi, In order to expand this knowledge outside of Linaro I took the Liberty of inviting both linux-me...@vger.kernel.org and gstreamer-de...@lists.freedesktop.org. For any newcomer I really recommend to do some catch-up reading on http://lists.linaro.org/pipermail/linaro-dev/2011-February/thread.html (v4l2 vs omx for camera thread) before making any comments. And sign up for Linaro-dev while you are at it :-) To make a long story short: Different vendors provide custom OpenMax solutions for say Camera/ISP. In the Linux eco-system there is V4L2 doing much of this work already and is evolving with mediacontroller as well. Then there is the integration in Gstreamer...Which solution is the best way forward. Current discussions so far puts V4L2 greatly in favor of OMX. Please have in mind that OpenMAX as a concept is more like GStreamer in many senses. The question is whether Camera drivers should have OMX or V4L2 as the driver front end? This may perhaps apply to video codecs as well. Then there is how to in best of ways make use of this in GStreamer in order to achieve no copy highly efficient multimedia pipelines. Is gst-omx the way forward? just fwiw, there were some patches to make v4l2src work with userptr buffers in case the camera has an mmu and can handle any random non-physically-contiguous buffer.. so there is in theory no reason why a gst capture pipeline could not be zero copy and capture directly into buffers allocated from the display Certainly a more general way to allocate buffers that any of the hw blocks (display, imaging, video encoders/decoders, 3d/2d hw, etc) could use, and possibly share across-process for some zero copy DRI style rendering, would be nice. Perhaps V4L2_MEMORY_GEM? Let the discussion continue... On 17 February 2011 14:48, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Thursday 10 February 2011 08:47:15 Hans Verkuil wrote: On Thursday, February 10, 2011 08:17:31 Linus Walleij wrote: On Wed, Feb 9, 2011 at 8:44 PM, Harald Gustafsson wrote: OMX main purpose is to handle multimedia hardware and offer an interface to that HW that looks identical indenpendent of the vendor delivering that hardware, much like the v4l2 or USB subsystems tries to do. And yes optimally it should be implemented in drivers/omx in Linux and a user space library on top of that. Thanks for clarifying this part, it was unclear to me. The reason being that it seems OMX does not imply userspace/kernelspace separation, and I was thinking more of it as a userspace lib. Now my understanding is that if e.g. OpenMAX defines a certain data structure, say for a PCM frame or whatever, then that exact struct is supposed to be used by the kernelspace/userspace interface, and defined in the include file exported by the kernel. It might be that some alignment also needs to be made between 4vl2 and other OS's implementation, to ease developing drivers for many OSs (sorry I don't know these details, but you ST-E guys should know). The basic conflict I would say is that Linux has its own API+ABI, which is defined by V4L and ALSA through a community process without much thought about any existing standard APIs. (In some cases also predating them.) By the way IL is about to finalize version 1.2 of OpenMAX IL which is more than a years work of aligning all vendors and fixing unclear and buggy parts. I suspect that the basic problem with Khronos OpenMAX right now is how to handle communities - for example the X consortium had something like the same problem a while back, only member companies could partake in the standard process, and they need of course to pay an upfront fee for that, and the majority of these companies didn't exactly send Linux community members to the meetings. And
[RFC] Linaro Toolchain for Android and NDK
Hello list, I would like to make a proposal about utilizing Linaro toolchain for Android and NDK (Native Development Kit)[1]. ** Motivation There are some different perspectives between Linaro toolchain and Google Android toolchain including technical and non-technical considerations. It doesn't really work if we only replace prebuilt toolchain with Linaro toolchain because of the compatibility of Android system utilities such as ELF prelinker. Also, since Android is developed in relatively closed environment (Google style open source model), a great amount of software components are not always verified by different toolchain or build configurations. This proposal attempts to establish the compact development flow to enable Linaro optimized ARM toolchain to build Android from scratch and verify it transparently. Eventually, Android can be the reference indicator as Linaro toolchain performance and reliability. ** Brief introduction to Google Android toolchain Inside Google, there is a dedicated compiler team working on GNU Toolchain for various purposes including server-side computing, Android, Chrome OS, etc. Google engineers submit patches to upstream for public review and maintain the toolchain for Android. Along with each Android Open Source Prokect (AOSP) release, there is a special branch in korg GIT [2] for hosting the GPL'd toolchain source code modified by Google. Usually, file README.google mentioned the summary, but it is not developer friendly because several changes were done within one GIT commit. Please refer to wiki for details: https://wiki.linaro.org/Platform/Android/UpstreamToolchain ** What's wrong with Android upstream Toolchain? In my opinion, list as following: (1) Few information about Google improvement: Sometimes, we have to guess something from implicit GIT commitlog such as commit gcc-4.4.3 which is used to build gcc-4.4.3 Android toolchain in master[3]. It is hard to track and get verified carefully. (2) Google specific improvements are absent in recent release, only enabled months later. For example, Google Compiler Team Lead, Dr. Shih-wei Liao, presented the improvements against GNU Toolchain in the middle of 2009.[4]. The report came with several impressive improvements like FDO (Feedback Directed Optimizations) and IPO (Inter-Procedure Optimizations). However, only some of them are public to AOSP and be integrated late in the middle of 2010 (Android Froyo; 2.2). Even FDO was merged in Android Froyo already, but there is few documentation and no robust method to verify by community members such as Linaro engineers. (3) For some reasons, Google tends to deliver stable (old) toolchain plus mainline backport. It is a safe and workable approach, but sometimes developers would expect to use the latest technologies as Linaro aims to bring to the world. (4) Few readable documentation. For example, Google already open its toolchain benchmark suite in early 2010, but there was no document specific to such important components. Furthermore, there was one file gone in public kog GIT, required by automated benchmark process. One year later, Google engineer finally put back the one to public. This implies the unusual way Google developed and delivered software. ** Linaro's Approach to enable latest technologies Linaro android team tries to do: (1) Document Android toolchain and related utilities in korg GIT as possible as we can. (2) Early adaptation of Linaro toolchain to Android build system and verify these output systematically. (3) Backport Google changes to Linaro GCC and review in public. (4) Improve the deployment and validation flow by means of Linaro infrastructure. (5) Build and test Android system with Linaro tools. Then, figure out the regressions caused by Linaro Toolchain and/or aggressive optimizations (6) measure performance gain by Linaro tools The detailed specification in wiki: https://wiki.linaro.org/Platform/Android/Specs/LinaroAndroidToolchain ** Implementation of Linaro toolchain for Android We started from Android style toolchain build and move to Linaro GCC + ARM specific optimizations in mind. The initial work can be obtained by wiki: https://wiki.linaro.org/Platform/Android/Toolchain We plan to maintain the following GIT repositories at least: * android/toolchain/build.git : Linaro-aware build system. Derived from Android toolchain build system, it can handle Linaro-GCC and Linaro snapshot/bzr. * android/toolchain/gcc-patches.git : Patchset to be applied on top of Linaro-GCC release/snapshots The reference builder script output: $ ./linaro-build.sh --help --prefix-dir= Specify where to install (default: /tmp/android-toolchain-eabi) --gcc-src-dir= Specify where linaro gcc source is (in toolchain/gcc) --apply-gcc-patch=(yes|no) Apply-patch which in toolchain/gcc-patches directory (default: no) Current verified combinations: * gcc-linaro: 4.5-2011.02-0 * binutils: 2.20.1 * gmp:
Re: Emdebian sprint - flash-kernel discussion
On 02/22/2011 09:54 PM, Somebody in the thread at some point said: Hi - I ask mostly from a position of ignorance, but is the information in this database related to the information linaro-media-create keeps about each board? If so, could it be shared somehow? It's completely related and I envisioned we could share it some time ago: http://www.mail-archive.com/linaro-dev@lists.linaro.org/msg00254.html even before linaro-image-tools existed ;-) But thanks for bringing this up, it's a good thing to put on the goals for the rework: that the data be usage-agnostic and self-contained as to allow reuse in other places. Since we discuss this later today going to throw my thoughts out there. Over the longer term I think it could be possible to arrange things that - hwpacks as they are - initrds, and - Qemu requirement for image composition, maybe whole l-m-c could in most or all cases be dispensed with. In that situation l-m-c itself would ideally disappear into composition-host-runnable scripts down /etc/board-specific.d or /usr/share/whatever.d for hosts that have a concept of external bootloader and / or kernel composition (ie, not shoving it in local NAND but SD card). So, at what used to be l-m-c time you run on the composition host the same scripts that the native device uses for bootloader and kernel install from the composed rootfs itself, with suitable abstraction of device names and so on. Any scripting config left from kernel package install could be batched and deferred until first boot where it runs natively. Another kinda-related simplification that would pay dividends is to enable taking advantage of multi-board kernels within the same arch that are possible, by having the same deal in terms of multi-board bootloaders within the same arch. Currently X-loader and U-Boot take a compile-time config approach that forces them to emit ultra-specific bootloader binaries. If that was fixed then it'd be possible to have, eg, a single Omap4 kernel package and a single Omap4 bootloader package that worked on all supported Omap4 boards and so on. -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
