Welcome! Log In Create A New Profile

Advanced

Rescue V3.0 : A work in progress ... wanna help?

Posted by davygravy 
Re: Rescue V3.0 : A work in progress ... wanna help?
September 03, 2012 12:38PM
Re: Rescue V3.0 : A work in progress ... wanna help?
September 05, 2012 03:37AM
Yes it should work with certificates.
I copied them from a working Dockstar...

cya
major
Re: Rescue V3.0 : A work in progress ... wanna help?
September 06, 2012 07:33PM
kk, gmail from it works... which required the certs

Has openvpn worked for you?

=====================================================


Re: Rescue V3.0 : A work in progress ... wanna help?
October 01, 2012 03:05PM
I tried booting a dockstar which has been running a Doozan debian with the image in post 1. I put it in a 750M partition on a 1G flash drive with a 250M swap partition.

There was no uInitrd--is that correct?

It gets to the point of "booting the kernal", but then nothing happens. Is there something evident that I am doing wrong?
U-Boot 2010.09 (Oct 23 2010 - 11:49:22)
Marvell-Dockstar/Pogoplug by Jeff Doozan

SoC:   Kirkwood 88F6281_A0
DRAM:  128 MiB
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot:  0
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 4 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
Loading file "/rescueme" from usb device 0:1 (usbda1)
** File not found /rescueme
reading /rescueme.txt

** Unable to read "/rescueme.txt" from usb 0:1 **
Creating 1 MTD partitions on "nand0":
0x000002500000-0x000010000000 : "mtd=3"
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    129024 bytes
UBI: smallest flash I/O unit:    2048
UBI: sub-page size:              512
UBI: VID header offset:          512 (aligned 512)
UBI: data offset:                2048
UBI error: ubi_read_volume_table: the layout volume was not found
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -22
UBI init error -22
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
1 bytes read
Found bootable drive on usb 0:1
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
3627880 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
** File not found /boot/uInitrd
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-3.3.2-kirkwide
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3627816 Bytes = 3.5 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
I have no problem booting off of my normal usb. I tried it on a second dockstar, with the same results, and with a second usb drive with the same results. I'm assuming that I should get a prompt in my putty session with the serial console connection.

Any ideas?
Re: Rescue V3.0 : A work in progress ... wanna help?
October 05, 2012 04:17AM
Looks like you need a new uboot.
http://forum.doozan.com/read.php?3,6965

Quote
davygravy
Kernel 3.2.y introduced a default setting for the kernel that affects kirkwood machines in particular, because of an unintended u-boot behavior with regard to the Level2Cache and decompression of the kernel image. Call it a latent bug in u-boot, a regression in the kernel, or whatever... the defconfig kirkwood kernel build of 3.2.y (and by extension, higher versions) will fail to boot in most/many cases.
Re: Rescue V3.0 : A work in progress ... wanna help?
November 20, 2012 08:50AM
I tried flashing the rescue system, https://dl.dropbox.com/u/1015928/Kirkwood/rescue/RescueV3-for-Major_Tom.tar.gz

with the following commands from the thread:

flash_erase /dev/mtd1 0 0
nandwrite /dev/mtd1 uImage-mtd1.img
flash_erase /dev/mtd2 0 0
ubiformat /dev/mtd2 -s 512 -f rootfs-mtd2.img -y

All went as expected, but when I reboot, I get the following:
U-Boot 2011.12 (Feb 12 2012 - 21:33:07)
Seagate FreeAgent DockStar

SoC:   Kirkwood 88F6281_A0
DRAM:  128 MiB
WARNING: Caches not enabled
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot:  0
env - environment handling commands

Usage:
env default -f - reset default environment
env edit name - edit environment variable
env export [-t | -b | -c] [-s size] addr [var ...] - export environment
env import [-d] [-t | -b | -c] addr [size] - import environment
env print [name ...] - print environment
env run var [...] - run commands in an environment variable
env save - save environment
env set [-f] name [arg ...]

(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 3 USB Device(s) found
       scanning bus for storage devices... 0 Storage Device(s) found
** Block device usb 0 not supported
** Block device usb 0 not supported
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   kernel 3.2.0-4-kirkwood
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1604488 Bytes = 1.5 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
u-boot>>
What boot commands should I have? I have a "2011.12" U-Boot, which successfully boots from usb. Is there a different pair of mtd files I should flash?
Re: Rescue V3.0 : A work in progress ... wanna help?
November 20, 2012 12:00PM
Ok, my post above may just indicate a hardware problem on that particular Dockstar, as shown by the "Bad Data CRC". I just installed the "2011.12" U-Boot and V3 rescue images on a new Dockstar, and it boots perfectly well into the rescue system. Thanks for this good work.
Re: Rescue V3.0 : A work in progress ... wanna help?
November 20, 2012 06:42PM
Thank you for the feedback - much appreciated.

=====================================================


Re: Rescue V3.0 : A work in progress ... wanna help?
May 26, 2013 01:59AM
Hi,
I've got a real difficult time trying to install Debian Wheezy on my Pogo V2 (pink). On the original pogoplug partition with latest uboot the script fails with "Fatal: kernel too old"
So I followed a link to here to try and run that script from a USB rescue. I untarred the file above on my usb, and rebooted to the usb. The pogoplug boots up with an orange light on the front and the network adaptor is not up (evidenced by only a green light on the port rather than both green and orange light).
Now I'm stuck...
I am afraid to use the other versions of the rescue to replace my original pogo partitions for fear that I would have the same network interface issue of not coming up then it would be bricked...
sylvester
Re: Rescue V3.0 : A work in progress ... wanna help?
December 11, 2013 12:27AM
First try for me to get debian to a goflex home.

Update the latest uboot, no problem. When trying to install wheezy, hit with the "FATAL: kernel too old" issue.
Fine, get the USB stick rescue system (rootfs-br2012.02_06082012.tar).

However, like other goflex system, I got Too few good blocks within range. Was told to use a patched kernel ( linux-image-3.3.2-sheevaesata40msnandfixforgoflexnet.deb).

I suppose I need to patch the rescue system with this kernel. However, the procedure requires dpkg and mkimage, how am I suppose to get that? (apt-get isn't in the rescure system as well).

I am stuck now... Any idea what to do next?
Re: Rescue V3.0 : A work in progress ... wanna help?
December 11, 2013 01:37AM
Re: Rescue V3.0 : A work in progress ... wanna help?
December 11, 2013 06:57PM
Thanks for the new rootfs. It boots up no problem. However, fw_printenv still gives me the "Too few good blocks within range" error.

In addition, after using nanddump to dump the uboot, I found that the md5sum is different from the one I flashed before (goflexhome davygravy-2012-04-19-current). Why would that be? After flashing, I am sure it reports the correct md5sum the few time I ran kirkwood.debian-wheezy.sh before the first reboot to the rescue rootfs. Looking at the nanddump, they contains all FF's so I suppose the nanddump is not really dumping the content.

Do I still need to use the davygravy's patched kernel in order to get fw_printenv and nanddump to behave? I tried it anyway but it failed to boot up.

Any idea?



Edited 1 time(s). Last edit at 12/11/2013 09:35PM by sylvester.
Re: Rescue V3.0 : A work in progress ... wanna help?
December 11, 2013 11:20PM
sylvester,

My kernel build has the patch for the "too few good blocks.." already incorporated for GoFlex Home. You could post your dmesg here so we can take a look. Also post your
cat /proc/mtd
cat /proc/cpuinfo

About the md5 from nanddump, did you get mtdparts definition printed out after installation? is it different now or the same?

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner



Edited 1 time(s). Last edit at 12/11/2013 11:31PM by bodhi.
Re: Rescue V3.0 : A work in progress ... wanna help?
December 12, 2013 06:51PM
May be somehow the arcNumber not set correctly? I thought the install_uboot_mtd0.sh script would do it correctly as it detected the correct platform when it was run. I didn't print out the mtdparts before so I can't compare. Anyway,


root@debian:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 02000000 00020000 "rootfs"
mtd3: 0db00000 00020000 "data"


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

Hardware : Marvell SheevaPlug Reference Board
Revision : 0000
Serial : 0000000000000000


dmesg:
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 3.12.0-kirkwood-tld-1 (root@tldDebian) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 PREEMPT Fri Nov 8 15:57:44 PST 2013
[ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: Marvell SheevaPlug Reference Board
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] On node 0 totalpages: 32768
[ 0.000000] free_area_init_node: node 0, pgdat c062dda0, node_mem_map c069b000
[ 0.000000] Normal zone: 256 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 32768 pages, LIFO batch:7
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
[ 0.000000] Kernel command line: console=ttyS0,115200 root=/dev/sda1 rootdelay=10 rootfstype=ext2 mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Memory: 116728K/131072K available (4271K kernel code, 325K rwdata, 1508K rodata, 198K init, 420K bss, 14344K reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xc8800000 - 0xff000000 ( 872 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
[ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
[ 0.000000] .text : 0xc0008000 - 0xc05acdd8 (5780 kB)
[ 0.000000] .init : 0xc05ad000 - 0xc05deb2c ( 199 kB)
[ 0.000000] .data : 0xc05e0000 - 0xc0631474 ( 326 kB)
[ 0.000000] .bss : 0xc0631474 - 0xc069a5ec ( 421 kB)
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] NR_IRQS:114
[ 0.000000] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms
[ 0.000000] Console: colour dummy device 80x30
[ 10.972141] Calibrating delay loop... 1191.11 BogoMIPS (lpj=5955584)
[ 11.061927] pid_max: default: 32768 minimum: 301
[ 11.062026] Security Framework initialized
[ 11.062099] Mount-cache hash table entries: 512
[ 11.062735] Initializing cgroup subsys devices
[ 11.062760] Initializing cgroup subsys freezer
[ 11.062772] Initializing cgroup subsys net_cls
[ 11.062782] Initializing cgroup subsys blkio
[ 11.062854] CPU: Testing write buffer coherency: ok
[ 11.063249] Setting up static identity map for 0xc040a308 - 0xc040a344
[ 11.065119] devtmpfs: initialized
[ 11.067485] pinctrl core: initialized pinctrl subsystem
[ 11.067811] regulator-dummy: no parameters
[ 11.068129] NET: Registered protocol family 16
[ 11.068563] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 11.069188] cpuidle: using governor ladder
[ 11.069205] cpuidle: using governor menu
[ 11.069304] Kirkwood: MV88F6281-A1, TCLK=200000000.
[ 11.069324] Feroceon L2: Enabling L2
[ 11.069363] Feroceon L2: Cache support initialised.
[ 11.069705] initial MPP regs: 01111111 11113322 00001111 00100000 00000000 00000000 00000000
[ 11.069732] final MPP regs: 01111111 11113322 00001111 00000000 00000000 00000000 00000000
[ 11.073278] bio: create slab <bio-0> at 0
[ 11.073728] vgaarb: loaded
[ 11.073855] usbcore: registered new interface driver usbfs
[ 11.073909] usbcore: registered new interface driver hub
[ 11.074011] usbcore: registered new device driver usb
[ 11.074629] Switched to clocksource orion_clocksource
[ 11.092578] NET: Registered protocol family 2
[ 11.093234] TCP established hash table entries: 1024 (order: 1, 8192 bytes)
[ 11.093270] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[ 11.093291] TCP: Hash tables configured (established 1024 bind 1024)
[ 11.093358] TCP: reno registered
[ 11.093371] UDP hash table entries: 256 (order: 0, 4096 bytes)
[ 11.093393] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[ 11.093594] NET: Registered protocol family 1
[ 11.093909] RPC: Registered named UNIX socket transport module.
[ 11.093921] RPC: Registered udp transport module.
[ 11.093928] RPC: Registered tcp transport module.
[ 11.093935] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 11.093946] PCI: CLS 0 bytes, default 32
[ 11.094158] Unpacking initramfs...
[ 11.638772] Freeing initrd memory: 6404K (c1101000 - c1742000)
[ 11.638876] NetWinder Floating Point Emulator V0.97 (double precision)
[ 11.639460] audit: initializing netlink socket (disabled)
[ 11.639518] type=2000 audit(0.660:1): initialized
[ 11.640373] VFS: Disk quotas dquot_6.5.2
[ 11.640423] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 11.640775] NFS: Registering the id_resolver key type
[ 11.640848] Key type id_resolver registered
[ 11.640857] Key type id_legacy registered
[ 11.640874] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ 11.641035] jffs2: version 2.2. (NAND) (SUMMARY) \xffffffc2\xffffffa9 2001-2006 Red Hat, Inc.
[ 11.641253] msgmni has been set to 240
[ 11.643150] alg: No test for stdrng (krng)
[ 11.643243] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[ 11.643255] io scheduler noop registered
[ 11.643262] io scheduler deadline registered
[ 11.643286] io scheduler cfq registered (default)
[ 11.643482] mv_xor mv_xor.0: Marvell shared XOR driver
[ 11.674689] mv_xor mv_xor.0: Marvell XOR: ( xor cpy )
[ 11.714680] mv_xor mv_xor.0: Marvell XOR: ( xor cpy )
[ 11.714781] mv_xor mv_xor.1: Marvell shared XOR driver
[ 11.754686] mv_xor mv_xor.1: Marvell XOR: ( xor cpy )
[ 11.794686] mv_xor mv_xor.1: Marvell XOR: ( xor cpy )
[ 11.794935] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 11.815491] serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33, base_baud = 12500000) is a 16550A
[ 12.323351] console [ttyS0] enabled
[ 12.327703] NAND device: Manufacturer ID: 0x98, Chip ID: 0xda (Toshiba NAND 256MiB 3,3V 8-bit), 256MiB, page size: 2048, OOB size: 64
[ 12.339788] Scanning device for bad blocks
[ 12.343943] Bad eraseblock 0 at 0x000000000000
[ 12.348462] Bad eraseblock 1 at 0x000000020000

..... more Bad eraseblock lines...

[ 22.005947] Bad eraseblock 2046 at 0x00000ffc0000
[ 22.010711] Bad eraseblock 2047 at 0x00000ffe0000
[ 22.015467] 4 cmdlinepart partitions found on MTD device orion_nand
[ 22.021765] Creating 4 MTD partitions on "orion_nand":
[ 22.026949] 0x000000000000-0x000000100000 : "u-boot"
[ 22.032215] 0x000000100000-0x000000500000 : "uImage"
[ 22.037428] 0x000000500000-0x000002500000 : "rootfs"
[ 22.042676] 0x000002500000-0x000010000000 : "data"
[ 22.047997] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 22.054552] ehci-pci: EHCI PCI platform driver
[ 22.059084] ehci-orion: EHCI orion driver
[ 22.063181] orion-ehci orion-ehci.0: EHCI Host Controller
[ 22.068643] orion-ehci orion-ehci.0: new USB bus registered, assigned bus number 1
[ 22.076432] orion-ehci orion-ehci.0: irq 19, io mem 0xf1050000
[ 22.094667] orion-ehci orion-ehci.0: USB 2.0 started, EHCI 1.00
[ 22.100778] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 22.107621] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 22.114895] usb usb1: Product: EHCI Host Controller
[ 22.119798] usb usb1: Manufacturer: Linux 3.12.0-kirkwood-tld-1 ehci_hcd
[ 22.126543] usb usb1: SerialNumber: orion-ehci.0
[ 22.131615] hub 1-0:1.0: USB hub found
[ 22.135445] hub 1-0:1.0: 1 port detected
[ 22.139858] mousedev: PS/2 mouse device common for all mice
[ 22.145826] rtc-mv rtc-mv: rtc core: registered rtc-mv as rtc0
[ 22.151754] i2c /dev entries driver
[ 22.155832] drop_monitor: Initializing network drop monitor service
[ 22.162414] TCP: cubic registered
[ 22.165776] NET: Registered protocol family 17
[ 22.170329] Key type dns_resolver registered
[ 22.175065] registered taskstats version 1
[ 22.179984] rtc-mv rtc-mv: setting system clock to 2013-12-13 01:33:02 UTC (1386898382)
[ 22.188926] Freeing unused kernel memory: 196K (c05ad000 - c05de000)
[ 22.265356] udevd[52]: starting version 175
[ 22.333019] mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
[ 22.440967] libphy: orion_mdio_bus: probed
[ 22.454755] usb 1-1: new high-speed USB device number 2 using orion-ehci
[ 22.477036] mvsdio mvsdio: no pins associated
[ 22.514811] mvsdio mvsdio: lacking card detect (fall back to polling)
[ 22.616831] usb 1-1: New USB device found, idVendor=8564, idProduct=1000
[ 22.623589] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 22.654685] usb 1-1: Product: Mass Storage Device
[ 22.659418] usb 1-1: Manufacturer: JetFlash
[ 22.663619] usb 1-1: SerialNumber: 882G2BADS1ARDFSC
[ 22.716635] SCSI subsystem initialized
[ 22.734900] usb-storage 1-1:1.0: USB Mass Storage device detected
[ 22.754687] scsi0 : usb-storage 1-1:1.0
[ 22.765917] usbcore: registered new interface driver usb-storage
[ 23.698705] mv643xx_eth_port mv643xx_eth_port.0 eth0: port 0 with MAC address 02:50:43:dc:10:63
[ 24.099549] scsi 0:0:0:0: Direct-Access JetFlash Transcend 8GB 1100 PQ: 0 ANSI: 4
[ 24.135629] sd 0:0:0:0: [sda] 15820800 512-byte logical blocks: (8.10 GB/7.54 GiB)
[ 24.143942] sd 0:0:0:0: [sda] Write Protect is off
[ 24.148936] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
[ 24.149472] sd 0:0:0:0: [sda] No Caching mode page found
[ 24.154859] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 24.164970] sd 0:0:0:0: [sda] No Caching mode page found
[ 24.170326] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 24.178337] sda: sda1 sda2
[ 24.184342] sd 0:0:0:0: [sda] No Caching mode page found
[ 24.189741] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 24.195919] sd 0:0:0:0: [sda] Attached SCSI removable disk
[ 24.211691] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 34.803065] udevd[236]: starting version 175
[ 35.231783] alg: hash: Test 1 failed for mv-hmac-sha1
[ 35.239017] 00000000: 0c aa 9f d5 37 c3 79 3a 91 d9 21 5f 42 2b 2c 24
[ 35.253253] 00000010: b7 c3 16 0c
[ 35.279782] orion_wdt: Initial timeout 21 sec
[ 40.476455] NET: Registered protocol family 10
[ 40.603709] mv643xx_eth_port mv643xx_eth_port.0 eth0: link down
[ 40.609847] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 42.464000] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 100 Mb/s, full duplex, flow control disabled
[ 42.473833] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Re: Rescue V3.0 : A work in progress ... wanna help?
December 12, 2013 08:11PM
Yes. arcNumber needs to be set to the GoFlex Home number. The script does not set arcNumber. Because it has no way of knowing if you have a kernel that supports it. Main line kernel does not have the patch for GF Home. Hence, the purpose of my kernel and rootfs builds.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: Rescue V3.0 : A work in progress ... wanna help?
December 12, 2013 10:01PM
Oh... checking through the script again and I think I found where I went wrong. I didn't notice the last couple of output line of the uboot install script (which is part of kirkwood.debian-wheezy.sh) to do fw_setenv arcnumber and the debian installation script just started right after that.

