installation on ix2-200, unable to boot kernel

This forum is for Marvell Kirkwood devices such as the GoFlex Home/Net, PogoPlug v1/v2, SheevaPlug, and ZyXEL devices.

Re: installation on ix2-200, unable to boot kernel

Postby summers » Fri Sep 18, 2020 10:53 am

Hmm. OK looking at uboot variables this is what it seems to be doing. First several environment variables are used:

Code: Select all
memoffset_kernel=0x02000000
memoffset_initrd=0x08004000
bootargs_console=console=ttyS0,115200
bootargs_mtdparts=mtdparts=orion_nand:640k(u-boot)ro,16k(u-boot-env),-(iomega-firmware)ro
bootargs_root=root=LABEL=ROOT rw


Then usb_load is run:
Code: Select all
setenv bootargs ${bootargs_console} ${bootargs_mtdparts} ${bootargs_root};
usb reset;
ext2load usb 0:1 ${memoffset_kernel} /uImage;
ext2load usb 0:1 ${memoffset_initrd} /uInitrd;
bootm ${memoffset_kernel} ${memoffset_initrd};


Then sata_load is run:
Code: Select all
setenv bootargs ${bootargs_console} ${bootargs_mtdparts} ${bootargs_root};
ide reset;
ext2load ide 0:1 ${memoffset_kernel} /uImage;
ext2load ide 0:1 ${memoffset_initrd} /uInitrd;
ext2load ide 1:1 ${memoffset_kernel} /uImage;
ext2load ide 1:1 ${memoffset_initrd} /uInitrd;
bootm ${memoffset_kernel} ${memoffset_initrd};


To my mind what to note is that usb_load is always run first, and it has no tests for bits failing, so I guess it always runs the
Code: Select all
bootm ${memoffset_kernel} ${memoffset_initrd};
at the end.

Now look at you boot, it scans USB as told, then it doesn't find any devices, then it runs the boot. But as it hasn't found any usb devices, it hasn't loaded the uImage or the uInitrd, it fails during the boot.

So looks like your boot process is wrong, it never gets to the sata_load.

But whats odd, is bootm is saying it has found uimages at the locations in memory passed to it.

I'd be tempted to type commands by hand and see what is needed, then adapt the uboot env as needed. Couldn't see the offset error you said the device tree kernel image had, but yet its the kind of think to check. Pity you can't do the modern way of passing the device tree (as third argument to boot), so have to use the hack of adding it to the end of the kernel image.

Have to wonder if anyone has done a modern uboot for the box, as you have the uart connected my be tempted to do the kwboot across the uart, to try more modern uboot. Only do this is you know what you are doing though ...
summers
 
Posts: 923
Joined: Sat Sep 06, 2014 12:56 pm

Re: installation on ix2-200, unable to boot kernel

Postby summers » Fri Sep 18, 2020 11:39 am

And this is interesting:
ALERT! When booting images that have been loaded to RAM (for instance using TFTP download) you have to be careful that the locations where the (compressed) images were stored do not overlap with the memory needed to load the uncompressed kernel. For instance, if you load a ramdisk image at a location in low memory, it may be overwritten when the Linux kernel gets loaded. This will cause undefined system crashes.
from http://www.denx.de/wiki/publish/DULG/to-delete/UBootCmdGroupExec.html and I note that your images uncompress to the same area of memory, as where the compressed images are. Alas being some time since I used uImages - so trying to remember how to do addresses ...
summers
 
Posts: 923
Joined: Sat Sep 06, 2014 12:56 pm

Re: installation on ix2-200, unable to boot kernel

Postby summers » Sat Sep 19, 2020 11:36 am

Did some digging last night as had some free time, to try and find the memory layout of the ix-200 -and sod all info out there.

But then noticed something odd, you are putting a zImage into the uImage. Now I can understand why, as your uboot can only do uImage, but this is odd becuase both zImage and uImage are compressed, so this is not normally done as no point in compressing an image twice. But it gets worse on running. uImages contain a load address, that gives where to uncompress the image to; and zImages uncompress themselves to the bottom part of lowmem - I forget the address its something like 0x8000.

But this gives you more of a problem, in uboot you load the uImage to one address, it needs to decompresed zImage to a new bit of memory. zImage then runs, and decompresses to the lowmen. So means you need to know your memory layout quite well.

Just trying to dig into what the old settings were from me on my NSA325, as its also kirkwood - and so give hints on how your board is set up.

Surprising bit is that a zImage that uncopmpresses to the same memory at the uImage, with the non device tree boots. So can you check what address it decompresses to - that will give hints. Also what image does it contain? is it compressed, zImage, or not, Image?
summers
 
Posts: 923
Joined: Sat Sep 06, 2014 12:56 pm

Re: installation on ix2-200, unable to boot kernel

Postby Schlunze » Sun Sep 20, 2020 7:44 pm

Hello,

same here. Booting dt kernel is not possible.

Greetings
Schlunze
 
Posts: 9
Joined: Tue Aug 20, 2019 3:27 pm

Re: installation on ix2-200, unable to boot kernel

Postby kriztioan » Sun Sep 20, 2020 9:06 pm

@Schlunze linux-kirkwood-dt 5.8.9-1 works just fine on my ix2-200.

Code: Select all
$ cat /proc/device-tree/model
Iomega StorCenter ix2-200

Code: Select all
$ pacman -Q | grep kirkwood
linux-kirkwood-dt 5.8.9-1
linux-kirkwood-dt-headers 5.8.9-1

Code: Select all
$ uname -a
Linux Twonky 5.8.9-1-ARCH #1 PREEMPT Sat Sep 12 23:08:31 UTC 2020 armv5tel GNU/Linux

Code: Select all
$ file /boot/uImage
/boot/uImage: u-boot legacy uImage, Arch Linux ARM kernel, Linux/ARM, OS Kernel Image (Not compressed), 6196752 bytes, Mon Sep 14 15:20:52 2020, Load Address: 0x00008000, Entry Point: 0x00008000, Header CRC: 0x37415B49, Data CRC: 0xB2A2B64B

Code: Select all
$ file /boot/uInitrd
uInitrd: u-boot legacy uImage, Arch Linux ARM initrd, Linux/ARM, RAMDisk Image (gzip), 9320072 bytes, Tue Sep 15 15:48:23 2020, Load Address: 0x08004000, Entry Point: 0x08004000, Header CRC: 0x64998C23, Data CRC: 0x15AF359D

Actually, my current is the second ix2-200 I converted to ALARM as my first had network issues and couldn't make a 1Gb/s connection.

@summers https://www.kernel.org/doc/Documentation/arm/Booting discusses, among other things, the recommended memory layout.

We'll have to hear back from @Abzstrak if the fixed mkimage-command resolves his issue and, if not, the image I pm'ed him at least works. In order the help out @Schlunze we'll need to know whether he experiences the same issue as @Abzstrak or something totally different.
kriztioan
 
Posts: 51
Joined: Sat Apr 29, 2017 1:32 am

Re: installation on ix2-200, unable to boot kernel

Postby summers » Mon Sep 21, 2020 9:12 am

Bingo.

Crux that you've done with the uImage for the dt kernel is that its not compressed, and has the load (and execute) address as 0x00008000 - so thats what people need to do when making the uImage.

Guess a question is now did you create, did you do "make uImage" with the PKGBUILD file, or did you modify the files that come in the package?
summers
 
Posts: 923
Joined: Sat Sep 06, 2014 12:56 pm

Re: installation on ix2-200, unable to boot kernel

Postby kriztioan » Mon Sep 21, 2020 3:58 pm

Yes, per http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html#d0e309: "Despite the ability to place zImage anywhere within memory, convention has it that it is loaded at the base of physical RAM plus an offset of 0x8000 (32K)."

While I did detail some of this in https://archlinuxarm.org/forum/viewtopic.php?f=53&t=13477&p=61065#p60790, it seems I didn't explicitly mention the mkimage-command ...

The zImage that comes with the package is turned into an uImage using the following.

Code: Select all
pacman -S linux-kirkwood-dt
cp /boot/zImage /boot/zImage-dtb
cat /boot/dtbs/kirkwood-iomega_ix2_200.dtb >> /boot/zImage-dtb
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n "Arch Linux ARM kernel" -d /boot/zImage-dtb /boot/uImage
kriztioan
 
Posts: 51
Joined: Sat Apr 29, 2017 1:32 am

Re: installation on ix2-200, unable to boot kernel

Postby summers » Tue Sep 22, 2020 8:45 am

Thats a great find. I knew that the zImage was self extracting, but didn't know that it could extract itself to the same address as the compressed file. Thats actually a clever design, as it means you can use a zImage just like a normal image. Also good think of you to pass "-C none", clever way of coping with double compression. Anyway looks like a good solution.
summers
 
Posts: 923
Joined: Sat Sep 06, 2014 12:56 pm

Previous

Return to Marvell Kirkwood

Who is online

Users browsing this forum: No registered users and 3 guests