Debian on iomega storcenter ix4-200d: succes!

> You can find how to set up to boot the ix4-200d
> with stock u-boot using USB rootfs here:
> http://forum.doozan.com/read.php?3,25120

Sorry, i've quickly read this forum, but i've found (for me, at least ;) relevant info on booting from MTD, not USB. You have pasted wrong link or i'm really dumb? Sorry...

In rootfs and kernel download topic i've found:

> usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params
> usb_rootfstype=ext2

(or =ext3), but is not clear... i need to run:

setenv usb_set_bootargs=...

Thanks.

See this post (in that thread):

http://forum.doozan.com/read.php?3,25120,25675#msg-25675

You will need serial console to try this, to be safe. Don't try to set the u-boot envs in stock OS. Do this permanently only after you have booted into Debian.

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

> You can find how to set up to boot the ix4-200d
> with stock u-boot using USB rootfs here:
> http://forum.doozan.com/read.php?3,25120

Bingo! I was able to boot stock rootfs, after fiddling a bit with correct cut&paste of setenv row into minicom...

But after that, i've upgrade the kernel to the latest 4.8.3 (and really, done a 'apt-get update && apt-get dist-upgrade') and after that seems there's no way to get the system boot back:

Marvell>> boot
(Re)start USB...
USB:   scanning bus for devices... 3 USB Device(s) found
       scanning bus for storage devices... T Device NOT ready
   Request Sense returned 00 00 00
1 Storage Device(s) found
** Bad partition 1 **
** Bad partition 1 **
## Booting image at 00800000 ...
Bad Magic Number

USB key seems ok.
I've tried to connect to my main linux box and get mounted.

But i've also done a 'e2fsck -f' by hand and now i can boot back again.

This is caused by using ext3 as FS? Better to switch to ext2?

root@debian:~# uname -a
Linux debian 4.8.3-kirkwood-tld-1 #1 PREEMPT Thu Oct 20 23:33:18 PDT 2016 armv5tel GNU/Linux

Now, some more experimenting...

> Now, some more experimenting...

Ok, the new kernel see all the 4 disks in bays. Installing 'mdadm' and 'lvm2' i was able to bind and mount the disks. Good.

There's some things i can do for the project? Dump something? A little strange thing:

root@debian:~# fw_printenv 
Cannot read bad block mark: Invalid argument

Next thing to do, i suppose, is upgrade uboot to be able to boot from disks, right?

Another question: digging into the stock firmware, seems that the display can be driven by a program (that accept a PNG image as option) or via a daemon.
There's some way to use the display in debian? And the two buttons right to the display?

Thanks.

marcogaio,

> > You can find how to set up to boot the ix4-200d
> > with stock u-boot using USB rootfs here:
> > http://forum.doozan.com/read.php?3,25120
>
> Bingo! I was able to boot stock rootfs,

That's not "stock" rootfs :) it's my Debian build.

> after
> fiddling a bit with correct cut&paste of setenv
> row into minicom...
>
> But after that, i've upgrade the kernel to the
> latest 4.8.3 (and really, done a 'apt-get update
> && apt-get dist-upgrade')

dist-upgrade is not recommended. dist-upgrade will install mainline Debian kernel.

> Linux debian 4.8.3-kirkwood-tld-1 #1 PREEMPT Thu
> Oct 20 23:33:18 PDT 2016 armv5tel GNU/Linux

This is where you want to be. But if you did dist-upgrade then the kernel will be mainline.

---

Mount the USB rootfs on your other Linux box, and list the /boot folder (if the USB is sdb1)

ls -latr /media/sdb1/boot

Pls post the output here. The idea is to check which kernel you are booting.

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

> That's not "stock" rootfs :) it's my Debian build.

Ahem sorry... i mean 'stock' as 'non upgraded kernel (and DTS). Your last rootfs!

> dist-upgrade is not recommended. dist-upgrade will
> install mainline Debian kernel.

Clearly, i've double checked the package installed/upgraded, doing the dist-upgrade, and none was added.

And i'm really running THIS kernel:
> > Linux debian 4.8.3-kirkwood-tld-1 #1 PREEMPT Thu Oct 20 23:33:18 PDT 2016 armv5tel GNU/Linux

eg, your rootfs upgraded to the latest kernel!


Looking at the forums (i'm a bit confused by forums, a wiki i think will be better for such things...) seems to me that:

a) there's no an upgraded uboot for the ix4-200d, but seems that the stock firmware can boot to HD.

b) there's a way to boot an ''intermediate bootloader'', but here i'm totally lost

