A descripancy on SBP2 spec 1998

Eric Anderson ewa at apple.com
Fri Feb 24 15:50:28 PST 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* Eric Anderson <ewa at apple.com>
*
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
*
* 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