Skip to contentSkip to conversation

Your kernel patches for the Marvell Mirabox

DISCUSSION Jason Cooper 3 participants 9 messages Dec 10, 2012 – Dec 12, 2012 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Jason Cooper

author
#1 lore raw
Quoted 1 line · Bernd

Hello Jason,

Hi Bernd!

Quoted 3 lines

If you don't take questions about your patches by direct email, could you point me to a mailing list which is more appropriate for asking such a question?

I prefer including, at a minimum, the Linux ARM Kernel mailinglist in the discussion. I've included it in the CC: now. Adding my address to the To: or CC: helps it stand out from the crowd, so no problem there.

Quoted 6 lines

If you do take questions about it, here is what I did:

I got the kernel source from

git://github.com/MISL-EBU-System-SW/mainline-public.git

Quoted 8 lines

commit 0c0029cb1806601430692d48c130a17302a18225, where Olof Johannson merged your changes for initial Mirabox support on top of Linus Torvalds' 3.7-rc7.

I built the kernel using the cross toolchain for ARM EABI from
https://sourcery.mentor.com/GNUToolchain/release2322?lite=arm and uboot-mkimage from
http://rapidlibrary.com/files/uboot-mkimage-0-4-tar-gz_ulzywyzvfni89on.html:

Most linux distro's I've seen include a 'uboot-tools' or 'uboot-utils' that you can install via the package manager. No need to pull it from unknown places.

Quoted 2 lines
$ make ARCH=arm mvebu_defconfig
$ make -j4 ARCH=arm CROSS_COMPILE=../arm-2012.09/bin/arm-none-eabi- uImage

Here's the problem. The stock u-boot installed by the manufacturer doesn't support devicetree. It uses the old method of handing the kernel a mach_type number to tell the kernel which board init it should call. 'boardid' in the u-boot environment.

The new method is to hand the kernel an address where the dtb (device tree blob) was loaded into RAM.

You have two choices, upgrade u-boot (sizeable task), or use a developer configuration option included in the kernel, CONFIG_ARM_APPENDED_DTB. Once set, you need to make a zImage, append arch/arm/boot/armada-<board>.dtb to the zImage, then turn the zImage into a uImage.

In u-boot you'll need to change the boardid environment variable to 0xffffffff, which needs to be in unsigned integer notation, 4294967295.

In general, you'll want to enable CONFIG_EARLY_PRINTK, and make sure earlyprintk is in your kernel command line options.

hth,

Jason.

#2 lore raw

Dear Jason Cooper,

Quoted 2 lines · Jason Cooper

In u-boot you'll need to change the boardid environment variable to 0xffffffff, which needs to be in unsigned integer notation, 4294967295.

I'm not sure this is strictly necessary. I've never done that on any Marvell U-Boot's and I'm happily booting DT-only kernels.

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
author
#3 lore raw
Quoted 9 lines · Thomas Petazzoni

Dear Jason Cooper,

Quoted 2 lines · Jason Cooper

In u-boot you'll need to change the boardid environment variable to 0xffffffff, which needs to be in unsigned integer notation, 4294967295.

I'm not sure this is strictly necessary. I've never done that on any Marvell U-Boot's and I'm happily booting DT-only kernels.

Yeah, I know it helped the topkick boot up. I probably needed this for kirkwood_defconfig, which includes support for legacy boards. mvebu_defconfig wouldn't need it then, since everything in mvebu is DT. Thanks for clarifying the point.

hth,

Jason.

#4 lore raw
In reply to Jason Cooper

Hi Jason,

Thanks for your explanations on the dtb. I tried it but it didn't work for me:

1. Turns out that mvebu_defconfig has the right settings already:

CONFIG_ARM_APPENDED_DTB=y

and, for enabling early debug messages:

CONFIG_DEBUG_LL=y
CONFIG_DEBUG_MVEBU_UART=y
CONFIG_DEBUG_LL_INCLUDE="debug/mvebu.S"
CONFIG_EARLY_PRINTK=y

