Linux 2.6.28 Porting to Oxnas

[WarheadsSE]

What I mean is I can't use uuid for the rootfs argument because it will not survive a dead disk.

[ftcodes]

But U-Boot on sata installed will not survive a dead disk either
If you copy the uuid to the new disk, that new file system will share the UUID.

see> tune2fs -U uuid device

So, it can survive a dead disk.

Here the explanation from the man page of tune2fs:

$this->bbcode_second_pass_code('', '
-U UUID
Set the universally unique identifier (UUID) of the filesystem
to UUID. The format of the UUID is a series of hex digits sepa‐
rated by hyphens, like this:
"c1b9d5a2-f162-11cf-9ece-0020afc76f16". The UUID parameter may
also be one of the following:

clear clear the filesystem UUID

random generate a new randomly-generated UUID

time generate a new time-based UUID
')

It is just stored in the filesystem.

The only other option is to put ehci hcd driver into a module and load it later. In fact on USB boot it is the best way you use uuid, anything else is just not predictable.

[WarheadsSE]

Which, on SATA boot is fine. However, since the pogoplugs have limited NAND, and a initrd is required for UUID or LABEL, we're at a touch of an impass. Hence my kexecboot procedures.

We're trying this viewtopic.php?f=23&t=1357 .. we're still evaluating.

[ftcodes]

USB storage is living on that unpredictable sd* naming scheme.
That is where the filesystem UUID comes in as well. I guess GPT has a partition uuid which would be more generic than the filesystem uuid.

Or you could make the SATA driver a module and load it after getting into booting the USB stick.

And I read it your idea is to have a initrd which is booting right into file system. In fact, there is not much needed for kexec. All what is required the SATA driver a small detection script and the file system driver. You should not consider a LSB-conforming system in that initrd. I remember that about a mega byte should be sufficient. But can be lot smaller if you use busybox stuff.

[ftcodes]

I implemented an ox820 gpio module which can be connected to the LED trigger support (config means) within the SATA driver.
I have not yet tested it but it is in my repository.

It is using standard GPIO interface of the kernel. As such, it is compatible with GPIO LED support within kernel.

It is not yet using IRQ supported GPIO events. But after testing, I am going to implement that. Useful for having the buttons working for some definable purpose.

[WarheadsSE]

xenoxaos and I successfully turned on EFI/GPT support, and configured a hybrid MBR/GPT and manually set a specific UUID, and named that within the root= bootargs variable.

It's a complete pain in the *****, but it works.

[ftcodes]

Manually setting the UUID is a special case and not normally done. But in specific cases it is definitely needed.
So, it sounds as a good option for those that do not have the possibility of getting away from the Flash boot.

[WarheadsSE]

I know that it is a special case, however, since many people seem to prefer to be able to simply apply a volume label, this is as close as I can get until we get u-boot to be capable enough.

[redsquare]

Good job on the SATA driver Ftcodes, my SATA 2.0 drive came up cleanly:

$this->bbcode_second_pass_code('', '
[ 6.250000] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 6.250000] ata1.00: ATA-8: WDC WD1600AAJS-00B4A0, 01.03A01, max UDMA/133
[ 6.260000] ata1.00: 312581808 sectors, multi 0: LBA48 NCQ (depth 0/32)
[ 6.270000] ata1.00: configured for UDMA/133
[ 6.270000] scsi 0:0:0:0: Direct-Access ATA WDC WD1600AAJS-0 01.0 PQ: 0 ANSI: 5
[ 6.280000] sd 0:0:0:0: [sda] 312581808 512-byte logical blocks: (160 GB/149 GiB)
[ 6.290000] sd 0:0:0:0: [sda] Write Protect is off
[ 6.290000] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 6.290000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 6.310000] sda: sda1
[ 6.320000] sd 0:0:0:0: [sda] Attached SCSI disk
[ 6.340000] scsi2 : usb-storage 1-1.4:1.0
[ 6.640000] ata2: SATA link down (SStatus 0 SControl 300)
')

[ftcodes]

With my device I have working LED support. I can control those via /sys/class/leds. Similar stuff can be done for the PogoPlugPro.

The LED Trigger support in the SATA driver has a little issue about not leaving the LED on long enough so you could actually see it.

Module for gpio access on OX820 Platform: gpio-ox820

Update: The disklight LED trigger uses now a timer to delay the switch off of the LED.