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?
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?
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...
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?
> I'm afraid not, at the very least the qcontrol.conf needs to register
> the hardware specific modules.
No worries :)
> For now you could try just:
> register("a125", "/dev/ttyS0")
> which ought to make the LCD work (substitute the right ttyS for your
> platform).
Yep, that works.... :)
So at least for that it's worth to have it build on i386/amd64 as well.
btw: have you an idea about the difference between lcd clear and reset?!
> 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)
> 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.
Good decision... not only does it save us from compiling modules... but
also... I really wouldn't trust the QNAP drivers/code a lot... they seem
to fuzz around in many places... and as said, their driver contains much
more than what we want to control.
> (rebooting is the only exception I'm aware of)
I saw that pic_raw command... what's the matter with it? I mean can't
one just use normal "reboot"? Is there anything special with it?
> I think we can ignore all this network/SATA/dm stuff, they are all
> supported fine by the mainline kernel code.
Absolutely... also... I wouldn't trust all their "tweaks" and alleged
bugfixes...
> > 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.
Yep... don't have it in mind now... but wasn't the actual check based on
the CPU platform, e.g. X86_CEDAVIEW in the case of my TS 569 Pro,... at
least that seems to be used for the actual conditional compiling...
There is a symbol TS569, but it seems to be only used to determine the
number of bays.
So perhaps QNAP itself uses this to know what kind of QNAP it is...
> > 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.
Ah I see...
> LEDs and buzzer
> are driven via the PIC.
and that via the PIC's serial device?
Well... my priority lies on the LEDs/buzzer... especially the 5 HDD LEDS
(not sure though, whether one can control them at all)...
nevertheless... having the buttons as well would of course be nice...
> qcontrol just drives the serial port directly from userspace, there is
> no kernel driver (other than the GPIO keys one).
I see... and I think this could be good news for us... cause one could
hope, that they didn't change the serial stuff too much between the
different devices...
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...
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.
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