2. So this is what I am using to build the kernel:

$ make ARCH=arm mvebu_defconfig
$ make -j4 ARCH=arm CROSS_COMPILE=../arm-2012.09/bin/arm-none-eabi- zImage
$ make ARCH=arm CROSS_COMPILE=../arm-2012.09/bin/arm-none-eabi-
armada-370-mirabox.dtb
$ cat arch/arm/boot/armada-370-mirabox.dtb >> arch/arm/boot/zImage
$ make ARCH=arm CROSS_COMPILE=../arm-2012.09/bin/arm-none-eabi- uImage

That builds a legacy uImage which, the way I understand your explanations, hides the dtb from my old u-boot but the kernel will find it anyway:

$ mkimage -l arch/arm/boot/uImage
Image Name:   Linux-3.7.0-rc7-00250-g0c0029c
Created:      Tue Dec 11 01:13:13 2012
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    1885555 Bytes = 1841.36 kB = 1.80 MB
Load Address: fffffff2
Entry Point:  fffffff2

3. My host distro doesn't have the uboot-tools in the package repository, but I downloaded the most current uboot distribution ftp://ftp.denx.de/pub/u-boot/u-boot-2012.10.tar.bz2 and now use the mkimage tool produced by 'make tools', just to be sure I am not using a broken mkimage.

4. In u-boot, I've set bootargs to:

Marvell>> printenv bootargs
bootargs=console=ttyS0,115200 root=/dev/sdb2 rootdelay=2 rootfstype=ext4 earlyprintk=serial,uart0,115200

so earlyprintk is set on the kernel command line.

5. When booting the kernel via tftp, I get:
--------------------------------------------
Marvell>> tftpboot 0x6400000 uImage3.7.0-rc7mirabox ; bootm 0x6400000 phyaddr= 0
Using egiga0 device
TFTP from server 192.168.1.10; our IP address is 192.168.1.138 Filename 'uImage3.7.0-rc7mirabox'.
Load address: 0x6400000
Loading: #################################################################
################################################################
done
Bytes transferred = 1885619 (1cc5b3 hex)
## Booting kernel from Legacy Image at 06400000 ...

   Image Name:   Linux-3.7.0-rc7-00250-g0c0029c
   Created:      2012-12-11   0:13:13 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1885555 Bytes =  1.8 MB

Load Address: fffffff2
Entry Point: fffffff2
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

--------------------------------------------

No debug messages and the box hangs.

When that failed, I tried to set in addition the configuration parameters

CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y

and rebuilt the kernel, but got the same result.

Any idea?

Cheers,

Bernd

Quoted 58 lines · Jason Cooper
Quoted 1 line · Bernd

Hello Jason,

Hi Bernd!

Quoted 3 lines

If you don't take questions about your patches by direct email, could you point me to a mailing list which is more appropriate for asking such a question?

I prefer including, at a minimum, the Linux ARM Kernel mailinglist in the discussion. I've included it in the CC: now. Adding my address to the To: or CC: helps it stand out from the crowd, so no problem there.

Quoted 6 lines

If you do take questions about it, here is what I did:

I got the kernel source from

git://github.com/MISL-EBU-System-SW/mainline-public.git

Quoted 8 lines

commit 0c0029cb1806601430692d48c130a17302a18225, where Olof Johannson merged your changes for initial Mirabox support on top of Linus Torvalds' 3.7-rc7.

I built the kernel using the cross toolchain for ARM EABI from
https://sourcery.mentor.com/GNUToolchain/release2322?lite=arm and uboot-mkimage from
http://rapidlibrary.com/files/uboot-mkimage-0-4-tar-gz_ulzywyzvfni89on.html:

Most linux distro's I've seen include a 'uboot-tools' or 'uboot-utils' that you can install via the package manager. No need to pull it from unknown places.

Quoted 2 lines
$ make ARCH=arm mvebu_defconfig
$ make -j4 ARCH=arm CROSS_COMPILE=../arm-2012.09/bin/arm-none-eabi- uImage

