> On Feb 16, 2016, at 11:21 PM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
>
> On Wed, Feb 17, 2016 at 6:24 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
>> 17.02.2016 05:02, Eric Snowberg пишет:
>>>
>>>> On Feb 16, 2016, at 1:16 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
>>>>
>>>> On Mon, Feb 15, 2016 at 10:11 PM, Eric Snowberg
>>>> <eric.snowb...@oracle.com> wrote:
>>>>> Fix the open firmware path property for sun4v SPARC systems. These
>>>>> platforms do not have a /sas/ within their path. Over time
>>>>> different OF addressing schemes have been supported. There
>>>>> is no generic addressing scheme that works across every HBA.
>>>>>
>>>>> Signed-off-by: Eric Snowberg <eric.snowb...@oracle.com>
>>>>> ---
>>>>> grub-core/osdep/linux/ofpath.c | 192
>>>>> +++++++++++++++++++++++++++++++++++++++-
>>>>> 1 files changed, 190 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/grub-core/osdep/linux/ofpath.c
>>>>> b/grub-core/osdep/linux/ofpath.c
>>>>> index a79682a..de51c57 100644
>>>>> --- a/grub-core/osdep/linux/ofpath.c
>>>>> +++ b/grub-core/osdep/linux/ofpath.c
>>>> ...
>>>>> @@ -444,6 +525,111 @@ of_path_of_scsi(const char *sys_devname
>>>>> __attribute__((unused)), const char *dev
>>>>> }
>>>>> else
>>>>> {
>>>>> +#ifdef __sparc__
>>>>> + int vendor = 0, device_id = 0;
>>>>> + check_hba_identifiers(sysfs_path, &vendor, &device_id);
>>>>> +
>>>>> + if (vendor == 0x1000) /* LSI Logic Vendor ID */
>>>>> + {
>>>>> + /* Over time different OF addressing schemes have been
>>>>> supported */
>>>>> + /* There is no generic addressing scheme that works across */
>>>>> + /* every HBA */
>>>>> + switch (device_id)
>>>>> + {
>>>>> + case 0x30: /* Rhea, Jasper 320, LSI53C1020/1030 */
>>>>> + case 0x50: /* SAS-1068E */
>>>>> + case 0x56: /* SAS-1064E */
>>>>> + case 0x58: /* Pandora SAS-1068E */
>>>>> + case 0x5d: /* Aspen, Invader, LSI SAS-3108 */
>>>>> + case 0x79: /* Niwot, SAS 2108 */
>>>>
>>>> That really does not scale. Can we enumerate device aliases and take
>>>> diskN and cdromN? So that we do not need to duplicate OBP logic?
>>>>
>>>
>>> Do you have an idea in mind on how to do this differently to make it scale
>>> better? This patch will default to the old disk@N for unknown HBAs. I
>>> agree it doesn’t scale that well, but new HBAs for SPARC with OF support
>>> don't come out that often.
>>>
>>> Before this patch, there isn’t a single SAS HBA that is enumerated
>>> correctly on SPARC. I went back 10 years and believe I have added every
>>> HBA with OF support. This isn’t duplicating OBP logic. The final part of
>>> the device path is vendor specific. OBP does not control that part of the
>>> path, it just uses it. Unfortunately there isn’t a standard. This code
>>> only gets run during setup/install (not boot) to return the path for OBP to
>>> use.
>>>
>>> You mentioned cdroms being enumerated with cdromN. I believe that type of
>>> enumeration stopped with IDE drives. A USB cdrom would be enumerated
>>> something like this:
>>>
>>> /pci@308/pci@1/usb@0/hub@1/storage@1/disk@0
>>>
>>> So the function that runs during boot: check_string_removable does not
>>> identify the cdrom properly.
>>>
>>> I’m open to making any changes to this patch if you have some ideas in
>>> mind. I tried to base it off of what was already in ofpath.c and I have
>>> some follow on patches coming the rely on this path being correct.
>>>
>>
>> I mean to read device aliases created by OBP (those displayed by
>> devalias OBP command).
>>
>> disk0 /pci@308/pci@1/usb@0/hub@1/storage@1/disk@0
>> ...
>
> Here is example
>
> Node 0xf022d638
> screen: '/pci@400/pci@1/pci@0/pci@7/pci@0/display@0'
> mouse:
> '/pci@400/pci@1/pci@0/pci@8/pci@0/usb@0,2/hub@2/device@4/mouse@1'
> disk7: '/pci@700/pci@1/pci@0/pci@0/@0/disk@p3'
> disk6: '/pci@700/pci@1/pci@0/pci@0/@0/disk@p2'
> disk5: '/pci@700/pci@1/pci@0/pci@0/@0/disk@p1'
> disk4: '/pci@700/pci@1/pci@0/pci@0/@0/disk@p0'
> scsi1: '/pci@700/pci@1/pci@0/pci@0/@0'
> net3: '/pci@600/pci@2/pci@0/pci@3/network@0,1'
> net2: '/pci@600/pci@2/pci@0/pci@3/network@0'
> rcdrom:
> '/pci@400/pci@1/pci@0/pci@8/pci@0/usb@0,2/hub@2/hub@3/storage@2/disk@0'
> rkeyboard:
> '/pci@400/pci@1/pci@0/pci@8/pci@0/usb@0,2/hub@2/device@4/keyboard@0'
> rscreen: '/pci@400/pci@1/pci@0/pci@7/pci@0/display@0:r1280x1024x60'
> net1: '/pci@400/pci@1/pci@0/pci@2/network@0,1'
> net0: '/pci@400/pci@1/pci@0/pci@2/network@0'
> net: '/pci@400/pci@1/pci@0/pci@2/network@0'
> disk3: '/pci@400/pci@1/pci@0/pci@0/@0/disk@p3'
> disk2: '/pci@400/pci@1/pci@0/pci@0/@0/disk@p2'
> disk1: '/pci@400/pci@1/pci@0/pci@0/@0/disk@p1'
> disk0: '/pci@400/pci@1/pci@0/pci@0/@0/disk@p0'
> disk: '/pci@400/pci@1/pci@0/pci@0/@0/disk@p0'
> scsi0: '/pci@400/pci@1/pci@0/pci@0/@0'
> scsi: '/pci@400/pci@1/pci@0/pci@0/@0'
> virtual-console: '/virtual-devices@100/console@1'
> name: ‘aliases'
>
With the example provided, the current code in ofpath.c, will not correctly
enumerate any of those drives.
To prove this, simply run grub-ofpathname /dev/sd<n> on your machine.
Then look at what follows disk@. I’m sure you will not see the “p”. Therefore
the wrong path is placed in grub.cfg and in core.img.
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
