Hello.

Does your kernel support it?
http://shop.lenovo.com/pl/pl/servers/network-storage/lenovoemc/ezmedia/
Console boot output:
https://pastebin.com/ncL7ZZca
dmsg
https://pastebin.com/kTEcgxc7

Please let me know if I can provide any more info.

root@iomega:~# cat /proc/cpuinfo 
Processor       : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1192.75
Features        : swp half thumb fastmult edsp 
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Hardware        : Feroceon-KW
Revision        : 0000
Serial          : 0000000000000000

root@iomega:~# uname -a
Linux iomega 2.6.31.8 Mon Nov 23 04:30:20 CET 2015 v0.0.9 Mon Nov 23 04:30:20 CET 2015 armv5tel GNU/Linux
root@iomega:~# cat /etc/de
debconf.conf    debian_version  default/        deluser.conf    
root@iomega:~# cat /etc/debian_version 
7.9
root@iomega:~# ls -l /usr/src/linux
lrwxrwxrwx 1 root root 24 Nov 23  2014 /usr/src/linux -> linux-feroceon_5_1_3_KW/

eine,

Please see here:

http://forum.doozan.com/read.php?2,15887

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

yes, it does but you need to modify uboot.

iomega ez

I updated kernel with 4.9.

Thank you guys, I didn't noticed that there are 3 pages of the thread, I've seen only one page. ;)
May I ask why the neediness for uboot upgrade? My plan is to remove all lenovo crap and install debian directly on hdd, then put initrd and kernel in the beginning of the disk and load proper sectors to RAM and boot it.

eine,

> May I ask why the neediness for uboot upgrade?

New u-boot is nice to have. But not necessary. You can change some u-boot envs in stock u-boot and boot with new rootfs.

> My
> plan is to remove all lenovo crap and install debi
> an directly on hdd, then put initrd and kernel in
> the beginning of the disk and load proper sectors
> to RAM and boot it.

There is no need to do that. You can create a new Debian rootfs: http://forum.doozan.com/read.php?2,12096 (use Debian-4.4.0-kirkwood-tld-1-rootfs-bodhi.tar.bz2).

And set it up like what iomega_ez did in the working thread.

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

bodhi,

Thank you again for the answer. Well, I do not see any other way while prevailing old u-boot, simply because I have quite big HDD there, hence neediness for using GPT partition table layout. Old one, won't see partitions and it's limited only to ext2load. Do you see any way/disadvantage of doing this?

Why I wanna keep old u-boot? I've never upgraded any before. Your upgrade notes, I've read it only briefly, looks kinda scary.

eine,

> because I have quite big HDD there, hence needines
> s for using GPT partition table layout.

Now, you do need new u-boot for this.

> Why I wanna keep old u-boot? I've never upgraded a
> ny before. Your upgrade notes, I've read it only b
> riefly, looks kinda scary.

At the moment, there is no new u-boot for the Iomega EZ anyway. So to use your large HDD, you do need to resort to a hybrid partition table.

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

bodhi,

I already know that I don't need new u-boot. Please look at this:

HDD layout:

[[GPT header][free space~100MiB][1st partition - swap][2nd - rootfs][3rd - storage]]

Free space - 100MiB:

[[1MiB free space][kernel][free space][initrd][rest of the free space]]

We can put kernel and initrd by simply dd'ing it to the place we want using its skip= option - to point the offset.


Kernel doesn't care if u-boot sees all data (paritions/disk space) or not. All I want from u-boot is to load and run kernel like:

ide read 0x40000 0x800 0x1800; ide read 0x900000 0x2000 0x1800; setenv bootargs $(console) $(bootargs_root) $(bootargs_mtd) $(bootargs_end); bootm 0x40000 0x900000;

So for me u-boot needs to see only few first MiBs of the HDD.

Then, if kernel has GPT support, it'll detect partitions and mount root FS. I did it already @ NSA-310 with stock u-boot, your 4.4.0 kernel, 3TB drive with GPT and your systemd based debian 8th.



Edited 6 time(s). Last edit at 07/08/2017 12:42AM by eine.

eine,

> So for me u-boot needs to see only few first MiBs
> of the HDD.
>
> Then, if kernel has GPT support, it'll detect part
> itions and mount root FS. I did it already @ NSA-3
> 10 with stock u-boot, your 4.4.0 kernel, 3TB drive
> with GPT and your systemd based debian 8th.

