I was trying to get Debian working on an original model Iomega IX2-200 but it was very erratic about booting from a USB stick. It would boot maybe one out of four times and often complained nothing was plugged into a USB port even when it had just successfully booted from the same port. I was looking into flashing the iConnect uboot version into this device and had the serial cable connected in a minicom session. After booting into the original Iomega software from hard disk, the serial connection would show occasional system messages including a bunch like these:

hub 1-1:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
hub 1-1:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
hub 1-1:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
hub 1-1:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
usb 1-1.2: new low speed USB device using ehci_marvell and address 36
usb 1-1.2: device descriptor read/64, error -32
usb 1-1.2: device descriptor read/64, error -32
usb 1-1.2: new low speed USB device using ehci_marvell and address 37
usb 1-1.2: device descriptor read/64, error -32
usb 1-1.2: device descriptor read/64, error -32
usb 1-1.2: new low speed USB device using ehci_marvell and address 38
usb 1-1.2: device not accepting address 38, error -32
usb 1-1.2: new low speed USB device using ehci_marvell and address 39
usb 1-1.2: device not accepting address 39, error -32

This would reoccur every 4 minutes or so. DMESG and the archived system logs showed this as well. It may have been happening for years unnoticed since I never used the USB ports running the IX2 as a two disk raid1. Running on just the hard drives, the IX2 has been a solid performer for years. If there is something wrong with the USB interface, could a new Debian be installed from a SATA disk or is this a sign of worse to come?

dougdeep,

> It would boot maybe one
> out of four times and often complained nothing was
> plugged into a USB port even when it had just
> successfully booted from the same port.

Some stock u-boot is quite inconsistent recognizing the USB thumb drive. Switching to a better thumb drive brand such as Sandisk would help.

However, the Iomega iX2-200/400 series are particularly bad with USB drives.


> I was
> looking into flashing the iConnect uboot version
> into this device and had the serial cable
> connected in a minicom session.

Don't do that! iConnect is a different box. If you flash the wrong u-boot, you will brick the box. Try kwboot booting first before you can experiment, so that you have some idea which u-boot version is most compatible with this box.

> If there is something wrong with the USB
> interface, could a new Debian be installed from a
> SATA disk

Lots of people installed Debian rootfs on the HDD, and use this box stock u-boot to boot it.

> or is this a sign of worse to come?

I would not be worry about that stock OS error. Sometime it is just a lack of USB definition in the kernel that results in this kind of error.

I can't recall if there is particular problem that will prevent you from booting a USB rootfs.

You should create the Debian rootfs on USB and try booting it. The DTB file for this box is /boot/dts/kirkwood-iomega_ix2_200.dtb.

If at u-boot prompt in serial console, you can do this and got the USB drive initialized, then you can boot with USB rootfs on this box.

usb reset

repeat the command a few times to see if the USB drive is initialized.

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

This Iomega box is resisting any attempt at USB booting.
>If at u-boot prompt in serial console, you can do this and got the USB drive initialized, then you can boot
>with USB rootfs on this box.

usb reset

>repeat the command a few times to see if the USB drive is initialized.

I tried 5 different USB sticks, including a new-in-package Sandisk Cruzer. All were formatted EXT2 or EXT3. Most of the time the reset command got me a message that 1 USB device found but no storage devices. It would only boot (or start to boot) if it said there was a storage device found.

On the other hand, the uboot ide reset command always seems to show what is plugged in:

Marvell>> ide reset

Reset IDE: 
Marvell Serial ATA Adapter
Integrated Sata device found
[0 0 0]: Enable DMA mode
  Device 0 @ 0 0:
Model: ST500DM009-2F110A                        Firm: CC43     Ser#:             Z993BJNS
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
[0 1 0]: Enable DMA mode
  Device 1 @ 0 1:
Model: ST500DM009-2DM14C                        Firm: CC46     Ser#:             Z4X19GKG
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)

I have a stack of spare notebook SATA drives that I can experiment with. Would replacing the two RAID disks with an EXT3 formatted drive set up like your instruction for a USB stick work? It seems like I just need to change the bootargs and bootcmd ENVs that reference "USB" to "IDE" to get things going or am I missing something important?

> I have a stack of spare notebook SATA drives that
> I can experiment with. Would replacing the two
> RAID disks with an EXT3 formatted drive set up
> like your instruction for a USB stick work? It
> seems like I just need to change the bootargs and
> bootcmd ENVs that reference "USB" to "IDE" to get
> things going or am I missing something important?

