------- Comment From bherren.com 2012-07-18 22:51 EDT-------
So I'm going to use this bug as a place for a more complete
discussion on the problem of having the appropriate unit
addresses (the last @xxx part) in OFW path. Can somebody make
sure we have the right grub2 people CCed on the redhat side ?

So the unit address is more or less adapter specific. Each adapter
firmware has its own way of encoding it unfortunately. We can start
building specific knowledge about each adapter type in our grub2
configuration script (fortunately we have a limited number of
supported adapters with OF firmwares on them), but it might be better
to seek a solution involving the kernel drivers knowing about the
methods used by the firmware for the specific adapters it drives.

I'm adding Brian on CC who might help discuss that from a SCSI
driver perspective. Ideally we'd want to add a "devspec" attribute
to the sysfs nodes of the disks.

So I've collected some info about a couple of common adapters.

First VSCSI:

The unit address for vscsi is the SRP "LUN" value (which is not
the same as the SCSI LUN). The formula to calculate it can be found in
the linux driver:

static inline u16 lun_from_dev(struct scsi_device *dev)
{
return (0x2 << 14) | (dev->id << 8) | (dev->channel << 5) | dev->lun;
}

Currently, SLOF in qemu doesn't use the above formula however, but I
will change it ASAP so grub2 doesnt have to deal with two different
methods for vscsi.

Then we have IPR/Obsidian. This itself falls into two categories, the
newer "SIS64" variants, which you can recognize via the presence of an
"ibm,sis64" property in the adapter device node, and the older "SIS32"
variants which don't have this property.

For SIS32, the unit address is a "resource address" of the form

(bus << 16) | (id << 8) | lun

However, bus can be 0xff when using HW RAID

For SIS64, the unit address is the SAS WWN of the disk (though it
might get appended a ",lun" when applicable, we need to double check
that)

So here we'll have to detect the adapter type, we'll also need to be
careful that below the adpater PCI device in the device-tree can be
a "functional" sub node to differenciate SAS from SATA which some of
those support (for the optical drive). I don't know what the address
encoding scheme is for SATA btw, I'll try to find it out later.

Due to the above complexity, it's clearly a piece of logic that is
best located in the IPR driver itself, which could either expose an
ioctl to retrieve a disk unit address or better, would create sysfs
devspec attributes in the disk sysfs directories, but that won't
happen immediately.

I'm still trying to get more info about other supported adapters such
as our fiber channel ones.

Additionally, there are some methods that our adapter firmwares
provide that can be called within the OFW environment to retrieve
lists of attached devices. Those are used by the SMS menu system, and
would be handy for grub2 to be able to use as well in some cases, to
display fallback menus of devices maybe, that sort of thing...

I'm in the process of obtaining the documentation for these and will
update this BZ when I have it.

------- Comment From bjking1.com 2012-07-18 23:04 EDT-------
Is there any reason that grub2 can't use the ofpathname script that is included in powerpc-utils to translate from a logical device name (i.e. /dev/sda) to an OF path name? There are far too many different pieces of code trying to do this translation, which makes it nearly impossible to keep them all up to date when the OF binding changes.

As for doing something in the ipr driver itself, the ipr driver does expose some attributes in sysfs that the ofpathname script uses in order to be able to build the OF path, but they still require some intelligence to know how to use them.

However, I'm not convinced that adding a devspec to the ipr driver for each device is the right answer, since there are plenty of other I/O adapters that need special treatment as well - LSI SAS, QLogic FC, Emulex FC, VSCSI, VFC, and more...

------- Comment From pfsmorigo.com 2012-07-19 00:31 EDT-------
I tested ofpathname here and it shows the id in the pHyp's OFW format:

[root@localhost target0:0:0]# ofpathname /dev/sda1
/vdevice/v-scsi@1002/disk@8000000000000000

I discover that the boot-device was blank after the instalation:

0 > printenv
---environment variable--------current value-------------default value------
use-axon-ddr?               true                      true
real-mode?                  true                      true
direct-serial?              false                     false
use-nvramrc?                false                     false
selftest-#megs              0                         0
security-password
security-mode               0                         0
security-#badlogins         0                         0
screen-#rows                200                       200
screen-#columns             200                       200
output-device
oem-logo?                   false                     false
oem-logo
oem-banner?                 false                     false
oem-banner
nvramrc
input-device
fcode-debug?                true                      true
diag-switch?                false                     false
diag-file
diag-device
boot-command                boot                      boot
boot-file
boot-device
auto-boot?                  true                      true

The device tree and the alias:

0 > ls
3e597a18 :  /vdevice
3e597c98 :  |-- vty@1000
3e597e70 :  |-- l-lan@1001
3e5981f8 :  +-- v-scsi@1002
3e5b7368 :      |-- disk@0,0
3e5b7a58 :      +-- cdrom@2,0 ok

0 > devalias
scsi : /vdevice/v-scsi@1002
cdrom : /vdevice/v-scsi@1002/cdrom@2,0
disk : /vdevice/v-scsi@1002/disk@0,0
net : /vdevice/l-lan@1001
hvterm : /vdevice/vty@1000 ok

I set the boot-device and the system booted:
setenv boot-device disk

------- Comment From bherren.com 2012-07-19 01:10 EDT-------
So to begin with, I wasn't even aware we had an ofpathname script in powerpc-utils :-)

As for the problem with qemu vs. OFW using a different format for vscsi, as I said in my previous post, I will fix that in qemu/SLOF, hopefully later today.

------- Comment From bherren.com 2012-07-19 01:13 EDT-------
BTW. We should also make yaboot use ofpathname instead of its own built-in ofpath.... might cause some "interesting" dependencies but probably the way to go, a single script to rule them all and in the darkness of forth bind them !

------- Comment From bherren.com 2012-07-19 06:58 EDT-------
I've now fixed qemu to behave like vscsi. I've also added a vscsi-report-luns method (which unlike OFW one supports multiple SCSI IDs which from what I can tell grub will parse properly).

This makes grub2 works in qemu for me. I've pushed the fixes to github and will submit a qemu patch to get a new build of SLOF upstream.

So can we close this out, then?