I see. It is a clever way to solve this problem :) no hybrid MBR.

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

bodhi,

Reporting success.

I was able to boot the newest kernel (4.11.3-kirkwood-tld-2) at Lenovo Iomega EZ Media & Backup Center with GPT partition scheme.

One thing I'm trying to understand. Can somebody please explain why this:

ide reset; ide read 0x800000 0x5000 0x2000; ide read 0xd00000 0xA000 0x4000; bootm 0x800000 0xd00000

Fails to load initrd with message:

[    0.000000] INITRD: 0x00d00000+0x0066b000 overlaps in-use memory region - disabling initrd

this hangs @ starting kernel

ide read 0x40000 0x5000 0x2000; ide read 0x1100000 0xA000 0x4000; bootm 0x40000 0x1100000

but this works:

ide read 0x40000 0x5000 0x2000; ide read 0x6400000 0xA000 0x4000; bootm 0x40000 0x6400000 
ide read 0x40000 0x5000 0x2000; ide read 0x2100000 0xA000 0x4000; bootm 0x40000 0x2100000

Sizes:

IDE read: device 0 block # 20480, count 8192 ... 8192 blocks read: OK

IDE read: device 0 block # 40960, count 16384 ... 16384 blocks read: OK
## Booting image at 00040000 ...
   Image Name:   Linux-4.11.3-kirkwood-tld-2
   Created:      2017-07-10  12:52:04 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3914659 Bytes =  3.7 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK
## Loading Ramdisk Image at 02100000 ...
   Image Name:   initrd.img-4.11.3-kirkwood-tld-2
   Created:      2017-07-10  12:52:02 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    6727690 Bytes =  6.4 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0

I don't understand where shall I load the kernel and initrd to not screw something up.



Edited 2 time(s). Last edit at 07/10/2017 10:19AM by eine.

eine,

ide reset; ide read 0x800000 0x5000 0x2000; ide read 0xd00000 0xA000 0x4000; bootm 0x800000 0xd00000
ide read 0x40000 0x5000 0x2000; ide read 0x1100000 0xA000 0x4000; bootm 0x40000 0x1100000

The above might be too close to each other for stock u-boot.

ide read 0x40000 0x5000 0x2000; ide read 0x6400000 0xA000 0x4000; bootm 0x40000 0x6400000 
ide read 0x40000 0x5000 0x2000; ide read 0x2100000 0xA000 0x4000; bootm 0x40000 0x2100000

The above are far enought.

You are running with stock u-boot. Unlike modern u-boot, which reallocates the images to regions where they are lined up nicely, old u-boot does not do this well (if at all). So the addresses must be in source code or stock u-boot envs. Usually we need to play around with the locations until it works (starting point is the stock envs).

To ensure that it loads OK. Look in dmesg for messages like this:

[    0.197479] Unpacking initramfs...
[    0.670819] Freeing initrd memory: 6812K

If the kernel continues booting past these messages then it was OK. Otherwise, you will see messages about a corrupted initramfs.

And thanks for reporting success! Please post which DTS/DTB you are using.

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



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

bondi,

You're right. I have those lines in my dmsg:

79:[    0.226469] Unpacking initramfs...
80:[    0.887839] Freeing initrd memory: 7472K

Is it safe to assume, that this is correct ?

ide read 0x40000 0x5000 0x2000; ide read 0x2100000 0xA000 0x4000; bootm 0x40000 0x2100000

My notes:
Well, everything looks outstanding. Nice freakin' work mate!

I used: Debian-4.4.0-kirkwood-tld-1-rootfs-bodhi.tar.bz2 and linux-4.11.3-kirkwood-tld-2-bodhi.tar.bz2 downloaded from this page.

Disk layout:

root@iomega:/# parted 
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit MiB                                                         
(parted) print                                                            
Model: ATA WDC WD20EFRX-68A (scsi)
Disk /dev/sda: 1907729MiB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start     End         Size        File system     Name    Flags
 1      128MiB    4224MiB     4096MiB     linux-swap(v1)  swap
 2      4224MiB   45184MiB    40960MiB    ext4            rootfs  boot, esp
 3      45184MiB  1907729MiB  1862545MiB  btrfs

u-boot reconfiguration, everything else is stock besides:

setenv bootargs 'root=/dev/sda2 init=/bin/systemd fsck.mode=force fsck.repair=yes console=ttyS0,115200 mtdparts=spi_flash:0x7e000@0(u-boot),0x1000@0x7f000(env),0x1000@0x7e000(env2)'
setenv bootcmd 'ide read 0x40000 0x5000 0x2000; ide read 0x2100000 0xA000 0x4000; bootm 0x40000 0x2100000'

Creating uImage & uInitrd and putting it to the disk

root@iomega:/boot# ls -l
total 60120
drwxr-xr-x 3 root root     4096 Jul 10 14:13 4.4.0
-rw-r--r-- 1 root root   151392 Jun  7 00:49 config-4.11.3-kirkwood-tld-2
drwxr-xr-x 2 root root     4096 May 29 18:12 dts
-rw-r--r-- 1 root root  7647474 Jul 11 09:29 initrd.img-4.11.3-kirkwood-tld-2
-rw-r--r-- 1 root root   147478 Jun  6 23:06 linux-4.11.3-kirkwood-tld-2.patch
-rw-r--r-- 1 root root  1269760 Jun  7 00:26 linux-dtb-4.11.3-kirkwood-tld-2.tar
-rw-r--r-- 1 root root  8372354 Jun  7 05:17 linux-headers-4.11.3-kirkwood-tld-2_2.0_armel.deb
-rw-r--r-- 1 root root 18124538 Jun  7 05:00 linux-image-4.11.3-kirkwood-tld-2_2.0_armel.deb
-rw------- 1 root root  2537435 Jun  7 04:54 System.map-4.11.3-kirkwood-tld-2
-rw-r--r-- 1 root root  3914723 Jul 11 09:29 uImage
-rw-r--r-- 1 root root  7647538 Jul 11 09:29 uInitrd
-rw------- 1 root root  3901568 Jun  7 04:54 vmlinuz-4.11.3-kirkwood-tld-2
-rwxr-xr-x 1 root root  3901568 Jun  7 02:02 zImage-4.11.3-kirkwood-tld-2
-rwxr-xr-x 1 root root  3914659 Jul 11 09:29 zImage.fdt


cd /boot
update-initramfs -uv
cp -a zImage-4.11.3-kirkwood-tld-2 zImage.fdt
cat dts/kirkwood-lenovo-ix2-ng.dtb >> zImage.fdt
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initrd.img-4.11.3-kirkwood-tld-2 -d initrd.img-4.11.3-kirkwood-tld-2 uInitrd
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-4.11.3-kirkwood-tld-2 -d zImage.fdt uImage
dd if=uImage of=/dev/sda bs=1MiB seek=10
dd if=uInitrd of=/dev/sda bs=1MiB seek=20

I've upgraded it to Debian 9 Strech without a glitch!
Console output after update: https://pastebin.com/2gDzk5Ea

Power button fix:

root@nsa310:~# apt-get install esekeyd

root@nsa310:~# cat /etc/default/esekeyd 
# Defaults for esekeyd initscript

# Start esekeyd on boot (set it to "true" to enable)
START_ESEKEYD=true

# Daemon options, at last config location must be present
DAEMON_OPTS=/etc/esekeyd.conf

root@nsa310:~# cat /etc/esekeyd.conf 
#
# ESE Key Deamon 1.2.7 config file
#

#
# example 1: to run mutt in xterm we must set DISPLAY
#            so the command line will be as follows:
#MAIL:/bin/sh -c "DISPLAY=:0 xterm -e mutt"
#
# example 2: turn on/off GPS reciever when lid is open/closed
#RADIO(press):echo 1 >/sys/device/platform/gps/gps_power
#RADIO(release):echo 0 >/sys/device/platform/gps/gps_power
#
# example 3: run nautilus when both left meta and e keys are press
#LEFTMETA+E:nautilus
#

#POWER(press): /usr/bin/logger -s -i "POWER button pushed"
POWER:/sbin/shutdown -h now

Leds:

root@iomega:/# cat /etc/rc.local 
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# turn on LED

echo 1 > /sys/devices/platform/gpio-leds/leds/ix2:blue:hdd/brightness
echo 0 > /sys/devices/platform/gpio-leds/leds/ix2\:red\:hdd1/brightness 
echo 0 > /sys/devices/platform/gpio-leds/leds/ix2:red:hdd2/brightness
echo 1 > /sys/devices/platform/gpio-leds/leds/ix2:red:sys/brightness
echo 0 > /sys/devices/platform/gpio-leds/leds/ix2:white:sys/brightness

