search

bigtreetech / CB1

OS System image for CB1
337 stars 49 forks source link

no USB Connection in actual image #133

Open rainerschulte opened 11 months ago

rainerschulte commented 11 months ago

I recently flashed my cb1 with the following image: CB1_Debian11_minimal_kernel5.16_20230303.img.xz

after installing klipper / Mainsail I cannot access my SKR mini e3 v3 due to lack of serial/by-id.

biqu@BTT-CB1:~$ ls -l /dev/serial/by-id
ls: cannot access '/dev/serial/by-id': No such file or directory
biqu@BTT-CB1:~$

in the meantime I tried to fix it with the udev-fix and run into the same results.

Does anyone have a working solution for this?

420noscope-exe commented 10 months ago

Yeah, don't use the minimal image. Use the Klipper image. The minimal image is put in place in case you want to use the CB1 for other projects, like a raspberry pi, or do something very specific or custom with klipper. If you are going to use it for basic Klipper use, don't create extra work for yourself, just use the Klipper image. This directory exists and functions on my Klipper install.

image

shine7k commented 9 months ago

me too When btt pi is connected to multiple USB devices at the same time, one of them will be disconnected randomly. btt pi+skr pico +ebb36 ebb36 disconnected soon after linux started my btt pi with the following image: CB1_Debian11_Klipper_kernel5.16_202300712.img.xz

Iskaroth commented 4 months ago

My CB1 can only see my Manta m5p in DFU mode. in regular mode it isn't listed. not even with lsusb. CB1_Debian11_Klipper_kernel5.16_20230303.img is installed. updated to CB1_Debian11_Klipper_kernel5.16_202300712.img the problem is still present.

Pneumanifest commented 4 months ago

My CB1 can only see my Manta m5p in DFU mode. in regular mode it isn't listed. not even with lsusb. CB1_Debian11_Klipper_kernel5.16_20230303.img is installed. updated to CB1_Debian11_Klipper_kernel5.16_202300712.img the problem is still present.

Sounds like you need to reconfigure and reinstall the firmware for the m5p

Iskaroth commented 4 months ago

It works again, I had to reflash the MCU in DFU mode. after 'make' you have to do make flash FLASH_DEVICE=(the boards USBId from lsusb) after the resest it worked again.

Pneumanifest commented 4 months ago

It works again, I had to reflash the MCU in DFU mode. after 'make' you have to do make flash FLASH_DEVICE=(the boards USBId from lsusb) after the resest it worked again.

Yeah, the make command only compiles the firmware. It still needs to be installed, either the way you did it in DFU mode or via an SD card with the firmware.bin file make creates.

Iskaroth commented 4 months ago

Yeah, the make command only compiles the firmware. It still needs to be installed, either the way you did it in DFU mode or via an SD card with the firmware.bin file make creates.

make is case sensitive, if you use make clean for example you erase the out folder from the compiling process. With make flash you flash the firmare to your targeted FLASH_DEVICE, that you can find in DFU mode via lsusb. You activate the DFU mode if you hold the Boot button and push the reset button for a second.

Pneumanifest commented 4 months ago

make is case sensitive, if you use make clean for example you erase the out folder from the compiling process. With make flash you flash the firmare to your targeted FLASH_DEVICE, that you can find in DFU mode via lsusb. You activate the DFU mode if you hold the Boot button and push the reset button for a second.

Correct. A lot of Linux and other's shell commands are case sensitive. DFU mode is not always available on all devices or is activated in different ways. Some boards require that the user extracts the .bin or other firmware file (again device specific) and use an SD card to install the firmware.