todbot / blink1

Official software for blink(1) USB RGB LED by ThingM
https://blink1.thingm.com/
Other
958 stars 236 forks source link

Openwrt Directions don't work anymore #325

Open symgryph opened 6 years ago

symgryph commented 6 years ago

I valiantly tried to follow openrt directions to no avail. Basically The 'working' process I managed was:

here is my dir structure

/project (root) /project/openwrt (openwrt) cd /project git clone https://github.com/todbot/blink1.git ./scripts feeds update packages/blink1

(assuming full clone of openwrt) (using LEDE/openwrt current)

cd openwrt
make menuconfig

choose architecture (in my case x86) choose toolchain (gnu-c) choose libstdc++ choose 'blink1' save

./scripts/feeds update -a
./scripts feeds install -a
make defconfig
cd packages
ln -s ../../blink1/openwrt openwrt
cd ..
make tools/install 
toolchain/install
make package/blink1/compile

LOTS of errors (here is a sample) make USBLIB_TYPE=HIDDATA OS="wrt" blink1-tool blink1-tiny-server -C /``` opt/build/test/new/openwrt/build_dir/target-x86_64_glibc/blink1 AR="x86_64-openwrt-linux$ make[3]: Entering directory '/opt/build/test/new/openwrt/build_dir/target-x86_64_glibc/blink1' ls: cannot access /home/installer/openwrt/OpenWrt-SDK-brcm47xx-for-linux-i486-gcc-4.6-linaro_uClibc-0.9.33.2/staging_dir/target-: No such file or directory x86_64-openwrt-linux-gnu-gcc -DUSE_HIDDATA -I/usr/include -std=gnu99 -g -DBLINK1_VERSION=\"""v17.01.4"-wrt-brcm47xx"\" -c hiddata.c -o hiddata.o ls: cannot access /home/installer/openwrt/OpenWrt-SDK-brcm47xx-for-linux-i486-gcc-4.6-linaro_uClibc-0.9.33.2/staging_dir/target-: No such file or directory cc1: note: someone does not honour COPTS correctly, passed 0 times In file included from /usr/include/features.h:374:0, from /usr/include/stdio.h:27, from hiddata.c:9: /opt/build/test/new/openwrt/staging_dir/toolchain-x86_64_gcc-7.3.0_glibc/include/sys/cdefs.h:459:49: error: missing binary operator before token "("

if __GNUC_PREREQ (4,8) || __glibc_clang_prereq (3,5)

                                             ^

In file included from hiddata.c:9:0: /usr/include/stdio.h:48:1: error: expected '=', ',', ';', 'asm' or 'attribute' before 'typedef' typedef struct _IO_FILE FILE; ^~~ /usr/include/stdio.h:49:1: error: unknown type name '__END_NAMESPACE_STD'


 Guess the openwrt is ONLY for specific version sadness.
todbot commented 6 years ago

Hi, Yes the OpenWrt compilation is both out-of-date and done by someone (me) who didn't quite know how to do proper OpenWrt cross-compilation.

If I'm reading this right, the error you're seeing is in cdefs.h?

blink(1) support is also in the mainline Linux kernel as part of the LED class subsystem. E.g. when blink(1) is plugged in, it shows up in /sys/class/leds/thingm0. Perhaps that would be faster to get going than blink1-tool?

todbot commented 6 years ago

Also, do you have a current guide for doing cross-compilation with OpenWrt? I'd like to try this out myself.

symgryph commented 6 years ago

not yet!

Thomas J Munn

On Mar 9, 2018, at 18:07, Tod E. Kurt notifications@github.com wrote:

Also, do you have a current guide for doing cross-compilation with OpenWrt? I'd like to try this out myself.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

MrMas commented 4 years ago

My current issue in regards to this is openwrt/src points to ../commandline but that doesn't exist in the repo.

todbot commented 4 years ago

Apologies, all the blink(1)-related C/C++ libraries and the blink1-tool commandline tool have been moved to https://github.com/todbot/blink1-tool/ Also I'm unclear if OpenWRT hasn't changed in the six years since I wrote those instructions. I'll try working through them now and update the openwrt guide. Thanks for your patience!

MrMas commented 4 years ago

Thanks @todbot I'll look at the new repo. I'm actually building QSDK which is based on OpenWRT. I found thingm in the repo and am building it. That will at least give me control at the system level. Thanks!

MrMas commented 4 years ago

Hi @todbot. I'm circling back around to this. I've built QSDK (built on OpenWRT) with HID_THINGM using kernel 3.14 (kinda old, I know but it's what I'm stuck with). I can now see the device in /sys/bus/hid/drivers/thingm but I'm not seeing anything in /sys/class/leds/ that relates to thingm. dmesg shows just one line when I connect the LED:

[ 48.221471] usb 1-1.4: new full-speed USB device number 4 using xhci-hcd

This contrasts with what I saw today in Ubuntu which closely parallels what you describe in https://github.com/todbot/blink1/tree/master/linux

Any ideas?

todbot commented 4 years ago

Hi! I believe also CONFIG_HID and CONFIG_LEDS_CLASS has to be set too, yes? https://cateee.net/lkddb/web-lkddb/LEDS_CLASS.html https://cateee.net/lkddb/web-lkddb/HID.html (I've not actually configured a kernel from scratch in a long time)

MrMas commented 4 years ago

That's correct -- and they are set.

It looks like the driver is being used. I added usb-utils so I can run lsusb. It's showing up. Also, cat /sys/kernel/debug/usb/devices shows the device and usbhid associated with it (same as Ubuntu):

D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=27b8 ProdID=01ed Rev= 1.01
S:  Manufacturer=ThingM
S:  Product=blink(1) mk3
S:  SerialNumber=3caaae8e
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
E:  Ad=01(O) Atr=03(Int.) MxPS=  64 Ivl=1ms

Maybe I'll reach out to the linux community to understand what is not running that produces the extra lines after USB device is found and mentioned in dmesg.

Thanks for the reply. If you have further ideas, I'd welcome them!

MrMas commented 4 years ago

@todbot I got the LED working, albeit both LEDs work in tandem (no individual control).

In 'make menuconfig', I had to enable hid, hid-generic, input-evdev (not sure why this one -- maybe that's a mistake), usb-hid.

In 'make kernel_menuconfig', I added HID_GENERIC.

As far as only getting unique control over both LEDs, I suspect that's due to me using an older kernel (3.14) and version of OpenWRT/QSDK.

Best!