(WIP) Linux Kernel and rootfs 4.14.24 for Seagate Business Storage NAS (CNS3xxx) package

How to create a U-Boot multi-image (with all kernel files embedded).

Sometime we are limited by stock u-boot to boot with a single uImage. And we cannot change the u-boot envs, or just don't want to change them.

Normally we want to boot with separate images because it is much more flexible to replace each with some newer version independenly. But if stock u-boot disables the modification of its envs, then multi-image might be the solution.


Note the colon : is the separator in the images name.

mkimage -A arm -O linux -T multi -C none -a 0x00008000 -e 0x00008000 -n Linux-4.11.3-kirkwood-tld-1 -d vmlinuz-4.11.3-kirkwood-tld-1:initrd.img-4.11.3-kirkwood-tld-1:dts/kirkwood-goflexnet.dtb  uImage

Image Name:   Linux-4.11.3-kirkwood-tld-1
Created:      Fri Jun  2 22:29:55 2017
Image Type:   ARM Linux Multi-File Image (uncompressed)
Data Size:    11008515 Bytes = 10750.50 kB = 10.50 MB
Load Address: 00008000
Entry Point:  00008000
Contents:
   Image 0: 3494088 Bytes = 3412.20 kB = 3.33 MB
   Image 1: 7502514 Bytes = 7326.67 kB = 7.15 MB
   Image 2: 11895 Bytes = 11.62 kB = 0.01 MB

And example of booting with this multi-image.

ext2load usb 0:1 0x800000 /boot/uImage
bootm 0x800000

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 10/26/2021 05:51PM by bodhi.

Thanks, Bodhi.
However, this is not how MontaVista / Blackarmor did this. Here is the Mkimage info from the latest firmware upgrade for the CNS3420:

Image Name: Linux-2.6.35.13-cavm1.whitney-ec
Created: Tue Mar 10 03:09:28 2015
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 8133104 Bytes = 7942.48 kB = 7.76 MB
Load Address: 02000000
Entry Point: 02000000

So, removing the uImage header, there is only the one image, identifying as a Linux kernel. I guess it is just a digression, but at least, if we want to run an initrd, and the memory model of our old U-boot seems to stop us, there is obviously a way. The important part for me, was to extract the initrd mostly because there is some magic going on here, which could possible give me a hint about how to activate som of the remaining hardware :-)

oklona,

It does not look like there is initrd in this image. Probably similar to Arch uImage, everything is compiled into the kernel.

Usually mkimage will list all embedded images.

Note that if you do a binwalk it will show different imformation from mkimage.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Ok, I take it you are then also not familiar with this way of doing things. There is definitely an initrd integrated. I extracted it using binwalk, then un-cpio'ed it, and found all the init.d startup scripts and (weirdly enough) initrd.d startup scripts within. -And the modules, including sopp_cns3xxx_nas, which seems to be the network driver.

It looks like these files are piggybacked to the kernel before compression, I see binwalk lists the initrd to be at 0x28000 (within the kernel.) My current idea is that most of the other files in there is just padding, to make sure initrd ends up at a specific location in memory before being called by the kernel. -And obviously that the original bootcmd points to an initrd being placed there, even though u-boot has actually not been asked to load an initrd into memory.

I was convinced they had done something like this, since the compiled kernel using Seagate's published sources amounts to approx. 3,5 MB, while the uImage in the formware is 8.1 MB. -And obviously, when the root filesystem is placed on an md device, as it is originally on these boxes, you need the initrd to initialize the volumes before mounting root :-)

Ha :) that will work. But a hackish way of doing things.:))

I guess these developers never heard of multi image which has been in u-boot for many years.

Not sure why they did it this way?

Perhaps because their kernel decompression did not work properly.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 02/17/2021 06:31AM by bodhi.

oklona,

Quote

It looks like these files are piggybacked to the kernel before compression, I see binwalk lists the initrd to be at 0x28000 (within the kernel.) My current idea is that most of the other files in there is just padding, to make sure initrd ends up at a specific location in memory before being called by the kernel. -And obviously that the original bootcmd points to an initrd being placed there, even though u-boot has actually not been asked to load an initrd into memory.

So did you extract the initrd successfully?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Yes, I did.

I do have the original initrd. It looks almost ordinary, but there is both the regular "/etc/init.d" folder, containing a lot of startup scripts that don't comply with how init scripts should be written. There is also an "/initrd" folder, containing the following scripts:

-rwxr-xr-x 1 root root   42 Feb  9 08:49 60-sop.sh
-rwxr-xr-x 1 root root 2695 Feb  9 08:49 80-md.sh
-rwxr-xr-x 1 root root 1060 Feb  9 08:49 85-nfsboot.sh

So, the 60-sop.sh simply modprobes the "sopp-cns3xxx-nas" driver, which either IS the NIC driver, or at least loads the NIC driver. The 80-md.sh naturally activates md devices before mounting root. The 85-nfsboot.sh is interesting, as it loads nfs, and prepares to load the root filesystem from NFS. -So there is actually an option to specify root=/dev/nfs nfsroot=xxxxx in the kernel parameters of the original uImage.

All data volumes are RAID1, and upon creation, md devices are initialized with 4 mirrors. -Even for the 2-bay model.

I uploaded the initrd here: https://www.dropbox.com/s/xvcvgqltm2srptb/BA-initrd.cpio.gz?dl=0

Hello,

I have Seagate Business Storage 2-Bay NAS SRN02D (STBN700), but I can't boot the device in any way.
neither usb 2.0/3.0 nor hdd 2,5'' / 3.5''. can you help me?

i can do this https://puchinin.ru/something/seagate-business-storage-2-bay-nas-srn02d-stbn700
thanks

Hi All! I am thinking it may be time to put a newer kernel on my old Seagate Business Storage NAS but I've pretty much forgotten all I learned about it the first time!

Is this box's meager 512 MB of RAM enough to reliably run a Linux 6.2 kernel?

Hi Mark,

> Hi All! I am thinking it may be time to put a
> newer kernel on my old Seagate Business Storage
> NAS but I've pretty much forgotten all I learned
> about it the first time!

So have I :) In the past, I found some info about this Cavium SoC problem, so I'm no longer interested in it.

> Is this box's meager 512 MB of RAM enough to
> reliably run a Linux 6.2 kernel?

512MB is plenty to run kernel 6.2+.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)