Skip to content
Projects
Groups
Snippets
Help
Loading...
Sign in
Toggle navigation
S
SDB - Self-describing Bus
Project
Project
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
Wiki
Wiki
image/svg+xml
Discourse
Discourse
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Commits
Issue Boards
Open sidebar
Projects
SDB - Self-describing Bus
Commits
6ee4edac
Commit
6ee4edac
authored
Jun 14, 2013
by
Alessandro Rubini
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
sdbfs/doc: document subdir placement and explain use case
Signed-off-by:
Alessandro Rubini
<
rubini@gnudd.com
>
parent
926ed232
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
49 additions
and
15 deletions
+49
-15
sdbfs.in
sdbfs/doc/sdbfs.in
+49
-15
No files found.
sdbfs/doc/sdbfs.in
View file @
6ee4edac
...
@@ -369,24 +369,24 @@ The individual fields of the SDB structure are filled in the following way:
...
@@ -369,24 +369,24 @@ The individual fields of the SDB structure are filled in the following way:
@item addr
_
first
@item addr
_
first
For a file this is the first byte address where data is found.
For a file this is the first byte address where data is found.
This is currently an absolute address, which makes sense since
This is an absolute address for the first level of the tree
we have no subdirectories yet. However, some use cases require
and a relative address for subdirectories.
the directory information not to live at offset 0, while referring
Unfortunately, some use cases require the top-level
to a file that is at the beginning of the storage. SDB mandates
directory information not to live at offset 0, while referring
relative addresses because it's designed for gateware crossbars,
to a file that is at the beginning of the storage; thus the
so we'll have to understand how to deal with this when we have
use of absolute addresses for the outer directory level.
subdirectories. For the directory itself, addr
_
first is the
For the toplevel directory, addr
_
first is set to zero
address of the directory -- again, data-before-dir is not cleanly
because this is the smallest address used by the tree.
handled.
@itemx addr
_
last
@itemx addr
_
last
This is the last allocated byte for files. If the configuration
This is the last allocated byte for files. If the configuration
file requested extra size for the file, it is accounted here.
file requested extra size for the file, it is accounted here.
The trailing space is filled with zeroes by @file
{
gensdbfs
}
but
The trailing space is filled with zeroes by @file
{
gensdbfs
}
but
later the configuration file will be able to specify a filler value.
in later releases
For directories, this is the last byte written by any files
the configuration file will be able to specify a filler value.
within the directory itself.
For directories, this is the last byte encompassed by any files
within the directory itself, including subdirectories.
@item
@item
@end table
@end table
...
@@ -435,7 +435,10 @@ The following options are supported
...
@@ -435,7 +435,10 @@ The following options are supported
Specifies the maximum file size. This allows a writeable file to
Specifies the maximum file size. This allows a writeable file to
be extended in the filesystem image, for later overwriting with
be extended in the filesystem image, for later overwriting with
different data. The program doesn't
different data. For directories, this allows reserving space
in your filesystem, that can be filled later -- by another
@i
{
sdbfs
}
, whose toplevel directory must live at zero.
The program doesn't
check whether @i
{
maxsize
}
is smaller than the current size.
check whether @i
{
maxsize
}
is smaller than the current size.
@c FIXME: the maxsize/size issue
@c FIXME: the maxsize/size issue
...
@@ -446,9 +449,10 @@ The following options are supported
...
@@ -446,9 +449,10 @@ The following options are supported
you'll find the SDB records, whose first 4 bytes are the magic
you'll find the SDB records, whose first 4 bytes are the magic
number. For files this is the placement of the associated data.
number. For files this is the placement of the associated data.
For all files where @i
{
position
}
is not specified, @file
{
gensdbfs
}
For all files where @i
{
position
}
is not specified, @file
{
gensdbfs
}
will allocate storage sequentially after the
directory itself
,
will allocate storage sequentially after the
ir own directory listing
,
respecting block alignment. It's not possible, currently, to
respecting block alignment. It's not possible, currently, to
request all files to be stored sequentially at a specific address
request a file to stored sequentially to another file.
The progrma doesn't check for allocation conflicts.
@end table
@end table
...
@@ -477,6 +481,36 @@ the directory itself at offset 0x1000 and an area of 64kB of storage
...
@@ -477,6 +481,36 @@ the directory itself at offset 0x1000 and an area of 64kB of storage
reserved for @code
{
gensdbfs.c
}
. The leading part of such are is filled
reserved for @code
{
gensdbfs.c
}
. The leading part of such are is filled
with the current contents of the file (which is shorter than 64kB).
with the current contents of the file (which is shorter than 64kB).
@c --------------------------------------------------------------------------
@node Use-case Example
@subsection Use-case Example
Our first use case for @i
{
sdbfs
}
is storing structured data in the 8kB
@sc
{
eeprom
}
fo @sc
{
fmc
}
cards. The standard reuires the leading part
of the memory to include an @sc
{
ipmi-fru
}
data structure, with device
identification, but the rest of the memory can be used at will (the
@sc
{
fru
}
structures include the concept of @i
{
user-area
}
but it's not
flexible enough.
Memories for our devices, thus, are laid out with @i
{
sdbfs
}
: the root
directory lives at address 0x200 and refers to a file called
@t
{
IPMI-FRU
}
at address 0. Since most cards reuire calibration
information, such data items are stored in other @sc
{
sdb
}
files
in the top directory, where they can be accessed by the device driver
for the specific board -- identified using the @sc
{
fru
}
header.
In some cases, the @sc
{
fpga
}
driving these cards hosts a @i
{
White
Rabbit
}
@sc
{
ptp
}
daemon, that needs to access its own information,
such as the @sc
{
mac
}
address of the Ethernet port and internal
software-related parameters. To allow this later addition to
@sc
{
eeprom
}
contents, the top-level directroy includes a subdirectory,
manually set as @t
{
position=0x800; size=0x1800
}
.
When setting up the card for @i
{
White Rabbit
}
, the new @i
{
sdbfs
}
image
can be written starting at offset 0x800, (2kB), and extending at most
for6kB). The overall filesystem is internally consistent thanks
to the use of relative addresses.
@c ==========================================================================
@c ==========================================================================
@node sdb-read
@node sdb-read
@section sdb-read
@section sdb-read
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment