lkml.org 
[lkml]   [2006]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Black box flight recorder for Linux
From
Date
Hi,

Andy Green <andy@warmcat.com> writes:

> A whole other way forward is to consider to replace the EEPROM from
> the original proposal (which does provide its own advantages such as
> simplicity, I accept) with something else that ends up on another
> PC. In this concept some logic presents a fake I2C peripheral to the
> DDC interface at an I2C address of our choosing. This logic acts as a
> bidirectional "UART" type of thing, allowing transfer of data in both
> directions between the Linux box being debugged and another PC.

Right. I think one could use something like ATMEL 89F2051 (20-pin 8051
non-SMD clones with flash and hardware UART) or something similar.

Client I2C is difficult in Linux (using general purpose I/O port) but
with a dedicated CPU it's not a problem (not sure about 400 kHz access).

> http://warmcat.com/milksop/filtror.html

Well, that's a bit more complicated. I'm not going to try that on
an experimental PCB :-)

> However this would be much simpler, not even needing RAM. It can hook
> to the second PC by the same I2C method, parallel printer port, RS232
> or USB depending on the level of complexity of the design.
>
> I guess the link will feel quite like a 9600 or 19200 baud serial port
> in terms of throughput.

Depends on I2C. With something like 400 kHz it should be faster,
probably like 115200.

> Maybe this effort is considered too esoteric, but it seems to me to be
> a reason to keep the DDC access drivers standalone, the
> hardware-specific framebuffer drivers can call through to them and we
> can use them in a clean way. I realize this is a bit of a late
> objection and that there was not previously much point to keeping them
> as separate things in the world.

Actually we have:
- the Xserver "hardware access" issue
- DRI/DRM
- now the I2C bus driver
- frame buffer

To avoid conflicts we really need them managed by a single driver.
Probably the GGI (KGI?) should be revisited?

Long-term project, unfortunatelly, but I think we'll have to do that
eventually.

The I2C, graphics subsystem and DRI/DRM could be sub-modules, with
the master module only keeping track of hardware access, mode
settings etc.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-06-08 01:55    [W:0.051 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site