Print

[kosh]

I have a Mirabox that was delivered with Debian squeeze and an apparently modified 2.6.35.9 kernel.

As support for squeeze is going to end and the Mirabox is intended to replace systems I am currently running on Debian wheezy, I thought it would be a good idea to get them to work with wheezy so I don't have to deal with two software versions and have to worry about updating in a few months.

From the Debian kernel package description at

http://packages.debian.org/jessie/linux-image-armmp

I gathered that correct kernel flavor for the Mirabox (Armada 370) is armmp, and that it would not be supported under the armel Debian architecture, as the OpenRD Client was.

So I created a wheezy image on my PC for the armhf architecture with debootstrap, but then realised that this doesn't work very well cross-platform, so I booted the squeeze on the NAND of the Mirabox and continued the package installation of the wheezy in a chroot on an SD card (which works surprisingly well, given that the kernel is armel and the userland is armhf). I copied the 2.6.35.9 kernel and its modules from NAND to the SD card and now have a working Debian wheezy (armhf) userland running on the original Mirabox (armel) kernel.

Now the hard part: I can't get a current kernel to work. I suppose that, as there is a Debian kernel package for Armada 370, I should get it to work on the Mirabox. Unfortunately, I don't know what to do with it and how the relevant tools work and what their parameters mean, so here is what I did:

I installed linux-image-3.11-0.bpo.2-armmp and initramfs-tools from wheezy-backports:

http://packages.debian.org/wheezy-backports/linux-image-3.11-0.bpo.2-armmp

and flash-kernel from jessie.

flash-kernel is supposed to create the uBoot compatible image files. It first complained about an the machine type being unknown, so I copy-pasted one together from the OpenRD entry (in /usr/share/flash-kernel/db/all.db):

Code: [Select]

Machine: Marvell OpenRD Ultimate Board
Kernel-Flavors: kirkwood
U-Boot-Kernel-Address: 0x00008000
U-Boot-Initrd-Address: 0x0
Boot-Kernel-Path: /boot/uImage
Boot-Initrd-Path: /boot/uInitrd
Required-Packages: u-boot-tools
Bootloader-Sets-Root: no

Machine: Marvell Armada-370
Kernel-Flavors: armmp
U-Boot-Kernel-Address: 0x00008000
U-Boot-Initrd-Address: 0x0
Boot-Kernel-Path: /boot/uImage
Boot-Initrd-Path: /boot/uInitrd
Required-Packages: u-boot-tools
Bootloader-sets-root: no

Now flash-kernel produces files, and they are accepted by uBoot:

Code: [Select]

Marvell>> setenv bootargs 'console=ttyS0,115200 root=/dev/sdb2 rootwait ro rootfstype=ext4'
Marvell>> ext2load usb 1:1 0x6800000 /uInitrd
Loading file "/uInitrd" from usb device 1:1 (usbdb1)
11106312 bytes read
Marvell>> ext2load usb 1:1 0x6400000 /uImage
Loading file "/uImage" from usb device 1:1 (usbdb1)
2607864 bytes read
Marvell>> bootm 0x6400000 0x6800000
## Booting kernel from Legacy Image at 06400000 ...
   Image Name:   kernel 3.11-0.bpo.2-armmp
   Created:      2014-01-02  18:09:48 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2607800 Bytes =  2.5 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 06800000 ...
   Image Name:   ramdisk 3.11-0.bpo.2-armmp
   Created:      2014-01-02  18:09:50 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    11106248 Bytes = 10.6 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Output stops there. Also, the machine doesn't ping, so I don't believe this to be just a console problem.

As an alternative, I tried this flash-kernel config:

Code: [Select]

Machine: Marvell Armada-370
Kernel-Flavors: armmp
U-Boot-Kernel-Address: 0x00068000
U-Boot-Initrd-Address: 0x0
Boot-Kernel-Path: /boot/uImage
Boot-Initrd-Path: /boot/uInitrd
Required-Packages: u-boot-tools
Bootloader-sets-root: no

With the same end result:

Code: [Select]

Marvell>> ext2load usb 1:1 0x6800000 /uInitrd
Loading file "/uInitrd" from usb device 1:1 (usbdb1)
11106312 bytes read
Marvell>> ext2load usb 1:1 0x6400000 /uImage
Loading file "/uImage" from usb device 1:1 (usbdb1)
2607864 bytes read
Marvell>> bootm 0x6400000 0x6800000
## Booting kernel from Legacy Image at 06400000 ...
   Image Name:   kernel 3.11-0.bpo.2-armmp
   Created:      2014-01-02  18:58:51 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2607800 Bytes =  2.5 MB
   Load Address: 00068000
   Entry Point:  00068000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 06800000 ...
   Image Name:   ramdisk 3.11-0.bpo.2-armmp
   Created:      2014-01-02  18:58:52 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    11106248 Bytes = 10.6 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Again, any help is appreciated.

[ghat]

hi

What is the U-boot version you are using (what came with the box ?)
I understand one needs the newer uboots for later kernels...

Is this box supporting debian stable ?
I have a dreamplug, and am planing to get a new one and was looking at this...

I like the concept of a minipci-e card, but I would have liked to see more USB ports
like the openRD used to have.

[ http://www.cyrius.com/debian/kirkwood/sheevaplug/troubleshooting/ ]


G

[noidea]

  Hi,

I think the best way to have a working kernel is to build a new one with the cross-compiler provide by Marvell.

See the others post to have more information on how to do it.

[kosh]

What is the U-boot version you are using (what came with the box ?)
I understand one needs the newer uboots for later kernels...

Code: [Select]

U-Boot 2009.08 (Sep 16 2012 - 22:50:06)Marvell version: 1.1.2 NQ
This is the version the box came with. It is also the only download I found.

According to other info I found, stock u-boot does not support the Mirabox, the version by Marvell has been modified by them to support the Mirabox (same as with the Linux kernel).

I find it rather odd, though, that this is done with ancient software instead of current software. I also find it rather odd that the relevant support hasn't surfaced upstream, yet, although the Mirabox is over a year old.

I shall try the build-from-source approach, then.