linaro-dev January 2011

linaro-dev@lists.linaro.org

81 participants
84 discussions

tcl8.5 breaks dpkg-cross assumptions and multiarch

by Wookey

tcl8.5-dev contains /usr/lib/tcl8.5/tclConfig.sh which is a symlink pointing to /usr/share/tcltk/tcl8.5/tclConfig.sh Currently dpkg-cross only copies symlinks across when crossing a package if the symlink points to somewhere within /lib. symlinks outside /lib are ignored because they are not arch-dependent so shouldn't need to be crossed. The file /usr/lib/tcl8.5/tclConfig.sh is used by packages which build extensions to tcl (such as sqlite), so that files does need to be present. The file is essentially a cache of the config options TCL was built with so that extensions can make sure they match up. However it is not arch-independent. e.g. Line 22 of that file is TCL_CC='x86_64-linux-gnu-gcc' on the x86_64 version and TCL_CC='arm-linux-gnueabi-gcc' on the armel version. Other options also differ between 32-bit and 64-bit arches for example. So this file is arch-dependent in that it's different for each arch it is built-on but arch-independent in that it's just a shell file. Debian policy (8.2) says: --------------- It is recommended that supporting files and run-time support programs that do not need to be invoked manually by users, but are nevertheless required for the package to function, be placed (if they are binary) in a subdirectory of /usr/lib, preferably under /usr/lib/package-name. If the program or file is architecture independent, the recommendation is for it to be placed in a subdirectory of /usr/share instead, preferably under /usr/share/package-name. Following the package-name naming convention ensures that the file names change when the shared object version changes. Files and support programs only useful when compiling software against the library should be included in the development package for the library --------------- A maintainer reading the above could reasonably decide that /usr/share was the right place for this file, because the file itself (being just shell) is arch-independent. The problem is that the contents are arch-dependent. Policy is not at all clear on this distinction (It's been making my head hurt all day). For multiarch, or existing dpkg-cross cross-compiling, to work, arch-dependent needs to mean either form _or_ content (see below for elaboration). The original tcl build puts both tclConfig.sh and tcl.m4 in /usr/lib but the debian packaging moves them to /usr/share/tcltk/tcl8.5 and /usr/share/aclocal/ respectively Currently the sqlite build fails because it looks for tclConfig.sh in /usr/<triplet>/lib/tcl8.5/ and doesn't find it there, because dpkg-cross didn't copy the symlink (or original) there. So, the questions is - which of these is the correct fix: 1) make dpkg-cross copy over symlinks even when they point into /usr/share 2) make tcl8.5 put tclConfig.sh in /usr/lib/tcl8.5 instead of /usr/share/tcltk/tcl8.5 3) make sqlite (and similar packages) look in /usr/share/tcltk/tcl8.5 instead of /usr/lib/tcl8.5 when building I note that the supplied tcl8.5.m4 file actually lists a whole pile of possible locations for the file: for i in `ls -d ${libdir} 2>/dev/null` \ `ls -d ${exec_prefix}/lib 2>/dev/null` \ `ls -d ${prefix}/lib 2>/dev/null` \ `ls -d /usr/local/lib 2>/dev/null` \ `ls -d /usr/contrib/lib 2>/dev/null` \ `ls -d /usr/share/tcltk/tk8.5 2>/dev/null` \ `ls -d /usr/lib 2>/dev/null` \ `ls -d /usr/lib64 2>/dev/null` \ However that list doesn't include anything ending in tcl8.5 (i.e /usr/<triplet>/lib/tcl8.5 or /usr/share/tcltk/tcl8.5) and perhaps should by way of 'back-up plan', although I haven't actually looked into the detals of how that is used. Consideration when deciding how to fix this include: Squeeze will be released in a few days with this broken so we will be stuck with the /usr/share/ file location for some time there. Any fix going into Ubuntu should make Natty easily enough. For Multiarch tcl-dev will be a Multiarch:same package (i.e a 'library' package) (despite the name, it contains nothing but headers, libraries and the above config.sh and m4 files), so the two different tclConfig.sh files supplied by the DEB_BUILD_ARCH and DEB_HOST_ARCH packages (when cross-building) will clash and the 2nd package will not be installable. This, it seems to me, is the clinching argument that the correct fix is to change the tcl build to put these files in /usr/lib. This also implies that policy 8.2 needs to be clarified to explain what 'arch-independent' means. Are there other situations which expect to find the tclConfig.sh file in /usr/share? Is so those need considering. Does anyone disgree with the above conclusions? And do people agree that policy 8.2 could be clearer on this point? I've filed a bug containing some of the above discussion and a patch for tcl8.5. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611650 Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/

15 years

Re: [PATCH] arm: Improve MMC performance on Versatile Express

by Russell King - ARM Linux

On Mon, Jan 24, 2011 at 12:27:16PM -0000, Pawel Moll wrote: > So - we'll try to enlarge FIFO. For the moment - playing with interrupts > affinity seem to be a viable workaround. I don't think enlarging the FIFO will help too much. The issue is whether the CPU can keep up with the data rate coming off the card. If it can't, then no matter how large the FIFO is, it will eventually overflow. The real answer is to avoid PIO mode, and use DMA support. However, I've had problems using DMA on the ARM development boards. You can find details my DMA issues internally within ARM by talking to Catalin. The alternative answer, I believe implemented by some of ARMs silicon partners, is to turn the card clock off when the FIFO becomes full/empty to stop it sending more data. I think this violates some of the MMC/SD requirements, but it seems to work for the silicon partners just fine.

15 years

RFC: Try moving kernel wg call to IRC?

by Dave Martin

Hi there, Just a thought--- is it worth experimenting with running the kernel wg meeting on IRC instead of the conf call? Personally, I find IRC meetings _much_ more digestible than conf calls (better "audio quality"; ability to scroll back when you don't hear / don't understand something etc.), but I don't know whether other people feel the same way -- that may just be my personal preference. Comparing the dev platform group's weekly IRC meeting with the kernel conf call, I've found that the IRC format works quite a lot better for me, but again, that may just be my experience. Cheers ---Dave

15 years

[PATCH] arm: Improve MMC performance on Versatile Express

by Pawel Moll

VE suffers from serious problem with MMC transfers - low performance, errors when other IO peripherals (especially USB) are used at the same time etc. It all boils down to the MMC controller short FIFO and - in result - timing constrains. The most problematic case - USB driver hogging CPU and MMC FIFO under/overruns in the result - can be mitigated on SMP system by distributing interrupts handling for these peripherals between cores. With this, the MMC card clock can be safely (at least it looks like it) increased to 1.5MHz, improving performance. Signed-off-by: Pawel Moll <pawel.moll(a)arm.com> --- arch/arm/mach-vexpress/v2m.c | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c index 4b5af01..300ac72 100644 --- a/arch/arm/mach-vexpress/v2m.c +++ b/arch/arm/mach-vexpress/v2m.c @@ -244,6 +244,7 @@ static unsigned int v2m_mmci_status(struct device *dev) static struct mmci_platform_data v2m_mmci_data = { .ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34, .status = v2m_mmci_status, + .f_max = 1500000, }; static AMBA_DEVICE(aaci, "mb:aaci", V2M_AACI, NULL); @@ -391,6 +392,19 @@ static void __init v2m_init(void) for (i = 0; i < ARRAY_SIZE(v2m_amba_devs); i++) amba_device_register(v2m_amba_devs[i], &iomem_resource); + /* WARNING: HACK HACK HACK! + * + * MMCI cell has very tight timing requirements regarding interrupt + * handling (fractions of millisecond), while the USB host controller + * interrupt handler can hog the CPU for more then 1 millisecond! + * + * To mitigate the problem on SMP systems, we can set CPU affinities + * of these interrupts to different cores... */ + BUG_ON(v2m_usb_resources[1].flags != IORESOURCE_IRQ); + irq_set_affinity(v2m_usb_resources[1].start, cpumask_of(0)); + irq_set_affinity(mmci_device.irq[0], cpumask_of(1)); + irq_set_affinity(mmci_device.irq[1], cpumask_of(1)); + pm_power_off = v2m_power_off; arm_pm_restart = v2m_restart; -- 1.6.3.3

15 years

Re: [PATCH] arm: Improve MMC performance on Versatile Express

by Russell King - ARM Linux

On Mon, Jan 24, 2011 at 05:54:18PM -0000, Pawel Moll wrote: > $ git am 0001-arm-Improve-MMC-performance-on-Versatile-Express.patch > > / # uname -a > Linux (none) 2.6.38-rc2+ #12 SMP Mon Jan 24 17:41:53 GMT 2011 armv7l GNU/Linux > / # cat /dev/sda > /dev/null & > / # dd if=/dev/mmcblk0 of=/dev/null bs=64k count=128 > 128+0 records in > 128+0 records out > 8388608 bytes (8.0MB) copied, 1.501529 seconds, 5.3MB/s > > > THERE IS NO ISSUE WITH MMCI. THE HARDWARE DOES NOT NEED "FIXING". > > I'm really pleased you think so. It's always nice to have happy customers :-) If you're flooding the system with USB traffic, enlargening the FIFO size won't help. Making the FIFO larger just decreases the _interrupt_ _latency_ requirements. It doesn't mean you can cope with the amount of data being transferred. if (cycles-to-transfer-usb-packets + cycles-to-transfer-MMC-data > available-cpu-cycles) you_are_stuffed(even_with_larger_fifo); So I'm not surprised that running USB and MMC at full speed results in MMC losing out. You will find that even with a larger FIFO, MMC will still lose out. Why? The ISP1761 can store the packets without complaint, and the host CPU can read them when it's ready. As soon as one packet is read off the host, the next packet is probably sitting there waiting for the host CPU to read it. When the ISP1761 buffer becomes full, it can tell the device to stop sending data. The result of that is the ISP1761 will be able to transfer data as fast as the host CPU can possibly go - to the exclusion of the MMC interface. No amount of FIFO (well, except several KB to cover the _largest_ size of MMC transfer we request) will resolve the problem of USB and MMC sharing the same CPU.

15 years

l-m-c console arguments

by Amit Kucheria

Hi, I just tried to create an SD image for the beagle with l-m-c from bzr. The kernel command-line ends up containing 'console=tty0 console=NONE,115200n8'. Board configuration problem? Overriding l-m-c with --console ttyO2 doesn't work since it is added before the other consoles, so doesn't end up getting input. Shouldn't it be the last console added in the list? Regards, Amit

15 years

[Francis J. Lacoste] Announcing Launchpad Squads

by James Westby

Hi, Since we use Launchpad so much within Linaro this may be of interest to some. I am the Launchpad stakeholder representative for Linaro, so if you wish to request any features or escalate any bugs then please feel free to talk to me. Thanks, James

15 years

[RFC PATCH] SDHCI: S3C: Add support for retrieving memory and irq resource information from device tree.

by thomas.abraham＠linaro.org

From: Thomas Abraham <thomas.abraham(a)linaro.com> Add support for retrieving memory and irq resource information from device tree for Samsung's SDHCI controller driver. Signed-off-by: Thomas Abraham <thomas.abraham(a)linaro.org> --- The modification will be made more generic to support both DT and non-DT versions of the driver without the #ifdef's. For now, this patch is for review and to understand if the approach adopted to obtain resource information from the device tree is appropriate. drivers/mmc/host/sdhci-s3c.c | 32 ++++++++++++++++++++++++++++++++ 1 files changed, 32 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c index 1720358..f536061 100644 --- a/drivers/mmc/host/sdhci-s3c.c +++ b/drivers/mmc/host/sdhci-s3c.c @@ -19,6 +19,9 @@ #include <linux/clk.h> #include <linux/io.h> #include <linux/gpio.h> +#include <linux/of.h> +#include <linux/of_irq.h> +#include <linux/of_address.h> #include <linux/mmc/host.h> @@ -348,23 +351,52 @@ static int __devinit sdhci_s3c_probe(struct platform_device *pdev) struct sdhci_s3c *sc; struct resource *res; int ret, irq, ptr, clks; + struct device_node *np = NULL; +#ifdef CONFIG_OF + struct resource iores; +#endif if (!pdata) { dev_err(dev, "no device data specified\n"); return -ENOENT; } +#ifdef CONFIG_OF + for_each_compatible_node(np, NULL, "samsung,sdhci-s3c") { + const u32 *id = of_get_property(np, "cell-index", NULL); + if (be32_to_cpu(*id) == pdev->id) + break; + } + + if (!np) { + dev_err(dev, "no matching device node specified in device tree\n"); + return -ENOENT; + } +#endif + +#ifndef CONFIG_OF irq = platform_get_irq(pdev, 0); +#else + irq = of_irq_to_resource(np, 0, NULL); +#endif if (irq < 0) { dev_err(dev, "no irq specified\n"); return irq; } +#ifndef CONFIG_OF res = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) { dev_err(dev, "no memory specified\n"); return -ENOENT; } +#else + if (of_address_to_resource(np, 0, &iores)) { + dev_err(dev, "no memory specified in device tree\n"); + return -ENOENT; + } + res = &iores; +#endif host = sdhci_alloc_host(dev, sizeof(struct sdhci_s3c)); if (IS_ERR(host)) { -- 1.6.6.rc2

15 years

Tidying up some ARM boards

by Michael Hope

