Newer uBoot as workaround to 3.2 kernel problem?

@telzey : please, if you happen to be in the experimenting mood, and you try one of the newer CodeSourcery chains... please let us know if use of this flag yields a normally operating u-boot binary.

;)

==================================
later that same evening...

Marvell>> tftpboot 0x800000 uboot.mtd0.kwb-stable2011.12-goflexnetv1
tftpboot 0x800000 uboot.mtd0.kwb-stable2011.12-goflexnetv1
Using egiga0 device
TFTP from server 192.168.11.149; our IP address is 192.168.11.150
Filename 'uboot.mtd0.kwb-stable2011.12-goflexnetv1'.
Load address: 0x800000
Loading: ####################################
done
Bytes transferred = 524288 (80000 hex)
Marvell>> nand erase 0x0 0x80000
nand erase 0x0 0x80000

NAND erase: device 0 offset 0x0, size 0x80000
Erasing at 0x60000 -- 100% complete.
OK
Marvell>> nand write.e 0x800000 0x0 0x80000
nand write.e 0x800000 0x0 0x80000

NAND write: device 0 offset 0x0, size 0x80000
 524288 bytes written: OK
Marvell>> reset
reset
resetting ...

U-Boot 2011.12 (Mar 19 2012 - 19:46:24)
Seagate GoFlexNet
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q3-67) 4.4.1
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709
Hit any key to stop autoboot:  4

This is pretty much a reworking of everything so far... based loosely on the openrd setup, and the dns-325, as well as looking at the LaCie devices.

I still have to work on the stuff involving IDE/SATA, and redo the LED stuff so that it is acceptable for submitting to the mainline u-boot repo.

Ahhh, and I haven't tested booting from either SATA port...

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

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 03/19/2012 08:11PM by davygravy.

I'll let you know ... when I get that far!

I've been breaking-in the box today to make sure that I don't have a lemon before opening it up and soldering in the serial cable.

u-boot seems to be building OK, and I'm researching the various configuration settings, and the additions in your earlier dockstar patch.

One thing that I did see is that the earlier patch wasn't setting CONFIG_EFI_PARTITION or CONFIG_SYS_64BIT_LBA.

That'll annoy the 3TB drive owners who have to use GPT partitions ;-)

Added -fno-zero-initialized-in-bss to u-boot-2011.12/arch/arm/cpu/arm926ejs/config.mk compiled u-boot for the Dockstar using CodeSourcery 2011.09: uboot builds but fails to load (using netconsole).

CodeSourcery 2009q3 appears to be the default choice.

Aw shucks ... I'd hoped that I'd stumbled across the magic bullet!

Thanks for testing it.

OK, it now boots from the USB, with SATA drives attached. I had to read the comments above my post in this thread: http://forum.doozan.com/read.php?2,5775,7406#msg-7406
... I had a feeling I was close to it, but as I just opened the box for my GoFlex Net 2 days ago or so, I had never read these threads...

So the uInitrd boots and then goes looking for the rootfs on (guess what! ... yup) the SATA drives.


I haven't tried booting from the SATA drive, but u-boot does recognize the SATA drive that is sitting on the left-most (from front) as well as the right hand drive port.[ NO!, correction, as with Jeff and Peaslakers/Carmichael u-boot, it only recognizes the drive on the right side, not the left side! I may look into fixing this, but it may be a peculiarity of the board. I wonder if it has something to do with the Bus0 and Bus1 being co-identified, although (IIUC) there is actually only one bus].

GoFlexNet> reset
reset
resetting ...

U-Boot 2011.12 (Mar 19 2012 - 22:10:07)
Seagate GoFlexNet
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q3-67) 4.4.1
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709
Hit any key to stop autoboot: 10 

 9 
 0 
GoFlexNet> 

GoFlexNet> 

GoFlexNet> ide reset
ide reset

Reset IDE: Bus 0: OK Bus 1: OK 
  Device 0: Model: TOSHIBA MK1655GSX  Firm: FG010D Ser#:  X9AHTNGQT
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 152627.8 MB = 149.0 GB (312581808 x 512)
  Device 1: not available
GoFlexNet>

Followup: It does boot just fine from the right SATA port.

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

• davy's Github Repo's rescue-dg

Edited 3 time(s). Last edit at 03/20/2012 10:10PM by davygravy.

OK, good enough is good enough, for now. I tried everything I could to get Device 1(left side) port to be recognized, but to no avail. So, we seem to stay with booting only from the Device 0 (right side) port. Linux does still recognize both ports, once the GoFlexNet is booted.

I've got the config minimized and cleaned up.