c) there's some way to drive the display and buttons, but really i've not understand how.

d) i need to ''map'' correctly the MTD to be able to use fw_printenv (and fw_* generally); also here i'm lost.

Again, say me if i can do something useful... and thanks!

marcogaio,

> Clearly, i've double checked the package
> installed/upgraded, doing the dist-upgrade, and
> none was added.

That's why I want to see the /boot directory. I want to doublecheck what kernel uImage and uInitrd files are being used.

> a) there's no an upgraded uboot for the ix4-200d,
> but seems that the stock firmware can boot to HD.

Yes, stock u-boot can boot USB and HDD.

> b) there's a way to boot an ''intermediate
> bootloader'', but here i'm totally lost

Not needed.

> d) i need to ''map'' correctly the MTD to be able
> to use fw_printenv (and fw_* generally); also here
> i'm lost.

Correct. Look for the content of the file /etc/fw_env.config. In Reto's thread: http://forum.doozan.com/read.php?3,25120, there should be description of this. It needs to match what was in stock rootfs (in NAND flash).

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



Edited 2 time(s). Last edit at 12/09/2016 03:40PM by bodhi.

> > Clearly, i've double checked the package
> > installed/upgraded, doing the dist-upgrade, and
> > none was added.
> That's why I want to see the /boot directory. I
> want to doublecheck what kernel uImage and uInitrd
> files are being used.

Ok, as you want...

root@albus:~# ls -la /mnt/boot/
totale 66968
drwxr-xr-x  4 root root    4096 dic  9 18:45 .
drwxr-xr-x 21 root root    4096 feb 17  2015 ..
-rw-r--r--  1 root root  140949 gen 26  2016 config-4.4.0-kirkwood-tld-1
-rw-r--r--  1 root root  146396 ott 21 07:38 config-4.8.3-kirkwood-tld-1
drwxr-xr-x  2 root root    4096 ott 23 10:51 dts
drwxr-xr-x  2 root root    4096 gen 26  2016 dts.orig
-rw-r--r--  1 root root 7181487 dic  9 15:23 initrd.img-4.4.0-kirkwood-tld-1
-rw-r--r--  1 root root 8718700 dic  9 18:45 initrd.img-4.8.3-kirkwood-tld-1
-rw-r--r--  1 root root 7511582 gen 26  2016 linux-headers-4.4.0-kirkwood-tld-1_1.0_armel.deb
-rw-------  1 root root 2240040 gen 26  2016 System.map-4.4.0-kirkwood-tld-1
-rw-------  1 root root 2361548 ott 21 11:30 System.map-4.8.3-kirkwood-tld-1
-rw-r--r--  1 root root 3241908 dic  9 15:34 uImage
-rw-r--r--  1 root root 3164416 dic  7 18:49 uImage.old
-rw-r--r--  1 root root 7342651 dic  9 15:35 uInitrd
-rw-r--r--  1 root root 7179935 dic  9 15:34 uInitrd.old
-rw-------  1 root root 3154832 gen 26  2016 vmlinuz-4.4.0-kirkwood-tld-1
-rw-------  1 root root 3232304 ott 21 11:30 vmlinuz-4.8.3-kirkwood-tld-1
-rwxr-xr-x  1 root root 3154832 gen 26  2016 zImage-4.4.0-kirkwood-tld-1
-rwxr-xr-x  1 root root 3232304 dic  9 15:31 zImage-4.8.3-kirkwood-tld-1
-rwxr-xr-x  1 root root 3241844 dic  9 15:33 zImage.fdt
-rwxr-xr-x  1 root root 3164352 dic  9 15:32 zImage.fdt.old

New kernel and initrd was installed via dpkg -i for the kernel package. New 'dts' dir was unpacked from tarballs (where the new .deb kernel reside.
zImage, uImage and uInitrd was generated with:

cp -a zImage-4.8.3-kirkwood-tld-1 zImage.fdt
cat dts/kirkwood-iomega_ix4_200d.dtb >> zImage.fdt
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-4.8.3-kirkwood-tld-1 -d zImage.fdt  uImage
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-4.8.3-kirkwood-tld-1 -d initrd.img-4.8.3-kirkwood-tld-1 uInitrd

Thanks for all the answer. For point c), eg, buttons and display?

marcogaio,

ls -lart  /mnt/boot/