Here's the problem. The stock u-boot installed by the manufacturer doesn't support devicetree. It uses the old method of handing the kernel a mach_type number to tell the kernel which board init it should call. 'boardid' in the u-boot environment.

The new method is to hand the kernel an address where the dtb (device tree blob) was loaded into RAM.

You have two choices, upgrade u-boot (sizeable task), or use a developer configuration option included in the kernel, CONFIG_ARM_APPENDED_DTB. Once set, you need to make a zImage, append arch/arm/boot/armada-<board>.dtb to the zImage, then turn the zImage into a uImage.

In u-boot you'll need to change the boardid environment variable to 0xffffffff, which needs to be in unsigned integer notation, 4294967295.

In general, you'll want to enable CONFIG_EARLY_PRINTK, and make sure earlyprintk is in your kernel command line options.

hth,

Jason.

#5 lore raw

Dear Bernd,

Quoted 3 lines · Bernd
Data Size:    1885555 Bytes = 1841.36 kB = 1.80 MB
Load Address: fffffff2
Entry Point:  fffffff2

Those Load address and Entry Point are incorrect.

I think this is due to the fact that mach-mvebu is now part of the ARCH_MULTIPLATFORM thing and therefore no longer defines its own zreladdr-y, but I'm not sure. In any case, what I'm doing here is:

./scripts/mkuboot.sh -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n 'Linux-marvell' -d myzImage-with-dtb-appended myuImage.

Best regards,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#6 lore raw

Hi Thomas,

Thanks, that did the trick! Now the kernel boots OK until it can't find the root filesystem (I know the reason for that).

It appears that there is a bug in

$ make ARCH=arm CROSS_COMPILE=../arm-2012.09/bin/arm-none-eabi- uImage

The command it uses to create the uImage is (got it from arch/arm/boot/.uImage.cmd):

/bin/sh /home/bernd/mirabox-dev/marvell-boards/scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a -e -n 'Linux-3.7.0-rc7-00250-g0c0029c' -d arch/arm/boot/zImage arch/arm/boot/uImage

So no value given for parameters -a and -e.

Best regards,

Bernd

Quoted 21 lines · Thomas Petazzoni

Dear Bernd,

Quoted 3 lines · Bernd
Data Size:    1885555 Bytes = 1841.36 kB = 1.80 MB
Load Address: fffffff2
Entry Point:  fffffff2

Those Load address and Entry Point are incorrect.

I think this is due to the fact that mach-mvebu is now part of the ARCH_MULTIPLATFORM thing and therefore no longer defines its own zreladdr-y, but I'm not sure. In any case, what I'm doing here is:

./scripts/mkuboot.sh -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n 'Linux-marvell' -d myzImage-with-dtb-appended myuImage.

Best regards,

Thomas

#7 lore raw

Dear Bernd,

Quoted 14 lines · Bernd

Thanks, that did the trick! Now the kernel boots OK until it can't find the root filesystem (I know the reason for that).

It appears that there is a bug in

$ make ARCH=arm CROSS_COMPILE=../arm-2012.09/bin/arm-none-eabi- uImage

The command it uses to create the uImage is (got it from arch/arm/boot/.uImage.cmd):

/bin/sh /home/bernd/mirabox-dev/marvell-boards/scripts/mkuboot.sh -A arm

(quoted diff) +0 -2
-O linux -C none  -T kernel -a  -e  -n 'Linux-3.7.0-rc7-00250-g0c0029c'
-d arch/arm/boot/zImage arch/arm/boot/uImage
Quoted 1 line

So no value given for parameters -a and -e.

Indeed "make uImage" is broken for any multiplatform capable platform, because zreladdr is not defined (in order to be multiplatform, the multiplatform kernel use AUTO_ZRELADDR, so there is no fixed zreladdr). Since you're building a multiplatform kernel, there is no "one" entry point address and load address: it depends on which platform you are going to boot the kernel into.