No LED's yet - that's next, but I'll keep that to a bare minimum for mainline. The drop-in replacement will have all the bells&whistles that Jeff's&PeterCarmichael's had.

Once pogoplug E02 is mainline, I'll submit this as well.

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

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 03/21/2012 08:46PM by davygravy.

davygravy Wrote:
-------------------------------------------------------
> OK, good enough is good enough, for now. I tried
> everything I could to get Device 1(left side) port
> to be recognized, but to no avail. So, we seem to
> stay with booting only from the Device 0 (right
> side) port. Linux does still recognize both
> ports, once the GoFlexNet is booted.
You need this patch: https://github.com/peaslaker/u-boot-ubit/commit/cda480dbf9986f028f381dc6b3eada7dc0866421
Details: http://forum.doozan.com/read.php?3,1893,3676#msg-3676

Thank you, that looks interesting.

I don't think I can put that as is in what I submit to mainline but I can try it out for the drop-in.

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

@ dpffann: thank you for posting that patch. I tried it and saw zero change in behavior. Not sure if I understand why, but there has been a lot of discussion since 2010 about changing the "IDE" stuff to something more modern and scalable.

Rogan Dawes had floated an RFC patch back then in an effort to fix an issue with a (new D-Link 323?) board, IIUC, but it isn't clear to me that it had ever been resolved. It attacked that very piece of ide.h. I tried his patch as well, but no luck. http://www.mail-archive.com/u-boot@lists.denx.de/msg36377.html
Wolfgang Denk seemed unsatisfied with some of the methods and symbols used in various patches.
(the mv_sata stuff works, but it seems to have hooks that are somewhat based on old-ish IDE stuff ... )

I'm not convinced yet, but I have considered it possible that the board for the GoFlexNet _inherently_ will only allow uboot to see a single port. I can get it to see port0 (right) or port1 (left), but not both on a single binary. If I delete

#define CONFIG_SYS_ATA_IDE0_OFFSET	MV_SATA_PORT0_OFFSET

from the SATA driver section below, it does then use Device 1 (left port).


Of course, once booted, Linux sees both ports.

What I _did_ do is to turn off the "phantom" or "ghost" 2nd (nonexistent) bus.

/*
 * SATA Driver configuration
 */
#undef CONFIG_SYS_IDE_MAXBUS
#define CONFIG_SYS_IDE_MAXBUS           1	
/*  hide phantom-nonexistent bus  */
#ifdef CONFIG_MVSATA_IDE
#define CONFIG_SYS_ATA_IDE0_OFFSET	MV_SATA_PORT0_OFFSET
#define CONFIG_SYS_ATA_IDE1_OFFSET	MV_SATA_PORT1_OFFSET
#endif /*CONFIG_MVSATA_IDE*/

Yields

GoFlexNet> ide reset
ide reset

Reset IDE: Bus 0: OK 
  Device 0: Model: TOSHIBA MK1655GSX  Firm: FG010D Ser#:  X9AHTNGQT
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 152627.8 MB = 149.0 GB (312581808 x 512)
  Device 1: not available

Note the

Reset IDE: Bus 0: OK

instead of

Reset IDE: Bus 0: .OK Bus 1: OK

which at least makes sense since it only has one bus available.

I had wondered if there was away to put some logic/decision structure to have it activate either Device 0 (right port) or Device 1 (left port).

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

• davy's Github Repo's rescue-dg

Edited 3 time(s). Last edit at 03/22/2012 07:19PM by davygravy.

I think this is now done. At this point, anyone with the Pogo E01, PogE02, Dockstar and GoFlex Net should be able to use a stock Debian 3.2 (or higher) kernel.

As far as I can tell and as far as I've heard, the replacements for Pogo E01/E02 and Dockstar are fine and should be truely transparent drop-in replacements. Literally, no adjustments to anything in the env vars need to be made for these, TTBOMK. I've tested it several times on E01, E02 and the Dockstar, and the replacement process seems reliable, reproducible and no more risky than any other flashing procedure.

I believe that the replacement for GoFlex Net is also good to go. It is _nearly_ as straightforward as the cases above, with one tiny deviation. Its default env var values are the same as Jeff set them to be, save for one item. I've defined the preset default arcNumber for it to be 2678, instead of 2097. (in hexadecimal, that would be a setting of 0xa76, instead of 0x831). Anyone doing a bit of research can see that my choice uses Sheevaplug eSATA as the fallback default, instead of Sheevaplug. To me this made sense, since the Sheevaplug eSATA is much closer to the GoFlex Net/Home, rather than the Sheevaplug (USB only, IIRC).