echo "disk-activity" > /sys/devices/platform/gpio-leds/leds/ix2:blue:hdd/trigger

There's small problem with /run filesystem (it's size - it's too small - during systemd service reloading). It's recommended to:

mount -t tmpfs tmpfs /run -o remount,size=32M,nosuid,noexec,relatime,mode=755

Before doing any apt-get upgrade. (it concerns Debian 9 Stretch only)

fstab & mem usage

root@iomega:/# cat /etc/fstab 
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/sda2      /               ext4    noatime,errors=remount-ro 0 1
tmpfs          /tmp            tmpfs   defaults          0       0
UUID=776a2dc8-2749-4f98-91bf-785682dcf506       /storage/       btrfs   noatime,nodiratime      0       2

root@iomega:/# free -h
              total        used        free      shared  buff/cache   available
Mem:           114M         19M        2.8M        332K         92M         89M
Swap:          4.0G        5.5M        4.0G

Performance:
I did fast iscsi benchmark, by:

root@iomega:/# apt -y install tgt dkms 

root@iomega:/# cat /etc/tgt/conf.d/target01.conf
<target iomega:storage>
    # provided devicce as a iSCSI target
    backing-store /dev/sda3
    MaxRecvDataSegmentLength 131072
    MaxXmitDataSegmentLength 131072
    MaxBurstLength 262144
    FirstBurstLength 262144
    TargetRecvDataSegmentLength=262144
    InitiatorRecvDataSegmentLength=262144
    MaxOutstandingUnexpectedPDUs=0
    MaxOutstandingR2T=1
    MaxCommands=128
</target>

# on the initiator
iscsiadm -m discovery -p iomega -t st -D
iscsiadm -m node --targetname iomega:storage --portal "iomega:3260" --login

Resulting in ~35-40 MiB/s read/write throughput (when dding from/to the device from initiator site like dd if=... of=... bs=1MiB). CPU seems to be the bottleneck. IMHO performance difference is hardly noticeable between Debian 7 with 2.6.31.8 kernel and Debian 9 with 4.11.3. But feature matrix and stability are insane for 50$ box...

Sensors:

root@iomega:/boot# sensors
kirkwood_thermal-virtual-0
Adapter: Virtual device
temp1:        +74.1°C

S.M.A.R.T.

root@iomega:/boot# smartctl -d sat -a /dev/sda       
smartctl 6.6 2016-05-31 r4324 [armv5tel-linux-4.11.3-kirkwood-tld-2] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Red
Device Model:     WDC WD20EFRX-68AX9N0
Serial Number:    WD-WCC300508923
LU WWN Device Id: 5 0014ee 003990a15
Firmware Version: 80.00A80
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is:    Tue Jul 11 14:11:09 2017 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever 
                                        been run.
Total time to complete Offline 
data collection:                (25320) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 256) minutes.
Conveyance self-test routine
recommended polling time:        (   5) minutes.
SCT capabilities:              (0x70bd) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   190   172   021    Pre-fail  Always       -       3475
  4 Start_Stop_Count        0x0032   092   092   000    Old_age   Always       -       8287
  5 Reallocated_Sector_Ct   0x0033   188   188   140    Pre-fail  Always       -       368
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   056   056   000    Old_age   Always       -       32547
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       147
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       59
193 Load_Cycle_Count        0x0032   198   198   000    Old_age   Always       -       8227
194 Temperature_Celsius     0x0022   101   099   000    Old_age   Always       -       46
196 Reallocated_Event_Count 0x0032   027   027   000    Old_age   Always       -       173
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%     32273         -
# 2  Short offline       Completed without error       00%     32249         -
# 3  Short offline       Completed without error       00%     32225         -
# 4  Short offline       Completed without error       00%     32201         -
# 5  Short offline       Completed without error       00%     32177         -
# 6  Short offline       Completed without error       00%     32153         -
# 7  Short offline       Completed without error       00%     32129         -
# 8  Extended offline    Completed without error       00%     32112         -
# 9  Short offline       Completed without error       00%     32105         -
#10  Short offline       Completed without error       00%     32081         -
#11  Short offline       Completed without error       00%     32059         -
#12  Short offline       Completed without error       00%     32033         -
#13  Short offline       Completed without error       00%     32009         -
#14  Short offline       Completed without error       00%     31986         -
#15  Short offline       Completed without error       00%     31962         -
#16  Extended offline    Completed without error       00%     31945         -
#17  Short offline       Completed without error       00%     31939         -
#18  Short offline       Completed without error       00%     31915         -
#19  Short offline       Completed without error       00%     31891         -
#20  Short offline       Completed without error       00%     31867         -
#21  Short offline       Completed without error       00%     31843         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

