[opensuse-arm] OpenSUSE 12.3 for armv7 on Mirabox fails
Standard, Mirabox is delivered with Debian. I would like to have it run OpenSUSE 12.3 for armV7 because I like openSUSE better :-) and it is natively compiled for armv7. Debian Squeeze (debian 6) is not (it is compiled for armv5 if I understand correctly, which sounds kind-of silly on an armv7 architecture). So I downloaded the opensuse image from http://download.opensuse.org/ports/armv7hl/distribution/12.3/images/openSUSE... and put it on my sdcard. I made 2 partitions, one FAT ca. 100MB for uImage (from the rootfs in the tbz file) and the remainder ext4 for the rootfilesystem. I hoped it would work right away but it did not. Right after the loading phase of uboot it stopped after the message "uncompressing linux...done, booting the kernel" and nothing was displayed. Then I thought I might use the precompiled uImage (from the debian distribution) together with the /lib/modules files from the debian distribution, so I copied /lib/modules from debian rootfs to the opensuse rootfs and the uImage to the FAT partition of my sdcard. It did boot but during the boot process it gave all strange errors and did not complete. uImage was from https://code.google.com/p/mirabox/downloads/detail?name=uImage-v2.6.35.9-gti-mirabox-v5-0-1-120924&can=2&q= and the debian rootfs from http://www.plugcomputer.org/405/us/mirabox/sources/rootfs/mira_fs-v5-0-1-120.... At some moment, I thought that might be logical because of the armv5 arch from debian and armv7 from opensuse. Then I tried running opensuse in a chroot on the mirabox with debian as a base, as described on http://en.opensuse.org/HCL:Chroot. That worked really wonderful. So that led me to the idea of compiling my own kernel on the mirabox when being in a chroot opensuse. I grabbed the kernel sources from http://www.plugcomputer.org/405/us/mirabox/sources/kernel/mira_kernel-v5-0-1..., did not modify the configuration in .config, ran "make", "make uImage", "make install", "make modules_install" and then booted opensuse with the resulting kernel. That did not work either. Right after the loading phase of uboot it stopped after the message "uncompressing linux...done, booting the kernel" and nothing was displayed. Then I tried compiling the kernel sources from opensuse (obtained from package "kernel-source" and "kernel-devel" via /sbin/yast2 in opensuse) by tweaking in the armada370 bits (including the same kernel .config file) from the kernel sources from the previous paragraph but it was too much tweaking and twiddling so I gave up on that. Why doesn't it work? What did I miss? Do I not understand the kernel building process? Any help is really appreciated. Thanks, Ge -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, not sure if someone answered you already. Le 23/03/2013 20:41, G. Heim a écrit :
Standard, Mirabox is delivered with Debian. I would like to have it run OpenSUSE 12.3 for armV7 because I like openSUSE better :-) and it is natively compiled for armv7. Debian Squeeze (debian 6) is not (it is compiled for armv5 if I understand correctly, which sounds kind-of silly on an armv7 architecture).
So I downloaded the opensuse image from http://download.opensuse.org/ports/armv7hl/distribution/12.3/images/openSUSE... and put it on my sdcard. I made 2 partitions, one FAT ca. 100MB for uImage (from the rootfs in the tbz file) and the remainder ext4 for the rootfilesystem. I hoped it would work right away but it did not. Right after the loading phase of uboot it stopped after the message "uncompressing linux...done, booting the kernel" and nothing was displayed.
You need a uImage built for your board.
Then I thought I might use the precompiled uImage (from the debian distribution) together with the /lib/modules files from the debian distribution, so I copied /lib/modules from debian rootfs to the opensuse rootfs and the uImage to the FAT partition of my sdcard. It did boot but during the boot process it gave all strange errors and did not complete. uImage was from https://code.google.com/p/mirabox/downloads/detail?name=uImage-v2.6.35.9-gti-mirabox-v5-0-1-120924&can=2&q= and the debian rootfs from http://www.plugcomputer.org/405/us/mirabox/sources/rootfs/mira_fs-v5-0-1-120.... At some moment, I thought that might be logical because of the armv5 arch from debian and armv7 from opensuse.
It may be due to armv5 vs armv7. But you could give us more details about the strange errors.
Then I tried running opensuse in a chroot on the mirabox with debian as a base, as described on http://en.opensuse.org/HCL:Chroot. That worked really wonderful.
Good. :)
So that led me to the idea of compiling my own kernel on the mirabox when being in a chroot opensuse. I grabbed the kernel sources from http://www.plugcomputer.org/405/us/mirabox/sources/kernel/mira_kernel-v5-0-1..., did not modify the configuration in .config, ran "make", "make uImage", "make install", "make modules_install" and then booted opensuse with the resulting kernel. That did not work either. Right after the loading phase of uboot it stopped after the message "uncompressing linux...done, booting the kernel" and nothing was displayed.
Could you access it via SSH maybe ? (To know if it is running but display nothing or if it is crashing).
Then I tried compiling the kernel sources from opensuse (obtained from package "kernel-source" and "kernel-devel" via /sbin/yast2 in opensuse) by tweaking in the armada370 bits (including the same kernel .config file) from the kernel sources from the previous paragraph but it was too much tweaking and twiddling so I gave up on that.
I do not know the upstream support for your board. Maybe mainline kernel (used by openSUSE) does not have a full support for your board.
Why doesn't it work? What did I miss? Do I not understand the kernel building process? Any help is really appreciated.
Maybe try to tune the .config with make menuconfig. You forgot to do a "make modules" before your "make modules_install" but the last one should trigger the first one if not manually called before. Moreover, if you install kernel stuff in chroot, then you cannot boot directly on it since it is in chroot, not in the real rootfs or FAT partition. Guillaume
Thanks, Ge -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Just a simple question :) What kind of Info do we expect to show up in the wiki ? Mike Veltman openSUSE Ambassador in Singapore -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 05/04/2013 11:37, Mike Veltman a écrit :
Just a simple question :)
What kind of Info do we expect to show up in the wiki ?
Here is the entry point for all informations about openSUSE on ARM: https://en.opensuse.org/Portal:ARM Are you looking for something specifically? Guillaume
Mike Veltman openSUSE Ambassador in Singapore
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 04/05/2013 05:44 PM, Guillaume Gardet wrote:
Le 05/04/2013 11:37, Mike Veltman a écrit :
Just a simple question :)
What kind of Info do we expect to show up in the wiki ?
Here is the entry point for all informations about openSUSE on ARM: https://en.opensuse.org/Portal:ARM
Are you looking for something specifically?
Guillaume
I was thinking about adding some stuff :)
Mike Veltman (Gwayne) openSUSE Ambassador in Singapore
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 05/04/2013 12:03, Mike Veltman a écrit :
On 04/05/2013 05:44 PM, Guillaume Gardet wrote:
Le 05/04/2013 11:37, Mike Veltman a écrit :
Just a simple question :)
What kind of Info do we expect to show up in the wiki ? Here is the entry point for all informations about openSUSE on ARM: https://en.opensuse.org/Portal:ARM
Are you looking for something specifically?
Guillaume
I was thinking about adding some stuff :)
I would say, we need to try all images (12.2, 12.3 and maybe current factory) on all boards and publish the current ARM HCL. We have already some things here and there but we still miss informations and others are outdated. Guillaume
Mike Veltman (Gwayne) openSUSE Ambassador in Singapore
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
I only have raspberry pi's here so I can not test the others. But when the base is ready I am willing to help with it. Thats why I mentioned it. We probably need a page with what we have in Images and supported boards. Basic tutorials and reverences to other websites etc etc. Well I am leaving now because my weekend has started. :-) On 04/05/2013 06:15 PM, Guillaume Gardet wrote:
Le 05/04/2013 12:03, Mike Veltman a écrit :
On 04/05/2013 05:44 PM, Guillaume Gardet wrote:
Le 05/04/2013 11:37, Mike Veltman a écrit :
Just a simple question :)
What kind of Info do we expect to show up in the wiki ? Here is the entry point for all informations about openSUSE on ARM: https://en.opensuse.org/Portal:ARM
Are you looking for something specifically?
Guillaume
I was thinking about adding some stuff :)
I would say, we need to try all images (12.2, 12.3 and maybe current factory) on all boards and publish the current ARM HCL. We have already some things here and there but we still miss informations and others are outdated.
Guillaume
Mike Veltman (Gwayne) openSUSE Ambassador in Singapore
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 05.04.2013 um 12:15 schrieb Guillaume Gardet <guillaume.gardet@free.fr>:
Le 05/04/2013 12:03, Mike Veltman a écrit :
On 04/05/2013 05:44 PM, Guillaume Gardet wrote:
Le 05/04/2013 11:37, Mike Veltman a écrit :
Just a simple question :)
What kind of Info do we expect to show up in the wiki ? Here is the entry point for all informations about openSUSE on ARM: https://en.opensuse.org/Portal:ARM
Are you looking for something specifically?
Guillaume I was thinking about adding some stuff :)
I would say, we need to try all images (12.2, 12.3 and maybe current factory) on all boards and publish the current ARM HCL. We have already some things here and there but we still miss informations and others are outdated.
For 12.3, we should rather work on fixing issues :) Alex
Guillaume
Mike Veltman (Gwayne) openSUSE Ambassador in Singapore
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Le 05/04/2013 13:22, Alexander Graf a écrit :
Am 05.04.2013 um 12:15 schrieb Guillaume Gardet <guillaume.gardet@free.fr>:
Le 05/04/2013 12:03, Mike Veltman a écrit :
On 04/05/2013 05:44 PM, Guillaume Gardet wrote:
Le 05/04/2013 11:37, Mike Veltman a écrit :
Just a simple question :)
What kind of Info do we expect to show up in the wiki ? Here is the entry point for all informations about openSUSE on ARM: https://en.opensuse.org/Portal:ARM
Are you looking for something specifically?
Guillaume I was thinking about adding some stuff :) I would say, we need to try all images (12.2, 12.3 and maybe current factory) on all boards and publish the current ARM HCL. We have already some things here and there but we still miss informations and others are outdated. For 12.3, we should rather work on fixing issues :)
Sure. But once main problems are fixed, we can tell people what is working out of the box or not. ;) Guillaume
Alex
Guillaume
Mike Veltman (Gwayne) openSUSE Ambassador in Singapore -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Dear Guillaume, Thanks for answering my question, I really appreciate that. I didn't got any response yet. Let me try to answer your questions. ----------------------------------------
Date: Fri, 5 Apr 2013 10:17:43 +0200 Subject: Re: [opensuse-arm] OpenSUSE 12.3 for armv7 on Mirabox fails
Then I thought I might use the precompiled uImage (from the debian distribution) together with the /lib/modules files from the debian distribution, so I copied /lib/modules from debian rootfs to the opensuse rootfs and the uImage to the FAT partition of my sdcard. It did boot but during the boot process it gave all strange errors and did not complete. [...] At some moment, I thought that might be logical because of the armv5 arch from debian and armv7 from opensuse.
It may be due to armv5 vs armv7. But you could give us more details about the strange errors.
I have attached a full bootlog below. Basically it reads uImage, then it boots, at some point it says: <27>systemd[1]: Failed to enumerate cgroup controllers: No such file or directory <30>systemd[1]: systemd 195 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ; suse) Welcome to [0;32mopenSUSE 12.3 (Dartmouth) (armv7hl)[0m! <27>systemd[1]: Failed to insert module 'autofs4' <30>systemd[1]: Set hostname to <linux.site>. <28>systemd[1]: CONFIG_CGROUPS was not set when your kernel was compiled. Systems without control groups are not supported. We will now sleep for 10s, and then continue boot-up. Expect breakage and please do not file bugs. Instead fix your kernel and enable CONFIG_CGROUPS. Consult http://0pointer.de/blog/projects/cgroups-vs-cgroups.html for more information. <28>systemd[1]: No control group support available, not creating root group. I don't get this error about this missing setting when I use the same uImage and modules in debian, then it continues until it gets to here: <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. etc, it continues like this in a loop
So that led me to the idea of compiling my own kernel on the mirabox when being in a chroot opensuse. I grabbed the kernel sources from http://www.plugcomputer.org [...]
Could you access it via SSH maybe ? (To know if it is running but display nothing or if it is crashing).
No, I also couldn't reach it pinging.
You forgot to do a "make modules" before your "make modules_install" but the last one should trigger the first one if not manually called before.
I think make modules has been triggered since I got modules in /lib/modules.
Moreover, if you install kernel stuff in chroot, then you cannot boot directly on it since it is in chroot, not in the real rootfs or FAT partition.
>Tag MAC [...]:4e:ad:f0 >Tag MAC [...]:4e:ad:f0 Memory policy: ECC disabled, Data cache writealloc Built 1 zonelists in Zone order, mobility grouping off. Total pages: 260096 Kernel command line: console=ttyS0,115200 root=/dev/sdb2 rootwait PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 512MB 296MB 216MB = 1024MB total Memory: 1032304k/1032304k available, 16272k reserved, 221184K highmem Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) DMA : 0xffc00000 - 0xffe00000 ( 2 MB) vmalloc : 0xf3000000 - 0xfa800000 ( 120 MB) lowmem : 0xc0000000 - 0xf2800000 ( 808 MB) pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) modules : 0xbf000000 - 0xbfe00000 ( 14 MB) .init : 0xc0008000 - 0xc0031000 ( 164 kB) .text : 0xc0031000 - 0xc06a5000 (6608 kB) .data : 0xc06a6000 - 0xc06d9d20 ( 208 kB) Hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. NR_IRQS:256 axp_time_init Calibrating delay loop... 1199.30 BogoMIPS (lpj=5996544)
Before I booted I moved the uImage to the boot partition (FAT) of my sd card. Do you have any hints how I can get this working? Can I help in some way? Thanks again, Ge. == now the full bootlog follows (from putty) reading uImage 3439396 bytes read ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-2.6.35.9 Created: 2012-08-24 2:13:39 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3439332 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.35.9 (root@localhost.localdomain) (gcc version 4.4.1 (sdk4.0-ct-ng-1.8.0) ) #12 Thu Aug 23 22:13:28 EDT 2012 CPU: Marvell PJ4Bv7 Processorÿÿ [561f5811] revision 1 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Marvell Armada-370 Using UBoot passing parameters structure pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok devtmpfs: initialized xor: measuring software checksum speed arm4regs : 1149.600 MB/sec 8regs : 814.400 MB/sec 32regs : 1145.200 MB/sec xor: using function: arm4regs (1149.600 MB/sec) NET: Registered protocol family 16 L0 cache Enabled Speculative Prefetch Disabled aurora_l2_init Aurora: Enabling L2 AuroraL2: System L2 cache support initialised Support IO coherency. CPU Interface ------------- SDRAM_CS0 ....base 00000000, size 512MB SDRAM_CS1 ....base 20000000, size 512MB SDRAM_CS2 ....disable SDRAM_CS3 ....disable DEVICE_CS0 ....base f2000000, size 32MB DEVICE_CS1 ....no such DEVICE_CS2 ....no such DEVICE_CS3 ....no such PEX0_MEM ....base e0000000, size 32MB PEX0_IO ....base f1100000, size 1MB PEX1_MEM ....base e2000000, size 32MB PEX1_IO ....base f1200000, size 1MB INTER_REGS ....base d0000000, size 1MB DMA_UART ....no such SPI_CS0 ....base f0000000, size 16MB SPI_CS1 ....no such SPI_CS2 ....no such SPI_CS3 ....no such SPI_CS4 ....no such SPI_CS5 ....no such SPI_CS6 ....no such SPI_CS7 ....no such BOOT_ROM_CS ....no such DEV_BOOTCS ....base f5000000, size 16MB PMU_SCRATCHPAD ....no such CRYPT0_ENG ....base c8010000, size 64KB Marvell Armada370 Board-- DB-88F6710-BP Soc: MV6710 A1 LE LSP version: Armada370_LSP_1.0.2_NQ_p10 Detected Tclk 200000000, SysClk 600000000, FabricClk 600000000 Armada-XP Performance Monitor Unit detected (Marvell ID)!!! hw perfevents: enabled with Marvell Sheeva-PJ4B PMU driver, 7 counters available Marvell USB EHCI Host controller #0: e0045600 Marvell USB EHCI Host controller #1: e0045400 pcie is init by steven pcie is init num= 2 PCI: bus0: Fast back to back transfers enabled PCI: bus1: Fast back to back transfers disabled pci 0000:01:01.0: BAR 0: assigned [mem 0xe2000000-0xe200ffff 64bit] pci 0000:01:01.0: BAR 0: set to [mem 0xe2000000-0xe200ffff 64bit] (PCI address [0xe2000000-0xe200ffff] pci 0000:01:01.0: BAR 2: assigned [mem 0xe2010000-0xe2010fff 64bit] pci 0000:01:01.0: BAR 2: set to [mem 0xe2010000-0xe2010fff 64bit] (PCI address [0xe2010000-0xe2010fff] pci 0000:01:01.0: BAR 4: assigned [mem 0xe2011000-0xe2011fff 64bit] pci 0000:01:01.0: BAR 4: set to [mem 0xe2011000-0xe2011fff 64bit] (PCI address [0xe2011000-0xe2011fff] pcie is init bio: create slab <bio-0> at 0 vgaarb: loaded SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb raid6: int32x1 121 MB/s raid6: int32x2 157 MB/s raid6: int32x4 198 MB/s raid6: int32x8 226 MB/s raid6: using algorithm int32x8 (226 MB/s) Advanced Linux Sound Architecture Driver Version 1.0.23. cfg80211: Calling CRDA to update world regulatory domain Switching to clocksource armada370_clocksource NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered UDP hash table entries: 512 (order: 1, 8192 bytes) UDP-Lite hash table entries: 512 (order: 1, 8192 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. PMU: registered new PMU device of type 0 NFP (FDB) init 16384 entries, 65536 bytes NFP (arp) init 16384 entries, 65536 bytes NFP (fib) init 16384 entries, 65536 bytes NFP (ct) init 16384 entries, 65536 bytes cesadev_init(c000ff24) mvCesaInit: channels=1, session=640, queue=64 Switched to NOHz mode on CPU #0 Armada XP hwmon thermal sensor initialized. Initializing Armada-XP CPU power management (DISABLED) highmem bounce pool size: 64 pages squashfs: version 4.0 (2009/01/31) Phillip Lougher JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. SGI XFS with security attributes, large block/inode numbers, no debug enabled msgmni has been set to 1584 alg: No test for stdrng (krng) async_tx: api initialized (async) io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) Initializing ths8200_init Initializing dove_adi9889_init Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xd0012000 (irq = 41) is a 16550A console [ttyS0] enabled brd: module loaded loop: module loaded sata_mv sata_mv.0: version 1.28 sata_mv sata_mv.0: cannot get clkdev sata_mv sata_mv.0: slots 32 ports 2 scsi0 : sata_mv scsi1 : sata_mv ata1: SATA max UDMA/133 irq 55 ata2: SATA max UDMA/133 irq 55 mvSFlashInit ERROR: Unknown SPI flash device! ERROR: sflash_probe - Failed to initialize the SFlash. armada-nand armada-nand.0: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC NAND device: Manufacturer ID: 0x2c, Chip ID: 0x38 (Micron NAND 1GiB 3,3V 8-bit) Creating 3 MTD partitions on "armada-nand": 0x000000000000-0x000000400000 : "UBoot" 0x000000400000-0x000000800000 : "UImage" 0x000000800000-0x000040000000 : "Root" 0 - Base 0x00000000 , Size = 0x20000000. 1 - Base 0x20000000 , Size = 0x20000000. 4 - Base 0xf2000000 , Size = 0x02000000. 8 - Base 0xe0000000 , Size = 0x02000000. 9 - Base 0xf1100000 , Size = 0x00100000. 10 - Base 0xe2000000 , Size = 0x02000000. 11 - Base 0xf1200000 , Size = 0x00100000. 12 - Base 0xd0000000 , Size = 0x00100000. 14 - Base 0xf0000000 , Size = 0x01000000. 23 - Base 0xf5000000 , Size = 0x01000000. 25 - Base 0xc8010000 , Size = 0x00010000. o 2 Giga ports supported o SKB recycle supported (Enabled) o NETA acceleration mode 1 o RX Queue support: 8 Queues * 128 Descriptors o TX Queue support: 8 Queues * 512 Descriptors o GSO supported o GRO supported o Receive checksum offload supported o Transmit checksum offload supported o Network Fast Processing (NFP) supported o NFP Bridging supported o NFP VLAN Processing supported o NFP Routing (FIB) supported o NFP NAT supported o Driver ERROR statistics enabled o Driver INFO statistics enabled o Driver DEBUG statistics enabled o Switch support enabled o Loading network interface(s) o Port 0 is connected to Linux netdevice giga p=0: mtu=1500, mac=e0027e78 o eth0, ifindex = 2, GbE port = 0 o Port 1 is connected to Linux netdevice giga p=1: mtu=1500, mac=e0027e78 o eth1, ifindex = 3, GbE port = 1 e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k4 e1000e: Copyright (c) 1999 - 2009 Intel Corporation. e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI e100: Copyright(c) 1999-2006 Intel Corporation sky2: driver version 1.28 usbcore: registered new interface driver zd1201 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci_marvell ehci_marvell.0: Marvell Orion EHCI ehci_marvell ehci_marvell.0: new USB bus registered, assigned bus number 1 ehci_marvell ehci_marvell.0: irq 45, io base 0xfbb50100 ehci_marvell ehci_marvell.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected ehci_marvell ehci_marvell.1: Marvell Orion EHCI ehci_marvell ehci_marvell.1: new USB bus registered, assigned bus number 2 ehci_marvell ehci_marvell.1: irq 46, io base 0xfbb51100 ehci_marvell ehci_marvell.1: USB 2.0 started, EHCI 1.00 hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected ata1: SATA link down (SStatus 0 SControl F300) usbcore: registered new interface driver usblp Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usbcore: registered new interface driver ums-datafab usbcore: registered new interface driver ums-freecom usbcore: registered new interface driver ums-jumpshot usbcore: registered new interface driver ums-sddr09 usbcore: registered new interface driver ums-sddr55 usbcore: registered new interface driver usbserial usbserial: USB Serial Driver core USB Serial support registered for cp210x usbcore: registered new interface driver cp210x cp210x: v0.09:Silicon Labs CP210x RS232 serial adaptor driver mice: PS/2 mouse device common for all mice rtc-mv rtc-mv: rtc core: registered rtc-mv as rtc0 i2c /dev entries driver Linux telephony interface: v1.00 Loading Marvell vpapi device Loading Marvell tdm device md: linear personality registered for level -1 md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 md: raid10 personality registered for level 10 md: raid6 personality registered for level 6 md: raid5 personality registered for level 5 md: raid4 personality registered for level 4 cpuidle: using governor ladder cpuidle: using governor menu mmc0: mvsdio driver initialized, lacking card detect (fall back to polling) mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver mv_xor mv_xor.0: Marvell XOR: ( xor ) mv_xor mv_xor.1: Marvell XOR: ( xor ) mmc0: new high speed SDIO card at address 0001 mv_xor mv_xor.2: Marvell XOR: ( cpy ) mv_xor mv_xor.3: Marvell XOR: ( fill cpy ) usbcore: registered new interface driver usbhid usbhid: USB HID core driver No device for DAI CS42L51 mv88fx_snd mv88fx_snd.0: cannot get clkdev cs42l51: chipid/revision = fb asoc: CS42L51 <-> mv88fx-i2s mapping ok ALSA device list: #0: mv_i2s (CS42L51) oprofile: using arm/mrvl_pj4b nf_conntrack version 0.5.0 (16129 buckets, 64516 max) ip_tables: (C) 2000-2006 Netfilter Core Team TCP cubic registered NET: Registered protocol family 10 ip6_tables: (C) 2000-2006 Netfilter Core Team IPv6 over IPv4 tunneling driver usb 1-1: new high speed USB device using ehci_marvell and address 2 NET: Registered protocol family 17 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com> All bugs added by David S. Miller <davem@redhat.com> VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 6 rtc-mv rtc-mv: setting system clock to 2013-04-06 14:22:22 UTC (1365258142) ata2: SATA link down (SStatus 0 SControl F300) md: Waiting for all devices to be available before autodetect md: If you don't use raid, use raid=noautodetect md: Autodetecting RAID arrays. md: Scanned 0 and added 0 devices. md: autorun ... md: ... autorun DONE. Waiting for root device /dev/sdb2... hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 1-1.1: new high speed USB device using ehci_marvell and address 3 usb-storage 1-1.1:1.0: Quirks match for vid 05e3 pid 0723: 8000 scsi2 : usb-storage 1-1.1:1.0 usb 1-1.2: new high speed USB device using ehci_marvell and address 4 usb-storage 1-1.2:1.0: Quirks match for vid 05e3 pid 0723: 8000 scsi3 : usb-storage 1-1.2:1.0 scsi 2:0:0:0: Direct-Access Generic STORAGE DEVICE 9451 PQ: 0 ANSI: 0 sd 2:0:0:0: [sda] Attached SCSI removable disk scsi 3:0:0:0: Direct-Access Generic STORAGE DEVICE 9451 PQ: 0 ANSI: 0 sd 3:0:0:0: [sdb] 15693824 512-byte logical blocks: (8.03 GB/7.48 GiB) sd 3:0:0:0: [sdb] Write Protect is off sd 3:0:0:0: [sdb] Assuming drive cache: write through sd 3:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sdb2 sd 3:0:0:0: [sdb] Assuming drive cache: write through sd 3:0:0:0: [sdb] Attached SCSI removable disk EXT3-fs (sdb2): error: couldn't mount because of unsupported optional features (240) EXT2-fs (sdb2): error: couldn't mount because of unsupported optional features (240) EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: (null) VFS: Mounted root (ext4 filesystem) on device 8:18. Freeing init memory: 164K <27>systemd[1]: Failed to enumerate cgroup controllers: No such file or directory <30>systemd[1]: systemd 195 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ; suse) Welcome to [0;32mopenSUSE 12.3 (Dartmouth) (armv7hl)[0m! <27>systemd[1]: Failed to insert module 'autofs4' <30>systemd[1]: Set hostname to <linux.site>. <28>systemd[1]: CONFIG_CGROUPS was not set when your kernel was compiled. Systems without control groups are not supported. We will now sleep for 10s, and then continue boot-up. Expect breakage and please do not file bugs. Instead fix your kernel and enable CONFIG_CGROUPS. Consult http://0pointer.de/blog/projects/cgroups-vs-cgroups.html for more information. <28>systemd[1]: No control group support available, not creating root group. <28>systemd[1]: Cannot add dependency job for unit xdm.service, ignoring: Unit xdm.service failed to load: No such file or directory. See system logs and 'systemctl status xdm.service' for details. <30>systemd[1]: Starting Collect Read-Ahead Data... Starting Collect Read-Ahead Data... <30>systemd[1]: Started Replay Read-Ahead Data. <30>systemd[1]: Starting Forward Password Requests to Wall Directory Watch. <27>systemd[500]: Failed at step OOM_ADJUST spawning /usr/lib/systemd/systemd-readahead: No such file or directory <30>systemd[1]: Started Forward Password Requests to Wall Directory Watch. <30>systemd[1]: Starting Remote File Systems. [[1;32m OK [0m] Reached target Remote File Systems. <30>systemd[1]: Reached target Remote File Systems. <30>systemd[1]: Starting Syslog Socket. [[1;32m OK [0m] Listening on Syslog Socket. <30>systemd[1]: Listening on Syslog Socket. <30>systemd[1]: Starting Delayed Shutdown Socket. [[1;32m OK [0m] Listening on Delayed Shutdown Socket. <30>systemd[1]: Listening on Delayed Shutdown Socket. <30>systemd[1]: Starting /dev/initctl Compatibility Named Pipe. [[1;32m OK [0m] Listening on /dev/initctl Compatibility Named Pipe. <30>systemd[1]: Listening on /dev/initctl Compatibility Named Pipe. <30>systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. <30>systemd[1]: Starting udev Kernel Socket. [[1;32m OK [0m] Listening on udev Kernel Socket. <30>systemd[1]: Listening on udev Kernel Socket. <30>systemd[1]: Starting udev Control Socket. [[1;32m OK [0m] Listening on udev Control Socket. <30>systemd[1]: Listening on udev Control Socket. <30>systemd[1]: Starting Encrypted Volumes. [[1;32m OK [0m] Reached target Encrypted Volumes. <30>systemd[1]: Reached target Encrypted Volumes. <30>systemd[1]: Starting Swap. [[1;32m OK [0m] Reached target Swap. <30>systemd[1]: Reached target Swap. <30>systemd[1]: Starting Journal Socket. [[1;32m OK [0m] Listening on Journal Socket. <30>systemd[1]: Listening on Journal Socket. <30>systemd[1]: Mounted POSIX Message Queue File System. <30>systemd[1]: Mounted Huge Pages File System. <30>systemd[1]: Mounted Debug File System. <30>systemd[1]: Starting Create dynamic rule for /dev/root link... Starting Create dynamic rule for /dev/root link... <30>systemd[1]: Starting Journal Service... Starting Journal Service... [[1;32m OK [0m] Started Journal Service. <30>systemd[1]: Started Journal Service. <29>systemd[1]: systemd-readahead-collect.service: main process exited, code=exited, status=206/OOM_ADJUST [[1;32m OK [0m] Started Collect Read-Ahead Data. <30>systemd[1]: Started Collect Read-Ahead Data. <30>systemd[1]: Started Set Up Additional Binary Formats. <30>systemd[1]: Starting Load Kernel Modules... Starting Load Kernel Modules... <30>systemd[1]: Started Setup Virtual Console. <30>systemd[1]: Starting udev Coldplug all Devices... Starting udev Coldplug all Devices... <30>systemd[1]: Started File System Check on Root Device. <30>systemd[1]: Starting Remount Root and Kernel File Systems... Starting Remount Root and Kernel File Systems... [[1;32m OK [0m] Started Load Kernel Modules. Starting Apply Kernel Variables... [[1;32m OK [0m] Started Remount Root and Kernel File Systems. [[1;32m OK [0m] Started Apply Kernel Variables. [[1;32m OK [0m] Started udev Coldplug all Devices. Starting Show Plymouth Boot Screen... Starting Load Random Seed... [[1;32m OK [0m] Started Create dynamic rule for /dev/root link. Starting udev Kernel Device Manager... <30>systemd[1]: systemd-udevd.service holdoff time over, scheduling restart. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. [etc, it continues like this in a loop] -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 06.04.2013, at 16:44, G. Heim wrote:
Dear Guillaume,
Thanks for answering my question, I really appreciate that. I didn't got any response yet. Let me try to answer your questions.
----------------------------------------
Date: Fri, 5 Apr 2013 10:17:43 +0200 Subject: Re: [opensuse-arm] OpenSUSE 12.3 for armv7 on Mirabox fails
Then I thought I might use the precompiled uImage (from the debian distribution) together with the /lib/modules files from the debian distribution, so I copied /lib/modules from debian rootfs to the opensuse rootfs and the uImage to the FAT partition of my sdcard. It did boot but during the boot process it gave all strange errors and did not complete. [...] At some moment, I thought that might be logical because of the armv5 arch from debian and armv7 from opensuse.
It may be due to armv5 vs armv7. But you could give us more details about the strange errors.
I have attached a full bootlog below. Basically it reads uImage, then it boots, at some point it says:
<27>systemd[1]: Failed to enumerate cgroup controllers: No such file or directory <30>systemd[1]: systemd 195 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ; suse)
Welcome to [0;32mopenSUSE 12.3 (Dartmouth) (armv7hl)[0m!
<27>systemd[1]: Failed to insert module 'autofs4' <30>systemd[1]: Set hostname to <linux.site>. <28>systemd[1]: CONFIG_CGROUPS was not set when your kernel was compiled. Systems without control groups are not supported. We will now sleep for 10s, and then continue boot-up. Expect breakage and please do not file bugs. Instead fix your kernel and enable CONFIG_CGROUPS. Consult http://0pointer.de/blog/projects/cgroups-vs-cgroups.html for more information. <28>systemd[1]: No control group support available, not creating root group.
I don't get this error about this missing setting when I use the same uImage and modules in debian, then it continues until it gets to here:
<28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start.
etc, it continues like this in a loop
CGROUPS are a hard requirement on 12.3. Please enable them in your kernel config :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Alex, Thanks for your fast reply. ----------------------------------------
Subject: Re: [opensuse-arm] OpenSUSE 12.3 for armv7 on Mirabox fails Date: Sat, 6 Apr 2013 17:26:57 +0200
On 06.04.2013, at 16:44, G. Heim wrote:
I have attached a full bootlog below. Basically it reads uImage, then it boots, at some point it says:
<27>systemd[1]: Failed to enumerate cgroup controllers: No such file or directory <30>systemd[1]: systemd 195 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ; suse)
Welcome to [0;32mopenSUSE 12.3 (Dartmouth) (armv7hl)[0m!
<27>systemd[1]: Failed to insert module 'autofs4' <30>systemd[1]: Set hostname to <linux.site>. <28>systemd[1]: CONFIG_CGROUPS was not set when your kernel was compiled. Systems without control groups are not supported. We will now sleep for 10s, and then continue boot-up. Expect breakage and please do not file bugs. Instead fix your kernel and enable CONFIG_CGROUPS. Consult http://0pointer.de/blog/projects/cgroups-vs-cgroups.html for more information. <28>systemd[1]: No control group support available, not creating root group.
I don't get this error about this missing setting when I use the same uImage and modules in debian, [...]
CGROUPS are a hard requirement on 12.3. Please enable them in your kernel config :).
Ah. But I don't understand, doesn't debian need it? It is the same uImage as I use for debian which doesn't complain. Or is this opensuse specific? If it is, do you think I can compile uImage using debian with CGROUPS set and then using that uImage & modules for opensuse? Thanks again, Ge -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 06.04.2013, at 17:32, G. Heim wrote:
Hi Alex,
Thanks for your fast reply.
----------------------------------------
Subject: Re: [opensuse-arm] OpenSUSE 12.3 for armv7 on Mirabox fails Date: Sat, 6 Apr 2013 17:26:57 +0200
On 06.04.2013, at 16:44, G. Heim wrote:
I have attached a full bootlog below. Basically it reads uImage, then it boots, at some point it says:
<27>systemd[1]: Failed to enumerate cgroup controllers: No such file or directory <30>systemd[1]: systemd 195 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ; suse)
Welcome to [0;32mopenSUSE 12.3 (Dartmouth) (armv7hl)[0m!
<27>systemd[1]: Failed to insert module 'autofs4' <30>systemd[1]: Set hostname to <linux.site>. <28>systemd[1]: CONFIG_CGROUPS was not set when your kernel was compiled. Systems without control groups are not supported. We will now sleep for 10s, and then continue boot-up. Expect breakage and please do not file bugs. Instead fix your kernel and enable CONFIG_CGROUPS. Consult http://0pointer.de/blog/projects/cgroups-vs-cgroups.html for more information. <28>systemd[1]: No control group support available, not creating root group.
I don't get this error about this missing setting when I use the same uImage and modules in debian, [...]
CGROUPS are a hard requirement on 12.3. Please enable them in your kernel config :).
Ah. But I don't understand, doesn't debian need it? It is the same uImage as I use for debian which doesn't complain. Or is this opensuse specific?
Maybe openSUSE simply uses a newer version of systemd? Or it compiles it with different options :). But I've ran into the same issue on a different board.
If it is, do you think I can compile uImage using debian with CGROUPS set and then using that uImage & modules for opensuse?
Yes, definitely! Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Alex, Thanks again. I did a compile of the debian kernel on my mirabox, then I booted with the modules and uImage. The full bootlog is below. As you can see, the first message about "systemd[1]: CONFIG_CGROUPS was not set" has disappeared, but the line <28>systemd[1]: No control group support available, not creating root group. is still there. I used these CGROUP related kernel compile options: CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y # CONFIG_CPUSETS is not set CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y # CONFIG_CGROUP_MEM_RES_CTLR is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set Also, opensuse gets in an loop with <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. [etc, continuing] Any hints how to continue are very much appreciated. Thanks again, Ge ----------------------------------------
Subject: Re: [opensuse-arm] OpenSUSE 12.3 for armv7 on Mirabox fails Date: Sat, 6 Apr 2013 17:40:03 +0200
On 06.04.2013, at 17:32, G. Heim wrote:
Hi Alex,
Thanks for your fast reply.
----------------------------------------
Subject: Re: [opensuse-arm] OpenSUSE 12.3 for armv7 on Mirabox fails Date: Sat, 6 Apr 2013 17:26:57 +0200
On 06.04.2013, at 16:44, G. Heim wrote:
I have attached a full bootlog below. Basically it reads uImage, then it boots, at some point it says:
<27>systemd[1]: Failed to enumerate cgroup controllers: No such file or directory <30>systemd[1]: systemd 195 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ; suse)
Welcome to [0;32mopenSUSE 12.3 (Dartmouth) (armv7hl)[0m!
<27>systemd[1]: Failed to insert module 'autofs4' <30>systemd[1]: Set hostname to <linux.site>. <28>systemd[1]: CONFIG_CGROUPS was not set when your kernel was compiled. Systems without control groups are not supported. We will now sleep for 10s, and then continue boot-up. Expect breakage and please do not file bugs. Instead fix your kernel and enable CONFIG_CGROUPS. Consult http://0pointer.de/blog/projects/cgroups-vs-cgroups.html for more information. <28>systemd[1]: No control group support available, not creating root group.
I don't get this error about this missing setting when I use the same uImage and modules in debian, [...]
CGROUPS are a hard requirement on 12.3. Please enable them in your kernel config :).
Ah. But I don't understand, doesn't debian need it? It is the same uImage as I use for debian which doesn't complain. Or is this opensuse specific?
Maybe openSUSE simply uses a newer version of systemd? Or it compiles it with different options :). But I've ran into the same issue on a different board.
If it is, do you think I can compile uImage using debian with CGROUPS set and then using that uImage & modules for opensuse?
Yes, definitely!
Alex
>Tag MAC [...]:4e:ad:f0 >Tag MAC [...]:4e:ad:f0 Memory policy: ECC disabled, Data cache writealloc Built 1 zonelists in Zone order, mobility grouping off. Total pages: 260096 Kernel command line: console=ttyS0,115200 root=/dev/sdb2 rootwait PID hash table entries: 4096 (order: 2, 16384 bytes) Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 512MB 296MB 216MB = 1024MB total Memory: 1032152k/1032152k available, 16424k reserved, 221184K highmem Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) DMA : 0xffc00000 - 0xffe00000 ( 2 MB) vmalloc : 0xf3000000 - 0xfa800000 ( 120 MB) lowmem : 0xc0000000 - 0xf2800000 ( 808 MB) pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) modules : 0xbf000000 - 0xbfe00000 ( 14 MB) .init : 0xc0008000 - 0xc0032000 ( 168 kB) .text : 0xc0032000 - 0xc06c9000 (6748 kB) .data : 0xc06ca000 - 0xc06fec00 ( 211 kB) Hierarchical RCU implementation. RCU-based detection of stalled CPUs is disabled. Verbose stalled-CPUs detection is disabled. NR_IRQS:256 axp_time_init Calibrating delay loop... 1199.30 BogoMIPS (lpj=5996544)
----- full bootlog follows reading uImage 3586324 bytes read ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-2.6.35.9 Created: 2013-04-06 20:39:30 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3586260 Bytes = 3.4 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Initializing cgroup subsys cpu Linux version 2.6.35.9 (AVALON ik@anfortas) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 Sat Apr 6 22:25:10 CEST 2013 CPU: Marvell PJ4Bv7 Processorÿÿ [561f5811] revision 1 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Marvell Armada-370 Using UBoot passing parameters structure pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 Initializing cgroup subsys ns Initializing cgroup subsys cpuacct Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys blkio CPU: Testing write buffer coherency: ok devtmpfs: initialized xor: measuring software checksum speed arm4regs : 1150.800 MB/sec 8regs : 899.600 MB/sec 32regs : 1115.600 MB/sec xor: using function: arm4regs (1150.800 MB/sec) NET: Registered protocol family 16 L0 cache Enabled Speculative Prefetch Disabled aurora_l2_init Aurora: Enabling L2 AuroraL2: System L2 cache support initialised Support IO coherency. CPU Interface ------------- SDRAM_CS0 ....base 00000000, size 512MB SDRAM_CS1 ....base 20000000, size 512MB SDRAM_CS2 ....disable SDRAM_CS3 ....disable DEVICE_CS0 ....base f2000000, size 32MB DEVICE_CS1 ....no such DEVICE_CS2 ....no such DEVICE_CS3 ....no such PEX0_MEM ....base e0000000, size 32MB PEX0_IO ....base f1100000, size 1MB PEX1_MEM ....base e2000000, size 32MB PEX1_IO ....base f1200000, size 1MB INTER_REGS ....base d0000000, size 1MB DMA_UART ....no such SPI_CS0 ....base f0000000, size 16MB SPI_CS1 ....no such SPI_CS2 ....no such SPI_CS3 ....no such SPI_CS4 ....no such SPI_CS5 ....no such SPI_CS6 ....no such SPI_CS7 ....no such BOOT_ROM_CS ....no such DEV_BOOTCS ....base f5000000, size 16MB PMU_SCRATCHPAD ....no such CRYPT0_ENG ....base c8010000, size 64KB Marvell Armada370 Board-- DB-88F6710-BP Soc: MV6710 A1 LE LSP version: Armada370_LSP_1.0.2_NQ_p10 Detected Tclk 200000000, SysClk 600000000, FabricClk 600000000 Armada-XP Performance Monitor Unit detected (Marvell ID)!!! hw perfevents: enabled with Marvell Sheeva-PJ4B PMU driver, 7 counters available Marvell USB EHCI Host controller #0: e0046600 Marvell USB EHCI Host controller #1: e0046400 pcie is init by steven pcie is init num= 2 PCI: bus0: Fast back to back transfers enabled PCI: bus1: Fast back to back transfers disabled pci 0000:01:01.0: BAR 0: assigned [mem 0xe2000000-0xe200ffff 64bit] pci 0000:01:01.0: BAR 0: set to [mem 0xe2000000-0xe200ffff 64bit] (PCI address [0xe2000000-0xe200ffff] pci 0000:01:01.0: BAR 2: assigned [mem 0xe2010000-0xe2010fff 64bit] pci 0000:01:01.0: BAR 2: set to [mem 0xe2010000-0xe2010fff 64bit] (PCI address [0xe2010000-0xe2010fff] pci 0000:01:01.0: BAR 4: assigned [mem 0xe2011000-0xe2011fff 64bit] pci 0000:01:01.0: BAR 4: set to [mem 0xe2011000-0xe2011fff 64bit] (PCI address [0xe2011000-0xe2011fff] pcie is init bio: create slab <bio-0> at 0 vgaarb: loaded SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb raid6: int32x1 126 MB/s raid6: int32x2 174 MB/s raid6: int32x4 155 MB/s raid6: int32x8 151 MB/s raid6: using algorithm int32x2 (174 MB/s) Advanced Linux Sound Architecture Driver Version 1.0.23. cfg80211: Calling CRDA to update world regulatory domain Switching to clocksource armada370_clocksource NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered UDP hash table entries: 512 (order: 1, 8192 bytes) UDP-Lite hash table entries: 512 (order: 1, 8192 bytes) NET: Registered protocol family 1 RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. PMU: registered new PMU device of type 0 NFP (FDB) init 16384 entries, 65536 bytes NFP (arp) init 16384 entries, 65536 bytes NFP (fib) init 16384 entries, 65536 bytes NFP (ct) init 16384 entries, 65536 bytes cesadev_init(c0010168) mvCesaInit: channels=1, session=640, queue=64 Switched to NOHz mode on CPU #0 Armada XP hwmon thermal sensor initialized. Initializing Armada-XP CPU power management (DISABLED) highmem bounce pool size: 64 pages squashfs: version 4.0 (2009/01/31) Phillip Lougher JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. SGI XFS with security attributes, large block/inode numbers, no debug enabled msgmni has been set to 1583 alg: No test for stdrng (krng) async_tx: api initialized (async) io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) Initializing ths8200_init Initializing dove_adi9889_init Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xd0012000 (irq = 41) is a 16550A console [ttyS0] enabled brd: module loaded loop: module loaded sata_mv sata_mv.0: version 1.28 sata_mv sata_mv.0: cannot get clkdev sata_mv sata_mv.0: slots 32 ports 2 scsi0 : sata_mv scsi1 : sata_mv ata1: SATA max UDMA/133 irq 55 ata2: SATA max UDMA/133 irq 55 mvSFlashInit ERROR: Unknown SPI flash device! ERROR: sflash_probe - Failed to initialize the SFlash. armada-nand armada-nand.0: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC NAND device: Manufacturer ID: 0x2c, Chip ID: 0x38 (Micron NAND 1GiB 3,3V 8-bit) Creating 3 MTD partitions on "armada-nand": 0x000000000000-0x000000600000 : "UBoot" 0x000000600000-0x000000a00000 : "UImage" 0x000000a00000-0x000040000000 : "Root" 0 - Base 0x00000000 , Size = 0x20000000. 1 - Base 0x20000000 , Size = 0x20000000. 4 - Base 0xf2000000 , Size = 0x02000000. 8 - Base 0xe0000000 , Size = 0x02000000. 9 - Base 0xf1100000 , Size = 0x00100000. 10 - Base 0xe2000000 , Size = 0x02000000. 11 - Base 0xf1200000 , Size = 0x00100000. 12 - Base 0xd0000000 , Size = 0x00100000. 14 - Base 0xf0000000 , Size = 0x01000000. 23 - Base 0xf5000000 , Size = 0x01000000. 25 - Base 0xc8010000 , Size = 0x00010000. o 2 Giga ports supported o SKB recycle supported (Enabled) o NETA acceleration mode 1 o RX Queue support: 8 Queues * 128 Descriptors o TX Queue support: 8 Queues * 512 Descriptors o GSO supported o GRO supported o Receive checksum offload supported o Transmit checksum offload supported o Network Fast Processing (NFP) supported o NFP Bridging supported o NFP VLAN Processing supported o NFP Routing (FIB) supported o NFP NAT supported o Driver ERROR statistics enabled o Driver INFO statistics enabled o Driver DEBUG statistics enabled o Switch support enabled o Loading network interface(s) o Port 0 is connected to Linux netdevice giga p=0: mtu=1500, mac=e0027e68 o eth0, ifindex = 2, GbE port = 0 o Port 1 is connected to Linux netdevice giga p=1: mtu=1500, mac=e0027e68 o eth1, ifindex = 3, GbE port = 1 e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k4 e1000e: Copyright (c) 1999 - 2009 Intel Corporation. e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI e100: Copyright(c) 1999-2006 Intel Corporation sky2: driver version 1.28 usbcore: registered new interface driver zd1201 ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci_marvell ehci_marvell.0: Marvell Orion EHCI ehci_marvell ehci_marvell.0: new USB bus registered, assigned bus number 1 ehci_marvell ehci_marvell.0: irq 45, io base 0xfbb50100 ehci_marvell ehci_marvell.0: USB 2.0 started, EHCI 1.00 hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected ehci_marvell ehci_marvell.1: Marvell Orion EHCI ehci_marvell ehci_marvell.1: new USB bus registered, assigned bus number 2 ehci_marvell ehci_marvell.1: irq 46, io base 0xfbb51100 ehci_marvell ehci_marvell.1: USB 2.0 started, EHCI 1.00 hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected ata1: SATA link down (SStatus 0 SControl F300) usbcore: registered new interface driver usblp Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usbcore: registered new interface driver ums-datafab usbcore: registered new interface driver ums-freecom usbcore: registered new interface driver ums-jumpshot usbcore: registered new interface driver ums-sddr09 usbcore: registered new interface driver ums-sddr55 mice: PS/2 mouse device common for all mice rtc-mv rtc-mv: rtc core: registered rtc-mv as rtc0 i2c /dev entries driver Linux telephony interface: v1.00 Loading Marvell vpapi device Loading Marvell tdm device md: linear personality registered for level -1 md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 md: raid10 personality registered for level 10 md: raid6 personality registered for level 6 md: raid5 personality registered for level 5 md: raid4 personality registered for level 4 cpuidle: using governor ladder cpuidle: using governor menu mmc0: mvsdio driver initialized, lacking card detect (fall back to polling) mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver mv_xor mv_xor.0: Marvell XOR: ( xor ) mv_xor mv_xor.1: Marvell XOR: ( xor ) mmc0: new high speed SDIO card at address 0001 mv_xor mv_xor.2: Marvell XOR: ( cpy ) mv_xor mv_xor.3: Marvell XOR: ( fill cpy ) usbcore: registered new interface driver usbhid usbhid: USB HID core driver No device for DAI CS42L51 mv88fx_snd mv88fx_snd.0: cannot get clkdev cs42l51: chipid/revision = fb asoc: CS42L51 <-> mv88fx-i2s mapping ok ALSA device list: #0: mv_i2s (CS42L51) oprofile: using arm/mrvl_pj4b nf_conntrack version 0.5.0 (16127 buckets, 64508 max) ip_tables: (C) 2000-2006 Netfilter Core Team TCP cubic registered NET: Registered protocol family 10 ip6_tables: (C) 2000-2006 Netfilter Core Team IPv6 over IPv4 tunneling driver usb 1-1: new high speed USB device using ehci_marvell and address 2 NET: Registered protocol family 17 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com> All bugs added by David S. Miller <davem@redhat.com> VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 6 rtc-mv rtc-mv: setting system clock to 2013-04-06 20:44:46 UTC (1365281086) ata2: SATA link down (SStatus 0 SControl F300) md: Waiting for all devices to be available before autodetect md: If you don't use raid, use raid=noautodetect md: Autodetecting RAID arrays. md: Scanned 0 and added 0 devices. md: autorun ... md: ... autorun DONE. Waiting for root device /dev/sdb2... hub 1-1:1.0: USB hub found hub 1-1:1.0: 4 ports detected usb 1-1.1: new high speed USB device using ehci_marvell and address 3 usb-storage 1-1.1:1.0: Quirks match for vid 05e3 pid 0723: 8000 scsi2 : usb-storage 1-1.1:1.0 usb 1-1.2: new high speed USB device using ehci_marvell and address 4 usb-storage 1-1.2:1.0: Quirks match for vid 05e3 pid 0723: 8000 scsi3 : usb-storage 1-1.2:1.0 scsi 2:0:0:0: Direct-Access Generic STORAGE DEVICE 9451 PQ: 0 ANSI: 0 sd 2:0:0:0: [sda] Attached SCSI removable disk scsi 3:0:0:0: Direct-Access Generic STORAGE DEVICE 9451 PQ: 0 ANSI: 0 sd 3:0:0:0: [sdb] 15693824 512-byte logical blocks: (8.03 GB/7.48 GiB) sd 3:0:0:0: [sdb] Write Protect is off sd 3:0:0:0: [sdb] Assuming drive cache: write through sd 3:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 sdb2 sd 3:0:0:0: [sdb] Assuming drive cache: write through sd 3:0:0:0: [sdb] Attached SCSI removable disk EXT3-fs (sdb2): error: couldn't mount because of unsupported optional features (240) EXT2-fs (sdb2): error: couldn't mount because of unsupported optional features (240) EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: (null) VFS: Mounted root (ext4 filesystem) on device 8:18. Freeing init memory: 168K <30>systemd[1]: systemd 195 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ; suse) Welcome to [0;32mopenSUSE 12.3 (Dartmouth) (armv7hl)[0m! <27>systemd[1]: Failed to insert module 'autofs4' <30>systemd[1]: Set hostname to <linux.site>. <28>systemd[1]: No control group support available, not creating root group. <28>systemd[1]: Cannot add dependency job for unit xdm.service, ignoring: Unit xdm.service failed to load: No such file or directory. See system logs and 'systemctl status xdm.service' for details. <30>systemd[1]: Starting Collect Read-Ahead Data... Starting Collect Read-Ahead Data... <30>systemd[1]: Started Replay Read-Ahead Data. <30>systemd[1]: Starting Forward Password Requests to Wall Directory Watch. <27>systemd[492]: Failed at step OOM_ADJUST spawning /usr/lib/systemd/systemd-readahead: No such file or directory <30>systemd[1]: Started Forward Password Requests to Wall Directory Watch. <30>systemd[1]: Starting Remote File Systems. [[1;32m OK [0m] Reached target Remote File Systems. <30>systemd[1]: Reached target Remote File Systems. <30>systemd[1]: Starting Syslog Socket. [[1;32m OK [0m] Listening on Syslog Socket. <30>systemd[1]: Listening on Syslog Socket. <30>systemd[1]: Starting Delayed Shutdown Socket. [[1;32m OK [0m] Listening on Delayed Shutdown Socket. <30>systemd[1]: Listening on Delayed Shutdown Socket. <30>systemd[1]: Starting /dev/initctl Compatibility Named Pipe. [[1;32m OK [0m] Listening on /dev/initctl Compatibility Named Pipe. <30>systemd[1]: Listening on /dev/initctl Compatibility Named Pipe. <30>systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. <30>systemd[1]: Starting udev Kernel Socket. [[1;32m OK [0m] Listening on udev Kernel Socket. <30>systemd[1]: Listening on udev Kernel Socket. <30>systemd[1]: Starting udev Control Socket. [[1;32m OK [0m] Listening on udev Control Socket. <30>systemd[1]: Listening on udev Control Socket. <30>systemd[1]: Starting Encrypted Volumes. [[1;32m OK [0m] Reached target Encrypted Volumes. <30>systemd[1]: Reached target Encrypted Volumes. <30>systemd[1]: Starting Swap. [[1;32m OK [0m] Reached target Swap. <30>systemd[1]: Reached target Swap. <30>systemd[1]: Starting Journal Socket. [[1;32m OK [0m] Listening on Journal Socket. <30>systemd[1]: Listening on Journal Socket. <30>systemd[1]: Mounted POSIX Message Queue File System. <30>systemd[1]: Mounted Huge Pages File System. <30>systemd[1]: Mounted Debug File System. <30>systemd[1]: Starting Create dynamic rule for /dev/root link... Starting Create dynamic rule for /dev/root link... <30>systemd[1]: Starting Journal Service... Starting Journal Service... [[1;32m OK [0m] Started Journal Service. <30>systemd[1]: Started Journal Service. <29>systemd[1]: systemd-readahead-collect.service: main process exited, code=exited, status=206/OOM_ADJUST [[1;32m OK [0m] Started Collect Read-Ahead Data. <30>systemd[1]: Started Collect Read-Ahead Data. <30>systemd[1]: Started Set Up Additional Binary Formats. <30>systemd[1]: Starting Load Kernel Modules... Starting Load Kernel Modules... <30>systemd[1]: Started Setup Virtual Console. <30>systemd[1]: Starting udev Coldplug all Devices... Starting udev Coldplug all Devices... <30>systemd[1]: Started File System Check on Root Device. <30>systemd[1]: Starting Remount Root and Kernel File Systems... Starting Remount Root and Kernel File Systems... [[1;32m OK [0m] Started Load Kernel Modules. Starting Apply Kernel Variables... [[1;32m OK [0m] Started Remount Root and Kernel File Systems. Starting Load Random Seed... [[1;32m OK [0m] Started udev Coldplug all Devices. [[1;32m OK [0m] Started Load Random Seed. Starting Show Plymouth Boot Screen... [[1;32m OK [0m] Started Create dynamic rule for /dev/root link. [[1;32m OK [0m] Started Apply Kernel Variables. Starting udev Kernel Device Manager... <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. [etc, continuing] -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 06.04.2013, at 22:55, G. Heim wrote:
Hi Alex,
Thanks again. I did a compile of the debian kernel on my mirabox, then I booted with the modules and uImage. The full bootlog is below.
As you can see, the first message about "systemd[1]: CONFIG_CGROUPS was not set" has disappeared, but the line
<28>systemd[1]: No control group support available, not creating root group.
is still there. I used these CGROUP related kernel compile options:
CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y # CONFIG_CPUSETS is not set CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y # CONFIG_CGROUP_MEM_RES_CTLR is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set
Also, opensuse gets in an loop with <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. [etc, continuing]
Any hints how to continue are very much appreciated.
Oh, I just realized that you're running on 2.6.35. There's a good chance your kernel is simply too old, which probably is why udev is failing. Are there any more recent kernels available for your machine? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 06.04.2013, at 23:16, Alexander Graf wrote:
On 06.04.2013, at 22:55, G. Heim wrote:
Hi Alex,
Thanks again. I did a compile of the debian kernel on my mirabox, then I booted with the modules and uImage. The full bootlog is below.
As you can see, the first message about "systemd[1]: CONFIG_CGROUPS was not set" has disappeared, but the line
<28>systemd[1]: No control group support available, not creating root group.
is still there. I used these CGROUP related kernel compile options:
CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y # CONFIG_CPUSETS is not set CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y # CONFIG_CGROUP_MEM_RES_CTLR is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set
Also, opensuse gets in an loop with <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. [etc, continuing]
Any hints how to continue are very much appreciated.
Oh, I just realized that you're running on 2.6.35. There's a good chance your kernel is simply too old, which probably is why udev is failing.
Are there any more recent kernels available for your machine?
Ah, looks like there is upstream support for it: https://patchwork.kernel.org/patch/1942941/ Would you mind to try a 3.9 based kernel with a simple defconfig for either mvebu or multi_v7? Compile the kernel as zImage, then the device tree that comes with Linux (arch/arm/boot/dts/armada-370-mirabox.dts) to a dtb and then load both from u-boot? You just pass the dtb as 3rd parameter to the bootz command. If you run without an initrd, just pass "-" to bootz to tell it you don't want one. I'd assume that should just work, and should also get you something properly working with openSUSE 12.3. No guarantees that all your hardware components will be supported by the upstream code however :). Traditionally, we've had quite a bit of trouble getting graphics rolling. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Alex, Thanks again for your replies. I downloaded the 3.9-rc5 kernel from kernel.org and it seems to have armada 370 support (which is my mirabox) so I started with the .config from the 3.6.35.9 debian mirabox kernel and did "make olddefconfig", then make, etc. "make uImage" complained about a missing LOADADDR so I did "make LOADADDR=0x0008000 uImage". Everything compiled nicely and then I booted with it, and the bootlog is as follows: reading uImage 3460464 bytes read ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-3.9.0-rc5 Created: 2013-04-07 10:10:29 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3460400 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... ... and then nothing more. I tried to ping but to no avail. In my .config are (amongst others): # # CPU Core family selection # # CONFIG_ARCH_MULTI_V6 is not set CONFIG_ARCH_MULTI_V7=y CONFIG_ARCH_MULTI_V6_V7=y # CONFIG_ARCH_MULTI_CPU_AUTO is not set CONFIG_ARCH_MVEBU=y # # Marvell SOC with device tree # CONFIG_MACH_ARMADA_370_XP=y CONFIG_MACH_ARMADA_370=y # CONFIG_MACH_ARMADA_XP is not set # CONFIG_ARCH_BCM is not set # CONFIG_GPIO_PCA953X is not set # CONFIG_ARCH_HIGHBANK is not set # CONFIG_ARCH_MXC is not set # CONFIG_ARCH_OMAP2PLUS is not set # CONFIG_ARCH_SOCFPGA is not set # CONFIG_ARCH_SUNXI is not set CONFIG_ARCH_VEXPRESS=y You also gave as an option:
Subject: Re: [opensuse-arm] OpenSUSE 12.3 for armv7 on Mirabox fails Date: Sat, 6 Apr 2013 23:21:30 +0200
Oh, I just realized that you're running on 2.6.35. There's a good chance your kernel is simply too old, which probably is why udev is failing.
Are there any more recent kernels available for your machine?
no, not that I know of.
Compile the kernel as zImage, then the device tree that comes with Linux (arch/arm/boot/dts/armada-370-mirabox.dts) to a dtb and then load both from u-boot? You just pass the dtb as 3rd parameter to the bootz command. If you run without an initrd, just pass "-" to bootz to tell it you don't want one.
I'd assume that should just work, and should also get you something properly working with openSUSE 12.3. No guarantees that all your hardware components will be supported by the upstream code however :). Traditionally, we've had quite a bit of trouble getting graphics rolling.
I think I understand what you write (except for the dts/dtb) but my uboot loader doesn't have a bootz, so I don't know how to continue with this suggestion. Any more suggestions are highly appreciated, Thanks again, Ge -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 07.04.2013, at 12:41, G. Heim wrote:
Hi Alex,
Thanks again for your replies.
I downloaded the 3.9-rc5 kernel from kernel.org and it seems to have armada 370 support (which is my mirabox) so I started with the .config from the 3.6.35.9 debian mirabox kernel and did "make olddefconfig", then make, etc. "make uImage" complained about a missing LOADADDR so I did "make LOADADDR=0x0008000 uImage". Everything compiled nicely and then I booted with it, and the bootlog is as follows:
reading uImage
3460464 bytes read ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-3.9.0-rc5 Created: 2013-04-07 10:10:29 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3460400 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
... and then nothing more. I tried to ping but to no avail.
It's probably trying to tell you that it can't find support for your machine id :).
In my .config are (amongst others): # # CPU Core family selection # # CONFIG_ARCH_MULTI_V6 is not set CONFIG_ARCH_MULTI_V7=y CONFIG_ARCH_MULTI_V6_V7=y # CONFIG_ARCH_MULTI_CPU_AUTO is not set CONFIG_ARCH_MVEBU=y
# # Marvell SOC with device tree # CONFIG_MACH_ARMADA_370_XP=y CONFIG_MACH_ARMADA_370=y # CONFIG_MACH_ARMADA_XP is not set # CONFIG_ARCH_BCM is not set # CONFIG_GPIO_PCA953X is not set # CONFIG_ARCH_HIGHBANK is not set # CONFIG_ARCH_MXC is not set # CONFIG_ARCH_OMAP2PLUS is not set # CONFIG_ARCH_SOCFPGA is not set # CONFIG_ARCH_SUNXI is not set CONFIG_ARCH_VEXPRESS=y
You also gave as an option:
Subject: Re: [opensuse-arm] OpenSUSE 12.3 for armv7 on Mirabox fails Date: Sat, 6 Apr 2013 23:21:30 +0200
Oh, I just realized that you're running on 2.6.35. There's a good chance your kernel is simply too old, which probably is why udev is failing.
Are there any more recent kernels available for your machine?
no, not that I know of.
Compile the kernel as zImage, then the device tree that comes with Linux (arch/arm/boot/dts/armada-370-mirabox.dts) to a dtb and then load both from u-boot? You just pass the dtb as 3rd parameter to the bootz command. If you run without an initrd, just pass "-" to bootz to tell it you don't want one.
I'd assume that should just work, and should also get you something properly working with openSUSE 12.3. No guarantees that all your hardware components will be supported by the upstream code however :). Traditionally, we've had quite a bit of trouble getting graphics rolling.
I think I understand what you write (except for the dts/dtb) but my uboot loader doesn't have a bootz, so I don't know how to continue with this suggestion.
Then use bootm, that works just as well if you create a uImage. Enabling bootz support in u-boot also isn't overly hard, but let's go one step at a time. In the old days of ARM (read: last year), there used to be machine IDs that u-boot pass on to the kernel to identify which board a particular machine identifies as. Linux then contains a C file describing what hardware looks like in that board. This means that every new board needed a new kernel, even if only very little changed to another, already implemented board. This scheme was deprecated by device trees. For most modern boards, you can now just pass in a device tree (dtb) into the kernel which describes what the C file used to describe, but in as data rather than code. That allows for a lot more flexibility. For your Mirabox, it looks as if support for the machine ID based approach simply never made it upstream, so you have to pass in a device tree to get Linux to actually run anything sensible on your board. You can compile dts files into dtb files using the dtc command line tool. Pass the dtb into your bootm command as 3rd parameter. Also make sure you have your console= setting correct. Then your board should boot with 3.9 :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Alex, Thanks again. I think I understand what you write. I found an armada-370-mirabox.dts in .../arch/arm/boot/dts of the linux-3.9 tree and it was already compiled to an armada-370-mirabox.dtb. There were also others (armada-370-db, armada-370-rd) but I did not try those. I copied armada-370-mirabox.dtb to the same partition on my sdcard where uImage is, and then I booted. Unfortuately it did not do anything more than before. This is what I tried: Marvell>> set bootcmd 'usb start; fatload usb 1 0x6400000 uImage; bootm 0x6400000 - armada-370-mirabox.dtb' Marvell>> boot This was what happened: reading uImage 3460464 bytes read ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-3.9.0-rc5 Created: 2013-04-07 10:10:29 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3460400 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... ... and nothing more. Then I tried: Marvell>> usb start (Re)start USB... USB: Active port: invalid port number 2, switching to port 0 Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 4 USB Device(s) found Waiting for storage device(s) to settle before scanning... scanning bus for storage devices... Device NOT ready Request Sense returned 02 3A 00 2 Storage Device(s) found Marvell>> fatload usb 1 0x6400000 uImage reading uImage 3460464 bytes read Marvell>> fatload usb 1 0xc000000 armada-370-mirabox.dtb reading armada-370-mirabox.dtb 5727 bytes read Marvell>> bootm 0x6400000 - 0xc000000 ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-3.9.0-rc5 Created: 2013-04-07 10:10:29 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3460400 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... ... and nothing more. Then I tried (because maybe I had the addresses in the wrong order): Marvell>> fatload usb 1 0x6400000 uImage reading uImage 3460464 bytes read Marvell>> fatload usb 1 0x5000000 armada-370-mirabox.dtb mada-370-mirabox.dtb reading armada-370-mirabox.dtb 5727 bytes read Marvell>> bootm 0x6400000 - 0x5000000 ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-3.9.0-rc5 Created: 2013-04-07 10:10:29 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3460400 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... ... and nothing more. Obviously I am missing something. Maybe my mirabox has an old Uboot? It says: BootROM 1.08 Booting from NAND flash DDR3 Training Sequence - Ver 2.1.6 DDR3 Training Sequence - Number of DIMMs detected: 1 DDR3 Training Sequence - Ended Successfully BootROM: Image checksum verification PASSED __ __ _ _ | \/ | __ _ _ ____ _____| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_| \_/ \___|_|_| _ _ ____ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/ |____/ \___/ \___/ \__| ** LOADER ** U-Boot 2009.08 (Sep 16 2012 - 22:50:06)Marvell version: 1.1.2 NQ U-Boot Addressing: Code: 00600000:006AFFF0 BSS: 006F8E40 Stack: 0x5fff70 PageTable: 0x8e0000 Heap address: 0x900000:0xe00000 and if I type Marvell>> help bootm bootm - boot application image from memory Usage: bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg ...'; when booting a Linux kernel, 'arg' can be the address of an initrd image Sub-commands to do part of the bootm sequence. The sub-commands must be issued in the order below (it's ok to not issue all sub-commands): start [addr [arg ...]] loados - load OS image bdt - OS specific bd_t processing cmdline - OS specific command line processing/setup prep - OS specific prep before relocation or go go - start OS Maybe it doesn't have a third parameter for device trees? Thanks again, Ge -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 07.04.2013, at 18:16, G. Heim wrote:
Hi Alex,
Thanks again. I think I understand what you write. I found an armada-370-mirabox.dts in .../arch/arm/boot/dts of the linux-3.9 tree and it was already compiled to an armada-370-mirabox.dtb. There were also others (armada-370-db, armada-370-rd) but I did not try those. I copied armada-370-mirabox.dtb to the same partition on my sdcard where uImage is, and then I booted. Unfortuately it did not do anything more than before. This is what I tried:
Marvell>> set bootcmd 'usb start; fatload usb 1 0x6400000 uImage; bootm 0x6400000 - armada-370-mirabox.dtb'
This should error out I would have assumed. Hrm.
Marvell>> boot
This was what happened:
reading uImage
3460464 bytes read ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-3.9.0-rc5 Created: 2013-04-07 10:10:29 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3460400 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
... and nothing more.
Then I tried:
Marvell>> usb start (Re)start USB... USB: Active port: invalid port number 2, switching to port 0 Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 4 USB Device(s) found Waiting for storage device(s) to settle before scanning... scanning bus for storage devices... Device NOT ready Request Sense returned 02 3A 00 2 Storage Device(s) found Marvell>> fatload usb 1 0x6400000 uImage reading uImage
3460464 bytes read Marvell>> fatload usb 1 0xc000000 armada-370-mirabox.dtb
I'd assume that 0xc0000000 is out of RAM, no?
reading armada-370-mirabox.dtb
5727 bytes read Marvell>> bootm 0x6400000 - 0xc000000 ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-3.9.0-rc5 Created: 2013-04-07 10:10:29 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3460400 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
... and nothing more.
Then I tried (because maybe I had the addresses in the wrong order):
Marvell>> fatload usb 1 0x6400000 uImage reading uImage
3460464 bytes read Marvell>> fatload usb 1 0x5000000 armada-370-mirabox.dtb
That looks more sensible. At which physical offset does RAM start on this machine?
mada-370-mirabox.dtb reading armada-370-mirabox.dtb
5727 bytes read Marvell>> bootm 0x6400000 - 0x5000000 ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-3.9.0-rc5 Created: 2013-04-07 10:10:29 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3460400 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
... and nothing more.
Obviously I am missing something. Maybe my mirabox has an old Uboot? It says:
BootROM 1.08 Booting from NAND flash DDR3 Training Sequence - Ver 2.1.6 DDR3 Training Sequence - Number of DIMMs detected: 1 DDR3 Training Sequence - Ended Successfully BootROM: Image checksum verification PASSED
__ __ _ _ | \/ | __ _ _ ____ _____| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_| \_/ \___|_|_| _ _ ____ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/ |____/ \___/ \___/ \__| ** LOADER **
U-Boot 2009.08 (Sep 16 2012 - 22:50:06)Marvell version: 1.1.2 NQ
This does sound quite old, yeah. Can you update your u-boot version to something more recent? There's a good chance Linux never gets to see the dtb...
U-Boot Addressing: Code: 00600000:006AFFF0 BSS: 006F8E40 Stack: 0x5fff70 PageTable: 0x8e0000 Heap address: 0x900000:0xe00000
and if I type Marvell>> help bootm bootm - boot application image from memory
Usage: bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg ...'; when booting a Linux kernel, 'arg' can be the address of an initrd image
Sub-commands to do part of the bootm sequence. The sub-commands must be issued in the order below (it's ok to not issue all sub-commands): start [addr [arg ...]] loados - load OS image bdt - OS specific bd_t processing cmdline - OS specific command line processing/setup prep - OS specific prep before relocation or go go - start OS
Maybe it doesn't have a third parameter for device trees?
Yup. :) Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 07.04.2013, at 19:54, Alexander Graf wrote:
On 07.04.2013, at 18:16, G. Heim wrote:
Hi Alex,
Thanks again. I think I understand what you write. I found an armada-370-mirabox.dts in .../arch/arm/boot/dts of the linux-3.9 tree and it was already compiled to an armada-370-mirabox.dtb. There were also others (armada-370-db, armada-370-rd) but I did not try those. I copied armada-370-mirabox.dtb to the same partition on my sdcard where uImage is, and then I booted. Unfortuately it did not do anything more than before. This is what I tried:
Marvell>> set bootcmd 'usb start; fatload usb 1 0x6400000 uImage; bootm 0x6400000 - armada-370-mirabox.dtb'
This should error out I would have assumed. Hrm.
Marvell>> boot
This was what happened:
reading uImage
3460464 bytes read ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-3.9.0-rc5 Created: 2013-04-07 10:10:29 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3460400 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
... and nothing more.
Then I tried:
Marvell>> usb start (Re)start USB... USB: Active port: invalid port number 2, switching to port 0 Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 4 USB Device(s) found Waiting for storage device(s) to settle before scanning... scanning bus for storage devices... Device NOT ready Request Sense returned 02 3A 00 2 Storage Device(s) found Marvell>> fatload usb 1 0x6400000 uImage reading uImage
3460464 bytes read Marvell>> fatload usb 1 0xc000000 armada-370-mirabox.dtb
I'd assume that 0xc0000000 is out of RAM, no?
reading armada-370-mirabox.dtb
5727 bytes read Marvell>> bootm 0x6400000 - 0xc000000 ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-3.9.0-rc5 Created: 2013-04-07 10:10:29 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3460400 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
... and nothing more.
Then I tried (because maybe I had the addresses in the wrong order):
Marvell>> fatload usb 1 0x6400000 uImage reading uImage
3460464 bytes read Marvell>> fatload usb 1 0x5000000 armada-370-mirabox.dtb
That looks more sensible. At which physical offset does RAM start on this machine?
mada-370-mirabox.dtb reading armada-370-mirabox.dtb
5727 bytes read Marvell>> bootm 0x6400000 - 0x5000000 ## Booting kernel from Legacy Image at 06400000 ... Image Name: Linux-3.9.0-rc5 Created: 2013-04-07 10:10:29 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3460400 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
... and nothing more.
Obviously I am missing something. Maybe my mirabox has an old Uboot? It says:
BootROM 1.08 Booting from NAND flash DDR3 Training Sequence - Ver 2.1.6 DDR3 Training Sequence - Number of DIMMs detected: 1 DDR3 Training Sequence - Ended Successfully BootROM: Image checksum verification PASSED
__ __ _ _ | \/ | __ _ _ ____ _____| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_| \_/ \___|_|_| _ _ ____ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/ |____/ \___/ \___/ \__| ** LOADER **
U-Boot 2009.08 (Sep 16 2012 - 22:50:06)Marvell version: 1.1.2 NQ
This does sound quite old, yeah. Can you update your u-boot version to something more recent? There's a good chance Linux never gets to see the dtb...
http://www.spinics.net/lists/arm-kernel/msg234398.html Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Sun, Apr 07, 2013 at 07:56:30PM +0200, Alexander Graf wrote:
Is there a general user-level howto on this stuff anywhere that you could recommend? (i.e. when you need to set an arcNumber, when you need to do this .dts / .dtb stuff). I have a dreamplug and I've been confused in the process of trying to get modern versions of Linux to run on it, somewhat similarly to the problems described in this thread. Fedora 18 works fine with the original u-boot, but not with a new u-boot (then it hangs after "Uncompressing Linux..." ). Ideally of course I would like to get openSUSE running on it, with an up-to-date u-boot. -- ======================== Roger Whittaker roger@disruptive.org.uk http://disruptive.org.uk ======================== -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 07.04.2013, at 22:11, Roger Whittaker wrote:
On Sun, Apr 07, 2013 at 07:56:30PM +0200, Alexander Graf wrote:
Is there a general user-level howto on this stuff anywhere that you could recommend? (i.e. when you need to set an arcNumber, when you need to do this .dts / .dtb stuff).
As this changes pretty much any day, I don't think you'll find any sensible howto. The general rule of thumb is that old code always based off of arcNumbers. Very new code only runs with dtb. Code that had arcNumbers upstream, but got converted to dtb may work with both. Keep in mind that the important notion here is _upstream_. If someone did a downstream port somewhere, you don't get any guarantees what happens upstream with the same target.
I have a dreamplug and I've been confused in the process of trying to get modern versions of Linux to run on it, somewhat similarly to the problems described in this thread. Fedora 18 works fine with the original u-boot, but not with a new u-boot (then it hangs after "Uncompressing Linux..." ).
Odd... Does the new u-boot change the arcNumber? Some times people chose random numbers and only later got an official ID reserved. So maybe your old u-boot version exposes an unofficial arcNumber - which your kernel expects - but new u-boot exposes a new official arcNumber, that your kernel doesn't know about?
Ideally of course I would like to get openSUSE running on it, with an up-to-date u-boot.
Very happy to hear that :). Marrying embedded ideology with a general purpose distro obviously is nothing for the faint of heart. Also keep in mind that the dreamplug is an ARMv5 device. As such, it again lives under even different rules than ARMv7 ones. For ARMv5 devices, I don't think anyone's really going through efforts to convert anything to device trees. At least I'm not aware of any efforts, but I like to be proven wrong :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Sun, Apr 07, 2013 at 10:43:33PM +0200, Alexander Graf wrote: [...]
I have a dreamplug and I've been confused in the process of trying to get modern versions of Linux to run on it, somewhat similarly to the problems described in this thread. Fedora 18 works fine with the original u-boot, but not with a new u-boot (then it hangs after "Uncompressing Linux..." ).
Odd...
Does the new u-boot change the arcNumber? Some times people chose random numbers and only later got an official ID reserved. So maybe your old u-boot version exposes an unofficial arcNumber - which your kernel expects - but new u-boot exposes a new official arcNumber, that your kernel doesn't know about? [...]
Thank you very much for this suggestion - I think that's it. The newer u-boot (which I built from source) says in the output of bdinfo: arch_number = 0x00000DDE The older u-boot gave 0x00000A63. But trying to override this with "setenv arcNumber 2659" doesn't seem to help me. I believe these devices were manufactured in two different types. -- ======================== Roger Whittaker roger@disruptive.org.uk http://disruptive.org.uk ======================== -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Sun, Apr 07, 2013 at 10:34:29PM +0100, Roger Whittaker wrote:
But trying to override this with "setenv arcNumber 2659" doesn't seem to help me.
I believe these devices were manufactured in two different types.
But "setenv machid 0x00000A63" worked beautifully. Thanks Alex for putting me on the right track. -- ======================== Roger Whittaker roger@disruptive.org.uk http://disruptive.org.uk ======================== -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Roger, Are you aware of the site http://www.xilka.com/sheeva/? It has recent Dreamplug and Sheevaplug kernels. If you run the script http://www.xilka.com/sheeva/UPDATE-DREAM-KERNEL.sh it'll do it automagically (it'll ask you what you want if I remember it correctly). Have fun, Best regards, Ge ----------------------------------------
Date: Sun, 7 Apr 2013 21:11:57 +0100 From: roger@disruptive.org.uk To: opensuse-arm@opensuse.org CC: agraf@suse.de Subject: Re: [opensuse-arm] OpenSUSE 12.3 for armv7 on Mirabox fails
On Sun, Apr 07, 2013 at 07:56:30PM +0200, Alexander Graf wrote:
Is there a general user-level howto on this stuff anywhere that you could recommend? (i.e. when you need to set an arcNumber, when you need to do this .dts / .dtb stuff).
I have a dreamplug and I've been confused in the process of trying to get modern versions of Linux to run on it, somewhat similarly to the problems described in this thread. Fedora 18 works fine with the original u-boot, but not with a new u-boot (then it hangs after "Uncompressing Linux..." ).
Ideally of course I would like to get openSUSE running on it, with an up-to-date u-boot.
-- ======================== Roger Whittaker roger@disruptive.org.uk http://disruptive.org.uk ======================== -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mon, Apr 08, 2013 at 08:08:57AM +0200, G. Heim wrote:
Are you aware of the site http://www.xilka.com/sheeva/? It has recent Dreamplug and Sheevaplug kernels. If you run the script http://www.xilka.com/sheeva/UPDATE-DREAM-KERNEL.sh it'll do it automagically (it'll ask you what you want if I remember it correctly).
Thanks for this. I had actually come across that site before, but failed with their kernel because of the machid problem in u-boot. I'll look at this again now - thanks for the reminder. Do you use these with an openSUSE root filesystem? -- ======================== Roger Whittaker roger@disruptive.org.uk http://disruptive.org.uk ======================== -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
This does sound quite old, yeah. Can you update your u-boot version to something more recent? There's a good chance Linux never gets to see
Hi Alex, Thanks again. You wrote: the dtb Basically I don't dare to install a new uboot and I'm not sure there is one from Globalscale. I tried a different approach, by compiling the kernel with: CONFIG_ARM_APPENDED_DTB=y # CONFIG_ARM_ATAG_DTB_COMPAT is not set According to serveral sources one should be able to take the generated zImage, add armada-370-mirabox.dtb to it (as in "cat zImage armada-370-mirabox.dtb > mynewzImage") and convert it to a uImage with mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n linux-3.9-rc5 -d mynewzImage uImage You might guess... still nothing after booting on the mirabox, still stops after Starting kernel: 3466263 bytes read ## Booting kernel from Legacy Image at 06400000 ... Image Name: linux-3.9-rc5 Created: 2013-04-08 17:31:00 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3466199 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Compared to my previous uImage it is a bit larger which is due to the armada-370-mirabox.dtb I think, but other than that I don't see anything that hints that it understands the dtb... I see quite some emails on the http://www.spinics.net/lists/arm-kernel email list discussing kernel things about the mirabox, supposedly some of the persons on there have a running mirabox with a new kernel (at least newer than I have). Do you know anyone over there which I can ask if I can use their kernel source & kernel image? I have uploaded my linux 3.9 rc 5 .config file here: http://pastebin.com/fswx9Q23. If you have more things I might try, that would be wonderful, if not, then thanks a lot for taking the time to think this over! Best regards, Ge -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 08.04.2013 um 20:59 schrieb "G. Heim" <heelgeheim@hotmail.com>:
Hi Alex,
This does sound quite old, yeah. Can you update your u-boot version to something more recent? There's a good chance Linux never gets to see
Thanks again. You wrote: the dtb
Basically I don't dare to install a new uboot and I'm not sure there is one from Globalscale.
I tried a different approach, by compiling the kernel with: CONFIG_ARM_APPENDED_DTB=y # CONFIG_ARM_ATAG_DTB_COMPAT is not set
According to serveral sources one should be able to take the generated zImage, add armada-370-mirabox.dtb to it (as in "cat zImage armada-370-mirabox.dtb > mynewzImage") and convert it to a uImage with mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n linux-3.9-rc5 -d mynewzImage uImage
You might guess... still nothing after booting on the mirabox, still stops after Starting kernel:
3466263 bytes read ## Booting kernel from Legacy Image at 06400000 ... Image Name: linux-3.9-rc5 Created: 2013-04-08 17:31:00 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3466199 Bytes = 3.3 MB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK
Starting kernel ...
The next thing you could try here would be to find out what the kernel is doing. Either by enabling early printk or by manually dumping the kernel's log buffer. Do you have an ARM JTAG available? If so, you could check where the kernel hangs and dump the log_buf variable. If you don't have a JTAG, you can at least try the poor man's alternative. Shorten pin 15 and the opposing pin (gnd) on the JTAG header. That will reset the SoC, but leave RAM intact. Then in u-boot, do: # md.b <address> 500 This should log the kernel's printk buffer. To get <address>, load the vmlinux file that matches your zImage in gdb. Then do (gdb) x /2c log_buf That won't be able to dump anything, but will give you the virtual address of log_buf. Let's assume it's 0xc0100000 for this example. You need to make a physical address out of this. Cut off the beginning 0xc and add the offset, where your soc starts its ram. IIRC the Marvells start RAM at address 0, so you can simply do: # md.b 0x100000 500 Keep in mind that the log_buf address differs on different kernel builds, so you need to really pull it out of your own vmlinux binary.
Compared to my previous uImage it is a bit larger which is due to the armada-370-mirabox.dtb I think, but other than that I don't see anything that hints that it understands the dtb...
I see quite some emails on the http://www.spinics.net/lists/arm-kernel email list discussing kernel things about the mirabox, supposedly some of the persons on there have a running mirabox with a new kernel (at least newer than I have). Do you know anyone over there which I can ask if I can use their kernel source & kernel image?
Well, if you see people who are apparently having something working, just approach them :) Alex
I have uploaded my linux 3.9 rc 5 .config file here: http://pastebin.com/fswx9Q23.
If you have more things I might try, that would be wonderful, if not, then thanks a lot for taking the time to think this over!
Best regards,
Ge
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Alex, Thanks a lot for your suggestions and your advice, but this is just too complicated for me. I really appreciate the time you took to help me. I might try some other twiddeling and tweaking but possibly I give up and hope someone else is able to get a recent kernel running on mirabox. Thanks again, Best regards, Ge ----------------------------------------
Subject: Re: [opensuse-arm] OpenSUSE 12.3 for armv7 on Mirabox fails Date: Tue, 9 Apr 2013 08:29:04 +0200
The next thing you could try here would be to find out what the kernel is doing. Either by enabling early printk or by manually dumping the kernel's log buffer.
Do you have an ARM JTAG available? If so, you could check where the kernel hangs and dump the log_buf variable.
If you don't have a JTAG, you can at least try the poor man's alternative. Shorten pin 15 and the opposing pin (gnd) on the JTAG header. That will reset the SoC, but leave RAM intact. [...] -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 06.04.2013, at 23:16, Alexander Graf wrote:
On 06.04.2013, at 22:55, G. Heim wrote:
Hi Alex,
Thanks again. I did a compile of the debian kernel on my mirabox, then I booted with the modules and uImage. The full bootlog is below.
As you can see, the first message about "systemd[1]: CONFIG_CGROUPS was not set" has disappeared, but the line
<28>systemd[1]: No control group support available, not creating root group.
is still there. I used these CGROUP related kernel compile options:
CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y # CONFIG_CPUSETS is not set CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y # CONFIG_CGROUP_MEM_RES_CTLR is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set
Also, opensuse gets in an loop with <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. <28>systemd[1]: systemd-udevd.service start request repeated too quickly, refusing to start. [etc, continuing]
Any hints how to continue are very much appreciated.
Oh, I just realized that you're running on 2.6.35. There's a good chance your kernel is simply too old, which probably is why udev is failing.
http://www.spinics.net/linux/fedora/fedora-arm/msg05638.html Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (5)
-
Alexander Graf -
G. Heim -
Guillaume Gardet -
Mike Veltman -
Roger Whittaker