[SLOF] [PATCH] board-qemu/slof/vio-vscsi: Scan up to 64 SCSI IDs

[Laurent Vivier]

On 06/12/2018 12:23, Thomas Huth wrote:
> On 2018-12-06 12:07, Laurent Vivier wrote:
>> On 06/12/2018 12:02, Thomas Huth wrote:
>>> QEMU supports up the 64 SCSI IDs on the vscsi "bus", see the string
>>> "max_target = 63" in the source file hw/scsi/spapr_vscsi.c of QEMU.
>>> However, SLOF currently only checks the first 9 IDs on the vscsi adaptor,
>>> so when you try to boot from a CD-ROM like this, the boot fails:
>>>
>>>  qemu-system-ppc64 ... -device spapr-vscsi,id=scsi0,reg=0x2000 \
>>>     -drive file=/path/to/cdrom.iso,format=raw,if=none,id=dr1,readonly=on \
>>>     -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=63,lun=1,drive=dr1,id=scd1
>>>
>>> Thus let's change the amount of IDs that we scan in SLOF to 64, too, to
>>> match the ID range that QEMU provides.
>>>
>>> Signed-off-by: Thomas Huth <thuth at redhat.com>
>>> ---
>>>  board-qemu/slof/vio-vscsi.fs | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/board-qemu/slof/vio-vscsi.fs b/board-qemu/slof/vio-vscsi.fs
>>> index f2d4c6f..be11b69 100644
>>> --- a/board-qemu/slof/vio-vscsi.fs
>>> +++ b/board-qemu/slof/vio-vscsi.fs
>>> @@ -507,9 +507,9 @@ TRUE VALUE first-time-init?
>>>      10000 \ Larger value seem to have problems with some CDROMs
>>>  ;
>>>  
>>> -8 CONSTANT #dev
>>> +\ Report the amount of supported SCSI IDs - QEMU uses "max_target = 63"
>>>  : dev-max-target ( -- #max-target )
>>> -    #dev
>>> +    40
>>>  ;
>>>  
>>>  " scsi-probe-helpers.fs" included
>>>
>>
>> In SLOF, it seems the id is encoded on 3 bits, see:
>>
>> \ We use SRP luns of the form 8000 | (bus << 8) | (id << 5) | lun
>> \ in the top 16 bits of the 64-bit LUN
>> : (set-target)
>>     to current-target
>> ;
>>
>> : dev-generate-srplun ( target lun -- )
>>     swap 8 << 8000 or or 30 <<
>> ;
> 
> Let me write that in C code:
> 
>   srplun = ((target << 8) | 0x8000 | lun) << 0x30;
> 
> If I count correctly, we've got 7 bits here, not 3, so my patch should
> be fine ...?

Yes, you're right.
My comment was based on the comment of (set-target) and it seems wrong.

Thanks
Laurent