My office was getting a bit messy so I re-purposed an old PC case and mounted my ARM boards, a switch, and far too many power supplies into it: http://people.linaro.org/~michaelh/racked/IMG_20110131_145444.jpg The Stagecoach board goes where the motherboard used to: http://people.linaro.org/~michaelh/racked/IMG_20110131_145403.jpg It turns out that a PandaBoard fits well in a floppy drive adapter slotted into a 5 1/4" drive bay. 2x PandaBoards, 2x BeagleBoards, and a Stagecoach gives 12 cores for a total of 9.76 GHz of processing... not as cool as David's box, but I like it :) -- Michael

15 years

Fwd: Generating ancilliary sections with gas

by Dave Martin

[Forwarding this to linaro-dev too ... should have sent it there in the first place! ---Dave] ---------- Forwarded message ---------- From: Dave Martin <dave.martin(a)linaro.org> Date: Fri, Jan 28, 2011 at 11:52 AM Subject: Generating ancilliary sections with gas To: linaro-toolchain <linaro-toolchain(a)lists.linaro.org> Hi all, With gas, does anyone know of a way to create a section whose name is based on that of the current section? The specific requirement is to be able to define a generic macro like the example "fixup" below, whose purpose is to record ancilliary data related to some other section. To illustrate: .macro fixup 100\@ : .pushsection fixup<current section name>, "a" .long 100\@b .popsection .endm .text ... fixup .long sym1 ... .section .other, "ax" ... fixup .long sym2 The linux kernel uses a technique just like this for patching SMP kernels at bootup to work on uniprocessor platforms (when CONFIG_SMP_ON_UP is enabled), resulting in code looking something like this: void exit __attribute__ (( __section__ (".text.exit") )) { ... asm( ... FIXUP("something") ... ); } Note that the inline asm may actually come out of a generic header file rather than being explitly written for this invocation. So it may have to be truly generic. Is far as I have been able to determine, it's not possible to generate sections named based on the current section. In practice, the kernel puts all the fixups into a single section. The downside of this is that when sections are selectively discarded at link time (which in general may happen -- for example, Linux discards the "module exit" code for drivers which are built into the kernel and therefore never exit) there is no way to selectively discard the related fixup entries. Currently the only solution is to include all the module exit code in the image and discard it at run-time when the kernel boots. This is obviously wasteful. Attempting to discard that code at like time results in a link error, since fixups refer to the removed sections. Of course, the "fixup" macro could be given an extra parameter to name the containing section, but the macro can then no longer be called in a generic way: all the calls to that macro must be manually (and buggily) maintained to ensure that the referenced section name is correct, some object post-processing must be done before linking, and/or a tool must be created to implement the missing assembler functionality. Unfortunately, such solutions are likely to be too fragile or complex to make it upstream. It's interesting to note that the same problem will apply for any section containing ancilliary data for another section. In particular, it looks like either the ABI or the assembler has had to grow a special-case workaround for this in order to support exception unwind information sections generated by .fnstart ... .fnend in a sane way: the unwind information sections get called .ARM.ex{idx,tab} for .text, and .ARM.ex{idx,tab}<section> for any other section. As a consequence, link-time discarding can handle this information properly, but IMHO this is a bit of a cheat and admits the general need to create sections with names based transparently on those of other sections, without satisfying that need. .popsection is also an example of such a cheat: most other aspects of assmbler state still cannot be saved and restored. In general, it would be useful if gas supported some general reflective abilities: i.e., the ability to query the current assembler state (section, subsection, active instruction set, active macro mode, etc.) and/or the ability to wrap or hook existing pseudo-ops. For example, the above problem would almost certainly solvable using assembler macros (albeit painfully) if wrapper macros could be defined for the section manipulation directives (section, .text, .data, .bss, .pushsection, .popsection, .previous). However, supporting some magic macro parameters reflecting the assembler state would be a lot simpler. As an example of the kind of behaviour I think would be useful, the macro argument qualifier could be extended to allow macros to query the assembler state in a backwards-compatible way; something like: .macro fixup base_section:gas_current_section_name, old_altmacro:gas_macro_mode .altmacro LOCAL fixup_location fixup_location: .pushsection \base_section\().fixup .long 100\@b .popsection \old_altmacro .endm Existing assembler code will continue to work just fine with this approach. Note how this also enables a local label to be generated hygenically, by making it possible to save and restore the macro mode. Otherwise, .altmacro (and hence LOCAL) is hard to use safely, since the initial macro mode is unknown and can't be restored. Any thoughts / comments? Cheers. ---Dave

15 years

← Newer
1
2
3
4
5
6
7
8
9
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-dev January 2011