The benefit of this is that now the default behavior would be to enable both USB and the SATA right-side port ( identified as IDE:Bus 0: Device 0 if you are watching the boot sequence from console/netconsole) as a default, with the stock kernel. All the standard methods and developed tricks/hacks/scripts/whatever should work as well as they ever did.

There is one minor internal difference. In the previous U-Boot there was a duplication of the IDE Bus: 0. It would show up as a duplication/phantom Bus 1. (IIRC, this was also the case in the old Marvell UBoot in the Buffalo LSPro/KuroPro series.) Now the Bus shows up only once (which makes sense, since there is only one bus available). This will not affect behavior otherwise.

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

• davy's Github Repo's rescue-dg

Hi Dave,

Thank you for all the hard works! is there any plan to automate the installation (similar to Jeff's install_uboot_mtd0.sh)?

bodhi

Hopefully it will all be purely drop in replacement, using Jeffs already-proven scripts. Still a tad of testing to do. :)

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

• davy's Github Repo's rescue-dg

Awesome :-)

davygravy, could you perhaps put together a post which explains what the problem is with the original Doozan uBoot and what had to be done to allow it to work with the 3.2+ kernels? From this forum I've been able to surmise that apparently the 3.2 kernels used a different compression scheme and that it is somehow incompatible with L2cache. (Well, maybe... tell me if I am wrong here...)

Is the solution simply to disable L2cache, and if so, under what circumstances is it disabled? (Only in the uBoot? Permanently by the uBoot?)

Were any other changes to the code made?

Is the new uBoot completely backwards-compatible with the new one? Can I slip it in now, even before I upgrade from squeeze to wheezy?

Also, at some point -- and I think you are planning to get to this eventually -- it would be good if you could consolidate the above description with a script and some instructions which describe how to install the new uBoot in layman's terms.

We all appreciate what you've done to keep the uBoot code working with the modern Debian loads, especially with the Pogo E02s, which doesn't seem to have a solid support base.

Thanks again!

Well, the short end of a long story is that u-boot for kirkwood had never been conscious of disabling the Level 2 Cache at boot time. On the other hand, Linux now assumes that to be the case. The reason things wouldn't get passed the decompressing stage is that the processor would hang, because u-boot never disabled the L2C... (... can't everyone please just let's get along with one another!!!...)

After booting the kernel, the L2C resumes normal behavior.

I'm running Debian w/ various kernels (2.6 and 3.x), and everything works for me.

I've been using the posted PogoE02 interim uboot for a few weeks now and it works the same as the original one. Just following the directions at top post will get you there. Several other users have done the same and have returned (the expected) good results. If you aren't switching to a 3.2 or higher kernel, you can just stay where you are for now.

Eventually it will be an automated update system, using the scripts/infrastructure that Jeff set up.

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

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 03/27/2012 03:46PM by davygravy.

Trying to load the new uboot, file uboot.mtd0.kwb-pogo_e02-DGL2CDisabled.tar.gz in my PogoPlug P21 (Model Pogo-E02) and ran into my first question:

davygravy Wrote:
-------------------------------------------------------
> The "Bytes transferred" value should be hex 80000
> (decimal 524288) - if you don't get that value,
> then something is wrong.

And I get;

Marvell>> tftpboot 0x800000 uboot.mtd0.kwb-pogo_e02-DGL2CDisabled.tar.gz
tftpboot 0x800000 uboot.mtd0.kwb-pogo_e02-DGL2CDisabled.tar.gz
Using egiga0 device
TFTP from server 192.168.1.75; our IP address is 192.168.1.161
Filename 'uboot.mtd0.kwb-pogo_e02-DGL2CDisabled.tar.gz'.
Load address: 0x800000
Loading: #######################################
done
Bytes transferred = 197182 (3023e hex)
Marvell>>

Your example use the dockstar file and I'm using the E02 file. Should the bytes transferred for the E02 also be hex 80000 or is what I'm getting (hex 3023e) correct?

Thanks

Well, its a tar.gz file. Just untar it and then try.

I put that bit in the directions, so that if anyone missed the directions about untarring it, they'd still catch that bit on the length comparison.
-----------------
I'll go back and bold that chunk... I do get it, it can be easy for someone to miss.

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

• davy's Github Repo's rescue-dg

Edited 1 time(s). Last edit at 03/31/2012 02:26PM by davygravy.

davygravy Wrote:
-------------------------------------------------------
> Well, its a tar.gz file. Just untar it and then
> try.

That's embarrassing.

