Re: Can't build correct kernel for 13.07 linaro-ubuntu on pandaboard
On 30 September 2013 02:54, Chao Xu caesarxuc...@gmail.com wrote: Hi, I tried to build linaro kernel for pandaboard. I have tried everything what I can think of but the kernel still can't boot correctly. Any help will be appreciated. Here is what I did: 1. I flash the 13.07 linaro-ubuntu-pandaboard image into the sd card (http://releases.linaro.org/13.07/ubuntu/panda). This image works fine. 2. I clone the kernel source code from git://git.linaro.org/kernel/linux-linaro-stable.git. 3. checkout the lsk 13.07 tag. 4. copy the config file from original image (i.e. /boot/config-3.10.1.0-1-linaro-omap). This can be trouble... if new, required config options that the kernel was tested with are somehow not on by default, you'll be missing them this way. Better to look at omap2plus_defconfig (make ARCH=arm omap2plus_defconfig ) from the new kernel, that's what people were actually using. 5. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- CFLAGS=-O LOADADDR=0x80008000 uImage The cross compiler on my machine is gcc-4.7-arm-linux-gnueabihf-base 6. From pandaboard, I load the built uImage via scp. The problem I met: 1. In most cases, the kernel can't boot correctly. And the terminal keeps printing hub 1-1:1.0: hub_port_status failed (err = -71). The hub error doesn't sound too terrible but can't boot correctly might not be good. Because of the way TI did things there are dependencies in their boot. Originally you had to worry about the right X-loader (MLO) with a compatible version of U-Boot which did the things that the particular version of the kernel you had wanted. Later they put X-loader into U-Boot tree, so those at least should be updated together, but the kernel still relies on the detail of what it expects to inherit from U-Boot in terms of PM actions (state of IP unit power) and other things. Ie, maybe update your U-Boot. They can get rid of this kind of issue by banning all unnecessary init from the bootloaders and forcing the kernel to assert whatever states it needs, but that proved impossible to coordinate / agree, although they made big strides with the kernel owning clocks properly at least. 2.Sometime, the kernel can finish booting. But the terminal prints for several times the aforementioned error message after booting. Plus, I don't have any module running, 'lsmod' shows nothing. Well for the modules you need to copy them over to your rootfs. I usually do something like this make ARCH=arm INSTALL_MOD_STRIP=1 modules_install INSTALL_MOD_PATH=`pwd`/staging then cp -rp or scp or rsync or whatever ./staging/* to / on the remote rootfs (it has /lib/modules/... in there). -Andy Please help! Thank you. -- Regards, Chao Xu ___ 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: Can't build correct kernel for 13.07 linaro-ubuntu on pandaboard
On 30 September 2013 09:52, Chao Xu caesarxuc...@gmail.com wrote: Thank you Andy! I tried with omap2plus_defconfig and the kernel seemed to be working, no more hub 1-1:1.0: hub_port_status failed (err = -71) so far. FWIW I don't think they are fatal errors for your boot anyway. If it was failing to boot it was probably something else. But I still don't understand why the config file copied from the /boot directory of a 13.07 linaro-ubuntu-pandaboard image doesn't work. I thought this was what linaro group used to compile the kernel. Could you explain a little more? Maybe the root cause is elsewhere (U-Boot version?) and omap2plus_defconfig simply disables the things that are broken by the root cause on your setup. So it only looks better. Another problem is the ethernet is still not working. Here is what I tried to debug this problem: 1. 'ifup eth0' replies 'Error getting hardware address for eth0: No such device'. 2. 'dmesg| grep eth' shows only this: usbcore: registered new interface driver cdc_ether. But on the stock linaro image, it shows a lot more: Seems no eth0, you can check with ifconfig -a [2.447448] usbcore: registered new interface driver cdc_ether [4.287170] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-1.1, smsc95xx U SB 2.0 Ethernet, 0e:60:7e:2a:4e:01 [ 21.024139] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 22.556945] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 22.557800] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1 [ 32.933746] eth0: no IPv6 3. Since smsc95xx is the eth driver, so I tried dmesg|grep 'smsc95xx', it shows: [1.830596] usbcore: registered new interface driver smsc95xx Yeah the driver is in but no usb device was probed. 4. I suspect it's still a usb problem, because 'lsusb' gives me 'unable to initialize libusb: -99. Could someone give me some suggestions? You're using the U-Boot that worked on the Linaro image that works? Linaro toolchain to build the kernel? Same U-Boot environment pieces, whatever they are nowadays, boot.scr, ini, txt etc Same MLO file from the working image? You copied your modules over as described? What's your power supply like? -Andy Thanks again. On Sun, Sep 29, 2013 at 7:21 PM, Andy Green andy.gr...@linaro.org wrote: On 30 September 2013 02:54, Chao Xu caesarxuc...@gmail.com wrote: Hi, I tried to build linaro kernel for pandaboard. I have tried everything what I can think of but the kernel still can't boot correctly. Any help will be appreciated. Here is what I did: 1. I flash the 13.07 linaro-ubuntu-pandaboard image into the sd card (http://releases.linaro.org/13.07/ubuntu/panda). This image works fine. 2. I clone the kernel source code from git://git.linaro.org/kernel/linux-linaro-stable.git. 3. checkout the lsk 13.07 tag. 4. copy the config file from original image (i.e. /boot/config-3.10.1.0-1-linaro-omap). This can be trouble... if new, required config options that the kernel was tested with are somehow not on by default, you'll be missing them this way. Better to look at omap2plus_defconfig (make ARCH=arm omap2plus_defconfig ) from the new kernel, that's what people were actually using. 5. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- CFLAGS=-O LOADADDR=0x80008000 uImage The cross compiler on my machine is gcc-4.7-arm-linux-gnueabihf-base 6. From pandaboard, I load the built uImage via scp. The problem I met: 1. In most cases, the kernel can't boot correctly. And the terminal keeps printing hub 1-1:1.0: hub_port_status failed (err = -71). The hub error doesn't sound too terrible but can't boot correctly might not be good. Because of the way TI did things there are dependencies in their boot. Originally you had to worry about the right X-loader (MLO) with a compatible version of U-Boot which did the things that the particular version of the kernel you had wanted. Later they put X-loader into U-Boot tree, so those at least should be updated together, but the kernel still relies on the detail of what it expects to inherit from U-Boot in terms of PM actions (state of IP unit power) and other things. Ie, maybe update your U-Boot. They can get rid of this kind of issue by banning all unnecessary init from the bootloaders and forcing the kernel to assert whatever states it needs, but that proved impossible to coordinate / agree, although they made big strides with the kernel owning clocks properly at least. 2.Sometime, the kernel can finish booting. But the terminal prints for several times the aforementioned error message after booting. Plus, I don't have any module running, 'lsmod' shows nothing. Well for the modules you need to copy them over to your rootfs. I usually do something like this make ARCH=arm INSTALL_MOD_STRIP=1 modules_install INSTALL_MOD_PATH=`pwd`/staging then cp -rp or scp or rsync or whatever ./staging
Re: Does linux-linaro support kernel page size bigger than 4K?
On 10 September 2013 05:46, Subash Patel subas...@gmail.com wrote: Hi Xu, Qiang, I doubt if it has anything todo with linaro kernel. ARM linux code is programming the page sizes as 4K. Steve Capper sent out some cool patches for Transparent Huge Pagetables http://lists.linaro.org/pipermail/linaro-kernel/2013-August/006574.html They applied fine to linux-linaro-core-tracking and seem to work. If you want to change the whole kernel to hugepages, you have to recook or meddle your rootfs with a library preload. But those patches just hide huge pages in linear allocations of smaller pages, so nobody notices. -Andy From my experience playing with the page tables, you will have to fiddle with the section size and page size programming in the ARM mmu initialization. Depending on kernel split, you store the page table pointers in TTBR0 and TTBR1, which point to 1MB sections each. The entries here are marked to point to 4k pages, You will have to change them to point to 64K. I don't know someone who has tried huge pages(64K) in public domain for v7 yet. Note: Theoretically it should be possible for the kernel to work with 4K pages, and user space to allocate 64K pages. It is a messy change (as it involves changes to process management as well) Even I am interested to explore more on this. But tied up with something else at the moment :( Regards, Subash On Wed, Aug 28, 2013 at 12:05 AM, Xu, Qiang qian...@qti.qualcomm.com wrote: Hi Linaro I am a software engineer from Qualcomm. I want to know that if Linaro can change its memory page size in kernel ? As my CPU is arm-v7, it supports 4k/64k/1M/16M page size translation, but in my linux kernel whose version is 2.6.38, the page size is always 4K, Do the linux-linaro support different page size in kernel? ___ 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: Panda, Android Bluetooth
On 18 August 2013 14:41, Fathi Boudra fathi.bou...@linaro.org wrote: Hey Mike, On 17 August 2013 20:07, Mike Turquette mturque...@linaro.org wrote: On Thu, Aug 15, 2013 at 6:02 PM, Andy Green andy.gr...@linaro.org wrote: On 16 August 2013 08:22, Mike Turquette mturque...@linaro.org wrote: Hi all, I'm interested in looking at some Bluetooth stuff on my OMAP 4460 Panda ES. Looking at the bug reports I don't see any Jelly Bean releases that have BT working properly on Panda. Is this correct? Can you please point me to a release where BT and display/hdmi are working for Panda? It's OK if it is ICS. I'm OK starting with binaries but I would much prefer to be able to build from source and reproduce any known-good bins. I have already built JB from the latest tip as well as the 13.07 manifest (display is working fine but BT doesn't work, bugs already filed). I tried the 12.07 Panda LEB (which I think was the last ICS release?) but the binaries supplied did not have display working even after running the install-binaries-4.0.4.sh script. Nicolas Dechesne may be able to help more directly, but mainline BT was never workable reliably on Panda. That's disappointing since an article on omappedia references the Linaro release and says, Note: Wifi, bluetooth, YouTube, jpeg, video playback (both .mp4 and .3gp), and audio playback (both .mp3 and .aac) all have been verified as working in this release. You can see it here: http://www.omappedia.com/wiki/Android_Panda_Build_Source#Building_from_Linaro What about asking Linaro guys that actually produce this build? Looking at our test results, the bluetooth test failed in 12.07 release. A bug has been opened at that time: https://bugs.launchpad.net/linaro-android/+bug/987765 Adding Vishal in CC, who's probably know the bluetooth status in Linaro Android builds better than me. Mike's saying even video didn't work when he tried that. Reading that bug it sounds like a firmware issue in the image. I say in the bug it's working on kernel side at that time. However like the video problem, it sort of hinges on the meaning of working. HDMI and DVI on Panda have worked to some extent for a long while. But they've never worked properly dual-head and in fact because they share a PLL for the pixel clock, they'll never work outside of special conditions like same monitor and resolution. Last I saw of it there's a behaviour in HDMI hotlug detect handling in the driver that means some monitors won't be seen as plugged, because they delay sending hpd by up to 1s (I have one of these monitors). The code in the Panda release was forward-ported from 3.0 DSS stack on omapzoom (since that's the only thing TI had on offer with working Android SGX) and that deviates hugely from mainline DSS, so any improvements in this area didn't get transplanted. Bluetooth is similar on mainline basis, it was able to work for a while but when hammered it fell over. -Andy The p-android stuff on omapzoom was meant to have numerous patches that actually made it work. At one point we talked to some guys from TI and got some patches, however they were patches against p-android-3.0 that not only did not apply on mainline but were 100% patching code that anyway did not exist in mainline, so we got literally nowhere with it. The p-android stuff are busy history trees, so it is very hard to extract a coherent series that fixes bluetooth. Even to do direct diffs at file level isn't easy since the files have all moved around and the 3.0 one we know worked is radically different than current mainline anyway. Some of the issues were down to PM related stuff and the p-android arrangements for that bear no relationship to mainline. Anyway Nicolas may know more, but the best bet may be to find a TI Alumni who worked on it and get the skinny. Nicolas, any inputs? Thanks, Mike -Andy Thanks, Mike Cheers, -- Fathi Boudra Builds and Baselines Manager | Release Manager Linaro.org | Open source software for ARM SoCs ___ 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: Panda, Android Bluetooth
On 16 August 2013 08:22, Mike Turquette mturque...@linaro.org wrote: Hi all, I'm interested in looking at some Bluetooth stuff on my OMAP 4460 Panda ES. Looking at the bug reports I don't see any Jelly Bean releases that have BT working properly on Panda. Is this correct? Can you please point me to a release where BT and display/hdmi are working for Panda? It's OK if it is ICS. I'm OK starting with binaries but I would much prefer to be able to build from source and reproduce any known-good bins. I have already built JB from the latest tip as well as the 13.07 manifest (display is working fine but BT doesn't work, bugs already filed). I tried the 12.07 Panda LEB (which I think was the last ICS release?) but the binaries supplied did not have display working even after running the install-binaries-4.0.4.sh script. Nicolas Dechesne may be able to help more directly, but mainline BT was never workable reliably on Panda. The p-android stuff on omapzoom was meant to have numerous patches that actually made it work. At one point we talked to some guys from TI and got some patches, however they were patches against p-android-3.0 that not only did not apply on mainline but were 100% patching code that anyway did not exist in mainline, so we got literally nowhere with it. The p-android stuff are busy history trees, so it is very hard to extract a coherent series that fixes bluetooth. Even to do direct diffs at file level isn't easy since the files have all moved around and the 3.0 one we know worked is radically different than current mainline anyway. Some of the issues were down to PM related stuff and the p-android arrangements for that bear no relationship to mainline. Anyway Nicolas may know more, but the best bet may be to find a TI Alumni who worked on it and get the skinny. -Andy Thanks, Mike ___ 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: [PATCH 2 0/2] RFC: introduce arch_early_time for early boot timestamps
On 14 August 2013 03:08, Deepak Saxena dsax...@linaro.org wrote: Idea is good though one note on this is that the DT binding is very Linux-specific and there is a move away from OS-specific bindings. I see... yes I read rumblings about this. I have an idea how to rearrange the DT bits to solve that objection I think. You'll have to repost to a wider audience including the new DT binding maintainers to get their input. You also need to add the binding to Documentation/devicetree/bindings regardless of what the final binding is. Yes, will do. Thanks for the input. -Andy ~Deepak On 9 August 2013 07:34, Andy Green andy.gr...@linaro.org wrote: The following patches extend accurate time much further back into the boot process by adding an optional arch_early_time source that starts counting about 1.75ms after the MMU is enabled. This exposes currently hidden kernel boot times exceeding 340ms for a 2GByte dual A9. Currently only Arm globaltimer is supported as the early time source. Where the globaltimer is and how to map it is configured by Device Tree as explained in the second patch. To get monotonic time in the kernel starting from before the normal time source can be initialized, the early time source offset is allowed to be added to scheduler clock time in the first patch. --- Andy Green (2): scheduler: time: allow arch-specific time offset function arm: time: add globaltimer-based arch_early_time arch/arm/Kconfig | 16 ++ arch/arm/Kconfig.debug | 10 arch/arm/boot/dts/mb8ac0300eb.dts | 10 +++- arch/arm/configs/fujitsu_defconfig |2 + arch/arm/include/asm/memory.h |8 +++ arch/arm/kernel/devtree.c |1 arch/arm/kernel/setup.c| 50 ++ arch/arm/kernel/time.c | 101 arch/arm/mach-mb8ac0300/Kconfig|3 + arch/arm/mm/mmu.c | 49 + include/linux/time.h |7 ++ kernel/sched/clock.c | 12 ++-- mm/Kconfig |2 - 13 files changed, 263 insertions(+), 8 deletions(-) -- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Deepak Saxena - Kernel Working Group Lead Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2 2/2] arm: time: add globaltimer-based arch_early_time
: 0x80284000 - 0x802a0cc0 ( 116 kB)
[0.336248].bss : 0x802a0cc0 - 0x802ddab4 ( 244 kB)
[0.336493] Preemptible hierarchical RCU implementation.
[0.336506] Dump stacks of tasks blocking RCU-preempt GP.
[0.336518] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
[0.336555] NR_IRQS:16 nr_irqs:16 16
[0.344257] sched_clock: 32 bits at 41MHz, resolution 24ns, wraps every
103727ms
[0.344788] Console: colour dummy device 80x30
[0.344985] console [tty0] enabled
[0.345045] Calibrating delay loop... 1318.91 BogoMIPS (lpj=6594560)
when normal time starts, it is offset by the corresponding early time, so the
logs are
monotonic and consistent in time.
To use enable
CONFIG_EARLY_TIME_ARM_GLOBALTIMER=y
A Device Tree stanza like this should be added to the top level description.
The first reg / size pair is the physical address and the second pair the
virtual address.
early-time {
compatible = arm,globaltimer;
reg = 0xf810 0x1000, 0xfd10 0x1000;
freq = 16550;
zero = 1;
cpumask = 3;
};
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/Kconfig |4 +
arch/arm/Kconfig.debug| 10
arch/arm/boot/dts/mb8ac0300eb.dts |8 +++
arch/arm/kernel/time.c| 101 +
arch/arm/mm/mmu.c | 49 ++
5 files changed, 172 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f3f4bcf..a3b1d75 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2311,6 +2311,10 @@ config ARM_CPU_SUSPEND
endmenu
+config HAS_ARCH_EARLY_TIME
+ bool
+ default n
+
source net/Kconfig
source drivers/Kconfig
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index de41088..10b4249 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -900,4 +900,14 @@ config PID_IN_CONTEXTIDR
additional instructions during context switch. Say Y here only if you
are planning to use hardware trace tools with this kernel.
+config EARLY_TIME_ARM_GLOBALTIMER
+ bool Enable early Arm globaltimer support
+ default n
+ select HAS_ARCH_EARLY_TIME
+ help
+ If you have a spare globaltimer in your SoC, you can use it to
+ get accurate log timings starting from very early in boot and
+ before the very first log entry.
+ You'll need to speify some additional gnarly details if enabled.
+
endmenu
diff --git a/arch/arm/boot/dts/mb8ac0300eb.dts
b/arch/arm/boot/dts/mb8ac0300eb.dts
index 76878d6..875649b 100644
--- a/arch/arm/boot/dts/mb8ac0300eb.dts
+++ b/arch/arm/boot/dts/mb8ac0300eb.dts
@@ -29,6 +29,14 @@
linux,initrd-end = 0;
};
+ early-time {
+ compatible = arm,globaltimer;
+ reg = 0xf810 0x1000, 0xfd10 0x1000;
+ freq = 16550;
+ zero = 1;
+ cpumask = 3;
+ };
+
alsa: mb8ac0300_adau1361 {
compatible = fujitsu,mb8ac0300_adau1361;
channel = 0;
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 98aee32..37b570f 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -25,11 +25,15 @@
#include linux/clocksource.h
#include linux/irq.h
#include linux/sched_clock.h
+#include linux/of_fdt.h
#include asm/thread_info.h
#include asm/stacktrace.h
#include asm/mach/arch.h
#include asm/mach/time.h
+#include asm/mach/map.h
+#include asm/io.h
+#include asm/div64.h
#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) || \
defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE)
@@ -121,3 +125,100 @@ void __init time_init(void)
else
clocksource_of_init();
}
+
+#ifdef CONFIG_EARLY_TIME_ARM_GLOBALTIMER
+
+static void __iomem *etagt_base;
+static u32 etagt_ps;
+
+#define GLOBALTIMER_CPU_ACCESS_OFS 0x54
+#define GLOBALTIMER_LOW_OFS 0x200
+#define GLOBALTIMER_HIGH_OFS 0x204
+#define GLOBALTIMER_ENABLE_OFS 0x208
+
+void arch_early_time_init(unsigned long node)
+{
+ const u32 *reg;
+ const u32 *freq;
+ const u32 *zero;
+ const u32 *cpumask;
+ unsigned long l;
+ u64 ps = 10240ull;
+
+ /* already checked by caller */
+ reg = of_get_flat_dt_prop(node, reg, l);
+ etagt_base = (void __iomem *)be32_to_cpu(reg[2]);
+
+ freq = of_get_flat_dt_prop(node, freq, l);
+ if (!freq || l != 4) {
+ pr_err(%s NULL freq or len %lu\n, __func__, l);
+ return;
+ }
+
+ zero = of_get_flat_dt_prop(node, zero, l);
+ if (!zero)
+ return;
+
+ cpumask = of_get_flat_dt_prop(node, cpumask, l);
+ if (!cpumask)
+ return;
+
+ do_div(ps, be32_to_cpu(*freq));
+ etagt_ps = (u32)ps;
+
+ __raw_writel(be32_to_cpu(*cpumask),
+ etagt_base
[PATCH 2 0/2] RFC: introduce arch_early_time for early boot timestamps
The following patches extend accurate time much further back into the boot process by adding an optional arch_early_time source that starts counting about 1.75ms after the MMU is enabled. This exposes currently hidden kernel boot times exceeding 340ms for a 2GByte dual A9. Currently only Arm globaltimer is supported as the early time source. Where the globaltimer is and how to map it is configured by Device Tree as explained in the second patch. To get monotonic time in the kernel starting from before the normal time source can be initialized, the early time source offset is allowed to be added to scheduler clock time in the first patch. --- Andy Green (2): scheduler: time: allow arch-specific time offset function arm: time: add globaltimer-based arch_early_time arch/arm/Kconfig | 16 ++ arch/arm/Kconfig.debug | 10 arch/arm/boot/dts/mb8ac0300eb.dts | 10 +++- arch/arm/configs/fujitsu_defconfig |2 + arch/arm/include/asm/memory.h |8 +++ arch/arm/kernel/devtree.c |1 arch/arm/kernel/setup.c| 50 ++ arch/arm/kernel/time.c | 101 arch/arm/mach-mb8ac0300/Kconfig|3 + arch/arm/mm/mmu.c | 49 + include/linux/time.h |7 ++ kernel/sched/clock.c | 12 ++-- mm/Kconfig |2 - 13 files changed, 263 insertions(+), 8 deletions(-) -- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2 1/2] scheduler: time: allow arch-specific time offset function
This introduces an optional arch_early_time() which by default doesn't exist and
doesn't cause any extra code to be generated.
If it is configured and declared though, it can be used in an architecture or
platform-specific way to provide time during early boot.
After early boot when normal time is available, it can stop counting and just
add its offset, so time in the boot is monotonic.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
include/linux/time.h |7 +++
kernel/sched/clock.c | 12 ++--
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/include/linux/time.h b/include/linux/time.h
index d5d229b..06fbb61 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -181,6 +181,13 @@ extern s32 timekeeping_get_tai_offset(void);
extern void timekeeping_set_tai_offset(s32 tai_offset);
extern void timekeeping_clocktai(struct timespec *ts);
+#ifdef CONFIG_HAS_ARCH_EARLY_TIME
+extern void arch_early_time_init(unsigned long node);
+extern u64 arch_early_time(u64 normal);
+#else
+#define arch_early_time(_x) ((u64)_x)
+#endif
+
struct tms;
extern void do_sys_times(struct tms *);
diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
index c3ae144..04b0490 100644
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -245,10 +245,10 @@ u64 sched_clock_cpu(int cpu)
WARN_ON_ONCE(!irqs_disabled());
if (sched_clock_stable)
- return sched_clock();
+ return arch_early_time(sched_clock());
if (unlikely(!sched_clock_running))
- return 0ull;
+ return arch_early_time(0);
scd = cpu_sdc(cpu);
@@ -257,7 +257,7 @@ u64 sched_clock_cpu(int cpu)
else
clock = sched_clock_local(scd);
- return clock;
+ return arch_early_time(clock);
}
void sched_clock_tick(void)
@@ -339,7 +339,7 @@ u64 local_clock(void)
unsigned long flags;
local_irq_save(flags);
- clock = sched_clock_cpu(smp_processor_id());
+ clock = arch_early_time(sched_clock_cpu(smp_processor_id()));
local_irq_restore(flags);
return clock;
@@ -355,9 +355,9 @@ void sched_clock_init(void)
u64 sched_clock_cpu(int cpu)
{
if (unlikely(!sched_clock_running))
- return 0;
+ return arch_early_time(0);
- return sched_clock();
+ return arch_early_time(sched_clock());
}
u64 cpu_clock(int cpu)
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/2] RFC: introduce arch_early_time for early boot timestamps
On 8 August 2013 17:35, Peter Maydell peter.mayd...@linaro.org wrote: On 8 August 2013 03:44, Andy Green andy.gr...@linaro.org wrote: These patches give accurate, monotonic timestamps from the very first log entry allowing insight into where the time is going during the whole of the boot process. It's a debug feature like DEBUG_LL, it does not cooperate with ARCH_MULTIPLATFORM (it works with such a kernel though) but can only be enabled for a single platform at compile-time. I think this kind of only-one-platform compile-time-set feature is definitely going in the wrong direction, even for a debug feature. It's bad enough that DEBUG_LL works like that. Yes it's doing the same thing as DEBUG_LL. DEBUG_LL hides things in a per-platform assembler file in addition to config. Can't you put the relevant information into the device tree so that it works on multiplatform kernels? That's the way the kernel's chosen to store its this is the config for this platform data, after all... I assumed if it could be done, DEBUG_LL would be doing it. It's starting time in assembler before the MMU is switched on. I don't think there's any existing code for walking the dtb at that time. Maybe it can start time a bit later after MMU and use the early dtb walking bits, I'll take a look but it's not a normal situation and may not have a normal solution. -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/2] RFC: introduce arch_early_time for early boot timestamps
On 8 August 2013 18:50, Peter Maydell peter.mayd...@linaro.org wrote:
On 8 August 2013 11:23, Andy Green andy.gr...@linaro.org wrote:
On 8 August 2013 17:35, Peter Maydell peter.mayd...@linaro.org wrote
Can't you put the relevant information into the device tree
so that it works on multiplatform kernels? That's the way
the kernel's chosen to store its this is the config for
this platform data, after all...
I assumed if it could be done, DEBUG_LL would be doing it.
I think DEBUG_LL should also be doing it. The virtualization
team is going to be looking into this, because we really don't
want to have lots of people trying to start VMs and coming
back with I get no output bug reports :-)
Well good luck it looks like a bigger job.
I can see how to get it from the flat device tree by adding properties
to chosen { } and riding on early_init_dt_scan_chosen() easily enough.
From the results I have already I know on this platform that's ~500us
after where we set it up at the moment, which is not really hurting.
So I'll give that a go, thanks for the advice.
-Andy
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/2] arm: time: add globaltimer-based arch_early_time
init, 236K bss, 71044K reserved, 0K highmem) [0.040750] Virtual kernel memory layout: [0.040750] vector : 0x - 0x1000 ( 4 kB) [0.040750] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.040750] vmalloc : 0x9080 - 0xff00 (1768 MB) [0.040750] lowmem : 0x8000 - 0x9000 ( 256 MB) [0.040750] pkmap : 0x7fe0 - 0x8000 ( 2 MB) [0.040750] modules : 0x7f80 - 0x7fe0 ( 6 MB) [0.040750] .text : 0x80008000 - 0x8026cb28 (2451 kB) [0.040750] .init : 0x8026d000 - 0x80287c80 ( 108 kB) [0.040750] .data : 0x80288000 - 0x802a4ca0 ( 116 kB) [0.040750].bss : 0x802a4ca0 - 0x802dff74 ( 237 kB) [0.040997] Preemptible hierarchical RCU implementation. [0.041010] Dump stacks of tasks blocking RCU-preempt GP. [0.041022] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2. [0.041059] NR_IRQS:16 nr_irqs:16 16 [0.048966] sched_clock: 32 bits at 41MHz, resolution 24ns, wraps every 103727ms [0.049495] Console: colour dummy device 80x30 [0.049688] console [tty0] enabled [0.050483] Calibrating delay loop... 1318.91 BogoMIPS (lpj=6594560) [0.138981] pid_max: default: 32768 minimum: 301 ... when normal time starts, it is offset by the corresponding early time, so the logs are monotonic and consistent in time. Like DEBUG_LL it's not compatible with ARCH_MULTIPLATFORM and not designed to be on by default, it's a debugging aid for studying where the real time is going during early kernel boot. If you have a globaltimer on your SoC, to use it set CONFIG_EARLY_TIME_ARM_GLOBALTIMER=y and ..._PHYS to the base address of the SoC region that contains the globaltimer at +0x200. ..._VIRT needs to be set to somewhere in the static virtual mapping region where it won't step on anything: if you already have a static virtual mapping for this area you can re-use the static mapping virtual address here. ..._FREQ needs to be the clock rate of the globaltimer clock in Hz. Normally you want to enable ..._ZERO, however it's configurable because you may also start the globaltimer in your bootloader, which will let you measure the total time from that to events in the kernel boot flow. For example: CONFIG_EARLY_TIME_ARM_GLOBALTIMER=y CONFIG_EARLY_TIME_ARM_GLOBALTIMER_ZERO=y CONFIG_EARLY_TIME_ARM_GLOBALTIMER_PHYS=0xf810 CONFIG_EARLY_TIME_ARM_GLOBALTIMER_VIRT=0xfd10 CONFIG_EARLY_TIME_ARM_GLOBALTIMER_FREQ=16550 Signed-off-by: Andy Green andy.gr...@linaro.org --- arch/arm/Kconfig |4 +++ arch/arm/Kconfig.debug | 35 ++ arch/arm/kernel/head.S | 65 arch/arm/kernel/time.c | 41 ++ 4 files changed, 145 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f3f4bcf..a3b1d75 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -2311,6 +2311,10 @@ config ARM_CPU_SUSPEND endmenu +config HAS_ARCH_EARLY_TIME + bool + default n + source net/Kconfig source drivers/Kconfig diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index de41088..e3a6570 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -900,4 +900,39 @@ config PID_IN_CONTEXTIDR additional instructions during context switch. Say Y here only if you are planning to use hardware trace tools with this kernel. +config EARLY_TIME_ARM_GLOBALTIMER + bool Enable early Arm globaltimer support + default n + select HAS_ARCH_EARLY_TIME + help + If you have a spare globaltimer in your SoC, you can use it to + get accurate log timings starting from very early in boot and + before the very first log entry. + You'll need to speify some additional gnarly details if enabled. + +config EARLY_TIME_ARM_GLOBALTIMER_ZERO + bool zeroing the globaltimer early in boot + depends on EARLY_TIME_ARM_GLOBALTIMER + default y + help + If you started the globaltimer in your bootloader, you can disable + this to stop the kernel code zeroing the timer. Then your logs + will reflect time from the point it was zeroed in the bootloader. + But normally, you want to see time from very early in kernel boot. + +config EARLY_TIME_ARM_GLOBALTIMER_PHYS + hex Physical address of your globaltimer + depends on EARLY_TIME_ARM_GLOBALTIMER + +config EARLY_TIME_ARM_GLOBALTIMER_VIRT + hex Virtual mapping address of your globaltimer + depends on EARLY_TIME_ARM_GLOBALTIMER + help + This shoud match a static mapping so the timer can be used + seamlessly after the static mappings are set up + +config EARLY_TIME_ARM_GLOBALTIMER_FREQ + int Frequency of your globaltimer in Hz + depends on EARLY_TIME_ARM_GLOBALTIMER + endmenu diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S index
[PATCH 1/2] scheduler: time: allow arch-specific time offset function
This introduces an optional arch_early_time() which by default doesn't exist and
doesn't cause any extra code to be generated.
If it is configured and declared though, it can be used in an architecture or
platform-specific way to provide time during early boot.
After early boot when normal time is available, it can stop counting and just
add its offset, so time in the boot is monotonic.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
include/linux/time.h |6 ++
kernel/sched/clock.c | 12 ++--
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/include/linux/time.h b/include/linux/time.h
index d5d229b..57dc58e 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -181,6 +181,12 @@ extern s32 timekeeping_get_tai_offset(void);
extern void timekeeping_set_tai_offset(s32 tai_offset);
extern void timekeeping_clocktai(struct timespec *ts);
+#ifdef CONFIG_HAS_ARCH_EARLY_TIME
+extern u64 arch_early_time(u64 normal);
+#else
+#define arch_early_time(_x) ((u64)_x)
+#endif
+
struct tms;
extern void do_sys_times(struct tms *);
diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
index c3ae144..04b0490 100644
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -245,10 +245,10 @@ u64 sched_clock_cpu(int cpu)
WARN_ON_ONCE(!irqs_disabled());
if (sched_clock_stable)
- return sched_clock();
+ return arch_early_time(sched_clock());
if (unlikely(!sched_clock_running))
- return 0ull;
+ return arch_early_time(0);
scd = cpu_sdc(cpu);
@@ -257,7 +257,7 @@ u64 sched_clock_cpu(int cpu)
else
clock = sched_clock_local(scd);
- return clock;
+ return arch_early_time(clock);
}
void sched_clock_tick(void)
@@ -339,7 +339,7 @@ u64 local_clock(void)
unsigned long flags;
local_irq_save(flags);
- clock = sched_clock_cpu(smp_processor_id());
+ clock = arch_early_time(sched_clock_cpu(smp_processor_id()));
local_irq_restore(flags);
return clock;
@@ -355,9 +355,9 @@ void sched_clock_init(void)
u64 sched_clock_cpu(int cpu)
{
if (unlikely(!sched_clock_running))
- return 0;
+ return arch_early_time(0);
- return sched_clock();
+ return arch_early_time(sched_clock());
}
u64 cpu_clock(int cpu)
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 0/2] RFC: introduce arch_early_time for early boot timestamps
The following patches introduce a debug feature, accurate timestamps on all kernel logs during boot. At the moment until time is set up in the kernel, all logs are timestamped [0.00] giving the impression these early boot activities have no duration. That's far from the case. These patches give accurate, monotonic timestamps from the very first log entry allowing insight into where the time is going during the whole of the boot process. It's a debug feature like DEBUG_LL, it does not cooperate with ARCH_MULTIPLATFORM (it works with such a kernel though) but can only be enabled for a single platform at compile-time. To use it, you need an ARM SoC with a globaltimer, which is very common now. Even if the globaltimer is used by the kernel, we can use it in early boot and stop using it as soon as a normal time source is set up, so there's no conflict. There are more details on how to use it and examples of the results in the second patch. --- Andy Green (2): scheduler: time: allow arch-specific time offset function arm: time: add globaltimer-based arch_early_time arch/arm/Kconfig |4 +++ arch/arm/Kconfig.debug | 35 ++ arch/arm/kernel/head.S | 65 arch/arm/kernel/time.c | 41 ++ include/linux/time.h |6 kernel/sched/clock.c | 12 - 6 files changed, 157 insertions(+), 6 deletions(-) -- ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LSK getting started
On 6 August 2013 20:47, Mark Brown broo...@kernel.org wrote: On Tue, Aug 06, 2013 at 08:24:52AM +0800, Andy Green wrote: I went through and split out the fixes after examining each one. Please submit things normally - attachments are non-standard and difficult to work with (both from the point of view of applying and from the point of view of workflow) and if you don't mention them they're not always terribly visible either. I didn't actually notice there was anything here first time around... I wonder why Google has an attachment button. If you do send attachments keep them as text/plain so that things like quoting in replies work. Bad google. 4) warning-elimination: ata: ata_hpa_resize default assignment Issue is upstream but I can't reproduce original compiler warning If the compiler figures it out we can probably drop this then. If it is still needed then it should be being submitted upstream. Yes it's strange though I did not have a stroke and start editing code randomly, this was generating an error in the recent past. 6) warning-elimination: nobody uses cci_pmu_destroy Presumably coming from the CCI stuff Tixy pulled in I'll apply this but please do send it to the ARM LT, we should be fixing this stuff in linux-linaro too. Tixy's on the list and hopefully able to process these newfangled attachments with his steampunk email client. 7) warning-elimination: regmap: cast pointer arg from int This seems to be a genuine issue of passing an int to a function wanting a const void *. However I can't reproduce the warning. This looks like you had a compiler bug or were carrying some other breakage; val is a pointer so we're just doing pointer arithmetic here, there's no casting needed and if there were the cast you're adding should be on val not on the final result. At the time it generated an warning it silenced it. I can see it's reasonable to ignore it when it isn't any longer, so fair enough. I have not updated my toolchain since March, so whatever changed is in the larger set of code, eg, headers, there's definitely something curious about the fixes that still apply but no longer genenrate the warning that got them fixed when the fix is removed. I noticed on 3.11-rc3 there's a make option W=? that I didn't see before, don't know when it was introduced. Maybe there has been some fiddling with gcc commandline at make level that impacts what's reported. As I say the toolchain is no different only thing that changed is the code as a whole. 8) warning-elimination: usb: dwc3 This only made problems if you have CONFIG_PM but not CONFIG_SUSPEND, dunno if people care or not. This should certainly be addressed upstream, please submit it. 1 4, and 8 I doubt anyone will buy upstream, but you should still consider 1. 4 can't be demonstrated to be a problem right now (although it has been...) 8 we turned on SUSPEND ourselves since it was a problem. Please use descriptive names for things rather than just numbers, it makes everything more legible. Except for the THUMB thing I don't see why any of these shouldn't be upstream - what makes you believe that there would be a problem? Hm you know the dynamic of people submitting things for your critique is not the only conversational mode that's possible, has that crossed your mind? -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LSK getting started
On Aug 6, 2013 11:06 PM, Jon Medhurst (Tixy) t...@linaro.org wrote: On Tue, 2013-08-06 at 21:12 +0800, Andy Green wrote: On 6 August 2013 20:47, Mark Brown broo...@kernel.org wrote: On Tue, Aug 06, 2013 at 08:24:52AM +0800, Andy Green wrote: 6) warning-elimination: nobody uses cci_pmu_destroy Presumably coming from the CCI stuff Tixy pulled in I'll apply this but please do send it to the ARM LT, we should be fixing this stuff in linux-linaro too. Tixy's on the list and hopefully able to process these newfangled attachments with his steampunk email client. I'd mostly stopped reading this thread but somehow managed to notice this. A proper mailed patch to the list, or a quick mail to me would have been more obvious ;-) I went back to the the original mail and Yes fair enough. I can just see the mail telling me to post them on linaro-kernel though. scrolled down to the bottom to find the attachments in my steampunk email client, and I'll add that to my CCI topic branch. Thanks. The PMU support is a Frankenstein creation cobbled together from previous patches and intended to keep CCI support in Gator working. There are newer patches on the upstream lists which may break things again, but I've sorta stopped pro-actively trying to keep my branches up-to-date with latest work, as I don't seem to have the time any more and it seems a forlorn task. Especially as a lot of it seems under constant churn as people ague about how things should look. Best to just wait for it to turn up in mainline and deal with it them. That may not be a bad approach. There were those patches a while back that killed various things like perf that crept in llct, it's a sign that unless there's some pedigree or direct support behind where the series came from it might be better to be without them. -Andy -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LSK getting started
On 5 August 2013 10:45, Andy Green andy.gr...@linaro.org wrote: Hi Mark - I have some small practical questions about LSK. I was able to make a tree with our linux-linaro-core-tracking@v3.10 LT patches on LSK basis work well (so far). I found this repo (it needs its ./description updating) https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git;a=summary 1) There seems to be two choices, linux-linaro-lsk and linux-linaro-lsk-android. I chose the android one, I assume it has the same androidization series on top that linux-linaro-core-tracking used at 3.10? Are there any other differences? 2) I saw the vexpress integration stuff from ARM LT was included already which is good, is there a wiki page (or README.html or the gitweb is also good) explaining the composition? 3) In our LT tree we patch mainline to remove all warnings coming with our defconfig. Then if we see any warnings coming, we know it's our fault and we need to go fix it. Are you interested in taking a similar approach? 4) Maybe this is too much thinking ahead, but shouldn't these lsk branches be versioned, like linux-linaro-lsk-3.10? Otherwise when the next lsk version is announced there'll be a problem. 5) Gator bits don't seem to be in there, presumably that's something ARM would like to see in there (it appears in llct) http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0482a/BABEJAAI.html https://git.linaro.org/gitweb?p=landing-teams/working/arm/kernel.git;a=shortlog;h=refs/heads/3.10-armlt-gator-5.15 -Andy -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LSK getting started
On 5 August 2013 16:58, Jon Medhurst (Tixy) t...@linaro.org wrote: On Mon, 2013-08-05 at 10:45 +0800, Andy Green wrote: 2) I saw the vexpress integration stuff from ARM LT was included already which is good, is there a wiki page (or README.html or the gitweb is also good) explaining the composition? The vexpress branch is basicall the same as what is in linux-linaro for the 13.07 release. I always merge my topics one at a time with --no-ff so it's easier to see how a branch is composed. A brief one line summary Right, it's much clearer that way. I was really asking about composition of what's in LSK, since for your and Andrey's tracking / rebase + merge branches I can look at the log and see. But LSK will have a linear history, it's already hard to see what's in there without log --graph. However this is very useful documentation -- for each is... tracking-armlt-config vexpress config fragments tracking-armlt-rtsm Device-tree updates for RTSM tracking-armlt-ve-updates Miscellaneous fixes for vexpress. tracking-armlt-hdlcd HDCLCD driver (TC2's video hardware). tracking-armlt-clcd Modifications to CLCD driver to work with device-tree, needed for fast models. tracking-armlt-misc-fixes Miscellaneous fixes useful for vexpress and TC2 but not necessarily to vexpress specific code. tracking-armlt-tc2-dt TC2 device-tree updates. tracking-armlt-mcpm Tweaks to the MCPM code which aren't upstream. tracking-armlt-cci CCI driver and CCI PMU patches. We started using that the other day trying to track down a nasty bug, I didn't even know we got it from vexpress ^^ The whole list is good things to have I just wonder how ongoing updates will be handled for backport. For example at some point Tweaks to the MCPM code which aren't upstream. will go upstream and probably be a bit different by then, someone should revert (it may not be that clean since other patches may have meddled) the old one in lsk and replace with the upstream patches. Mark's watching out for that, or you are for the trees you merged that went into LSK, or what's the plan? -Andy tracking-armlt-spc vexpress Serial Power Controller (SPC) present in ARM Versatile Express TC2 core tiles. tracking-armlt-psci PSCI changes to enable run time selection of PSCI. tracking-armlt-dcscb Tweaks to the DCSCB code (RTSM's cluster control) which aren't upstream. tracking-armlt-tc2-pm TC2 PM functions and big.LITTLE cpuidle driver. tracking-armlt-tc2-psci Updates TC2 PM functions to use PSCI. This topic is stacked on top of -tc2-pm as it modifies it. tracking-armlt-tc2-cpufreq big.LITTLE cpufreq driver for vexpress. tracking-armlt-iks-cpufreq IKS cpufreq driver. The latter is probably not vexpress specific, I just inherited it because no-one else was handling it. -- Tixy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LSK getting started
On 5 August 2013 18:00, Jon Medhurst (Tixy) t...@linaro.org wrote: On Mon, 2013-08-05 at 10:53 +0100, Mark Brown wrote: On 5 August 2013 10:44, Jon Medhurst (Tixy) t...@linaro.org wrote: On Mon, 2013-08-05 at 17:13 +0800, Andy Green wrote: The whole list is good things to have I just wonder how ongoing updates will be handled for backport. For example at some point Tweaks to the MCPM code which aren't upstream. will go upstream and probably be a bit different by then, someone should revert (it may not be that clean since other patches may have meddled) the old one in lsk and replace with the upstream patches. Mark's watching out for that, or you are for the trees you merged that went into LSK, or what's the plan? Plan? There's no plan that I know of. As was mentioned on linaro-kernel the plan is that you should be sending me incremental updates as needed. But who decides what's needed? If what is in 3.10 works, why backport a different version? And I hadn't planned on spending any time on backporting new versions or fixes. Often there are improvements from upstream comment inbetween the last private drop of something and it appearing upstream. That can just be style or it can be better error handling or covering cases that weren't originally obvious. You won't literally always need to backport the changes if it's removing a comment or something but generally someone's going to at least have to eyeball the version that went upstream and check nothing nasty got fixed before ignoring it. More to the point there may need to be some kind of traceability list for what fed LSK like the merged topics list you sent, and if Mark expects someone to monitor those then an owner associated with that as well (maybe you can pass the buck up to the component merge branch author). Otherwise with it being a long term history branch pretty soon there will be so many patches piled on you'll have to do git diff v3.10 --stat to try understand what's actually in there. Somebody needs to follow the status of the contribution branch content in terms of it went upstream now or it got rejected or it was redone etc. There won't be that many topic branches overall in LSK, so it should be something that can stay under control if it's understood it needs to be under control. -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LSK getting started
On 5 August 2013 18:16, Mark Brown broo...@linaro.org wrote: On 5 August 2013 03:45, Andy Green andy.gr...@linaro.org wrote: 1) There seems to be two choices, linux-linaro-lsk and linux-linaro-lsk-android. I chose the android one, I assume it has the same androidization series on top that linux-linaro-core-tracking used at 3.10? Are there any other differences? There are some patches to improve the performance of the interactive scheduler in there as well. Currently we didn't take John's branch in order to make it easier to track the Google stuff while we're preparing for release, that will get filtered in sometime this week. I see, thanks. There may be other stuff lurking in linux-linaro that I'm not aware of, everything is supposed to be individually selected for backport. Literally linux-linaro I'm not sure is useful for anything, the tree LTs are basing on is linux-linaro-core-tracking. It's composed by rebase and then merges, so it's easy to see what's in there from a quick git log. https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=shortlog;h=refs/heads/linux-linaro-core-tracking For tracking, we rebase our BSP patches on this every rc and get all the latest nice things like IKS and HMP coming in our tree with no drama. For v3.10 what I've done is switch the basis from the v3.10 version of llct to your tree, and that went easily too. 3) In our LT tree we patch mainline to remove all warnings coming with our defconfig. Then if we see any warnings coming, we know it's our fault and we need to go fix it. Are you interested in taking a similar approach? We will take suitably non-invasive warning fixes and obviously any actual bug fixes that are fixed in the upstream LTS but we won't actively go looking for warnings in anything that's not built for testing of LSK ourselves. There is no commitment to making things in the underlying kernel warning free. Sounds reasonable attached is our current patch for your consideration. There's a permanent #warning about an unwind tables TODO this also knocks out the others are actual problems. 4) Maybe this is too much thinking ahead, but shouldn't these lsk branches be versioned, like linux-linaro-lsk-3.10? Otherwise when the next lsk version is announced there'll be a problem. This is what I inherited, we'd certainly start versioning things when there's more than one LSK around but having a this is the default version pointer does seem useful. I was intending to add versioned branches as part of the official release (which should be 13.08 now Greg's announced v3.10 as a LTS). If we start doing it shortly it's fine. Otherwise people who want 3.10-specific one will have no choice but to point at the latest one if that's all there is, and that will not always be 3.10. Having the default one mirror the latest versioned one sounds like the best of both worlds. -Andy clean-warnings Description: Binary data ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LSK getting started
On 5 August 2013 18:59, Mark Brown broo...@kernel.org wrote: On Mon, Aug 05, 2013 at 06:42:33PM +0800, Andy Green wrote: On 5 August 2013 18:16, Mark Brown broo...@linaro.org wrote: There may be other stuff lurking in linux-linaro that I'm not aware of, everything is supposed to be individually selected for backport. Literally linux-linaro I'm not sure is useful for anything, the tree LTs are basing on is linux-linaro-core-tracking. It's composed by rebase and then merges, so it's easy to see what's in there from a quick git log. That doesn't help with understanding why any of it is there or what it's for. Andrey is here hopefully he can do a Tixy-style breakdown. Sounds reasonable attached is our current patch for your consideration. There's a permanent #warning about an unwind tables TODO this also knocks out the others are actual problems. Please split this up into proper patches, and of course you should be submitting any fixes upstream if they're still present - if you're doing this sort of warning cleanup work it's going to be useful upstream too. I had a quick glance through and: These are only applied on lsk and llct, I don't actually know where the code patched came from but I think they're all mainline. I'll check it out later. - Things like just assigning a value to variables at declaration are worrying since that just shuts up the flow analysis warnings even if they're actually pointing out a genuine missed code path. In this case it's okay, that var is written via a pointer arg to another call, but the call either returns an err or fills it in. The value is only used on non-error path. It's just keeping the compiler happy. - The regmap change isn't something that I've seen upstream... If you mean where did the original come from commit 5a08d15602987bbdff3407d7645f95b7a70f1a6f Author: Stephen Warren swar...@nvidia.com Date: Wed Mar 20 17:02:02 2013 -0600 regmap: don't corrupt work buffer in _regmap_raw_write() - For printf() warnings consider changing the printf() format specifier to be accurate rather than casting. Yes fair enough. -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LSK getting started
On 5 August 2013 22:11, Mark Brown broo...@kernel.org wrote: On Mon, Aug 05, 2013 at 07:37:10PM +0800, Andy Green wrote: On 5 August 2013 18:59, Mark Brown broo...@kernel.org wrote: - The regmap change isn't something that I've seen upstream... If you mean where did the original come from I mean I haven't seen that warning that I'm aware of. commit 5a08d15602987bbdff3407d7645f95b7a70f1a6f Author: Stephen Warren swar...@nvidia.com Date: Wed Mar 20 17:02:02 2013 -0600 regmap: don't corrupt work buffer in _regmap_raw_write() Note that the above change is part of v3.10... I know, it's just unclear what you were saying about the regmap change isn't something that I've seen upstream... I went through and split out the fixes after examining each one. 1) warning elimination: arm: silence THUMB2 no unwind warning I think RMK wants it to blow warnings, the issue is there's no frame context if you build THUMB2 (which we are). In Kconfig # RMK wants arm kernels compiled with frame pointers or stack unwinding. # If you know what you are doing and are willing to live without stack # traces, you can get a slightly smaller kernel by setting this option to # n, but then RMK will have to kill you ;). config FRAME_POINTER bool depends on !THUMB2_KERNEL so I doubt he'll accept a patch silencing it. For me, it's a pointless warning and for lsk fixed at 3.10 it's also pointless IMO. 2) warning-elimination: android: binder This seems to be a problem with a patch already upstream 3) warning-elimination: androidization: mm Problem coming from Androidization patches 4) warning-elimination: ata: ata_hpa_resize default assignment Issue is upstream but I can't reproduce original compiler warning 5) warning-elimination: ion: use size_t-specific format Introduced in Androidization 6) warning-elimination: nobody uses cci_pmu_destroy Presumably coming from the CCI stuff Tixy pulled in 7) warning-elimination: regmap: cast pointer arg from int This seems to be a genuine issue of passing an int to a function wanting a const void *. However I can't reproduce the warning. 8) warning-elimination: usb: dwc3 This only made problems if you have CONFIG_PM but not CONFIG_SUSPEND, dunno if people care or not. So 3 and 5 are out-of-mainline Androidizaton issues. 6 only exists on ARM LT tree - llct / lsk and need to be dealt with here. 1 4, and 8 I doubt anyone will buy upstream, but you should still consider 1. 4 can't be demonstrated to be a problem right now (although it has been...) 8 we turned on SUSPEND ourselves since it was a problem. 2 is a problem from mainline. 7 is your department. -Andy warning elimination: arm: silence THUMB2 no unwind warning Description: Binary data warning-elimination: ion: use size_t-specific format Description: Binary data warning-elimination: nobody uses cci_pmu_destroy Description: Binary data warning-elimination: regmap: cast pointer arg from int Description: Binary data warning-elimination: androidization: mm Description: Binary data warning-elimination: ata: ata_hpa_resize default assignment Description: Binary data warning-elimination: usb: dwc3 Description: Binary data warning-elimination: android: binder Description: Binary data ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LSK getting started
On 6 August 2013 11:03, John Stultz john.stu...@linaro.org wrote: On 08/05/2013 05:24 PM, Andy Green wrote: 2) warning-elimination: android: binder This seems to be a problem with a patch already upstream 3) warning-elimination: androidization: mm Problem coming from Androidization patches [snip] 5) warning-elimination: ion: use size_t-specific format Introduced in Androidization Thanks Andy! I've applied these three to the linaro-fixes/experimental/android-3.10 branch. Thanks. Are you planning on sending #2 above on to lkml/Greg? Yes, you and Mark are on cc. -Andy thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
LSK getting started
Hi Mark - I have some small practical questions about LSK. I was able to make a tree with our linux-linaro-core-tracking@v3.10 LT patches on LSK basis work well (so far). I found this repo (it needs its ./description updating) https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git;a=summary 1) There seems to be two choices, linux-linaro-lsk and linux-linaro-lsk-android. I chose the android one, I assume it has the same androidization series on top that linux-linaro-core-tracking used at 3.10? Are there any other differences? 2) I saw the vexpress integration stuff from ARM LT was included already which is good, is there a wiki page (or README.html or the gitweb is also good) explaining the composition? 3) In our LT tree we patch mainline to remove all warnings coming with our defconfig. Then if we see any warnings coming, we know it's our fault and we need to go fix it. Are you interested in taking a similar approach? 4) Maybe this is too much thinking ahead, but shouldn't these lsk branches be versioned, like linux-linaro-lsk-3.10? Otherwise when the next lsk version is announced there'll be a problem. -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Organizing Config Fragments
On 1 August 2013 14:11, Viresh Kumar viresh.ku...@linaro.org wrote: Hi Andrey, linaro/configs/* is getting bigger and bigger, probably its the right time to organize it better for the future. There can be multiple things that we can do to avoid confusions of names but for now probably we can create separate directories for boards, rootfs kernel fragments? Or some other idea that you might have? Just a thought these seem to me like they are covering up for missing select xxx in the related Kconfig option (eg, CONFIG_ANDROID), or stuff that should be in the defconfig (eg, omap4, vexpress). There's also an issue the fragments are all =y when for ARCH_MULTIPLATFORM, it implies all things not needed for rootfs mount need to be =m. -Andy -- viresh ___ 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: Organizing Config Fragments
On 1 August 2013 16:30, Ryan Harkin ryan.har...@linaro.org wrote: On 1 August 2013 07:57, Andy Green andy.gr...@linaro.org wrote: On 1 August 2013 14:11, Viresh Kumar viresh.ku...@linaro.org wrote: Hi Andrey, linaro/configs/* is getting bigger and bigger, probably its the right time to organize it better for the future. There can be multiple things that we can do to avoid confusions of names but for now probably we can create separate directories for boards, rootfs kernel fragments? Or some other idea that you might have? Just a thought these seem to me like they are covering up for missing select xxx in the related Kconfig option (eg, CONFIG_ANDROID), or stuff that should be in the defconfig (eg, omap4, vexpress). Is the platform specific defconfig still relevant in a multiarch kernel? I guess the fragments should adding items missing from the default multiarch config. Excuse my ignorance, 'cause I don't know how multiarch works... It lets you have more than one CONFIG_ARCH_blah at once enabled in the config and working in the one kernel binary . You give it one of the valid dtbs to tell it what it is at runtime. We use it to have the CONFIG_ARCH_(dual aa9 SoC) and CONFIG_ARCH_(big.LITTLE SoC) in the same kernel binary so the same kernel can start up on both platforms. Once it's started though, it's just bloat to have peripheral drivers present on only one of the platforms built-in to the monolithic kernel. For example those two SoCs have different video IPs, so we need them to be both built as modules and then use the different Device Tree definition to bind to just the right module at runtime so it all works out nicely. So you do still need to tell the kernel what drivers are relevant to your combined set of arches, your defconfig needs to reflect that (and builds everything selected as modules where possible). Historically, the main reason for us creating the frags was because of the platforms (eg, Ubuntu) adding lots of config options that weren't in the defconfig. The vexpress defconfig has always been broken. But over-riding the defconfig with Ubuntu/Android/whatever options was a bigger bodge than creating fragments. Right I think eg, adding selects to CONFIG_ANDROID in its Kconfig, or adding CONFIG_ANDROID_TYPICAL to do that and select CONFIG_ANDROID would soak up some of them anyway. General Ubuntuesque options I don't know, maybe that's more legit. So I think they are still important for Linaro's builds. Escpecially as we aren't building multiarch kernels for all our platforms yet. There's also an issue the fragments are all =y when for ARCH_MULTIPLATFORM, it implies all things not needed for rootfs mount need to be =m. That's a good point and something we should look into. We should really be using multiarch kernels sooner rather than later, right? I think it makes a lot of sense for each vendor to have their own stuff building as a single multiarch kernel if possible. Then you can just provide one image with one or two kernels (LPAE and non-LPAE don't play together) plus a lot of modules and dtbs that covers all the cases. It will be possible to enable different vendor arches all at the same time as well, but the different bootloader requirements situation will scuttle that. Some combinations will work like Fujitsu AA9 has bootloader in internal NOR, it can share an SD with OMAP4 using MLO inside VFAT okay. At any rate to get the SoC support upstream now you have to meet the checklist for ARCH_MULTIPLATFORM so it's certainly the way of the future. -Andy -Andy -- viresh ___ 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: Organizing Config Fragments
On 2 August 2013 01:46, Jon Medhurst (Tixy) t...@linaro.org wrote: On Thu, 2013-08-01 at 17:40 +0100, Peter Maydell wrote: On 1 August 2013 09:30, Ryan Harkin ryan.har...@linaro.org wrote: The vexpress defconfig has always been broken. ...maybe we could fix it? It has been suggested that should be deleted as people can use the multiplatform defconfig (though I believe that is missing the regulator config for mmc as well). People have different ideas where various configs should live, boards specific defconfig, multiplatform defconfig or in Kconfig; and any particular change probably would have people arguing against it. And That's probably a correct prediction... but it doesn't mean all of the solutions are equally good. I guess nobody outside Linaro with these kernels uses and most don't even know about the config fragments scripts. We inherit them from llct but nobody uses them in Fujitsu. - For things fixing a defconfig, or making it appropriate for other patches added in that kernel, shouldn't we patch the defconfig directly (via make savedefconfig)? Then people will use the fix and you have a fix to suggest upstream. - For optional things that follow from enabling a single Kconfig selection (eg, CONFIG_ANDROID) why not have it enforced at the selection of that config? - For Ubuntize or -- with vexpress we have the added complication thrown into the mix that people use it a lot with QEMU ;-) ...if there's something special needed for QEMU, maybe the fragments are the right answer. Or if it's just lack of models for IP maybe building the drivers modular anyway and knocking them out in dts (status=not okay) is the right answer. However currently they all have a let's make a fat kernel =y approach when our defconfig is more like allmodules, so for us we can't use any of the fragments meaningfully, so eliminating them doesn't sound like a bad idea. -Andy -- Tixy ___ 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: Organizing Config Fragments
On 2 August 2013 07:38, Peter Maydell peter.mayd...@linaro.org wrote: On 2 August 2013 00:26, Andy Green andy.gr...@linaro.org wrote: On 2 August 2013 01:46, Jon Medhurst (Tixy) t...@linaro.org wrote: with vexpress we have the added complication thrown into the mix that people use it a lot with QEMU ;-) ...if there's something special needed for QEMU, maybe the fragments are the right answer. My general aim is that the kernel that works on h/w should also work on the QEMU model. In general it does, though we rely a bit on various driver probe routines gracefully coping with the device not actually being present. Somebody put We have a similar situation with a (non-QEMU) simulator, but it's not possible to win on that since just probing an empty address will blow a bus fault. We have to take the approach to knock out the missing device instantiations in the dtsi. something new into the kernel and exposed a missing bit of QEMU emulation support is also a periodic event, but those are just bugs that need fixing. The biggest roadblock I'm seeing at the moment actually is that there's a big class of problems (which generally boil down to wrong kernel config or sometimes wrong QEMU command line arguments) which manifest as kernel produces no output. 'common and easy user error' + 'zero diagnostics' = 'lots of annoying support email' :-) Right, I can imagine. x86 manages to do much better here because the everything looks like a PC effect means it's much easier for the kernel to produce output to serial or video very early. It's much easier to configure an ARM kernel so it doesn't look for the serial port in the right place or so it falls over before it gets round to actually being able to output to serial (and earlyprintk is very hit-and-miss especially in a multiplatform kernel). I'm not sure there's really a good solution to this problem, though :-( The problem is the bootloader being flexible and meddling with the dtb chosen line to match its private state (bootargs in U-Boot env for example). I don't know how to stop U-Boot doing that, since if it even gets wind that you loaded a dtb image it's all over it meddling. But if you could stop it, preparing a golden chosen commandline in the dts and telling people to disable bootloader dtb meddling would be a nice debugging aid. We use a stub bootloader instead that always uses the chosen already in the dts. -Andy -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] uboot optimize memmove
Looping Will... On 29 July 2013 16:28, Dirk Behme dirk.be...@de.bosch.com wrote: On 26.07.2013 15:42, Andy Green wrote: On 26 July 2013 20:58, Wolfgang Denk w...@denx.de wrote: ... you not make sure that you provide optimized implementations for such functions and consequently #define __HAVE_ARCH_MEMMOVE (and __HAVE_ARCH_MEMCPY) ? Yes I found these afterwards... performance is slightly better than memcpy() thanks to Nicolas Pitre it seems. The U-Boot config for the platform we have didn't know about them, it's much better with them. After I wrote this patch it was also pointed out by Will Newton at Linaro that we have Neon accelerated memcpy lying around with BSD license https://launchpad.net/cortex-strings however for my purposes NOR boot is working good enough with the ARCH versions. I've had a look to https://launchpad.net/cortex-strings and there downloaded https://launchpad.net/cortex-strings/trunk/2013.01/+download/cortex-strings-1.0-2013.01.tar.bz2 (from the green download button on the right side). The README mentions src/neon contains NEON based routines for AArch32. but the cortex-strings-1.0-2013.01.tar.bz2 seems to contain an empty src/neon directory. Is this intended? I don't know... I agree that dir is empty... Will, do you know the story? I found nice-looking ones in reference/newlib but I don't think they're NEON. -Andy Best regards Dirk ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] uboot optimize memmove
Dear Wolfgang Denk, On 27 July 2013 03:06, Wolfgang Denk w...@denx.de wrote: Dear Andy Green, In message caafg0w7p6rvvamqsksc09yqnfpod08ydtbeh_mqrz6n+b4i...@mail.gmail.com you wrote: Instead of making assumptions on the performance of memcpy() and As I wrote, I measured the performance and got a very big gain, it's 3x faster on my setup to use memcpy() then default memmove(). Yes, in your single test case of copying a Linux kernel image, i. e. a multi-megabyte file. That single test case of copying a multi-megabyte file is the reason d'etre of a bootloader...if it doesn't perform well doing that then it's a problem. However I agree the alternative arch-specific implementation for ARM is pretty good, so this is kind of moot. Since I traced my problem to here I fixed it there, but that actual problem was were using the default implementations at all (the config was inherited).. By calling that an assumption you're saying that there exist platforms where 32-bit linear memmove() is slower than doing it with 8-bit actions? No. I said you should not assume that memcpy() is always faster than memmove(); a system may use optiomized versions of either. I did not assume that, I looked at your code for both and saw, and proved, that using 32-bit operations for mass move actions is going to perform better than using 8-bit operations. That's not something you can write off as an assumption, it's a fact. adding the overhead of an additional function call (which can be expensive especially for short copy operations) it would make more I am not sure U-Boot is really in the business of doing small memmoves, but okay... It's easy to avoid this overhead, and also get rid of the restrictions you built into it (otimizong only the non-overlapping case), so if we touch that code, we should do it right. Given that code should perferably never be used, maybe it should print a warning like Using default memory ops and leave it like it is. The problem is not correctness just inefficiency. sense to pull the copy a word at a time code from memcpy() into memmove(), too. On the other hand - if you really care about performance, then why do I spent several hours figuring out why our NOR boot performance was terrible it's because this default memmove code is gloriously inefficient for all cases. If you like it like that, no worries. Don't twist my words. I asked for a different, better implementation, that's all. Unfortunately I'm only looking at it because it made trouble, and we now no longer use that code. For the use-case I'm studying (very fast overall boot) it still may make sense to implement the NEON stuff in which case I'll offer a patch for that. -Andy Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The only time the world beats a path to your door is when you are in the bathroom. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] uboot optimize memmove
While studying the reason why kernel copy from NOR was so slow on our platform,
I realized U-Boot is pulling it from 32-bit NOR in 8-bit chunks needlessly.
bootm uses memmove() and that just takes the approach by default to move u8s
around.
This optimization prefers memcpy() implementation (done mostly in 32-bit reads
and writes) if there's no overlap in source and dest, resulting in a huge
speedup on our platform (480ms copy from 32-bit NOR --- 140ms)
Signed-off-by: Andy Green andy.gr...@linaro.org
---
lib/string.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/string.c b/lib/string.c
index c3ad055..96d66e0 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -542,13 +542,21 @@ void * memmove(void * dest,const void *src,size_t count)
if (src == dest)
return dest;
- if (dest = src) {
+ if (dest src) {
+
+ if ((unsigned long)dest + count = (unsigned long)src)
+ return memcpy(dest, src, count);
+
tmp = (char *) dest;
s = (char *) src;
while (count--)
*tmp++ = *s++;
}
else {
+
+ if ((unsigned long)src + count = (unsigned long)dest)
+ return memcpy(dest, src, count);
+
tmp = (char *) dest + count;
s = (char *) src + count;
while (count--)
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] uboot optimize memmove
On 26 July 2013 20:58, Wolfgang Denk w...@denx.de wrote: Dear Andy Green, In message 20130726065323.27333.82421.stgit@localhost.localdomain you wrote: While studying the reason why kernel copy from NOR was so slow on our platform, I realized U-Boot is pulling it from 32-bit NOR in 8-bit chunks needlessly. bootm uses memmove() and that just takes the approach by default to move u8s around. This optimization prefers memcpy() implementation (done mostly in 32-bit reads and writes) if there's no overlap in source and dest, resulting in a huge speedup on our platform (480ms copy from 32-bit NOR --- 140ms) Sorry, but I dislike your patch. I see. Instead of making assumptions on the performance of memcpy() and As I wrote, I measured the performance and got a very big gain, it's 3x faster on my setup to use memcpy() then default memmove(). By calling that an assumption you're saying that there exist platforms where 32-bit linear memmove() is slower than doing it with 8-bit actions? adding the overhead of an additional function call (which can be expensive especially for short copy operations) it would make more I am not sure U-Boot is really in the business of doing small memmoves, but okay... sense to pull the copy a word at a time code from memcpy() into memmove(), too. On the other hand - if you really care about performance, then why do I spent several hours figuring out why our NOR boot performance was terrible it's because this default memmove code is gloriously inefficient for all cases. If you like it like that, no worries. you not make sure that you provide optimized implementations for such functions and consequently #define __HAVE_ARCH_MEMMOVE (and __HAVE_ARCH_MEMCPY) ? Yes I found these afterwards... performance is slightly better than memcpy() thanks to Nicolas Pitre it seems. The U-Boot config for the platform we have didn't know about them, it's much better with them. After I wrote this patch it was also pointed out by Will Newton at Linaro that we have Neon accelerated memcpy lying around with BSD license https://launchpad.net/cortex-strings however for my purposes NOR boot is working good enough with the ARCH versions. -Andy Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is dangerous to be sincere unless you are also stupid. - George Bernard Shaw ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Perf test giving strange results
Hi -
Trying perf test on llct-based 3.10-rc6 isn't entirely happy.
root@aa9-eb:~# perf test
1: vmlinux symtab matches kallsyms: FAILED!
2: detect open syscall event : Ok
3: detect open syscall event on all cpus : Ok
4: read samples using the mmap interface : Ok
5: parse events tests : Warning:
function sizeof not defined
Warning: function sizeof not defined
Warning: function scsi_trace_parse_cdb not defined
Warning: function scsi_trace_parse_cdb not defined
Warning: function scsi_trace_parse_cdb not defined
Warning: function scsi_trace_parse_cdb not defined
Warning: function jiffies_to_msecs not defined
Warning: function jiffies_to_msecs not defined
Warning: bad op token {
Warning: bad op token {
Warning: bad op token {
Warning: Error: expected type 4 but read 0
Warning: bad op token {
Warning: Error: expected type 4 but read 0
Warning: bad op token {
Warning: bad op token {
Warning: bad op token {
Warning: bad op token {
Warning: bad op token {
Warning: unknown op '{'
Warning: unknown op '{'
Ok
6: Validate PERF_RECORD_* events perf_sample fields : FAILED!
7: Test perf pmu format parsing : Ok
8: Test dso data interface: Ok
9: roundtrip evsel-name check: Ok
10: Check parsing of sched tracepoints fields : FAILED!
11: Generate and check syscalls:sys_enter_open event fields: Ok
12: struct perf_event_attr setup : (omitted) Ok
13: Test matching and linking mutliple hists : Ok
14: Try 'use perf' in python, checking link problems : FAILED!
15: Test breakpoint overflow signal handler: FAILED!
16: Test breakpoint overflow sampling : FAILED!
17: Test number of exit event of a simple workload : FAILED!
18: Test software clock events have valid period values: Ok
I started tracing the first failure... it stops because it can't find
_stext in /proc/kallsyms. But it is there
root@aa9-eb:~# cat /proc/kallsyms | grep _stext
800081c0 T _stext
test 5 (parse event tests) seems to be badly broken.
Is this just our problem or is it broken for everyone?
-Andy
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Perf test giving strange results
On 26 June 2013 17:57, Milosz Wasilewski milosz.wasilew...@linaro.org wrote:
On 26 June 2013 09:16, Andy Green andy.gr...@linaro.org wrote:
Hi Milosz -
test 5 (parse event tests) seems to be badly broken.
Is this just our problem or is it broken for everyone?
I'm not sure if the reason is the same but this test was broken in
LAVA for some time now. The latest result on 3.10.0-1-linaro-omap
kernel looks like this:
perf test - parse events tests
:Can't open event dir : No such file or directory
Can't open event dir : No such file or directory
Warning : function scsi_trace_parse_cdb not defined
Warning : function scsi_trace_parse_cdb not defined
Warning : function scsi_trace_parse_cdb not defined
Warning : function scsi_trace_parse_cdb not defined
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : function jiffies_to_msecs not defined
Warning : function jiffies_to_msecs not defined
Warning : bad op token {
Warning : bad op token {
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : Error : expected type 4 but read 0
Warning : bad op token {
Warning : bad op token {
Warning : bad op token {
Warning : bad op token {
Warning : bad op token {
Warning : unknown op '{'
Warning : unknown op '{'
FAIL
Thanks.
I guess it is simply broken upstream, or we missed a point somewhere.
Llct does have one patch compared to vanilla 3.10-rc6 but that's it
diff --git a/tools/perf/config/utilities.mak b/tools/perf/config/utilities.mak
index 8ef3bd3..3e89719 100644
--- a/tools/perf/config/utilities.mak
+++ b/tools/perf/config/utilities.mak
@@ -173,7 +173,7 @@ _ge-abspath = $(if $(is-executable),$(1))
# Usage: absolute-executable-path-or-empty = $(call
get-executable-or-default,variable,default)
#
define get-executable-or-default
-$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2),$(1)))
+$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2)))
endef
_ge_attempt = $(if
$(get-executable),$(get-executable),$(_gea_warn)$(call _gea_err,$(2)))
_gea_warn = $(warning The path '$(1)' is not executable.)
What's the plan for tests that are in Lava that are themselves
partially broken? We should snip or force the results, patch to turn
off those tests?
-Andy
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Gator with IKS config but not running on big.LITTLE
On 20 June 2013 17:34, Dave Martin dave.mar...@linaro.org wrote:
On Thu, Jun 13, 2013 at 12:08:49PM +0100, Jon Medhurst (Tixy) wrote:
On Thu, 2013-06-13 at 12:14 +0800, Andy Green wrote:
Hi -
Something maybe unrelated after inserting gator successfully get
some kernel logs coming
[ 52.491528] CPU PMU: unable to set irq affinity (irq=0, cpu=0)
[ 52.496351] CPU PMU: unable to set irq affinity (irq=0, cpu=0)
...
irq = 0 isn't looking very happy... are there more new DT properties
we need somewhere to be compatible? Our actual pmu section just looks
like this
pmu {
compatible = arm,cortex-a9-pmu;
interrupts = 0 98 0x4,
0 99 0x4;
};
This isn't an area I have any knowledge in, sorry. But for what it's
worth that looks the same format as vexpress pmu nodes. IRQs are
obviously different, and the number of them match the number of CPUs.
Hi Dave -
This may be another side effect on the perf hacks of the changed IKS
CPU pairing.
Thanks... when I updated to -rc6 pieces without those patches, the
logs about irq affinity are gone. So it may well have been related.
I don't intend to fix this unless someone has a strong need for it.
I'm working on something to supersede those perf hacks, but it won't
be ready immediately.
AFAIK we're alright at the moment now.
-Andy
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Gator with IKS config but not running on big.LITTLE
Thanks for the info: you're right I missed that. When I add it, the
BUG is gone on gator module insertion, so from my POV we can call it
fixed.
-Andy
On 11 June 2013 23:12, Jon Medhurst (Tixy) t...@linaro.org wrote:
On Tue, 2013-06-11 at 22:49 +0800, Andy Green wrote:
Blows chunks the same with this
cpus {
#size-cells = 0;
#address-cells = 1;
cpu@0 {
compatible = arm,cortex-a9;
next-level-cache = L2;
reg = 0;
};
cpu@1 {
compatible = arm,cortex-a9;
next-level-cache = L2;
reg = 1;
};
};
I think it's following Lorenzo's method.
You missed
device_type = cpu;
from both cpu nodes. That's a mandatory attribute mentioned in the docs,
and also what the gator code searches for with of_find_node_by_type().
I'm still going to make gator codp with missing cpu nodes.
--
Tixy
-Andy
On 11 June 2013 22:34, Jon Medhurst (Tixy) t...@linaro.org wrote:
On Tue, 2013-06-11 at 22:09 +0800, Andy Green wrote:
Thanks. This and the similar issue with perf might be telling us a
global probed SoC capability flag for bL or-ed with the config being
there might be helpful.
Now we have accepted DT bindings for cpu nodes [1] perhaps all board's
device-trees should be updated to use them? I believe that
'mpidr_cpuids_count is 0 and nr_cpu_ids is 2' means you don't have cpu
nodes in your device tree?
And code like gator should use some common kernel functions for looking
up cpu mappings rather than parsing DT for cpu nodes itself.
I'll make gator behave one way or the other so it doesn't break on
platforms with missing cpu node or no IKS.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/170234.html
--
Tixy
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Gator with IKS config but not running on big.LITTLE
Hi -
Something maybe unrelated after inserting gator successfully get
some kernel logs coming
[ 52.491528] CPU PMU: unable to set irq affinity (irq=0, cpu=0)
[ 52.496351] CPU PMU: unable to set irq affinity (irq=0, cpu=0)
...
irq = 0 isn't looking very happy... are there more new DT properties
we need somewhere to be compatible? Our actual pmu section just looks
like this
pmu {
compatible = arm,cortex-a9-pmu;
interrupts = 0 98 0x4,
0 99 0x4;
};
-Andy
On 13 June 2013 08:26, Andy Green andy.gr...@linaro.org wrote:
Thanks for the info: you're right I missed that. When I add it, the
BUG is gone on gator module insertion, so from my POV we can call it
fixed.
-Andy
On 11 June 2013 23:12, Jon Medhurst (Tixy) t...@linaro.org wrote:
On Tue, 2013-06-11 at 22:49 +0800, Andy Green wrote:
Blows chunks the same with this
cpus {
#size-cells = 0;
#address-cells = 1;
cpu@0 {
compatible = arm,cortex-a9;
next-level-cache = L2;
reg = 0;
};
cpu@1 {
compatible = arm,cortex-a9;
next-level-cache = L2;
reg = 1;
};
};
I think it's following Lorenzo's method.
You missed
device_type = cpu;
from both cpu nodes. That's a mandatory attribute mentioned in the docs,
and also what the gator code searches for with of_find_node_by_type().
I'm still going to make gator codp with missing cpu nodes.
--
Tixy
-Andy
On 11 June 2013 22:34, Jon Medhurst (Tixy) t...@linaro.org wrote:
On Tue, 2013-06-11 at 22:09 +0800, Andy Green wrote:
Thanks. This and the similar issue with perf might be telling us a
global probed SoC capability flag for bL or-ed with the config being
there might be helpful.
Now we have accepted DT bindings for cpu nodes [1] perhaps all board's
device-trees should be updated to use them? I believe that
'mpidr_cpuids_count is 0 and nr_cpu_ids is 2' means you don't have cpu
nodes in your device tree?
And code like gator should use some common kernel functions for looking
up cpu mappings rather than parsing DT for cpu nodes itself.
I'll make gator behave one way or the other so it doesn't break on
platforms with missing cpu node or no IKS.
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/170234.html
--
Tixy
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Gator with IKS config but not running on big.LITTLE
Hi - If you have a CONFIG_ARCH_MULTIPLATFORM kernel, with big.LITTLE configured but running on say, a CA9 system, and you have gator from llct, and you insert gator root@localhost:~# modprobe gator [ 73.951009] [ cut here ] [ 73.955673] kernel BUG at /projects/linaro/linux-2.6/drivers/gator/gator_iks.c:43! [ 73.963260] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP THUMB2 [ 73.969392] Modules linked in: gator(+) hid_generic usbhid hid f_usb20hdc_otg usbcore f_usb30_udc udc_core usb_common [ 73.980325] CPU: 1 PID: 1711 Comm: modprobe Not tainted 3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+ #87 [ 73.989678] task: ea395400 ti: ea38a000 task.ti: ea38a000 [ 73.995221] PC is at gator_module_init+0x5f/0xb0 [gator] [ 74.000594] LR is at of_find_node_by_type+0x33/0x3c [ 74.005488] pc : [7f8f5070]lr : [801de123]psr: 800f0033 [ 74.005488] sp : ea38be58 ip : 7f8f0090 fp : 7f8efe64 [ 74.016980] r10: 001c r9 : r8 : 7f8f5011 [ 74.022211] r7 : 7f8efea0 r6 : 7f8effc0 r5 : r4 : [ 74.028777] r3 : 0002 r2 : r1 : 400f0013 r0 : [ 74.035344] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user [ 74.042706] Control: 50c5387d Table: a957404a DAC: [ 74.048493] [ 74.048493] LR: 0x801de0a3: [ 74.052776] e0a0 f08f4802 4620fb51 bf00bd38 8048f5e0 460eb573 490d4615 f7ffaa01 4604fe17 [ 74.061000] e0c0 f75ab188 9b01fa7f d80c4298 212c4620 fcd6f756 1c44b100 46214630 f75a462a [ 74.069262] e0e0 2000fb6b f06fe001 bd7c0012 8033e4e9 4604b5f8 460e4d0c f08f4628 4607f9fe [ 74.077494] e100 e007b104 e006686c b1186860 f75a4631 b110f9bd 2c006aa4 4803d1f6 f08f4639 [ 74.085713] e120 4620fb2a bf00bdf8 8048f5e0 4604b5f8 460e4d0c f08f4628 4607f9e0 e007b104 [ 74.093930] e140 e006686c b1186820 f75a4631 b110f99f 2c006aa4 4803d1f6 f08f4639 4620fb0c [ 74.102150] e160 bf00bdf8 8048f5e0 4605b570 6844480a f9c3f08f e0064606 b11868e0 f75a4629 [ 74.110371] e180 b110f985 2c006aa4 4803d1f6 f08f4631 4620faf2 bf00bd70 8048f5e0 460eb570 [ 74.118591] e1a0 21004605 6820e007 4631b118 f96ef75a 4628b130 f7ff4621 4604fcfb d1f22800 [ 74.126811] [ 74.126811] SP: 0xea38bdd8: [ 74.131085] bdd8 001d 80412ab4 ea38be54 0001 001d [ 74.139301] bdf8 80412ab4 7f8f5072 800f0033 ea38be44 8000c1e1 400f0013 [ 74.147522] be18 0002 7f8effc0 7f8efea0 7f8f5011 [ 74.155738] be38 001c 7f8efe64 7f8f0090 ea38be58 801de123 7f8f5070 800f0033 [ 74.163954] be58 7f8f5011 7f8efe58 ea38bf58 0001 800084f5 7f8f5011 [ 74.172174] be78 0001 7f8efe58 7f8efe58 ea38bf58 0001 7f8efea0 ea96fec0 0001 [ 74.180391] be98 001c 8004a4cd 7f8efe64 7fff 80047b3d ea38bf1c 0028 [ 74.188607] beb8 80412434 7f8effac 80271bec f0c54c18 ea38beec 76f6efa8 2033 [ 74.196835] Process modprobe (pid: 1711, stack limit = 0xea38a238) [ 74.203022] Stack: (0xea38be58 to 0xea38c000) [ 74.207384] be40: 7f8f5011 [ 74.215579] be60: 7f8efe58 ea38bf58 0001 800084f5 7f8f5011 0001 7f8efe58 [ 74.223773] be80: 7f8efe58 ea38bf58 0001 7f8efea0 ea96fec0 0001 001c 8004a4cd [ 74.231968] bea0: 7f8efe64 7fff 80047b3d ea38bf1c 0028 80412434 [ 74.240163] bec0: 7f8effac 80271bec f0c54c18 ea38beec 76f6efa8 2033 ea38bf1c [ 74.248357] bee0: 5f696261 8000c0b5 f0ca 76e5d000 0305 7f8edf44 000d [ 74.256549] bf00: [ 74.264740] bf20: 2033 76d41000 76f6efa8 [ 74.272931] bf40: 0080 8000c764 ea38a000 8004a727 f0b84000 0011c385 [ 74.281125] bf60: f0c542b8 f0c54048 f0c9de18 7bfc 9bac [ 74.289315] bf80: 003c 003d 0025 001a 0022 76f6fbe4 0004 [ 74.297506] bfa0: 77fa81c0 8000c5c1 76f6fbe4 0004 76d41000 0011c385 76f6efa8 0002 [ 74.305700] bfc0: 76f6fbe4 0004 77fa81c0 0080 77fb0158 0011c385 [ 74.313895] bfe0: 76eeec00 7ec74368 76f693ad 76eeec10 8010 76d41000 ab7dd821 ab7ddc21 [ 74.322199] [7f8f5070] (gator_module_init+0x5f/0xb0 [gator]) from [800084f5] (do_one_initcall+0x61/0xd8) [ 74.332064] [800084f5] (do_one_initcall+0x61/0xd8) from [8004a4cd] (load_module+0xbdd/0xdc8) [ 74.340875] [8004a4cd] (load_module+0xbdd/0xdc8) from [8004a727] (SyS_init_module+0x6f/0x7e) [ 74.349693] [8004a727] (SyS_init_module+0x6f/0x7e) from [8000c5c1] (ret_fast_syscall+0x1/0x46) [ 74.358673] Code: 4b12 681b 429c d000 (de02) 4c11 [ 74.363473] ---[ end trace 4b8ff3a1ee8d2385 ]--- -Andy ___ linaro-dev mailing list linaro-dev@lists.linaro.org
Re: Gator with IKS config but not running on big.LITTLE
I see... I was still on -rc4 https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=commitdiff;h=882503738c0cbef28da55b511913c0c603016e26 ...behind the times... thanks for the fix. -Andy On 11 June 2013 21:04, Jon Medhurst (Tixy) t...@linaro.org wrote: On Tue, 2013-06-11 at 20:29 +0800, Andy Green wrote: Hi - If you have a CONFIG_ARCH_MULTIPLATFORM kernel, with big.LITTLE configured but running on say, a CA9 system, and you have gator from llct, and you insert gator Looks like a bug I fixed a week ago... https://bugs.launchpad.net/linaro/+bug/1184712 That fix is now in the llct. -- Tixy root@localhost:~# modprobe gator [ 73.951009] [ cut here ] [ 73.955673] kernel BUG at /projects/linaro/linux-2.6/drivers/gator/gator_iks.c:43! [ 73.963260] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP THUMB2 [ 73.969392] Modules linked in: gator(+) hid_generic usbhid hid f_usb20hdc_otg usbcore f_usb30_udc udc_core usb_common [ 73.980325] CPU: 1 PID: 1711 Comm: modprobe Not tainted 3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+ #87 [ 73.989678] task: ea395400 ti: ea38a000 task.ti: ea38a000 [ 73.995221] PC is at gator_module_init+0x5f/0xb0 [gator] [ 74.000594] LR is at of_find_node_by_type+0x33/0x3c [ 74.005488] pc : [7f8f5070]lr : [801de123]psr: 800f0033 [ 74.005488] sp : ea38be58 ip : 7f8f0090 fp : 7f8efe64 [ 74.016980] r10: 001c r9 : r8 : 7f8f5011 [ 74.022211] r7 : 7f8efea0 r6 : 7f8effc0 r5 : r4 : [ 74.028777] r3 : 0002 r2 : r1 : 400f0013 r0 : [ 74.035344] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user [ 74.042706] Control: 50c5387d Table: a957404a DAC: [ 74.048493] [ 74.048493] LR: 0x801de0a3: [ 74.052776] e0a0 f08f4802 4620fb51 bf00bd38 8048f5e0 460eb573 490d4615 f7ffaa01 4604fe17 [ 74.061000] e0c0 f75ab188 9b01fa7f d80c4298 212c4620 fcd6f756 1c44b100 46214630 f75a462a [ 74.069262] e0e0 2000fb6b f06fe001 bd7c0012 8033e4e9 4604b5f8 460e4d0c f08f4628 4607f9fe [ 74.077494] e100 e007b104 e006686c b1186860 f75a4631 b110f9bd 2c006aa4 4803d1f6 f08f4639 [ 74.085713] e120 4620fb2a bf00bdf8 8048f5e0 4604b5f8 460e4d0c f08f4628 4607f9e0 e007b104 [ 74.093930] e140 e006686c b1186820 f75a4631 b110f99f 2c006aa4 4803d1f6 f08f4639 4620fb0c [ 74.102150] e160 bf00bdf8 8048f5e0 4605b570 6844480a f9c3f08f e0064606 b11868e0 f75a4629 [ 74.110371] e180 b110f985 2c006aa4 4803d1f6 f08f4631 4620faf2 bf00bd70 8048f5e0 460eb570 [ 74.118591] e1a0 21004605 6820e007 4631b118 f96ef75a 4628b130 f7ff4621 4604fcfb d1f22800 [ 74.126811] [ 74.126811] SP: 0xea38bdd8: [ 74.131085] bdd8 001d 80412ab4 ea38be54 0001 001d [ 74.139301] bdf8 80412ab4 7f8f5072 800f0033 ea38be44 8000c1e1 400f0013 [ 74.147522] be18 0002 7f8effc0 7f8efea0 7f8f5011 [ 74.155738] be38 001c 7f8efe64 7f8f0090 ea38be58 801de123 7f8f5070 800f0033 [ 74.163954] be58 7f8f5011 7f8efe58 ea38bf58 0001 800084f5 7f8f5011 [ 74.172174] be78 0001 7f8efe58 7f8efe58 ea38bf58 0001 7f8efea0 ea96fec0 0001 [ 74.180391] be98 001c 8004a4cd 7f8efe64 7fff 80047b3d ea38bf1c 0028 [ 74.188607] beb8 80412434 7f8effac 80271bec f0c54c18 ea38beec 76f6efa8 2033 [ 74.196835] Process modprobe (pid: 1711, stack limit = 0xea38a238) [ 74.203022] Stack: (0xea38be58 to 0xea38c000) [ 74.207384] be40: 7f8f5011 [ 74.215579] be60: 7f8efe58 ea38bf58 0001 800084f5 7f8f5011 0001 7f8efe58 [ 74.223773] be80: 7f8efe58 ea38bf58 0001 7f8efea0 ea96fec0 0001 001c 8004a4cd [ 74.231968] bea0: 7f8efe64 7fff 80047b3d ea38bf1c 0028 80412434 [ 74.240163] bec0: 7f8effac 80271bec f0c54c18 ea38beec 76f6efa8 2033 ea38bf1c [ 74.248357] bee0: 5f696261 8000c0b5 f0ca 76e5d000 0305 7f8edf44 000d [ 74.256549] bf00: [ 74.264740] bf20: 2033 76d41000 76f6efa8 [ 74.272931] bf40: 0080 8000c764 ea38a000 8004a727 f0b84000 0011c385 [ 74.281125] bf60: f0c542b8 f0c54048 f0c9de18 7bfc 9bac [ 74.289315] bf80: 003c 003d 0025 001a 0022 76f6fbe4 0004 [ 74.297506] bfa0: 77fa81c0 8000c5c1 76f6fbe4 0004 76d41000 0011c385 76f6efa8 0002 [ 74.305700] bfc0: 76f6fbe4 0004 77fa81c0 0080 77fb0158 0011c385 [ 74.313895] bfe0: 76eeec00 7ec74368 76f693ad 76eeec10 8010 76d41000 ab7dd821 ab7ddc21 [ 74.322199] [7f8f5070] (gator_module_init+0x5f/0xb0 [gator]) from [800084f5] (do_one_initcall+0x61/0xd8
Re: Gator with IKS config but not running on big.LITTLE
No, unfortunately I am evidently ahead of the times ^^ -- your patch
does not fix my bug...
I have a valid DT table, it's just not on a SoC that has big.LITTLE.
mpidr_cpuids_count is 0 and nr_cpu_ids is 2 ...
Instead of using DT being there or not it seems you need to test
something more to do with it being on a big.LITTLE or not...
-Andy
On 11 June 2013 21:23, Jon Medhurst (Tixy) t...@linaro.org wrote:
On Tue, 2013-06-11 at 21:08 +0800, Andy Green wrote:
I see... I was still on -rc4
https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=commitdiff;h=882503738c0cbef28da55b511913c0c603016e26
...behind the times...
Actually, it was also fixed on -rc4 too [1]. From your BUG() output
below I think you're even more behind the times than you thought ;-)
[1]
https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=shortlog;h=refs/tags/tracking-gator-llct-20130604.0
thanks for the fix.
-Andy
On 11 June 2013 21:04, Jon Medhurst (Tixy) t...@linaro.org wrote:
On Tue, 2013-06-11 at 20:29 +0800, Andy Green wrote:
Hi -
If you have a CONFIG_ARCH_MULTIPLATFORM kernel, with big.LITTLE
configured but running on say, a CA9 system, and you have gator from
llct, and you insert gator
Looks like a bug I fixed a week ago...
https://bugs.launchpad.net/linaro/+bug/1184712
That fix is now in the llct.
--
Tixy
root@localhost:~# modprobe gator
[ 73.951009] [ cut here ]
[ 73.955673] kernel BUG at
/projects/linaro/linux-2.6/drivers/gator/gator_iks.c:43!
[ 73.963260] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP THUMB2
[ 73.969392] Modules linked in: gator(+) hid_generic usbhid hid
f_usb20hdc_otg usbcore f_usb30_udc udc_core usb_common
[ 73.980325] CPU: 1 PID: 1711 Comm: modprobe Not tainted
3.10.0-linaro_fjslt-tracking-bsp2.0.0-rc1+ #87
[ 73.989678] task: ea395400 ti: ea38a000 task.ti: ea38a000
[ 73.995221] PC is at gator_module_init+0x5f/0xb0 [gator]
[ 74.000594] LR is at of_find_node_by_type+0x33/0x3c
[ 74.005488] pc : [7f8f5070]lr : [801de123]psr: 800f0033
[ 74.005488] sp : ea38be58 ip : 7f8f0090 fp : 7f8efe64
[ 74.016980] r10: 001c r9 : r8 : 7f8f5011
[ 74.022211] r7 : 7f8efea0 r6 : 7f8effc0 r5 : r4 :
[ 74.028777] r3 : 0002 r2 : r1 : 400f0013 r0 :
[ 74.035344] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb
Segment user
[ 74.042706] Control: 50c5387d Table: a957404a DAC:
[ 74.048493]
[ 74.048493] LR: 0x801de0a3:
[ 74.052776] e0a0 f08f4802 4620fb51 bf00bd38 8048f5e0 460eb573
490d4615 f7ffaa01 4604fe17
[ 74.061000] e0c0 f75ab188 9b01fa7f d80c4298 212c4620 fcd6f756
1c44b100 46214630 f75a462a
[ 74.069262] e0e0 2000fb6b f06fe001 bd7c0012 8033e4e9 4604b5f8
460e4d0c f08f4628 4607f9fe
[ 74.077494] e100 e007b104 e006686c b1186860 f75a4631 b110f9bd
2c006aa4 4803d1f6 f08f4639
[ 74.085713] e120 4620fb2a bf00bdf8 8048f5e0 4604b5f8 460e4d0c
f08f4628 4607f9e0 e007b104
[ 74.093930] e140 e006686c b1186820 f75a4631 b110f99f 2c006aa4
4803d1f6 f08f4639 4620fb0c
[ 74.102150] e160 bf00bdf8 8048f5e0 4605b570 6844480a f9c3f08f
e0064606 b11868e0 f75a4629
[ 74.110371] e180 b110f985 2c006aa4 4803d1f6 f08f4631 4620faf2
bf00bd70 8048f5e0 460eb570
[ 74.118591] e1a0 21004605 6820e007 4631b118 f96ef75a 4628b130
f7ff4621 4604fcfb d1f22800
[ 74.126811]
[ 74.126811] SP: 0xea38bdd8:
[ 74.131085] bdd8 001d 80412ab4 ea38be54
0001 001d
[ 74.139301] bdf8 80412ab4 7f8f5072 800f0033 ea38be44
8000c1e1 400f0013
[ 74.147522] be18 0002 7f8effc0
7f8efea0 7f8f5011
[ 74.155738] be38 001c 7f8efe64 7f8f0090 ea38be58 801de123
7f8f5070 800f0033
[ 74.163954] be58 7f8f5011 7f8efe58 ea38bf58 0001
800084f5 7f8f5011
[ 74.172174] be78 0001 7f8efe58 7f8efe58 ea38bf58 0001
7f8efea0 ea96fec0 0001
[ 74.180391] be98 001c 8004a4cd 7f8efe64 7fff 80047b3d
ea38bf1c 0028
[ 74.188607] beb8 80412434 7f8effac 80271bec f0c54c18
ea38beec 76f6efa8 2033
[ 74.196835] Process modprobe (pid: 1711, stack limit = 0xea38a238)
[ 74.203022] Stack: (0xea38be58 to 0xea38c000)
[ 74.207384] be40:
7f8f5011
[ 74.215579] be60: 7f8efe58 ea38bf58 0001 800084f5 7f8f5011
0001 7f8efe58
[ 74.223773] be80: 7f8efe58 ea38bf58 0001 7f8efea0 ea96fec0
0001 001c 8004a4cd
[ 74.231968] bea0: 7f8efe64 7fff 80047b3d ea38bf1c 0028
80412434
[ 74.240163] bec0: 7f8effac 80271bec f0c54c18 ea38beec 76f6efa8
2033 ea38bf1c
[ 74.248357] bee0: 5f696261 8000c0b5 f0ca 76e5d000 0305
7f8edf44 000d
[ 74.256549] bf00:
Re: Gator with IKS config but not running on big.LITTLE
Blows chunks the same with this
cpus {
#size-cells = 0;
#address-cells = 1;
cpu@0 {
compatible = arm,cortex-a9;
next-level-cache = L2;
reg = 0;
};
cpu@1 {
compatible = arm,cortex-a9;
next-level-cache = L2;
reg = 1;
};
};
I think it's following Lorenzo's method.
-Andy
On 11 June 2013 22:34, Jon Medhurst (Tixy) t...@linaro.org wrote:
On Tue, 2013-06-11 at 22:09 +0800, Andy Green wrote:
Thanks. This and the similar issue with perf might be telling us a
global probed SoC capability flag for bL or-ed with the config being
there might be helpful.
Now we have accepted DT bindings for cpu nodes [1] perhaps all board's
device-trees should be updated to use them? I believe that
'mpidr_cpuids_count is 0 and nr_cpu_ids is 2' means you don't have cpu
nodes in your device tree?
And code like gator should use some common kernel functions for looking
up cpu mappings rather than parsing DT for cpu nodes itself.
I'll make gator behave one way or the other so it doesn't break on
platforms with missing cpu node or no IKS.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/170234.html
--
Tixy
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] linux-linaro kernel schedule / llct age
On 05/06/13 04:05, the mail apparently from Andrey Konovalov included: On 06/04/2013 03:22 AM, Andy Green wrote: On 22/05/13 02:48, the mail apparently from Andrey Konovalov included: The next steps are: May 22: ll rebuild based on llct-20130521.0 May 23: ll rebuild based on llct-20130521.0, linux-linaro release candidate, code freeze The last llct update for this cycle is scheduled on May 21, The last linux-linaro update for this cycle is scheduled on May 23. May 23 is the linux-linaro code freeze for 13.05 (only bug fixes allowed after this date). This happened, which is good, but llct has not updated for 3.10-rc3 or 3.10-rc4 yet, which is not good; llct is two weeks old. Something similar happened last month. Agreed. This is not good. And I've pushed the llct updates to fix that. Thanks. On the other side, I am considering dropping llct as an intermediate step when creating the ll tree. The linux-linaro-stable work done in 13.05 shown that topic dependencies may be more complex, and could not be met by just creating one intermediate tree. The more generic approach seems to add explicit topic dependencies into the manifest, so that the tool to merge the topic together would use this information. I think that might be telling you that you're trying to get one llct branch to do too many integration angles at once. There's certainly a place for a tree that just collects a bunch of aligned topic trees like ARMLT vexpress, bl switcher, Androidization and binds them standalone. That's the one we want. As you do more like solving conflicts between bsp trees you're integrating, we don't want to subscribe to that so it's another, separate step I think. Another point to mention, is the proposal to merge the board enablement topics first, and the generic features next (the LSK case). This would assume the generic topics to enable their features for all the linaro supported boards, or adding separate topic to enable the features for particular boards. This also breaks the current 2-level llct/ll model. I don't think that's a good idea the problem will be the tree is unbuildable from the start when you bind the bsps that depend on the new generic features (vexpress for any big.LITTLE...) but only merge in the dependencies like vexpress later. It's better if the tree stays buildable as you go for sanity checks if nothing else, merging the generic features without users, then adding the users meets that. Also I am going to more actively use rebasing the topic to their most recent base w/o topic owners intervention (e.g. like I did for one month for the Samsung LT's integration topic few cycles ago). For the topic owners this would mean something like that if their topic C is based on topics A and B, the topic C must be based on the A and B tip when submitted to for inclusion into linux-linaro(-whatever) tree, and after that it will be automatically rebased onto the most recent version of topic A and B unless there are conflicts requiring the topic owner's help. This is a very rough idea at the moment - I am not quite sure if it could even work. Yeah we started out with TI tree purely doing rebases and it works as a flow, although with the - frankly - stupid structure of carrying around 2,500 patches of other people's rotting junk being enforced it becomes hard to manage. Later I realized we're totally compatible with merge if we get them all over with before we rebase our actual bsp tree patches on top as the last guys, that's the approach we take now. Now we have more control over how to arrange the work we completely ban out history series of patches in our rebase part for the bsp, we squash in topic patches currently limited to just 40 patches, even though a lot of work is going on with them. We use tagging for every working build that's notable to allow capture or understanding of the delta. So the problem of slow or unmanageable rebase is eliminated. This is another sign that the proposal you mentioned above is broken though, merge management can only happen underneath the rebase part, so you'll need to be be merging the generic trees first... I realize this isn't the case for everyone but actually the literal schedule for 13.05 holds zero interest for me. In long term this should evolve into change log / release notes. (I do use it for writing the release notes) Timely updates on llct for each mainline -rc are very interesting though, in fact we depend on them. OK. Could you use ll instead of llct, if ll were updated frequently enough (soon after every -rc at least)? At the moment with llct I can put my finger on your merges and explain what kind of thing we have in our tree inbetween Linus and our bsp patches, that is nice. (We have some extra trees merged in as well locally like upstream-headed mailbox series). Last time we discussed this ll already has other bsps merged in, eg, Samsung. At the moment we're basically
Re: [ANNOUNCE] linux-linaro kernel schedule / llct age
On 22/05/13 02:48, the mail apparently from Andrey Konovalov included: The next steps are: May 22: ll rebuild based on llct-20130521.0 May 23: ll rebuild based on llct-20130521.0, linux-linaro release candidate, code freeze The last llct update for this cycle is scheduled on May 21, The last linux-linaro update for this cycle is scheduled on May 23. May 23 is the linux-linaro code freeze for 13.05 (only bug fixes allowed after this date). This happened, which is good, but llct has not updated for 3.10-rc3 or 3.10-rc4 yet, which is not good; llct is two weeks old. Something similar happened last month. I realize this isn't the case for everyone but actually the literal schedule for 13.05 holds zero interest for me. Timely updates on llct for each mainline -rc are very interesting though, in fact we depend on them. Is it possible things have gotten a little unbalanced with all the excitement of code freezes, releases, schedules that make the choo-choo noises for the monthly release train set, we're not giving the llct tracking activity enough love? -Andy -- Andy Green | Fujitsu Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Tiny BL switcher compatibility issue with PMU on non-BL SoC
On 30/05/13 18:50, the mail apparently from Dave Martin included:
On Thu, May 30, 2013 at 10:06:20AM +0800, Andy Green wrote:
Hi -
We're using one kernel binary with BL Switcher enabled in config,
but able to work on SoC without Big Little.
This is OK except where the BL patches touch the PMU driver. It
makes an assumption about BL configured == in use which is not true.
PMU init fails and when you try to use perf list later, it blows
chunks.
I worked around it with the hack below, so it can fail out from the
bigLITTLE path when it doesn't see the cluster property in DT, but
there's presumably a better way to do that which more directly
checks if we care about BL in this execution environment.
-Andy
Author: Andy Green andy.gr...@linaro.org
Date: Thu May 30 09:44:17 2013 +0800
bl switcher fix dont assume bl active in pmu probe
Signed-off-by: Andy Green andy.gr...@linaro.org
diff --git a/arch/arm/kernel/perf_event_cpu.c
b/arch/arm/kernel/perf_event_cpu.c
index b3ae24f..c02ea21 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -440,6 +440,9 @@ static int cpu_pmu_device_probe(struct
platform_device *pdev)
hwid = of_get_property(ncluster, reg, len);
if (hwid len == 4)
cluster = be32_to_cpup(hwid);
+ } else {
+ ret = probe_current_pmu(pmu);
+ goto bail;
Can you provide logs?
If you really want them, but ---
Why is the DT different for MP versus IKS?
That is not the issue (nor did I mention IKS anywhere...), we are using
CONFIG_ARCH_MULTIPLATFORM and supporting SoCs based on CA9 and SoCs with
other things. In the case I'm talking about, the kernel with
big.LITTLE configured on finds itself waking up on a CA9 box.
It is incorrect for the DT to be different, because the hardware is
exactly the same in both cases.
If the DT isn't different, then can you elaborate on what is fixed
by this change?
The bug where having BL_SWITCHER configured on has gotten mixed up with
the idea that the kernel must therefore be running on a bL SoC, for PMU
purposes. In a CONFIG_ARCH_MULTIPLATFORM world, that ain't so.
I think the bug is smaller and less interesting than you're giving it
credit for ^^ but it's still something that should be fixed.
-Andy
You may be getting affected by the fact that we're relying on non-
pstreamed DT bindings to describe the PMUs in the system. Discussions
upstream are taking a different direction, so this code is going to
get substantially rewritten at some point. The perf support for IKS
is a big hack at the moment... Unfortunately, I have ongoing
distractions which mean that progress on this is mostly stalled
right now.
There is also a separate problem caused by a recent change to the IKS
code which breaks the perf support's assumptions about what physical/
logical CPU mappings are possible. I need to fix this, but it's not
done yet... If you are using up-to-date IKS code, it's possible you're
hitting this issue.
Cheers
---Dave
}
/* set sibling mask to all cpu mask if socket is not
specified */
/*
@@ -501,7 +504,7 @@ static int cpu_pmu_device_probe(struct
platform_device *pdev)
} else {
ret = probe_current_pmu(pmu);
}
-
+bail:
if (ret)
goto error;
--
Andy Green | Fujitsu Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
--
Andy Green | Fujitsu Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Tiny BL switcher compatibility issue with PMU on non-BL SoC
Hi -
We're using one kernel binary with BL Switcher enabled in config, but
able to work on SoC without Big Little.
This is OK except where the BL patches touch the PMU driver. It makes
an assumption about BL configured == in use which is not true. PMU init
fails and when you try to use perf list later, it blows chunks.
I worked around it with the hack below, so it can fail out from the
bigLITTLE path when it doesn't see the cluster property in DT, but
there's presumably a better way to do that which more directly checks if
we care about BL in this execution environment.
-Andy
Author: Andy Green andy.gr...@linaro.org
Date: Thu May 30 09:44:17 2013 +0800
bl switcher fix dont assume bl active in pmu probe
Signed-off-by: Andy Green andy.gr...@linaro.org
diff --git a/arch/arm/kernel/perf_event_cpu.c
b/arch/arm/kernel/perf_event_cpu.c
index b3ae24f..c02ea21 100644
--- a/arch/arm/kernel/perf_event_cpu.c
+++ b/arch/arm/kernel/perf_event_cpu.c
@@ -440,6 +440,9 @@ static int cpu_pmu_device_probe(struct
platform_device *pdev)
hwid = of_get_property(ncluster, reg, len);
if (hwid len == 4)
cluster = be32_to_cpup(hwid);
+ } else {
+ ret = probe_current_pmu(pmu);
+ goto bail;
}
/* set sibling mask to all cpu mask if socket is not
specified */
/*
@@ -501,7 +504,7 @@ static int cpu_pmu_device_probe(struct
platform_device *pdev)
} else {
ret = probe_current_pmu(pmu);
}
-
+bail:
if (ret)
goto error;
--
Andy Green | Fujitsu Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: arm-probe (with ARM Energy probe)
On 27/05/13 16:53, the mail apparently from Robert Brehm included: Hi, I have downloaded and compiled/installed (on Ubuntu 12.04 the arm-probe from: https://git.linaro.org/gitweb?p=tools/arm-probe.git;a=tree Now I am facing some issues using the tool. My Arm Energy Probe shows up as virtual serial port as /dev/ttyACM0 and I am able to open that port via “ # sudo screen /dev/ttyACM0 and when I “ctrl-c” in screen I get a response from the energy probe saying “ARM Energy Probe”. So the probe should be working fine. If I however run # arm-probe –c ch1 All it just shows is the blelow, there are no data streamed out at all: # configuration: ./config # config_name: K70-SOM # trigger: 0.40V (hyst 0.20V) 0.00W (hyst 0.20W) 400us Configuration: K70-SOM # date: Fri, 24 May 2013 15:45:57 +0200 # host: rb # This is the content of my configuration file: # arm-probe configuration file # # setup name K70-SOM /dev/ttyACM0 ch1 0.470 1 -0.000253 0 VCORE1/MPU ch2 0.470 2 -0.000253 0 VCORE1/MPU ch3 0.470 3 -0.000253 0 VCORE1/MPU Have you tried using the config file here? https://git.linaro.org/gitweb?p=tools/arm-probe.git;a=blob;f=config;h=2daed868003999ec3da619a4b0ebc9b4c11b6b6f;hb=HEAD It changed recently to use /dev/serial/by-id/... and instead of polling for AEPs just collect all the ones mentioned. -Andy -- Andy Green | Fujitsu Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: arm-probe (with ARM Energy probe)
On 28/05/13 00:06, the mail apparently from Robert Brehm included: Just tried with the config example (but also had tried that earlier already) - however, no success. It also still doesn't complain if I just run it without the AEP or I unplug the AEP while arm-probe is running - there is no difference to the output. No it won't complain just wait until it has seen all the AEPs mentioned in the config file before starting. Using exactly what's pushed to git $ arm-probe # configuration: ./config # config_name: PandaBoardES-B1-ANDY # trigger: 0.40V (hyst 0.20V) 0.00W (hyst 0.20W) 400us Configuration: PandaBoardES-B1-ANDY # date: Tue, 28 May 2013 08:05:36 +0800 # host: kaiji # + /dev/serial/by-id/usb-NXP_SEMICOND_ARM_Energy_Probe_S_NO-if00 Starting... sending start to 0 # VDD_VCORE1SoCVCORE1/MPU VBAT#ff SoC # VDD_VCORE2SoCVCORE2/IVA\\_AUDIO VBAT#c0 SoC # VDD_VCORE3SoCVCORE3/CORE VBAT#a0 SoC # VBAT VBATDC_IN #55 virtual # # time SoCVCORE1/MPU(V) SoCVCORE1/MPU(A) SoCVCORE1/MPU(W) SoCVCORE2/IVA\\_AUDIO(V) SoCVCORE2/IVA\\_AUDIO(A) SoCVCORE2/IVA\\_AUDIO(W) SoCVCORE3/CORE(V) SoCVCORE3/CORE(A) SoCVCORE3/CORE(W) ARMED 0.17 0. 0.0 0.16 0. 0.0 0.15 0. 0.0 ARMED 0.15 0.0036 0.00053 0.17 0. 0.0 0.17 0. 0.0 ARMED 0.16 0. 0.0 0.17 0. 0.0 0.16 0.0024 0.00037 ARMED 0.16 0.0036 0.00057 0.17 0. 0.0 0.15 0. 0.0 ARMED 0.17 0. 0.0 0.15 0.0015 0.00023 0.16 0. 0.0 ARMED 0.17 0. 0.0 0.16 0. 0.0 0.17 0. 0.0 ARMED 0.16 0. 0.0 0.16 0.0022 0.00035 0.17 0. 0.0 ARMED 0.16 0. 0.0 0.16 0. 0.0 0.15 0.0007 0.00011 ARMED 0.18 0. 0.0 0.15 0. 0.0 0.15 0.0018 0.00027 ARMED 0.17 0. 0.0 0.15 0.0015 0.00023 0.17 0. 0.0 ARMED 0.17 0. 0.0 0.16 0. 0.0 0.15 0.0030 0.00047 ARMED 0.17 0. 0.0 0.16 0. 0.0 0.16 0.0028 0.00045 ARMED 0.17 0. 0.0 0.15 0. 0.0 0.16 0.0024 0.00037 ARMED 0.17 0.0013 0.00022 0.17 0. 0.0 0.15 0. 0.0 ARMED 0.17 0. 0.0 0.16 0. 0.0 0.15 0. 0.0 ARMED 0.18 0. 0.0 0.16 0. 0.0 0.16 0. 0.0 ARMED 0.16 0.0004 0.6 0.17 0. 0.0 0.16 0. 0.0 ARMED 0.18 0. 0.0 0.17 0. 0.0 0.14 0.0003 0.4 ARMED 0.16 0.0063 0.00102 0.17 0. 0.0 0.16 0. 0.0 ARMED 0.16 0.0036 0.00056 0.16 0. 0.0 0.16 0. 0.0 ARMED 0.17 0. 0.0 0.16 0. 0.0 0.16 0. 0.0 ARMED 0.18 0. 0.0 0.16 0. 0.0 0.15 0.0018 0.00027 ARMED 0.15 0. 0.0 0.17 0. 0.0 0.16 0.0001 0.1 ARMED 0.17 0.0049 0.00082 0.17 0. 0.0 0.15 0. 0.0 ARMED 0.16 0.0063 0.00102 0.17 0. 0.0 0.15 0. 0.0 ARMED 0.16 0. 0.0 0.14 0.0028 0.00040 0.17 0. 0.0 ARMED 0.17 0.0027 0.00044 0.17 0. 0.0 0.15 0. 0.0 ARMED 0.17 0.0036 0.00060 0.17 0. 0.0 0.15 0. 0.0 ARMED 0.16 0.0059 0.00092 0.17 0. 0.0 0.16 0. 0.0 ARMED 0.16 0. 0.0 0.16 0.0028 0.00043 0.17 0. 0.0 ARMED 0.16 0. 0.0 0.15 0.0015 0.00023 0.16 0. 0.0 ARMED 0.16 0. 0.0 0.17 0. 0.0 0.16 0. 0.0 ARMED 0.16 0. 0.0 0.16 0.0015 0.00023 0.16 0. 0.0 ARMED 0.16 0.0036 0.00057 0.17 0. 0.0 0.16 0. 0.0 ARMED 0.18 0.0013 0.00023 0.16 0. 0.0 0.15 0. 0.0 ARMED 0.16 0. 0.0 0.16 0. 0.0 0.15 0.0028 0.00043 ARMED 0.17 0. 0.0 0.17 0. 0.0 0.16 0.0020 0.00031 ARMED 0.17 0. 0.0 0.15 0. 0.0 0.15 0.0030 0.00046 ARMED 0.16 0. 0.0 0.17 0.0011 0.00018 0.17 0. 0.0 ^C VDD_VCORE1: 0.14V 0.165Vavg 0.20V, 0.A 0.00091Aavg 0.0063A, 0.00W 0.000146Wavg 0.001208W VDD_VCORE2: 0.13V 0.162Vavg 0.19V, 0.A 0.00037Aavg 0.0032A, 0.00W 0.58Wavg 0.000512W VDD_VCORE3: 0.13V 0.159Vavg 0.19V, 0.A 0.00043Aavg 0.0030A, 0.00W 0.67Wavg 0.000544W exited I noticed that on this laptop with USB3 ports, AEP won't work plugged in direct (LMP, using a similar NXP chip are the same). They need to be connected via a USB2 hub in order to work. Maybe that's something to do with it. -Andy From: Andy Green [andy.gr...@linaro.org] Sent: 27 May 2013 14:14 To: Robert Brehm Cc: linaro-dev@lists.linaro.org Subject: Re: arm-probe (with ARM Energy probe) On 27/05/13 16:53, the mail apparently from Robert Brehm included: Hi, I have downloaded and compiled/installed (on Ubuntu 12.04 the arm-probe from: https://git.linaro.org/gitweb?p=tools/arm-probe.git;a=tree Now I am facing some issues using the tool. My Arm Energy Probe shows up as virtual serial port as /dev/ttyACM0 and I am able to open that port via “ # sudo screen /dev
Re: [ANNOUNCE] linux-linaro kernel schedule for 13.05 published
On 16/05/13 02:59, the mail apparently from Andrey Konovalov included: On 05/15/2013 12:04 AM, Andrey Konovalov wrote: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule The 13.05 linux-linaro release will be v3.10-rc2 based, May 15: v3.10-rc1 based linux-linaro-core-tracking (llct) rebuild Thanks Andrey, we were looking forward to that. -Andy * Done: the tag is llct-20130515.1 * Changes: . the 3.8-based binder topic re-added . kernel/printk.c: build error in CONFIG_DEBUG_LL=y case fixed . ARM: crypto: sha1-armv4-large.S: fix SP handling patch needed to enable CONFIG_CRYPTO_SHA1_ARM The next step is: May 16: ll rebuild based on llct-20130515.1 The last llct update for this cycle is scheduled on May 21, The last linux-linaro update for this cycle is scheduled on May 23. May 23 is the linux-linaro code freeze for 13.05 (only bug fixes allowed after this date). Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Andy Green | Fujitsu Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: automated build coverage
On 13/05/13 16:12, the mail apparently from Nicolas Dechesne included: On Thu, May 9, 2013 at 7:56 PM, Fathi Boudra fathi.bou...@linaro.org mailto:fathi.bou...@linaro.org wrote: Hi all, I just wanted to forward this thread from LAKML to linaro-dev: http://article.gmane.org/gmane.linux.ports.tegra/10683 Seems there is lots desire for an improvement to automated build coverage and automated reporting along with it. I replied to it. We've got already such daily builds with boot testing: https://ci.linaro.org/jenkins/view/kernel-ci I'm surprised that some people involved in Linaro and this thread didn't mentioned it. Anyway, it's a good opportunity to remind people that we've got a Kernel CI and I'll be happy to get more feedback to improve it. Hi Fathi, I have to admit that what we do in terms of Kernel CI is still a bit fuzzy to me, even now that I am an insider. When I was at TI and working closely with the TI Landing team, I don't believe we ever reached the point where Linaro kernel CI was useful for the 'products' we were jointly doing. Now that I am at Linaro, I am going to need LAVA and kernel CI for our project shortly. I have no doubt that what is being is worthwhile, but I believe a little bit of marketing and/or presentation would be very welcome. It might be nice to highlight the bugs that have been found (and fixed?) *thanks to* Linaro kernel CI too, for example. also in the link above all of the 7 'active' jobs are failing with 3 of them who always failed, and 2 of them failing for 2 weeks. so it's not clear what that means. i am sure it doesn't mean that none of our kernel ever boots ;-) if we want Kernel CI to be useful and kernel devs to rely on it, it should work all the time, so that failure are quickly identified and fixed. maybe this is why Linaro Kernel CI was not mentioned by Linaro people in that thread. I think TI use of CI only evolved as far as compiling the thing, it's not hooked up to any actual testing. The error mails we are still getting spammed with are partly my fault. Previously, LAVA would remain silent if a build failed. That is quite a bad situation if you're committing to that tree, and the last thing you heard was everything is good then the build machine has a problem and stops testing. You can have committed something that broke build even, but continue thinking everything is good because nothing is telling you that it's not actually in test any more. So after some prompting from me pointing out that false sense of security undermines the point of LAVA, now we get notifications that the build attempt failed. However since I didn't touch tilt-3.4 or tilt-tracking for months, it's surprising the number of failure reports we periodically get that are basically Lava infrastructure choking on trying to build it, not any actual problems. -Andy -- Andy Green | Fujitsu Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mali-ization
On 17/04/13 19:11, the mail apparently from Jon Medhurst (Tixy) included: On Wed, 2013-04-17 at 16:28 +0530, Tushar Behera wrote: On 04/16/2013 09:46 AM, Andy Green wrote: On 16/04/13 10:08, the mail apparently from Selina Kuo included: Hi, John, Your assumption is right. The ump code is part of the out-of-tree mali driver. - Selina Kuo, one of Andy's colleagues ^^ As Selina says it's a code drop we got via Fujitsu from ARM for the OOT Mali driver. However that code is all GPL2, as it should be. I think any of the options are good, - make our own repo and keep it in sync with llct - privately encourage ARM to keep it in sync with Linus' HEAD, publicly - upstream it so it's always in sync This obviously helps of all LT who want to / can harmonize their tree on llct basis. Tushar, do you have any opinion? It would always help to have the Mali driver synced with latest upstream and getting merged into 'llct'. The LT's who need to use this driver can have their modifications (if any) on top of it. Each LT will have to make sure that their changes are suitably guarded with #ifdefs to avoid stepping on each other's toes. But then that isn't going to work with a multi-platform kernel. So the changes are going to need to be made run-time configurable based on device-tree or something. Speaking of device-tree, do the Mali drivers have device-tree support? Nope... this will be a basis that other branches patch on top of if they want to modify. If it does happen that xyz-LT had special sauce, they'll have a branch like xyz-mali-t6xx-tracking which is mali-t6xx-tracking with their patches on top, and they'll follow by rebase. Having been there before and survived 2,500 patch loads on top of a rebase tree, trust me this one is trivial to deal with. Obviously it is nicer if eventually the changes for supporting different IP revisions cleanly, and any member special sauces (if any) are merged in one tree. But it is not necessary and everyone is ahead just by having a basis tree for the OOT module that actually builds againt llct, as Tushar noted. -Andy -- Andy Green | Fujitsu Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mali-ization
On 16/04/13 14:29, the mail apparently from Jon Medhurst (Tixy) included: On Tue, 2013-04-16 at 12:16 +0800, Andy Green wrote: On 16/04/13 10:08, the mail apparently from Selina Kuo included: Hi, John, Your assumption is right. The ump code is part of the out-of-tree mali driver. - Selina Kuo, one of Andy's colleagues ^^ As Selina says it's a code drop we got via Fujitsu from ARM for the OOT Mali driver. However that code is all GPL2, as it should be. I assume it's not for as yet unreleased IP and under NDA or anything. (Just thought I would throw that in there.) Is T624 secret for ARM atm? It's just the kernelside bits we're talking about not the userland. I think any of the options are good, - make our own repo and keep it in sync with llct - privately encourage ARM to keep it in sync with Linus' HEAD, publicly - upstream it so it's always in sync This obviously helps of all LT who want to / can harmonize their tree on llct basis. Tushar, do you have any opinion? Anyone who dealt with this code or at ARM (Tixy?) I've never dealt with this code but one thing occurs to me: how would you manage the user side binary blob? If different members have different versions of the blobs (or have tweaked them) are they all going to work with a common version of the kernel driver or have different members tweaked things for there own needs? It's an issue but it is a bit separate. If they will build their userland to work with a particular kernel + module at all, they all need to have module sources that work against that kernel to start with. Right now if what we have is representative, it's pretty lagging in that regard. So this effort will give them a starting point that always builds (and hopefully works) they can maintain patches on top of. It's not for unifying all variations, unless people want to contribute and maintain them. It's still enough that they can approach tracking Linus HEAD knowing they only need to take care of their patch content for uplevel purposes, and not take care of the bulk of the module. -Andy -- Andy Green | Fujitsu Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mali-ization
On 16/04/13 17:39, the mail apparently from Selina Kuo included: On 16 April 2013 16:20, Andy Green andy.gr...@linaro.org wrote: On 16/04/13 14:29, the mail apparently from Jon Medhurst (Tixy) included: On Tue, 2013-04-16 at 12:16 +0800, Andy Green wrote: On 16/04/13 10:08, the mail apparently from Selina Kuo included: Hi, John, Your assumption is right. The ump code is part of the out-of-tree mali driver. - Selina Kuo, one of Andy's colleagues ^^ As Selina says it's a code drop we got via Fujitsu from ARM for the OOT Mali driver. However that code is all GPL2, as it should be. I assume it's not for as yet unreleased IP and under NDA or anything. (Just thought I would throw that in there.) Is T624 secret for ARM atm? It's not secret for ARM. The latest version of MaliT624 kernel driver was released on 2013 March. http://malideveloper.arm.com/develop-for-mali/drivers/open-source-mali-t6xx-gpu-kernel-device-drivers/ The latest version on website is the same with the latest one which I got via Fujitsu from ARM. Thanks... since that ARM page makes it clear it is GPL2, I pushed it here https://git.linaro.org/gitweb?p=landing-teams/working/fujitsu/mali-t6xx-tracking.git;a=summary with our modifications as a starting point. -Andy It's just the kernelside bits we're talking about not the userland. I think any of the options are good, - make our own repo and keep it in sync with llct - privately encourage ARM to keep it in sync with Linus' HEAD, publicly - upstream it so it's always in sync This obviously helps of all LT who want to / can harmonize their tree on llct basis. Tushar, do you have any opinion? Anyone who dealt with this code or at ARM (Tixy?) I've never dealt with this code but one thing occurs to me: how would you manage the user side binary blob? If different members have different versions of the blobs (or have tweaked them) are they all going to work with a common version of the kernel driver or have different members tweaked things for there own needs? It's an issue but it is a bit separate. If they will build their userland to work with a particular kernel + module at all, they all need to have module sources that work against that kernel to start with. Right now if what we have is representative, it's pretty lagging in that regard. So this effort will give them a starting point that always builds (and hopefully works) they can maintain patches on top of. It's not for unifying all variations, unless people want to contribute and maintain them. It's still enough that they can approach tracking Linus HEAD knowing they only need to take care of their patch content for uplevel purposes, and not take care of the bulk of the module. -Andy -- Andy Green | Fujitsu Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog -- Andy Green | Fujitsu Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mali-ization
On 16/04/13 10:08, the mail apparently from Selina Kuo included: Hi, John, Your assumption is right. The ump code is part of the out-of-tree mali driver. - Selina Kuo, one of Andy's colleagues ^^ As Selina says it's a code drop we got via Fujitsu from ARM for the OOT Mali driver. However that code is all GPL2, as it should be. I think any of the options are good, - make our own repo and keep it in sync with llct - privately encourage ARM to keep it in sync with Linus' HEAD, publicly - upstream it so it's always in sync This obviously helps of all LT who want to / can harmonize their tree on llct basis. Tushar, do you have any opinion? Anyone who dealt with this code or at ARM (Tixy?) FWIW our TSC rep is aware of this and I believe would support whatever the best-looking of these solutions is. -Andy On 16 April 2013 07:50, John Stultz john.stu...@linaro.org wrote: On 04/13/2013 03:22 AM, Andy Green wrote: On 13/04/13 09:07, the mail apparently from Andy Green included: I'm hoping someone else will write the patches ^^ but if not I'll try to sort something out. The attached series gets it building cleanly against current llct with ION. Cool. Although the patches look like they are all against the ump driver(which I'm not familiar with), as opposed to changes to the ION infrastructure itself. So they won't apply to the AOSP trees, and I can't send them upstream. I assume the ump code is part of the out-of-tree mali driver? Looking at llct, I don't see a drivers/base/ump directory. https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=tree;f=drivers/base;h=cbad2d664fa248ec366430dbd1724b2959ae43ee;hb=refs/heads/linux-linaro-core-tracking But I'm guessing this is the point of your original mail in this thread: we need a mali tree upon which fixes like these can be applied and then pulled into llct. Or even better, can we get the mali devs to publish a repo of their latest work (to which fixes like Andy's can be submitted to) which can also be pulled into llct? thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Andy Green | Fujitsu Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mali-ization
On 13/04/13 18:22, the mail apparently from Andy Green included: On 13/04/13 09:07, the mail apparently from Andy Green included: I'm hoping someone else will write the patches ^^ but if not I'll try to sort something out. The attached series gets it building cleanly against current llct with ION. It can't be tested on my side atm. There's one funny, WARNING: v7_dma_flush_range [/projects/linaro/mali-t624/kernel/drivers/base/ump/src/ump.ko] undefined! that does seem to still be around in arch/arm/mm/cache-v7.S, maybe it's not exported suitably or I missed the point (and perhaps someone who recognizes this kind of thing can educate me). The version we got is not Device Tree -ready either. The probe() in gpu/arm/t6xx/kbase/src/linux/mali_kbase_core_linux.c insists on platform_data. However they seems to use an accessor kbasep_get_config_value() in gpu/arm/t6xx/kbase/src/common/mali_kbase_config.c to touch that structured platform_data in a way that would make it simple to add DT support. The code doesn't conform to kernel style much, but that's not hard to fix... has anyone thought of actually upstreaming this? -Andy -- Andy Green | Fujitsu Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mali-ization
On 13/04/13 09:07, the mail apparently from Andy Green included: I'm hoping someone else will write the patches ^^ but if not I'll try to sort something out. The attached series gets it building cleanly against current llct with ION. It can't be tested on my side atm. There's one funny, WARNING: v7_dma_flush_range [/projects/linaro/mali-t624/kernel/drivers/base/ump/src/ump.ko] undefined! that does seem to still be around in arch/arm/mm/cache-v7.S, maybe it's not exported suitably or I missed the point (and perhaps someone who recognizes this kind of thing can educate me). -Andy -- Andy Green | Fujitsu Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog clean-mali-t624.tar.gz Description: application/gzip ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Mali-ization
Hi - At the moment the Mali T624 OOT module sources I have do not build against 3.9-rcX / linux-linaro-core-tracking. A colleague checked it and it does build against 3.4. The problems I saw are around ION compatibility but they didn't look tremendously bad. I could work around the problems myself, but it seems to me this might be something that Linaro could solve centrally, dealing with it using the Androidization model - sync a Linaro repo against code drops coming from upstream, ie, ARM, but keep it always building against llct inbetween. Perhaps even inside llct. I know we're not the only LT in this boat, Anmar mentioned Arndale acceleration is pending, a central Mali-ization tree will also solve that, especially if it's always there and always building in llct already. There may be stuff to take care about for support for different IP revision. But there aren't that many AFAIK. How does this sound to folks? -Andy -- Andy Green | Fujitsu Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mali-ization
On 13/04/13 08:50, the mail apparently from John Stultz included: On 04/12/2013 05:34 PM, Andy Green wrote: Hi - At the moment the Mali T624 OOT module sources I have do not build against 3.9-rcX / linux-linaro-core-tracking. A colleague checked it and it does build against 3.4. The problems I saw are around ION compatibility but they didn't look tremendously bad. Any details on what the ION compatibility issues are? Build with ION looks like this atm pwd=/projects/linaro/mali-t624/kernel/drivers/gpu/arm/t6xx/kbase make -C /projects/linaro/mali-t624/kernel/drivers/gpu/arm/t6xx/kbase/../../../../../../kernel/drivers/base/kds make[1]: Entering directory `/projects/linaro/mali-t624/kernel/drivers/base/kds' make ARCH=arm -C /projects/linaro/mali-t624/kernel/../../linux-2.6/panda M=/projects/linaro/mali-t624/kernel/drivers/base/kds EXTRA_CFLAGS=-I/projects/linaro/mali-t624/kernel/drivers/base/kds/../../../include CONFIG_KDS=m make[2]: Entering directory `/projects/linaro/linux-2.6/panda' LD /projects/linaro/mali-t624/kernel/drivers/base/kds/built-in.o CC [M] /projects/linaro/mali-t624/kernel/drivers/base/kds/kds.o Building modules, stage 2. MODPOST 1 modules CC /projects/linaro/mali-t624/kernel/drivers/base/kds/kds.mod.o LD [M] /projects/linaro/mali-t624/kernel/drivers/base/kds/kds.ko make[2]: Leaving directory `/projects/linaro/linux-2.6/panda' make[1]: Leaving directory `/projects/linaro/mali-t624/kernel/drivers/base/kds' make -C /projects/linaro/mali-t624/kernel/drivers/gpu/arm/t6xx/kbase/../../../../../../kernel/drivers/base/ump/src make[1]: Entering directory `/projects/linaro/mali-t624/kernel/drivers/base/ump/src' make ARCH=arm -C /projects/linaro/mali-t624/kernel/../../linux-2.6/panda M=/projects/linaro/mali-t624/kernel/drivers/base/ump/src EXTRA_CFLAGS=-I/projects/linaro/mali-t624/kernel/drivers/base/ump/src/../../../../include -DCONFIG_UMP -DCONFIG_MALI_DEBUG -DCONFIG_MALI_PLATFORM_FAKE -DCONFIG_MALI_PLATFORM_VEXPRESS -DCONFIG_MALI_UNCACHED -DCONFIG_MALI_GATOR_SUPPORT -DCONFIG_KDS CONFIG_UMP=m KBUILD_EXTRA_SYMBOLS= /projects/linaro/mali-t624/kernel/drivers/base/ump/src/../../../../../kernel/drivers/base/kds/Module.symvers modules make[2]: Entering directory `/projects/linaro/linux-2.6/panda' CC [M] /projects/linaro/mali-t624/kernel/drivers/base/ump/src/common/ump_kernel_core.o CC [M] /projects/linaro/mali-t624/kernel/drivers/base/ump/src/common/ump_kernel_descriptor_mapping.o CC [M] /projects/linaro/mali-t624/kernel/drivers/base/ump/src/linux/ump_kernel_linux.o CC [M] /projects/linaro/mali-t624/kernel/drivers/base/ump/src/linux/ump_kernel_linux_mem.o LD [M] /projects/linaro/mali-t624/kernel/drivers/base/ump/src/ump.o CC [M] /projects/linaro/mali-t624/kernel/drivers/base/ump/src/imports/ion/ump_kernel_import_ion.o /projects/linaro/mali-t624/kernel/drivers/base/ump/src/imports/ion/ump_kernel_import_ion.c: In function ‘import_ion_client_create’: /projects/linaro/mali-t624/kernel/drivers/base/ump/src/imports/ion/ump_kernel_import_ion.c:52:2: warning: passing argument 2 of ‘ion_client_create’ makes pointer from integer without a cast [enabled by default] In file included from /projects/linaro/mali-t624/kernel/drivers/base/ump/src/imports/ion/ump_kernel_import_ion.c:17:0: /projects/linaro/linux-2.6/include/linux/ion.h:128:20: note: expected ‘const char *’ but argument is of type ‘unsigned int’ /projects/linaro/mali-t624/kernel/drivers/base/ump/src/imports/ion/ump_kernel_import_ion.c:52:2: error: too many arguments to function ‘ion_client_create’ In file included from /projects/linaro/mali-t624/kernel/drivers/base/ump/src/imports/ion/ump_kernel_import_ion.c:17:0: /projects/linaro/linux-2.6/include/linux/ion.h:128:20: note: declared here /projects/linaro/mali-t624/kernel/drivers/base/ump/src/imports/ion/ump_kernel_import_ion.c: In function ‘import_ion_final_release_callback’: /projects/linaro/mali-t624/kernel/drivers/base/ump/src/imports/ion/ump_kernel_import_ion.c:79:2: error: implicit declaration of function ‘ion_unmap_dma’ [-Werror=implicit-function-declaration] /projects/linaro/mali-t624/kernel/drivers/base/ump/src/imports/ion/ump_kernel_import_ion.c: In function ‘import_ion_import’: /projects/linaro/mali-t624/kernel/drivers/base/ump/src/imports/ion/ump_kernel_import_ion.c:112:2: error: implicit declaration of function ‘ion_import_fd’ [-Werror=implicit-function-declaration] /projects/linaro/mali-t624/kernel/drivers/base/ump/src/imports/ion/ump_kernel_import_ion.c:112:23: warning: assignment makes pointer from integer without a cast [enabled by default] /projects/linaro/mali-t624/kernel/drivers/base/ump/src/imports/ion/ump_kernel_import_ion.c:119:2: error: implicit declaration of function ‘ion_map_dma’ [-Werror=implicit-function-declaration] /projects/linaro/mali-t624/kernel/drivers/base/ump/src/imports/ion/ump_kernel_import_ion.c:119:19: warning: assignment makes pointer from integer without a cast [enabled
Re: kernel NULL pointer dereference
On 28/01/13 21:10, the mail apparently from Renato Golin included: On 28 January 2013 12:43, Andy Green andy.gr...@linaro.org mailto:andy.gr...@linaro.org wrote: Without this or something doing a similar deal, a Panda ES will blow chunks after a short period at 1.2GHz. Hi Andy, I agree kernel panic is better than blowing up the board, but that might indicate the scaling is not working very well. Also, does that mean I should not use the 12.02 image because the risk of blowing up my board? No, blowing chunks (slang for vomiting) is different than blowing up... the 4460 has a separate comparator that is able to reset the SoC if it gets really too hot. It will crash colourfully before then is what I mean, unless one of these thermal mechanisms is helping. It varies by chip actually, some can idle at 1.2GHz for a long time before choking others crash in a few seconds. I can't really remember the status a year ago, we had it working a while before Panda ES was available IIRC. I did not hear of any actually burned 4460, I think the reset mechanism will save it. Tilt-3.3 and -3.4 should be fine at least. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Fwd: Re: Fwd: trouble using wifi on Linaro Ubuntu for Pandaboard
Original Message Subject:Re: Fwd: trouble using wifi on Linaro Ubuntu for Pandaboard Date: Sun, 18 Nov 2012 22:13:57 -0800 (PST) From: Alex Stefanescu stefane...@rice.edu Reply-To: Alex Stefanescu stefane...@rice.edu To: Andy Green andy.gr...@linaro.org Thank you for the reply. It worked! -- Alex Stef *From:* Andy Green andy.gr...@linaro.org *To:* Fathi Boudra fathi.bou...@linaro.org *Cc:* Alex Stefanescu stefane...@rice.edu; linaro-dev linaro-dev@lists.linaro.org *Sent:* Sunday, November 18, 2012 9:21 PM *Subject:* Re: Fwd: trouble using wifi on Linaro Ubuntu for Pandaboard On 11/18/12 16:24, the mail apparently from Fathi Boudra included: Wrong mailing list, forwarding lo linaro-dev -- Forwarded message -- From: Alex Stefanescu stefane...@rice.edu mailto:stefane...@rice.edu Date: 18 November 2012 02:09 Subject: trouble using wifi on Linaro Ubuntu for Pandaboard Hello, I'm having trouble connecting to wifi on the Linaro Ubuntu releases for the Pandaboard. I've tried with both 12.10 and 12.09 releases, which are listed to have passed the wifi test. ... I'm using Pandaboard with OMAP4430 and wl1271 wlan chipset. I've also tried running wpa_supplicant manually to connect to both the same open network, or another one secured with WPA2 (I used the wpa_supplicant.conf from an Android phone so I'm pretty sure it was correct) and I have the same issue. There is also a wpa_supplicant always running in the background, does it matter? Yes you can't have two wpa_supplicants fighting over the state of the same wireless interface. The by hand method for the WPA2 network -- # service network-manager stop # wpa_passphrase Rice Visitor /etc/wpa_supplicant/wpa_supplicant.conf (type the AP passphrase and enter) # wpa_supplicant -Dwext -iwlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf (should associate after a second or two) # dhclient wlan0 At that point you should have an IP on wlan0, default route and DNS configured and workable. For unencrypted AP by hand, you don't use wpa_supplicant. # service network-manager stop # killall wpa_supplicant # iwlist wlan0 scan (find your AP, use its info below) # ifconfig wlan0 up # iwconfig wlan0 essid Unencypted AP Name # iwconfig wlan0 chan 11 # iwconfig wlan0 ap 00:1F:12:34:56:78 (check if associated) # iwconfig wlan0IEEE 802.11abgn ESSID:Unencrypted AP Name Mode:Managed Frequency:2.462 GHz Access Point: 00:1F:12:34:56:78 Bit Rate=72.2 Mb/s Tx-Power=20 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on Link Quality=40/70 Signal level=-70 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:2 Missed beacon:0 # dhclient wlan0 Again your connection should have DNS, route and be workable. If you're missing some of these commands make sure you have dhcp3-client and wireless-tools packages. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Fwd: trouble using wifi on Linaro Ubuntu for Pandaboard
On 11/18/12 16:24, the mail apparently from Fathi Boudra included: Wrong mailing list, forwarding lo linaro-dev -- Forwarded message -- From: Alex Stefanescu stefane...@rice.edu Date: 18 November 2012 02:09 Subject: trouble using wifi on Linaro Ubuntu for Pandaboard Hello, I'm having trouble connecting to wifi on the Linaro Ubuntu releases for the Pandaboard. I've tried with both 12.10 and 12.09 releases, which are listed to have passed the wifi test. ... I'm using Pandaboard with OMAP4430 and wl1271 wlan chipset. I've also tried running wpa_supplicant manually to connect to both the same open network, or another one secured with WPA2 (I used the wpa_supplicant.conf from an Android phone so I'm pretty sure it was correct) and I have the same issue. There is also a wpa_supplicant always running in the background, does it matter? Yes you can't have two wpa_supplicants fighting over the state of the same wireless interface. The by hand method for the WPA2 network -- # service network-manager stop # wpa_passphrase Rice Visitor /etc/wpa_supplicant/wpa_supplicant.conf (type the AP passphrase and enter) # wpa_supplicant -Dwext -iwlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf (should associate after a second or two) # dhclient wlan0 At that point you should have an IP on wlan0, default route and DNS configured and workable. For unencrypted AP by hand, you don't use wpa_supplicant. # service network-manager stop # killall wpa_supplicant # iwlist wlan0 scan (find your AP, use its info below) # ifconfig wlan0 up # iwconfig wlan0 essid Unencypted AP Name # iwconfig wlan0 chan 11 # iwconfig wlan0 ap 00:1F:12:34:56:78 (check if associated) # iwconfig wlan0 IEEE 802.11abgn ESSID:Unencrypted AP Name Mode:Managed Frequency:2.462 GHz Access Point: 00:1F:12:34:56:78 Bit Rate=72.2 Mb/s Tx-Power=20 dBm Retry long limit:7 RTS thr:off Fragment thr:off Encryption key:off Power Management:on Link Quality=40/70 Signal level=-70 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:2 Missed beacon:0 # dhclient wlan0 Again your connection should have DNS, route and be workable. If you're missing some of these commands make sure you have dhcp3-client and wireless-tools packages. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Test Result Summary of Calendar Week 45 for Linaro ubuntu.
On 11/09/12 15:20, the mail apparently from Botao Sun included: Hi - 3. Panda 4430 + ubuntu (Column AD): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZkhrZ1VYUEg2LTlQZzR0RlhzM3c#gid=0 Audio works. Dead lock error still exists in boot log, and the issues Audio has been working for months kernelside FWIW, I'm glad it's caught up in these tests. still exist in power management and Bluetooth. All other features remain the same status. BT has always been a bit fragile. There exists a bunch of patches and changes in TI Android that make it super good apparently, I don't think status of BT will change unless we get these. Which may happen. 4. Panda 4460 + ubuntu (Column AC): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZkhrZ1VYUEg2LTlQZzR0RlhzM3c#gid=1 Exactly same status as previous test result. Audio input is unavailable I was using PandaBoard ES audio input over the weekend perfectly well, whatever the problem there it's not a problem with the kernel. and dead lock error exists in boot log, although no significant effect to system. That locking log warning is coming from the SGX driver. They seem content to ship it like that and despite it sounds dire it doesn't make trouble. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Test Result Summary of Calendar Week 45 for Linaro ubuntu.
On 11/12/12 11:57, the mail apparently from Botao Sun included: Hi Andy, The Audio input on Panda 4460 always bothers me. My microphone works well on my PC, Vexpress A9 board, but never works on Panda 4460. The plug is a standard 3 parts one. How did you work out this issue? With a line in cable? Yes the situation there is not as simple as it could be. Neither Panda will accept a microphone in the line in socket. They don't provide MICBIAS to power the microphone. 4430 PandaBoard wires Line In to headset microphone input on the audio chip. Confusingly that is Mono and we think differential. What gets recorded there is the difference between the L and R signal we believe. So you should just play silence on one channel and your signal on the other to get a good result. The result will be a fake stereo file with the same mono capture on both channels. 4460 PandaBoard ES fixed that by wiring Line In socket to AuxFM L+R on the audio chip instead, which act like normal, 2 x single-ended inputs. So you can record in stereo properly there. However even then L + R are swapped at the connector compared to the output ^^ UCM stuff knows about the differences; the ALSA driver calls the card differently between PandaBoard and PandaBoardES sso the UCM stuff can route headset mic or AuxFM for capture accordingly. One other gotcha, they both only issue S32_LE sample format, not the more common S16_LE. Here's a magic capture script that works on both without relying on UCM or other things. #!/bin/sh amixer cset name='MUX_UL00' 'AMic0' amixer cset name='MUX_UL01' 'AMic1' if [ -z `cat /proc/asound/cards | grep PandaBoardES` ] ; then amixer cset name='Analog Left Capture Route' 'Headset Mic' amixer cset name='Analog Right Capture Route' 'Headset Mic' else amixer cset name='Analog Left Capture Route' 'Aux/FM Left' amixer cset name='Analog Right Capture Route' 'Aux/FM Right' fi amixer cset name='Capture Preamplifier Volume' 2 amixer cset name='Capture Volume' 4 arecord -v -v -D hw:0,0 -d 5 -f s32_LE -c 2 -r 48000 record.wav -Andy On Mon, Nov 12, 2012 at 2:51 PM, Andy Green andy.gr...@linaro.org mailto:andy.gr...@linaro.org wrote: On 11/09/12 15:20, the mail apparently from Botao Sun included: Hi - 3. Panda 4430 + ubuntu (Column AD): https://docs.google.com/a/__linaro.org/spreadsheet/ccc?__key=__0AroPySpr4FnEdEwwZkhrZ1VYUEg2L__TlQZzR0RlhzM3c#gid=0 https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZkhrZ1VYUEg2LTlQZzR0RlhzM3c#gid=0 Audio works. Dead lock error still exists in boot log, and the issues Audio has been working for months kernelside FWIW, I'm glad it's caught up in these tests. still exist in power management and Bluetooth. All other features remain the same status. BT has always been a bit fragile. There exists a bunch of patches and changes in TI Android that make it super good apparently, I don't think status of BT will change unless we get these. Which may happen. 4. Panda 4460 + ubuntu (Column AC): https://docs.google.com/a/__linaro.org/spreadsheet/ccc?__key=__0AroPySpr4FnEdEwwZkhrZ1VYUEg2L__TlQZzR0RlhzM3c#gid=1 https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AroPySpr4FnEdEwwZkhrZ1VYUEg2LTlQZzR0RlhzM3c#gid=1 Exactly same status as previous test result. Audio input is unavailable I was using PandaBoard ES audio input over the weekend perfectly well, whatever the problem there it's not a problem with the kernel. and dead lock error exists in boot log, although no significant effect to system. That locking log warning is coming from the SGX driver. They seem content to ship it like that and despite it sounds dire it doesn't make trouble. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/__Linaro/155974581091106 http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/__linaroorg http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linux-linaro kernel trees move to 3.7 and 12.11 schedule
On 11/07/12 19:52, the mail apparently from Tushar Behera included: On 11/07/2012 01:40 AM, Andrey Konovalov wrote: Greetings, This cycle some more attention is given to the shape of the ci builds done from the llct tree (the ones with llct in their name at https://ci.linaro.org/jenkins/view/Linux%20Linaro%20Tracking/). See below. On 10/27/2012 12:39 PM, Andrey Konovalov wrote: The 12.11 linux-linaro kernel release will be v3.7-rc5 or v3.7-rc6 based. Please make sure to update your topics to 3.7. Here is the plan: * October 30: initial v3.7-rc3 based llct build, 3.6 based topics will not be included if there are conflicts Done. The tag is llct-20121101.1. v3.7-rc3 based. Origen failed to boot in LAVA (silence after Uncompressing Linux... done, booting the kernel.) I haven't tested it yet (llct), but it might be because of incorrect serial port number. I have tested v3.7-rc4 kernel with said change in config file, it works. Anyways, I will get back tomorrow after testing llct. FWIW we are currently retargeting on 3.7-rc4 I think + llct and then tracking. So there might be more than one hundreds of arch-specific patches LT kernels based on llct to bind together this time, making ll more than theoretically useful. -Andy mmc doesn't work on Panda when the kernel is built using the (old) config fragments (http://validation.linaro.org/lava-server/scheduler/job/37832/log_file). Panda boots ok with omap2plus_defconfig. vexpress boots ok. * November 6: updated big-LITTLE-MP topic arrives, llct rebuild (llct-20121106) Done. The tag is llct-20121106.0. v3.7-rc4 based. Android and big-LITTLE-MP topics are back. New Gator version (v5.12). *ubuntu-sauce topic will be dropped* Anyone objects? The same boot failure for Origen. Disabling device tree in the kernel config makes the kernel to start booting (http://validation.linaro.org/lava-server/scheduler/job/37885/log_file). Could be arch/arm/boot/dts/exynos4210-origen.dts issue. Thanks, Andrey * November 8: linux-linaro (ll) rebuild based on llct-20121106 * November 13: llct rebuild (llct-20121113) * November 15: ll rebuild based on llct-20121113 * November 20: llct rebuild (llct-20121120) * November 22: ll rebuild based on llct-20121120, ll code freeze (no massive ll topics updates after that; bugfixes only) (The dates above are milestones, there will be additional llct/ll rebuilds on other dates as well) The config fragment branches to be used in 12.11: git://git.linaro.org/kernel/configs.git , config-core-tracking and config-boards-tracking branches. Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] Energy/power monitoring within the kernel
=== Although the trace event makes it possible to obtain interesting information using perf, the user wouldn't be able to treat the energy meter as a normal data source. In particular there would be no way of creating a group of events consisting eg. of a normal leader (eg. cache miss event) triggering energy meter read. The only way to get this done is to implement a perf PMU backend providing environmental data to the user. In terms of like perf top don't think it'll be possible to know when to sample the acquisition hardware to tie the result to a particular line of code, even if it had the bandwidth to do that. Power readings are likely to lag activities on the cpu somewhat, considering sub-ns core clocks, especially if it's actually measuring the input side of a regulator. = High-level hwmon API and PMU = Current hwmon subsystem does not provide any abstraction for the measured values and requires particular drivers to create specified sysfs attributes than used by userspace libsensors. This makes the framework ultimately flexible and ultimately hard to access from within the kernel... What could be done here is some (simple) API to register the measured values with the hwmon core which would result in creating equivalent sysfs attributes automagically, but also allow a in-kernel API for values enumeration and access. That way the core could also register a hwmon PMU with the perf framework providing data from all compliant drivers. = A driver-specific PMU = Of course a particular driver could register its own perf PMU on its own. It's certainly an option, just very suboptimal in my opinion. Or maybe not? Maybe the task is so specialized that it makes sense? === Option 3: CPU power(energy) monitoring framework === And last but not least, maybe the problem deserves some dedicated API? Something that would take providers and feed their data into interested parties, in particular a perf PMU implementation and cpufreq governors? Maybe it could be an extension to the thermal framework? It already gives some meaning to a physical phenomena. Adding other, related ones like energy, and relating it to cpu cores could make some sense. If you turn the problem upside down to solve the representation question first, maybe there's a way forward defining the power tree in terms of regulators, and then adding something in struct regulator that spams readers with timestamped results if the regulator has a power monitoring capability. Then you can map the regulators in the power tree to real devices by the names or the supply stuff. Just a thought. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Planning topcs for inclusion in linux-linaro
On 06/10/12 08:52, the mail apparently from Ricardo Salveti included: On Fri, Oct 5, 2012 at 2:03 PM, Andrey Konovalov andrey.konova...@linaro.org wrote: On 10/05/2012 12:12 PM, Jon Medhurst (Tixy) wrote: On Thu, 2012-10-04 at 23:02 +0400, Andrey Konovalov wrote: don't we need some kind of notification system where you announce a plan to rebuild linux-linaro and give us a version of llct to base our LT branches off? Andrey, let's make sure this is properly communicated over time for the maintainers and linaro-dev, so everyone can understand and see the progress done (to prepare any kind of rebase/pull). If Andrey keeps llct reasonably following Linus HEAD (as he has been, kudos) - and keep a nice llc-3.6 with 3.6 stable pieces and any critical backport fix for other llct content appearing on it in parallel - you'll be solving everything needed on TILT side. Also, I assume we're not going to try to move to Linux 3.7 this month? That's correct. We didn't have the kernel.org release based (vs -rc based) Our plan is retarget on 3.6 basis next week and before long generate a tilt-3.6. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: llct stable trees
On 09/05/12 17:19, the mail apparently from Andy Green included: On 09/04/12 12:13, the mail apparently from Ricardo Salveti included: Hi - 1) Can we have linux stable point release content in tilt-3.4? Rather than my doing it, isn't it better to add it to llc-3.4 and merge it on the lt history tree periodically? That way every lt can get them from one place. I don't see why merging the stable release contents would be an issue. We could keep updating the tree based on stable-only releases, as long as we still have at least one Landing Team interested on consuming it. This would be another job that would probably be automated by Andrey's scripts. Right it should usually be simple, although don't forget there is quite a lot of avant garde content in llct, such as Androidization. Just today I saw Xavier at TI find that merging of stable had a patch conflicting with llct Androidization content. So, it turns out that is a good example. I researched the conflict and found a thread from RMK rejecting the patch 96714b5dfe283cd8ab13aac1f9ccb565064af152 that seems to have come in by Androidization series via llct. http://lists.infradead.org/pipermail/linux-arm-kernel/2010-May/014116.html We decided to take the kernel.org stable version of the patch 6019ae78aa65afe273da8c0dfeed8e89fb5edf8f which removes some locking evil in the Androidization version, which RMK noted opened up a horrible race. Xavier then found a ghastly bug that had previously been impossible to track down disappeared. So we now know that 96714b5dfe283cd8ab13aac1f9ccb565064af152 we had been happily pushing out on everyone in llct-3.4 is a terrible idea, not just for TILT but any kernel that has it in will suffer from very hard to reproduce mm instability under stress, and needs reverting in favour of the version that went in kernel.org stable. But now we know about that flaw in llct-3.4 should we not do something about it? -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
llct stable trees
Hi - We've been getting some good mileage from the llct-based tilt-3.4 history tree the last months. However a couple of points have been raised by TI which really boil down to being about the deal with llct post-release. We know that it goes on mutating and tracking as it should, but the release-specific version, like linux-linaro-3.4 just sits there afaik. The points raised were: 1) Can we have linux stable point release content in tilt-3.4? Rather than my doing it, isn't it better to add it to llc-3.4 and merge it on the lt history tree periodically? That way every lt can get them from one place. 2) What's the deal with things that were the latest and greatest at that time, ie, the best CMA or whatever series was in tracking, but after it got copied out to be linux-linaro-core-3.4, horrible bugs were fixed in linux-linaro-tracking? What's happening is that TI are sticking with these releases for a fair time as the basis for their release to customers. I can see there's tension between tracking-style fix it for the future, and backport to old and crusty things, there's also issue of testing, but there must be some cases where this makes some sense. Again people looking after the feature tree for llct are best placed to make those calls about, hm, that looks like it should maybe also go on the last couple of llc release trees. What do you think about this? -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: tilt-3.4 compilation broken
On 08/24/12 19:15, the mail apparently from Viresh Kumar included: Hi - Leave that. My fault :( I always use O=../some-folder for all compilation related commands and do all this with script every time (so no manual mistakes). But since some time i am observing the current source folder also gets dirty. Some time it complains for running make mrproper on source folder and sometimes gives above errors. make mrproper fixed this issue. Glad you're sorted... actually fwiw I also use scripted O= scheme for all builds here (it makes switching between different build contexts of same sources cheap) and I don't have any contamination of ./ happening. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Build failure for Omap
On 13/07/12 15:45, the mail apparently from Viresh Kumar included: On 12 July 2012 16:59, Scott Bambrough scott.bambro...@linaro.org mailto:scott.bambro...@linaro.org wrote: Try the omap4plus_defconfig. There is no such defconfig, only following are present: omap1_defconfig omap2plus_defconfig It looks like this combined tree is not ready for primetime. We provide and test with omap4plus_defconfig on the TI LT tree. It seems the combined tree isn't being tested equivalently at the moment. http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=summary If you're only currently interested in omap, try tilt-3.4 from there with omap4plus_defconfig. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Problem building Precise Ubuntu Desktop
On 07/03/12 03:47, the mail apparently from David Cullen included: Hello, Tom, On 7/2/2012 2:29 PM, Tom Gall wrote: That should work fine. What's important for cross assembling your own images is that qemu is reasonably up to date. Lucid is getting fairly old now. Speaking for myself I haven't built anything on lucid for some time. You have a good point about qemu. One of the reasons I created the Ubuntu 12.04 Server VM was to get a newer version of qemu-user-static. Ok. One thing to note. When using live build it doesn't actually build the packages, it just assembles images. It uses .debs which are found in all the various archives (including your own) to accomplish this. Well, that's not what I need. I need to rebuild the kernel. I'm just going to chroot into a copy of the root file system that I got from the image I downloaded from here: http://www.omappedia.com/wiki/Ubuntu_Pre-Built_Binaries That way, I can just install the linux-source package, build-essential, and whatever else I need in a self-contained environment. I originally started looking at the Linaro stuff because the armhf+omap4 Ubuntu image runs very slowly, even after installing the PowerSVG binary driver. However, when I loaded the 12.05 and 12.06 Linaro Ubuntu images, all I got was a black screen with a mouse pointer. After running some experiments here, I discovered that the Linaro Ubuntu images only work with displays that have a native resolution of 1920x1080. I tried to use kernel command line arguments to force the resolution to work with my 1680x1050 monitor, but my changes had no effect. I wanted to look at the kernel source for the Linaro Ubuntu image because I can probably figure out the correct kernel command line arguments from that. However, I could not figure out which git tree to use. The whole thing reminds me of the line from Zork: You are in a maze of twisty little passages, all alike. Just to be clear, the kernel is recognizing your monitor and coming up with kms OK at your native resolution? IIUI Xorg starts and you get a pointer you can move around but Xorg chokes somewhere. Did you have a look at the Xorg logs then, or try to come up in runlevel three and do startx at the terminal? If I did get the idea I am not sure recooking the kernel will change much, it's actually doing its side (as distinct from SGX module perhaps) okay from the sound of it. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Problem building Precise Ubuntu Desktop
On 03/07/12 22:03, the mail apparently from David Cullen included: Hello, Andy, On 7/3/2012 2:14 AM, Andy Green wrote: On 07/03/12 03:47, the mail apparently from David Cullen included: After running some experiments here, I discovered that the Linaro Ubuntu images only work with displays that have a native resolution of 1920x1080. I tried to use kernel command line arguments to force the resolution to work with my 1680x1050 monitor, but my changes had no effect. I wanted to look at the kernel source for the Linaro Ubuntu image because I can probably figure out the correct kernel command line arguments from that. However, I could not figure out which git tree to use. Just to be clear, the kernel is recognizing your monitor and coming up with kms OK at your native resolution? What's kms? But yes, the kernel appears to be driving the monitor at the native resolution. Kernel Mode Select. IIUI Xorg starts and you get a pointer you can move around but Xorg chokes somewhere. If Xorg choked, would I even have a mouse pointer? Right what I mean is Xorg + display manager and points south, ie, your desktop choked somewhere. Did you have a look at the Xorg logs then, or try to come up in runlevel three and do startx at the terminal? No. I'm not an expert at troubleshooting Xorg problems, so I didn't even think about doing any of that. I'll give it a shot and post my findings. You can often hear about problems in the display manager logs, for gdm it's /var/log/gdm/\:0-greeter.log I am not sure what it is on Ubuntu. If you do start X from the commandline, you will get valuable stderr coming quite deep into the whole desktop startup process. If I did get the idea I am not sure recooking the kernel will change much, it's actually doing its side (as distinct from SGX module perhaps) okay from the sound of it. After looking at the kernel source for another project, I was able to figure out how to pass LCD panel timings via the kernel command line to get the resolution I needed. So one reason I wanted to look at the Linaro kernel source was to try to figure out how to force the DVI output to use a specific resolution and bit depth. However, the image from here http://cdimage.ubuntu.com/releases/12.04/release/ubuntu-12.04-preinstalled-desktop-armhf+omap4.img.gz Well that is 12.04, the kernel will be quite different. does display the GUI properly on my monitor, so I know it can be done. This raises the question, What are the differences between the Ubuntu image and the Linaro image? If the primary difference is the kernel, then rebuilding the kernel may fix the problem. Well, good luck... I think a more certain result will come from finding some evidence from the desktop logs about where it gets stuck. However, the real reason I need to rebuild the kernel has nothing to do with getting the GUI working. Unfortunately, it is not obvious to me how to acquire the source to the kernel that goes with the image here http://releases.linaro.org/12.06/ubuntu/leb-panda/ Using apt, I can easily get the source for the Ubuntu image mentioned above. So, I will be sticking with the Ubuntu image for now. Ubuntu's Panda kernel as the Linaro Ubuntu LEB kernel, is based on our LT kernel here http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortlog;h=refs/heads/tilt-3.4 I don't know where they put the exact tree, but they basically set their own config similar to our omap4plus_defconfig and add a bunch of UBUNTU SAUCE patches on top, almost all of which are affecting generic kernel code. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Black screen when booting Ubuntu
On 06/30/12 02:23, the mail apparently from David Cullen included: Hello, linaro-dev, When I boot the Ubuntu desktop image available from http://releases.linaro.org/12.06/ubuntu/leb-panda/lt-panda-x11-base_20120626-139-ubuntu-desktop.img.bz2 all I see is a black screen and the mouse pointer. I see some messages on the console like [ 13.996887] (stk) : timed out waiting for ldisc to be un-installed [ 15.145019] (stk) :ldisc installation timeout These are from bluetooth, it's fixed on tilt-3.4 since three days ago. They don't mean anything except BT is broken. and [ 22.983459] omap-hdmi-audio-dai omap-hdmi-audio-dai: audio not supported [ 22.990631] omap-hdmi-audio-dai omap-hdmi-audio-dai: can't open interface omap-hdmi-audio-dai: -19 These are just telling that your HDMI link is not using a resolution that supports playing audio down it, and the desktop was trying to do that. My PandaBoard is connected to a Dell monitor with a native resolution of 1680 x 1050. Is this a problem? I don't think so. It's probably something to do with the current SGX (video accelerator) stuff in Ubuntu. Next week TI are providing a big update around SGX1.9 and other new features I guess that will impact it. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: alloc failed, but?
On 06/28/12 11:27, the mail apparently from Tom Gall included: Hi All, I'm stressing a system with apachebench. As one scales up work on a system obviously there's always a point where the wheels fall off, the engine explodes or something else exciting happens. But as Han Solo would say ... hold together baby, I'd like to eek out as much as I can. (If you're really interested, here's what I'm up to : http://fullshovel.wordpress.com/ start with part 1) In this case with apachebench, I'm geting the following allocation errors in the kernel and need a little help deciphering. It sure looks like there's plenty of space to swap out however if I have this right, we're getting so much network traffic that the kernel gets inundated and it OOMs in the network stack. I did later try setting sysctl -w vm.min_free_kbytes=32768 but that didn't really seem to help. The much more complete dmesg dump is located at http://people.linaro.org/~tgall/dmesg-dump.txt [127100.245117] swapper/0: page allocation failure: order:3, mode:0x20 [127100.245666] [80100f14] (__alloc_pages_nodemask+0x678/0x7a4) from [80695270] (kmem_getpages.isra.35+0x3c/0xc0) [127100.245666] [80695270] (kmem_getpages.isra.35+0x3c/0xc0) from [80695380] (cache_grow.constprop.37+0x8c/0x1fc) [127100.245666] [80695380] (cache_grow.constprop.37+0x8c/0x1fc) from [8069570c] (cache_alloc_refill+0x21c/0x274) [127100.245819] [8069570c] (cache_alloc_refill+0x21c/0x274) from [80132dac] (__kmalloc_track_caller+0xac/0x1b0) [127100.245910] [80132dac] (__kmalloc_track_caller+0xac/0x1b0) from [8057a37c] (__alloc_skb+0x60/0xfc) [127100.245971] [8057a37c] (__alloc_skb+0x60/0xfc) from [8057a874] (__netdev_alloc_skb+0x2c/0x54) [127100.245971] [8057a874] (__netdev_alloc_skb+0x2c/0x54) from [8049dbb8] (rx_submit+0x2c/0x1d4) [127100.245971] [8049dbb8] (rx_submit+0x2c/0x1d4) from [8049e1c0] (rx_complete+0x1a4/0x1b8) [127100.245971] [8049e1c0] (rx_complete+0x1a4/0x1b8) from [804a5f38] (usb_hcd_giveback_urb+0xb0/0xfc) [127100.246246] [804a5f38] (usb_hcd_giveback_urb+0xb0/0xfc) from [804b887c] (ehci_urb_done+0xb8/0xc4) [127100.246246] [804b887c] (ehci_urb_done+0xb8/0xc4) from [804bb240] (qh_completions+0xc8/0x49c) Just some not directly useful extra info... I noticed these yesterday in dmesg as well while adding the 32K min_free_kybytes in tilt-3.4 as a hack. It seems to be part of some syndrome with smsc driver and network memory allocation that's in mainline and not Panda-specific. Yesterday I saw in Google the same problems plaguing Raspberry Pi folks. When I recently tried to stress the Panda a week or so ago by cloning gcc with a plan to compile it, in fact it lost sanity during the download with a storm of these kevent lost messages, hence the 32K hack being added. I also remember the same problems about kevents being dropped getting looked at like a year ago without any solid result, it'll be interesting if anyone understands and can explain what the underlying issue is. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] Can we use mmcblk0p8?
On 06/19/12 09:45, the mail apparently from Michael Hudson-Doyle included: Paul Larson paul.lar...@linaro.org writes: One thing I was thinking, is whether we could munge the boot script when we install it to this partition and replace the paths in some automagic way. This would solve the issue of making sure we always have the latest bootargs and dtb files for booting, and get us one step closer to parity with a manually imaged system. Yeah, I've thought about that a bit too. One problem at a time :-) (and hopefully sdmux will happen and we can forget about this whole issue). Have we given up on Lava ever supporting / testing non-SD boot paths, or is that going to be supported by this sdmux implementation? -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Linaro-validation] Can we use mmcblk0p8?
On 06/19/12 11:04, the mail apparently from Michael Hudson-Doyle included: Andy Green andy.gr...@linaro.org writes: On 06/19/12 09:45, the mail apparently from Michael Hudson-Doyle included: Paul Larson paul.lar...@linaro.org writes: One thing I was thinking, is whether we could munge the boot script when we install it to this partition and replace the paths in some automagic way. This would solve the issue of making sure we always have the latest bootargs and dtb files for booting, and get us one step closer to parity with a manually imaged system. Yeah, I've thought about that a bit too. One problem at a time :-) (and hopefully sdmux will happen and we can forget about this whole issue). Have we given up on Lava ever supporting / testing non-SD boot paths, or is that going to be supported by this sdmux implementation? No, we have not given up -- although it's not a focus of current work -- and no, it is not going to be supported by this sdmux implementation. So if I understood, it's not supported and there is no plan to support it. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linux-linaro-core-tracking updated to 3.5
On 06/12/12 02:44, the mail apparently from Andrey Konovalov included: Andy Green pointed out that this patch http://www.mail-archive.com/linux-omap@vger.kernel.org/msg63852.html is important for OMAP... thanks to Tushar for digging up the context of it for us. We're carrying a replica of it in our tracking atm but since what was tracking-thermal_exynos4_imx6-3.4-2012.05 had just one of the pair of patches in older llct, it should be improved to have both, if it doesn't already with this update. The current answer is that thermal_exynos4_imx6_work doesn't have the 2nd patch (and this topic has not been updated for 8 weeks). And the reason for having just the 1st patch is probably that the 1st patch is the ARM generic one, while the 2nd one is for OMAP. And AFAIK the topic doesn't support OMAPs yet. The 2nd patch worth including into llct, but I haven't decided how to do that yet - need to sync with the PMWG. OK... we are carrying a rediscovered version of the second patch from Dave Long for now. However although one is for OMAP, the patches belong together because they change the handling of something and then correct OMAP to comply with the New Way. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-3.4 ... / Audit of OOT android code
On 06/10/2012 05:53 PM, the mail apparently from Andy Green included: These are the suspicious things I found from the diff between linaro-android-3.4 (from http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/linaro-android-3.4 at HEAD 8674fd7a65aeff35c3879cf0d56e78c93ee62e2c) vs v3.4. Some are clear cut and others change code I don't really understand, but others on this list will. I noticed while making patches for these that the basis for the diff was upstream/android-3.4 instead of linaro-android-3.4 I thought I was using. Studying the diff between those two, I see there are already changes addressing some of these problems. 1) drivers/input/evdev.c: adds wakelock code not dependent on ANDROID *** need discussion *** Wakelocks got changed in their include file to generate empty structs and apis in case CONFIG_WAKELOCK is not defined. That solves the wakelock part of 16, 17, 18. 16 introduces a flag in mmc code, I am not sure if nulling out the wakelock code but leaving the flag is the same as not having the flag. 3) add net/activity_stats.c contingent on NET_ACTIVITY_STATS *** BUG *** default y fixed 4) net/Kconfig: add ANDROID_PARANOID_NETWORK *** BUG *** default Y: needs changing fixed 8) kernel/power/Kconfig: ***BUG*** HAS_WAKELOCK, WAKELOCK, USER_WAKELOCK all introduced as default y fixed The debug_ll printk problem is also solved. 13) drivers/char/Kconfig: Add DEVMEM *** BUG *** default y ; add DCC_TTY (harmless) fixed That leaves the following: 2) *** BUG *** changes net/wireless/scan.c not protected by CFG80211_ALLOW_RECONNECT: IEEE80211_SCAN_RESULT_EXPIRE reduced to 3s from 15s whether configured or not 5) mm/page_alloc.c: replace constant of 1 with filescope int min_free_order_shift defaults to 1 but changeable from sysctl *** Needs comment *** 6) fs/proc.c: add support for Android-specific OOM adjust interface... ***BUG*** should be contingent on CONFIG_ANDROID or the ANDROID OOM config 7) kernel/cgroup.c: adds a queue of wairer to do rmdir() cgroup, removes most content from free_css_set_work(), screws with much else in there, no idea if that makes cgroups better or worse, but the changes are not contingent on anything *** needs discussion *** 9) kernel/printk.c: *** BUG? *** unconditionally remove CPU_DYING notification from console_cpu_notify, log_buf_get_len, log_buf_clear, log_buf_copy apis added 10) kernel/sched/core.c: __might_sleep_init_called flag introduction (harmless) change __might_sleep processing *** Needs checking ***; add allow_attach cgroup api callback, if not same task actig on itself then confirm CAP_SYS_NICE, or effective uid is suid (seems good); only requeue task if any ancestors are the one element in queue as well as if it's just us (seems good) 11) kernel/sysctl.c: add min_order_free_shift change (pagealloc.c) interface *** Needs comment *** 12) drivers/base/power/main.c: add driver suspend / resume timeout concept, no driver may take more than 12s suspending or BUG(), not dependent on any CONFIG_ probably benficial but *** Needs discussion *** 14) drivers/cpuidle/governors/menu.c: remove scaling formula mult += 2 * get_loadavg(); *** needs discussion *** 15) drivers/mmc/card/block.c: change computation in mmc_get_devidx() *** needs discussion ***; add pr_err if r/w command fails or we abort, harmless; deferred resume implementation properly protected by config, harmless; set md-disk-flags to GENHD_FL_EXT_DEVT *** needs discussion *** 16) drivers/mmc/core/core.c: mmc_resume_bus() introduction; extend wakelock flag, other unconditonal changes *** needs discussion *** 17) drivers/mmc/core/host.c:adds pm_notifier if not flagged MMC_PM_IGNORE_PM_NOTIFY *** needs discussion *** 18) drivers/power/power_supply_core.c: change power_supply_changed() processing *** needs discussion *** 19) arch/arm/boot/compressed/head.S: wrap older chip IDs from colliding with v7 *** needs discussion *** 20) arch/arm/include/asm/hardware/coresight.h: various lowlevel io changes *** need discussion *** 21) arch/arm/include/asm/mach/mmc.h: extra stuff for embedded_sdio_data, declares mmc_platform_data ??? *** needs discussion *** 22) arch/arm/kernel/etm.c: mass changes, no idea *** needs discussion *** 23) arch/arm/mm/cache-l2x0.c: add sets and ways count, service CONFIG_PL310_ERRATA_727915, two magic debug_writel *** needs discussion *** 24) arch/arm/mm/cache-v6.S: support CONFIG_CACHE_FLUSH_RANGE_LIMIT *** needs discussion *** 25) arch/arm/mm/mmu.c: simplify early_pte_alloc() args, add force_pages to alloc_init_pud(), more changes *** needs discussion *** 26) arch/arm/vfp/entry.S: thumb2 code added *** needs discussion *** 27) arch/arm/vfp/vfpmodule.c: add SMP code *** needs discussion *** 28) linux/amba/mmci.h: hmmm also defines stuff defined
Re: Call for topics for the 12.06 linux-linaro* trees
On 06/08/2012 08:25 PM, the mail apparently from Andrey Konovalov included: Greetings, There will be three linux-linaro trees this month. Also some LTs have moved to 3.5, while the others will stay on older kernels. In addition to linux-linaro-core-tracking and linux-linaro ones (described under https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess), linux-linaro-tracking tree will be created as a merge of the tracking trees of TI (v3.4 based) and Samsung (currently v3.4-rc7 based) LTs. For reference the TI + Samsung trees I did during Connect can be found here: http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortlog;h=refs/heads/unify-samsung-ti This builds and works for OMAP at least. Probably more LT tracking trees would be added, but I am not sure due to the different bases the others use. Each LT's tracking tree act as a topic here, so the call for topics doesn't apply to this tree. linux-linaro-core-tracking tree is moving to 3.5 (but not published at git.linaro.org yet). For those using the 3.4, llct_3.4 branch has been created. This is a copy of the most recent v3.4 based linux-linaro-core-tracking tree. *New generic (not board specific) topics and updates to the existing topics are welcomed for the 3.5 based linux-linaro-core-tracking tree* The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it The current topics are: * arm_soc/testing/multiplatform * svenkatr/ufs-for-linux-linaro * svenkatr/emmc-for-linux-linaro * amitdanielk/thermal_exynos4_imx6_work Not sure if this will now already have it, but this patch http://www.mail-archive.com/linux-omap@vger.kernel.org/msg63852.html is important for OMAP... thanks to Tushar for digging up the context of it for us. We're carrying a replica of it in our tracking atm but since what was tracking-thermal_exynos4_imx6-3.4-2012.05 had just one of the pair of patches in older llct, it should be improved to have both, if it doesn't already with this update. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-3.4 or android-3.4-compat
On 24/05/12 09:11, Somebody in the thread at some point said: On 05/23/2012 05:25 PM, Andy Green wrote: On 24/05/12 06:42, Somebody in the thread at some point said: Am I right in thinking the issue you're running into here is that your customer has direct expectations for the tree you're maintaining, which makes adding unexpected instability on a vanilla build very undesireable? (If that's not the case, then generally I don't see a problem with broadening the group testing the Androidization patches to the vanilla set -- they will be beta testing, but that's one key part of open source QA.) Pretty much, I think they're saying to their customers, here's an enabled vanilla tree and then nobody wants to see problems coming from OOT Androidization series. Since we already had funny things in vanilla build from the series, this isn't so paranoid to be concerned about. I think part of the difficulty here has been the classic question of: A) Is the linaro kernel release a development snapshot of the current state of our work - allowing us to get real world testing of our not-yet-upstreamed work? B) Or is it a stable base for others to build upon? And the answer so far has been both! (we're always optimistic! :) but this is a good example of a case where the integration testing of android code with mainline (which helps resolve issues before pushing upstream) is apparently considered too risky for folks wanting that stable base to build upon. If we were claiming to be doing something to the OOT Android series (which is not our work at all) to make it more consistent and workable with upstream, it would be easier to explain to people who don't actually want it but might accept some temporary risk for the greater good. Again, I can see both sides, and what makes most sense depends on our priorities. Personally I like the idea of the Androidization becoming part of the basis because it puts us in generally converged direction with mainline. But then we have a responsibility to make it as transparent as mainline will insist that it is if we expect members are seriously going to offer vanilla kernels on this basis. I like it too. What could we do cheaply that will give us the transparency or policy that addresses the risk you've outlined? Someone needs to audit the OOT Androidization stuff and confirm that for patches that go out of their box, ie, reach out of /staging or some specific driver: - the impact of the patch is negated if CONFIG_ANDROID or some more specific config is disabled, or, - remove the patch as too invasive, or, - conclude the patch is useful and needed in vanilla case too there's a big variety of out of the box patches for stuff like cache code, mmc core, network stack and so on in that series last time I looked. We should give some assurance for people using linux-linaro-core-tracking that someone at least looked at each of those cases and determined its status as above. Again, this would be great to have. Although the calls being made here also have costs to consider: * If we remove the patch, we diverge from AOSP, which makes keeping up with Google's tree more costly. Not sure we can eat both those cakes, either we're doing mighty feats of engineering on OOT Google stuff to align it to upstream and there may be some dust, or we are just mechanically cloning AOSP OOT content in our mainline tree because we believe any change from AOSP series would be heretical. * If the patch is needed in vanilla, but might not be acceptable, considerable work might be required to get it into shape. So what do we do in the meantime? Unless it reeks too badly, stick it on llct so we get the sinful benefits and switch to the clean version when it comes from mainline. That's interesting to tree consumers because path through mainline can often be very twisty and slow, yet inbetweentimes mainline lacks the feature and we have it. If that's true of dozens of pending features at any one time, yet our tree is overall consistent with direction and basis of mainline, our tree is looking pretty hot. Further, for the various bits that are not config switched, any such review would need to be done by domain experts, as much of the changes (especially with regard to arm architecture and mmc tweaks) are well beyond my/a novice's ability to audit. In some cases where I've pushed seemingly trivial fixes from the AOSP stack to lkml, Russell and others have not been able to come to consensus as to if the fix is correct or not, so this definitely isn't a trivial work. And all of the above suggestions you've made are desired, but given time constraints we've been focusing on the more generic functionality first, and moving from there to the more specific driver and architecture changes (which is where the majority of the un-config switched changes are). Its just taking some time to get there, so I suspect pushing the linaro-android tree into a separate merge tree is likely
Re: android-3.4 or android-3.4-compat
On 22/05/12 23:57, Somebody in the thread at some point said: On 05/21/2012 09:21 PM, Andy Green wrote: On 22/05/12 01:58, Somebody in the thread at some point said: On Mon, May 21, 2012 at 10:33:47AM -0700, John Stultz wrote: like Andy, I am a bit concerned that we merge the android stuff into the linaro-core and that we get android candies in 'vanilla' kernel. can't we (shouldn't we) have -android on top of -core and pull -android only into 'android' kernel? it's true that for most things, -android is not impacting a 'vanilla' kernel, but clearly from the outside (community *and* customers) a kernel 'tainted' with Android is not a 'vanilla' kernel anymore... So this re-opens the discussion we've been having since at least last Oct in moving to a consolidated kernel. Since Android upstreaming is an very active goal of Linaro, I think there's strong technical value in putting the Android patches in along with all the other Linaro trees, as it allows us to work out any sort of incompatibilities or issues, so we can resolve them prior to being pushed upstream. I'm quite +1 on what John is saying. There was a time when there was great uncertainty about the future of the Android patches, but since Linus' comment last year it's become dead certain that the functionality /will/ be merged upstream. We can pave the way by getting any integration issues sorted out early -- similarly to what we do for practically everything else in linux-linaro. Hm I just said we should audit it for being dependent on CONFIG_ANDROID. If we KNOW that deconfiguration of CONFIG_ANDROID is equivalent to not having Androidization patched in, people will stop wanting to get rid of the patches. But since Google's interest is in the case it is configured, I doubt they took care about having it disabled well. For new or optional functionality, this is usually the case, but not for all changes. Having multiple config based code paths has additional maintainance burden, so frequently if a change really should be generic there isn't any need for a config. The simplest example of this are bug fixes, which shouldn't be configurable off :) For an example we had a problem yesterday with the Androidization interactive cpufreq governor turning up unexpectedly in an Ubuntu build and spamming block task logs. I dunno why it appeared yet, maybe it's marked up as defauly=y or some config fumble on part of guy who built the kernel. For other configurable features in the mainline kernel, part of the deal of getting in there is that they can be turned off nicely. There's even a wholesale CONFIG_PM. But the remaining (200 or so last time I looked) Androidization patches haven't been through that kind of scrutiny by anyone. Again last time I looked they fiddled with a fair amount of kernel guts, sometimes with additional config coverage but not always. Initially we added without discrimination that 7 year old patch that turns dmesg into junk to llct because it came in with Google's Androidization series. It suggests we're just shovelling them on without any plan at the moment. And I'd say in this case things worked ideally! Android tree had a very old hack that has since become obsolete. You noticed it in the tree and Yeah but that's what I am saying, we shovelled the patches on with no plan about assessment or audit and just waited for trouble. It's fair enough to do that on android-specific tree because it's for benefit of Android guys. But some vanilla people don't want to participate in finding bugs from non-mainline Android code they don't care about. requested it be reverted. I've generated a patch to do so, and plan to send it to AOSP in my next submission bundle. Once the Google guys rebase, and squish the two patches down, we're down one more patch. This is exactly the type of integration work I think we benefit from. If this were something that we went in and just configured off, its less likely anyone would notice it was unnecessary until we finished upstreaming all the larger changes we're focusing on. Some consumers of trees that are basing on linux-linaro-core-tracking actively don't want the Androidization stuff and we need to make sure their needs are met. Similarly, Andrey and Tushar found early cases during the first few integration attempts where parts of the Android patch set didn't align with non-Android builds. They submitted patches that have since been pushed back to AOSP. With regard to your characterization of shovelling the patches in, its true we've traditionally taken the patch tree in its entirety, in order to produce Android builds that were fully functional. The positive news is that as items have been making it upstream, we may soon be able to reverse the model, only hand picking specific required changes from the AOSP tree. This possibility has different pros and cons, so it may not be the right approach, but its something I'll be looking at in the future. If we're
Re: thermal issue on panda
On 23/05/12 18:00, Somebody in the thread at some point said: Hi, I have successfully tested one of the latest daily build. The thermal issue doesn't occur anymore Great - thanks a lot for the report and retest. -Andy Thanks, Vincent On 17 May 2012 08:57, Ricardo Salvetiricardo.salv...@linaro.org wrote: On Wed, May 16, 2012 at 8:51 AM, Andy Greenandy.gr...@linaro.org wrote: On 16/05/12 19:49, Somebody in the thread at some point said: On 14 May 2012 16:12, Andy Greenandy.gr...@linaro.orgwrote: On 14/05/12 20:53, Somebody in the thread at some point said: On 14/05/12 20:45, Somebody in the thread at some point said: Hi Aneesh, Adding linaro-dev in the loop as someone else could be also interested I have reproduced my thermal error with a lava test so you can have a complete log available here: http://validation.linaro.org/lava-server/scheduler/job/18564/log_file As a summary of the problem, the panda board turns off during some sysbench tests because the SDRAM has exceeded its temperature limit Recently Sebastien Jan at TI found that on tilt-3.3, cpu_idle is interacting badly with smartreflex and the wrong Vcore can be selected for 4460. At the moment we disabled 1.2GHz on tilt-3.3, we think we have a fix + workaround and I'll update with it tomorrow. tilt-3.3 is updated with the fixes and workaround of disabling CPU_IDLE, please give that a try. Hi Andy, Is there any daily build hwpack that is available with this version on tilt-3.3 so I will be easier for me to test it? The Linaro Panda hwpack is based on tilt-3.3, but I don't know if it has taken in the latest patches yet (it should). The latest kernel packages are always published at our Kernel PPA, that is manually copied to the Overlay at least once a week. Check https://launchpad.net/~linaro-maintainers/+archive/kernel/+packages?field.name_filter=lt-omapfield.status_filter=publishedfield.series_filter=precise for the latest lt-omap kernel, based on the latest changes from Andy. Unfortunately the config changes are not propagated automatically yet, so I had to update the package config by hand to properly disable it. The new build should be available at the PPA in a few hours, and you can follow the progress at https://ci.linaro.org/jenkins/view/Ubuntu%20Packaged%20Kernels/job/create-packaged-linux-linaro-lt-omap-3.3/38/ and https://code.launchpad.net/~jcrigby/+recipe/linux-linaro-3.3-lt-omap-daily. Please check the package changelog to confirm the hash from the LT's tree. Cheers, -- Ricardo Salveti de Araujo -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-3.4 or android-3.4-compat
On 24/05/12 06:42, Somebody in the thread at some point said: On Wed, May 23, 2012 at 02:21:50PM +0800, Andy Green wrote: If we KNOW that deconfiguration of CONFIG_ANDROID is equivalent to not having Androidization patched in, people will stop wanting to get rid of the patches. But since Google's interest is in the case it is configured, I doubt they took care about having it disabled well. For new or optional functionality, this is usually the case, but not for all changes. Having multiple config based code paths has additional maintainance burden, so frequently if a change really should be generic there isn't any need for a config. The simplest example of this are bug fixes, which shouldn't be configurable off :) For an example we had a problem yesterday with the Androidization interactive cpufreq governor turning up unexpectedly in an Ubuntu build and spamming block task logs. I dunno why it appeared yet, maybe it's marked up as defauly=y or some config fumble on part of guy who built the kernel. Generally when analyzing a situation like this I think the first question is whether feature X will be merged upstream, and then the question is whether it would be protected by CONFIG_ANDROID. How does the interactive governor fair against this criteria? Will it be accepted upstream, and if so, will it be behind CONFIG_ANDROID=y? Initially we added without discrimination that 7 year old patch that turns dmesg into junk to llct because it came in with Google's Androidization series. It suggests we're just shovelling them on without any plan at the moment. And I'd say in this case things worked ideally! Android tree had a very old hack that has since become obsolete. You noticed it in the tree and Yeah but that's what I am saying, we shovelled the patches on with no plan about assessment or audit and just waited for trouble. It's fair enough to do that on android-specific tree because it's for benefit of Android guys. But some vanilla people don't want to participate in finding bugs from non-mainline Android code they don't care about. Am I right in thinking the issue you're running into here is that your customer has direct expectations for the tree you're maintaining, which makes adding unexpected instability on a vanilla build very undesireable? (If that's not the case, then generally I don't see a problem with broadening the group testing the Androidization patches to the vanilla set -- they will be beta testing, but that's one key part of open source QA.) Pretty much, I think they're saying to their customers, here's an enabled vanilla tree and then nobody wants to see problems coming from OOT Androidization series. Since we already had funny things in vanilla build from the series, this isn't so paranoid to be concerned about. Personally I like the idea of the Androidization becoming part of the basis because it puts us in generally converged direction with mainline. But then we have a responsibility to make it as transparent as mainline will insist that it is if we expect members are seriously going to offer vanilla kernels on this basis. I like it too. What could we do cheaply that will give us the transparency or policy that addresses the risk you've outlined? Someone needs to audit the OOT Androidization stuff and confirm that for patches that go out of their box, ie, reach out of /staging or some specific driver: - the impact of the patch is negated if CONFIG_ANDROID or some more specific config is disabled, or, - remove the patch as too invasive, or, - conclude the patch is useful and needed in vanilla case too there's a big variety of out of the box patches for stuff like cache code, mmc core, network stack and so on in that series last time I looked. We should give some assurance for people using linux-linaro-core-tracking that someone at least looked at each of those cases and determined its status as above. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-3.4 or android-3.4-compat
On 21/05/12 18:27, Somebody in the thread at some point said: hi, On Fri, May 18, 2012 at 6:00 AM, Andy Green andy.gr...@linaro.org mailto:andy.gr...@linaro.org wrote: So I just wanted to check first with folks to make sure there are no objections to merging in the -compat changes, and that the timing of merging in these changes isn't problematic (I can happily hold off till this months release is done, so we don't risk any last minute gotchas). The only worry I can see is that now even vanilla versions of LT kernels are basing off llct that includes Androidizaton, even vanilla will have possibly invasive wakelock code. It might be good to briefly audit the changes to confirm they don't appear if CONFIG_ANDROID is off. Google might not take much care about that case but I think it might be important for us. like Andy, I am a bit concerned that we merge the android stuff into the linaro-core and that we get android candies in 'vanilla' kernel. can't we (shouldn't we) have -android on top of -core and pull -android only into 'android' kernel? it's true that for most things, -android is not impacting a 'vanilla' kernel, but clearly from the outside (community *and* customers) a kernel 'tainted' with Android is not a 'vanilla' kernel anymore... I really like the linux-core tree by the way, and the fact that we get Linaro technologies pre-integrated is helping us clearly. I think if we only add -android as a branch on top of -core, then that should be enough. Then Andy (or other LT) would pull -core into their -vanilla, and pull -android branch into the LT androidized kernel! Right that is how it used to be until recently. But to be fair to platform guys, recently mainline did bring a lot of Android stuff back into vanilla staging with intention to make it a permanent part of vanilla. The problem is they were the easy bits of Androidization that would stay in the staging box. The Androidization in llct and this new tranche is more invasive to the general tree. Despite I am not on John's whitelist of People Whose Opinions Matter for that subject, maybe we should take some care to either audit what we're adding to vanilla or as Nicolas is suggesting separate it out again. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: New Gator version ready for Linaro kernels / Mali
On 17/05/12 15:37, Somebody in the thread at some point said: On Thu, 2012-05-17 at 07:42 +0800, Andy Green wrote: Just curious... how many LTs have Mali stuff? If it's more than one, we should perhaps be talking about moving it to linux-linaro-core-tracking. We have two teams with three different versions of the driver ;-) with, I suspect, custom modifications (different memory management components?). From my bystanders point of view, the interaction with closed source binary blobs seems to cause people enough nightmares without also trying to converge code-lines between teams. Especially when engineering resources are spread so thin. Well... Fortunately (?), the two teams have the drivers under different paths with different module and Kconfig option naming, so they could coexist in the same tree. ... without underestimating the problems (which we know well from SGX), this is exactly Linaro's core business to sort out isn't it? I mean they're even nominally *Linaro* LT trees and they're divergent on a critical, expensive chunk of code and we're saying, but it's hrd. My guess is those teams lose sleep over Mali same as we lost much sleep over SGX and would welcome getting a single, latest version with correct userland handed to them, so there's one thing to talk about with ARM. Then by fixing this Linaro directly and visibly has added value for the members involved. Whatever customizations are patched on top need to come out of the woodwork and get discussed what they're for. Depending what they are they could either go in llct if acceptable to all parties or if necessary get stitched in smarter so they're enabled by flags from plat-...er DT. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: New Gator version ready for Linaro kernels / Mali
On 17/05/12 21:26, Somebody in the thread at some point said: On Thu, May 17, 2012 at 2:21 PM, Scott Bambrough scott.bambro...@linaro.org wrote: On 12-05-17 03:37 AM, Jon Medhurst (Tixy) wrote: On Thu, 2012-05-17 at 07:42 +0800, Andy Green wrote: Just curious... how many LTs have Mali stuff? If it's more than one, we should perhaps be talking about moving it to linux-linaro-core-tracking. We have two teams with three different versions of the driver ;-) with, I suspect, custom modifications (different memory management components?). Yes, there are three different memory managers (UMP from ARM, HWMEM from STE, and UMM). From my bystanders point of view, the interaction with closed source binary blobs seems to cause people enough nightmares without also trying to converge code-lines between teams. Especially when engineering resources are spread so thin. Fortunately (?), the two teams have the drivers under different paths with different module and Kconfig option naming, so they could coexist in the same tree. It would be best if the driver and user space was converted to use UMM so we could drop UMP/HWMEM, and standardize on one driver. Added Jesse here as he may have some info that is relevant. Scott is right, and we are pushing slowly in that direction, but it will be a while before that is possible for all Mali400 instances could be supported from a single stack. What does this mean for the unified kernel effort then? We should attempt to unify kernels excluding Mali, or we should wrap or capture the differences in Mali? Is there anything that the unified kernel effort can do (I mean in terms of slotting things in llct and the like) that can converge with where UMM-uber-alles is headed? -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 17/05/12 17:41, Somebody in the thread at some point said: On Thu, 2012-05-10 at 23:34 +0400, Andrey Konovalov wrote: Greetings, So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree) Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. What happened to this? linux-linaro hasn't changed for 4 weeks now, so our vexpress 'tracking' builds of Android and Ubuntu are in fact the same kernels as the 12.04 release. It doesn't matter as long as llct is moving - and it has been, Andrey is doing a really nice job. If we can get all the LTs to base on llct, and get all the important things standardized in llct, then everything will come right. Nobody cares that we glued a couple dozen patches from ARM LT on one other LT tree as a one-off. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: New Gator version ready for Linaro kernels / Mali
On 17/05/12 22:44, Somebody in the thread at some point said: On Thu, May 17, 2012 at 3:33 PM, Andy Greenandy.gr...@linaro.org wrote: On 17/05/12 21:26, Somebody in the thread at some point said: On Thu, May 17, 2012 at 2:21 PM, Scott Bambrough scott.bambro...@linaro.orgwrote: On 12-05-17 03:37 AM, Jon Medhurst (Tixy) wrote: On Thu, 2012-05-17 at 07:42 +0800, Andy Green wrote: Just curious... how many LTs have Mali stuff? If it's more than one, we should perhaps be talking about moving it to linux-linaro-core-tracking. We have two teams with three different versions of the driver ;-) with, I suspect, custom modifications (different memory management components?). Yes, there are three different memory managers (UMP from ARM, HWMEM from STE, and UMM). From my bystanders point of view, the interaction with closed source binary blobs seems to cause people enough nightmares without also trying to converge code-lines between teams. Especially when engineering resources are spread so thin. Fortunately (?), the two teams have the drivers under different paths with different module and Kconfig option naming, so they could coexist in the same tree. It would be best if the driver and user space was converted to use UMM so we could drop UMP/HWMEM, and standardize on one driver. Added Jesse here as he may have some info that is relevant. Scott is right, and we are pushing slowly in that direction, but it will be a while before that is possible for all Mali400 instances could be supported from a single stack. What does this mean for the unified kernel effort then? We should attempt to unify kernels excluding Mali, or we should wrap or capture the differences in Mali? Is there anything that the unified kernel effort can do (I mean in terms of slotting things in llct and the like) that can converge with where UMM-uber-alles is headed? Naive question alert... If the Mali driver is an out-of-tree module, does it matter? Last time I looked in Dec, it and its lovely symlinks were in-tree. Who are you asking does it matter to? If you are asking, does it help the unified kernel effort, sure, OOT module succeeds to hide the poop. In the larger sense of Linaro's legacy, meaning, value... -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 17/05/12 23:01, Somebody in the thread at some point said: On Thu, 2012-05-17 at 22:40 +0800, Andy Green wrote: On 17/05/12 17:41, Somebody in the thread at some point said: On Thu, 2012-05-10 at 23:34 +0400, Andrey Konovalov wrote: Greetings, So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree) Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. What happened to this? linux-linaro hasn't changed for 4 weeks now, so our vexpress 'tracking' builds of Android and Ubuntu are in fact the same kernels as the 12.04 release. It doesn't matter as long as llct is moving - and it has been, Andrey is doing a really nice job. If we can get all the LTs to base on llct, and get all the important things standardized in llct, then everything will come right. Nobody cares that we glued a couple dozen patches from ARM LT on one other LT tree as a one-off. OK, so you're saying linux-linaro is dead/on-hold and I should go back to maintaining my own branches for releasing Ubuntu and Android VExpress kernels? If that's true, I wish people would actually tell me these things. Dude I'm not in charge, I'm just relating the facts. linux-linaro-tracking is currently meaningless to anyone. Naturally it doesn't get updated, it's a meaningless Potemkin village. llct is very valuable though and if we take care about it as we all should, eventually it will be able to generate a meaningful linux-linaro-tracking itself because it caused the LTs to converge on all the critical points. In the meanwhile the thing we should all be taking care about is understanding the current deep incompatibilities in LT trees - like Mali - and steering things in the right direction. But somehow excluding topics became the fetish for half a year now and afaik nobody - nobody - has actually tried to bind the LT trees together to discover the issues since I last did it in Dec. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: android-3.4 or android-3.4-compat
On 18/05/12 09:49, Somebody in the thread at some point said: Hey Andrey, Zach, So I'm back from my vacation, and have found that the Android team has released a -compat tree for their 3.4 kernel. Basically this tree re-adds some items like earlysuspend and classic wakelocks in order to provide better compatibility with old (and by old, I really mean current as far as we see - so ICS and earlier) Android userland. Since we're still shipping ICS, and have no access to whatever the Android 5.0 userland will be, it seems merging in the -compat tree would make sense. However, I know Tixy and others have already tried to address the lack of earlysuspend in the android-3.3+ kernels, so I wanted to double check that this wouldn't cause additional pain (since those adjustments might need to be reverted). So I just wanted to check first with folks to make sure there are no objections to merging in the -compat changes, and that the timing of merging in these changes isn't problematic (I can happily hold off till this months release is done, so we don't risk any last minute gotchas). The only worry I can see is that now even vanilla versions of LT kernels are basing off llct that includes Androidizaton, even vanilla will have possibly invasive wakelock code. It might be good to briefly audit the changes to confirm they don't appear if CONFIG_ANDROID is off. Google might not take much care about that case but I think it might be important for us. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: New Gator version ready for Linaro kernels / Mali
On 16/05/12 23:58, Somebody in the thread at some point said: Hi - ARM have released a new version of Developer Studio 5 (DS-5) and we now have a new version of the Gator component [1] to go with this which needs updating in all Linaro kernel trees that will be part of the 12.05 release. For those people maintaining kernel trees here is what this means... - If your kernels are including the linux-linaro-core-tracking [2] branch then you will get the new Gator version from this when it is updated over the next couple of days. You don't need to do anything except to make sure you are up to date with this branch before the 12.05 release. I suspect we'll be issuing tilt-3.3 again, so even though we're on llct for tracking we'll have to revert and update. For those people who have applied Mali driver patches to support profiling by Gator: you don't need to modify those Mali patches, just take the new version of Gator, this will still work OK. Just curious... how many LTs have Mali stuff? If it's more than one, we should perhaps be talking about moving it to linux-linaro-core-tracking. Presumably that then needs coordination about matching userlands in multiple LTs which will need some time. Even if Mali is in good sync today between multiple LTs the architecture of each LT having their own copy of what's meant to be permanently in sync invites problems. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 15/05/12 23:01, Somebody in the thread at some point said: If it's the case that stuff in linaro tree is more upstream-converged than what Tushar's tree works with, then we can put it another way: the current implementation in Samsung tree (no ding intended since it can just as easily be any of us and no doubt soon will be) needs to be fixed to work with current upstream-headed pieces it needs. Yes, indeed. We are working on fixing this stuff. Just that, it won't be fixed before 2012.05 release. That is why I was wondering whether Samsung LT Android solution could use linux-linaro tree. Understood... for one reason and another we often can't do stuff for monthly release timescale either and have to pass on it. However in medium term, the LT trees are going to have to become compatible with llct, and it's sensible enough because llct is closer to what's going to mainline than what the LTs individually have. Otherwise there'll never be any genuine unified tree. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 11/05/12 10:19, Somebody in the thread at some point said: On Fri, May 11, 2012 at 3:43 AM, Andy Greenandy.gr...@linaro.org wrote: On 11/05/12 08:27, Somebody in the thread at some point said: 4. in between RCs, we only move mainline on our linux-linaro release baseline forward if we see a working tracking build that wouldn't drop any topics that already made it into this RC cycle. The probability of getting a good unified tree follows the kernel cycle, we all have good reasons to have tried to arrive at a good, working, release. Sometimes we only get a reasonably good result a week or two after Linus' release. For that reason maybe you should just be trying to 'release' a release-basis unified tree, ie, the 3.4 one targeted now as the deliverable. It still has meaning to make a monthly release of that since it can collect stable mainline updates and updates from each LT release tree that happened in the meanwhile. We do need to create these intermediate unified trees so we know what to fix on our trees so they can go in smoothly, but it matters less then if one day half the LT trees are missing on it since it's of interest only for LTs and platform guys to study what else needs solving on the LT trees. I still think you won't get anywhere useful until we are trying to build the unified trees for real. Then we can start the needed work to make them fit together properly, until then we're treading water in technical debt. Discussing how to run the tree is something to do later after gaining this experience. I had a look at the LT gits ARMMerge-managed integration-linux-vexpress 3.4-rc4 TI Rebase-managed tilt-tracking 3.4-rc4 Freescale Merge-managed lt-3.4 3.4-rc3 SamsungRebase-managed tracking 3.4-rc3 STEMerge-managed integration-linux-ux5003.4-rc6 (wow STE - on igloocommunity.org - have a LOT of patches! I thought we were leading the way) Actually locally TILT are on -rc6 but there was almost no conflict coming between -rc4 and -rc6. If you take the approach to merge these trees, I found that late in the cycle it's usually pretty forgiving about some variation in basis. So why not give these all a test merge today and see what starts falling out? I am sure we all have something to fix and there may be larger issues I will check with Andrey/Ricardo if we can do that :) ... would it be exciting enough if we just try adding TI to the mix this month (and not all?)? In any case, you should definitely send Andrey a list of topic branches you want to register for linux-linaro and things will get picked up as soon as Andrey can I guess :). Sure, actually merging trees and dealing with the fallout, even if it's just one more tree if that's all you can handle, will get us moving further forward than just talking about it. AIUI this topic thing is not blocking you, you can just merge tilt-tracking as a single topic for now and discover the pain points. All I am planning to provide ultimately is an in-tree text file mapping topic names to head hashes, as I produced for Andrey before, not register topics anywhere. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 11/05/12 13:04, Somebody in the thread at some point said: On 05/11/2012 01:04 AM, Andrey Konovalov wrote: Greetings, So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree) Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7. The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus the 7 generic topics currently included into the linux-linaro-core-tracking tree: ufs (ufs-for-linux-linaro) emmc (emmc-for-linux-linaro) thermal_exynos4_imx6 (thermal_exynos4_imx6_work) linaro-android-3.4 armlt-gator (tracking-armlt-gator) umm-wip (umm-3.4rc4-wip) linaro-configs-3.4 If you don't see your generic topic in this list, but you think it should be there, please let me know ASAP. If you have a new topic to add, please send me the request before the next Thursday, May 17; the sooner, the better. The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it The landing teams - please update your topic branches if needed: ARM: tracking-armlt-hdlcd tracking-armlt-mmc tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes tracking-armlt-ubuntu-config tracking-armlt-android-config Samsung: topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi topic/mali topic/cma_v24 topic/android_config Is any other LT using CMA patchset? If so, this topic branch can be moved into linux-linaro-core-tracking. We'll be using it again shortly, CMA is in linux-linaro-core-tracking already though, I believe the same version #24. http://git.linaro.org/gitweb?p=kernel%2Flinux-linaro-tracking.gita=searchh=refs%2Fheads%2Flinux-linaro-core-trackingst=commits=CMA -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linux-linaro-core-tracking tree created
On 04/26/2012 10:49 AM, Somebody in the thread at some point said: On 04/26/2012 01:54 AM, Somebody in the thread at some point said: Hi - Please don't remove your dt bits! Instead let me know when I can drop the conflicting (== redundant) commits from my tracking-unsorted branch. It's just that one patch from Grant that sets up the DT machine name stuff in board-omap4panda. If it's not intentional you're providing it I can stick it back on when you remove it on your side. This happened and I added the support back in OK, thanks. Maybe it's something on my side but I noticed I have android logging coming on my vanilla defconfig now. I can force it off in my defconfig, but I am wondering if that's intentional? No, it wasn't. In the Android patchset all their new config options are y by default, regardless of CONFIG_ANDROID even. We (well, John Stultz) have started changing these defaults to n, and to enabling them in configs/android.conf (the WAKELOCK ones, ANDROID_PARANOID_NETWORK, and NET_ACTIVITY_STATS). Right that's what's needed. I'll just wait for this to go away as we track -core then. Since it's still there in today's llct and making me see double, I tracked it down to this from Androidization series 109a3af ARM: Make low-level printk work I don't think that makes any sense any more and should be removed, unless there's some case on Android side that really needs it. Vanilla has better DEBUG_LL support now since 2005 when that patch was introduced and the Android kernels will inherit it. I've reverted it in my tree since we commonly need DEBUG_LL on (but we don't need printascii garbling all our logging as if there was an echo in there). -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linux-linaro-core-tracking tree created / update frequency
On 04/25/2012 03:43 AM, Somebody in the thread at some point said: Hi - The plan is to rebase this tree on the current mainline tip daily. Now we're basing on it, our tracking progress depends on these daily rebases, but it's stuck since Friday. So we're missing -rc5 for 3 days. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linux-linaro-core-tracking tree created
On 04/25/2012 10:22 AM, Somebody in the thread at some point said: Hi - Maybe it's something on my side but I noticed I have android logging coming on my vanilla defconfig now. I can force it off in my defconfig, but I am wondering if that's intentional? It doesn't seem to be android logger itself, just something else I always saw after Androidization, kernel logging that's anyway enabled to console by printk / loglevel is repeated without having it severity tag parsed off. That's objectionable now the basis is androidized and it still happens even with CONFIG_ANDROID off. We're still undergoing uplevel on tilt-tracking and didn't get back to tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we have a fix for that today), so I put off this common config thing. OMAP4 is booting again FWIW just a few dings to sort out. However now I see it included, aren't most of the patches about board support redundant? If LTs base on this, they will add in their own golden initial defconfig for their board(s) at that point; when they're combined they'll all be in the combined tree. It seems like I shouldn't be seeing a defconfig about Panda coming in with this base tree, but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree. Looking closer at this, we prefer not to have CONFIG_MTD or CONFIG_JFFS in the base config. We don't really have a case for them on Panda. You might want to push those out into a mtd.conf we will pass over, or something similar. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linux-linaro-core-tracking tree created
On 04/26/2012 01:54 AM, Somebody in the thread at some point said: Hi - I've changed basis to it (there's not much choice but to take that approach since it's done with merges, but lack of any nexty content means it was painless), and it has updated thermal, CMA (#21 - #24) and other little bits like Panda dt I could remove from our tree and use these common versions for. Please don't remove your dt bits! Instead let me know when I can drop the conflicting (== redundant) commits from my tracking-unsorted branch. It's just that one patch from Grant that sets up the DT machine name stuff in board-omap4panda. If it's not intentional you're providing it I can stick it back on when you remove it on your side. Maybe it's something on my side but I noticed I have android logging coming on my vanilla defconfig now. I can force it off in my defconfig, but I am wondering if that's intentional? No, it wasn't. In the Android patchset all their new config options are y by default, regardless of CONFIG_ANDROID even. We (well, John Stultz) have started changing these defaults to n, and to enabling them in configs/android.conf (the WAKELOCK ones, ANDROID_PARANOID_NETWORK, and NET_ACTIVITY_STATS). Right that's what's needed. I'll just wait for this to go away as we track -core then. As I mentioned before the LT trees also have some config mistakes like this that never show up on their tree because the stuff is always configured on. When they're combined, several small - trivial - Kconfig bugs to fix like that will shake out from all over. When we start seeing complaints about that, I'll know we're really getting our teeth into combining trees. We're still undergoing uplevel on tilt-tracking and didn't get back to tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we have a fix for that today), so I put off this common config thing. However now I see it included, aren't most of the patches about board support redundant? If LTs base on this, they will add in their own golden initial defconfig for their board(s) at that point; when they're combined they'll all be in the combined tree. It seems like I shouldn't be seeing a defconfig about Panda coming in with this base tree, yes (this comes from the unsorted topic wich I am going to drop from this tree) ... Fine. but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree. ...and yes Although as I say our tracking is still missing some topics compared to tilt-3.3 as we are uplevelling, with this change of basis and elimination of CMA#21 delta we had until now, actually tilt-tracking can be considered for trial merge in unified tree I think. It's not very meaningful in terms of usefulness of our tree right now but it certainly should be interesting in terms of what makes trouble, if anything. Very good. I was thinking about creating (reusing actually) linux-linaro-tracking branch to be the linux-linaro-core-tracking plus the LT's topics. But I still have quite a long TODO list, and linux-linaro-core-tracking and linux-linaro branches are higher priorities for me. So no commitments WRT linux-linaro-tracking at the moment :) Well, it's not like I'm in a rush for it. But if we're not piling on more LT trees aimed at 3.4 soon, we probably don't get a meaningful combined tree for 3.4 release. (I don't think ARM LT content + one other LT tree tells us much since great as ARM LT stuff is, it's not a full BSP tree like other LTs but just introduces novel features that have nothing to conflict with except the odd Makefile one-liner). Generally if all LTs are basing and tracking on -core, 90% of the integration-readiness job is done. So long as there's not too much off-piste content showing up in diffstat from anyone, you'll likely be surprised how easily they go together at that point (plus or minus inevitable surprise from each tree that another tree had also patched that Kconfig / Makefile now). -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linux-linaro-core-tracking tree created
On 04/25/2012 03:43 AM, Somebody in the thread at some point said: Hi Andrey - I've just created linux-linaro-core-tracking branch in git://git.linaro.org/kernel/linux-linaro-tracking.git. It is based on mainline tip, and has all the Platform and Working Groups topics which would appear in the next linux-linaro kernel release. No topics from the Landing Teams there (this is what core implies). This Nice job, thanks for the new branch which definitely solves the chicken-and-egg. In fact it's going to be a great tracking fake future upstream staging point for all the good stuff being worked on that is not ready for upstream yet. It'll help the LT trees look more consistently like future upstreams where the vendor content is already in too, and let people use technologies like UMM easily long before they appear upstream. In that way hopefully we will provide I've changed basis to it (there's not much choice but to take that approach since it's done with merges, but lack of any nexty content means it was painless), and it has updated thermal, CMA (#21 - #24) and other little bits like Panda dt I could remove from our tree and use these common versions for. Otherwise it made very few conflicts compared to yesterday's Linus HEAD we were already on and the tree is as workable as it was. http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=summary Maybe it's something on my side but I noticed I have android logging coming on my vanilla defconfig now. I can force it off in my defconfig, but I am wondering if that's intentional? We're still undergoing uplevel on tilt-tracking and didn't get back to tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we have a fix for that today), so I put off this common config thing. However now I see it included, aren't most of the patches about board support redundant? If LTs base on this, they will add in their own golden initial defconfig for their board(s) at that point; when they're combined they'll all be in the combined tree. It seems like I shouldn't be seeing a defconfig about Panda coming in with this base tree, but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree. Although as I say our tracking is still missing some topics compared to tilt-3.3 as we are uplevelling, with this change of basis and elimination of CMA#21 delta we had until now, actually tilt-tracking can be considered for trial merge in unified tree I think. It's not very meaningful in terms of usefulness of our tree right now but it certainly should be interesting in terms of what makes trouble, if anything. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linux-linaro-core-tracking tree created
On 04/25/2012 11:12 AM, Somebody in the thread at some point said: We're still undergoing uplevel on tilt-tracking and didn't get back to tilt-3.3 functionality yet (OMAP4 boot is busted, although hopefully we have a fix for that today), so I put off this common config thing. However now I see it included, aren't most of the patches about board support redundant? If LTs base on this, they will add in their own golden initial defconfig for their board(s) at that point; when they're combined they'll all be in the combined tree. It seems like I shouldn't be seeing a defconfig about Panda coming in with this base tree, but create it (perhaps after mixing in config fragments that did come in with the base tree) in my tree. We could just have the fragments per topic, and then the LT can decide either to add another fragment, or simply creating an entire different config to be used by default. Having everything in config fragments may help automating the builds, but I understand that having one defconfig might also help people that are consuming the tree directly. Yes I'm not really referring to fragment process here, I understand the idea and as I wrote expect the common one(s) to come in with this base tree. What I'm talking about is ./configs/panda.conf brought in by this http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=commitdiff;h=36f22ea6ac55d44026d374669cb55c60bb366d4e actually, now we don't maintain anything directly equivalent, we only have omap4plus_defconfig that builds a single kernel that runs with everything we support, including OMAP543x. I guess panda.conf is trying to be mainline compatible OMAP44x0 Panda config. But what we're going to provide, and what's meaningful and tested with our tree, will be this omap4plus_defconfig that appears in our topics. panda.conf that we are inheriting from this basis branch may not even build with our tree, it's at least confusing to have it there and at worst it'll mislead end users, rot as we go on etc. We can figure out how to apply ./configs/linaro-base.conf to omap4panda_defconfig and work with that. But panda.conf coming in at base tree is not meaningful and not tested on our tree, I think it and the other board confs coming in probably need to be removed from the basis tree and the LT minimal configs introduced in LT trees used instead. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Preliminary 12.04 linux-linaro kernel tree
On 04/19/2012 11:33 PM, Somebody in the thread at some point said: Andrey/Ricardo: do you agree? Can we make such a linux-linaro-tracking-core branch (and a tag accordingly) available that basically reflects the state we have after merging WG topics and before LT topics? Sure :) With just one difference probably. Shouldn't this linux-linaro-tracking-core branch be mainline tip based, not just the most recent -rc? (So it would be the real tracking tree.) I That's the spirit ^^ Actually we found (with tilt patchload anyway) at start of kernel cycle, there is often heavy breakage coming from mainline HEAD day by day or even hour by hour. Keeping on top of that so you don't experience it all at once is really important. But usually after the middle of the cycle, even trees that differ by two -rcs are basically compatible and can be merged / rebased pretty painlessly. However... spare a thought for how this'll scale for you personally when you are dealing with say 10 LT trees each with 1000 patches. When our tree hit 2100 patches (it should be half that at 3.4) it was taking hours to rebase, merging is not markedly faster. It's single-threaded so throwing more cores at it doesn't help. It's another reason separating out -core flavouring uplevel and unified uplevel is the right path. also planned to have a linux-linaro-tracking branch to be exactly the same linux-linaro-tracking-core branch plus the current LT's topics for the next linux-linaro release. The linux-linaro-tracking* branches would be for new work being done (like moving to new CMA version), while the linux-linaro branch would be used mostly for testing and bug fixing. When we see that the linux-linaro-tracking is good enough, we move linux-linaro to it (rebasing to the nearest -rc if necessary). This implies that two versions of the topics must be supported: the current (use the same -rc as linux-linaro) and the next (mainline tip based) ones. Guess the WGs and the LTs are already doing something similar anyway. In tilt anyway we just have tracking and release-based branch. We do use tags now to give tracking a granular history. But there's no concept of -rc based sub-release atm. I guess you mention -rc basis because you're looking to make it a rendezvous point for combined tree, which is fair enough, although later in the cycle I found it's really accepting of quite a bit of deviation from exact same basis. Generally, we only trash tracking once per cycle at the start when mainline undergoes its convulsion. The rest of the cycle, tracking should normally be tending to get better monotonically, since I don't normally push a new tree until it seems to be performing as well as what's in the repo already, unless there are special circumstances. Without thinking I would say that every branch (tracking, stable, etc.) and tag (release candidate, release etc.) should have the same -core subset explicitely marked. At best we could sneak that service in for todays release candidate? We probably could. But this has very little value for the current 12.04 release. Having linux-linaro-tracking-core *well before* the 12.05 release is much more important than right before the 12.04. That's why we could consider the linux-linaro-tracking* branches to follow the mainline tip more closely than with per -rc granularity. My understanding is that it would help for Andy for this release. Can we just do the tags/branches? No I did not mention anything about that. Today we only have half a tree undergoing a delayed rebase on 3.4-rc3+. That's running on its own timetable (ie, as fast as we can do it) that is completely disconnected to any monthly release action. We need this -core thing not to speed us up for a monthly deadline but because existing approach isn't workable. We better get used to the idea that now we want HEAD of everything (laudably) none of these trees, the LT ones, mainline, the mandatory source trees, none of them intrinsically care a fig about some random monthly release deadline and will only be in sync with what you want by occasional accident. Last known good approach is not what you might think in this case either, since to combine them you'll have to revert all the trees to the same (or similar if late in the cycle) basis point, and for some LTs having to also revert to match the bad boy, that may be in worse state than their HEAD. You'll sometimes only be able reissue last known good combined tree, not generate a new one at all. The combined tree has some unique characteristics. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