In my situation, since your kernel and rootfs doesn't let me run fw_setenv, does it mean that I have to get access to the console port to set it before the auto-boot?

I also asked a friend who has another "untouched" GoFlex Home to run the commands. The mtdparts definition is different in his. It also different from what I read elsewhere. Did Seagate change it for different revision? His results:

-bash-3.2$ cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00600000 00020000 "uImage"
mtd2: 0f900000 00020000 "root"

-bash-3.2$ cat /proc/cpuinfo
Processor : ARM926EJ-S 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
Cache type : write-back
Cache clean : cp15 c7 ops
Cache lockdown : format C
Cache format : Harvard
I size : 16384
I assoc : 4
I line length : 32
I sets : 128
D size : 16384
D assoc : 4
D line length : 32
D sets : 128

Hardware : Feroceon-KW
Revision : 0000
Serial : 0000000000000000



Edited 2 time(s). Last edit at 12/12/2013 11:30PM by sylvester.
Re: Rescue V3.0 : A work in progress ... wanna help?
December 13, 2013 12:03AM
sylvester Wrote:
-------------------------------------------------------
> Oh... checking through the script again and I
> think I found where I went wrong. I didn't
> notice the last couple of output line of the uboot
> install script (which is part of
> kirkwood.debian-wheezy.sh) to do fw_setenv
> arcnumber and the debian installation script just
> started right after that.

