Qmk_firmware: 'lib/chibios' did not match any file(s) known to git.

Created on 7 Sep 2017  ·  10Comments  ·  Source: qmk/qmk_firmware

I'm running on a mac. I've brew installed all the dev environment libraries. I've cloned this repo, and initialized the submodule(s). Am I just dumb or is there a path issue here. There is a ../../lib/chibios relative to the keyboards/let_split directory, but there is not a lib folder IN the lets_split directory.

Robert@heiwa:lets_split[master]$ make rev2-default-avrdude
QMK Firmware vplanck-4.2
error: pathspec 'lib/chibios' did not match any file(s) known to git.
make: *** [rev2-default-avrdude] Error 1

Most helpful comment

We've supported building with either method in the past but we're actually about to change that, see #1659. The issue you ran into is one example of why, a change I made today turns out to be more complicated than anticipated.

Getting the timing right on the pro micro is tricky. You have a 5 second window where the bootloader accepts updates and if you're too soon or too late you'll miss it.

All 10 comments

Try running make lets_split-rev2-default-avrdude from the top level directory.

That gets me past that error. All the documentation I've read so far recommends running the command in the keyboard's directory. Is running it from the top level the new standard, or is this an actual issue?

...so I'm past that error now. This is what I'm seeing now.

Robert@heiwa:qmk_firmware[master]$ make lets_split-rev2-default-avrdude
QMK Firmware vplanck-4.2
Making lets_split/rev2 with keymap default and target avrdude

avr-gcc (GCC) 7.2.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Size before:
   text    data     bss     dec     hex filename
      0   18378       0   18378    47ca lets_split_rev2_default.hex

Compiling: ./tmk_core/common/command.c                                                              [OK]
Linking: .build/lets_split_rev2_default.elf                                                         [OK]
Creating load file for Flash: .build/lets_split_rev2_default.hex                                    [OK]
Detecting Pro Micro port, reset your Pro Micro now....
Detected Pro Micro port at /dev/tty.usbmodem1411

Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding

avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
Found programmer: Id = ""; type = ?
    Software Version = ?.; Hardware Version = ?.?
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: error: buffered memory access not supported. Maybe it isn't
a butterfly/AVR109 but a AVR910 device?
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

avrdude: butterfly_recv(): programmer is not responding
avrdude: error: programmer did not respond to command: leave prog mode
avrdude: butterfly_recv(): programmer is not responding
avrdude: error: programmer did not respond to command: exit bootloader

avrdude done.  Thank you.

make[1]: *** [avrdude] Error 1
make: *** [lets_split-rev2-default-avrdude] Error 1
Make finished with errors

I realize this is unrelated to the original issue and probably shouldn't go here, but I'm not sure how to continue trouble shooting. My pro micro is a ATmega32U4 at 5V/16MHz

We've supported building with either method in the past but we're actually about to change that, see #1659. The issue you ran into is one example of why, a change I made today turns out to be more complicated than anticipated.

Getting the timing right on the pro micro is tricky. You have a 5 second window where the bootloader accepts updates and if you're too soon or too late you'll miss it.

@InsidiousMind sorry, this was caused by a different issue. When we split up the Ergodoxes recently, there was no default keymap for the infinity (it used the ez's) - I've just added it, along with a keymaps folder for the infinity - if you pull, it should build.

have the same issue on Archlinux trying to build in a vagrant VM (VirtualBox) running the 'ubuntu/xenial64' (Ubuntu 16.04) box in an attempt to make my environment as clean as possible. Trying to build the default keymap for the ergodox infinity.

get same error. When i try in the top-level directory, it seems to build a ton of different keymaps and only targets 'default'. It also errors out on each attempt of building a keymap with 'no rule to make target lib/ugfx/gfx.mk'

EDIT - This is the comment I removed because i thought i fixed it, in reality it was @jackhumbert, so i'm adding this comment back to remove any confusion.

Thanks @jackhumbert !

Getting a similar error on WSL.

ivan@Ivan-PC ~/qmk_firmware % make iso_split_rshift
QMK Firmware v0.5.128
make: *** No rule to make target 'iso_split_rshift'. Stop.
Makefile:515: *** recipe commences before first target.  Stop.

Also, getting this when running wsl_install.sh˙

dpkg: warning: package not in database at line 1: grub-pc
dpkg: warning: found unknown packages; this might mean the available database
is outdated, and needs to be updated through a frontend method

@ivancuric this should be fixed by rebasing and making from the qmk root.

Also, try using MSYS2, as WSL is now depreciated.
https://docs.qmk.fm/newbs_getting_started.html

Thanks, managed to solve it in the meantime.

Awesome, glad to hear it.

Anyone else?

Sounds like this was resolved or abandoned.

If not, please reopen.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jmagee picture jmagee  ·  3Comments

vokeio picture vokeio  ·  3Comments

levitanong picture levitanong  ·  3Comments

MarkuBu picture MarkuBu  ·  3Comments

mrceephax picture mrceephax  ·  4Comments