[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
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
: 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
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
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
. <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
. <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
. <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
. <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
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
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
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"
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
participants (5)
-
Alexander Graf
-
G. Heim
-
Guillaume Gardet
-
Mike Veltman
-
Roger Whittaker