What doesn't work?

root@iomega:/# dmesg | grep mtd
15:[    0.000000] Kernel command line: root=/dev/sda2 init=/bin/systemd fsck.mode=force fsck.repair=yes console=ttyS0,115200 mtdparts=spi_flash:0x7e000@0(u-boot),0x1000@0x7f000(env),0x1000@0x7e000(env2)
126:[    5.771446] mtd: partition "u-boot" doesn't end on an erase block -- force read-only
128:[    5.785973] mtd: partition "u-boot env2" doesn't start on an erase block boundary -- force read-only
130:[    5.801826] mtd: partition "u-boot env" doesn't start on an erase block boundary -- force read-only
root@iomega:/# fw_printenv 
Warning: Bad CRC, using default environment
bootargs=
bootcmd=
bootdelay=2
baudrate=115200
arch=sandbox
cpu=sandbox
board=sandbox
board_name=sandbox
stdin=serial,cros-ec-keyb,usbkbd
stdout=serial,vidconsole
stderr=serial,vidconsole
ethaddr=00:00:11:22:33:44
eth1addr=00:00:11:22:33:45
eth3addr=00:00:11:22:33:46
eth5addr=00:00:11:22:33:47
ipaddr=1.2.3.4
host_boot=if host dev ${devnum}; then setenv devtype host; run scan_dev_for_boot_part; fi
boot_net_pci_enum=pci enum
boot_net_usb_start=usb start
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
boot_prefixes=/ /boot/
boot_scripts=boot.scr.uimg boot.scr
boot_script_dhcp=boot.scr.uimg
boot_targets=host1 host0 
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
bootcmd_host1=setenv devnum 1; run host_boot
bootcmd_host0=setenv devnum 0; run host_boot
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
bootm_size=0x10000000
kernel_addr_r=0x1000000
fdt_addr_r=0xc00000
ramdisk_addr_r=0x2000000
scriptaddr=0x1000
pxefile_addr_r=0x2000
root@iomega:/#

I've read in the other thread that dts is bad, unfortunately I don't have the necessary knowledge to fix it. Please let me know if someone is willing to fix it and needs testing environment. I still have somewhere patched sources for 2.6.31.8 if it helps somehow.



Edited 12 time(s). Last edit at 07/11/2017 07:37AM by eine.

eine,

> You're right. I have those lines in my dmsg:
>

> 79:[    0.226469] Unpacking initramfs...
> 80:[    0.887839] Freeing initrd memory: 7472K
>

>
> Is it safe to assume, that this is correct ?
>

> ide read 0x40000 0x5000 0x2000; ide read 0x2100000
> 0xA000 0x4000; bootm 0x40000 0x2100000
>

Yes. It is correct.

And everything looks great! thanks for posting all these info.

> What doesn't work?

1. LEDs: working, but you can use better trigger with these format

echo default-on > /sys/class/leds/ix2:white:sys/trigger
echo ide-disk1 >  > /sys/class/leds/ix2:blue:hdd/trigger

2. mtd partition

Please find out what type of SPI flash,... any info you can.

I'll be back.

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

bodhi Wrote:
> 2. mtd partition
>
> Please find out what type of SPI flash,... any inf
> o you can.
>
> I'll be back.

I've viewed ton of web pages to find its name only. And I think I won't find it in that way. I'll try to start to analyze the mainboard and chips on it. What do you think? Is there better place to start?



Edited 2 time(s). Last edit at 07/12/2017 10:43AM by eine.

> . And I think I won't find it in that way. I'll tr
> y to start to analyze the mainboard and chips on i
> t. What do you think? Is there better place to sta
> rt?

I think the serial bootlog and then the GPL source. Usually the name will show when u-boot starts if it initializes the chip. And if not there, the GPL source for u-boot and kernel. The kernel GPL source should have this info if SPI is working in stock OS.

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