There is an important reason to always see the files listing in reversed chronological order. You'll be abe to check mistake easily that way.

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



Edited 1 time(s). Last edit at 12/10/2016 04:39PM by bodhi.

> ls -lart /mnt/boot/
> There is an important reason to always see the
> files listing in reversed chronological order.
> You'll be abe to check mistake easily that way.

Ok, sure, but still i don't see the point:

root@albus:~# ls -lart  /mnt/boot/
totale 66968
drwxr-xr-x 21 root root    4096 feb 17  2015 ..
-rw-r--r--  1 root root  140949 gen 26  2016 config-4.4.0-kirkwood-tld-1
-rwxr-xr-x  1 root root 3154832 gen 26  2016 zImage-4.4.0-kirkwood-tld-1
-rw-------  1 root root 3154832 gen 26  2016 vmlinuz-4.4.0-kirkwood-tld-1
-rw-------  1 root root 2240040 gen 26  2016 System.map-4.4.0-kirkwood-tld-1
-rw-r--r--  1 root root 7511582 gen 26  2016 linux-headers-4.4.0-kirkwood-tld-1_1.0_armel.deb
drwxr-xr-x  2 root root    4096 gen 26  2016 dts.orig
-rw-r--r--  1 root root  146396 ott 21 07:38 config-4.8.3-kirkwood-tld-1
-rw-------  1 root root 3232304 ott 21 11:30 vmlinuz-4.8.3-kirkwood-tld-1
-rw-------  1 root root 2361548 ott 21 11:30 System.map-4.8.3-kirkwood-tld-1
drwxr-xr-x  2 root root    4096 ott 23 10:51 dts
-rw-r--r--  1 root root 3164416 dic  7 18:49 uImage.old
-rw-r--r--  1 root root 7181487 dic  9 15:23 initrd.img-4.4.0-kirkwood-tld-1
-rwxr-xr-x  1 root root 3232304 dic  9 15:31 zImage-4.8.3-kirkwood-tld-1
-rwxr-xr-x  1 root root 3164352 dic  9 15:32 zImage.fdt.old
-rwxr-xr-x  1 root root 3241844 dic  9 15:33 zImage.fdt
-rw-r--r--  1 root root 3241908 dic  9 15:34 uImage
-rw-r--r--  1 root root 7179935 dic  9 15:34 uInitrd.old
-rw-r--r--  1 root root 7342651 dic  9 15:35 uInitrd
-rw-r--r--  1 root root 8718700 dic  9 18:45 initrd.img-4.8.3-kirkwood-tld-1
drwxr-xr-x  4 root root    4096 dic  9 18:45 .

Note that the initrd is newer because i've installed some package that have regenerated it (like mdadm and lvm2), so i know i'm booting the old initrd (because i've not mkimage-d it).

Also, i've noted now that zImage-* is the same file as vmlinuz-*:

root@albus:/mnt/boot# md5sum vmlinuz-4.8.3-kirkwood-tld-1 zImage-4.8.3-kirkwood-tld-1
128a840b0b58ee47492ef185bd520b5f  vmlinuz-4.8.3-kirkwood-tld-1
128a840b0b58ee47492ef185bd520b5f  zImage-4.8.3-kirkwood-tld-1

Probably all this stuff can be scripted...

Precisely, uInitrd is old. And that is no good.

And furthermore, even you did not see newer mainline kernel files afer apt-get dist-upgrade this time, it does not mean that you want to do that in the future.

I'm speaking in general to other users who are reading this, too.

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



Edited 1 time(s). Last edit at 12/10/2016 08:18PM by bodhi.

> Precisely, uInitrd is old. And that is no good.

As stated, i've installed some package (mdadm, lvm2) that trigger an initrd rebuild, but i've not put / (root) filesystem on software raid or LVM, so i've not re mkimage-ed it.

> And furthermore, even you did not see newer
> mainline kernel files afer apt-get dist-upgrade
> this time, it does not mean that you want to do
> that in the future.
> I'm speaking in general to other users who are
> reading this, too.

This is true. Generally speaking doing a dist upgrade can be dangerous, without some caution...

I'm having trouble booting from HDD, i catch CRC errors.

I'm using the same rootfs of the my USB key, that work flawlessy. Same Kernel, Same Initrd. The only different things is the partiton setup: i've created a little (1GB) /dev/sda1 partition with /boot.

I'm using to boot this environment:

Marvell>> setenv usb_make_boot_args 'setenv bootargs console=ttyS0,115200 mtdparts=orion_nand:$(uboot_size)@$(uboot_start)(uboot),$(env_size)@$(env_start)(env),$(kernel_si
ze)@$(kernel_start)(zImage),$(initrd_size)@$(initrd_start)(initrd),32m@0x0(flash) root=LABEL=rootfs rootdelay=10'
Marvell>> setenv load_initrd 'ext2load scsi 0:1 0x1100000 /uInitrd' 
Marvell>> setenv load_uimage 'ext2load scsi 0:1 0x800000 /uImage' 
Marvell>> setenv sata_boot 'ide reset; run load_uimage; run load_initrd; bootm 0x800000 0x1100000'
Marvell>> setenv bootcmd 'run usb_make_boot_args ; run sata_boot; reset'

and i get:

Reset IDE: 
Marvell Serial ATA Adapter
Integrated Sata device found


3241908 bytes read

7342651 bytes read
## Booting image at 00800000 ...
   Image Name:   Linux-4.8.3-kirkwood-tld-1
   Created:      2016-12-09  14:34:33 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3241844 Bytes =  3.1 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC

What i'm doing wrong now?

Thanks.

PS: I've forgot to say... partition seems accessible:

Marvell>> ext2ls scsi 0:1
<DIR>       4096 .
<DIR>       4096 ..
<DIR>      16384 lost+found
          140949 config-4.4.0-kirkwood-tld-1
         3154832 vmlinuz-4.4.0-kirkwood-tld-1
         7342651 uInitrd
         7179871 initrd.img-4.4.0-kirkwood-tld-1
         2240040 System.map-4.4.0-kirkwood-tld-1
<DIR>       4096 dts
         3241908 uImage
         7511582 linux-headers-4.4.0-kirkwood-tld-1_1.0_armel.deb
         3154832 zImage-4.4.0-kirkwood-tld-1
         3164416 uImage.old
         3164352 zImage.fdt
         7179935 uInitrd.old

and if i boot on USB, because i've defined the partition /dev/sda3 as 'rootfs', i boot straight to the hdd, not USB.



Edited 1 time(s). Last edit at 01/18/2017 05:32PM by marcogaio.

Ahem... some hint/feedback on how the same kernel boot from USB and return 'CRC error' on sata?

Thanks.

marcogaio,

> Ahem... some hint/feedback on how the same kernel
> boot from USB and return 'CRC error' on sata?
>

It usually happens if

1. After the uImage was generated, you forgot to do a sync before reboot.
2. the uImage was a wrong type, e.g. generated for a different architecture.Things like that.


This problem would go away if you regenerate it on the ix4-200d, and do a few syncs before reboot.

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

I was sure i've done the right things, anyway i've redone all the stuff.

I'm using exactly the same kernel/initrd that boot on the USB key; i've copied them on the HD and i've double checked it (the USB key is mounted as /mnt, of course):

root@debian:/boot# md5sum uI* /mnt/boot/uI*
408fd043a0e53507adead04e1080b270  uImage
74cec6beff390144c60de3f2ecb0e725  uImage.old
050de4fe74883241660fa03b8095dc55  uInitrd
bff4c384ee2fd25ef37ee16fccb635b0  uInitrd.old
408fd043a0e53507adead04e1080b270  /mnt/boot/uImage
74cec6beff390144c60de3f2ecb0e725  /mnt/boot/uImage.old
050de4fe74883241660fa03b8095dc55  /mnt/boot/uInitrd
bff4c384ee2fd25ef37ee16fccb635b0  /mnt/boot/uInitrd.old

Still, both the kernel return 'CRC error':

Marvell>> setenv usb_make_boot_args 'setenv bootargs console=ttyS0,115200 mtdparts=orion_nand:$(uboot_size)@$(uboot_start)(uboot),$(env_size)@$(env_start)(env),$(kernel_si
ze)@$(kernel_start)(zImage),$(initrd_size)@$(initrd_start)(initrd),32m@0x0(flash) root=LABEL=rootfs rootdelay=10'
Marvell>> setenv load_initrd 'ext2load scsi 0:1 0x1100000 /uInitrd' 
Marvell>> setenv load_uimage 'ext2load scsi 0:1 0x800000 /uImage' 
Marvell>> setenv sata_boot 'ide reset; run load_uimage; run load_initrd; bootm 0x800000 0x1100000'
Marvell>> setenv bootcmd 'run usb_make_boot_args ; run sata_boot; reset'
Marvell>> boot

