[LinuxBIOS] [PATCH] v3: add a check for a termination member

[Peter Stuge]

On Sat, Jan 05, 2008 at 08:52:49PM -0800, ron minnich wrote:
> On Jan 5, 2008 5:11 PM, Peter Stuge <peter at stuge.se> wrote:
> > On Sat, Jan 05, 2008 at 02:44:55PM -0800, ron minnich wrote:
> > > NOT finding a file should be efficient.
> >
> > Yes.
> >
> > Where do the delay come from? Can anyone measure the LPC?
> 
> I will try to measure for you but remember it is  running uncached.
> Each and every access is a full LPC cycle, which is not really fast.

True. It is definately LPC access time causing this.


On Sun, Jan 06, 2008 at 05:17:31PM +0100, Carl-Daniel Hailfinger wrote:
> IIRC the PCEngines alix.1c has parallel flash

Nope. Both the soldered-on flash and obviously the LPC port are LPC.


> for all boards with LPC-to-SPI translation through a IT8716F Super
> I/O chip, the following applies:
> My calculations suggest that for optimal reads (4 bytes at a 4 byte
> boundary) with the IT8716F SPI translation function, we need (1 byte
> opcode + 3 bytes addr + 4 bytes data)* 8 = 64 clock cycles on the SPI
> bus alone. With a maximum of 33 MHz for the SPI clock on that particular
> chip (MUST verify that the chip is set to 33 MHz and not 16 MHz!), this
> optimal read takes 2 usec. Smaller reads take at least 1.25 usec. On top
> of the pure SPI bus time we have to add the time to transmit and receive
> that data over LPC.

Say 5 us per byte. That's rather slow for us, yes.


On Mon, Jan 07, 2008 at 10:40:02AM +0100, Carl-Daniel Hailfinger wrote:
> Well, we can't use CPU cache, but we can abuse CAR memory as cache

I like this.


> 1. Explicit "stop searching here" marker.

Maybe. But I do not think this is very clean..


On Mon, Jan 07, 2008 at 08:40:31AM -0800, ron minnich wrote:
> I would rather not walk all of empty space ever at any time.

I think the cost of one walk is ok for the flexibility gained.


> I like the end marker best.

I think the runtime-created index is much more fun.
It also keeps the lar format very clean.

In practice, the marker is the most efficient method, but it is a bit
of an abomination IMO. :p


How do we handle the integrity issue when a single flash block that
contains the start of a lar file is erased at runtime? (Thus breaking
a link in the list.)

That re-introduces the walking cost if we want to be able to find
any files beyond the erased block.

Maybe both run-time indexing and marker is good? But then there's no
point in the marker. So only build the index when a hole is
encountered.


//Peter