I am not sure what is the plan forward. Maybe boot zImages directly from U-Boot? Let people build their uImage manually?

Best regards,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#8 lore raw

Dear Thomas,

Having to create the uImage manually is not so bad, IMO. The address (0x00008000) seems to be a 'magic number', though, so I think the process of creating a uImage for a particular box should be documented.

Meanwhile, I am struggling with the next issue which is getting the kernel to recognize and mount any root filesystem on the mirabox. Preferably I would like to use an SD card in the internal card reader for it. The factory kernel accesses the card reader via USB, so I assume I need to get USB working for that in mainline, too. Alternatively, I would use the built-in flash memory which the factory kernel accesses via MTD. So far I am out of luck ("Kernel panic - not syncing: VFS:
Unable to mount root fs...") as I don't know whether drivers for any of the devices are available in mainline already and, if yes, which ones I need to enable in config for that.

Is this information available somewhere?

Cheers,

Bernd

Quoted 33 lines · Thomas Petazzoni

Dear Bernd,

Quoted 14 lines · Bernd

Thanks, that did the trick! Now the kernel boots OK until it can't find the root filesystem (I know the reason for that).

It appears that there is a bug in

$ make ARCH=arm CROSS_COMPILE=../arm-2012.09/bin/arm-none-eabi- uImage

The command it uses to create the uImage is (got it from arch/arm/boot/.uImage.cmd):

/bin/sh /home/bernd/mirabox-dev/marvell-boards/scripts/mkuboot.sh -A arm

(quoted diff) +0 -2
-O linux -C none  -T kernel -a  -e  -n 'Linux-3.7.0-rc7-00250-g0c0029c'
-d arch/arm/boot/zImage arch/arm/boot/uImage
Quoted 1 line

So no value given for parameters -a and -e.

Indeed "make uImage" is broken for any multiplatform capable platform, because zreladdr is not defined (in order to be multiplatform, the multiplatform kernel use AUTO_ZRELADDR, so there is no fixed zreladdr). Since you're building a multiplatform kernel, there is no "one" entry point address and load address: it depends on which platform you are going to boot the kernel into.

I am not sure what is the plan forward. Maybe boot zImages directly from U-Boot? Let people build their uImage manually?

Best regards,

Thomas

#9 lore raw

Dear Bernd,

Quoted 4 lines · Bernd

Having to create the uImage manually is not so bad, IMO. The address (0x00008000) seems to be a 'magic number', though, so I think the process of creating a uImage for a particular box should be documented.

Well, actually, I *think* it could potentially be any address that fits within the DRAM, since we use AUTO_ZRELADDR. But I have never tested.

Quoted 11 lines

Meanwhile, I am struggling with the next issue which is getting the kernel to recognize and mount any root filesystem on the mirabox. Preferably I would like to use an SD card in the internal card reader for it. The factory kernel accesses the card reader via USB, so I assume I need to get USB working for that in mainline, too. Alternatively, I would use the built-in flash memory which the factory kernel accesses via MTD. So far I am out of luck ("Kernel panic - not syncing: VFS: Unable to mount root fs...") as I don't know whether drivers for any of the devices are available in mainline already and, if yes, which ones I need to enable in config for that.

Quoted 1 line

Is this information available somewhere?

The SD card readers in the Mirabox are controlled by a controller on the USB bus, and we haven't enabled the USB controller of the Marvell SoC on the Mirabox yet. (Note that the USB controller of the Marvell SoC is *not* the one that controls the USB ports on the back of the
Mirabox: those USB 3.0 ports are controlled by a USB 3.0 controller on the PCIe port).

For now, your choices of root filesystem solutions are:

* initramfs (this is what most of us are doing to bring up those platforms)

* root over NFS, since we have network support for the Mirabox

* USB key on one of the USB 3.0 ports, but that requires you to apply the 16 patches patch set I've sent last Friday on the LAKML to enable the PCIe interfaces of the Armada 370.

Hope this helps,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com