tftpboot 0x800000 uboot.mtd0.kwb-pogo_e02-DGL2CDisabled
Using egiga0 device
TFTP from server 192.168.1.75; our IP address is 192.168.1.161
Filename 'uboot.mtd0.kwb-pogo_e02-DGL2CDisabled'.
Load address: 0x800000
Loading: #################################################################
	 ######################################
done
Bytes transferred = 524288 (80000 hex)

And it works!

U-Boot 2011.12 (Feb 20 2012 - 21:21:59)
Pogoplug E02
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q3-67) 4.4.1
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709
Hit any key to stop autoboot:  5 

u-boot>>

Edited 1 time(s). Last edit at 03/31/2012 03:36PM by laprjns.

laprjns Wrote:
-------------------------------------------------------
> That's embarrassing.
hehehe, doesn't matter!
> tftpboot 0x800000
> uboot.mtd0.kwb-pogo_e02-DGL2CDisabled
> Using egiga0 device
> TFTP from server 192.168.1.75; our IP address is
> 192.168.1.161
> Filename 'uboot.mtd0.kwb-pogo_e02-DGL2CDisabled'.
> Load address: 0x800000
> Loading:
> ##################################################
> ###############
> ######################################
> done
> Bytes transferred = 524288 (80000 hex)
> [/code]
>
> And it works!
Only _that_ matters. ;)

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

• davy's Github Repo's rescue-dg

Dear All,

I just made updates my Dockstar based on Debian Wheezy to the newest version, but fortunately I had a backup of my system. I was not aware of the incompatibility of the uboot with the new kernel. Doesn't matter, I went back to my backup.

My question, as I lost somehow the red-line in the thread, it must by possible to update the uboot before I tried to update to the newer kernel and without using the netconsole, just in the normal booted system?

My suggestion:
1. Download and upack uboot.mtd0.kwb-2011.12-L2Cdisabled-davysconfig
2. # Erase the first 512k of /dev/mtd0
flash_erase /dev/mtd0 0 4
3 # Write the new bootloader
nandwrite /dev/mtd0 uboot.mtd0.kwb-2011.12-L2Cdisabled-davysconfig

Am I right, please give my feedback.

KR
Koenisch



Edited 1 time(s). Last edit at 04/04/2012 11:29AM by Koenisch.

Yes, This should work. I've upgraded all my kirkwood machines from linux, not from u-boot.

pazos Wrote:
-------------------------------------------------------
> Yes, This should work. I've upgraded all my
> kirkwood machines from linux, not from u-boot.

I can confirm, I just tested my suggestion and it worked perfect.

KR
Koenisch

Thanks for your hard work! Instruction are clear and I installed the new uboot without a hitch. I have been having ocassional problems upon rebooting where I would see in net console that it reached the point of starting kernel but after waiting I can't access the server through ssh and everything else looks like it's not working (I can't access web pages). Having no choice I pull out the plug and put it back in, but I'm not sure why it doesn'talways boot properly. this happned a few times. Also there is somekind if error everytime it boots, I'm not sure what it means.

U-Boot 2011.12 (Feb 20 2012 - 21:21:59)
Pogoplug E02
arm-none-linux-gnueabi-gcc (Sourcery G++ Lite 2009q3-67) 4.4.1
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709
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-0x000008000000 : "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: attached mtd1 to ubi0
UBI: MTD device name:            "mtd=3"
UBI: MTD device size:            91 MiB
UBI: number of good PEBs:        722
UBI: number of bad PEBs:         6
UBI: max. allowed volumes:       128
UBI: wear-leveling threshold:    4096
UBI: number of internal volumes: 1
UBI: number of user volumes:     0
UBI: available PEBs:             711
UBI: total number of reserved PEBs: 11
UBI: number of PEBs reserved for bad PEB handling: 7
UBI: max/mean erase counter: 1/1
UBIFS error (pid 0): ubifs_get_sb: cannot open "ubi:rootfs", error -19
Error reading superblock on volume 'ubi:rootfs'!
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)
1574408 bytes read
Loading file "/boot/uInitrd" from usb device 0:1 (usbda1)
6760358 bytes read
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   kernel 3.2.0-2-kirkwood
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1574344 Bytes = 1.5 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   ramdisk 3.2.0-2-kirkwood
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    6760294 Bytes = 6.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Thanks

@ Lewy1, everything up above looks normal to me. The only errors that I see in the messages are expected ones, triggered by the uboot not finding a recovery script token, for instance.

Btw, what is your usb_rootfstype? Ext2 or Ext3? Are you using a flash drive, or a USB<->SATA adapter w/ an actual HDD?

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

• davy's Github Repo's rescue-dg

