Drobo

DroboFS boot loader?

Does anybody have any docs on the droboFS boot loader?

I’m looking to add support for booting Fedora Linux directly.
Currently Fedora runs on the DroboFs in my lab using only a chroot’ed environment. The obvious next step is to boot into Fedora directly.

I suspect like other Marvel boards the Drobo’s have uboot.

Anybody know, or point to documentation?

Thanks,

-Parasense

I’m wondering how do you plan to support BeyondRAID. Did you manage to extract the BeyondRAID SCSI driver? Or do you plan to just have a standard Linux software RAID?

My understanding is the volume-management is actually handled in the vxWorks OS, not in Linux. The DroboFS is a two CPU board, with two OS running in parallel. Actually this is one of the big issues on my todo list, as it would seem the linux and vxWorks share the same memory, so Linux kernel would have to set some memory range to avoid corrupting vxworks.

In other words, BeyondRAID is proprietary, Data Robotics implemented in VXworks to avoid having to share the code back in linux. Linux is only for management, but there are a number of assumptions there. Obviously linux is used for the actual purpose of networking and storage sharing.

All that could be done in Fedora.

We are also looking at porting Fedora to the Synology kit too, fyi. :slight_smile:

My Fedora-chroot app is forthcoming.

You will enjoy being able to use GCC natively in the chroot without your cross-compile env. :wink:

Not only that, but all the apps you might have cross-compiled we have working in Fedora already, and are available by yum install.

It is a very reasonable assumption, but it seems to me that the link between those two is done via a SCSI driver in Linux. My guess is that you would still need that driver to be able to communicate with the vxWorks side.

I’m more of a Debian/Ubuntu guy myself, but hey, I will take any package management system we can get! :smiley:

It is a very reasonable assumption, but it seems to me that the link between those two is done via a SCSI driver in Linux. My guess is that you would still need that driver to be able to communicate with the vxWorks side.

The storage volumes are presented as a device node, on mine it’s /dev/sda1

So yes, via the storage sub-system.

Same here. But if you look under /sys/block/sda:

root@DroboFS:/sys/block/sda# ls -la drwxr-xr-x 7 root root 0 Feb 27 13:09 . drwxr-xr-x 6 root root 0 Feb 25 09:23 .. -r--r--r-- 1 root root 4096 Feb 28 09:09 capability -r--r--r-- 1 root root 4096 Feb 28 09:09 dev lrwxrwxrwx 1 root root 0 Feb 27 13:09 device -> ../../devices/dri_dnas_primary/dnas_adp_1/host0/target0:0:0/0:0:0:0 drwxr-xr-x 2 root root 0 Feb 25 09:23 holders drwxr-xr-x 3 root root 0 Feb 25 09:23 queue -r--r--r-- 1 root root 4096 Feb 28 09:09 range -r--r--r-- 1 root root 4096 Feb 28 09:09 removable drwxr-xr-x 3 root root 0 Feb 25 09:23 sda1 drwxr-xr-x 3 root root 0 Feb 25 09:23 sda2 -r--r--r-- 1 root root 4096 Feb 28 09:09 size drwxr-xr-x 2 root root 0 Feb 25 09:23 slaves -r--r--r-- 1 root root 4096 Feb 28 09:09 stat lrwxrwxrwx 1 root root 0 Feb 28 09:09 subsystem -> ../../block --w------- 1 root root 4096 Feb 28 09:09 uevent

And under /sys/bus/dri_dnas_fake_bus/devices/dnas_adp_1/host0/target0:0:0/0:0:0:0:

root@DroboFS:/sys/bus/dri_dnas_fake_bus/devices/dnas_adp_1/host0/target0:0:0/0:0:0:0# ls -la drwxr-xr-x 2 root root 0 Feb 28 09:29 . drwxr-xr-x 3 root root 0 Feb 28 09:29 .. lrwxrwxrwx 1 root root 0 Feb 28 09:29 block:sda -> ../../../../../../block/sda lrwxrwxrwx 1 root root 0 Feb 28 09:29 bus -> ../../../../../../bus/scsi --w------- 1 root root 4096 Feb 28 09:29 delete -r--r--r-- 1 root root 4096 Feb 28 09:29 device_blocked lrwxrwxrwx 1 root root 0 Feb 28 09:29 driver -> ../../../../../../bus/scsi/drivers/sd lrwxrwxrwx 1 root root 0 Feb 28 09:29 generic -> ../../../../../../class/scsi_generic/sg0 -r--r--r-- 1 root root 4096 Feb 28 09:29 iocounterbits -r--r--r-- 1 root root 4096 Feb 28 09:29 iodone_cnt -r--r--r-- 1 root root 4096 Feb 28 09:29 ioerr_cnt -r--r--r-- 1 root root 4096 Feb 28 09:29 iorequest_cnt -r--r--r-- 1 root root 4096 Feb 28 09:29 modalias -r--r--r-- 1 root root 4096 Feb 28 09:29 model -r--r--r-- 1 root root 4096 Feb 28 09:29 queue_depth -r--r--r-- 1 root root 4096 Feb 28 09:29 queue_type --w------- 1 root root 4096 Feb 28 09:29 rescan -r--r--r-- 1 root root 4096 Feb 28 09:29 rev lrwxrwxrwx 1 root root 0 Feb 28 09:29 scsi_device:0:0:0:0 -> ../../../../../../class/scsi_device/0:0:0:0 lrwxrwxrwx 1 root root 0 Feb 28 09:29 scsi_disk:0:0:0:0 -> ../../../../../../class/scsi_disk/0:0:0:0 lrwxrwxrwx 1 root root 0 Feb 28 09:29 scsi_generic:sg0 -> ../../../../../../class/scsi_generic/sg0 -r--r--r-- 1 root root 4096 Feb 28 09:29 scsi_level -rw-r--r-- 1 root root 4096 Feb 28 09:29 state lrwxrwxrwx 1 root root 0 Feb 28 09:29 subsystem -> ../../../../../../bus/scsi -rw-r--r-- 1 root root 4096 Feb 28 09:29 timeout -r--r--r-- 1 root root 4096 Feb 28 09:29 type -rw-r--r-- 1 root root 4096 Feb 28 09:29 uevent -r--r--r-- 1 root root 4096 Feb 27 13:09 vendor

I have to confess I’m not as familiar with the structure of SCSI drivers as I would like to be, but it seems to me that in /sys is located the interface to access the underlying BeyondRAID array. Not only that, there are both a disk interface (sda) and a generic SCSI device (sg0), to which the BeyondRAID specific commands are sent.

Again, most of this is speculation on my part from basically browsing the log files and the content of other system folders.

Will investigate. Does not seem very well documented. dmesg shows the scsi driver dri_dnas looking like any other scsi device. I wonder if it’s memory mapped? It would make sense to have a scsi driver use some kind of shared memory to communicate. I am guessing vxworks os exposes some memory, and the dri_dnas interfaces that way. I am aware the Drobo developers had to alter the linux kernel to avoid some memory areas, so perhaps they also don’t avoid other memory.

I don’t know if you have found the info you were looking for, but for what it’s worth, here is some interesting info from dmesg:

Mar  4 13:33:25 DroboFS kernel: Using UBoot passing parameters structure

In other words, yes it is a UBoot scheme.

Mar  4 13:33:25 DroboFS kernel: Kernel command line: console=ttyS0,115200 mtdparts=cfi_flash_0:3m@1m(kernel),21m@4m(root_fs),2m@59m(var) root=/dev/mtdblock1 rw cpu0=eth0,eth2,eth3,pcie0,pcie1,sata,nand,spi,usb0,usb1,usb2,tdm cpu1=eth1,nor,xor ip=169.254.1.0:169.254.123.234:::DB78xx0:eth0:none

How cool is that? CPU 0 handles almost everything, CPU 1 does only NOR and XOR.

Mar 4 13:33:25 DroboFS kernel: Memory: 512MB 0MB 0MB 0MB = 512MB total Mar 4 13:33:25 DroboFS kernel: Memory: 188800KB available (2984K code, 255K data, 108K init)
Well I’ll be damned. The FS has 512 MB of RAM, and could potentially be expanded to 2 GB. We have to find out whether or not it is actually feasible to do so, or if they are surface mounted.

Mar  4 13:33:25 DroboFS kernel: Marvell Development Board (LSP Version 2.0.2_Patch1_MV78XX0)-- DB-MV78200-A-BP  Soc: MV78200 LE

Found it! Confirmed 800 MHz processor dual-core processor.

Mar  4 13:33:26 DroboFS kernel: mice: PS/2 mouse device common for all mice

What? The FS supports PS/2 mice?

Mar 4 13:33:26 DroboFS kernel: device=eth0, addr=169.254.1.0, mask=255.255.0.0, gw=255.255.255.255, Mar 4 13:33:26 DroboFS kernel: host=DB78xx0, domain=, nis-domain=(none), Mar 4 13:33:26 DroboFS kernel: bootserver=169.254.123.234, rootserver=169.254.123.234, rootpath=
It seems the FS can always be reached under the IP 169.254.123.234/16.

So, what do we take away from this? It seems that the DroboFS has a very, very similar hardware to the Buffalo Linkstations. In fact, if you search for some of the messages from dmesg, you’ll find threads like this one. This is great news, since most Buffalo devices have been throughly investigated and most, if not all, have been reflashed to support stock distros, like Debian.

I have an old Linkstation Live v2 running Debian Squeeze. It works perfectly. I would love to have a DroboFS running Debian Squeeze too. Time will tell. :slight_smile: