Using initrd on Wandboard i.MX6 dual

[Temallius]

Hello,

I've been attempting to get an initrd I created in arch to successfully boot, with no success. The ramdisk was created with the command:
mkinitcpio -g /boot/initrd.gz -v (with compression=gzip and an added hook for 'encrypt' in mkinitcpio.conf)

After which, I wrapped the ramdisk with the command:
mkimage -A arm -O linux -T ramdisk -a 10008000 -e 10008000 -n "Initial Ram Disk" -d initrd.gz initrd.u-boot

which output:
Image Name: Initial Ram Disk
Created: Wed Dec 31 17:39:27 1969
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 2713629 Bytes = 2650.03 kB = 2.59 MB
Load Address: 10008000
Entry Point: 10008000

After 'disabling' both zImage and u-boot.imx in /boot, and creating a uEnv.txt which contains:
video=mxcfb0:dev=hdmi,800x600M@60,if=RGB24
initrd_file=/boot/initrd.u-boot
root=/dev/mmcblk0p1 rootfstype=ext4 rootwait ro

a power-on of the board drops me to a serial console, not booting the initrd.

At the console, I've tried:
ext4load mmc 0:1 10008000 /boot/initrd.u-boot
bootm 10008000

which returns:
## Booting kernel from Legacy Image at 10008000 ...
Image Name: Initial Ram Disk
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 2713629 Bytes = 2.6 MiB
Load Address: 10008000
Entry Point: 10008000
Verifying Checksum ... OK
Wrong Image Type for bootm command
ERROR: can't get kernel image!

...aaaaand I'm stuck. Really stuck. Couldn't pass "-T imximage" to mkimage (and don't even know if that would work). I've been attempting to lurk moar, but most sources are for the RPi or chromebook. Anybody know what I'm doing wrong here? My eventual goal is to get full root encryption, but I'm hung up on the initrd stage.

Thanks in advance

[WarheadsSE]

because bootm uInitrd won't work. You need bootm kernel uinitrd, unles you are using a kernel with a zImage + dtb, which is yet-different.

[Temallius]

Thanks! passing "-T kernel" seems to have worked (with error), returning:
Uncompressing Kernel Image ... Error: inflate() returned -3
GUNZIP: uncompress, out-of-mem or overwrite error - must RESET board to recover

I've chased this issue down to the fact that either my load address or entry point is insufficient for a 2.59Mb kernel, but I'm unsure of what to do. Is there a particular memory range that I should be shooting for?

[WarheadsSE]

What the....

No.

Make initrd, use kernel + initrd

You can't "boot" an initrd.

Don't make me smack you with a manual, son.

[Temallius]

I wish I could find a manual on this. I'm trying to LUKS-ify my entire root directory on "mmcblk0p2" and leave an unencrypted ext4 /boot on mmcblk0p1. Having done this setup on an x64 board, my skills in translating this to an armv7 are sorely lacking. Thus, when you say that both the kernel and the initrd need to be called by bootm, it doesn't make much sense to me (ignorant though i am) since I'd need an initrd with the "encrypt" hook to even see the kernel in the first place. Is this not the correct approach? I'm really just shooting for something that drops me into the "enter password" for LUKS on the root directory. Thanks again.

EDIT: My references: https://wiki.archlinux.org/index.php/Dm ... ire_system
and
viewtopic.php?f=47&t=7071

[WarheadsSE]

http://www.denx.de/wiki/U-Boot/Documentation

[pepedog]

In brief, load zImage/dtb/initrd into memory, then bootz (not bootm) the 3 memory addresses

[Temallius]

Thanks! At the u-boot console, I entered:

ext4load mmc 0:1 42000000 /boot/zImage
ext4load mmc 0:1 44000000 /boot/initrd.u-boot
ext4load mmc 0:1 46000000 /boot/dtbs/imx6dl-wandboard.dtb
bootz 42000000 44000000 46000000

which output:

Kernel image @ 0x42000000 [ 0x000000 - 0x36ed20 ]
## Loading init Ramdisk from Legacy Image at 44000000 ...
Image Name: Initial Ram Disk
Image Type: ARM Linux RAMDisk Image (gzip compressed)
Data Size: 2713611 Bytes = 2.6 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 46000000
Booting using the fdt blob at 0x46000000
Using Device Tree in place at 46000000, end 4600d169

Starting kernel ...

however, at this point, the system hangs. Is there something else I've been missing?

[pepedog]

You don't know if it's hanging, better see your uboot printenv to see what your console= entries are.
You can have more than one, one being the screen (uboot frame buffer permitting) and the other the mx tty
More than likely though it can't find the rootfs and you have rootwait

[kmihelich]

The bigger problem is loading stuff into memory addresses well beyond the 1GB of RAM you have.