Your kernel patches for the Marvell Mirabox

Your kernel patches for the Marvell Mirabox

[Jason Cooper]

On Sun, Dec 09, 2012 at 04:21:12PM +0100, Bernd wrote:
> Hello Jason,

Hi Bernd!

> 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.

> 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
> 
> 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.

> $ 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.

Your kernel patches for the Marvell Mirabox

[Thomas Petazzoni]

Dear Jason Cooper,

On Mon, 10 Dec 2012 09:02:02 -0500, Jason Cooper wrote:

> 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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Your kernel patches for the Marvell Mirabox

[Jason Cooper]

On Mon, Dec 10, 2012 at 04:27:29PM +0100, Thomas Petazzoni wrote:
> Dear Jason Cooper,
> 
> On Mon, 10 Dec 2012 09:02:02 -0500, Jason Cooper wrote:
> 
> > 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.

Your kernel patches for the Marvell Mirabox

[Bernd]

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


On 2012-12-10 15:02, Jason Cooper wrote:
> On Sun, Dec 09, 2012 at 04:21:12PM +0100, Bernd wrote:
>> Hello Jason,
> 
> Hi Bernd!
> 
>> 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.
> 
>> 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
>>
>> 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.
> 
>> $ 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.

Your kernel patches for the Marvell Mirabox

[Thomas Petazzoni]

Dear Bernd,

On Tue, 11 Dec 2012 01:43:28 +0100, Bernd wrote:

> 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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Your kernel patches for the Marvell Mirabox

[Bernd]

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


On 2012-12-11 16:15, Thomas Petazzoni wrote:
> Dear Bernd,
> 
> On Tue, 11 Dec 2012 01:43:28 +0100, Bernd wrote:
> 
>> 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
> 

Your kernel patches for the Marvell Mirabox

[Thomas Petazzoni]

Dear Bernd,

On Tue, 11 Dec 2012 22:15:06 +0100, Bernd wrote:

> 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.

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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Your kernel patches for the Marvell Mirabox

[Bernd]

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

On 2012-12-12 09:31, Thomas Petazzoni wrote:
> Dear Bernd,
> 
> On Tue, 11 Dec 2012 22:15:06 +0100, Bernd wrote:
> 
>> 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.
> 
> 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

Your kernel patches for the Marvell Mirabox

[Thomas Petazzoni]

Dear Bernd,

On Wed, 12 Dec 2012 21:01:45 +0100, Bernd wrote:

> 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.

> 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?

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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com