Re: [PATCH 4/8] ARM: vexpress: use generic cpu idle function for wfi
On Tue, 11 Jun 2013, Pawel Moll wrote:
On Tue, 2013-06-11 at 06:33 +0100, Sanjay Singh Rawat wrote:
use cpu_do_idle for entering the wfi mode.
Signed-off-by: Sanjay Singh Rawat sanjay.ra...@linaro.org
---
arch/arm/mach-vexpress/hotplug.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-vexpress/hotplug.c
b/arch/arm/mach-vexpress/hotplug.c
index f0ce6b8..b3dffc2 100644
--- a/arch/arm/mach-vexpress/hotplug.c
+++ b/arch/arm/mach-vexpress/hotplug.c
@@ -60,7 +60,8 @@ static inline void platform_do_lowpower(unsigned int
cpu, int *spurious)
* code will have already disabled interrupts
*/
for (;;) {
-wfi();
+/* enter WFI mode */
+cpu_do_idle();
if (pen_release == cpu_logical_map(cpu)) {
/*
I probably don't get the whole picture, but may I ask what is the
rationale behind this change? As in: why cpu_do_idle() is better?
commit: 8553cb67d2318db327071018fc81084cbabccc46 explains that
Oh, I've noticed the dsb there, I'm just asking why is it necessary in
the cpu_die() case? The core is going down anyway, it left the coherency
domain and we could cut the power now (if only it was possible). All
cache maintenance (which undoubtedly included dsb) has been long done.
Now, don't get me wrong - I'm not saying it's wrong to do the dsb. I
simply would like to know if and why is required (I'm admitting my
ignorance here ;-) But if you simply grep-ed for wfi() in the whole
kernel and automatically replaced them with cpu_do_idle(), it doesn't
make sense.
That's my feeling too. There is a semantic difference between calling
cpu_do_idle() and executing a WFI inline. I'd use cpu_do_idle() only in
those cases where the call is expected to return and keep the inlined
WFI otherwise (with the added DSB when necessary which is not all cases
as explained above).
Nicolas
___
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 Thu, 30 May 2013, Dave Martin wrote: So, the problem is the hacked DT bindings we're using for vexpress, which aren't compatible with upstream -- the perf changes assume these non-standard bindings are in use. Your fix won't work for platforms which describe multiple CPU PMUs in their DTs -- but that shouldn't happen for non-multicluster platforms anyway. Since this code needs significant rework anyway, I think your patch is a reasonable workaround for now? Nico, do you think it's worth picking this up in your tree? It only really affects people using the BL support in multiplatform kernels. You are the perf master, so if you agree I agree. I'd need a patch that can be applied though. And your ACK would be good. In fact Tixy might be interested as well as the IKS patches feed into the linux-linaro tree via his tree. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] cpuidle: arm_big_little: route target residency to mcpm
On Thu, 16 May 2013, Liviu Dudau wrote: From previous discussions between Achin, Charles and Nico I am aware that Nico has decided for the moment that target residency should be useful enough to be used by MCPM. That is because Nico is a big proponent of doing everything in the kernel and keeping the firmware dumb and (mostly) out of the way. However, the view that we have here at ARM (but I will only speak in my name here) is that in order to have alignment with AArch64 kernel and the way it is using PSCI interface, we should be moving the kernel on AArch32 and armv7a to run in non-secure mode. At that time, the kernel will make PSCI calls to do CPU_ON, CPU_SUSPEND, etc. and the aim is to provide to the firmware the deepest C-state that the core can support going to without being woken up to do any additional state management. It is then the latitude of the firmware to put the core in that state or to tally the sum of all requests in a cluster and decide to put the cores and the cluster in the lowest common C-state. That's all good. My worry is about the definition of all the different C-state on all the different platforms. I think it is simpler to have the kernel tell the firmware what it anticipates in terms of load/quiescence periods (e.g. the next interrupt is likely to happen in x millisecs), and let the firmware and/or low-level machine specific backend translate that into the appropriate C-state on its own. After all, the firmware is supposed to know what is the best C-state to apply given a target latency and the current state of the surrounding CPUs, which may also differ depending on the cluster type, etc. Regarding the migration of the guest kernels, it should be transparent (to a certain extent) wether on resume it is running on the same core or it has been migrated. The host OS should have a better understanding on what can be achieved and what invariants it can still hold, but it should not be limited to do that in a specific amount of time. Lets take an example: one core in the cluster says that it can go as deep as cluster shutdown but it does so in your use of the API by saying that it would like to sleep for at least amount X of time. The host however has to tally all the cores in the cluster in order to decide if the cluster can be shutdown, has to do a lot of cache maintainance and state saving, turning off clocks and devices etc, and in doing so is going to consume some compute cycles; it will then substract the time spent making a decision and doing the cleanup and then figure out if there is still time left for each of the cores to go to sleep for the specified amount of time. All this implies that the guest has to have an understanding of the time the host is spending in doing maintainance operations before asking the hypervisor for a target residency and the host still has to do the math again to validate that the guest request is still valid. I don't follow your reasoning. Why would the guest have to care about what the host can do at all and in what amount of time? What the guest should tell the host is this: I don't anticipate any need for the CPU during the next 500 ms so take this as a hint to perform the most efficient power saving given the constraints you alone have the knowledge of. The host should know how long it takes to flush its cache, whether or not that cache is in use by other guests, etc. But the guest should not care. And in this case the math performed by the guest and the host are completely different. If we choose to use the target C-state, the request validation is simplified to a comparision between each core target C-state and the lowest common C-state per cluster, all done in the host. Of course, by describing C-states in terms of target residency times both schemes can be considered equivalent. But that target residency time is not constant for all code paths and for all conditions and that makes the decision process more complicated. For who? If the guest is responsible for choosing a C-state itself and pass it on to the host, it has to process through a set of available C-states and select the proper one according to the target residency time it must compute anyway since this is all the scheduler can tell you. And since those C-states are likely to have different latency profiles on different clusters, the guest will have to query the type of host it is running on or the available C-states each time it wants to select one, etc. So I don't think passing the target residency directly to the host is more complicated when you look at the big picture. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] configs: linaro-base: Enable CRYPTO_[AES|SHA1]_ARM
On Wed, 15 May 2013, Ard Biesheuvel wrote: On 15 May 2013 14:38, Jon Medhurst (Tixy) t...@linaro.org wrote: I see that the ARM version is following the pattern of SPARC64 and X86 SSSE3 in how it is configured, so for fear of opening a can of worms, perhaps it's simpler if we just go with the linaro-base.conf patch which started this thread? :-) Yes please! Please make sure your sp adjustment patch is included or you'll get corrupted SHA1 digest whenever an interrupt is serviced in the middle of the SHA1 processing ( ... unless you have CONFIG_KPROBES=y in which case you would have been lucky to get headroom on the stack). Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
The Linaro IKS code now publicly available
I'm delighted to announce that the Linaro Technical Steering Committee has approved the release of the big.LITTLE in-kernel switcher (IKS) code to the public. So here it is: Branch big.LITTLE-IKS-snapshot of git://git.linaro.org/landing-teams/working/arm/kernel.git Although this is a snapshot of our latest IKS code, it still needs some minor tidying before it is submitted upstream. So please consider the above as a temporary branch for people to look and play with, and not a branch that we'll keep stable and maintain. This code was also developed for and tested on the VExpress TC2 development platform. An MCPM backend and possibly a special cpufreq clock driver are required for this code to be usable on other platforms. The switcher concept is discussed here: http://lwn.net/Articles/481055/ Porting documentation is available here: https://wiki.linaro.org/projects/big.LITTLE.MP/Big.Little.Switcher/Docs/porting-guide The switcher code description is available here (slightly out of date): https://wiki.linaro.org/projects/big.LITTLE.MP/Big.Little.Switcher/Docs/in-kernel-code And a review of the MCPM layer upon which IKS and HMP rely: http://lwn.net/Articles/539082/ The core MCPM patches are queued for inclusion into the v3.10 mainline kernel. The MCPM backend for TC2 and the IKS patches will tentatively be submitted for v3.11. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC 1/1] clk: Add notifier support in clk_prepare_enable/clk_disable_unprepare
On Fri, 15 Mar 2013, Russell King - ARM Linux wrote: On Tue, Mar 12, 2013 at 06:47:53PM -0700, Bill Huang wrote: On Tue, 2013-03-12 at 21:40 +0800, Russell King - ARM Linux wrote: On Tue, Mar 12, 2013 at 05:37:41AM -0700, Bill Huang wrote: Add the below four notifier events so drivers which are interested in knowing the clock status can act accordingly. This is extremely useful in some of the DVFS (Dynamic Voltage Frequency Scaling) design. PRE_CLK_ENABLE POST_CLK_ENABLE PRE_CLK_DISABLE POST_CLK_DISABLE Signed-off-by: Bill Huang bilhu...@nvidia.com NAK. *Sigh* NO, this is the wrong level to be doing stuff like this. The *ONLY* thing that clk_prepare_enable() and clk_prepare_disable() should *EVER* be doing is calling clk_prepare(), clk_enable(), clk_disable() and clk_unprepare(). Those two functions are *merely* helpers for drivers who don't wish to make the individual calls. Drivers are still completely free to call the individual functions, at which point your proposal breaks horribly - and they _do_ call the individual functions. I'm proposing to give device driver a choice when it knows that some driver might be interested in knowing its clock's enabled/disabled state change at runtime, this is very important for centralized DVFS core driver. It is not meant to be covering all cases especially for drivers which is not part of the DVFS, so we don't care if it is calling clk_enable/disable directly or not. But you're not giving drivers a choice. You're giving them an ultimatum. Either they use clk_prepare_enable() which must only be called from non- atomic contexts and have the notifiers, or if they need to use the individual functions (which is what they _should_ be doing but people are too lazy to properly convert stuff) they don't get the option of the notifiers at all. This sucks totally, design wise. The whole point of clk_prepare_enable() is that it is a helper function to _only_ do the clk_prepare() call followed by a clk_enable() call and _nothing_ _else_ _what_ _so_ _ever_. If people are too lazy and start abusing clk_prepare_enable() then this helper function becomes counter-productive and should simply be removed. Same issue as with IS_ERR_OR_NULL(). Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: No section mismatch warnings for Thumb2 kernels
On Wed, 20 Feb 2013, Jon Medhurst (Tixy) wrote: After some time investigating why I wasn't seeing some kernel section mismatch errors that someone else was seeing, I found the cause was that in Linaro we build Thumb2 kernels in the main, and modpost.c doesn't have support for any of the Thumb relocation types in addend_arm_rel(). I thought I would spread this knowledge, because lack of section mismatch warnings means we might miss some nasty bugs when developing code. If this is old news, then sorry for the noise. This is not old news to me. In fact, I think you should create a bug for this issue so it is tracked and fixed. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: suggestion: move kernel patches off linaro-dev
On Mon, 18 Feb 2013, Amit Kucheria wrote: Since Peter and I were discussing this on IRC that led to this email, here is a bit of context on the current behaviour: On Mon, Feb 18, 2013 at 8:16 PM, Peter Maydell peter.mayd...@linaro.org wrote: Hi; does anybody else think it would be a good idea to move all the kernel patch email traffic off linaro-dev and onto a more kernel-specific mailing list (eg, linaro-kernel, maybe) ? A quick eyeball of a few pages of my gmail folder for linaro-dev shows that something like 75% of it is kernel devs patchbombing the list. You don't see huge floods of patches here for gcc or QEMU or any of the many other projects Linaro contributes to, so why all the kernel patches? linaro-dev was supposed to be how we kept track of all development activity that Linaro was involved in - it wasn't supposed to be restricted only to kernel. IOW, someone could subscribe to this one list to find out everything that Linaro was participating in. So much so that it was baked into our guidelines for how to use git to send patches to upstream projects[1] Admittedly, those were early days and our contributions to upstream projects have grown significantly since then. So it might be time to revisit that policy. I think that moving these off to their own list would allow those who have a genuine interest in kernel internals to read and review these patches, and reduce the noise level on this (Linaro's most generic list) for everybody else. NB: I'm not suggesting no kernel discussion here; I just would like actual patchmail to go elsewhere... For the record, I think what Peter is suggesting is reasonable. There must be better ways for people to find out what Linaro is participating in other than scaring them away from linaro-dev when they have no interest in the patch details. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] Genericise CPUIdle for ARM big.LITTLE
On Wed, 16 Jan 2013, Mark Hambleton wrote: +obj-$(CONFIG_BIG_LITTLE) += arm_big_little.o There is nothing big.LITTLE specific in all of this, so arm_idle.c would be better. I figured that because the current version calls into the big.little platform power framework (bL_entry.c) and makes calls into that framework that this wasn't totally generic and is dependant upon that code. The version of the cpuidle driver won't build unless that code is built in, so I still think this is more appropriate naming, I could call it bL_* but I suspect someone will object to that upstream because of the mixed case. Well, calling it big.LITTLE, bL or whatever else describing a big and a LITTLE is wrong IMHO because it makes people think this a driver for big.LITTLE ARM platforms. And it is not, if we ever manage to make it generic. You are missing the point, this driver is dependent on the big.little framework that is being upstreamed by Nicolas / Dave, so it is big.little specific (specific to the big.little framework). When a truly generic version is available this one could be removed. The b.L framework is not really b.L specific. As such I'll try to rename it before it gets merged. Somehow, finding a good name isn't trivial. I fail to understand why we want to make this code generic NOW, ARM kernel is not ready for that and to be honest I do not see why it has to be done now. Because we are about to take a copy of this code and make some tiny modifications to it to make it run on our platform, and this seemed a better solution (I suspect a few others are about to do the same, like they used to do with platsmp and all that other good stuff that Nicolas / Dave have been cleaning up). Basically, if you guys really aren't interested in a step towards less code lurking in mach-vexpress we can carry patches to make things work, just seemed like an easy enough win... To be honest, your patch is a good thing. The driver definitely has to move out of mach-vexpress. It is just not the fish we are (I am) frying at the moment. But I think Tixy could just pick it up into the ARM »LT tree for now. Obviously, the driver will evolve over time. That may as well happen in its proper location. Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH] Genericise CPUIdle for ARM big.LITTLE
On Tue, 15 Jan 2013, Mark Hambleton wrote: Hi Lorenzo, +obj-$(CONFIG_BIG_LITTLE) += arm_big_little.o There is nothing big.LITTLE specific in all of this, so arm_idle.c would be better. I figured that because the current version calls into the big.little platform power framework (bL_entry.c) and makes calls into that framework that this wasn't totally generic and is dependant upon that code. The version of the cpuidle driver won't build unless that code is built in, so I still think this is more appropriate naming, I could call it bL_* but I suspect someone will object to that upstream because of the mixed case. I'll wait that someone with a cluebat. Semantically, bL_ is the most efficient prefix you could find to refer to big.LITTLE. And no one eported any issue with that from the initial public review so far. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [kvmarm] [PATCH] bootwrapper: CPU hotplug aware boot protocol
On Fri, 14 Dec 2012, Marc Zyngier wrote: On 14/12/12 15:54, Jon Medhurst (Tixy) wrote: I must admit, my patch is based on someone elses work, and I've not seen documentation which says that NOR flash can be written to simply by the application being loaded by the models having code located at the relevant address. I do know, that this code works on both A15 and A15xA7 models to boot Linux and Android, and that the new support it provides for power down and up cores works. I'll try and see if I can find out if locating code at address zero is officially supported... In the horrible hack that I use to boot both TC2 and RTSM, I use the static RAM located at 0x2E00. It is only 64kB though. That misses the point. This patch has to hook some code at the address where the reset vector is, so that we can get control of a CPU when it is brought back out of reset. So gents, please let stop splitting hairs. This is required for CPU hotplug to work, and by extension the b.L switcher. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making countless kernel reboots painless on TC2
On Wed, 24 Oct 2012, Viresh Kumar wrote: Nice article! Thanks. On 24 October 2012 08:26, Nicolas Pitre nicolas.pi...@linaro.org wrote: When working on low level kernel code, the indication that something went wrong is often noticed as a kernel oops, or even a totally silent system. This usually implies a modify-recompile-reboot cycle which can become very very annoying if the reboot step implies popping out an SD card from the board, inserting it into the work PC, mounting it, copying the newly compiled kernel over, unmounting, moving the SD card back to the board, to finally hit the reset button. You can also connect vexpress board with your PC with a USB cable, and the uSD card will be shown on your PC as data storage, as soon as bootloader or bootmonitor is on. You can simply copy files from your linux pc to this storage and reboot :) I know. But that implies mounting and unmounting the device (unless you have an auto-mounter set up which I haven't). Also, this makes the boot very long when large files have to be reflashed, especially ramdisk images. And this is not very flexible when requiring runtime changes to the DTB. And for me, the deal breaker is the fact that all the other boards on my desk don't have such fancy USB storage connection and they are set up for booting over the network already. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making countless kernel reboots painless on TC2
On Wed, 24 Oct 2012, Jon Medhurst (Tixy) wrote: The official release pages will include _some_ similar (and more up to date information), however you won't find any mention of any bootloader other than UEFI. Another bootloader to hate. Joy! And, at least for now, no mention of how to boot a kernel other than by removing the SD card and copying it over. Maybe good for production, but abominable for development. I'm not buying. Personally (and unofficially), I find that the simplest and most reliable way to use vexpress is to flash the kernel/dtb/initrd images into NOR flash and use the bootmonitor supplied with the board to load these. Yes, did that before. The reflashing is still relatively long, enough to annoy me. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making countless kernel reboots painless on TC2
On Wed, 24 Oct 2012, Ryan Harkin wrote: On 24 October 2012 09:29, Jon Medhurst (Tixy) t...@linaro.org wrote: Personally (and unofficially), I find that the simplest and most reliable way to use vexpress is to flash the kernel/dtb/initrd images into NOR flash and use the bootmonitor supplied with the board to load these. No you don't. The party line is: we all use UEFI. ;-) If it does TFTP and can be scripted then I don't mind. Otherwise, if I'm going to still use U-Boot in the end then UEFI will be just an extra roundtrip into another to-be-despised bootloader in lack of visibility and attention since it'll do nothing but increase my kernel boot latency. Did I mention already that I hate bootloaders? Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Making countless kernel reboots painless on TC2
On Wed, 24 Oct 2012, Pawel Moll wrote: On Tue, 2012-10-23 at 22:56 -0400, Nicolas Pitre wrote: The script to generate a boot script to generate an ATAGS block is a rather nice hack. These days are, fortunately, long gone :-) I deduced as much, given your example boot log reported a RTC time in 2004. Still, that was a nice piece of art IMHO. New-ish Boot Monitors (5.x.x versions in particular) speak initrd, ATAG _and_ DTB natively, so one can boot the board with fl linux initrd busybox fl linux fdt ca9 fl linux boot zimage console=ttyAMA0,38400 It still can't do TFTP though, so it's just a formal remark - I'm not trying to convert anyone. I think it is not wrong to have second stage bootloaders. No need to duplicate functionality if an existing piece of software does it well already. Eventually this is down to personal work habits and preferences. Having the choice is good. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Making countless kernel reboots painless on TC2
When working on low level kernel code, the indication that something went wrong is often noticed as a kernel oops, or even a totally silent system. This usually implies a modify-recompile-reboot cycle which can become very very annoying if the reboot step implies popping out an SD card from the board, inserting it into the work PC, mounting it, copying the newly compiled kernel over, unmounting, moving the SD card back to the board, to finally hit the reset button. If you are an old fashioned kernel developer like me and live by the simplest development environment (bash, vi, gcc) and your most trusted debugging tool is printk(), then having the ability to quickly boot a new kernel after moving printk traces around in order to pinpoint a crash location is vital. But even for validation purposes on a remote board, not needing physical intervention is really nice. So, by popular demand, here's how I accomplished this on VirtualExpress with a TC2 tile. This probably applies to other VirtualExpress configurations too, but TC2 is the only one I tested. Obtaining U-Boot I don't have a particular affection for any bootloaders. They tend to ask for more and more attention and visibility while their raison d'être is actually to get out of the way and disappear as fast as possible. While U-Boot has many things that certainly gets on my nerves, it has a good point for itself which is its networking support. And here is the key: let's fetch everything we need to boot the board over the network, script it, so not to have to deal with the bootloader (or bootloaders in this case) anymore. First, let's get a copy of the U-Boot source tree. I used the Linaro version as it includes Versatile Express support. $ git clone git://git.linaro.org/boot/u-boot-linaro-stable.git $ cd u-boot-linaro-stable/ Now... to get rid of U-Boot's most obnoxious feature (my opinion), the following patch should be applied: diff --git a/include/configs/vexpress_common.h b/include/configs/vexpress_common.h index 88a2c95..3328443 100644 --- a/include/configs/vexpress_common.h +++ b/include/configs/vexpress_common.h @@ -177,6 +177,8 @@ #define CONFIG_CMD_SAVEENV #define CONFIG_CMD_RUN #define CONFIG_CMD_BOOTD +#define CONFIG_CMD_BOOTZ +#define CONFIG_SUPPORT_RAW_INITRD #define CONFIG_CMD_ECHO #define CONFIG_CMD_FAT That basically enables U-Boot to boot a plain ARM Linux zImage file without going through the mkimage step (the bootz command), and load a plain ramdisk image without having to run mkimage on it. This mkimage step is just extra fuss I can dispense with when working on and booting kernels frequently. Now let's build it. There is no TC2 (ca15 or ca7) config, however the ca5 one appears to be close enough for our needs: $ make vexpress_ca5x2 You should end up with a u-boot.bin to be used later. ARM Versatile Express Boot Monitor -- This is the native boot loader on the Virtual Express. In fact there are many instances of different loaders even on different processors making the whole system rather weird but flexible. It lacks the ability to load files from the network though. But that's what a second stage bootloader such as U-Boot is for. Good information on setting up a Virtual Express already exists. While the instructions listed therein may or may not all apply to our case, I still recommend to read the following pages to get familiar with this beast: https://wiki.linaro.org/PawelMoll/BootingVEMadeEasy The script to generate a boot script to generate an ATAGS block is a rather nice hack. But I want runtime DTB support and I prefer booting over the network, especially when playing with ramdisk images which is otherwise long to get reflashed. Still this page provides a nice introduction to Virtual Express setup and gives good insights on the micro switch usage and the VE boot monitor structure. https://wiki.linaro.org/ARM/VersatileExpressSetup This page shows how to install U-Boot on a Virtual Express and that's what we want here. you should follow the instructions listed for the CA15x2 CoreTile, except that the U-Boot binary to use is the one we just compiled above. Also, for TC2 the images.txt file is located in SITE1/HBI0249A/. In short, once the internal MicroSD card is mounted over USb, the u-boot.bin file we compiled should be copied to SOFTWARE/u-boot.bin. Then the file SITE1/HBI0249A/images.txt should be updated to contain something similar to this: NOR4UPDATE: AUTO NOR4ADDRESS: 0f80 NOR4FILE: \SOFTWARE\u-boot.bin NOR4LOAD: 0x8080 NOR4ENTRY: 0x8080 We also need a boot script to start U-Boot automatically: NOR5UPDATE: AUTO NOR5NAME: BOOTSCRIPT NOR5ADDRESS: NOR5FILE: \SOFTWARE\boot.txt Here the BOOTSCRIPT name is important otherwise the script won't be found and executed. The number after NOR may differ, depending on the other images your images.txt may already
Re: [RFC 3/4] ARM: topology: Update cpu_power according to DT information
On Wed, 13 Jun 2012, Peter Zijlstra wrote: On Tue, 2012-06-12 at 14:02 +0200, Vincent Guittot wrote: +#ifdef CONFIG_OF That must really be the worst CONFIG_ name ever.. Indeed! We must corner Grant to do a s/CONFIG_OF/CONFIG_DEVICE_TREE/ on the whole tree and send the patch to Linus. He just managed to chicken away from doing it so far. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: won't someone please think of the users!?
On Fri, 6 Apr 2012, Ricardo Salveti wrote: On Fri, Apr 6, 2012 at 6:05 AM, Wookey woo...@wookware.org wrote: The fundamental question really is 'are we a distro or not'? If linaro is not a distro then no-one should be expecting stable releases - we are a technology showcase, and developer quick-start mechanism, and the existing process seems reasonably appropriate for that, but if we are expecting people to actually base real work off our outputs, then he's right and we ought to change some things. It might be the same thing, but for me the question is really do we care about users and we want people to use our LEBs?. If we assume the LEBs are just a bunch of evaluation images to be used internally to help improving the development and testing, then you could simply say that we're not any kind of distro. Now if we decide to have people using and consuming our LEBs (what I believe we do), then we need to think a bit further, and assume some extra responsibilities. We don't want to be a full distro, as we want to be flexible enough to break things once a while, but we really need to be aware that once we get users running our images, they will *expect* some sort of stability, putting us back as we were a distro :-) Stability is not sufficient. Users will also expect support, updates, and security fixes, etc. And the more stable our stuff looks, the more users and user demands we'll get. Fulfilling those user *expectations* is hard and costly. Some companies are basing their entire business on that, and they do a really great job already. We certainly don't shine at being a distro, and IMHO we shouldn't even try. If some people want the latest cool stuff we provide that's fine, but they should expect a shaky world. Existing distro people out there will pick up our work too and stabilize it. In fact, they are encouraged to do so. Stabilization takes time, which is why there is a delay before our stuff is available through existing distros. There is simply no way around that. Stable and latest bleeding edge are simply not compatible. If Linaro is to produce stabilized releases, we'll introduce extra delays too, and we'll consume a significant amount of development resources doing that. Therefore I don't think we should duplicate what distro people are already doing. That shouldn't be where our focus is. Expectations to users should probably be clarified as well. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v8 0/8] Consolidate cpuidle functionality
On Tue, 20 Mar 2012, Kevin Hilman wrote: Looks like you never heard from anyone actively working on at91, shmobile, kirwood or davinci. I'm not sure we should merge those platform-specific changes without an ack from those platform maintainers. Depends. There is a limit to how long you may be willing to wait after people. Sometimes the only way to make progress is to merge the thing and hope that someone who cares will test the stuff during the ~2 months -rc period and provide any fix then. And if that doesn't happen during that time then either the code is just right and no one noticed the change, or no one cares anymore. IMHO, Rob posted those patches many times now for quite a while (many months) already. So I'd suggest simply pushing that stuff into mainline as is. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v8 0/8] Consolidate cpuidle functionality
On Wed, 21 Mar 2012, Amit Kucheria wrote: On Wed, Mar 21, 2012 at 12:48 AM, Kevin Hilman khil...@ti.com wrote: Maybe it's time that drivers/cpuidle gets a maintainer. With lots of discussions of scheduler changes that affect load estimation, I suspect we're all going to have a bit of CPUidle work to do in the not-so-distant future. I don't mean to be piling on to Len here, but Daniel Lezcano too has a bunch of clean ups that didn't get any maintainer review for over two months. He has now refreshed them for 3.3 and is getting ready to send them out again. We (Linaro) expect to be spending a lot of time on cpuidle in the future and would be glad to help review, test and collect patches into a tree for Linus/Andrew to pull while we wait for Len to respond or another maintainer to emerge. As I advised recently, it is usually a good idea for the person/group who is working the most on a subsystem to simply take the lead and become the new maintainer. Waiting for another maintainer to emerge could be compared to cowardice. Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
On Tue, 20 Mar 2012, Paul Walmsley wrote: We need to indicate in some way that the existing code and API is very likely to change in ways that could involve quite a bit of work for adopters. [...] Anyway. It is okay if we want to have some starter common clock framework in mainline; this is why deferring the merge hasn't been proposed. But the point is that anyone who bases their code or platform on the common clock framework needs to be aware that, to satisfy one of its major use-cases, the behavior and/or API of the common clock code may need to change significantly. Paul, While I understand your concern, please don't forget that the perfect is the enemy of the good. This common clk API has been under development for over *two* years already, with several attempts to merge it. And each previous merge attempt aborted because someone came along at the last minute to do exactly what you are doing i.e. underline all the flaws and call for a redesign. This is becoming a bad joke. We finally have something that the majority of reviewers are happy with and which should cover the majority of existing cases out there. Let's give it a chance, shall we? Otherwise one might ask where were you during those development years if you claim that the behavior and/or API of the common clock code still need to change significantly? Explicitly stating this is not only simple courtesy to its users, many of whom won't have been privy to its development. It also is intended to make the code easier to change once it reaches mainline. The code will be easier to change once it is in mainline, simply due to the fact that you can also change all its users at once. And it is well possible that most users won't have to deal with the same magnitude of complexity as yours, again reducing the scope for resistance to changes. Let's see how things go with the current code and improve it incrementally. Otherwise no one will get involved with this API which is almost just as bad as not having the code merged at all. So, until the API is well-defined and does all that it needs to do for its major users, [...] No, the API simply can't ever be well defined if people don't actually start using it to eventually refine it further. Major users were converted to it, and in most cases The API does all that it needs to do already. Otherwise you'll be stuck in a catch22 situation forever. And APIs in the Linux kernel do change all the time. There is no stable API in the kernel. Extensions will come about eventually, and existing users (simple ones by definition if the current API already meets their needs) should be converted over easily. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v7 1/3] Documentation: common clk API
On Fri, 16 Mar 2012, Arnd Bergmann wrote: FWIW, it's in arm-soc now, and it's the last thing I put in there for v3.4. Amen! Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: boot failure with __iounmap changes in v3.3
On Mon, 12 Mar 2012, jonsm...@gmail.com wrote:
On Mon, Mar 12, 2012 at 4:18 PM, Nicolas Pitre nicolas.pi...@linaro.org
wrote:
On Mon, 12 Mar 2012, jonsm...@gmail.com wrote:
I'm working on getting out of tree support for the NXP LPC31xx
ARM926EJS based CPUs ready for submission. Everything was working fine
on v3.2 but I lost the ability to boot with v3.3. The boot failure is
very early in the boot process. I did a bisect and came up with:
[6ee723a6570a897208b76ab3e9a495e9106b2f8c] ARM: simplify __iounmap()
when dealing with section based mapping
I tried to revert it but there have been a bunch of edits in this
file. Not sure how to go about debugging this.
The first thing to look for is any overlap in the virtual memory ranges
used in your struct map_desc array. No overlap is allowed anymore.
There appear to be overlaps. I'll have to study things for a while to
figure out how to eliminate them. This is from a three year old NXP
BSP. We have a product based on the CPU and want to use a more recent
kernel.
They've defined multiple large peripheral regions...
/* APB4 address range*/
#define IO_APB4_PHYS (0x1700)
#define IO_APB4_SIZE (0x1000)
{
.virtual= io_p2v(IO_APB4_PHYS),
.pfn= __phys_to_pfn(IO_APB4_PHYS),
.length = IO_APB4_SIZE,
.type = MT_DEVICE
},
and then declared various devices inside of them...
/* DMA registers address range*/
#define DMA_PHYS (0x1700)
#define IO_DMA_REG_PHYS (DMA_PHYS)
#define IO_DMA_REG_SIZE (0x800)
{
.virtual= io_p2v(IO_DMA_REG_PHYS),
.pfn= __phys_to_pfn(IO_DMA_REG_PHYS),
.length = IO_DMA_REG_SIZE,
.type = MT_DEVICE
},
Just get rid of the map_desc entryes corresponding to subsets of a
larger entry that already covers them and you should be fine.
Nicolas___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH-WIP 01/13] xen/arm: use r12 to pass the hypercall number to the hypervisor
On Fri, 9 Mar 2012, Dave Martin wrote: Register variables feel like a red herring though. We're only using those because we can't do the needful thing and actually desscribe these constraints in the asm constraints (which would seem to be the right place). We specifically don't care where those values are except at the boundaries of the asm block itself. Absolutely. Is there a reason why ARM gcc doesn't provide the ability to specify such exact-register constraints, or is this more for historical reasons? It is possible? I don't know how much things have changed since I last looked at the gcc code, but implementing this seemed to be pretty trivial at the time. The problem would be to determine a good letter scheme to map to actual registers. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH-WIP 01/13] xen/arm: use r12 to pass the hypercall number to the hypervisor
On Thu, 8 Mar 2012, Richard Earnshaw wrote:
On 02/03/12 21:15, Nicolas Pitre wrote:
So, to me, the gcc documentation is perfectly clear on this topic.
there really _is_ a guarantee that those asm marked variables will be in
the expected registers on entry to the inline asm, given that the
variable is _also_ listed as an operand to the asm statement. But only
in that case.
It is true that gcc may reorder other function calls or other code
around the inline asm and then intervening code can clobber any
registers. Then it is up to gcc to preserve the variable's content
elsewhere when its register is used for other purposes, and restore it
when some inline asm statement is referring to it.
And if gcc does not do this then it is buggy. Version 3.4.0 of gcc was
buggy. No other gcc versions in the last 7 years had such a problem or
the __asmeq macro in the kernel would have told us.
Or, to summarise another way, there is no way to control which register
is used to pass something to an inline asm in general (often we get away
with this, and there are a lot of inline asms in the kernel that assume
it works, but the more you inline the more likely you are to get nasty
surprises).
This statement is therefore unfounded and wrong. Please direct the
tools guy who mislead you to the above gcc documentation.
The problem is not really about re-ordering functions but about implicit
functions that come from the source code; for example
int foo (int a, int b)
{
register int x __asm__(r0) = 33;
register int c __asm__(r1) = a / b; /* Ooops, clobbers r0 with
division function call. */
asm (svc 0 : : r (x));
}
There's nothing in the specification to say what happens if there's a
statement in the code that causes an implicit clobber of your assembly
register.
I'm sure gcc is full of implicit behaviors that are not mentioned in
the specification. But as long as the specification is respected, then
there is no need to mention any unobservable side effects from a program
flow point of view, right?
Why wouldn't gcc be able to respect the documented feature by
preventing live variable from being clobbered and reloading them in
the specified register at the inline asm entry point, just like it does
for function calls?
Here's an example code that shows that, unfortunately, gcc is still
broken with regards to the documented behavior:
extern int bar(int);
int foo(int y)
{
register int x __asm__(r1) = 33;
y += bar(x);
asm (@ x should be live in %0 here : +r (x) : r (y));
y += bar(x);
asm (@ x should be live in %0 here : +r (x) : r (y));
return x;
}
Result is:
foo:
stmfd sp!, {r4, lr}
mov r4, r0
mov r0, #33
bl bar
add r4, r0, r4
@ x should be live in r1 here
mov r0, r1
bl bar
add r0, r0, r4
@ x should be live in r1 here
mov r0, r1
ldmfd sp!, {r4, lr}
bx lr
To me this is clearly a bug if gcc is not able to meet the documented
expectation. And the documented expectation is not at all unreasonable.
Nicolas
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH-WIP 01/13] xen/arm: use r12 to pass the hypercall number to the hypervisor
[ coming back from vacation and trying to catch up ] On Wed, 29 Feb 2012, Dave Martin wrote: Just had a chat with some tools guys -- apparently, when passing register arguments to gcc inline asms there really isn't a guarantee that those variables will be in the expected registers on entry to the inline asm. If gcc reorders other function calls or other code around the inline asm (which it can do, except under certain controlled situations), then intervening code can clobber any registers in general. I'm hearing this argument about once every year or so for the last 8 years. I think that the tools people are getting confused between themselves as you may get a different interpretation of what gcc should do depending to whom you happen to talk to. I did submit a bug to gcc in 2004 about this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15089 You can see the confusion among gcc developers lurking there. So let's quote the relevant gcc documentation: - * C Extensions::GNU extensions to the C language family. - * Explicit Reg Vars:: Defining variables residing in specified registers. |GNU C allows you to put a few global variables into specified hardware |registers. You can also specify the register in which an ordinary |register variable should be allocated. | | * Global register variables reserve registers throughout the program. | This may be useful in programs such as programming language | interpreters which have a couple of global variables that are | accessed very often. | | * Local register variables in specific registers do not reserve the | registers, except at the point where they are used as input or | output operands in an `asm' statement and the `asm' statement | itself is not deleted. The compiler's data flow analysis is | capable of determining where the specified registers contain live | values, and where they are available for other uses. Stores into | local register variables may be deleted when they appear to be | dead according to dataflow analysis. References to local register | variables may be deleted or moved or simplified. | | These local variables are sometimes convenient for use with the | extended `asm' feature (*note Extended Asm::), if you want to | write one output of the assembler instruction directly into a | particular register. (This will work provided the register you | specify fits the constraints specified for that operand in the | `asm'.) - * Local Reg Vars:: [...] | Defining such a register variable does not reserve the register; it |remains available for other uses in places where flow control |determines the variable's value is not live. | | This option does not guarantee that GCC will generate code that has |this variable in the register you specify at all times. You may not |code an explicit reference to this register in the _assembler |instruction template_ part of an `asm' statement and assume it will |always refer to this variable. However, using the variable as an `asm' |_operand_ guarantees that the specified register is used for the |operand. So, to me, the gcc documentation is perfectly clear on this topic. there really _is_ a guarantee that those asm marked variables will be in the expected registers on entry to the inline asm, given that the variable is _also_ listed as an operand to the asm statement. But only in that case. It is true that gcc may reorder other function calls or other code around the inline asm and then intervening code can clobber any registers. Then it is up to gcc to preserve the variable's content elsewhere when its register is used for other purposes, and restore it when some inline asm statement is referring to it. And if gcc does not do this then it is buggy. Version 3.4.0 of gcc was buggy. No other gcc versions in the last 7 years had such a problem or the __asmeq macro in the kernel would have told us. Or, to summarise another way, there is no way to control which register is used to pass something to an inline asm in general (often we get away with this, and there are a lot of inline asms in the kernel that assume it works, but the more you inline the more likely you are to get nasty surprises). This statement is therefore unfounded and wrong. Please direct the tools guy who mislead you to the above gcc documentation. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH-WIP 01/13] xen/arm: use r12 to pass the hypercall number to the hypervisor
On Wed, 29 Feb 2012, Ian Campbell wrote: On Wed, 2012-02-29 at 12:58 +, Dave Martin wrote: On Wed, Feb 29, 2012 at 09:56:02AM +, Ian Campbell wrote: On Wed, 2012-02-29 at 09:34 +, Dave Martin wrote: On Tue, Feb 28, 2012 at 12:28:29PM +, Stefano Stabellini wrote: I don't have a very strong opinion on which register we should use, but I would like to avoid r7 if it is already actively used by gcc. But there is no framepointer for Thumb-2 code (?) Peter Maydell suggested there was: r7 is (used by gcc as) the Thumb frame pointer; I don't know if this makes it worth avoiding in this context. Sounds like it might be a gcc-ism, possibly a non-default option? Anyway, I think r12 will be fine for our purposes so the point is rather moot. Just had a chat with some tools guys -- apparently, when passing register arguments to gcc inline asms there really isn't a guarantee that those variables will be in the expected registers on entry to the inline asm. If gcc reorders other function calls or other code around the inline asm (which it can do, except under certain controlled situations), then intervening code can clobber any registers in general. Or, to summarise another way, there is no way to control which register is used to pass something to an inline asm in general (often we get away with this, and there are a lot of inline asms in the kernel that assume it works, but the more you inline the more likely you are to get nasty surprises). There is no workaroud, except on some architectures where special asm constraints allow specific individual registers to be specified for operands (i386 for example). I had assumed I just couldn't find the right syntax. Useful to know that I couldn't find it because it doesn't exist! It does exist. See my previous reply to this thread. You can find this syntax described in section 6.44.2 Specifying Registers for Local Variables in gcc v4.6.1 (possibly another section number in the documentation for a different gcc version). Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
my LWN article on big.LITTLE
For those of you interested by the topic, my article was published today. With a LWN subscription (or freely accessible in 2 weeks), it can be viewed here: http://lwn.net/Articles/481055/ The comments section is growing fast already! Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What our customers want from Android
On Tue, 31 Jan 2012, Zach Pfeffer wrote: On 31 January 2012 11:19, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Tue, 31 Jan 2012, Zach Pfeffer wrote: They love our builds, but they'd really like it if they could get stock AOSP builds for their boards on stable kernels that they can work with using fastboot that have been CI tested and QA'd. I'm not advocating for the wholesale destruction of our current way of life, tip kernels, tip toolchains, linaro-android-media-create, but I would like to move in a direction that gives our users what they want. And by the time you do that i.e. stable kernel and so on, then those customers will come back asking for this and that new cool feature available in the latest upstream kernel and ask you to backport it to your stable kernel. Nico, you bring up a good point. Consolidating and upstreaming core ARM features that exist across each architecture is our main job. The customer ask remains the same though. If we deliver a platform with a set of features, customers don't want any of those features to break when we give them an upgrade. You just can't have it both ways. If you focus on a stable platform then you cannot have the latest features. If you develop new features, it obviously can't be stable. But whatever you do, customers will always ask for both in a single package. I think it is a matter of clearly defining what we do, and also what we don't (and shouldn't) do. Expectations about Linaro cannot be the same as for Ubuntu/Canonical or Android/Google. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: What our customers want from Android
On Tue, 31 Jan 2012, Zach Pfeffer wrote: On 31 January 2012 15:01, Nicolas Pitre nicolas.pi...@linaro.org wrote: You just can't have it both ways. If you focus on a stable platform then you cannot have the latest features. If you develop new features, it obviously can't be stable. But whatever you do, customers will always ask for both in a single package. I think it is a matter of clearly defining what we do, and also what we don't (and shouldn't) do. Expectations about Linaro cannot be the same as for Ubuntu/Canonical or Android/Google. That is true., but lets talk nuts and bolts. What I think would be good for Linaro to do, is to list the features of each board it wants to support without regressions and define a set of tests against those features. As we improve things, we ensure that the core feature set doesn't break. We have the test cases, so we know exactly what break means. Absolutely. This is why the Linaro CI loop is so important. [...] Then we get to the worst offenders, graphics drivers. These tend to do very interesting things with VM tables against alloc_bootmem regions. UMM probably won't get used here since it won't give vendors the SoC specific, low-level per-page bit twiddling APIs that they need to eke out the last drop of graphics performance. These are definitely a problem, but if there's anywhere we should be confronting issues it would be right here since most of our members feel pain here the most. I can't agree more. However there won't be any good solution here without access to the source code for those graphics drivers. I don't see any easy way out. Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: perf fixes not present in Linaro kernel
On Thu, 15 Dec 2011, Will Deacon wrote: Hi Nicolas, It seems as though some of my perf patches have ended up in the Linaro kernel source but the fixes that I've pushed during the -rc haven't made it: https://bugs.launchpad.net/linaro-landing-team-freescale/+bug/893653 https://bugs.launchpad.net/ubuntu/+source/linux-linaro-omap/+bug/843628 Rather than me point each landing team at the patches, would you be able to cherry-pick the fixes from mainline please? They are: bce34d14 (ARM: perf: initialise used_mask for fake PMU during validation) e5a21327 (ARM: perf: check that we have a platform device when reserving PMU) 6bd05409 (ARM: 7185/1: perf: don't assign platform_device on unsupported CPUs) Cherry-picked and pushed out. Thanks! Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: perf fixes not present in Linaro kernel
On Thu, 15 Dec 2011, Nicolas Pitre wrote: On Thu, 15 Dec 2011, Will Deacon wrote: Rather than me point each landing team at the patches, would you be able to cherry-pick the fixes from mainline please? They are: bce34d14 (ARM: perf: initialise used_mask for fake PMU during validation) e5a21327 (ARM: perf: check that we have a platform device when reserving PMU) 6bd05409 (ARM: 7185/1: perf: don't assign platform_device on unsupported CPUs) Cherry-picked and pushed out. And tagged as linux-linaro-3.1-2011.12-1. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
On Wed, 14 Dec 2011, Amit Kachhap wrote: Hi Nicolas, Is it possible for you to add these 2 patches for this month release? I am not able to give you the git link as there is seems some problem with the linaro git server. Also I attached the patches in case required. I merged them. However it would be a good idea if you could gather at least one Acked-by tag from someone else who is also familiar with that code next time. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 0/2] thermal: Add generic cpu cooling devices according to thermal framework
On Wed, 14 Dec 2011, Amit Kachhap wrote: Hi Nicolas, Please pull my samsung thermal implementation work from git repository (git://git.linaro.org/people/amitdanielk/linux.git thermal_cpu_cooling). Some of the patches are under review and some are in mainline in 3.2 rc* version. It is all based on the tip of your tree. Merged. There were minor conflicts in Kconfig and Makefile with your previous patches that I fixed up. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: latest linux-linaro-3.1 compile errors
On Tue, 13 Dec 2011, John Rigby wrote: With the latest 3.1.5 merge linux-linaro-3.1 fails to build on Jenkins: https://ci.linaro.org/jenkins/view/All%20CI/job/linux-linaro-3.1_panda-omap2plus/303/ GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 `oprofile_arch_exit' referenced in section `.init.text' of arch/arm/oprofile/built-in.o: defined in discarded section `.exit.text' of arch/arm/oprofile/built-in.o `oprofile_arch_exit' referenced in section `.init.text' of arch/arm/oprofile/built-in.o: defined in discarded section `.exit.text' of arch/arm/oprofile/built-in.o Fixed. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linux-next not booting on snowball
On Mon, 12 Dec 2011, Daniel Lezcano wrote: Does anyone have some clues or ideas I can investigate ? I am really not familiar with this part. See the next suggestion I gave you in my previous email. You could also work with Linus Walleij who maintains this architecture, and who has access to the hardware while I don't. I already summarized the problem to him privately. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linux-next not booting on snowball
On Fri, 2 Dec 2011, Daniel Lezcano wrote: ## ## ez-pine-gpg v0.4h ## http://Business-PHP.com/opensource/ez-pine-gpg/ ## Tue Dec 6 22:27:12 EST 2011 ## xanadu.home ## gpg: Signature made Fri 02 Dec 2011 12:31:27 PM EST using RSA key ID A9506600 gpg: Can't check signature: public key not found %% Something went wrong --- See above for more info %% -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2011 01:11 AM, Nicolas Pitre wrote: Yes. Either you have access to a fancy debugger and then you could trace what happens from the moment devicemaps_init() is entered. Or, using the good old way, just insert a couple of printk(%s:%s line %d\n, __FILE__, __func__, __LINE__); in a couple places (still with the 2 earlier patches applied). Good locations for those traces would be: - Upon entering devicemaps_init() to confirm it makes that far. - Just before and right after the call to mdesc-map_io(), still in devicemaps_init(). - If you don't see the trace after mdesc-map_io(), then the problem is most likely in u8500_map_io(), in which case you should add more traces in there to narrow the problem area down to the problematic call. The kernel hangs at: u8500_map_io - ux500_map_io - ux500_read_asicid(addr=9001dbf4), base=9001d000 - readl(__io_address(9001dbf4)=f901dbf4); OK, forget my debug patches then. They won't help you in that case because the ux500_read_asicid code is cheating. It is expecting mappings from the iotable_init() to be valid right away. The local_flush_tlb_all() + flush_cache_all() calls that follows are a clear indicator of a layering violation here. My debugging patch expressly doesn't make those mappings effective untill they're all set up in order to preserve the debug UART alive. So the readl() is crashing the kernel since there is no actual mapping for it. If my install_temp_mm() code is disabled (make it #if 0 instead of #ifdef CONFIG_DEBUG_LL), execution should go past that point as the needed mapping would be installed and ux500_map_io() would complete its job. In fact, the first thing that u8500_map_io() does is to re-map the debug UART so you should be able to continue tracing the code past that point (or past the call to ux500_map_io() given its included cache/TLB flushes). So try this: - Disable the install_temp_mm() code. - Remove all printk traces you added so far. - Keep the printascii() hack in printk.c active. - Test that kernel and see what you get. - If still nothing then resume adding your printk traces but only from the moment ux500_map_io() returned in u8500_map_io() and beyond. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linux-next not booting on snowball
On Thu, 1 Dec 2011, Daniel Lezcano wrote: On 12/01/2011 03:58 PM, Mark Brown wrote: On Thu, Dec 01, 2011 at 03:51:00PM +0100, Daniel Lezcano wrote: commit 549158d2ab01e8370d2773044fe09738a26f7086 Author: Nicolas Pitre nicolas.pi...@linaro.org Date: Thu Aug 25 00:35:59 2011 -0400 ARM: move iotable mappings within the vmalloc region I recently reported an issue with this patch on s3c64xx which I'm avoiding with the below change, I believe Nicolas folded this in to his code but it's not propagated into -next yet. [...] Thanks for the patch Mark. I applied it and tried to boot but the kernel is still stuck on the same place :( Please have a look at this email: http://article.gmane.org/gmane.linux.ports.arm.kernel/141386 There are two patches in there which should help you get some debugging info out. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Freeze date for the Linaro 11.11 kernel release
We are considering freezing the 11.11 kernel this next Monday (Nov 14) in order to release it on Wednesday (Nov 16), so it is out there before the US Thanksgiving holiday. If anyone would like to see their patches included in the Linaro kernel for this month, please consider submitting them ASAP. As discussed in Orlando, we are also considering a shift towards using the latest tagged release from Torvalds' mainline tree. This process is not fully in place yet, so the regular Linaro release based on the latest stable upstream release will still occur for this month. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Some more comments on CI loop interface
On Tue, 8 Nov 2011, Deepak Saxena wrote: Hi Michael, I went to take a look at the kernel ci-loop page to see the build status of upstream builds ... FYI, the venerable ARM kautobuild run by Vincent Sanders was shut down a while ago. http://article.gmane.org/gmane.linux.ports.arm.kernel/139303 This means there is now a real hole to fill. Given that Linaro's ci infrastructure has more resources, it hopefully will be more useful too. One thing that I didn't like much about kautobuild is that it only coalesced all build results into a single report instead of having a per config failure report sent to the appropriate maintainer. Should we try to advertise Linaro's plans more widely? Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Some more comments on CI loop interface
On Tue, 8 Nov 2011, Deepak Saxena wrote: On 8 November 2011 14:10, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Tue, 8 Nov 2011, Deepak Saxena wrote: Hi Michael, I went to take a look at the kernel ci-loop page to see the build status of upstream builds ... FYI, the venerable ARM kautobuild run by Vincent Sanders was shut down a while ago. http://article.gmane.org/gmane.linux.ports.arm.kernel/139303 This means there is now a real hole to fill. Given that Linaro's ci infrastructure has more resources, it hopefully will be more useful too. One thing that I didn't like much about kautobuild is that it only coalesced all build results into a single report instead of having a per config failure report sent to the appropriate maintainer. Should we try to advertise Linaro's plans more widely? What I'd like to do is get this being used regularly by Arnd and also the TI maintainers first (as they've expressed some interest in it). Once that's up and running, we can reach out to other sub-architecture maintainers and figure out which trees/configs we want to build. I'd rather get the kinks sorted out with a small group than opening up to lots of people at once. I was thinking more about letting people know what we are up to, not necessarily open the system to anyone yet. Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: imx cpuidle pull request
On Wed, 19 Oct 2011, Rob Lee wrote: (Re-send from my Linaro email address this time) Requesting to add the commits in the attached patch to the October Linaro release. These commits add a common imx cpuidle driver, some common cpuidle mach-mx5 code, and the init call for i.MX51 SoCs. git://git.linaro.org/people/rob_lee/imx_cpuidle.git imx_mx5_mx51 A patch series containing this functionality was also submitted to lkml: http://patchwork.ozlabs.org/patch/115012/ Besides some minor requested changes, this submission was not accepted as there is some common functionality being duplicated by many of the ARM SoC cpuidle implementations and Russell King wants there to be common ARM cpuidle code to handle this. The commits contained in this pull request address the other minor issues discussed in the community submission. I am working on a common ARM implementation will occur but it will take longer. In the mean time, i.MX platform coul use this imx cpuidle implementation in Linaro kernels. OK, merged. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: SCHED_MC dropped from ARM configs?
On Mon, 17 Oct 2011, Amit Kucheria wrote: On Sat, Oct 15, 2011 at 3:43 AM, John Stultz john.stu...@linaro.org wrote: Hey Amit, In updating our tree to 3.1, I noticed the SCHED_MC config option dropped out of the savedefconfig and it doesn't seem to be found in the arm Kconfig. Is that expected? Or are there out of tree patches that provide the SCHED_MC option for 3.1? Hi John, sched_mc for ARM is in Russell's tree for the 3.2 merge. In the meanwhile, Nico is carrying it in his tree for Linaro enablement. Aren't you based on top of Nico's tree? I don't think I have it if it is queued for 3.2. Do you have a reference to the needed patch? Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro and common- tree
On Wed, 5 Oct 2011, Andy Green wrote: Actually, it would be a big advantage for many folks to not be doing their Android kernel development on lagging releases, but by tracking Linus HEAD. They would have access to latest stuff already and they don't have to think about backport or later forwardport stuff to a new release, it's constantly tracking HEAD and being adapted. Amen! Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: ioctl ABI considerations for 64b ARM?
On Mon, 19 Sep 2011, Rob Clark wrote: On Mon, Sep 19, 2011 at 10:39 AM, Will Deacon will.dea...@arm.com wrote: Arnd, On Mon, Sep 19, 2011 at 08:15:45AM +0100, Arnd Bergmann wrote: Assuming that we can prevent any funny stuff from going into such an ABI, we only need to worry about the warts of the current ABI for ARM specific considerations. The one thing that I've noticed before is that structs on ARM (at least on one of the ABIs, forgot which) are padded to 32 bits, even if all members inside are smaller. This is only the case for the old ABI. EABI lays out structures so that they are aligned to their most aligned member and padded to be the smallest possible multiple of that alignment which can contain all of their aligned members. Hmm, so then since you can build the kernel w/ OABI compatibility, it seems like structs should always have padding fields to force them to be a multiple of 32bits... Depends what you want to achieve. The OABI compat is there only to allow _most_ old binaries to execute on a modern system. When I wrote that code, I left out ioctl ABI compatibility issues because there are simply too many of them, and in practice the most often used ones just work already. A notable exception is ALSA. So at this point I think there is no point caring too much about the OABI. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Request] Can Linaro-dev not send duplicate mail to recipients?
On Wed, 31 Aug 2011, John Stultz wrote: So being on vacation for a few days and checking my mail and have found an explosion of emails. Unfortunately most of them are duplicates. It seems the linaro-dev list isn't configed to avoid mailing folks who are already recipients of the email. So if you're on linaro-dev and you're also To/CC'ed in the email, you get it twice (three times if your other work email was CC'ed as well, but that cannot be helped). Sure it can. Just use formail with -D. It will discard duplicates based on a cache of message-id's. For example, I'm using the following procmail script: # remove duplicates :0 Wh: .msgid.lock | formail -D 65536 .msgid.cache Thoughts? (but don't CC me! :) Nah. Removing you from CC (or the to: field) is too much hassle. Furthermore this is something I want people replying to me to *NOT* do. Emails not directly addressed to me get much lower priority in my mbox. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 14/24] video: omap: include mach/irqs.h directly
On Tue, 23 Aug 2011, Venkatraman S wrote: From: Venkatraman S ven...@linaro.org Do not depend on the generic irq header file to include the platform specific header file. Signed-off-by: Venkatraman S ven...@linaro.org This is wrong. Obviously we don't want the generic asm/irq.h to include mach/irqs.h anymore, however we also want to get rid of any references to mach/*.h _outside_ of the machine specific directory too. drivers/video/omap/lcdc.c |1 + drivers/video/omap/sossi.c |1 + In this case the needed definitions are presumably only useful to those drivers, in which case they probably should be moved into those drivers directly, or better yet passed into struct resource instances. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 15/24] gpio: include mach/irqs.h directly
On Tue, 23 Aug 2011, Venkatraman S wrote: From: Venkatraman S ven...@linaro.org Signed-off-by: Venkatraman S ven...@linaro.org --- drivers/gpio/gpio-exynos4.c |2 +- drivers/gpio/gpio-nomadik.c |2 +- drivers/gpio/gpio-s5pv210.c |1 + drivers/gpio/pl061.c|1 + Same issue as for patch #14/24. One of the big issue with the GPIO code is its reliance on mach/gpio.h which has to be solved already, since in a multi SOC kernel we just don't know which of the many mach/irqs.h we want to include. I think that one of the solution for this would involve making mach/*.h into mach/$soc_name/*.h up front... meaning that we recurse again another level down with all its implications. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 16/24] mfd: twl4030-irq: include mach/irqs.h directly
On Tue, 23 Aug 2011, Venkatraman S wrote: From: Venkatraman S ven...@linaro.org Signed-off-by: Venkatraman S ven...@linaro.org Same issue here, however it is not obvious what mach/irqs.h provides that the code relies on. In such cases it is a good idea to state it in the commit log so if the solution is not satisfactory then it is easier for reviewers to suggest alternatives. --- drivers/mfd/twl4030-irq.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c index 8a7ee31..ac3a27d 100644 --- a/drivers/mfd/twl4030-irq.c +++ b/drivers/mfd/twl4030-irq.c @@ -34,7 +34,7 @@ #include linux/slab.h #include linux/i2c/twl.h - +#include mach/irqs.h #include twl-core.h /* -- 1.7.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 19/24] hack: Define constant IRQ_BITMAP_BITS independent of NR_IRQS
On Tue, 23 Aug 2011, Venkatraman S wrote: From: Venkatraman S ven...@linaro.org Currently a hack. Need to define a polite way of defining IRQ_BITMAP_BITS Signed-off-by: Venkatraman S ven...@linaro.org Well... given how IRQ_BITMAP_BITS is used, it looks like simply having a sufficiently high number is all that is needed. The current value appears to be totally arbitrary (and having 8196 instead of 8192 there is rather odd). So I think this shouldn't need to be defined in terms of NR_IRQS at all in fact. --- kernel/irq/internals.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h index 6546431..60db644 100644 --- a/kernel/irq/internals.h +++ b/kernel/irq/internals.h @@ -8,7 +8,7 @@ #include linux/irqdesc.h #ifdef CONFIG_SPARSE_IRQ -# define IRQ_BITMAP_BITS (NR_IRQS + 8196) +# define IRQ_BITMAP_BITS (512 + 8196) #else # define IRQ_BITMAP_BITS NR_IRQS #endif -- 1.7.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 23/24] sound: imx-pcm-fiq: replace fiq enable/disable interface with irq apis
On Tue, 23 Aug 2011, Venkatraman S wrote: From: Venkatraman S ven...@linaro.org The underlying implementation in enable_fiq/disable_fiq uses the irqs anyway, so use them directly. Signed-off-by: Venkatraman S ven...@linaro.org Same comment as for patch #22/24. --- sound/soc/imx/imx-pcm-fiq.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/imx/imx-pcm-fiq.c b/sound/soc/imx/imx-pcm-fiq.c index 413b78d..7f12b4b 100644 --- a/sound/soc/imx/imx-pcm-fiq.c +++ b/sound/soc/imx/imx-pcm-fiq.c @@ -138,7 +138,7 @@ static int snd_imx_pcm_trigger(struct snd_pcm_substream *substream, int cmd) hrtimer_start(iprtd-hrt, ns_to_ktime(iprtd-poll_time_ns), HRTIMER_MODE_REL); if (++fiq_enable == 1) - enable_fiq(imx_pcm_fiq); + enable_irq(imx_pcm_fiq + FIQ_START); break; @@ -148,7 +148,7 @@ static int snd_imx_pcm_trigger(struct snd_pcm_substream *substream, int cmd) atomic_set(iprtd-running, 0); if (--fiq_enable == 0) - disable_fiq(imx_pcm_fiq); + disable_irq(imx_pcm_fiq + FIQ_START); break; default: -- 1.7.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC PATCH 18/24] arm: irq: do not assume NR_IRQS to be defined
On Tue, 23 Aug 2011, Venkatraman S wrote:
From: Venkatraman S ven...@linaro.org
If SPARSE_IRQ is defined, NR_IRQS will not necessarily be
relevant. Use the number populated in machine descriptor.
Note: HARDIRQ_BITS is defined as a constant independent of NR_IRQS.
Needs review if this assumption makes sense.
Signed-off-by: Venkatraman S ven...@linaro.org
This could be posted to LAK for further comments too.
---
arch/arm/common/gic.c |8
arch/arm/include/asm/hardirq.h |6 ++
arch/arm/kernel/irq.c |8 +++-
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 4ddd0a6..6fb5fa4 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -28,7 +28,7 @@
#include linux/smp.h
#include linux/cpumask.h
#include linux/io.h
-
+#include linux/irqnr.h
#include asm/irq.h
#include asm/mach/irq.h
#include asm/hardware/gic.h
@@ -231,7 +231,7 @@ static void gic_handle_cascade_irq(unsigned int irq,
struct irq_desc *desc)
goto out;
cascade_irq = gic_irq + chip_data-irq_offset;
- if (unlikely(gic_irq 32 || gic_irq 1020 || cascade_irq = NR_IRQS))
+ if (unlikely(gic_irq 32 || gic_irq 1020 || cascade_irq = nr_irqs))
do_bad_IRQ(cascade_irq, desc);
else
generic_handle_irq(cascade_irq);
@@ -312,8 +312,8 @@ static void __init gic_dist_init(struct gic_chip_data
*gic,
* Limit number of interrupts registered to the platform maximum
*/
irq_limit = gic-irq_offset + gic_irqs;
- if (WARN_ON(irq_limit NR_IRQS))
- irq_limit = NR_IRQS;
+ if (WARN_ON(irq_limit nr_irqs))
+ irq_limit = nr_irqs;
/*
* Setup the Linux IRQ subsystem.
diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
index 89ad180..4bea5c0 100644
--- a/arch/arm/include/asm/hardirq.h
+++ b/arch/arm/include/asm/hardirq.h
@@ -30,6 +30,10 @@ u64 smp_irq_stat_cpu(unsigned int cpu);
#define arch_irq_stat_cpusmp_irq_stat_cpu
+#ifndef NR_IRQS
+/* FIXME: Need a better way to derive HARDIRQ_BITS */
+#define HARDIRQ_BITS 10
+#else
#if NR_IRQS 512
#define HARDIRQ_BITS 10
#elif NR_IRQS 256
@@ -47,6 +51,8 @@ u64 smp_irq_stat_cpu(unsigned int cpu);
# error HARDIRQ_BITS is too low!
#endif
+#endif
+
#define __ARCH_IRQ_EXIT_IRQS_DISABLED1
#endif /* __ASM_HARDIRQ_H */
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 83bbad0..12ffa9d 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -124,7 +124,13 @@ void __init init_IRQ(void)
#ifdef CONFIG_SPARSE_IRQ
int __init arch_probe_nr_irqs(void)
{
- nr_irqs = machine_desc-nr_irqs ? machine_desc-nr_irqs : NR_IRQS;
+ if (machine_desc-nr_irqs)
+ nr_irqs = machine_desc-nr_irqs;
+ #ifdef NR_IRQS
+ else
+ nr_irqs = NR_IRQS;
+ #endif
+ WARN_ON(nr_irqs);
return nr_irqs;
}
#endif
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Patch for fixing soft-reboot problem in ORIGEN
On Mon, 22 Aug 2011, Tushar Behera wrote: Hi Nicolas, Can you please cherry-pick following patch onto linaro kernel? http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=patch;h=d2edddf2b25863ec0893635662b0832f9965b543 Done. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: trouble building linux-linaro-3.0-2011.08-0
On Mon, 22 Aug 2011, Christian Robottom Reis wrote: On Sun, Aug 21, 2011 at 09:54:56PM -0400, Nicolas Pitre wrote: AS arch/arm/boot/compressed/head.o arch/arm/boot/compressed/head.S: Assembler messages: arch/arm/boot/compressed/head.S:127: Error: selected processor does not support requested special purpose register -- `mrs r2,cpsr' arch/arm/boot/compressed/head.S:134: Error: selected processor does not support requested special purpose register -- `mrs r2,cpsr' arch/arm/boot/compressed/head.S:136: Error: selected processor does not support requested special purpose register -- `msr cpsr_c,r2' make[2]: *** [arch/arm/boot/compressed/head.o] Error 1 make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2 make: *** [uImage] Error 2 [...] Looks to me like your assembler is broken, or gcc is not properly telling it about the actual architecture in use. Right. And the original unwind-related missing symbols is a problem somewhere in configuration land? Yep. That one looks trivial. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: trouble building linux-linaro-3.0-2011.08-0
On Sun, 21 Aug 2011, John Rigby wrote: I'm having trouble building the Thumb2 kernel on, I actually believe this same code worked some time ago before a toolchain update. There are actually two problems described below. I get past the first with a config change but don't know how to fix the second one. [...] AS arch/arm/boot/compressed/head.o arch/arm/boot/compressed/head.S: Assembler messages: arch/arm/boot/compressed/head.S:127: Error: selected processor does not support requested special purpose register -- `mrs r2,cpsr' arch/arm/boot/compressed/head.S:134: Error: selected processor does not support requested special purpose register -- `mrs r2,cpsr' arch/arm/boot/compressed/head.S:136: Error: selected processor does not support requested special purpose register -- `msr cpsr_c,r2' make[2]: *** [arch/arm/boot/compressed/head.o] Error 1 make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2 make: *** [uImage] Error 2 Here is my gcc version: $ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.1-5ubuntu2~ppa1) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. And as version: GNU assembler (GNU Binutils for Ubuntu) 2.21.52.20110707 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `arm-linux-gnueabi'. Looks to me like your assembler is broken, or gcc is not properly telling it about the actual architecture in use. To confirm, please try this: echo -e .arch armv7-a\n.thumb\nmrs r2, cpsr | \ arm-linux-gnueabi-as - -o /dev/null If that works then your assembler is fine. In that case the following should fail: echo -e .thumb\nmrs r2, cpsr | \ arm-linux-gnueabi-gcc -march=armv7-a -x assembler -o /dev/null -c - If for some reasons this works too, then the kernel build might be wrong. In that case, see the output of: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- V=1 \ arch/arm/boot/compressed/head.o I have: arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.5.2-8ubuntu3) 4.5.2 GNU assembler (GNU Binutils for Ubuntu) 2.21.0.20110327 And that works for me just fine. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linux kernel review tags (Re: [PATCH 0/3] Fix Thumb-2 undef handling for mixed-arch kernels)
On Thu, 18 Aug 2011, Dave Martin wrote: On Wed, Aug 17, 2011 at 6:24 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Wed, 17 Aug 2011, Dave Martin wrote: Acked-by = This patch is definitely right, or I fully agree with the patch and trust the author's judgement (I will share responsibility for the correctness and appropriateness of this patch). This implies Reviewed-by. Normally an ack shouldn't get added unless the acker is confident that the patch is adequately tested (where the level of testing deemed adequate depends on the complexity of the patch) Again, this may rely on judgement of the comptence of the author and the other reviewers. Reviewed-by = This patch looks correct and appropriate and I judge it ok to merge, but I assume the author knows what they're doing, and I don't necessarily take responsibility for the change. I think some aspects of the above two are mixed up. Normally, ACK == acknowledgement i.e. I conceptually agree with the patch, but that doesn't necessarily mean that it was reviewed thoroughly. In other words, this quite matches your definition, but does not imply a Reviewed-by, and that assumes the author knows what they're doing. Reviewed-by means that you did review the patch content in details, whether or not the author knows what they're doing. A Reviewed-by obviously implies an Acked-by. Interesting... I thought there was a chance I was getting this wrong. My impression was that an Ack carries more weight with upstream maintainers when it comes to merging; but does it instead depend on _who_ the tag comes from? (i.e., if an experienced and well-known person takes a cursory glance at the patch and the review that's gone on and Acks it, this may carry more weight than a Reviewed-by by a less well-known person?) Absolutely. And the more experienced a person might be, the more patches that person might be expected to look at. So it is normal for such person to look at the purpose and general design of a patch only, while trusting the author to get the details right. Hence the acked-by tag. This is also where the coding style get important as it is possible for a reviewer to look at the patch and get a feel for that general design more easily. A Reviewed-by is meant to be more thorough. See the definition from Ted Tso here: http://kerneltrap.org/Linux/Introducing_Reviewed-by_Tags But it is true that the value of any such tag is pondered by the reputation of the person providing it, and that reputation is usually based on the perceived quality of the code that person provided in the past. Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linux kernel review tags (Re: [PATCH 0/3] Fix Thumb-2 undef handling for mixed-arch kernels)
On Wed, 17 Aug 2011, Dave Martin wrote: Acked-by = This patch is definitely right, or I fully agree with the patch and trust the author's judgement (I will share responsibility for the correctness and appropriateness of this patch). This implies Reviewed-by. Normally an ack shouldn't get added unless the acker is confident that the patch is adequately tested (where the level of testing deemed adequate depends on the complexity of the patch) Again, this may rely on judgement of the comptence of the author and the other reviewers. Reviewed-by = This patch looks correct and appropriate and I judge it ok to merge, but I assume the author knows what they're doing, and I don't necessarily take responsibility for the change. I think some aspects of the above two are mixed up. Normally, ACK == acknowledgement i.e. I conceptually agree with the patch, but that doesn't necessarily mean that it was reviewed thoroughly. In other words, this quite matches your definition, but does not imply a Reviewed-by, and that assumes the author knows what they're doing. Reviewed-by means that you did review the patch content in details, whether or not the author knows what they're doing. A Reviewed-by obviously implies an Acked-by. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Single zImage at Linaro Connect
On Fri, 29 Jul 2011, Dave Martin wrote: On Thu, Jul 28, 2011 at 02:44:17PM -0400, Nicolas Pitre wrote: On Thu, 28 Jul 2011, Dave Martin wrote: I have a slightly biased interest in this, since ARM seems to like funky memory maps for many of its newer boards, and it would be unfortunate for these to get left out of the whole single effort. Of course we could include those platforms in non-sparsemem kernels, but since that will often mean sacrificing half the RAM, this is far from ideal. Maybe that half could simply be pushed to home. Eh? Euh... I meant himem. No idea how my fingers turned that into home. We could even embed the printch() function body into the DT if we wanted to make the kernel's job even simpler. Realistic implementations of this function are tiny, so this shouldn't be too cumbersome. That really seems an abuse of the DT though, since this goes beyond just describing the hardware. Well... I'm not entirely against the idea. This could be seen as the most efficient way to describe how to output a character over some serial device for the given hardware. The danger is that some vendors might be tempted to abuse that idea by stuffing BIOS-like services in there that the kernel would have to cope with. See my reply to Arnd... What might be done is to describe the data FIFO register location, and the FIFO full bit mask, and the FIFO empty bit mask. That's all we need really. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Single zImage at Linaro Connect
On Fri, 29 Jul 2011, Rob Herring wrote: On 07/29/2011 07:40 AM, Nicolas Pitre wrote: On Fri, 29 Jul 2011, Dave Martin wrote: On Thu, Jul 28, 2011 at 02:44:17PM -0400, Nicolas Pitre wrote: On Thu, 28 Jul 2011, Dave Martin wrote: I have a slightly biased interest in this, since ARM seems to like funky memory maps for many of its newer boards, and it would be unfortunate for these to get left out of the whole single effort. Of course we could include those platforms in non-sparsemem kernels, but since that will often mean sacrificing half the RAM, this is far from ideal. Maybe that half could simply be pushed to home. Eh? Euh... I meant himem. No idea how my fingers turned that into home. We could even embed the printch() function body into the DT if we wanted to make the kernel's job even simpler. Realistic implementations of this function are tiny, so this shouldn't be too cumbersome. That really seems an abuse of the DT though, since this goes beyond just describing the hardware. Well... I'm not entirely against the idea. This could be seen as the most efficient way to describe how to output a character over some serial device for the given hardware. The danger is that some vendors might be tempted to abuse that idea by stuffing BIOS-like services in there that the kernel would have to cope with. See my reply to Arnd... What might be done is to describe the data FIFO register location, and the FIFO full bit mask, and the FIFO empty bit mask. That's all we need really. Except for RPC which outputs to video memory. We don't care about that one for single kernel, but that may limit a new common solution. There will always be exceptions. Since RPC is so different and unique, it better be left alone and we should not try to find a solution that covers it as well. I doubt it will ever use DT either. BTW, I did implement a conversion to use debug macro code for uncompress, but it doesn't work for RPC, OMAP and Davinci. So while it shrinks the the code by over 2K lines, we probably need a new approach like you suggest. The patches are here if you want to take a look: git://git.jdl.com/software/linux-3.0.git http://git.jdl.com/gitweb/?p=linux-3.0.git;a=shortlog;h=refs/heads/uncompress Will try to have a look. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: OOM with linux-linaro-3.0 on a beagleboard
On Thu, 28 Jul 2011, James Westby wrote: On Thu, 28 Jul 2011 18:18:09 +0200, Daniel Lezcano daniel.lezc...@linaro.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/28/2011 12:58 PM, James Westby wrote: Hi, Have you tried the omap3 hardware pack with a Linaro image? That contains the 3.0 kernel I think, so may give a comparison point. Ok, I tested with: developer-n-tar-20110628-1.tar.gz hwpack_linaro-omap3_20110726-1_armel_supported.tar.gz and I don't have any problem. Then I picked /proc/config.gz, compiled the kernel (but disable thumb2) and booted without any problem too. I changed some kernel options (added cpufreq and cpuidle), compiled and booted without problem. And lastly, I rerun make omap2plus_defconfig, compiled and booted the kernel. And that triggers the OOM killer. So I guess the problem is coming from the default omap2plus config. I guess the diff from omap2plus_defconfig to one of the configs that worked is pretty huge? Doing a 'make savedefconfig' in both cases and comparing the produced ./defconfig should make the comparison much easier. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Single zImage at Linaro Connect
On Thu, 28 Jul 2011, Dave Martin wrote: On Wed, Jul 27, 2011 at 10:58:36PM -0400, Nicolas Pitre wrote: To everyone, and especially to those who are expected to work on this topic next week, please find below a list of tasks that needs to be investigated and/or accomplished. I'll coordinate the work and collect patches for the team. If you have comments on this, or if you know about some omissions, please feel free to provide them as a reply to this message. I'd like to know if people are particularly interested in one (or more :-)) items they would like to work on. If so please say so as well. [...] Currently, device tree is not fully supported upstream for vexpress. Lorenzo Pieralisi wrote some patches, but there were a few outstanding issues and these weren't merged yet. It could make sense for me to take a look at this, since vexpress is also the base for our initial Cortex-A15 refernece platform. With the right people around next week, we have a chance to get any issues thrashed out more quickly. Is this a good idea for next week, or should we be focusing more on core issues? DT enablement will also be an important topic next week. I'm sure you'll be appreciated whatever you work on. Some more thoughts: 1.1.5) Other weird things Some machines have non linear memory maps or bus address translations, sparsemem, etc. Examples of that are: arch/arm/mach-realview/include/mach/memory.h arch/arm/mach-integrator/include/mach/memory.h I think solving this is out of scope for this round. Deleting arch/arm/mach-*/include/mach/memory.h can't be done universally. So a new Kconfig symbol (NO_MACH_MEMORY_H) is introduced to indicate which machine class has its legacy mach/memory.h file removed. The single zImage for multiple targets will be restricted, amongst other things, to those machines or SOCs with that symbol selected. Partial result here: http://git.linaro.org/gitweb?p=people/nico/linux.git;a=shortlog;h=refs/heads/redux One possibility here is to enable any non-sparsemem platform to be built with sparsemem enabled by just defining a single memory block in this case to encompass the platform's RAM. I believe that platforms which have small I/O holes in their memory maps can continue to use memblock_reserve techniques as before -- there's no need to represent the holes via sparsemem (which would be expensive) Having talked to Will Deacon about this, it sounds like the feasibiltiy and performance impact may depend on how often things like pfn_valid get called when sparsemem is enabled. Is this worth looking into? Certainly, especially given your bias. ;-) The sparsemem might get pretty inefficient if the build time constants such as SECTION_SIZE_BITS can't be relied upon though. I have a slightly biased interest in this, since ARM seems to like funky memory maps for many of its newer boards, and it would be unfortunate for these to get left out of the whole single effort. Of course we could include those platforms in non-sparsemem kernels, but since that will often mean sacrificing half the RAM, this is far from ideal. Maybe that half could simply be pushed to home. LPAE (Seems to fit neatly under weird things for now ;) Do we care strongly about supporting LPAE and non-LPAE platforms in a single kernel? No. I think that would be rather insane. The page table definitions have deep repercussions all over the place, often in performance critical paths down in core kernel code. Trying to introduce variable elements which are otherwise build time optimized constants is probably not going to find many followers. 1.10) mach/debug-macro.S This is used when CONFIG_DEBUG_LL is set. Supporting that option with a single kernel image might prove very difficult with a rapidly diminishing return on the investment. This code is in need of some refactoring already: http://article.gmane.org/gmane.linux.ports.arm.kernel/118525 To still benefit from the most likely needed debugging aid, we might consider the ability to still allow the selection of one amongst the existing implementation when building a kernel with many SOC support. Obviously that would only work on the one hardware platform for which the selected printch implementation was designed, but that should be good enough for debugging purposes. DT is precisely for solving this kind of problem... We would be dependent on examining the device tree very earlier, however. It looks like the code in drivers/of/ won't work in the zImage loader environment without a lot of modifications; so we might need to create a separate, very minimal lightweight parser for this. Then we can build all the relevant printch() implementations into the kernel and also into the zImage loader, and pick the right one based on the DT? The DT could define a special alias for the UART available for low
Single zImage at Linaro Connect
To everyone, and especially to those who are expected to work on this topic next week, please find below a list of tasks that needs to be investigated and/or accomplished. I'll coordinate the work and collect patches for the team. If you have comments on this, or if you know about some omissions, please feel free to provide them as a reply to this message. I'd like to know if people are particularly interested in one (or more :-)) items they would like to work on. If so please say so as well. Without further ado, here it is: 0) The so called single zImage project We wish to provide the ability to build as many ARM platforms as possible into a single kernel binary image. This will greatly simplify the archive packaging and maintenance effort by having only one kernel that could be built and booted on multiple ARM targets. A side effect of this is also to enforce better source code architecture even if the resulting binaries are not always supporting multiple targets. This work started a while ago. Some initial description can be found here: https://wiki.ubuntu.com/Specs/ARMSingleKernel Part of it has been implemented already, namely the runtime determined PHYS_OFFSET, the AUTO_ZRELADDR and some other items referenced below. But there is still a large amount of work remaining. 1) Removal of any dependencies on mach/*.h from generic header files To see the current culprits: $ git grep #include mach/.*.h arch/arm/include/ arch/arm/include/asm/clkdev.h:#include mach/clkdev.h arch/arm/include/asm/dma.h:#include mach/isa-dma.h arch/arm/include/asm/floppy.h:#include mach/floppy.h arch/arm/include/asm/gpio.h:#include mach/gpio.h arch/arm/include/asm/hardware/dec21285.h:#include mach/hardware.h arch/arm/include/asm/hardware/iop3xx-adma.h:#include mach/hardware.h arch/arm/include/asm/hardware/iop3xx-gpio.h:#include mach/hardware.h arch/arm/include/asm/hardware/sa.h:#include mach/bitfield.h arch/arm/include/asm/io.h:#include mach/io.h arch/arm/include/asm/irq.h:#include mach/irqs.h arch/arm/include/asm/mc146818rtc.h:#include mach/irqs.h arch/arm/include/asm/memory.h:#include mach/memory.h arch/arm/include/asm/mtd-xip.h:#include mach/mtd-xip.h arch/arm/include/asm/pci.h:#include mach/hardware.h /* for PCIBIOS_MIN_* */ arch/arm/include/asm/pgtable.h:#include mach/vmalloc.h arch/arm/include/asm/system.h:#include mach/barriers.h arch/arm/include/asm/timex.h:#include mach/timex.h arch/arm/include/asm/vga.h:#include mach/hardware.h 1.1) mach/memory.h This may contain the following defines: 1.1.1) ARM_DMA_ZONE_SIZE This can be eliminated by moving that value into struct machine_desc. The work is done already, but presented as an example for other tasks: http://git.linaro.org/gitweb?p=people/nico/linux.git;a=shortlog;h=refs/heads/dma And as of now this is merged in mainline already for v3.1-rc1. 1.1.2) PLAT_PHYS_OFFSET Most occurrences can be eliminated. With CONFIG_ARM_PATCH_PHYS_VIRT, it is possible to determine PHYS_OFFSET at run time. Remains to remove the direct uses, mostly by mdesc-boot_params initializers. Changing boot_params into atag_offset has two effects: that makes it clearer that it is only about ATAGs and not DT, and a relative offset plays more nicely with a runtime determined PHYS_OFFSET. This work is done but not yet accepted: http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=123480 1.1.3) FLUSH_BASE, FLUSH_BASE_PHYS, FLUSH_BASE_MINICACHE, UNCACHEABLE_ADDR Those are StrongARM related constants, and different for each variants. Fixing this involves making the virtual addresses constant for all variants, and hiding the differences in the physical addresses during the actual mapping. The solution is here: http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=123477/force_load=t/focus=124849 1.1.4) CONSISTENT_DMA_SIZE Maybe the CMA work will make this obsolete and the consistent DMA area could be dynamically adjusted. In the mean time, the easiest solution is probably to store this in the machine_desc structure just like with ARM_DMA_ZONE_SIZE. This has not been addressed yet. 1.1.5) Other weird things Some machines have non linear memory maps or bus address translations, sparsemem, etc. Examples of that are: arch/arm/mach-realview/include/mach/memory.h arch/arm/mach-integrator/include/mach/memory.h I think solving this is out of scope for this round. Deleting arch/arm/mach-*/include/mach/memory.h can't be done universally. So a new Kconfig symbol (NO_MACH_MEMORY_H) is introduced to indicate which machine class has its legacy mach/memory.h file removed. The single zImage for multiple targets will be restricted, amongst other things, to those machines or SOCs with that symbol selected. Partial result here: http://git.linaro.org/gitweb?p=people/nico/linux.git;a=shortlog;h=refs/heads/redux 1.2) mach/io.h This contains things like IO_SPACE_LIMIT, __io(), __mem_pci(), and sometimes
Re: The Linaro-3.0 kernel branch is now open
On Tue, 19 Jul 2011, Grant Likely wrote: On Tue, Jul 19, 2011 at 03:22:58PM -0300, Ricardo Salveti wrote: On Tue, Jul 19, 2011 at 3:04 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Tue, 19 Jul 2011, John Rigby wrote: My first request would be for board level device tree support. I think Grant should have that ready soon. Grant, do you know if this will be included for 11.07 release/tag? Would be good to have it, as we're already deploying dt support at u-boot and at all hwpacks (and it's expected to be there by linaro-media-create tool). I plan to send Nico exactly the same thing that I'm going to send to Linus T. in a day or so, so yes. The clock is ticking ... ... ... I'm supposed to freeze the 11.07 kernel today. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The Linaro-3.0 kernel branch is now open
On Thu, 21 Jul 2011, Grant Likely wrote: On Thu, Jul 21, 2011 at 3:36 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Thu, 21 Jul 2011, Grant Likely wrote: You can pull devicetree/next right now. I've still got a few things to do before I get you to pull the dt board support patches. Give me a few more hours. No problem. I can wait until I go to bed. Okay, I'm spinning up the tree now. I don't have an ack yet from tglx on the irq_domain, so they won't be the *exact* commits that go into linus' tree, but they will be close. I'm assuming that you've already got the zImage dtb append patches, and that you've taken care of getting them into linux-next. Actually, I'm not pushing it upstream yet as I'm not satisfied with some parts of the ATAG to DT support. But I'll merge what I have now in the linaro-3.0 tree. Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The Linaro-3.0 kernel branch is now open
On Thu, 21 Jul 2011, Deepak Saxena wrote: On 21 July 2011 16:47, john stultz johns...@us.ibm.com wrote: On Thu, 2011-07-21 at 16:34 -0700, john stultz wrote: On Thu, 2011-07-21 at 15:18 -0700, Deepak Saxena wrote: On 21 July 2011 15:08, john stultz johns...@us.ibm.com wrote: On Mon, 2011-07-18 at 22:57 -0400, Nicolas Pitre wrote: Please let me know if you want to see something merged into the linaro-3.0 tree before Thursday. So I'm working on merging this into the Android tree and something in your tree is causing Pandaboard to hang very early at boot: Starting kernel ... Uncompressing Linux... done, booting the kernel. ... And that's all. I rolled back to just your tree and got the same thing (the vanilla Android 3.0 branch still works fine). [snip] Bisecting narrowed it down to: af496a67c101b2161a12c1bc70626f6a479501bb Arnd: Maybe something went badly with the merge collision resolution there? And frustratingly, since its a merge commit, I can't just revert that one commit. Is anyone else testing Nico's tree (or even the ARM-SOC tree) with PandaBoard? According to the following from today, the merge should not have happened in the first place. Nico, do you need to rebase/merge with latest arm-soc/for-next tree? http://lists.infradead.org/pipermail/linux-arm-kernel/2011-July/058255.html OK, my fault, I missed that. Obviously I should not have taken that merge given its uncertainty. So I reverted it. [...] And... the latest arm-soc/for-next branch is giving me yet more conflicts in the imx and omap code. I'm not in a position to resolve those this close to the freeze deadline. Too bad: I'm not merging it at all. Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
The Linaro-3.0 kernel branch is now open
Yes, it is the big 3.0 coming to a Linaro server near you ! The Linux v3.0 based Linaro kernel branch is now available from: http://git.linaro.org/gitweb?p=kernel/linux-linaro-3.0.git;a=summary http://git.linaro.org/git/kernel/linux-linaro-3.0.git Since the official final v3.0 from Linus Torvalds is going to happen in a matter of hours now, and considering that the freeze for the 11.07 kernel release is supposed to take effect this Thursday, this is probably the best time to fork the Linaro-3.0 branch and start merging patches onto it. Currently this contains the following from RMK's devel-stable branch: * The comprehensive ARM kprobes work from Jon (Tixy) Medhurst * The new processor struct macros from Dave Martin * A small part of the single zImage work from myself * The ARM cpu topology definition from Vincent Guittot * Basic Cortex A5 support from Will Deacon Pawel Moll * DMA infrastructure cleanups from Russell King * A kernel helper to perform 64-bit atomic operations from myself Please let me know if you want to see something merged into the linaro-3.0 tree before Thursday. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/1] Add ARM cpu topology definition
On Tue, 12 Jul 2011, Amit Kucheria wrote: From: Vincent Guittot vincent.guit...@linaro.org (Patch accepted by Russell for 3.1: http://www.spinics.net/lists/arm-kernel/msg131273.html) That is good enough for me. I merged it in the linaro-2.6.39 tree for now, and I'll pick it up from mainline when linaro-3.0 opens. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Usefulness of GCC's 64bit __sync_* ops on ARM
On Fri, 8 Jul 2011, Dave Martin wrote: On Fri, Jul 08, 2011 at 12:21:27AM +0100, David Gilbert wrote: Nicolas just added; Richard's argument is that if it was actually a VDSO I'd just have linked against a symbol and if the symbol wasn't there then I would have got a fairly normal linker error - I wouldn't have needed any special code; and to be honest I think that would also solve the problem that accessing that wacky address is also a pain for things like qemu because we're going to have to intercept that read. Note that pre-existing code already calls into the vectors page. Right, qemu must be intercepting it already. The kernel helpers located at a fixed address in the vector page have been around for more than 6 years. This doesn't necessarily mean that adding a VDSO interface is bad, but it does mean the existing interface can't easily be changed or removed. Agreed. There is nothing preventing the addition of a VDSO, but I've yet to see a convincing argument for spending time adding it. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Usefulness of GCC's 64bit __sync_* ops on ARM
On Fri, 8 Jul 2011, Richard Henderson wrote: I find this attitude to be short-sighted. These exact same arguments were made about a.out vs elf, and all the horrible extra overhead that elf has with its plts and dynamic symbol resolution. The fact that people came up with hacks such as prelinking must not be for nothing. I urge you to go ahead and create the VDSO anyway, even if you continue to bypass it with new fixed addresses for new entry points. I have no problem with that at all. Keeping the fixed address ABI will at least provide an alternative to those who are always after the last bit of performance because they don't know better than calling get_tls() a couple thousand times per second within the same thread. The VDSO does more than simply hold the code for those functions, it also describes them with the symbol and symbol versioning tables, and the unwind info. This is of enormous value to debugging and other introspection tools. Absolutely. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v8 00/12] use nonblock mmc requests to minimize latency
On Sun, 3 Jul 2011, Per Forlin wrote: On 2 July 2011 21:37, Arnd Bergmann a...@arndb.de wrote: On Saturday 02 July 2011 14:29:38 Russell King - ARM Linux wrote: One other thing to be considered here is whether this idea should be limited to just MMC or whether it should be extended further, to move the DMA mapping stuff out of the hot path for other block devices too. There are ARM systems with SATA which do 28MB/s - which could be improved by this technique. Excellent point. We had discussed SATA items in the context of Linaro work before, and the conclusion was always that we wouldn't need to do any work for it in the common code. I'll make sure that we bring it up at the meeting next month in Cambridge so we can officially assign someone to do this. Arnd, do you know if any of the Linaro boards have SATA? The latest i.mx53 boards have SATA. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: problem with todays linux-linaro-2.6.39 and THUMB2 kernel
On Thu, 23 Jun 2011, John Rigby wrote: I thought this was new but it has been around for awhile. My default config was not turning on THUMB2 kernel so I only saw it today. Old known issue. I wonder why I didn't stumble on it. Should be fixed now. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: TI LT 3.0 Tracking branches
On Thu, 23 Jun 2011, Andy Green wrote: Hi - I mentioned this already to npitre but for various reasons we are planning to target 3.0 kernel rather than linux-linaro-2.6.39 at the moment. 2.6.39 has some known issues like no onboard audio or HDMI audio, but since 3.0 has a new and better ALSA implementation for Panda I'm not sure it's worth spending time on when the old implementation won't really go into linux-linaro even if we did forward-port it again. $ git diff --shortstat v2.6.39..linaro-2.6.39 sound/ 158 files changed, 20097 insertions(+), 6899 deletions(-) $ git diff --shortstat linaro-2.6.39..v3.0-rc4 sound/ 65 files changed, 4586 insertions(+), 3612 deletions(-) So please lets stop that linaro-2.6.39 is just 2.6.39 rhetoric when numbers show that linaro-2.6.39 is much closer to the strictly speaking still nonexistent 3.0 than 2.6.39. When linux-linaro-3.0 is coming in the next weeks, we will use that as a base instead as before. The base will be just as good as the contributions made by people to it. And besides a few notable exceptions such as yours, I didn't get much from people in terms of patches and/or pull requests. I'm seriously starting to question the usefulness of the Linaro kernel tree in fact. For one year that I've been putting such a tree together, the feedback and response have been less than overwhelming. The idea was to _consolidate_ the work that the various groups within Linaro was producing into a single and coherent whole without screwing up the other groups' work, but so far this hasn't been a great success for various reasons. So I'm asking people for comments about this tree. - Is this useful? - Is it important? - Are _you_ using it? - Is solving the ARM fragmentation problem still a Linaro priority? - Is the Linaro kernel effective for this? Half a year ago when I did ask for comments about the usefulness of the linaro-next tree, I got almost no responses as I suspected, and I therefore dropped that tree to concentrate my efforts on the Linaro stable branches. If even the stable branch doesn't steer more interest than it does now then this effort is just wasted. Either our process is to blame, our priorities are wrong, or some efforts are diverted where they shouldn't. One reason for the Linaro tree was to help LTs moving ahead rather than sticking to ancient kernels. Now it seems that everyone wants to get ahead of the actual latest release from kernel.org which is a radical shift. Does this mean that vendors and co now are getting used to the upstream pace and they're going to move to a rebasing workflow for real, or they're just fooled by the marketing prospects of a meaningless major kernel version bump? If the former that would be wonderful and maybe the Linaro kernel outlived its usefulness. If the later... well... what can I say here? In any case that doesn't make a strong case for the Linaro kernel. We could as well just patch the latest Ubuntu kernel, the latest Android kernel, or whatever existing distro or vendor kernel, in order to showcase the Linaro initiated work and results. In practice that's what I see people doing right now anyway. Pushing that work into mainline is what matters the most in the end, and _that_ should always be Linaro's top priority. I don't feel compelled to fight for the survival of the Linaro kernel either if it is not widely used and significantly useful. I'm more effective fighting with mainline kernel people: it is much more interesting and useful with lasting results. Opinions anyone? Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: OMAP3 Core dpll fix
On Wed, 22 Jun 2011, Vishwanath Sripathy wrote: On Wed, Jun 22, 2011 at 3:50 PM, Amit Kucheria amit.kuche...@linaro.org wrote: On 11 Jun 22, Vishwanath Sripathy wrote: Hi Nicolas, Can you pls pull below patch from 2.6.39 mainline kernel into 11.5 Linaro kernel? This would fix some of the DVFS related issues seen on OMAP3. Patch: commit 5fd2a84ab3c8b87176e25db1d98c5cc34043a669 Author: Avinash H.M avinas...@ti.com OMAP3: set the core dpll clk rate in its set_rate function Vishwa After this fix, can CPU_FREQ be re-enabled on OMAP3? cpufreq as such will work as expected and will scale MPU and L3 frequency based on system load. However if any driver is not requesting for the required l3 frequency, then we might start seeing issues at driver level (like FIFO underflow etc due to l3 running at lower rate). So my suggestion is not to keep ondemand as the default governor and if someone wants to experiment, they can enable it. I merged the fix to linaro-2.6.38 and pushed out. What about linaro-2.6.39 which is the base for the 11.06 release due next week? Does it work properly there? The above commit is already included, but I would like to know how things are working wrt power management in that kernel. Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 02/11] omap_hsmmc: add support for pre_req and post_req
On Tue, 21 Jun 2011, Per Forlin wrote: On 21 June 2011 07:41, Kishore Kadiyala kishorek.kadiy...@gmail.com wrote: snip + +static void omap_hsmmc_pre_req(struct mmc_host *mmc, struct mmc_request *mrq, + bool is_first_req) I don't see the usage of is_first_req below. Is it required? It is not required. It is only an indication that this request is the first in a series of request. The host driver may do various optimisations based on this information. The first request in a series of jobs can't be prepared in parallel to the previous job. The host driver can do the following to minimise latency for the first job. * Preparing the cache while the MMC read/write cmd is being processed. In this case the pre_req could do nothing and the job is instead run in parallel to the read/write cmd being sent. If the is_first_req is false pre_req will run in parallel to an active transfer, in this case it is more efficient to prepare the request in pre_req. * Run PIO mode instead of DMA That is never going to be a good tradeoff. If the CPU is busy doing PIO, it won't have a chance to prepare a subsequent request in parallel to the first transfer. Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Compiling kernel for panda linaro natty 11.05
On Tue, 21 Jun 2011, Dave Martin wrote: On Tue, Jun 21, 2011 at 12:52:12PM +0530, Amit Mahajan wrote: ERROR: __aeabi_uldivmod [sound/soc/codecs/snd-soc-wm8974.ko] undefined! ERROR: __aeabi_uldivmod [sound/soc/codecs/snd-soc-wm8940.ko] undefined! ERROR: __aeabi_uldivmod [sound/soc/codecs/snd-soc-wm8510.ko] undefined! WARNING: modpost: Found 2 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 John, do you know why the packaged kernel builds don't get these errors? I do tend to get this whenever I try to build a full set of kernel from the packaged kernel config. I haven't reproduced it recently though, so I don't know exactly what tool versions are affected. http://article.gmane.org/gmane.linux.linaro.toolchain/1123 Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 02/11] omap_hsmmc: add support for pre_req and post_req
On Tue, 21 Jun 2011, Per Forlin wrote: On 21 June 2011 21:18, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Tue, 21 Jun 2011, Per Forlin wrote: On 21 June 2011 07:41, Kishore Kadiyala kishorek.kadiy...@gmail.com wrote: snip + +static void omap_hsmmc_pre_req(struct mmc_host *mmc, struct mmc_request *mrq, + bool is_first_req) I don't see the usage of is_first_req below. Is it required? It is not required. It is only an indication that this request is the first in a series of request. The host driver may do various optimisations based on this information. The first request in a series of jobs can't be prepared in parallel to the previous job. The host driver can do the following to minimise latency for the first job. * Preparing the cache while the MMC read/write cmd is being processed. In this case the pre_req could do nothing and the job is instead run in parallel to the read/write cmd being sent. If the is_first_req is false pre_req will run in parallel to an active transfer, in this case it is more efficient to prepare the request in pre_req. * Run PIO mode instead of DMA That is never going to be a good tradeoff. If the CPU is busy doing PIO, it won't have a chance to prepare a subsequent request in parallel to the first transfer. If you have two CPUs and the MMC interrupts are scheduled on the CPU 1, CPU 0 can prepare the next one. Well, it is true that in theory the PIO operation shouldn't take all the CPU anyway, so maybe there are some cycles left in between FIFO interrupts. The danger here is of course to be presented with a trickle of single requests. Doing them all with PIO is going to waste more power or prevent other tasks from running with 100% CPU which might impact the system latency more than the latency we're trying to avoid here. In other words this is something that should be evaluated and not applied freely. Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] ARM: mx5: change babbage card_detect and write_protect to use gpio
On Mon, 20 Jun 2011, Shawn Guo wrote: Due to the issue reported with ESDHC_CD_CONTROLLER mode as below, GPIO mode becomes the best choice for card detection before the issue gets addressed. http://article.gmane.org/gmane.linux.ports.arm.kernel/120790 Signed-off-by: Shawn Guo shawn@linaro.org Thanks. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Getting rid of alignment faults in userspace
On Sat, 18 Jun 2011, Nicolas Pitre wrote:
int main(int argc, char * argv[])
{
char buf[8];
void *v = buf[1];
unsigned int *p = (unsigned int *)v;
strcpy(buf, abcdefg);
printf(*%p = 0x%08x\n, p, *p);
return 0;
}
Obviously, there is a buffer overflow here, so the buf array should be
enlarged.
Nicolas
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [GIT PULL] fix for bug 754254
On Fri, 17 Jun 2011, Shawn Guo wrote: Hi Nicolas, Could you pull the fix for [Bug 754254] imx51 randomly truncates serial input at 31 characters? It extends the card CD/WP support for mx5 platforms, and adds the board level configuration for mx51evk to fix bug 754254 on this particular board. Other boards need to add their board level configuration to actually enable the support. Done. Actually I did merge and pushed it yesterday but forgot to acknowledge. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Getting rid of alignment faults in userspace
On Fri, 17 Jun 2011, Arnd Bergmann wrote: On Friday 17 June 2011 14:10:11 Dave Martin wrote: As part of the general effort to make open source on ARM better, I think it would be great if we can disable the alignment fixups (or at least enable logging) and work with upstreams to get the affected packages fixed. For release images we might want to be more forgiving, but for development we have the option of being more aggressive. Yes, makes sense. These apps typically generate hundreds or thousands of faults per session, but not millions, but it's still quite a lot of noise in syslog. Then we should make sure that an appropriate rate limiting is in place, like the patch below (untested) would do. Arnd 8--- ARM: Add rate-limiting to alignment trap printk Malicious or buggy applications can easily flood syslog by accessing unaligned data. Better use printk_ratelimited for the warning to prevent this while also allowing us to see the important output. No. The logging doesn't happen by default. You have to set the appropriate flag via the kernel cmdline or at runtime by echoing that flag to /proc/cpu/alignment which can be done by root only. This is therefore a debugging facility that should not be rate limited otherwise it loses its purpose. The only effective rate limiting configuration I would recommend is to SIGBUS misaligned accesses by default. And that's also supported already with the right flag. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Getting rid of alignment faults in userspace
On Fri, 17 Jun 2011, Paul Brook wrote:
There is still going to be a small cost even in hardware fixup so this
is very much worth solving despite it's becoming invisible because the
chips are hiding / solving it already.
But I believe that h/w feature is turned off in Linux by default. You
have to add noalign to the kernel command line to enable.
I think you'll find the hardware fixups are enabled by default on CPUs
with that design, quite possibly it can't be turned off.
The situation is much more complicated than that. There are two completely
different models for misaligned accesses (v6 and pre-v6). v7 cores are only
required to support the former.
However even under the v6 model some instructions will fault on misaligned
addresses, and the CPU may be configured to fault many others. The exact
behavior depends on the particular instruction chosen by the compiler. I
don't know whether Linux currently knows how to enable alignment checking on
v6/v7 hardware.
It does. Has done for a long time. Please see arch/arm/mm/alignment.c:
static int __init alignment_init(void)
{
[...]
/*
* ARMv6 and later CPUs can perform unaligned accesses for
* most single load and store instructions up to word size.
* LDM, STM, LDRD and STRD still need to be handled.
*
* Ignoring the alignment fault is not an option on these
* CPUs since we spin re-faulting the instruction without
* making any progress.
*/
if (cpu_architecture() = CPU_ARCH_ARMv6 (cr_alignment CR_U)) {
cr_alignment = ~CR_A;
cr_no_alignment = ~CR_A;
set_cr(cr_alignment);
ai_usermode = UM_FIXUP;
}
And if you look at arch/arm/mm/proc-v6.S in __v6_setup, you'll find out
that the CR_U bit is set.
int main(int argc, char * argv[])
{
char buf[8];
void *v = buf[1];
unsigned int *p = (unsigned int *)v;
This does not (reliably) do what you expect. The compiler need not align buf.
Printing the value of p should clarify this.
And, as we can see above, the simple accesses are left to the hardware
to fix up. However, if the misaligned access is performed using a
64-bit value pointer, then the kernel will trap an exception and the
access will be simulated.
Nicolas
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
The Linaro monthly release cycle
As you might know already, Linaro is moving to a monthly release of technology preview for most of the components being worked on. This obviously includes the kernel, so some coordination amongst all people involved is required. It was decided that those releases would happen on the last Thursday of each month, so for the 11.06 release this is June 30th. To give a chance for the kernel to be stable by that time, I'll effectively freeze it one week earlier i.e. on June 23rd for the 11.06 release. The last week before the actual release should be dedicated to testing and bug fixing only. So... what this means is that you need to send me any patches and/or pull requests for the Linaro kernel at least _8_ DAYS BEFORE THE RELEASE. Obviously, you can send me patches way before that deadline as well, which would be highly appreciated. Today is June 14th, meaning that there are less than 9 days left (less so if you don't include the weekend). We also hope that everyone will try to perform a bit more testing than usual during the last week, and also get involved in bug fixing activities until the release. If you have some concerns about this please let me know so we can find ways to improve things. Hopefully we'll get up to speed with this pace and there won't be any major problems. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The Linaro monthly release cycle
On Tue, 14 Jun 2011, Mounir Bsaibes wrote: Nico, Is there any dependency on the Toolchain WG? Does the latest kernel have to be built using the latest Toolchain release? No, it doesn't have to. That would be a good thing to do nevertheless. Does the kernel have to boot under the latest QEMU release? For device tree support I would think so. An older Linaro release for U-Boot should be fine too. Maybe John Crigby could provide more details here. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On Thu, 9 Jun 2011, Andy Green wrote: On 06/09/2011 10:01 AM, Somebody in the thread at some point said: ... and with omap4_defconfig anyway cpufreq seems at least to start up on both CPUs on Panda now, cool. Going to have a go at omap2plus_defconfig. omap2plus_defconfig is still blowing SIGILLs where omap4_defconfig is happy (these defconfigs are vs my master branch) Did you rebase your tree with all its features? I'm asking because some people would like to see HDMI support back in the Linaro kernel tree for Panda. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Usefulness of GCC's 64bit __sync_* ops on ARM
On Fri, 10 Jun 2011, David Gilbert wrote: On 25 May 2011 04:45, Nicolas Pitre nicolas.pi...@linaro.org wrote: snip FWIW, here's what the kernel part might look like, i.e. for compatibility with pre ARMv6k systems (beware, only compile tested): snip Hi Nicolas, I've just about got a set of gcc backend changes working for the inline case and plan on attacking libgcc next week. What are your intentions for that code that you sent in this message - do you intend to finish it off and upstream it or were you wanting me to do that as part of this task? I'll refine it and push it upstream. If you're doing it could you confirm the interface to work to. Here it goes: * Reference prototype: * * int __kernel_cmpxchgd64(const int64_t *oldval, * const int64_t *newval, * volatile int64_t *ptr); * * Input: * * r0 = pointer to oldval * r1 = pointer to newval * r2 = pointer to target value * lr = return address * * Output: * * r0 = returned value (zero or non-zero) * C flag = set if r0 == 0, clear if r0 != 0 * * Clobbered: * * r3, condition flags * * Definition and user space usage example: * * typedef int (__kernel_cmpxchg64_t)(const int64_t *oldval, *const int64_t *newval, *volatile int64_t *ptr); * #define __kernel_cmpxchg64 (*(__kernel_cmpxchg64_t *)0x0f60) * * Atomically store *newval in *ptr if *ptr is equal to *oldval for user space. * Return zero if *ptr was changed or non-zero if no exchange happened. * The C flag is also set if *ptr was changed to allow for assembly * optimization in the calling code. * * Notes: * *- This routine already includes memory barriers as needed. * *- Due to the length of some sequences, this spans 2 regular kuser * slots so 0x0f80 is not used as a valid entry point. * *- This call is valid only if __kernel_helper_version = 5. Of course, as discussed, this would be preferable if the interface in libgcc was in a separate object file so any reference to it would also bring in a global constructor from which the __kernel_helper_version value could be verified in order to prevent usage of this interface on kernels that lack it. Also, do you think there should be a halfword and byte interface as well, given that halfword and byte ldrex implementations aren't available on older ARMs, or expect user space to do a bit of mask fiddling with the 32bit ones? It is indeed better if user space deals with it using the 32-bit interface. I'd prefer adding new kernel helpers only when absolutely required. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: device tree stuff for linaro-2.6.39
On Wed, 8 Jun 2011, John Rigby wrote: Nicolas, Is device tree stuff equivalent to what was in .38 going in? I'm looking for the equivalent of what went into .38 in commit 3fb7bd037f31f5acdc213c0eb431c07a38803445 Merge branch 'devicetree/arm-linaro-2.6.38' of git://git.secretlab.ca/git/linux-2.6 into linaro-2.6.38 Hmmm... In fact it looks like the machine specific bits are missing. @Grant: what is the plan for those? Do you have a branch with them on top of what went into 3.0-rc1? Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On Wed, 8 Jun 2011, Dave Martin wrote: Bisecting when CONFIG_THUMB2_KERNEL=y reproducibly identified af3e4fd37a18f2e5a00175bc96061541d1364a3b as the first bad commit between v2.6.39 and linux-linaro-2.6.39/master, but it's obviously totally irrelevant and causes no code changes at all (which I confirmed by disassembling) :P Only the config.gz data and kernel signature in the kernel changes... It could be a decompressor problem or similar, but actually booting from an Image doesn't work for me either after or before the above commit. How is this commit identified as the first bad one then? Another thing to keep in mind is the fact that the OMAP code is doing pretty nasty things wrt the serial console where the detection and initialization of the serial port address is done in the zImage code, and the kernel proper simply hope for the best by simply relying on some leftovers in memory from zImage to keep on using the serial console. You can bypass this by hardcoding the appropriate addresses in arch/arm/mach-omap2/include/mach/debug-macro.S, otherwise running zImage is pretty much mandatory. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On Wed, 8 Jun 2011, Dave Martin wrote: Bisecting when CONFIG_THUMB2_KERNEL=y reproducibly identified af3e4fd37a18f2e5a00175bc96061541d1364a3b as the first bad commit between v2.6.39 and linux-linaro-2.6.39/master, but it's obviously totally irrelevant and causes no code changes at all (which I confirmed by disassembling) :P Only the config.gz data and kernel signature in the kernel changes... No, the code did change. I dismissed this commit at first, but I finally found the problem. Have a look at the fix: http://article.gmane.org/gmane.linux.ports.arm.kernel/119896 I'm not entirely satisfied with the W() usage in there though, even less so by the THUMB(nop) that are inserted here and there to provide proper padding. As the patch above shows, this is just too easy to overlook and break. I wish we could get rid of them and make that code a bit more streamlined, but I have no bright idea for that at the moment. It could be a decompressor problem or similar, but actually booting from an Image doesn't work for me either after or before the above commit. The early serial port usage issue I mentioned before notwitstanding, there was actually a real bug there too, especially if you had CONFIG_OF=y but not using any DTB. The fix is here: http://article.gmane.org/gmane.linux.ports.arm.kernel/119893 All those fixes plus a bunch of other fixes from mainline are now merged in linaro-2.6.39. BTW, I'm using git://github.com/swetland/omap4boot.git which allows to push a kernel over USB and boot it directly, entirely bypassing U-Boot and the MMC card or the network, which is *WAY* more convenient for kernel development and git bisect runs (thanks to Kevin Hilman for the link). A simple './usbboot zImage' on your build machine and a press on the reset button on the Panda and it is booted. This requires CONFIG_CMDLINE_FORCE=y though. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On Tue, 7 Jun 2011, Dave Martin wrote: On Tue, Jun 07, 2011 at 10:49:51AM +0100, Tixy wrote: No, were using two different methods to produce configs. The one I use produces a Thumb2 kernel, the one you use doesn't. Well, it seems we have a few different problems here: Certainly, it looks like there is some kernel bug related to Thumb-2. Andy's SIGILL symptom is probably something else though. I'm seeing those SIGILL crashes too, even with plain v2.6.39 from kernel.org. So this one might not be linaro-2.6.39 specific. Finally, we're not all using the same configuration, which is causing confusion. There are at least two sources for the config: * The debian.linaro/config/...config.* files from the packaged linaro kernel tree (at least me, Tixy and the packaged kernel use this) * omap2plus_defconfig (omap upstream and some other people use this) That's the one I'm also using due to its convenience. I'm not sure if there's a correct answer to that one ... but we should be careful to explain more carefully what config we're using when discussing kernel problems (I'm guilty of being a bit vague on this...) Yes, it is pretty necessary, especially if there is a config that works and another that doesn't. Does anyone have a strong view on which config we should be using? The more configs we use the better. More coverage is always good. In the end, if only one config amongst many provides eratic behaviors this is a bug worth looking at. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel / LT path for patches
On Fri, 3 Jun 2011, Andy Green wrote: Anyway linus HEAD on Panda is otherwise quite nice now, the bluetooth stuff is in there already, WLAN is working well and so on. DSS stuff is still a WIP though. If you could suggest a list of commits from Linus HEAD that I could cherry-pick in order to have BT and WLAN working as well in linaro-2.6.39 that would be cool. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On Thu, 2 Jun 2011, Dave Martin wrote: vexpress linux-linaro-2.6.39/master doesn't seem to work on vexpress using the linux-linaro-natty configuration (I get starting the kernel, then nothing). Upstream v2.6.39 does appear to work fully on vexpress in both ARM and Thumb-2. The bad commit is: 6e7c40e473c1f0553175efff64cf30288c1bc9f4 (clockevents: ARM sp804: obtain sp804 timer rate via clks) Rob Herring proposed a patch to fix this issue (below). Note that the last hunk of the patch affecting libata is not relevant (Rob subsequently retracted it.) http://article.gmane.org/gmane.linux.ports.arm.kernel/118249 That additional patch seems to fix the problem for me. Applied. imx51 - I get a booting kernel from linux-linaro-2.6.39/master in mx51evk, so long as I boot without an fdt blob. If I build a Thumb-2 kernel, it does not boot, but a Thumb-2 kernel built from linux-linaro-natty/master does boot; i.e. I get no messages at all after Starting kernel ... I haven't investigated what the problem is yet. I might not have carried over all the Thumb2 patches yet, if any of them are still relevant which is something I still need to figure out. However those would only affect build issues if I remember right. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On Thu, 2 Jun 2011, John Rigby wrote: I noticed all the fine AndyDoan/Ricardo fixes that make panda wonderful are missing. My question now is should that stuff go back in or should we plan on a LT/BSP kernel for full functionality. I presume if those patches were headed upstream they would be headed upstream:). If not they they should not be in linux-linaro. This is the strategy of this game. If it isn't going upstream you lose. In practice this means that AndyDoan/Ricardo will have to do their work again on top of this tree, and then I might merge it. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: The linaro-2.6.39 kernel repository is now alive
On Thu, 2 Jun 2011, Zach Pfeffer wrote: On 2 June 2011 18:55, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Thu, 2 Jun 2011, John Rigby wrote: I noticed all the fine AndyDoan/Ricardo fixes that make panda wonderful are missing. My question now is should that stuff go back in or should we plan on a LT/BSP kernel for full functionality. I presume if those patches were headed upstream they would be headed upstream:). If not they they should not be in linux-linaro. This is the strategy of this game. If it isn't going upstream you lose. First, please don't take offense to this feedback. I know kernel banter can have a harsh undertone. Am I really harsh? I'd like to suggest this kind of feedback isn't appropriate. The issues concerning what can't be upstreamed are well known. I'm not talking about what can't be upstreamed. I'm talking about what _can_ be upstreamed and still isn't. In practice this means that AndyDoan/Ricardo will have to do their work again on top of this tree, and then I might merge it. I'd like to further suggest that in the interest of cooperation that we take a more constructive tone. We're all going to need to work closely to accomplish our goals of upstreaming support for these boards and unifying implementations. Isn't that what we're all doing? Anyway I don't understand why you need to talk about constructive tone here, unless you read something different in my words than I actually meant. But mind you, that wouldn't be the first time this happened to me. Confused. Nicolas___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/2] sdio: make sdio_single_irq optional due to suprious IRQ
On Tue, 31 May 2011, Daniel Drake wrote: On 31 May 2011 21:33, Per Forlin per.for...@linaro.org wrote: Daniel Drake reported an issue in the libertas sdio client that was triggered by the sdio_single_irq functionality. His SDIO device seems to raise an interrupt even though there are no bits set in the CCCR_INTx register. This behaviour is not supported by the sdio_single_irq feature nor the SDIO spec. The purpose of the sdio_single_irq feature is to avoid the overhead of checking the CCCR_INTx registers, this result in no error handling of the case if there is a pending IRQ with none CCCR_INTx bits set. Thanks a lot for diagnosing this and nice work on figuring out the root cause presumably without even having access to the hardware! I've looked further, based on your findings, and have found that you are correct. During initialisation, exactly one interrupt is received with CCCR_INTx=0. Previously the mmc stack threw this interrupt away, after the optimization it now calls into libertas before it is ready to handle interrupts, leading to the crash. From that point, all other interrupts that come in are normal. This is definitely a weird hardware issue, and it would annoy me for this hardware to cause a second generic mmc layer feature be disabled by default! And actually it is not much work to harden up the libertas driver to be able to accept that spurious IRQ, and during the process of fixing that it actually made the spurious IRQ go away completely. Patch attached. So, I vote for that we work around this little hardware issue in the libertas driver, and leave this optimization enabled by default until we find a hardware issue that is more difficult to workaround. I can take on submission of the libertas patch. Thoughts? This is definitively the best approach. Thanks for fixing the root cause. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/2] sdio: report error if pending IRQ but none function bits
On Tue, 31 May 2011, Per Forlin wrote:
Return error in case of pending IRQ but none functions bits
in CCCR_INTx is set.
Signed-off-by: Per Forlin per.for...@linaro.org
---
drivers/mmc/core/sdio_irq.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index 2f81ddc..8184b6e 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -50,6 +50,11 @@ static int process_sdio_pending_irqs(struct mmc_card *card)
return ret;
}
+ if (!pending) {
+ printk(KERN_WARNING %s: pending IRQ but none function bits\n,
+mmc_card_id(card));
+ ret = -EINVAL;
+ }
Nope, this won't work with the polled interrupt mode.
Nicolas
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 0/2] sdio: add quirk for spurious SDIO IRQ
On Wed, 1 Jun 2011, Per Forlin wrote: From: Per Forlin per.for...@linaro.org Daniel Drake reported an issue in the libertas sdio client that was triggered by the sdio_single_irq functionality. His SDIO device seems to raise an interrupt even though there are no bits set in the CCCR_INTx register. This behaviour is not supported by the sdio_single_irq feature nor the SDIO spec. The purpose of the sdio_single_irq feature is to avoid the overhead of checking the CCCR_INTx registers, this result in no error handling of the case if there is a pending IRQ with none CCCR_INTx bits set. This patchset adds a quirk to support this spurious IRQ issue and also report a warning if an SDIO interrupt is raised but none CCCR_INTx bits are set. Given that the issue can be fixed locally to the libertas driver, I'd suggest not merging this series until truly unfixable issues come up, as Daniel said. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
The linaro-2.6.39 kernel repository is now alive
Time to leave 2.6.38 behind and move on! We now have a 2.6.39 based Linaro kernel which can be viewed here: http://git.linaro.org/gitweb?p=kernel/linux-linaro-2.6.39.git;a=summary or cloned from either of those: git://git.linaro.org/kernel/linux-linaro-2.6.39.git http://git.linaro.org/git/kernel/linux-linaro-2.6.39.git This will continue to evolve as this is just the beginning for that tree, so more stuff will be merged. Only smoke tested on a Dove board, and compile tested for OMAP so far. Most of the ARM related patches which made their way into v3.0-rc1 in mainline are included. However there might still be patches that were included in linaro-2.6.38 which are missing from linaro-2.6.39 at the moment. I might forward port some of them according to their importance, their look, or even my mood. So if you need extra patches on top of what's currently there please tell me and don't just assume I will pick them up from linaro-2.6.38 automatically (this is reverse garbage collection i.e. I'll simply leave unwanted patches behind). This is also a good opportunity for landing teams to test their git-rebase skills and move ahead to linaro-2.6.39. Enjoy! Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Usefulness of GCC's 64bit __sync_* ops on ARM
On Tue, 31 May 2011, Dave Martin wrote: On Tue, May 31, 2011 at 03:35:42PM +0100, Richard Earnshaw wrote: I think the difficulty here is that glibc expects either the compiler, or libgcc to provide the sync primitives; and while GCC can tie the inlined copy of the primitive to use of CPUs with the relevant instruction, the libgcc version doesn't know how to specify that the code it's relying on requires a minimal kernel version... The libgcc 64-bit atomic helpers could do a runtime check on the __kernel_helper_version field in the vectors page before calling the 64-bit cmpxchg helper. This will allow the absence of the helper to be reliably detected on older kernels. Because this is data, it might cause an extra D-TLB miss to accompany any other miss associated with calling the kernel helper (if it exists). Isn't there a way to pull in a global constructor or similar whenever a reference to the 64-bit cmpxchg helper is made, so that the constructor code could simply validate the kuser version number and bail out otherwise? I know this is certainly the case on x86 that if you statically compile a binary on a modern distro in the hope of being able to execute that binary anywhere, you may get a kernel too old error message when trying to run it on older distros. The same thing could be done for the ARM 64-bit cmpxchg helper as well, at startup rather than on every invokation, no? Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Usefulness of GCC's 64bit __sync_* ops on ARM
On Thu, 26 May 2011, Dave Martin wrote: The core logic spans 5 instructions. Only 3 of them are actually the same in both cases i.e. those with no references to 1b or 2b, and they're perfectly interlaced in between the others. Trying to make this into common runtime code would result in even bigger code I'm afraid. This could be made into common source code via a macro though. Fair enough -- a macro might be worth a try _if_ it simplifies things in the source, but I think you're right that merging the actual code probably isn't worth it just to save a few words in the vectors page (which eats up 4K regardless of what we put in it) and a few cycles per fault (which already costs many, many cycles). In the normal cases, there is no additional cycles per fault as the inline check remains unchanged, and it goes like this: @ Make sure our user space atomic helper is restarted @ if it was interrupted in a critical region. Here we @ perform a quick test inline since it should be false @ 99.% of the time. The rest is done out of line. cmp r2, #TASK_SIZE blhskuser_cmpxchg_fixup In most cases the branch is not taken. Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Usefulness of GCC's 64bit __sync_* ops on ARM
On Tue, 24 May 2011, Michael Hope wrote:
On Tue, May 24, 2011 at 10:33 AM, Michael Casadevall
mcasadev...@ubuntu.com wrote:
On 05/19/2011 10:56 AM, David Gilbert wrote:
On 19 May 2011 16:49, Ken Werner k...@linux.vnet.ibm.com wrote:
On 05/19/2011 12:40 PM, David Rusling wrote:
Is this going to end up in a blueprint? This is the last loose end of
SMP / atomic memory operations work and I'd like to see it happen
Hi,
Yep, there is one (kind of a skeleton) in place at:
https://blueprints.launchpad.net/linaro-toolchain-misc/+spec/64-bit-sync-primitives
Which I'll be filling out in the next few days.
Dave
Is there a timeline for this feature? It's been requested by members of
the ARM Server Club to have this implemented, and its important that
this makes it into the Ubuntu 11.10 release.
Michael
Hi Michael. The topics for this planning cycle are listed here:
https://wiki.linaro.org/Cycles//TechnicalTopics/Toolchain
64 bit sync primitives are medium priority so they will be achieved in
the next six months.
A draft of what is in whos queue is at:
https://wiki.linaro.org/Cycles//TechnicalTopics/Toolchain/Planning
The primitives are second in Dave's queue so should be started in the
next three months.
FWIW, here's what the kernel part might look like, i.e. for
compatibility with pre ARMv6k systems (beware, only compile tested):
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index e8d8856..53830a7 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -383,7 +383,7 @@ ENDPROC(__pabt_svc)
.endm
.macro kuser_cmpxchg_check
-#if __LINUX_ARM_ARCH__ 6 !defined(CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG)
+#if !defined(CONFIG_CPU_32v6K) !defined(CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG)
#ifndef CONFIG_MMU
#warning NPTL on non MMU needs fixing
#else
@@ -392,7 +392,7 @@ ENDPROC(__pabt_svc)
@ perform a quick test inline since it should be false
@ 99.% of the time. The rest is done out of line.
cmp r2, #TASK_SIZE
- blhskuser_cmpxchg_fixup
+ blhskuser_cmpxchg64_fixup
#endif
#endif
.endm
@@ -797,6 +797,139 @@ __kuser_helper_start:
/*
* Reference prototype:
*
+ * int __kernel_cmpxchgd64(int64_t *oldval, int64_t *newval, int64_t *ptr)
+ *
+ * Input:
+ *
+ * r0 = pointer to oldval
+ * r1 = pointer to newval
+ * r2 = pointer to target value
+ * lr = return address
+ *
+ * Output:
+ *
+ * r0 = returned value (zero or non-zero)
+ * C flag = set if r0 == 0, clear if r0 != 0
+ *
+ * Clobbered:
+ *
+ * r3, flags
+ *
+ * Definition and user space usage example:
+ *
+ * typedef int (__kernel_cmpxchg64_t)(const int64_t *oldval,
+ *const int64_t *newval,
+ *volatile int64_t *ptr);
+ * #define __kernel_cmpxchg64 (*(__kernel_cmpxchg64_t *)0x0f60)
+ *
+ * Atomically store newval in *ptr if *ptr is equal to oldval for user space.
+ * Return zero if *ptr was changed or non-zero if no exchange happened.
+ * The C flag is also set if *ptr was changed to allow for assembly
+ * optimization in the calling code.
+ *
+ * Notes:
+ *
+ *- This routine already includes memory barriers as needed.
+ *
+ *- Due to the length of some sequences, this spans 2 regular kuser
+ * slots so 0x0f80 is not used as a valid entry point.
+ */
+
+__kuser_cmpxchg64: @ 0x0f60
+
+#if defined(CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG)
+
+ /*
+* Poor you. No fast solution possible...
+* The kernel itself must perform the operation.
+* A special ghost syscall is used for that (see traps.c).
+*/
+ stmfd sp!, {r7, lr}
+ ldr r7, 1f @ it's 20 bits
+ swi __ARM_NR_cmpxchg64
+ ldmfd sp!, {r7, pc}
+1: .word __ARM_NR_cmpxchg64
+
+#elif defined(CONFIG_CPU_32v6K)
+
+ stmfd sp!, {r4, r5, r6, r7}
+ ldrdr4, r5, [r0]@ load old val
+ ldrdr6, r7, [r1]@ load new val
+ smp_dmb arm
+1: ldrexd r0, r1, [r2]@ load current val
+ eorsr3, r0, r4 @ compare with oldval (1)
+ eoreqs r3, r1, r5 @ compare with oldval (2)
+ strexdeq r3, r6, r7, [r2] @ store newval if eq
+ teqeq r3, #1 @ success?
+ beq 1b @ if no then retry
+ smp_dmb arm
+ rsbsr0, r3, #0 @ set returned val and C flag
+ ldmfd sp!, {r4, r5, r6, r7}
+ usr_ret lr
+
+#elif !defined(CONFIG_SMP)
+
+#ifdef CONFIG_MMU
+
+ /*
+* The only thing that can break atomicity in this cmpxchg64
+* implementation is either an IRQ or a data abort exception
+* causing another
