grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] sparc64: fix OF path names for sun4v systems


From: Eric Snowberg
Subject: Re: [PATCH] sparc64: fix OF path names for sun4v systems
Date: Wed, 17 Feb 2016 11:05:04 -0700

> On Feb 16, 2016, at 11:21 PM, Andrei Borzenkov <address@hidden> wrote:
> 
> On Wed, Feb 17, 2016 at 6:24 AM, Andrei Borzenkov <address@hidden> wrote:
>> 17.02.2016 05:02, Eric Snowberg пишет:
>>> 
>>>> On Feb 16, 2016, at 1:16 AM, Andrei Borzenkov <address@hidden> wrote:
>>>> 
>>>> On Mon, Feb 15, 2016 at 10:11 PM, Eric Snowberg
>>>> <address@hidden> 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 <address@hidden>
>>>>> ---
>>>>> 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 address@hidden 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:
>>> 
>>> /address@hidden/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden
>>> 
>>> 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 
>> /address@hidden/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden
>> ...
> 
> Here is example
> 
>    Node 0xf022d638
>        screen:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden'
>        mouse:
> '/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden,2/address@hidden/address@hidden/address@hidden'
>        disk7:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/@0/address@hidden'
>        disk6:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/@0/address@hidden'
>        disk5:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/@0/address@hidden'
>        disk4:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/@0/address@hidden'
>        scsi1:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/@0'
>        net3:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden,1'
>        net2:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden'
>        rcdrom:
> '/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden,2/address@hidden/address@hidden/address@hidden/address@hidden'
>        rkeyboard:
> '/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden,2/address@hidden/address@hidden/address@hidden'
>        rscreen:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden:r1280x1024x60'
>        net1:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden,1'
>        net0:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden'
>        net:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/address@hidden'
>        disk3:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/@0/address@hidden'
>        disk2:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/@0/address@hidden'
>        disk1:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/@0/address@hidden'
>        disk0:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/@0/address@hidden'
>        disk:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/@0/address@hidden'
>        scsi0:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/@0'
>        scsi:  
> '/address@hidden/address@hidden/address@hidden/address@hidden/@0'
>        virtual-console:  '/address@hidden/address@hidden'
>        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 address@hidden  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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]