Reset IDE: 
Marvell Serial ATA Adapter
Integrated Sata device found


3241908 bytes read

7342651 bytes read
## Booting image at 00800000 ...
   Image Name:   Linux-4.8.3-kirkwood-tld-1
   Created:      2016-12-09  14:34:33 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3241844 Bytes =  3.1 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC

Marvell>> setenv usb_make_boot_args 'setenv bootargs console=ttyS0,115200 mtdparts=orion_nand:$(uboot_size)@$(uboot_start)(uboot),$(env_size)@$(env_start)(env),$(kernel_si
ze)@$(kernel_start)(zImage),$(initrd_size)@$(initrd_start)(initrd),32m@0x0(flash) root=LABEL=rootfs rootdelay=10'
Marvell>> setenv load_initrd 'ext2load scsi 0:1 0x1100000 /uInitrd.old'
Marvell>> setenv load_uimage 'ext2load scsi 0:1 0x800000 /uImage.old'
Marvell>> setenv sata_boot 'ide reset; run load_uimage; run load_initrd; bootm 0x800000 0x1100000'
Marvell>> setenv bootcmd 'run usb_make_boot_args ; run sata_boot; reset'
Marvell>> boot

Reset IDE: 
Marvell Serial ATA Adapter
Integrated Sata device found


3164416 bytes read

7179935 bytes read
## Booting image at 00800000 ...
   Image Name:   Linux-4.4.0-kirkwood-tld-1
   Created:      2016-12-07  17:49:51 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3164352 Bytes =  3 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC

Boh...

marcogaio,

Why did you use scsi ? is that because of the current stock u-boot?

Marvell>> setenv load_initrd 'ext2load scsi 0:1 0x1100000 /uInitrd' 
Marvell>> setenv load_uimage 'ext2load scsi 0:1 0x800000 /uImage'

Did you try this?

Marvell>> setenv load_initrd 'ext2load ide 0:1 0x1100000 /uInitrd' 
Marvell>> setenv load_uimage 'ext2load ide 0:1 0x800000 /uImage'

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

I've had tried 'sata' with no luck, so i think SCSI was the correct option. Sorry.

Anyway, same result:

Marvell>> setenv usb_make_boot_args 'setenv bootargs console=ttyS0,115200 mtdparts=orion_nand:$(uboot_size)@$(uboot_start)(uboot),$(env_size)@$(env_start)(env),$(kernel_si
ze)@$(kernel_start)(zImage),$(initrd_size)@$(initrd_start)(initrd),32m@0x0(flash) root=LABEL=rootfs rootdelay=10'
Marvell>> setenv load_initrd 'ext2load ide 0:1 0x1100000 /uInitrd' 
Marvell>> setenv load_uimage 'ext2load ide 0:1 0x800000 /uImage' 
Marvell>> setenv sata_boot 'ide reset; run load_uimage; run load_initrd; bootm 0x800000 0x1100000'
Marvell>> setenv bootcmd 'run usb_make_boot_args ; run sata_boot; reset'
Marvell>> boot

Reset IDE: 
Marvell Serial ATA Adapter
Integrated Sata device found

** Bad partition 1 **
** Bad partition 1 **
## Booting image at 00800000 ...
   Image Name:   Linux-4.8.3-kirkwood-tld-1
   Created:      2017-01-31  21:44:30 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3241844 Bytes =  3.1 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC

Note the 'Bad partition 1' message that does not happen on SCSI...

marcogaio Wrote:
-------------------------------------------------------
> I've had tried 'sata' with no luck, so i think SCS
> I was the correct option. Sorry.
>
> Anyway, same result:
>

