Re: AM335x mpurate + bogomips
On Thu, Feb 21, 2013 at 11:36 AM, Mark Jackson mpfj-l...@mimc.co.uk wrote: Before I dig any deeper, can anyone tell me if the bootarg mpurate is meant to be supported for AM335x SoCs ? I've tried it on our custom board using 3v8, but no joy. The boot log shows:- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-03059-g621553c-dirty (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #113 SMP Thu Feb 21 16:29:48 GMT 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow NanoBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] AM335X ES1.0 (neon ) ... [0.00] Kernel command line: console=ttyO0,115200n8 mpurate=720 root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait ... [0.001119] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408) I don't think mpurate does anything on AM335x, though I could be wrong---just that I've not heard of anyone using it for any purpose. The BogoMIPS values don't seem to be very useful. I'm not sure of their purpose, but the hopefully useful information I can offer you is that if you are running a kernel supporting dynamic frequency scaling on AM335x, the number tends to be lower. I have seen other boot logs outputs [1] from other people where they are getting nearly double that. Looking at omap2xxx_clk_arch_init(), only ompa24xx devices are supported. Am I missing something obvious (like it's not yet supported !!) ? Use the cpufreq tools to determine and set the frequency. Cheers Mark J. [1] http://e2e.ti.com/support/embedded/linux/f/354/t/245316.aspx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4: 3.8: IPV6 + PREEMPT_VOLUNTARY + !DEBUG_[SPINLOCK|MUTEXES] = BUG()
On Thu, Feb 21, 2013 at 10:48:19AM +0100, Paolo Pisati wrote:
any idea how can i debug this?
Please try this patch, and report back whether it solves your problem.
Thanks.
arch/arm/mm/alignment.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index b820eda..db26e2e 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -749,7 +749,6 @@ do_alignment(unsigned long addr, unsigned int fsr, struct
pt_regs *regs)
unsigned long instr = 0, instrptr;
int (*handler)(unsigned long addr, unsigned long instr, struct pt_regs
*regs);
unsigned int type;
- mm_segment_t fs;
unsigned int fault;
u16 tinstr = 0;
int isize = 4;
@@ -760,16 +759,15 @@ do_alignment(unsigned long addr, unsigned int fsr, struct
pt_regs *regs)
instrptr = instruction_pointer(regs);
- fs = get_fs();
- set_fs(KERNEL_DS);
if (thumb_mode(regs)) {
- fault = __get_user(tinstr, (u16 *)(instrptr ~1));
+ u16 *ptr = (u16 *)(instrptr ~1);
+ fault = probe_kernel_address(ptr, tinstr);
if (!fault) {
if (cpu_architecture() = CPU_ARCH_ARMv7
IS_T32(tinstr)) {
/* Thumb-2 32-bit */
u16 tinst2 = 0;
- fault = __get_user(tinst2, (u16 *)(instrptr+2));
+ fault = probe_kernel_address(ptr + 1, tinst2);
instr = (tinstr 16) | tinst2;
thumb2_32b = 1;
} else {
@@ -778,8 +776,7 @@ do_alignment(unsigned long addr, unsigned int fsr, struct
pt_regs *regs)
}
}
} else
- fault = __get_user(instr, (u32 *)instrptr);
- set_fs(fs);
+ fault = probe_kernel_address(instrptr, instr);
if (fault) {
type = TYPE_FAULT;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM335x mpurate + bogomips
On 02/22/2013 02:03 AM, Jason Kridner wrote: On Thu, Feb 21, 2013 at 11:36 AM, Mark Jackson mpfj-l...@mimc.co.uk wrote: Before I dig any deeper, can anyone tell me if the bootarg mpurate is meant to be supported for AM335x SoCs ? I've tried it on our custom board using 3v8, but no joy. The boot log shows:- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-03059-g621553c-dirty (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #113 SMP Thu Feb 21 16:29:48 GMT 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow NanoBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] AM335X ES1.0 (neon ) ... [0.00] Kernel command line: console=ttyO0,115200n8 mpurate=720 root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait ... [0.001119] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408) I don't think mpurate does anything on AM335x, though I could be wrong---just that I've not heard of anyone using it for any purpose. The BogoMIPS values don't seem to be very useful. I'm not sure of their purpose, but the hopefully useful information I can offer you is that if you are running a kernel supporting dynamic frequency scaling on AM335x, the number tends to be lower. I have seen other boot logs outputs [1] from other people where they are getting nearly double that. Looking at omap2xxx_clk_arch_init(), only ompa24xx devices are supported. Am I missing something obvious (like it's not yet supported !!) ? Use the cpufreq tools to determine and set the frequency. Cant we just drop mpurate? The initial trigger was to be able to boot at a known frequency - bootloaders typically do that. having to deal with mpurate means that we have to deal with it for *all* SoCs - which means we have to support frequency and voltage forced setting, including other fringe stuff like abb, avs etc.. for example: just doing a clock setting to 1GHz is not an good idea if bootloader booted at 300MHz without being able to do everything right *if* it is right for the SoC. I agree with Jason here, if we wanted to boot up kernel at a higher frequency - do it in the bootloader. if your bootloader is not controlled or too ancient to be modified, do it with cpufreq userspace utils. at least the bootlogic will remain in the at least predictable boot order of initcalls and subsystem bringup sequences without having to deal with exception overrides like mpurate, which dont always work 100%. --- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Introducing Device Tree Overlays
Our use case is partial reconfiguration of the FPGA. This will be driven from userspace, so the bitstream to program the FPGA will come from userspace, then the overlay for the DT, also from userspace. So we want to take a compiled partial device tree and simply 'cat' it to a point under /proc, such as 'cat new-ip.dtb /proc/device-tree' Alan Tull Altera Corp. On Thu, Feb 21, 2013 at 3:53 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Alan, On Feb 21, 2013, at 1:25 PM, delicious quinoa wrote: I like where this is heading. I'm interested in a use case where IP can be loaded into a FPGA, then add a blob to the device tree and load some drivers. I see your github tree. If I wanted to cherry-pick your code and play around with it, which branch should I use? not-capebus-21? not-capebus-v21 is the latest one and indeed that has it in. Please note that I had some other FPGA people interested with it. Perhaps we can go through use cases to come up with your requirements Thanks, Alan Tull Altera Corp Regards -- Pantelis On Fri, Jan 4, 2013 at 1:31 PM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: The following patchset introduces Device Tree overlays, a method of dynamically altering the kernel's live Device Tree. This patchset is against mainline as of Friday Jan 4 2013. (4956964 Merge tag 'driver-core-3.8-rc2' of \ git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core) Note that a separate patch for the DTC compiler has been posted and is required to compile the DTS files according to the documentation. The patch is dtc: Dynamic symbols fixup support An implementation patchset for a beaglebone cape loader will follow, but if you want to check out a working kernel for the beaglebone please pull from: git://github.com/pantoniou/linux-bbxm.git branch not-capebus-v8 Pantelis Antoniou (6): OF: Introduce device tree node flag helpers. OF: export of_property_notify OF: Export all DT proc update functions OF: Introduce utility helper functions OF: Introduce Device Tree resolve support. OF: Introduce DT overlay support. .../devicetree/dynamic-resolution-notes.txt| 25 + Documentation/devicetree/overlay-notes.txt | 179 + drivers/of/Kconfig | 19 + drivers/of/Makefile| 4 +- drivers/of/base.c | 114 +-- drivers/of/overlay.c | 831 + drivers/of/resolver.c | 394 ++ drivers/of/util.c | 253 +++ include/linux/of.h | 243 ++ 9 files changed, 2005 insertions(+), 57 deletions(-) create mode 100644 Documentation/devicetree/dynamic-resolution-notes.txt create mode 100644 Documentation/devicetree/overlay-notes.txt create mode 100644 drivers/of/overlay.c create mode 100644 drivers/of/resolver.c create mode 100644 drivers/of/util.c -- 1.7.12 ___ devicetree-discuss mailing list devicetree-disc...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Kbuild support for ARM FIT images
On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: Any comments on this approach? Is it better to merge mkfitsrc.sh with mkuboot.sh? I know this was discussed quite extensively yesterday, but here is my take on it: Given the recent complications from multiplatform, we really saw a strong reason to _not_ do the final boot wrapping in the kernel build system. Produce the zImage and the DTB files, and have a surrounding script that bundles the two in a format that your particular device needs. Most distros have scripts to handle the make install step of a kernel build. That's where this belongs, not in the actual build step. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM335x mpurate + bogomips
On 2/21/2013 11:36 AM, Mark Jackson wrote: Before I dig any deeper, can anyone tell me if the bootarg mpurate is meant to be supported for AM335x SoCs ? I've tried it on our custom board using 3v8, but no joy. The boot log shows:- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-03059-g621553c-dirty (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #113 SMP Thu Feb 21 16:29:48 GMT 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow NanoBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] AM335X ES1.0 (neon ) ... [0.00] Kernel command line: console=ttyO0,115200n8 mpurate=720 root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait ... [0.001119] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408) I have seen other boot logs outputs [1] from other people where they are getting nearly double that. I have also observed a drop in the reported BogoMIPS value when using the latest kernel. Previously (with a 3.5 kernel) the BogoMIPS value was approximately equal to the CPU frequency. I finally found the reason for the BogoMIPS change: http://www.spinics.net/lists/arm-kernel/msg221672.html It looks like BogoMIPS reporting changed because of the delay routine patch introduced in 3.6. So the change in BogoMIPS is real, but should not be a concern. frank agius -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Fri, Feb 22, 2013 at 02:56:33AM -0500, Jason Kridner wrote: The desired FPGA use case is DT updates after booting the kernel. This has nothing to do with FIT images. And if the FPGA tools generate the DTB, then it is certainly not tied to the kernel. Completely unrelated, but do you have any pointer for how to do this? Hot plugging a 'dtb fragment' into the kernel would be really handy.. This doesn't answer the full question on how FPGA tools generate DTB, but it is a huge problem for BeagleBone add-on hardware that we have In all my cases I hand code the DT's for the FPGA IP, they get quite big, the one I'm looking at now has over 17 DT nodes inside the FPGA already. This is why we are re-using the DT framework to describe the chip, not building a C coded PCI driver to do the same work. some mechanism to dynamically load DT fragments. Pantelis posted some work in that direction[1] and has continued development of his patches and we've been using those extensively with BeagleBone kernel development[2]. Yes, I saw this. They look really interesting, I think the notion of hot plugging a DT fragment into the main DT is useful for many applications.. Jason -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On 02/21/2013 05:39 PM, Russell King - ARM Linux wrote: On Thu, Feb 21, 2013 at 05:10:36PM -0700, Stephen Warren wrote: On 02/21/2013 02:18 PM, Nicolas Pitre wrote: ... Someone will want to use a previously unsupported feature of some HW and then write the DT bindings for that feature for the first time. E.g. Tegra's one-wire controller isn't that commonly used, so we have no binding for it yet despite it being maybe a couple years after starting DT work for Tegra. The AC'97 was only recently supported. Now I agree that this probably will settle down eventually. However, HW will have been widely distributed well before the DT bindings are feature-complete and bug-free. Any solution needs to take that into account, rather than only attempting to solve the situation after the hardware is obsolete and hence the bindings are stable. Tell me then - how is it possible for my laptop to boot correctly with its ACPI data which describes its hardware, and that ACPI data hardly ever has to be updated. Many PC systems have been doing this for years, with various degrees of success - but generally once you have a working system it stays working and never needs to have its ACPI data updated. I'm not too familiar with ACPI or even low-level x86/PC architecture, so forgive me if I'm talking crap, but I suspect there are quite a few reasons for the differences here: * PC systems in general are rather simpler and more standardized. Even where differentiation can exist, it's encapsulated behind simple self-contained interfaces. * As an example, most random expansion devices on a PC are PCIe or USB based, even built-in stuff such as WiFi cards etc. On ARM, there are no standards, so anything goes. Hence, PC expansion cards are much more self-contained and interact with other devices less, whereas on ARM you have a whole spaghetti slew of chips, GPIOs, regulators, interrupts, ... * I think ARM designs are exposed to a wider audience earlier on in their maturity cycle. On x86, there are a number of standards for ACPI etc., and the first people to interact with boards and implement these standards are BIOS and board vendors, and then the boards get out to the general public, and they at least basically all confirm to those standards and work. However, on ARM, we're developing those standards well after the fact; after the HW has shipped and been in use, retro-fitting the standards etc. So, we're being exposed to a much earlier point in the whole cycle than we can even see on x86. I bet x86 CPU, chipset, BIOS, and board vendors see the kind of change in ACPI tables that we're seeing in DT right now. * I imagine there are fewer different sets of people (CPU vendors, BIOS vendors) having to work on defining ACPI standards than there are ARM SoC vendors and Linux developer who're working on DT standards. * x86 is very mature, so there's a lot more incremental development and compatibility. ARM and DT-on-ARM are very new, so it's still the wild west. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
