linaro-kernel October 2013

linaro-kernel@lists.linaro.org

87 participants
222 discussions

mainline boot: 33 pass, 0 fail (v3.12-rc5-56-g0056019)

by Kevin's boot bot

Automated DT boot report for various ARM defconfigs. Tree/Branch: mainline Git describe: v3.12-rc5-56-g0056019 Full Report =========== omap2plus_defconfig ------------------- am335x-boneblack PASS: 0 min 30.3 sec omap3-beagle-xm PASS: 0 min 51.8 sec am335x-bone PASS: 0 min 26.1 sec omap3-tobi,3530overo PASS: 0 min 21.1 sec omap4-panda PASS: 1 min 7.1 sec omap4-panda-es PASS: 1 min 4.8 sec omap3-tobi,3730storm PASS: 0 min 20.3 sec omap3-beagle PASS: 0 min 55.3 sec tegra_defconfig --------------- tegra30-beaver PASS: 0 min 16.9 sec imx_v6_v7_defconfig ------------------- imx6dl-wandboard,wand-dual PASS: 0 min 16.2 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.1 sec imx6q-wandboard PASS: 0 min 14.8 sec mvebu_defconfig --------------- armada-xp-openblocks-ax3-4 PASS: 0 min 21.9 sec armada-370-mirabox PASS: 0 min 19.9 sec exynos_defconfig ---------------- exynos5250-arndale PASS: 0 min 34.7 sec multi_v7_defconfig ------------------ ste-snowball PASS: 0 min 25.2 sec tegra30-beaver PASS: 0 min 14.2 sec am335x-boneblack PASS: 0 min 34.4 sec omap3-beagle-xm PASS: 0 min 48.8 sec armada-370-mirabox PASS: 0 min 20.6 sec omap4-panda PASS: 1 min 2.5 sec omap4-panda-es PASS: 0 min 58.5 sec armada-xp-openblocks-ax3-4 PASS: 0 min 22.8 sec sun4i-a10-cubieboard PASS: 0 min 13.7 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.3 sec omap3-tobi,3530overo PASS: 0 min 19.8 sec am335x-bone PASS: 0 min 33.2 sec imx6q-wandboard PASS: 0 min 15.7 sec omap3-tobi,3730storm PASS: 0 min 22.1 sec imx6dl-wandboard,wand-dual PASS: 0 min 16.5 sec omap3-beagle PASS: 0 min 52.2 sec u8500_defconfig --------------- ste-snowball PASS: 0 min 33.7 sec sama5_defconfig --------------- sama5d35ek PASS: 0 min 17.3 sec

11 years, 10 months

queue boot: 14 pass, 3 fail (v3.10.16-69-g1bda1fa)

by Kevin's boot bot

