On Mon, 2013-06-17 at 00:16 +0200, Christoph Anton Mitterer wrote: > On Sun, 2013-06-16 at 11:36 +0100, Ian Campbell wrote: > > Hrm, not a lot there to even say we are running on qnap at all, never > > mind which specific variant. > Yeah... I haven't found much more so far... any idea about other tools > like dmidecode which could give some info here?
Other than having a grep around in /sys and /proc for (caseinsensitive) qnap not much springs to mind. > With the ARM based devices you just base this on the presence of that > gpio stuff? Couldn't that be available on other machines as well? We initially gate on /proc/cpuinfo:Hardware to discover which broad class of QNAP device we are running on, then use GPIOs to discover the specific set of peripherals which this particular variant has (the main one being the LCD). However in order to be able to consult the GPIOs we need to know we are on some particular class of hardware, and not some totally different ARM or x86 box. > Do we need the check at all? You don't start anything per default, and > if the user configures a device which he doesn't have it's his fault... On ARM we use it to provide a suitable default config at package install time. We use it in the initscript to know whether LEDs/buzzers are available (i.e. to signal "boot completed"). On x86 we could provide an empty default configuration and abstract the initscript stuff a bit more to make it easier for people to configure by hand. However before we do that I think we need to simply get the daemon working at all on such platforms. > > I would rather want to have automatically determined,... which ttySx is > what... > If we could determine that correctly (i.e. it's an A125... or it's a PIC > xyz ... then we could probably ignore much of the "which QNAP model is > it"... sure they may not use all functionality of the PIC, but at least > this shouldn't cause much harm... > > Do you think it's possible to determine which serial device belongs to > what? And also which type of PIC/etc. is behind it? At the moment it sounds like it isn't even possible to determine that you are running on a QNAP device at all. Remember that once the package exists on x86 people could try and install on a whitebox x86 server or any random piece of hardware, we need to do the right (i.e. non-destructive) thing in this case. Even once we know it is a QNAP I don't think we can safely just probe serial ports looking for things. > btw: have you an idea about the difference between lcd clear and reset?! They are different byte sequences. If I had to guess I would say that clear just writes all cells to blank and reset actually power cycles the LCD and/or its controller. > > Right, on ARM they are all controlled by communicating with the PIC via > > a serial port, typically ttyS1. > Ok I see... so one more question for my understanding... if you use the > serial devices for all this... why do you have/need the gpio_stuff? > (answered below I guess) Yes, its for the buttons which don't go via the PIC. > > (rebooting is the only exception I'm aware of) > I saw that pic_raw command... what's the matter with it? It is from the QNAP drivers. We don't have that driver. > I mean can't > one just use normal "reboot"? Is there anything special with it? The reboot handing is done as the very last thing the kernel does, after it has stoppoed all processes umounted all filesystems and quiesced all the disks etc. This little bit is done in the kernel by opening the serial and writing the couple of control bytes to reset the board. > One thing about the gpio_keys... on the ARM devices... does this work > out of the box? I.e. is it auto-loaded... and/or is any special > configuration needed? Is a backend GPIO driver needed/auto-loaded? > Cause GPIO-keys by itself seems to be pretty generic... I think the installer arranges to have it loaded, by writing the name to /etc/modules. The module itself is pretty generic but the GPIO->keys mapping is platform specific. e.g. for an ARM platform it is defined in the platform code. See qnap_ts41x_buttons[] in arch/arm/mach-kirkwood/ts41x-setup.c (in the kernel). And something needs to provide the driver for the GPIO controller. > On the Debian amd64 kernels that module is not build... so I built my > own kernel with it... nevertheless... no success so far... perhaps I'm > missing something else... at least that device > in /dev/input/gpioSomething didn't turn up. You know that GPIO == General Purpose I/O, right? They are literally just pins on the processor (or some chipset peripheral, more likely on x86 I think) which you can control to be outputs or inputs, set high/low or read the current level (perhaps with an IRQ trigger). The only way to use them is to know how the hardware designed has wired them up. Something needs to tell the driver which GPIO lines correspond to which keys. This is a property of the particular hardware platform. You also need a driver for the particular GPIO controller on your platform. Ian.
signature.asc
Description: This is a digitally signed message part
