August 2012 - openSUSE ARM - openSUSE Mailing Lists

[opensuse-arm] armStoneA8: Failed to mount /dev
by Andreas Färber 02 Dec '12

02 Dec '12

Hello, On the armStoneA8 board, using NBoot V14 and U-Boot, I'm trying to boot the downstream 3.3.7 kernel (BSP V1.1) from SD with a LimeJeOS rootfs on SD. I had to reconfigure the kernel with CONFIG_LBDAF to mount the ext3[*] rootfs r/w. This is what I get now: [...] mmc0: new high speed SDHC card at address b368 IPv6 over IPv4 tunneling driver mmcblk0: mmc0:b368 NCard 7.48 GiB NET: Registered protocol family 17 can: controller area network core (rev 20090105 abi 8) mmcblk0: p1 NET: Registered protocol family 29 can: raw protocol (rev 20090105) can: broadcast manager protocol (rev 20090105 t) Registering the dns_resolver key type VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 2 s3c-rtc s3c64xx-rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) kjournald starting. Commit interval 5 seconds EXT3-fs (mmcblk0p1): using internal journal EXT3-fs (mmcblk0p1): recovery complete EXT3-fs (mmcblk0p1): mounted filesystem with ordered data mode VFS: Mounted root (ext3 filesystem) on device 179:1. Freeing init memory: 148K Failed to mount /dev: No such device Our rootfs definitely contains /dev, so what is this complaining about? Thanks, Andreas [*] U-Boot seemed to hang loading zImage from ext4. -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

3 6

[opensuse-arm] openSUSE 12.2 Beta/Warmup for Release Candidates
by Dirk Müller 13 Oct '12

13 Oct '12

Hi, over the weekend we've built 12.2 images and smoke-tested them on one board (Panda). The images are here: http://download.opensuse.org/repositories/openSUSE:/12.2:/ARM/images/ We plan to announce them later as Release Candiate 1. If you own a Pandaboard, BeagleBoard or an EfikaMX, please give them a try. the Vexpress ones are iirc also completely untested so far. Any feedback (positive or negative) is highly welcome. Thanks! Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

4 15

[opensuse-arm] build armv7l issues.
by Joop Boonen 31 Aug '12

31 Aug '12

Hi All, Dependency resolving isn't correct for home:worldcitizen:armv7l abootimg. It says abootimg-0.6-4.1.armv7hl.rpm requires: libblkid.so.1()(64bit) libblkid.so.1(BLKID_1.0)(64bit) libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) This should be non 64bit versions. Regards, Joop. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 1

[opensuse-arm] ARM mini-summit at kernel summit
by Alexander Graf 29 Aug '12

29 Aug '12

