Search
20:48:48
froggey
there are old driver threads, but they clean themselves up at boot time
20:48:54
fitzsim
OK, nice, that explains it then
20:48:56
froggey
all hardware is automatically detected during boot
20:49:39
froggey
transfering images between different systems is an expected use case
20:51:23
fitzsim
OK, so I haven't been doing something weird there, good to know
21:32:20
fitzsim
PS/2 mouse init got 0 during probe (1)
21:46:53
froggey
you're welcome to fiddle with the PS/2 initialization sequence. I don't really want to touch it, it's not my favourite device
22:23:16
fitzsim
sure; there's a bunch of messages about PS/2 probing in cbmemc too
22:23:33
fitzsim
including mentioning finding the mouse
22:32:38
fitzsim
one idea I had was to write an FTDI driver, to enable a USB-to-serial console as early in boot as possible
22:32:58
fitzsim
then I could do PS/2 probe tests in a REPL
22:37:49
fitzsim
it's a USB-to-UART chip
22:38:00
fitzsim
well, they're one maker of that type of chip
22:38:02
fitzsim
Future Technology Devices International
22:38:19
fitzsim
sort of a funny name, I'd never seen it expanded before
22:39:13
froggey
that'd need the USB stack working too, right?
22:39:42
fitzsim
so I don't know how early it could get
22:40:02
fitzsim
I think where I'm at already it'd be available though
22:40:17
fitzsim
it would be a potentially more reliable way into any system
22:41:08
froggey
another problem... your device has a UHCI controller, there are only drivers for OHCI & EHCI controllers
22:42:59
fitzsim
I've poked around the Linux USB internals and spec before; it's quite hairy as I remember
22:45:41
froggey
a network driver might be easier, if you can get ahold of the datasheet
22:48:26
froggey
makes everything a lot easier, as suddenly you have slime/swank working