A descripancy on SBP2 spec 1998

sudeep.biswas at wipro.com sudeep.biswas at wipro.com
Sun Feb 26 20:37:03 PST 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* <sudeep.biswas at wipro.com>
*
Hi Eric,
Thanks
Looking at figure 8 in section 4.4, your explaination is rational, but,
in actual normalised page tables, there are two entries (lets
concentrate on first segment only), segment base address and offset.
If offset points to the segment start address, then where does segnment
base adress point to ?
Then as per the figure 8, does the segment base address point to system
page boundary of 0xCEA000, with offset pointing to segment start of
0xCEAA9C.
But explaination of segment_base_Hi/Lo under figure 24 in section 5.2.2
is confusing in this context.
I am quoting it for you as below.
" The segment_base_hi and segment_base_lo fields together shall specify
the base address of the
segment within the node's 48-bit system memory address range.
The segment_offset field shall contain the starting address for data
transfer within the segment."
Please comment.
Regards,
Sudeep
-----Original Message-----
From: Eric Anderson [mailto:ewa at apple.com]
Sent: Saturday, February 25, 2006 5:20 AM
To: Sudeep Biswas (WT01 - Semiconductors IP Solutions)
Cc: t10 at t10.org
Subject: Re: A descripancy on SBP2 spec 1998
Hello Sudeep,
I think the text is confusing because the structure called "page table"
would be more accurately called a "segment table".
Pages are the regions in memory that start at fixed multiples starting
|from address zero, according to page_size.
Segments are portions of memory described by the SBP-2 "page table".
Mostly, the boundaries of the segments will match the boundaries of the
system pages.
So, if a segment in the "page table" has an offset, the segment starts
at that offset, but the "system page" is not adjusted by the offset.
For example, consider Figure 8 in section 4.4, and the text in section
4.4:
The first segment starts at 0xCEAA9C and has length 0x0564.  This
segment fits into (part of) the system page that starts at 0xCEA000 and
has length 0x1000.
The second segment starts at 0xCEC000 and has length 0x1000.  This
second segment exactly matches the system page at 0xCEC000.
The fourth segment starts at 0xCEF000 and has length 0x03FC.  This
segment fits into (part of) the system page at 0xCEF000 with length
0x1000.
It is the system page boundaries at 0xCEA000, 0xCEB000, 0xCEC000, etc.,
that must not be crossed when accessing data.
So a legal access would be:
1. Read 0x0564 bytes at 0xCEAA9C
2. Read 0x1000 bytes at 0xCEC000
3. Read 0x1000 bytes at 0xCED000
4. Read 0x03FC bytes at 0xCEF000
However, this access would be illegal:
5. Read 0x0564 bytes at 0xCEAA9C
6. Read 0x2000 bytes at 0xCEC000
7. Read 0x03FC bytes at 0xCEF000
... because read 6 would "cross" the (system) page boundary at 0xCED000.
(By the way, read 6 would also be too large for 1394, where the largest
asynchronous packet size is 0x1000 bytes).
So, to answer your question, for normalized page tables, the system page
boundaries (which must not be crossed) exist at fixed multiples starting
|from address zero.  The system page boundary does not depend on the
segment base address in the ORB.
Does that help?
Eric
On Feb 22, 2006, at 12:11 AM, sudeep.biswas at wipro.com wrote:
>
> Hello Eric,
>
> Thanks.
>
> Certainly this has resolved my understanding of contigous data memory,
> but am I right in saying that, this explaination does not exactly fit
> on normalised page tables, because there the page boundary depends on
> the segment base address specified  in the page elements.
> Please comment.
>
> Thanks and regards,
> Sudeep biswas
> Project Engineer
> Wipro Technologies
> Pune, India
> 411057
>
> -----Original Message-----
> From: Eric Anderson [mailto:ewa at apple.com]
> Sent: Wednesday, February 22, 2006 12:58 AM
> To: Sudeep Biswas (WT01 - Semiconductors IP Solutions)
> Cc: t10 at t10.org
> Subject: Re: A descripancy on SBP2 spec 1998
>
> Hello Sudeep,
>
> Figure 7 is correct, but the example is confusing because some
> information is missing.
>
> For the example described using Figure 7, the ORB specifies p=0 and
> page_size=4.	p=0 (page_table_present=0) indicates that no page table
> is used, so data_descriptor points directly to the first byte of the
> data buffer.	However, page_size=4 indicates the system has 4096-byte
> (0x1000) page boundaries.  (This value of 4 is not clearly mentioned.)
>
> This combination of p=0 and page_size=4 places some restrictions on
> how the SBP-2 target may access the data.
>
> In the example, the data length is 0x3088 and the data address is
> 0x236174.  So, system page boundaries occur inside the buffer at
> 0x237000, 0x238000, and 0x239000 as suggested in Figure 7.
>
> A valid operation by the printer would be to transfer data like this:
>
> 1. Read 0x0E8C bytes at 0x236174
> 2. Read 0x1000 bytes at 0x237000
> 3. Read 0x1000 bytes at 0x238000
> 4. Read 0x01FC bytes at 0x239000
>
> For comparison, the following operation would be invalid:
>
> 5. Read 0x1000 bytes at 0x236174
> 6. Read 0x1000 bytes at 0x237174
> 7. Read 0x1000 bytes at 0x238174
> 8. Read 0x0088 bytes at 0x239174
>
> The second example (5-8) is invalid, because read 5 will cross the
> page boundary at 0x237000, and read 6 will cross the page boundary at
> 0x238000, and read 7 will cross the page boundary at 0x239000.
> Because p=0 and page_size=4, such reads are illegal.
>
> In other words, the page boundaries are located at multiples of 0x1000
> (in this example).  The location of the page boundaries does not
> depend on where the buffer begins; instead, the page boundaries are
> fixed in system memory based on the system page size.
>
> Does this answer your question?
>
> Eric Anderson
> Apple Computer, Inc.
> ewa at apple.com
>
>
> On Feb 21, 2006, at 1:28 AM, sudeep.biswas at wipro.com wrote:
>
>>
>> Hello ,
>>
>> This is regarding a confusion on SBP2 spec about contiguos data
>> buffer.
>> According to Page number 14 and 15, under 4.4 Data Buffers, and page
>> number 62, under 9.2 Data Transfer of SBP2 specs Rev 2 May 19,1998,
>> even when p =0 in an ORB, it can have page boudaries according to the
>> page_size (if page_size is nonzero), and without page boudaries if
>> page_size is zero, and in figure 7, the data descriptor points to a
>> data buffer start location where the first page boundary does not
>> appear on page_size, which shows an offset on first page.
>> If there should be a offset which is described by the data_descriptor
>> then what describes the base address for the same ?
>> or is there a bug in the figure 7, so that the data_descriptot shows
>> the base address/starting address and from the first page onwards,
>> every page has full page_sige only.
>>
>> Please advice ASAP since we are in mid of designing the SBP2 protocol
>> for our customer and we are stuck in between.
>>
>> Thanks and regards,
>>
>> Sudeep Biswas
>> Project Engineer
>> Wipro Technologies
>> Pune, India
>> 411057
>
>
>
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> addressee(s) and may contain proprietary, confidential or privileged
> information. If you are not the intended recipient, you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately and destroy all copies of this message and any
> attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of
> viruses. The company accepts no liability for any damage caused by any
> virus transmitted by this email.
>
> www.wipro.com
The information contained in this electronic message and any attachments to
this message are intended for the exclusive use of the addressee(s) and may
contain proprietary, confidential or privileged information. If you are not
the intended recipient, you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately and destroy all copies of this
message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should
check this email and any attachments for the presence of viruses. The company
accepts no liability for any damage caused by any virus transmitted by this
email.
www.wipro.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list