Hi guys, I managed to sneak into the arm mini summit at kernel summit. Here are a few notes I and others took throughout: - openSUSE got recognized for working on ARM - we should report bugs / problems to the respective MLs (panda crash, origen issues, ...) - generic zImage coming (one kernel for all SoCs), some technical / political roadblocks still but should show up soon'ish ----- etherpad notes ------- Info: https://sites.google.com/site/kernelsummit2012/workshops/arm Agenda: https://docs.google.com/spreadsheet/ccc?key=0AqglsllX3y3fdGoxY2lTc3RoTE9zTF… IRC: #armsummit on Freenode WIFI: "Linux Foundation", password "linux2012" Monday Secure Monitor APIs [WD] - OMAP calls: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=blob;f=ar… - Calxeda copied the SMC calls from OMAP - Samsung has reset and boot CPU calls:http://thread.gmane.org/gmane.linux.ports.arm.kernel/183607/http://th… - On hypervisor guests, HVC instead of SMC might be used, currently none on KVM, Xen uses paravirtualization - Some SMCs (e.g. l2 cache setup) might be called very early, necessary since it affects boot time - for any future SMCs we would like to avoid this, preferably push to device drivers, for some errata this might be unavoidable - Another level of APIs is used for secure software on OMAP (audio/video encryption paths) - We need to agree on which services exist and how to access them, atleast define them in the device tree - Also secure monitor calls can be redefined by dynamically-loaded software (e.g. "PPA") - these are not simply defined by the boot ROM - ux500 pushed all secure calls behind the TEE (Trusted Execution Environment) APIs: http://git.linaro.org/gitweb?p=bsp/st-ericsson/linux-3.0-ux500.git;a=tree;f… - We have two classes of problems: - Really early stuff that needs to be done before the MMU is turned on - Less early stuff that can be handled in a more generic way using device tree and all - Samsung suggested high-level abstraction: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/115785.ht… - Useful for everybody apart from OMAP? Stale Platform Deprecation [OJ] - Easy to build-test, but do the older platforms still boot? - Deprecate non-DT platforms after some time of inactivity? (1-2yrs?) - OMAP1 not a burden, mainline still actively used - Some (many) drivers still to be updated for DT... - Appended dtb blob to deal with legacy (non-DT) bootloaders - Tony to post list of OMAP board files marked for deprecation - Magnus to write git plugin to identify dead boards - In-tree defconfigs should be superset of options => shmobile needs to do this!! - mother of all defconfigs for single zImage - A patch to delete pnx-4008 is in the pipe - What to do with mach-bcmring? Broken for 2 years, but hobbyists now working on it. Horrible OS abstraction layer. Move to staging? - Dead platforms: mach-ks8695, mach-h720x, mach-l7200, mach-netx, mach-w90x900 - Long term deprecation: mach-ixp4xx, - mach-msm/<some board files> ...tricky. Virtualisation (Xen vs KVM) - Xen and KVM under active development for ARM, although both currently out-of-tree - Virtualisation extensions introduced in latest revision of ARMv7 (Cortex-A7, A15) * HYP mode (PL2), non-secure only, higher privilege level than svc (OS) but different system interface (translation, registers etc) * VMID to identify virtual machine (guest), used to tag TLBs and caches * Some peripherals virtualised in hardware (GIC, generic timers) * Second-stage translation: IPA => PA - KVM doesn't support nesting or CPU emulation (ie. guest CPU matches the real hardware) - Paul: What if HYP is used for other purposes (power management etc)? KVM: Tough. Mutual exclusion of privilege level (one or the other) - SMC interface should be used for power management / cluster switching instead of HVC: https://silver.arm.com/download/download.tm?pv=1303201 [free registration required...] - Boot protocol: kernel must be entered in hyp mode in order to make use of virtualisation extensions - Major performance issue is due to QEMU (probably due to the traps) ? possibility of creating a new subarch that uses virtio - may be best to simply strip down the Versatile Express platform - Development done on the kvm-arm mailing list - Magnus: what about virtualized IOMMU development? - Xen * no QEMU used, so no emulated hardware - only minimal set of devices supported (serial) - serial needed due to kernel assembly language code that touches UART * extensive use of DT - very concerned about ACPI on ARM - 50% of Xen codebase for x86 is ACPI parser - so big it does not fit into the hypervisor - ACPI generator also required; would be bloated - concerned also about DT format changes across kernel releases, since Xen is modifying this - Stephen: when will DT device bindings be declared as concrete & stable? - Olof/Arnd: once the main platforms are completely described in DT * bootloaders need modification to load hypervisor, etc. - grub for ARM? * two different Xen ports for ARM - one relies on the hypervisor instructions and so only works on A7/A15 - the other (Samsung) can run on older ARM cores * patch status: - hypervisor side almost fully upstream - Linux side: sent to the lists - devicetree patches sent to the DT mailing list * console is paravirtualized, rather than emulated hardware DMA Mapping [MS] - Many changes in last year, most of it merged for 3.5 - Conversion to dma_map_ops-based implementation Per-device mapping operations Support for DMA bounce w/ IOMMU Mixture of coherent and non-coherent devices - Core DMA mapping code is architecture-independent, but the integration layer is currently only implemented for ARM - not very difficult to add integration support for other architectures - CMA stuck in catch-22 situation of not being enabled / not being used * Could enable by default with warnings on allocation failures => see how many bug reports we receive * Convert carve-out (?) code to CMA for all platforms - i.mx?, OMAP, SH/Mobile, msm? - also get rid of GFP_DMA tricks for carve-outs - Use of highmem with CMA still needs work - Arnd: for callers who require mappings at specific virtual addresses, IOMMU API calls should be used - Stephen: needed because nVidia chips use address 0 for some boot-related code - Marek: our codec device requires firmware to be loaded at the lowest address, we just assume that the first allocated buffer for codec device gets the lowest address Hacking - Virtualisation (KVM / Xen guys) - randconfig - SMP ops - PMU (PaulW!) - Timer-based delay loop - Platform data testing - Common clock Tuesday arm-soc Process Review - Keeping everybody happy is impossible! - work split between arnd and ojn working well * Arnd dislikes rejecting patches * Late patches/pull requests also a problem - multiple branches vs single linear histor * Although some (Tegra) prefer the latter, can live with the current approach - Used to have many conflicts and dependendies, although this seems to have died down (why?) * Moving stuff to drivers/ may have helped - Signed-tags are `really nice' => allows some commentary for the merge * Most pull requests should use them [upgrade your git!] * http://git-blame.blogspot.com/2012/01/using-signed-tag-in-pull-requesyts.ht… - shmobile needs to follow same topic branch style as everyone else - Requirements for merging new platform code into arm-soc are somehow now coming from customers too (!) single zImage (again) - Work done to eliminate duplicate header files across platforms (mostly done) * Problem now device drivers including platform-specific headers (mach/*.h) * Including these headers is not something we *want* to do, but unfortunately it happens * Rename mach/* headers to include platform name as prefix (at least fixes the build) * rmk: break drivers including mach/ headers as incentive for people to fix their code * Magnus to extend checkpatch.pl to flag up code including these headers - Three remaining problematic headers: uncompress.h, gpio.h, timex.h - CLOCK_TICK_RATE problematic (timex.h) but not required for NO_HZ... * tlindgren: not required for platforms using clocksource/clockevents (? -- needs to be checked) * arnd: value is usually different and usually wrong - Rob: highbank, picoxcell, socfgpa, vexpress, (zynq) can all be built together without the header prefixing - Arnd: Samsung platforms huge problem with mach/ includes due to earlier work to reduce the amount of code - After header prefixing, drivers including mach files hit largely in mach-pxa, mach-sa1100 * To make it worse, many of these are common... * for plat- includes, omap the main one, although largely platform data - First cleanup pass should be straightforward * Remaining drivers can be annoted with depends on !ARM_MULTIPLATFORM * tlindgren can do first pass for omap in next week or so for drivers/ - Frameworks required for single zImage: common clock, sparse IRQ - Arnd will fix Marc's smp_ops patch series and re-post - Kconfig changes add new option `allow multiple platforms to be selected' * Architecture level {v4,v4T,v5}, {v6,v7} * Choice of SoC family with default selection * linker barfs if no machine selected (empty mach_info) * Choice of whether to expose individual board files in Kconfig left to the platform AArch64 - Catalin has a talk at LinuxCon to introduce the architecture in more depth (please attend!) - 2nd version of patches on LKML - DT-only, etc - Potentially ACPI coming from server folks / our friends in Washington - Initial platform code for very simple vexpress model - Aim as high as we can wrt late initialisation of platform code (as a module?) for the moment - timers, gic under drivers/ -- could also be used by arch/arm/ with ifdefs for the inline asm - device initialisation via DT as opposed to early hooks in the platform code - Push back on platforms with things like broken secure interface, etc * Olof: difficult if popular platform turns up with another OS but let's start from this position and see - Not clear when platform code will turn up from silicon vendors but not expected within the next year - v8 CPUs may be drop-in replacements for v7 CPUs on existing SoCs * Server guys more likely to start from scratch - Arnd: vexpress could be pushed as it's the only `hardware' available at the moment - Catalin: prefer to push only the core code initially, then cleanup SoC code prior to posting (use as an example) - Upstreaming: aiming to be in -next for 3.7-rc1 * Arnd: nah, just stick it in -next now and aim for 3.7 in mainline * Action: Arnd to Ack all the patches - personality discussion ongoing... * Arnd: just copy x86 * Catalin: no. <long discussion about PER_LINUX> - 2MB limit on size of dtb * Rob: 1MB limit for AArch32 already * Mark Brown: multi-megabyte co-efficient data for baseband processors could also come via device-tree (for example) * Turns out dtb header contains size information, so let's just use that and be done with it - DMA operations * Single set of ops, currently untested (model doesn't have any DMA-capable devices) * DMA32 likely to be required * swiotlb currently implemented but will be dropped for initial posting as untested - Stuff to share between arch/arm and arch/arm64 * dts files * perf * generic timer * gic * kvm / Xen [if/when merged] big.LITTLE - Linux Plumbers scheduling micro-conference - big.LITTLE => DVFS by other means * big cores and little cores, architecturally identical * Different approaches - Switching: switch between big and little cores transparently * Complications where cluster size not identical (i.e. more of one type than the other) - MP: kernel aware of all cores * Paul Turner has patches to track per-task load history => can be used to pick appropriate target core for a given task * v3 posted to LKML, will publish git tree * `more accurate load tracking at lower cost' - Morten Rasmussen has scheduler patches based on the above * Reduces wakeups on the big cores - spreading vs race-to-idle -- related discussion on LKML - tglx making CPU hotplug suck less * parking/unparking kthreads rather than killing/creating * worst-case scenario an order or magnitude faster with new approach * stop_machine() needs to be removed when CPU is offlined - topology static in header files, cache-level descriptions * need more for big.LITTLE description as micro-architecture radically different DMA Engine - no device-tree bindings * many things currently blocked on it * Patches from Jon Hunter - Other Patches from Vinod Koul * Arnd doesn't think good idea (the DT information in the client should be enough information for the DMAEngine driver) * The controversy is over the client not needing to know any of the information. - Discussing patches from Jon * The managing of these properties should be hidden within the DMA subsystem. The clients and DMA driver shouldn't have to deal with these properties. * (It should be like regulators, etc do it) * Propose binding uses integer flags field for describing things like direction * Mark Brown: `not exactly a readability triumph' * Suggestion: why not use a fixed index for read/write/ etc But, it is more complex. We want the request API to be simple. It can't be just an index. <Arnd lists bunch of implementation problems with DT> * Stephen Warren: we could use multiple properties? One property is hard to read. (Mark Brown argues we really need preprocessor support for dtc) Arnd suggests 'dmas' lists all of them, and another 'dma-names' that names them. (key,value) pairs like we do with irqs and regs. Arnd: having fixed property names allows something to scan the whole tree to find properties. If the property has a different name for each device, it is hard to find the dma properties. Stephen: You would have to scan for prefixes anyway, as well as regulator. The flags are only needed if we want to name the channels. Makes it more complex for devices with only one channel. Paul W: By forcing naming to be consistent, it helps with HW changesintroducing additional channels for existing IP. Consensus on having name. * Q: Which direction are 'read' and 'write'? A: Don't say read or write. :) See macros in dmaengine.h (enum dma_transfer_direction) [clarification from Vinod Koul - Intel] * What about a virtual channel manager that handles the mappings. Vinod: Drivers shouldn't be knowing about channels, etc. Argues for platform handling this. Allocating and filtering channels should be handled by generic code, not individual drivers. Alex