Yes, try that. Replace "usb" with 'ide".

First, make sure you can initialize the SATA drive

ide reset
ide part
ext2ls ide 0:1 /

If all looks good then you'll know you can boot with the SATA rootfs directly. The bootargs should be the same for USB or SATA rootfs.

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

I used these ENVs that were developed for someone else's IX2 problem and got it working:

setenv bootcmd_ide 'ide reset; ext2load ide 0:1 0x800000 /boot/uImage; ext2load ide 0:1 0x2100000 /boot/uInitrd'
setenv bootcmd_stock 'nand read 0x800000 uImage; nand read 0x2100000 uInitrd; bootm 0x00800000 0x2100000'
setenv bootcmd 'setenv bootargs $(bootargs_console) root=LABEL=rootfs rootfdelay=10 earlyprintk=serial; run bootcmd_ide; run bootcmd_stock'

...with only a little bit of weirdness where the serial console stops after several statements (although the Debian login appears later):

Marvell>> boot

Reset IDE: 
Marvell Serial ATA Adapter
Integrated Sata device found
[0 0 0]: Enable DMA mode
  Device 0 @ 0 0:
Model: ST910021AS                               Firm: 8.04     Ser#:             3MH1405C
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 95396.2 MB = 93.1 GB (195371568 x 512)


4975416 bytes read

9713936 bytes read

NAND read: mtdids not defined, no default present
'uImage' is not a number

NAND read: mtdids not defined, no default present
'uInitrd' is not a number
## Booting image at 00800000 ...
   Image Name:   Linux-5.2.9-kirkwood-tld-1
   Created:      2022-02-26  22:27:27 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4975352 Bytes =  4.7 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK
## Loading Ramdisk Image at 02100000 ...
   Image Name:   initramfs-5.2.9-kirkwood-tld-1
   Created:      2019-08-25   2:22:50 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    9713872 Bytes =  9.3 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000][    T0] Booting Linux on physical CPU 0x0
[    0.000000][    T0] Linux version 5.2.9-kirkwood-tld-1 (root@tldDebian) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 PREEM9
[    0.000000][    T0] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f
[    0.000000][    T0] CPU: VIVT data cache, VIVT instruction cache
[    0.000000][    T0] OF: fdt: Machine model: Iomega StorCenter ix2-200
[    0.000000][    T0] printk: bootconsole [earlycon0] enabled
[    0.000000][    T0] Memory policy: Data cache writeback
[    0.000000][    T0] Built 1 zonelists, mobility grouping on.  Total pages: 65024
[    0.000000][    T0] Kernel command line: root=LABEL=rootfs rootfdelay=10 earlyprintk=serial
[    0.000000][    T0] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000][    T0] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000][    T0] Memory: 234780K/262144K available (9216K kernel code, 868K rwdata, 3400K rodata, 1024K init, 301K bss, 27364K rese)
[    0.000000][    T0] random: get_random_u32 called from cache_alloc_refill+0x38c/0x928 with crng_init=0
[    0.000000][    T0] rcu: Preemptible hierarchical RCU implementation.
[    0.000000][    T0]  Tasks RCU enabled.
[    0.000000][    T0] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[    0.000000][    T0] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000][    T0] clocksource: orion_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302233 ns
[    0.000011][    T0] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 10737418237ns
[    0.008526][    T0] Switching to timer-based delay loop, resolution 5ns
[    0.015985][    T0] Console: colour dummy device 80x30
[    0.021170][    T0] printk: console [tty0] enabled
[    0.025968][    T0] printk: bootconsole [earlycon0] disabled

Debian GNU/Linux 10 debian ttyS0

debian login: root
Password: 
Last login: Sat Feb 26 13:07:50 HST 2022 on ttyS0
Linux debian 5.2.9-kirkwood-tld-1 #1 PREEMPT Sat Aug 17 15:00:56 PDT 2019 armv5tel

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@debian:~#

Not sure what I turned off to stop the serial printout - DMESG keeps on going after that last "bootconsle disable" statement and my serial/USB connector keeps on blinking its TX/RX leds. Maybe the comm speed suddenly changed (using MINICOM).

The main thing is Debian is running from the SATA drive and the network interface is operational. Once Debian is up, I found that only the front USB connector acknowledges anything being plugged in. Even so, it complains about every stick I try to insert so I'm just going to consider USB inoperative on this device.

Thank you for your direction on getting this working.