Automated DT boot report for various ARM defconfigs. Tree/Branch: queue Git describe: v3.10.16-69-g1bda1fa Failed boot tests (console logs at the end) =========================================== armada-xp-openblocks-ax3-4: FAIL: multi_v7_defconfig armada-370-mirabox: FAIL: multi_v7_defconfig sun4i-a10-cubieboard: FAIL: multi_v7_defconfig Full Report =========== omap2plus_defconfig ------------------- omap3-beagle-xm PASS: 0 min 52.6 sec am335x-bone PASS: 0 min 26.3 sec omap3-tobi,3530overo PASS: 0 min 33.5 sec omap4-panda PASS: 1 min 4.4 sec omap4-panda-es PASS: 1 min 5.9 sec omap3-tobi,3730storm PASS: 0 min 36.1 sec omap3-beagle PASS: 0 min 52.2 sec tegra_defconfig --------------- tegra30-beaver PASS: 0 min 15.0 sec imx_v6_v7_defconfig ------------------- imx6dl-wandboard,wand-dual PASS: 0 min 16.7 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.6 sec mvebu_defconfig --------------- armada-xp-openblocks-ax3-4 PASS: 0 min 21.6 sec armada-370-mirabox PASS: 0 min 19.6 sec exynos_defconfig ---------------- exynos5250-arndale PASS: 0 min 28.9 sec multi_v7_defconfig ------------------ armada-xp-openblocks-ax3-4 FAIL: 0 min 19.9 sec armada-370-mirabox FAIL: 0 min 18.0 sec sun4i-a10-cubieboard FAIL: 1 min 9.0 sec sama5_defconfig --------------- sama5d35ek PASS: 0 min 16.4 sec Console logs for failures ========================= multi_v7_defconfig ------------------ armada-xp-openblocks-ax3-4: FAIL: last 24 lines of boot log: ------------------------------------------------------------ [<c0013bcc>] (unwind_backtrace+0x0/0xf4) from [<c0011490>] (show_stack+0x10/0x14) [<c0011490>] (show_stack+0x10/0x14) from [<c0275720>] (panic+0xa0/0x1e8) [<c0275720>] (panic+0xa0/0x1e8) from [<c0326110>] (mount_block_root+0x294/0x298) [<c0326110>] (mount_block_root+0x294/0x298) from [<c03262c4>] (prepare_namespace+0x14c/0x184) [<c03262c4>] (prepare_namespace+0x14c/0x184) from [<c0325d60>] (kernel_init_freeable+0x1c8/0x1d8) [<c0325d60>] (kernel_init_freeable+0x1c8/0x1d8) from [<c027147c>] (kernel_init+0x8/0x158) [<c027147c>] (kernel_init+0x8/0x158) from [<c000df18>] (ret_from_fork+0x14/0x3c) CPU0: stopping CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.16-00069-g1bda1fa #1 [<c0013bcc>] (unwind_backtrace+0x0/0xf4) from [<c0011490>] (show_stack+0x10/0x14) [<c0011490>] (show_stack+0x10/0x14) from [<c001234c>] (handle_IPI+0x108/0x130) [<c001234c>] (handle_IPI+0x108/0x130) from [<c000851c>] (armada_370_xp_handle_irq+0x90/0xa8) [<c000851c>] (armada_370_xp_handle_irq+0x90/0xa8) from [<c000dac0>] (__irq_svc+0x40/0x50) Exception stack(0xc0355f70 to 0xc0355fb8) 5f60: c1d566d8 00000000 000000be 000000be 5f80: c037fa2c c035c4a8 c027cebc c0354000 c037fa2c c0354000 c0354000 c035c45c 5fa0: 0000001f c0355fb8 c000f070 c004f8e0 60000113 ffffffff [<c000dac0>] (__irq_svc+0x40/0x50) from [<c004f8e0>] (cpu_startup_entry+0xfc/0x140) [<c004f8e0>] (cpu_startup_entry+0xfc/0x140) from [<c0325a3c>] (start_kernel+0x2c4/0x2d0) [<c0325a3c>] (start_kernel+0x2c4/0x2d0) from [<00008074>] (0x8074) ~$off # PYBOOT: Exception: kernel: ERROR: failed to boot: Kernel panic # PYBOOT: Time: 19.91 seconds. # PYBOOT: Result: FAIL armada-370-mirabox: FAIL: last 24 lines of boot log: ---------------------------------------------------- mousedev: PS/2 mouse device common for all mice sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman sdhci-pltfm: SDHCI platform and OF driver helper usbcore: registered new interface driver usbhid usbhid: USB HID core driver VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 6 Registering SWP/SWPB emulation handler ../../drivers/rtc/hctosys.c: unable to open rtc device (rtc0) List of all partitions: No filesystem could mount root, tried: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.16-00069-g1bda1fa #1 [<c0013bcc>] (unwind_backtrace+0x0/0xf4) from [<c0011490>] (show_stack+0x10/0x14) [<c0011490>] (show_stack+0x10/0x14) from [<c0275720>] (panic+0xa0/0x1e8) [<c0275720>] (panic+0xa0/0x1e8) from [<c0326110>] (mount_block_root+0x294/0x298) [<c0326110>] (mount_block_root+0x294/0x298) from [<c03262c4>] (prepare_namespace+0x14c/0x184) [<c03262c4>] (prepare_namespace+0x14c/0x184) from [<c0325d60>] (kernel_init_freeable+0x1c8/0x1d8) [<c0325d60>] (kernel_init_freeable+0x1c8/0x1d8) from [<c027147c>] (kernel_init+0x8/0x158) [<c027147c>] (kernel_init+0x8/0x158) from [<c000df18>] (ret_from_fork+0x14/0x3c) ~$off # PYBOOT: Exception: kernel: ERROR: failed to boot: Kernel panic # PYBOOT: Time: 17.97 seconds. # PYBOOT: Result: FAIL sun4i-a10-cubieboard: FAIL: last 24 lines of boot log: ------------------------------------------------------ ipmi_si: Trying default-specified bt state machine at i/o address 0xe4, slave address 0x0, irq 0 ipmi_si: Could not set up I/O space Trying to free nonexistent resource <00000000000000e4-00000000000000e4> Trying to free nonexistent resource <00000000000000e5-00000000000000e5> Trying to free nonexistent resource <00000000000000e6-00000000000000e6> ipmi_si: Unable to find any System Interface(s) Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 17) is a U6_16550A console [ttyS0] enabled usbcore: registered new interface driver usb-storage mousedev: PS/2 mouse device common for all mice sdhci: Secure Digital Host Controller Interface driver sdhci: Copyright(c) Pierre Ossman sdhci-pltfm: SDHCI platform and OF driver helper usbcore: registered new interface driver usbhid usbhid: USB HID core driver VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3 Registering SWP/SWPB emulation handler ../../drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Waiting for root device /dev/mmcblk0p2... ~$off # PYBOOT: Exception: kernel: ERROR: failed to boot: <class 'pexpect.TIMEOUT'> # PYBOOT: Time: 68.96 seconds. # PYBOOT: Result: FAIL