1 0

[opensuse-arm] Kernel for Gooseberry (Allwinner)
by Ciaran Farrell 24 Aug '12

24 Aug '12

Looks like somebody got Ubuntu working on the Gooseberry. Details and an apparently working image are here: https://www.miniand.com/forums/forums/2/topics/82 I'm currently downloading the image. The kernel is available here: http://dl.miniand.com/toby_corkindale/kernel_3.0.36_hf.tar.gz So I guess I could try to use an openSUSE rootfs with that for starters. Ciaran -- Ciaran Farrell, Attorney SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, DE GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 3

[opensuse-arm] Raspberrypi vom 12.10.2012
by Edgar Dombrowski 21 Aug '12

21 Aug '12

Hallo, Raspberry-Freunde Ich habe die obige OpenSuSeVersion installiert, schaffe es aber nicht - im Gegensatz zur Debian-Version - die deutsche Tastatur einzustellen. Wer kann mir helfen? Besten Dank Edgar aus München -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] [ANN] Embedded Linux workshop around Snowball board
by Andreas Färber 20 Aug '12

20 Aug '12

Hi, German company Hitex is offering several English-language workshops in Germany on Embedded Linux development with the Snowball board (in openSUSE: kernel-u8500 WIP by awafaa). What seems interesting is that they have an Early Bird pricing that ends TODAY (sorry for late notice!), which includes the board for - at a quick glance - lower than in the Calao Systems online shop. As usual, be sure to check such offers on your own though (e.g., VAT). http://www.hitex.de/quickstartworkshop Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1

[opensuse-arm] qemu-accel-armv5el
by Bernhard M. Wiedemann 20 Aug '12

20 Aug '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I had another look at our armv5 qemu-accel rpm and found a way to speed it up by another 50% (excl rpm time): https://build.opensuse.org/request/show/131138 using x86_64 rpm and rpmbuild are still broken: > rpm -U > /home/abuild/rpmbuild/RPMS/armv5tel/psmisc-22.16-0.armv5tel.rpm package psmisc-22.16-0.armv5tel is intended for a different architecture > rpmbuild Segmentation fault Tracing it with gdb is not very helpful either: process 21870 is executing new program: /dev/shm/build-root/emul/x86_64-for-arm/usr/bin/rpmbuild warning: Loadable section ".dynsym" outside of ELF segments warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIGSEGV, Segmentation fault. 0x00007f94c4b3b7d1 in ?? () (gdb) bt #0 0x00007f94c4b3b7d1 in ?? () #1 0x0000000000000001 in ?? () #2 0x0000000000000000 in ?? () Ciao Bernhard M. -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAvo1gACgkQSTYLOx37oWQ7SwCg1yujJP3kbu2PHJTqu6hDUTVt gHMAn2PzsZbLc5i7OMN9LvY4SpXJf5iC =EAU1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

2 1

[opensuse-arm] openSUSE ARM call
by Alexander Graf 16 Aug '12

16 Aug '12

Hi guys, I've set up this doodle to coordinate when would work for most folks: http://doodle.com/x6xk7z6gbqc8g2tr Please mark when you'd be available, so we can choose a nice time for the call. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0

[opensuse-arm] AArch64 toolchain
by Alexander Graf 16 Aug '12

16 Aug '12

Hi guys, I just realized that binutils patches for AArch64 (ARMv6 64-bit mode) already went out: http://sourceware.org/ml/binutils/2012-07/msg00269.html So it's about time to start hacking away on 1) initial cross-compilers to test compile easy programs 2) QEMU emulation Anyone interested in either of the two items above? :) Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-arm+owner(a)opensuse.org

1 0