> Marvell>> setenv usb_make_boot_args 'setenv bootar
> gs console=ttyS0,115200 mtdparts=orion_nand:$(uboo
> t_size)@$(uboot_start)(uboot),$(env_size)@$(env_st
> art)(env),$(kernel_si
> ze)@$(kernel_start)(zImage),$(initrd_size)@$(initr
> d_start)(initrd),32m@0x0(flash) root=LABEL=rootfs
> rootdelay=10'
> Marvell>> setenv load_initrd 'ext2load ide 0:1 0x1
> 100000 /uInitrd'
> Marvell>> setenv load_uimage 'ext2load ide 0:1 0x8
> 00000 /uImage'
> Marvell>> setenv sata_boot 'ide reset; run load_ui
> mage; run load_initrd; bootm 0x800000 0x1100000'
> Marvell>> setenv bootcmd 'run usb_make_boot_args ;
> run sata_boot; reset'
> Marvell>> boot
> 
> Reset IDE:
> Marvell Serial ATA Adapter
> Integrated Sata device found
> 
> ** Bad partition 1 **
> ** Bad partition 1 **
> ## Booting image at 00800000 ...
> Image Name:   Linux-4.8.3-kirkwood-tld-1
> Created:      2017-01-31  21:44:30 UTC
> Image Type:   ARM Linux Kernel Image (uncompres
> sed)
> Data Size:    3241844 Bytes =  3.1 MB
> Load Address: 00008000
> Entry Point:  00008000
> Verifying Checksum ... Bad Data CRC
>

>
> Note the 'Bad partition 1' message that does not h
> appen on SCSI...

I see. This is how this stock u-boot was buillt then.

Last question: were you the root user when you tar the rootfs to the HDD? and being root the whole time after that?

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

bodhi Wrote:

> Last question: were you the root user when you tar
> the rootfs to the HDD? and being root the whole ti
> me after that?

Do you mean 'untar' i suppose... yes, i was root. Effectively, i've boot into the USB key and then partition, format and untar your rootfs tarball into the HD.

All done as root.

> Do you mean 'untar' i suppose... yes, i was root.
> Effectively, i've boot into the USB key and then p
> artition, format and untar your rootfs tarball int
> o the HD.
>
> All done as root.

So the HDD rootfs is new, not the same one you run on USB.

Can you backup (tar) the USB rootfs, and "untar" it to the HDD (using a different Linux box)?

In case you need to refresh your memory, this is in the Wiki
http://forum.doozan.com/read.php?2,12096,24034#msg-24034

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



Edited 1 time(s). Last edit at 01/31/2017 04:30PM by bodhi.

bodhi Wrote:

> So the HDD rootfs is new, not the same one you run
> on USB.

Yes. They both use the same 'source' tarball, indeed.

> Can you backup (tar) the USB rootfs, and "untar"
> it to the HDD (using a different Linux box)?

I will try. But i don't understand how can be correlated... the CRC error are about the kernel, that is a file...

> I will try. But i don't understand how can be corr
> elated... the CRC error are about the kernel, that
> is a file...

It is just saying the uImage file is bad, for whatever reason. So cloning a working rootfs is a sure way to eliminate al other variables.

Sometime if this drive has file system errors, the uImage will be bad, too. Did you run fsck on this HDD parttion?

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

Sash Wrote:
-------------------------------------------------------
> just for the record. these are the 2 different iom
> ega storcenter ix4-200d uboot versions the differe
> nt revisions of the unit was delivered with.
>
> i can also provide a wholeflash backup of the clou
> d und noncloud version on request if there is any
> demand.....

Hi Sash, do you have a wholeflash backup of the cloud edition?

tks,

Gastal

Hi

as long as your bootloader is still intact you can always do a recovery....just google how to do it. you can also recover to the cloud edition this way.....but who wants the orig fw if you can have debian running instead?!

Sash. Wrote:
-------------------------------------------------------
> Hi
>
> as long as your bootloader is still intact you can
> always do a recovery....just google how to do it.
> you can also recover to the cloud edition this way
> .....but who wants the orig fw if you can have deb
> ian running instead?!


Hi Sash,
I don't have bootloader because I accidentially erased the whole NAND Flash. With this wholeflash backup can I flash the nand using kwboot?

Tks,
Gastal

without a working uboot you have a brick. you will have to flash uboot via jtag (dont know if the jtag pins a populated). anyway 1st thing would be to add an serial connection and check whats alive....

Sash. Wrote:
-------------------------------------------------------
> without a working uboot you have a brick. you will
> have to flash uboot via jtag (dont know if the jta
> g pins a populated). anyway 1st thing would be to
> add an serial connection and check whats alive....

Sash,

Have you tried kwboot this box? if you have not, try it.

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



Edited 1 time(s). Last edit at 05/10/2017 03:16PM by bodhi.

The serial connection it's OK. I can connect and boot the board with kwboot. I am researching how to flash uboot and then flash your wholeflash backup.

@Sash,

Have you tried kwboot this box? if you have not, try it. See here:

http://forum.doozan.com/read.php?3,7852,31082#msg-31082

@Gastal,

Connect serial console and you can unbrick this easily.

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