No, you should not set arcNumber to the GoFlex Home without having a supported kernel. It should remain as 2097 (the Reference Board). And then change arcNumber only when you've booted up a supported kernel.


> In my situation, since your kernel and rootfs
> doesn't let me run fw_setenv, does it mean that I
> have to get access to the console port to set it
> before the auto-boot?
>

I am not sure why it did not let you use fw_setenv. How many bad blocks do you have? can you post them here or pastebin them?


> I also asked a friend who has another "untouched"
> GoFlex Home to run the commands. The mtdparts
> definition is different in his. It also different
> from what I read
> [url=http://wiki.openwrt.org/toh/seagate/goflexhom
> e#flash.layout]elsewhere[/url]. Did Seagate
> change it for different revision? His results:
>
> -bash-3.2$ cat /proc/mtd
> dev: size erasesize name
> mtd0: 00100000 00020000 "u-boot"
> mtd1: 00600000 00020000 "uImage"
> mtd2: 0f900000 00020000 "root"
>
> -bash-3.2$ cat /proc/cpuinfo
> Processor : ARM926EJ-S 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
> Cache type : write-back
> Cache clean : cp15 c7 ops
> Cache lockdown : format C
> Cache format : Harvard
> I size : 16384
> I assoc : 4
> I line length : 32
> I sets : 128
> D size : 16384
> D assoc : 4
> D line length : 32
> D sets : 128
>
> Hardware : Feroceon-KW
> Revision : 0000
> Serial : 0000000000000000

The above is normal for stock GoFlex Home.

To summarize,

You have a cach-22 here. You can't use fw_setenv to set arcNumber in Debian. So you need either netconsole or serial console to change arcNumber! and you can't setup netconsole in Debian without fw_setenv.

So your option are:

1. Connect serial console.
2. I will have to build a special version for you that works with arcNumber 2097, but also have the patch. The patch might work even for the Reference Board, i.e. I could leave the patch in.
3. You will need to find this kernel somewhere that works and replace the kernel on my rootfs. Boot up and setup netconsole.

If you can get serial console connected then it's very easy to get it working. The other 2 options will take time.

-bodhi
===========================
[b][color=#3333FF][url=http://forum.doozan.com/read.php?2,23630]Wiki[/url][/color][/b]
[url=http://forum.doozan.com/read.php?2,12096]latest Kirkwood kernel builds and rootfs[/url]
[url=http://forum.doozan.com/read.php?3,12381]latest u-boot-kirkwood builds[/url]
[url=http://forum.doozan.com/read.php?2,16044]latest Oxnas kernel builds and rootfs[/url]
[url=http://forum.doozan.com/read.php?3,16017]latest u-boot-oxnas builds[/url]
[url=http://forum.doozan.com/read.php?2,32146]latest MVEBU Armada kernel builds and rootfs[/url]
[url=http://forum.doozan.com/read.php?3,19093]U-Boot & Kernel Booting process[/url]
[url=https://github.com/mibodhi]bodhi's u-boot GitHub[/url]
[url=https://mibodhi.blogspot.com]bodhi's corner[/url]
Re: Rescue V3.0 : A work in progress ... wanna help?
December 26, 2013 08:21PM
bodhi Wrote:
-------------------------------------------------------
>
> To summarize,
>
> You have a cach-22 here. You can't use fw_setenv
> to set arcNumber in Debian. So you need either
> netconsole or serial console to change arcNumber!
> and you can't setup netconsole in Debian without
> fw_setenv.
>
> So your option are:
>
> 1. Connect serial console.
> 2. I will have to build a special version for you
> that works with arcNumber 2097, but also have the
> patch. The patch might work even for the Reference
> Board, i.e. I could leave the patch in.
> 3. You will need to find this kernel somewhere
> that works and replace the kernel on my rootfs.
> Boot up and setup netconsole.
>
> If you can get serial console connected then it's
> very easy to get it working. The other 2 options
> will take time.


Yes, that's what I thought. At the end, I opened it up and get the console port going.

I must say the procedure to get debian on GFH is very convoluted. One can easily overlooked some steps and bricked the thing. Netconsole can also be a trap if anything wrong with a new uBoot. Fortunately UART booting somehow saved the day.

All good now and I have the latest kernel and uBoot installed. Thanks.
Re: Rescue V3.0 : A work in progress ... wanna help?
February 25, 2014 06:49AM
Any chance of adding the ability to mount ext4 partitions as well as a version of wget that supports https?
Hi,
I am having prolem with wheexy instl script for dockstar(kernel too old error) hence I am trying to get rescue version.However I did steps from README, but I can't ssh to dockstar after booting. I see a green led on dockstar and also device in the router client list.
Please help.

Thanks,
Puja
Re: Rescue V3.0 : A work in progress ... wanna help?
May 17, 2014 04:28PM
The easiest thing to do is to create a rootfs on USB thumb drive, get it from here:
http://forum.doozan.com/read.php?2,12096

Boot with this, and then while in Debian you can figure out why the Rescue system did not boot. If you're trying to install a new Debian system, then you can continue using this rootfs, too, as a a starting point.

-bodhi
===========================
Wiki
latest Kirkwood kernel builds and rootfs
latest u-boot-kirkwood builds
latest Oxnas kernel builds and rootfs
latest u-boot-oxnas builds
latest MVEBU Armada kernel builds and rootfs
U-Boot & Kernel Booting process
bodhi's u-boot GitHub
bodhi's corner
Re: Rescue V3.0 : A work in progress ... wanna help?
July 20, 2014 10:34PM
Hello,

I would like to request that the full blown wget be added (versus the wget provided by busybox) for https support, now that dropbox is redirecting all http downloads to https.

Thanks

gray
Author:

Your Email:


Subject:


Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: