Re: DOC firmware problems

Re: DOC firmware problems

[David Woodhouse]

On 7 Feb 2002, raja wrote:

>  i have a DiskOnChip 2000 and i have the firmware doc504.exb loaded in it.
>   i am new to this and I have a few elementary doubts.
> 
> 1. Actually what does this firmware do inside the DOC ?

The firmware provides a BIOS extension, which allocates lots of sub-640K 
memory and installs an extra handler for the INT 13h disc service 
interrupt. Using this, it pretends to be a hard drive for the benefit of 
anything which uses the standard BIOS interfaces (i.e. DOS and 
bootloaders).

> 2. Can this firmware be replaced with some other one (i.e. can i format
> the DOC with some other open source firmwares )

Yes. You can install the Grub bootloader in place of the M-Systems BIOS 
extension. Rather than installing an INT 13h handler and continuing to let 
the machine boot as normal, it hooks the INT 18h bootstrap handler to 
start Grub instead of trying to boot from floppy or INT 13h device as 
normal. Grub can drive the DiskOnChip directly, without the assistance of 
the original firmware extension, and hence boot a kernel from it.

> 3. How does the BIOS recognize the DOC (is BIOS recognition related to
> firmware ) ?

The DiskOnChip is mapped into the host memory in the Upper Memory Blocks 
used for BIOS extensions - the first few bytes of it have the BIOS 
extension signature that has been defined since the first IBM BIOS to 
persuade the BIOS to run extra stuff at startup.

> I will be grateful if you could clarify my intial doubts ( cause i am
> stuck up with a DOC which has BIOS and firmware problems)

-- 
dwmw2

i node, u node, we all node for inodes

[Adam Wozniak]

Is there some sort of "JFFS2 internals for dummies" guide around?

I'm seeing odd behavior that I can only attribute to linked lists
in RAM becoming corrupt, and I'd like to get a better understanding
of how each list is used, etc...

In the JFFS2 context...

Is the next_phys chain in the raw_node_ref null terminated?

Is the trick with the NULL member in the inode_cache guaranteed to
always work,
or just at boot time?

Can an inode have raw nodes in multiple erase blocks?  If so, how is
this
represented in the raw_node_ref?

Does an inode have a fixed or maximum size?

Can a raw node contain data used by mutiple inodes?  If not, what
prevents
this from happening?

Some basic definitions would be helpful.

--Adam
-- 
Adam Wozniak (KG6GZR)   COM DEV Wireless - Digital and Software Systems
awozniak@comdev.cc      3450 Broad St. 107, San Luis Obispo, CA 93401
                        http://www.comdev.cc
                        Voice: (805) 544-1089       Fax: (805) 544-2055

Re: i node, u node, we all node for inodes

[David Woodhouse]

On Fri, 8 Feb 2002, Adam Wozniak wrote:

> Is there some sort of "JFFS2 internals for dummies" guide around?

Well, there was one here at linux.conf.au a few hours ago :)

> I'm seeing odd behavior that I can only attribute to linked lists
> in RAM becoming corrupt, and I'd like to get a better understanding
> of how each list is used, etc...
> 
> In the JFFS2 context...
> 
> Is the next_phys chain in the raw_node_ref null terminated?

Yes.
> 
> Is the trick with the NULL member in the inode_cache guaranteed to
> always work, or just at boot time?

Always _except_ during boot time, when the NULL member is in fact used.

> Can an inode have raw nodes in multiple erase blocks?  If so, how is
> this represented in the raw_node_ref?

Yes. The raw_node_ref has a next_phys pointer pointing to the next 
physical node on the medium, and a next_in_ino pointer pointing to the 
next physical node belonging to the same inode. They're unrelated.

> Does an inode have a fixed or maximum size?

Do you mean a node? Not explicitly, although each type of node has its own 
limits so you could deduce the maximum node size you'll ever see.

> Can a raw node contain data used by mutiple inodes?  If not, what
> prevents this from happening?

Each node belongs to only one inode. It's generated for that inode, added 
to the list for that inode, the physical node on the flash contains the 
inode number. Why would it get shared?

-- 
dwmw2

Re: i node, u node, we all node for inodes

[Adam Wozniak]

David Woodhouse wrote:
> > Does an inode have a fixed or maximum size?
> 
> Do you mean a node? Not explicitly, although each type of node has its own
> limits so you could deduce the maximum node size you'll ever see.

Maybe I don't have a clear idea of what an "inode" is in this context.
I normally think of an inode as a small block on a physical disk.  It
has
a fixed size, say 1K.  A file larger than 1K would span multiple inodes.
Or maybe I have this wrong.

> > Can a raw node contain data used by mutiple inodes?  If not, what
> > prevents this from happening?
> 
> Each node belongs to only one inode. It's generated for that inode, added
> to the list for that inode, the physical node on the flash contains the
> inode number. Why would it get shared?

In the case where a file consists of multiple inodes, and a data write
is performed which spans two inodes, does the write get broken into two
raw nodes, and linked into two inode chains, or is one raw node written
and somehow magically shared between two inode chains?

--Adam
-- 
Adam Wozniak (KG6GZR)   COM DEV Wireless - Digital and Software Systems
awozniak@comdev.cc      3450 Broad St. 107, San Luis Obispo, CA 93401
                        http://www.comdev.cc
                        Voice: (805) 544-1089       Fax: (805) 544-2055

Re: i node, u node, we all node for inodes

[David Woodhouse]

On Fri, 8 Feb 2002, Adam Wozniak wrote:

> > Do you mean a node? Not explicitly, although each type of node has its own
> > limits so you could deduce the maximum node size you'll ever see.
> 
> Maybe I don't have a clear idea of what an "inode" is in this context. I
> normally think of an inode as a small block on a physical disk.  It has
> a fixed size, say 1K.  A file larger than 1K would span multiple inodes.
> Or maybe I have this wrong.

Basically, 'inode' == 'file'. Or devicenode, symlink, etc. But basically 
it's a _logical_ filesystem object. Nothing physical on the medium - just 
the 'inode #' field in each physical node to say which inode they belong 
to.

> In the case where a file consists of multiple inodes, and a data write
> is performed which spans two inodes, does the write get broken into two
> raw nodes, and linked into two inode chains, or is one raw node written
> and somehow magically shared between two inode chains?

I think I've obsoleted this question. I _hope_ I have, at least. If not, 
read on a little...

JFFS is log-structured. Basically you keep a log of every change that 
happens to the filesystem, by writing packets of data, or 'nodes' to the 
flash to say what happened each time something changed. So you make a new 
file, and it'll pick an unused inode number for it, and write a 'node' to 
the flash containing the metadata (uid,gid,etc) for that file. 

It'll also write a 'dirent node', containing the inode# of the directory,
the name of the file and the inode number of the file - which is enough to
rebuild the filesystem tree.

Whenever you write to the file, it just appends another node (or nodes) to 
the flash, giving the new metadata (mtime, isize etc) and the new data. 

Even if you overwrite the beginning of the file, it just appends another 
node to the log, saying 'and now he wrote <this> <here>'...

It replays this log of events in chronological order, when it needs to 
know the 'current' state of the file/filesystem, in order to satisfy 
reads etc.

Imagine it with an infinite amount of flash, just writing out changelogs 
every time you change anything on the file system - and it's very simple. 

Then just take my word for it when I say that garbage collection doesn't 
really change the concept very much :)

-- 
dwmw2