11 years, 10 months

next-thierry boot: 31 pass, 2 fail (next-20131016)

by Kevin's boot bot

Automated DT boot report for various ARM defconfigs. Tree/Branch: next-thierry Git describe: next-20131016 Failed boot tests (console logs at the end) =========================================== exynos5250-arndale: FAIL: exynos_defconfig am335x-bone: FAIL: multi_v7_defconfig Full Report =========== omap2plus_defconfig ------------------- am335x-boneblack PASS: 0 min 30.0 sec omap3-beagle-xm PASS: 0 min 50.5 sec am335x-bone PASS: 0 min 26.1 sec omap3-tobi,3530overo PASS: 0 min 21.4 sec omap4-panda PASS: 1 min 7.4 sec omap4-panda-es PASS: 1 min 5.1 sec omap3-tobi,3730storm PASS: 0 min 21.0 sec omap3-beagle PASS: 0 min 50.9 sec tegra_defconfig --------------- tegra30-beaver PASS: 0 min 17.1 sec imx_v6_v7_defconfig ------------------- imx6dl-wandboard,wand-dual PASS: 0 min 16.3 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.2 sec imx6q-wandboard PASS: 0 min 14.9 sec mvebu_defconfig --------------- armada-xp-openblocks-ax3-4 PASS: 0 min 22.0 sec armada-370-mirabox PASS: 0 min 20.0 sec exynos_defconfig ---------------- exynos5250-arndale FAIL: 0 min 33.4 sec multi_v7_defconfig ------------------ ste-snowball PASS: 0 min 25.5 sec tegra30-beaver PASS: 0 min 17.0 sec am335x-boneblack PASS: 0 min 34.5 sec omap3-beagle-xm PASS: 0 min 50.1 sec armada-370-mirabox PASS: 0 min 20.8 sec omap4-panda PASS: 1 min 6.3 sec omap4-panda-es PASS: 1 min 8.6 sec armada-xp-openblocks-ax3-4 PASS: 0 min 22.8 sec sun4i-a10-cubieboard PASS: 0 min 13.7 sec imx6dl-wandboard,wand-solo PASS: 0 min 16.5 sec omap3-tobi,3530overo PASS: 0 min 19.8 sec am335x-bone FAIL: 0 min 31.4 sec imx6q-wandboard PASS: 0 min 16.8 sec omap3-tobi,3730storm PASS: 0 min 22.1 sec imx6dl-wandboard,wand-dual PASS: 0 min 16.7 sec omap3-beagle PASS: 0 min 49.9 sec u8500_defconfig --------------- ste-snowball PASS: 0 min 33.0 sec sama5_defconfig --------------- sama5d35ek PASS: 0 min 17.4 sec Console logs for failures ========================= exynos_defconfig ---------------- exynos5250-arndale: FAIL: last 24 lines of boot log: ---------------------------------------------------- tftp 0x407c0000 tmp/arndale-rXxUQ2/exynos5250-arndale.dtb Waiting for Ethernet connection... done. Using asx0 device TFTP from server 192.168.1.2; our IP address is 192.168.1.171 Filename 'tmp/arndale-rXxUQ2/exynos5250-arndale.dtb'. Load address: 0x407c0000 Loading: *### done Bytes transferred = 32949 (80b5 hex) ARNDALE5250 # printenv bootargs printenv bootargs bootargs=console=tty0 console=ttySAC2,115200n8 rw root=/dev/mmcblk1p3 rootwait rootfstype=ext4 ip=192.168.1.171:192.168.1.2:192.168.1.254:255.255.255.0::::192.168.1.254:none ARNDALE5250 # bootz 0x40800000 - 0x407c0000 bootz 0x40800000 - 0x407c0000 ## Flattened Device Tree blob at 407c0000 Booting using the fdt blob at 0x407c0000 Using Device Tree in place at 407c0000, end 407cb0b4 Starting kernel ... ~$off # PYBOOT: Exception: kernel: ERROR: did not start booting. # PYBOOT: Time: 33.37 seconds. # PYBOOT: Result: FAIL multi_v7_defconfig ------------------ am335x-bone: FAIL: last 24 lines of boot log: --------------------------------------------- cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use cu: /home/khilman/dev/am335xbone: Line in use Unknown command 'þ`æ~þþþææþ`æ~þþþææþ`æ~þþþææxð~xð~' - try 'help' U-Boot# ~$off # PYBOOT: Exception: ERROR: Could not break into autoboot. # PYBOOT: Time: 31.38 seconds. # PYBOOT: Result: FAIL

11 years, 10 months

[PATCH] clk: s3c64xx: Fix aliases for SPI devices

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> The clock aliases for SPI devices do not reflect the actual usage in the driver causing the SPI controller to fail to probe when the clock driver is in use, fix this up. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/clk/samsung/clk-s3c64xx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/samsung/clk-s3c64xx.c b/drivers/clk/samsung/clk-s3c64xx.c index 7d2c842..3cbd47c 100644 --- a/drivers/clk/samsung/clk-s3c64xx.c +++ b/drivers/clk/samsung/clk-s3c64xx.c @@ -356,8 +356,8 @@ static struct samsung_clock_alias s3c64xx_clock_aliases[] = { ALIAS(SCLK_MMC2, "s3c-sdhci.2", "mmc_busclk.2"), ALIAS(SCLK_MMC1, "s3c-sdhci.1", "mmc_busclk.2"), ALIAS(SCLK_MMC0, "s3c-sdhci.0", "mmc_busclk.2"), - ALIAS(SCLK_SPI1, "s3c6410-spi.1", "spi-bus"), - ALIAS(SCLK_SPI0, "s3c6410-spi.0", "spi-bus"), + ALIAS(SCLK_SPI1, "s3c6410-spi.1", "spi_busclk1"), + ALIAS(SCLK_SPI0, "s3c6410-spi.0", "spi_busclk0"), ALIAS(SCLK_AUDIO1, "samsung-pcm.1", "audio-bus"), ALIAS(SCLK_AUDIO1, "samsung-i2s.1", "audio-bus"), ALIAS(SCLK_AUDIO0, "samsung-pcm.0", "audio-bus"), -- 1.8.4.rc3

11 years, 10 months

Re: .align may cause data to be interpreted as instructions

by Dave Martin

On Wed, Oct 16, 2013 at 12:13:28PM +0100, Ben Dooks wrote: > On 15/10/13 23:38, Taras Kondratiuk wrote: > > Hi > > > > I was debugging kprobes-test for BE8 and noticed that some data fields > > are stored in LE instead of BE. It happens because these data fields > > get interpreted as instructions. > > > > Is it a known issue? > > I reported the crashes to Tixy along with a different > method of sovling the problem (changed to using pointers to > the strings) a while ago. However it seems that nothing has > happened to fix this. > > Since kprobes seems to work with the fixed tests I forgot > to follow up and prod Jon about looking into this problem. > > Jon, if you are not interested in fixing this, then please > let me know and we can get a patch sorted to fix it. > > PS, I am going to leave this out of the current be8 patchset > as I want to get that merged, and at the moment kprobes-test > is not essential to getting the system started. > > > For example: > > test_align_fail_data: > > bx lr > > .byte 0xaa > > .align > > .word 0x12345678 > > > > I would expect to see something like this: > > 00000000<test_align_fail_data>: > > 0: e12fff1e bx lr > > 4: aa .byte 0xaa > > 5: 00 .byte 0x00 > > 6: 0000 .short 0x0000 > > 8: 12345678 .word 0x12345678 > > > > But instead I have: > > 00000000<test_align_fail_data>: > > 0: e12fff1e bx lr > > 4: aa .byte 0xaa > > 5: 00 .byte 0x00 > > 6: 0000 .short 0x0000 > > 8: 12345678 eorsne r5, r4, #120, 12 ; 0x7800000 > > > > As a result the word 0x12345678 will be stored in LE. > > > > I've run several tests and here are my observations: > > - Double ".align" fixes the issue :) > > - Behavior is the same for LE/BE, ARM/Thumb, GCC 4.4.1/4.6.x/4.8.2 > > - Size of alignment doesn't matter. > > - Issue happens only if previous data is not instruction-aligned and > > 0's are added before NOPs. > > - Explicit filling with 0's (.align , 0) fixes the issue, but as a side > > effect data @0x4 is interpreted as a single ".word 0xaa000000" > > instead of ".byte .byte .short". I'm not sure if there can be any > > functional difference because of this. There isn't. This is just objdump's pretty-printing behaviour. Objdump prints out the data in naturally-aligned units, but this has nothing to do with whether .byte, .short or .word/.long was used in the source. > > - Issue doesn't happen if there is no instructions before data > > (no "bx lr" in the example). > > - Issue doesn't happen if data after .align is defined as > > ".type<symbol>,%object". > > Thanks for getting down to a simple test case. Unfortunately, objdump can and does get confused about data/instruction boundaries, so the output you see above may be misleading. Displaying the symbol table with --special-syms will list the magic symbols that mark the instruction and data boundaries, to help debug this kind of situation. However, in this case, I think you've found a bug in the assembler, as shown below. Before linking, the final $a symbol (indicating the start of ARM instructions) is at address 8, so in this case objdump is correct to show 0x12345678 as an instruction. After linking, the mapping symbols ($[atd]) remain as before, and the linker has byteswapped this "instruction" (as it should). This is likely related to the magic for inserting the extensible NOP-padding fragment which implements the .align in code sections. That is code, and requires a $a mapping symbol, but that somehow goes AWOL or gets displaced after the alignment padding ... I can't quite get my head around what is going on in binutils/gas/config/tc-arm.c. We would need to understand that before we can identify a reliable workaround. > > My view is to fix this by not doing complicated things by trying > to save a bit of space by embedding strings into the code. It is > not as if we cannot get the compiler to put the strings into the > relevant data area and give us a pointer we can use. > > The code in this case is /not easy/ to follow and it would be nice > if it could be cleaned up to just take the string as a argument to > the test code instead of trying to find it via assembly magic. My conslusion is the same as yours -- we should avoid these clever tricks in asm for now, if possible. Otherwise, we need to identify a workaround... Cheers ---Dave [terminal spew follows] $ arm-linux-gnueabi-as --version GNU assembler (GNU Binutils) 2.23.2 $ arm-linux-gnueabi-as -EB -o test.o test.s $ arm-linux-gnueabi-ld -EB --be8 -o test test.o arm-linux-gnueabi-ld: warning: cannot find entry symbol _start; defaulting to 0000000000008054 $ arm-linux-gnueabi-objdump -dst --special-syms test.o test.o: file format elf32-bigarm SYMBOL TABLE: 00000000 l d .text 00000000 .text 00000000 l d .data 00000000 .data 00000000 l d .bss 00000000 .bss 00000000 l .text 00000000 test_align_fail_data 00000000 l .text 00000000 $a 00000004 l .text 00000000 $d 00000005 l .text 00000000 $d 00000008 l .text 00000000 $a 00000000 l d .ARM.attributes 00000000 .ARM.attributes Contents of section .text: 0000 e12fff1e aa000000 12345678 ./.......4Vx Contents of section .ARM.attributes: 0000 41000000 15616561 62690001 0000000b A....aeabi...... 0010 06020801 0901 ...... Disassembly of section .text: 00000000 <test_align_fail_data>: 0: e12fff1e bx lr 4: aa .byte 0xaa 5: 00 .byte 0x00 6: 0000 .short 0x0000 8: 12345678 eorsne r5, r4, #120, 12 ; 0x7800000 $ arm-linux-gnueabi-objdump -dst --special-syms test test: file format elf32-bigarm SYMBOL TABLE: 00008054 l d .text 00000000 .text 00000000 l d .ARM.attributes 00000000 .ARM.attributes 00000000 l df *ABS* 00000000 test.o 00008054 l .text 00000000 test_align_fail_data 00008054 l .text 00000000 $a 00008058 l .text 00000000 $d 00008059 l .text 00000000 $d 0000805c l .text 00000000 $a 00000000 l df *ABS* 00000000 00010060 g .text 00000000 _bss_end__ 00010060 g .text 00000000 __bss_start__ 00010060 g .text 00000000 __bss_end__ 00000000 *UND* 00000000 _start 00010060 g .text 00000000 __bss_start 00010060 g .text 00000000 __end__ 00010060 g .text 00000000 _edata 00010060 g .text 00000000 _end Contents of section .text: 8054 1eff2fe1 aa000000 78563412 ../.....xV4. Contents of section .ARM.attributes: 0000 41000000 15616561 62690001 0000000b A....aeabi...... 0010 06020801 0901 ...... Disassembly of section .text: 00008054 <test_align_fail_data>: 8054: e12fff1e bx lr 8058: aa .byte 0xaa 8059: 00 .byte 0x00 805a: 0000 .short 0x0000 805c: 12345678 eorsne r5, r4, #120, 12 ; 0x7800000

11 years, 10 months

.align may cause data to be interpreted as instructions

by Taras Kondratiuk

Hi I was debugging kprobes-test for BE8 and noticed that some data fields are stored in LE instead of BE. It happens because these data fields get interpreted as instructions. Is it a known issue? For example: test_align_fail_data: bx lr .byte 0xaa .align .word 0x12345678 I would expect to see something like this: 00000000 <test_align_fail_data>: 0: e12fff1e bx lr 4: aa .byte 0xaa 5: 00 .byte 0x00 6: 0000 .short 0x0000 8: 12345678 .word 0x12345678 But instead I have: 00000000 <test_align_fail_data>: 0: e12fff1e bx lr 4: aa .byte 0xaa 5: 00 .byte 0x00 6: 0000 .short 0x0000 8: 12345678 eorsne r5, r4, #120, 12 ; 0x7800000 As a result the word 0x12345678 will be stored in LE. I've run several tests and here are my observations: - Double ".align" fixes the issue :) - Behavior is the same for LE/BE, ARM/Thumb, GCC 4.4.1/4.6.x/4.8.2 - Size of alignment doesn't matter. - Issue happens only if previous data is not instruction-aligned and 0's are added before NOPs. - Explicit filling with 0's (.align , 0) fixes the issue, but as a side effect data @0x4 is interpreted as a single ".word 0xaa000000" instead of ".byte .byte .short". I'm not sure if there can be any functional difference because of this. - Issue doesn't happen if there is no instructions before data (no "bx lr" in the example). - Issue doesn't happen if data after .align is defined as ".type <symbol>,%object". -- Taras Kondratiuk

11 years, 10 months

[PATCH 1/2] ASoC: rt5640: Power down LDO while suspended

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> If we have control over the LDO then disable it during suspend; the device is already being put into reset so will be non-functional over suspend anyway and this will save a small amount of power. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- sound/soc/codecs/rt5640.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c index 641eeeb..b0cde92 100644 --- a/sound/soc/codecs/rt5640.c +++ b/sound/soc/codecs/rt5640.c @@ -1979,12 +1979,20 @@ static int rt5640_suspend(struct snd_soc_codec *codec) rt5640_reset(codec); regcache_cache_only(rt5640->regmap, true); regcache_mark_dirty(rt5640->regmap); + if (gpio_is_valid(rt5640->pdata.ldo1_en)) + gpio_set_value_cansleep(rt5640->pdata.ldo1_en, 0); return 0; } static int rt5640_resume(struct snd_soc_codec *codec) { + struct rt5640_priv *rt5640 = snd_soc_codec_get_drvdata(codec); + + if (gpio_is_valid(rt5640->pdata.ldo1_en)) { + gpio_set_value_cansleep(rt5640->pdata.ldo1_en, 1); + msleep(400); + } rt5640_set_bias_level(codec, SND_SOC_BIAS_STANDBY); return 0; -- 1.8.4.rc3

11 years, 10 months

[PATCH] spi/atmel: Convert to devm_ioremap_resource()

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> This simplifies error handling. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/spi/spi-atmel.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c index beca9cd..daa9f27 100644 --- a/drivers/spi/spi-atmel.c +++ b/drivers/spi/spi-atmel.c @@ -1545,7 +1545,7 @@ static int atmel_spi_probe(struct platform_device *pdev) INIT_LIST_HEAD(&as->queue); as->pdev = pdev; - as->regs = ioremap(regs->start, resource_size(regs)); + as->regs = devm_ioremap_resource(&pdev->dev, regs); if (!as->regs) goto out_free_buffer; as->phybase = regs->start; @@ -1616,7 +1616,6 @@ out_free_dma: out_free_irq: free_irq(irq, master); out_unmap_regs: - iounmap(as->regs); out_free_buffer: if (!as->use_pdc) tasklet_kill(&as->tasklet); @@ -1668,7 +1667,6 @@ static int atmel_spi_remove(struct platform_device *pdev) clk_disable_unprepare(as->clk); clk_put(as->clk); free_irq(as->irq, master); - iounmap(as->regs); spi_unregister_master(master); -- 1.8.4.rc3

11 years, 10 months

[PATCH V4 1/2] ARM: at91: cpuidle: convert to platform driver

by Daniel Lezcano

Using the platform driver model is a good way to separate the cpuidle specific code from the low level pm code. It allows to remove the dependency between these two components. The platform_device is located in the pm code and a 'set' function has been added to set the standby function from the AT91_SOC_START initialization function. Each SoC with a cpuidle driver will set the standby function in the platform_data field at init time. Then pm code will register the cpuidle platform device. The cpuidle driver will register the platform_driver and use the device's platform_data as a standby callback in the idle path. The at91_pm_enter function contains a { if then else } based on cpu_is_xx similar to what was in cpuidle. This is considered dangerous when adding a new SoC. Like the cpuidle driver, a standby ops is defined and assigned when the SoC init function specifies what is its standby function and reused in the at91_pm_enter's 'case' block. Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org> --- arch/arm/mach-at91/at91rm9200.c | 3 +++ arch/arm/mach-at91/at91sam9260.c | 3 +++ arch/arm/mach-at91/at91sam9261.c | 3 +++ arch/arm/mach-at91/at91sam9263.c | 3 +++ arch/arm/mach-at91/at91sam9g45.c | 3 +++ arch/arm/mach-at91/at91sam9rl.c | 3 +++ arch/arm/mach-at91/cpuidle.c | 29 +++++++++++++++-------------- arch/arm/mach-at91/pm.c | 27 +++++++++++++++++++-------- arch/arm/mach-at91/pm.h | 4 ++++ 9 files changed, 56 insertions(+), 22 deletions(-) diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c index 4aad93d..0d234f2 100644 --- a/arch/arm/mach-at91/at91rm9200.c +++ b/arch/arm/mach-at91/at91rm9200.c @@ -27,6 +27,7 @@ #include "generic.h" #include "clock.h" #include "sam9_smc.h" +#include "pm.h" /* -------------------------------------------------------------------- * Clocks @@ -337,6 +338,8 @@ static void __init at91rm9200_initialize(void) /* Initialize GPIO subsystem */ at91_gpio_init(at91rm9200_gpio, cpu_is_at91rm9200_bga() ? AT91RM9200_BGA : AT91RM9200_PQFP); + + at91_pm_set_standby(at91rm9200_standby); } diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c index 5de6074..ffe9ce7 100644 --- a/arch/arm/mach-at91/at91sam9260.c +++ b/arch/arm/mach-at91/at91sam9260.c @@ -28,6 +28,7 @@ #include "generic.h" #include "clock.h" #include "sam9_smc.h" +#include "pm.h" /* -------------------------------------------------------------------- * Clocks @@ -351,6 +352,8 @@ static void __init at91sam9260_initialize(void) /* Register GPIO subsystem */ at91_gpio_init(at91sam9260_gpio, 3); + + at91_pm_set_standby(at91sam9_standby); } /* -------------------------------------------------------------------- diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c index 0e07932..1edbb6f 100644 --- a/arch/arm/mach-at91/at91sam9261.c +++ b/arch/arm/mach-at91/at91sam9261.c @@ -27,6 +27,7 @@ #include "generic.h" #include "clock.h" #include "sam9_smc.h" +#include "pm.h" /* -------------------------------------------------------------------- * Clocks @@ -293,6 +294,8 @@ static void __init at91sam9261_initialize(void) /* Register GPIO subsystem */ at91_gpio_init(at91sam9261_gpio, 3); + + at91_pm_set_sandby(at91sam9_standby); } /* -------------------------------------------------------------------- diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c index 6ce7d18..8c81c89 100644 --- a/arch/arm/mach-at91/at91sam9263.c +++ b/arch/arm/mach-at91/at91sam9263.c @@ -26,6 +26,7 @@ #include "generic.h" #include "clock.h" #include "sam9_smc.h" +#include "pm.h" /* -------------------------------------------------------------------- * Clocks @@ -330,6 +331,8 @@ static void __init at91sam9263_initialize(void) /* Register GPIO subsystem */ at91_gpio_init(at91sam9263_gpio, 5); + + at91_pm_set_standby(at91sam9263_standby); } /* -------------------------------------------------------------------- diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c index 474ee04..8460f52 100644 --- a/arch/arm/mach-at91/at91sam9g45.c +++ b/arch/arm/mach-at91/at91sam9g45.c @@ -26,6 +26,7 @@ #include "generic.h" #include "clock.h" #include "sam9_smc.h" +#include "pm.h" /* -------------------------------------------------------------------- * Clocks @@ -379,6 +380,8 @@ static void __init at91sam9g45_initialize(void) /* Register GPIO subsystem */ at91_gpio_init(at91sam9g45_gpio, 5); + + at91_pm_set_standby(at91sam9g45_standby); } /* -------------------------------------------------------------------- diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c index d4ec0d9..c7986e4 100644 --- a/arch/arm/mach-at91/at91sam9rl.c +++ b/arch/arm/mach-at91/at91sam9rl.c @@ -27,6 +27,7 @@ #include "generic.h" #include "clock.h" #include "sam9_smc.h" +#include "pm.h" /* -------------------------------------------------------------------- * Clocks @@ -296,6 +297,8 @@ static void __init at91sam9rl_initialize(void) /* Register GPIO subsystem */ at91_gpio_init(at91sam9rl_gpio, 4); + + at91_pm_set_standby(at91sam9_standby); } /* -------------------------------------------------------------------- diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c index 4ec6a6d..a077437 100644 --- a/arch/arm/mach-at91/cpuidle.c +++ b/arch/arm/mach-at91/cpuidle.c @@ -21,26 +21,17 @@ #include <linux/export.h> #include <asm/proc-fns.h> #include <asm/cpuidle.h> -#include <mach/cpu.h> - -#include "pm.h" #define AT91_MAX_STATES 2 +static void (*at91_standby)(void); + /* Actual code that puts the SoC in different idle states */ static int at91_enter_idle(struct cpuidle_device *dev, struct cpuidle_driver *drv, int index) { - if (cpu_is_at91rm9200()) - at91rm9200_standby(); - else if (cpu_is_at91sam9g45()) - at91sam9g45_standby(); - else if (cpu_is_at91sam9263()) - at91sam9263_standby(); - else - at91sam9_standby(); - + at91_standby(); return index; } @@ -60,9 +51,19 @@ static struct cpuidle_driver at91_idle_driver = { }; /* Initialize CPU idle by registering the idle states */ -static int __init at91_init_cpuidle(void) +static int at91_cpuidle_probe(struct platform_device *dev) { + at91_standby = (void *)(dev->dev.platform_data); + return cpuidle_register(&at91_idle_driver, NULL); } -device_initcall(at91_init_cpuidle); +static struct platform_driver at91_cpuidle_driver = { + .driver = { + .name = "cpuidle-at91", + .owner = THIS_MODULE, + }, + .probe = at91_cpuidle_probe, +}; + +module_platform_driver(at91_cpuidle_driver); diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c index 15afb5d..9986542 100644 --- a/arch/arm/mach-at91/pm.c +++ b/arch/arm/mach-at91/pm.c @@ -39,6 +39,8 @@ #include "at91_rstc.h" #include "at91_shdwc.h" +static void (*at91_pm_standby)(void); + static void __init show_reset_status(void) { static char reset[] __initdata = "reset"; @@ -266,14 +268,8 @@ static int at91_pm_enter(suspend_state_t state) * For ARM 926 based chips, this requirement is weaker * as at91sam9 can access a RAM in self-refresh mode. */ - if (cpu_is_at91rm9200()) - at91rm9200_standby(); - else if (cpu_is_at91sam9g45()) - at91sam9g45_standby(); - else if (cpu_is_at91sam9263()) - at91sam9263_standby(); - else - at91sam9_standby(); + if (at91_pm_standby) + at91_pm_standby(); break; case PM_SUSPEND_ON: @@ -314,6 +310,18 @@ static const struct platform_suspend_ops at91_pm_ops = { .end = at91_pm_end, }; +static struct platform_device at91_cpuidle_device = { + .name = "cpuidle-at91", +}; + +void at91_pm_set_standby(void (*at91_standby)(void)) +{ + if (at91_standby) { + at91_cpuidle_device.dev.platform_data = at91_standby; + at91_pm_standby = at91_standby; + } +} + static int __init at91_pm_init(void) { #ifdef CONFIG_AT91_SLOW_CLOCK @@ -325,6 +333,9 @@ static int __init at91_pm_init(void) /* AT91RM9200 SDRAM low-power mode cannot be used with self-refresh. */ if (cpu_is_at91rm9200()) at91_ramc_write(0, AT91RM9200_SDRAMC_LPR, 0); + + if (at91_cpuidle_device.dev.platform_data) + platform_device_register(&at91_cpuidle_device); suspend_set_ops(&at91_pm_ops); diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h index 2f5908f..76dd1a7 100644 --- a/arch/arm/mach-at91/pm.h +++ b/arch/arm/mach-at91/pm.h @@ -11,9 +11,13 @@ #ifndef __ARCH_ARM_MACH_AT91_PM #define __ARCH_ARM_MACH_AT91_PM +#include <asm/proc-fns.h> + #include <mach/at91_ramc.h> #include <mach/at91rm9200_sdramc.h> +extern void at91_pm_set_standby(void (*at91_standby)(void)); + /* * The AT91RM9200 goes into self-refresh mode with this command, and will * terminate self-refresh automatically on the next SDRAM access. -- 1.7.9.5

11 years, 10 months

[RFC PATCH 0/4] Big Endian support for ARM64 kernel

by Ankit Jindal

This patchset adds support for using Big Endian mode of AArch64 CPUs All patches have been tested on APM X-Gene Storm SOC. The Big Endian toolchain used for development can be found at: http://cbuild.validation.linaro.org/snapshots/big_endian We have tested both 32bit BE and 64bit BE root filesystems with these patches. The 64bit BE root filesystem was build manually using busybox-1.21.1 and above mentioned toolchain. The 32bit BE root filesystem was readily available from Linaro releases located at: http://snapshots.linaro.org/openembedded/images Ankit Jindal (4): ARM64: Add Kconfig option to enable Big Endian kernel ARM64: Include appropriate byteorder for Big Endian ARM64: Big Endian fixes for kernel booting ARM64: Support for 32-bit big endian userspace arch/arm64/Kconfig | 2 ++ arch/arm64/Makefile | 7 +++++++ arch/arm64/include/asm/assembler.h | 7 +++++++ arch/arm64/include/asm/processor.h | 3 +++ arch/arm64/include/uapi/asm/byteorder.h | 4 ++++ arch/arm64/kernel/head.S | 34 +++++++++++++++++++++++++++++++ arch/arm64/kernel/setup.c | 19 +++++++++++++---- arch/arm64/kernel/signal32.c | 4 ++++ arch/arm64/kernel/smp_spin_table.c | 5 +++-- arch/arm64/mm/Kconfig | 7 +++++++ arch/arm64/mm/proc.S | 2 +- 11 files changed, 87 insertions(+), 7 deletions(-) create mode 100644 arch/arm64/mm/Kconfig -- 1.7.9.5

11 years, 10 months

← Newer
1
...
8
9
10
11
12
13
14
...
23
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel October 2013