Marvell>> reset

         __  __                      _ _
        |  \/  | __ _ _ ____   _____| | |
        | |\/| |/ _` | '__\ \ / / _ \ | |
        | |  | | (_| | |   \ V /  __/ | |
        |_|  |_|\__,_|_|    \_/ \___|_|_|
 _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/    |____/ \___/ \___/ \__|  ** ix1-spi ** ** uboot_ver:0.0.8 **

 ** MARVELL BOARD: DB-88F6282A-BP LE

U-Boot 1.1.4 (Oct 28 2011 - 15:17:21) Marvell version: 3.6.1 - EMC

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CD5A0

Soc: 88F6282 A1 CPU running @ 1200Mhz L2 running @ 600Mhz
SysClock = 400Mhz , TClock = 200Mhz

DRAM (DDR3) CAS Latency = 6 tRP = 6 tRAS = 15 tRCD=6
DRAM CS[0] base 0x00000000   size 128MB
DRAM Total size 128MB  16bit width
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
[1024kB@f8000000] Flash:  1 MB

Marvell Serial ATA Adapter
Integrated Sata device found
[0 0 0]: Enable DMA mode (6)
  Device 0 @ 0 0:
Model: WDC WD20EFRX-68EUZN0                     Firm: 82.00A82 Ser#:      WD-WCC4M6UXV7U1
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 1907729.0 MB = 1863.0 GB (-387938128 x 512)


CPU : Marvell Feroceon (Rev 1)

Streaming disabled
Write allocate disabled


USB 0: host mode
PEX 0: interface detected no Link.
PEX 1: interface detected no Link.
Net:   egiga0 [PRIME]
Hit any key to stop autoboot:  0
Marvell>> flinfo

Bank # 1:
Flash Base Address  : 0xf8000000
Flash Model         : MXIC MX25L8006E
Manufacturer ID     : 0xc2
Device Id           : 0x2014
Sector Size         : 4K
Number of sectors   : 256
Page Size           : 256
Write Protection    : Upper 1 of 2

Datasheet: http://www.zlgmcu.com/mxic/pdf/NOR_Flash_c/MX25L1606-8006E_DS_EN.pdf



Edited 1 time(s). Last edit at 07/13/2017 08:06AM by eine.

eine,

Good stuff :)

> Marvell>> flinfo
>
> Bank # 1:
> Flash Base Address : 0xf8000000
> Flash Model : MXIC MX25L8006E
> Manufacturer ID : 0xc2
> Device Id : 0x2014
> Sector Size : 4K
> Number of sectors : 256
> Page Size : 256
> Write Protection : Upper 1 of 2
> [/code]
>
> Datasheet: http://www.zlgmcu.com/mxic/pdf/NOR_Flas
> h_c/MX25L1606-8006E_DS_EN.pdf

Let's see if I can find this somewhere in the kernel.

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

OK, so looks like I need to add an entry for this specific chip in the spi-nor driver. The chip is supported as compatible with mx25l8005, but without 4K sector option.

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

bondi,

please suspend researching this topic. I think I've found some major issue with your kernel and this box and I think that wrong dts/dtb are somehow connected. During heavy io and cpu stress test I discovered that the box shuts itself down without any clear reasons and output in logs/serial console. I know, it smells like hardware issue or some thermal watchdog? I can reproduce it by leaving those two commands:

dd if=/dev/sda of=/dev/null bs=1MiB &
dd if=/dev/urandom of=/dev/null bs=1MiB &

and leaving it for 15-20 minutes. It "works" every time. :)
I am going to rule out hardware issues by doing this on the stock kernel. If it will not shut down itself down then I am right.
I've tired 4.11.3 with its 4.11.3 dts' and 4.4.0 with 4.11.3 dts' - same thing. I think we use some memory areas we shouldn't touch and shutting down is some sort of u-boot defensive behavior. Even with stock kernel 2.6.31.8 oom, memory management and ethernet driver buffers was a mess. Have you heard similar reports? Does my thinking have any sense? What do you think?

Yesterday's crashes during heavy IO and dd tests:

Jul 13 11:36:45 linux iscsid: connection5:0 is operational after recovery (48 attempts)
Jul 13 11:56:10 linux iscsid: connection5:0 is operational after recovery (28 attempts)
Jul 13 12:19:34 linux iscsid: connection5:0 is operational after recovery (135 attempts)
Jul 13 13:15:03 linux iscsid: connection5:0 is operational after recovery (61 attempts)
Jul 13 13:49:01 linux iscsid: connection5:0 is operational after recovery (34 attempts)

Time between random shutdowns and me noticing it.

Let's rock:

root@iomega:~# uname -a
Linux iomega 2.6.31.8 Mon Nov 23 04:30:20 CET 2015 v0.0.9 Mon Nov 23 04:30:20 CET 2015 armv5tel GNU/Linux
root@iomega:~# date
Fri Jul 14 17:36:01 CEST 2017
root@iomega:~# dd if=/dev/sda of=/dev/null bs=1MiB &
[1] 2361
root@iomega:~# dd if=/dev/urandom of=/dev/null bs=1MiB &
[2] 2362

In meantime - one hour later, it's still allive:
Temperature gauges: https://pasteboard.co/GAVgn3W.png

root@iomega:~# date; kill -USR1 2361; kill -USR1 2362
Fri Jul 14 18:48:26 CEST 2017
2870+4 records in
2870+3 records out
3010744520 bytes (3.0 GB) copied, 4344.48 s, 693 kB/s
263044+0 records in
263043+0 records out
275820576768 bytes (276 GB) copied, 4344.49 s, 63.5 MB/s

In the meantime, I covered it with clothes to increase temperature. Yesterday was a little bit warmer.

At this point I am pretty convinced about the issue (not the cause). I'll leave it for few hours longer just to be sure.

root@iomega:~# date; killall dd
Fri Jul 14 20:14:52 CEST 2017
[1]-  Terminated              dd if=/dev/sda of=/dev/null bs=1MiB
[2]+  Terminated              dd if=/dev/urandom of=/dev/null bs=1MiB

I've killed it, disk is so hot I cannot touch it.

194 Temperature_Celsius     0x0022   084   083   000    Old_age   Always       -       66

https://pasteboard.co/GAVW9Uq.png

I think it's undebugable.



Edited 19 time(s). Last edit at 07/14/2017 01:37PM by eine.

eine,

Quote

I think that wrong dts/dtb are somehow connected.

Perhaps the kirkwood-lenovo-ix2-ng.dts is not yet usable for this box. You and iomega_ez will be the ones who determine what need to be changed (if any) to make it appropriate for the Iomega EZ.

Quote

shutting down is some sort of u-boot defensive behavior. Even with stock kernel 2.6.31.8 oom, memory management and ethernet driver buffers was a mess. Have you heard similar reports? Does my thinking have any sense? What do you think?

I have not heard any report like this. Nobody has reported trying this kernel with the kirkwood-lenovo-ix2-ng.dts, except you and iomega_ez.

Not u-boot. u-boot is gone completely when you are running Debian. This behavior indicated that some hardware watchdog has shutdown the box. Try googling the subject to see if anybody has experienced a shutdown like this running either stock or custom build.

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

eine said:

> root@iomega:/boot# sensors
> kirkwood_thermal-virtual-0
> Adapter: Virtual device
> temp1: +74.1°C

That's very hot. Does the your device have a fan? My IX2-ng CPU will hit about 58°C when it is working hard and the fan will spin faster. This is what a real IX2-ng has for sensors.

player1@mnemotest:~$ sensors
kirkwood_thermal-virtual-0
Adapter: Virtual device
temp1: +47.0°C

adt7473-i2c-0-2e
Adapter: mv64xxx_i2c adapter
in1: +1.11 V (min = +0.00 V, max = +2.99 V)
+3.3V: +3.36 V (min = +2.96 V, max = +3.61 V)
fan1: 786 RPM (min = 0 RPM)
fan2: 0 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
fan4: 0 RPM (min = 0 RPM)
temp1: +37.2°C (low = -63.0°C, high = +191.0°C)
(crit = +100.0°C, hyst = +96.0°C)
Board Temp: +36.0°C (low = -63.0°C, high = +191.0°C)
(crit = +100.0°C, hyst = +96.0°C)
temp3: +33.0°C (low = -63.0°C, high = +191.0°C)
(crit = +100.0°C, hyst = +96.0°C)


Regarding the SPI flash chip. You can edit the spi-nor.c file and add the chip and it will work. But... that chip has an ID that duplicates/conflicts with an existing entry for mx25l8005 chip. I think that's going to cause problems for any device that uses a mx25l8005 chip.

sarcastic.mannequin,

>
> Regarding the SPI flash chip. You can edit the spi
> -nor.c file and add the chip and it will work. But
> ... that chip has an ID that duplicates/conflicts
> with an existing entry for mx25l8005 chip. I think
> that's going to cause problems for any device that
> uses a mx25l8005 chip.

I'll take a look to see if we can do this without conflict.

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

sarcastic.mannequin,
,
It does seem like it is going to work. The id match is actually by name, not by jdec.

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

Hey guys,

I need someone to test the change in this SPI flash driver for MX25L8006E. I have kernel 4.12.1 on my other Kirkwood boxes. But I don't have Iomega EZ, or any box that use MX25L8006E or MX25L8005.

Any volunteer, please post.

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



Edited 1 time(s). Last edit at 07/16/2017 07:46PM by bodhi.

sarcastic.mannequin,

I must point that, the device was in full IO activity and CPU usage for about 20-30 minutes. I guessing that your measurement was in almost idle state.

Currently the box is without cover, so it works in better outside temperature conditions. I agree 74C is quite hot. The box doesn't have the fan at all. Even in stock shape (cover, software), those getting hot quite fast - when CPU is idle and when no disk IO activity, but the disk is spinning constantly. I am not sure if sensors in 4.11 works as supposed to - I didn't test it and I think that temperature should be at least 10-15C lower, I recreated the event on stock event in much worse conditions though. The temperature of the hard drive was at least 10-15C higher. In the temperature gauges you can see that CPU temperature reached quoted temperature. As for editing the kernel, then I am unfortunately a modest sysadmin and editing kernel source in C is an overkill for my field of expertise.

bodhi,
please send me what you got, I'll test it with pleasure as a contribution for your very appreciated work.
I've searched google for similar reports regardless unexpected shutdowns for terms: iomega, lenovo, arm, linux.
Only last one give some relatively good results. People most commonly point BIOS' watchdog, which I think is not relevant in this case.

Gentlemens,
if you have any propositions how we can debug it, then I am really glad to take the shot. I am pretty convinced, that I can leave this box to 24h stress test on stock kernel and it'll work. If you're not convinced then please let me know.



Edited 7 time(s). Last edit at 07/17/2017 07:57AM by eine.

Eine,

Boot with USB rootfs, and put the HDD in sleep. Then you would be able to compare the results. Your roofs is the HDD then it would bever be idle.

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

bodhi,

> Boot with USB rootfs, and put the HDD in sleep. Th
> en you would be able to compare the results. Your
> roofs is the HDD then it would bever be idle.

Just to be sure, we want:
4.4.0 rootfs with Debian 8,
4.11.3 kernel with its dts
rootfs served on usb @ ext2 filesystem,
dd urand CPU stress test only.
rule out kernel SATA storage subsystem (mv_sata)

Is that correct?

In the meantime I did longer stress test on the stock kernel (2.6.31.8):
https://pasteboard.co/GBtRj6T.png
Console output:

root@iomega:~# dd if=/dev/urandom of=/dev/null bs=1MiB &
[1] 18537
root@iomega:~# dd if=/dev/sda of=/dev/null bs=1MiB &
[2] 18548
root@iomega:~# date
Mon Jul 17 14:48:06 CEST 2017
root@iomega:~# 1907729+1 records in
1907729+1 records out
2000398934016 bytes (2.0 TB) copied, 31117.3 s, 64.3 MB/s

[2]+  Done                    dd if=/dev/sda of=/dev/null bs=1MiB
root@iomega:~# date
Tue Jul 18 10:14:58 CEST 2017
root@iomega:~# fg
^C
dd if=/dev/urandom of=/dev/null bs=1MiB
72791+1 records in
72791+0 records out
76326895616 bytes (76 GB) copied, 70025 s, 1.1 MB/s
root@iomega:~#

It means:
9h constant max HDD I/O and 19h max CPU usage. I hope that ends speculation about hardware failure.



Edited 6 time(s). Last edit at 07/18/2017 09:08AM by eine.

Eine!

Ugh. No fan. Disk gets too hot to touch? Ouch! Don't use a 7200 rpm hard drive in it, that's for sure! Why does the stock firmware survive? I wonder if the stock firmware has some sort of throttling when it gets to hot. There is a surprising amount of edits and patches in these thing's stock linux drivers.

I'll check the Marvell Kirkwood thermal driver to see if it has the ability to slowdown the CPU or do a shutdown if it gets in panic state. It might be worth having a look for any other temperature sensors on the board. Use either your eyes or use i2c-tools/lm-sensors to scan for sensors. Might have to create a script to monitor temp and do controlled shutdown or ??? instead of controlling a fan. All this assuming it is thermal related issue.