On Sat, 2013-06-15 at 23:46 +0200, Christoph Anton Mitterer wrote: > > Is there any way (via /proc or /sys) to distinguish the different x86 > > QNAP platforms? > You talk about the concrete model name? Uhm... well haven't found > anything... dmidecode gives just what's attached.
Hrm, not a lot there to even say we are running on qnap at all, never
mind which specific variant.
We should probably put this to one side and worry about getting it to
work on your variant first.
> > Which qcontrol.conf did you use? You will need one for your platform.
> Ah? Oh... used none and simply expected stuff would run out of the box..
I'm afraid not, at the very least the qcontrol.conf needs to register
the hardware specific modules. For now you could try just:
register("a125", "/dev/ttyS0")
which ought to make the LCD work (substitute the right ttyS for your
platform).
> > You may also need to author a supporting C module for your platform
> > (which is the loaded by qcontrol.conf).
> AFAIU,... the current platform modules all use a serial device for
> sending LED/buzzer/fan commands, right?
Right, on ARM they are all controlled by communicating with the PIC via
a serial port, typically ttyS1.
> I've looked a bit around what QNAP itself doesn and it seems to work
> different.
Right, they have tended to put most of the functionality for driving the
PIC into kernel drivers. With very few exceptions that's not what we
want for upstream etc. (rebooting is the only exception I'm aware of)
>
> They offer a GPL tarball bundle on their homepage, which also contains
> their kernel (one can diff it against 3.4.6) to see what they
> changed.... it's a lot... they patch around in all different places from
> network drivers, over SATA drivers to the dm code.
I think we can ignore all this network/SATA/dm stuff, they are all
supported fine by the mainline kernel code.
> To me that makes the QNAP code even less trustworthy... since usually
> the kernel developers know what they do.
>
> Anyway,... it also contains many patches for GPIO stuff (I didn't
> include these) and also the qnap drivers I've included in
> qnap-linux.tar.xz.
> Seems this contains amongst others the LED/buzzer/fan stuff we want to
> use.
Yes, and I can see references to your 569 platform in there.
> But also much more... I'm not a kernel expert but it seems they also
> signal RAID stuff and other more system deep things... (last power
> state, etc.) via the PIC controller... I really think we should leave
> the hands of all these... god alone know what it can break.
Yes, certainly at first!
> > > There doesn't seem to be that gpio_keys module, or any such device in
> > > /dev/input.
> >
> > This is a platform specific driver on ARM. I'm not sure it is so common
> > to use gpio in this way on x86 platforms so it is possible that the
> > buttons etc are exposed differently. If they were using GPIO for it then
> > you would need to write a suitable platform specific driver.
> No idea about that... at least they don't have gpio_keys loaded...
>
> For what are you actually using the GPIOs? Just for the buttons? Or also for
> the LEDs/buzzer?
On the ARM platforms the GPIO keys is used for buttons. LEDs and buzzer
are driven via the PIC.
> > LEDs on the ARM platforms are controlled by the PIC. Do you know if the
> > x86 versions have the same one or even if they have one at all? You may
> > need to look into the qnap kernel drivers to figure it out.
> Ah... I see... well... yeah I think they also have a PIC then... but no idea
> which one.
>
> But with qcontrol... do you write your own PIC driver? Or is some
> generic one used... cause obviously you don't include all the kernel
> modifications they make.
qcontrol just drives the serial port directly from userspace, there is
no kernel driver (other than the GPIO keys one).
So most of what qnap do in their kernel patches is done in the qcontrol
userspace process instead.
Ian.
signature.asc
Description: This is a digitally signed message part