I'm using a flash drive (cruzer), Ext2. Thanks for the response.

For some time now, I've wondered about the viability of adding an option to the uBoot to initialize and start the hardware watchdog timer before dispatching to the kernel. Then, in the kernel's boot sequence, it could reset or re-initialize the watchdog for its own purposes. One problem would be that the watchdog doesn't really provide much range time-wise. I think its timer can only be extended to give about a 20 second delay before the watchdog fires so it would have to be addressed early in the kernel's boot sequence, and addressing it via init.d would be out of the question. But such a scheme could theoretically be used to prevent this type of problem from leaving a remote system locked up in the event of a glitch.

hi,

is there any chance to test ab uboot fpr goflex net with sataboot and kernel 3.2 support?
i ve two devices to test....

cu major

major-tom007 Wrote:
-------------------------------------------------------
> hi,
>
> is there any chance to test ab uboot fpr goflex
> net with sataboot and kernel 3.2 support?
> i ve two devices to test....
>
> cu major

Yes, but I'm in the middle of getting caught up on some "house" stuff... I'll try to have something ready by 4/20 - the weekend, or so.

thank you,

davy

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

• davy's Github Repo's rescue-dg

lewy1 Wrote:
-------------------------------------------------------
> I'm using a flash drive (cruzer), Ext2. Thanks for
> the response.


Since it's Ext2, you might want to try running e2fsck for this stick on a different Linux box, just in case...

Booting from either SATA port (right or left) is now possible. Acks & thanks to Simon Baatz who brought this to us working on Kirkwood dual SATA units, as he, Gerald Kerma and Luka Perkov have been working hard a pair of other such devices (the ICY BOX NAS6210 and NAS6220) supported in mainline U-Boot.

U-Boot 2011.12 (Apr 17 2012 - 16:35:46)
Seagate GoFlexNet

SoC:   Kirkwood 88F6281_A1
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 
GoFlexNet> 
GoFlexNet> ide reset; ext2load ide 1:1 0x800000 /boot/uImage; ext2load ide 1:1 0x1100000 /boot/uInitrd; setenv bootargs 'console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 rootfstype=ext2 mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)'; bootm 0x800000 0x1100000

Reset IDE: Bus 0: OK Bus 1: OK 
  Device 0: Model: TOSHIBA MK1655GSX  Firm: FG010D Ser#:  X9AHTNGQT
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 152627.8 MB = 149.0 GB (312581808 x 512)
  Device 1: Model: ST9320325AS  Firm: 0002BSM1 Ser#: 5VD35RQG
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 305245.3 MB = 298.0 GB (625142448 x 512)
Loading file "/boot/uImage" from ide device 1:1 (hdb1)
1574664 bytes read
Loading file "/boot/uInitrd" from ide device 1:1 (hdb1)
5739979 bytes read
## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-3.1.10-kirkwood
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1574600 Bytes = 1.5 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   initramfs-3.1.10-kirkwood
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    5739915 Bytes = 5.5 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.1.10-kirkwood (root@debian) (gcc version 4.6.2 (Debian 4.6.2-11) ) #1 Thu Jan 19 06:14:30 UTC 2012
[    0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine: Marvell eSATA SheevaPlug Reference Board
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
[    0.000000] Kernel command line: console=ttyS0,115200 root=LABEL=rootfs 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] allocated 524288 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
...
[   44.410849] NET: Registered protocol family 10
Cleaning up temporary files....
INIT: Entering runlevel: 2
Using makefile-style concurrent boot in runlevel 2.
Starting internet superserver: inetd.
Starting OpenBSD Secure Shell server: sshd.
Starting Samba daemons: nmbd smbd.
[   47.473712] ip_tables: (C) 2000-2006 Netfilter Core Team
/etc/rc.local: 17: /etc/rc.local: cannot create /sys/class/leds/dockstar:orange:misc/trigger: Directory nonexistent
startpar: service(s) returned failure: rc.local ... failed!

Debian GNU/Linux wheezy/sid debian ttyS0

debian login:

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

• davy's Github Repo's rescue-dg

@ major_tom007:

At your own risk...(sorry, we all gotta do that disclaimer thingy...) here is a tar.gz of the U-Boot that I just finished testing on my GoFlex Net... it will enable __both__ SATA ports for booting. Make sure you __untar__gunzip___ before flashing. Flashing directions for it are the same as on the Pogoplug V2, and the Dockstar.

I'd really appreciate testing w/ respect to LED behavior, and if the SATA booting from both sides works for you. (see the operand/command in the post just one up ^^^).

davy

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

• davy's Github Repo's rescue-dg