USB drive not showing up on PC or car

[mattster98]

Just built this from scratch and while the log says it's connected to USB host and dmesg shows that it is connected (at least electrically) the drive does not show up. The backing file is fine, can mount it and see directories. Any ideas?

[marcone]

What does fdisk -l /backingfiles/cam_disk.bin say? Does the drive show up if you modprobe -r g_mass_storage followed by modprobe g_mass_storage ?

[mattster98]

OK - it's a new day and this morning the drive will show up on my Chromebook. Maybe just my Windows machine doesn't like it? Maybe it fully baked overnight? ;) Who knows.

Confirmed everything looked good and took it out to the car (Model X - 2019.8.5) - several observations.

After initial attempts failed as before, I plugged my go-to USB thumb drive in which is what I'm using in the meantime and it didn't work either. Rebooted the MCU and it started working again - tried the USB stick in both USB ports to make sure they acted similar. They did.

Plugged in the teslausb raspi (both pi ports into both tesla ports) and waited.. got the two-flash pattern and waited, and still no gray or red dot camera icon. Switched back to the USB stick and it wasn't recognized either. Seems like something about the raspi is freaking it out. Rebooted it again. Also tried powering the raspi from a 12v accessory adapter and only having the usb connection to the car's usb port. No difference.

Logs with requested commands below. (edit: cut/pasted them instead of attached) dmesg is immediately after the modprobe commands.

root@teslausb:# dmesg [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.14.98+ (dom@dom-XPS-13-9370) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1200 Tue Feb 12 20:11:02 GMT 2019 [ 0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] OF: fdt: Machine model: Raspberry Pi Zero W Rev 1.1 [ 0.000000] Memory policy: Data cache writeback [ 0.000000] cma: Reserved 8 MiB at 0x1b400000 [ 0.000000] On node 0 totalpages: 114688 [ 0.000000] free_area_init_node: node 0, pgdat c09caaf0, node_mem_map db010000 [ 0.000000] Normal zone: 1008 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 114688 pages, LIFO batch:31 [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 113680 [ 0.000000] Kernel command line: 8250.nr_uarts=0 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 smsc95xx.macaddr=B8:27:EB:EF:7B:9A vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=PARTUUID=d2cec6a2-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait modules-load=dwc2 quiet fastboot noswap ro [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes) [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Memory: 435212K/458752K available (6451K kernel code, 589K rwdata, 1992K rodata, 440K init, 673K bss, 15348K reserved, 8192K cma-reserved) [ 0.000000] Virtual kernel memory layout: vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xffc00000 - 0xfff00000 (3072 kB) vmalloc : 0xdc800000 - 0xff800000 ( 560 MB) lowmem : 0xc0000000 - 0xdc000000 ( 448 MB) modules : 0xbf000000 - 0xc0000000 ( 16 MB) .text : 0xc0008000 - 0xc0655050 (6453 kB) .init : 0xc08d4000 - 0xc0942000 ( 440 kB) .data : 0xc0942000 - 0xc09d54f8 ( 590 kB) .bss : 0xc09dadf0 - 0xc0a8338c ( 674 kB) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] ftrace: allocating 24128 entries in 71 pages [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [ 0.000029] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns [ 0.000062] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns [ 0.000145] bcm2835: system timer (irq = 27) [ 0.000712] Console: colour dummy device 80x30 [ 0.000739] console [tty1] enabled [ 0.000773] Calibrating delay loop... 697.95 BogoMIPS (lpj=3489792) [ 0.060289] pid_max: default: 32768 minimum: 301 [ 0.060785] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.060804] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.062103] Disabling memory control group subsystem [ 0.062270] CPU: Testing write buffer coherency: ok [ 0.063407] Setting up static identity map for 0x8200 - 0x8238 [ 0.064656] devtmpfs: initialized [ 0.074298] random: get_random_u32 called from bucket_table_alloc+0x88/0x1c4 with crng_init=0 [ 0.075331] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5 [ 0.075717] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.075746] futex hash table entries: 256 (order: -1, 3072 bytes) [ 0.077099] pinctrl core: initialized pinctrl subsystem [ 0.078430] NET: Registered protocol family 16 [ 0.081541] DMA: preallocated 1024 KiB pool for atomic coherent allocations [ 0.088219] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers. [ 0.088236] hw-breakpoint: maximum watchpoint size is 4 bytes. [ 0.088369] Serial: AMBA PL011 UART driver [ 0.091320] bcm2835-mbox 2000b880.mailbox: mailbox enabled [ 0.092043] uart-pl011 20201000.serial: could not find pctldev for node /soc/gpio@7e200000/uart0_pins, deferring probe [ 0.131262] bcm2835-dma 20007000.dma: DMA legacy API manager at dc80d000, dmachans=0x1 [ 0.133563] SCSI subsystem initialized [ 0.133783] usbcore: registered new interface driver usbfs [ 0.133877] usbcore: registered new interface driver hub [ 0.134088] usbcore: registered new device driver usb [ 0.140826] raspberrypi-firmware soc:firmware: Attached to firmware from 2019-02-12 19:42 [ 0.142977] clocksource: Switched to clocksource timer [ 0.228811] VFS: Disk quotas dquot_6.6.0 [ 0.228933] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 0.229227] FS-Cache: Loaded [ 0.229555] CacheFiles: Loaded [ 0.246808] NET: Registered protocol family 2 [ 0.247990] TCP established hash table entries: 4096 (order: 2, 16384 bytes) [ 0.248077] TCP bind hash table entries: 4096 (order: 2, 16384 bytes) [ 0.248171] TCP: Hash tables configured (established 4096 bind 4096) [ 0.248322] UDP hash table entries: 256 (order: 0, 4096 bytes) [ 0.248350] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [ 0.248696] NET: Registered protocol family 1 [ 0.249421] RPC: Registered named UNIX socket transport module. [ 0.249434] RPC: Registered udp transport module. [ 0.249439] RPC: Registered tcp transport module. [ 0.249444] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.251503] hw perfevents: no irqs for PMU, sampling events not supported [ 0.251584] hw perfevents: enabled with armv6_1176 PMU driver, 3 counters available [ 0.255379] workingset: timestamp_bits=14 max_order=17 bucket_order=3 [ 0.267618] FS-Cache: Netfs 'nfs' registered for caching [ 0.268942] NFS: Registering the id_resolver key type [ 0.268993] Key type id_resolver registered [ 0.269000] Key type id_legacy registered [ 0.269026] nfs4filelayout_init: NFSv4 File Layout Driver Registering... [ 0.273852] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)[ 0.274274] io scheduler noop registered [ 0.274287] io scheduler deadline registered (default) [ 0.274821] io scheduler cfq registered [ 0.274835] io scheduler mq-deadline registered [ 0.274843] io scheduler kyber registered [ 0.277122] BCM2708FB: allocated DMA memory 5b500000 [ 0.277187] BCM2708FB: allocated DMA channel 0 @ dc80d000 [ 0.285279] Console: switching to colour frame buffer device 82x26 [ 0.293234] bcm2835-rng 20104000.rng: hwrng registered [ 0.293463] vc-mem: phys_addr:0x00000000 mem_base=0x1ec00000 mem_size:0x20000000(512 MiB) [ 0.294454] vc-sm: Videocore shared memory driver [ 0.295055] gpiomem-bcm2835 20200000.gpiomem: Initialised: Registers at 0x20200000 [ 0.313700] brd: module loaded [ 0.325762] loop: module loaded [ 0.325784] Loading iSCSI transport class v2.0-870. [ 0.326637] usbcore: registered new interface driver smsc95xx [ 0.326667] dwc_otg: version 3.00a 10-AUG-2012 (platform bus) [ 0.326839] dwc_otg: FIQ enabled [ 0.326846] dwc_otg: NAK holdoff enabled [ 0.326852] dwc_otg: FIQ split-transaction FSM enabled [ 0.326867] Module dwc_common_port init [ 0.327281] usbcore: registered new interface driver usb-storage [ 0.327686] mousedev: PS/2 mouse device common for all mice [ 0.327744] IR NEC protocol handler initialized [ 0.327752] IR RC5(x/sz) protocol handler initialized [ 0.327757] IR RC6 protocol handler initialized [ 0.327762] IR JVC protocol handler initialized [ 0.327767] IR Sony protocol handler initialized [ 0.327772] IR SANYO protocol handler initialized [ 0.327777] IR Sharp protocol handler initialized [ 0.327782] IR MCE Keyboard/mouse protocol handler initialized [ 0.327787] IR XMP protocol handler initialized [ 0.329036] bcm2835-wdt 20100000.watchdog: Broadcom BCM2835 watchdog timer [ 0.329540] bcm2835-cpufreq: min=700000 max=1000000 [ 0.330155] sdhci: Secure Digital Host Controller Interface driver [ 0.330165] sdhci: Copyright(c) Pierre Ossman [ 0.330758] mmc-bcm2835 20300000.mmc: could not get clk, deferring probe [ 0.331370] sdhost-bcm2835 20202000.mmc: could not get clk, deferring probe [ 0.331551] sdhci-pltfm: SDHCI platform and OF driver helper [ 0.332104] ledtrig-cpu: registered to indicate activity on CPUs [ 0.332233] hidraw: raw HID events driver (C) Jiri Kosina [ 0.332461] usbcore: registered new interface driver usbhid [ 0.332469] usbhid: USB HID core driver [ 0.333481] vchiq: vchiq_init_state: slot_zero = db580000, is_master = 0

[ 0.344940] [vc_sm_connected_init]: end - returning 0 [ 0.345886] Initializing XFRM netlink socket [ 0.345945] NET: Registered protocol family 17 [ 0.346103] Key type dns_resolver registered [ 0.347951] registered taskstats version 1 [ 0.356177] uart-pl011 20201000.serial: cts_event_workaround enabled [ 0.356330] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2 [ 0.359258] mmc-bcm2835 20300000.mmc: mmc_debug:0 mmc_debug2:0 [ 0.359278] mmc-bcm2835 20300000.mmc: DMA channel allocated [ 0.414528] sdhost: log_buf @ db510000 (5b510000) [ 0.450974] mmc1: queuing unknown CIS tuple 0x80 (2 bytes) [ 0.452683] mmc1: queuing unknown CIS tuple 0x80 (3 bytes) [ 0.454365] mmc1: queuing unknown CIS tuple 0x80 (3 bytes) [ 0.457304] mmc1: queuing unknown CIS tuple 0x80 (7 bytes) [ 0.493037] mmc0: sdhost-bcm2835 loaded - DMA enabled (>1) [ 0.514386] of_cfs_init [ 0.514533] of_cfs_init: OK [ 0.515570] Waiting for root device PARTUUID=d2cec6a2-02... [ 0.516501] random: fast init done [ 0.560446] mmc0: host does not support reading read-only switch, assuming write-enable [ 0.562864] mmc0: new high speed SDHC card at address 0001 [ 0.563942] mmcblk0: mmc0:0001 GB1QT 29.8 GiB [ 0.566248] mmcblk0: p1 p2 p3 p4 [ 0.589631] mmc1: new high speed SDIO card at address 0001 [ 0.590822] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null) [ 0.590917] VFS: Mounted root (ext4 filesystem) readonly on device 179:2. [ 0.600115] devtmpfs: mounted [ 0.602590] Freeing unused kernel memory: 440K [ 0.602599] This architecture does not have kernel memory protection. [ 1.127414] systemd[1]: System time before build time, advancing clock. [ 1.285476] NET: Registered protocol family 10 [ 1.287307] Segment Routing with IPv6 [ 1.308810] ip_tables: (C) 2000-2006 Netfilter Core Team [ 1.332033] random: systemd: uninitialized urandom read (16 bytes read) [ 1.341029] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) [ 1.342070] systemd[1]: Detected architecture arm. [ 1.343625] systemd[1]: Set hostname to . [ 1.391550] random: systemd: uninitialized urandom read (16 bytes read) [ 1.630389] random: systemd-cryptse: uninitialized urandom read (16 bytes read) [ 2.458735] systemd[1]: Listening on udev Kernel Socket. [ 2.460506] systemd[1]: Started Forward Password Requests to Wall Directory Watch. [ 2.461513] systemd[1]: Listening on Journal Socket. [ 2.462077] systemd[1]: Reached target Swap. [ 2.491770] systemd[1]: Listening on Journal Socket (/dev/log). [ 2.493954] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point. [ 2.495703] systemd[1]: Created slice User and Session Slice. [ 2.770615] dwc2 20980000.usb: 20980000.usb supply vusb_d not found, using dummy regulator [ 2.770756] dwc2 20980000.usb: 20980000.usb supply vusb_a not found, using dummy regulator [ 3.223261] dwc2 20980000.usb: EPs: 8, dedicated fifos, 4080 entries in SPRAM [ 3.224607] dwc2 20980000.usb: DWC OTG Controller [ 3.224673] dwc2 20980000.usb: new USB bus registered, assigned bus number 1 [ 3.224767] dwc2 20980000.usb: irq 33, io mem 0x20980000 [ 3.225184] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 3.225201] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.225212] usb usb1: Product: DWC OTG Controller [ 3.225221] usb usb1: Manufacturer: Linux 4.14.98+ dwc2_hsotg [ 3.225230] usb usb1: SerialNumber: 20980000.usb [ 3.226444] hub 1-0:1.0: USB hub found [ 3.226554] hub 1-0:1.0: 1 port detected [ 4.637745] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null) [ 6.424042] systemd-journald[62]: Received request to flush runtime journal from PID 1 [ 8.268224] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned. [ 8.314669] bcm2835_alsa bcm2835_alsa: card created with 8 channels [ 9.073479] brcmfmac: F1 signature read @0x18000000=0x1541a9a6 [ 9.100680] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43430-sdio.bin for chip 0x00a9a6(43430) rev 0x000001 [ 9.101078] usbcore: registered new interface driver brcmfmac [ 9.309382] EXT4-fs (mmcblk0p4): recovery complete [ 9.315753] EXT4-fs (mmcblk0p4): mounted filesystem with ordered data mode. Opts: (null) [ 9.381033] EXT4-fs (mmcblk0p3): recovery complete [ 9.391181] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data mode. Opts: (null) [ 9.519738] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f [ 9.520972] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 7.11.15 Compiler: 1.24.2 ClmImport: 1.24.1 Creation: 2014-05-26 10:53:55 Inc Data: 9.10.39 Inc Compiler: 1.29.4 Inc ClmImport: 1.36.3 Creation: 2017-10-23 03:47:14 [ 12.844833] uart-pl011 20201000.serial: no DMA platform data [ 14.998909] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 14.998964] brcmfmac: power management disabled [ 15.959047] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 17.413322] Bluetooth: Core ver 2.22 [ 17.413513] NET: Registered protocol family 31 [ 17.413524] Bluetooth: HCI device and connection manager initialized [ 17.413558] Bluetooth: HCI socket layer initialized [ 17.413578] Bluetooth: L2CAP socket layer initialized [ 17.413663] Bluetooth: SCO socket layer initialized [ 17.431760] Bluetooth: HCI UART driver ver 2.3 [ 17.431783] Bluetooth: HCI UART protocol H4 registered [ 17.431790] Bluetooth: HCI UART protocol Three-wire (H5) registered [ 17.442209] Bluetooth: HCI UART protocol Broadcom registered [ 18.036994] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 18.037010] Bluetooth: BNEP filters: protocol multicast [ 18.037047] Bluetooth: BNEP socket layer initialized [ 22.266177] FS-Cache: Netfs 'cifs' registered for caching [ 22.266999] Key type cifs.spnego registered [ 22.267032] Key type cifs.idmap registered [ 23.340110] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-2 [ 27.439474] Mass Storage Function, version: 2009/09/11 [ 27.439493] LUN: removable file: (no medium) [ 27.439655] LUN: removable file: /backingfiles/cam_disk.bin [ 27.439665] Number of LUNs=1 [ 27.445904] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 [ 27.445923] g_mass_storage gadget: g_mass_storage ready [ 27.445938] dwc2 20980000.usb: bound driver g_mass_storage [ 27.472329] dwc2 20980000.usb: new device is high-speed [ 27.825630] dwc2 20980000.usb: new device is high-speed [ 27.883728] dwc2 20980000.usb: new address 10 [ 27.896746] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage [ 257.430353] Mass Storage Function, version: 2009/09/11 [ 257.430381] LUN: removable file: (no medium) [ 257.430603] LUN: removable file: /backingfiles/cam_disk.bin [ 257.430616] Number of LUNs=1 [ 257.437338] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 [ 257.437363] g_mass_storage gadget: g_mass_storage ready [ 257.437383] dwc2 20980000.usb: bound driver g_mass_storage root@teslausb:~# fdisk -l /backingfiles/cam_disk.bin Disk /backingfiles/cam_disk.bin: 26 GiB, 27868647424 bytes, 54430952 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xd9f482f6

Device Boot Start End Sectors Size Id Type /backingfiles/cam_disk.bin1 2048 54430951 54428904 26G c W95 FAT32 (LBA) root@teslausb:~#

[lapean111]

I have this issue too. Mine will show up and record once, but the minute it loses power when the Tesla goes to sleep, it won't come back after it boots. If I run fsck, it will work again once, but fail again after it reboots.

[marcone]

With the Pi attached to the host of your choice (whether PC, Tesla or otherwise), can you ssh into the Pi, then touch /tmp/archive_is_unreachable and look at /mutable/archiveloop.log ? That should show the drive being disconnected from mass storage, fsck being run on the image, then the drive being published as mass storage again.

For what it's worth, I use a battery (a.k.a portable phone charger) connected to the power port of the Pi to provide continuous power. I also made a "data-only" USB cable by putting a bit of tape over the 5V lead of the USB cable, because I noticed the car pulling power from the battery through the Pi when the car was off (the battery showed a load of 400mA with the car off, whereas normally the Pi only used about 100-150mA)

[marcone]

I noticed that I sometimes, but not always, get kernel stack dumps in dmesg when connecting the Pi to a host. This is apparently a kernel issue, and running rpi-update to update the kernel to 4.19 appears to have fixed that. Might be a worth a try for you, @mattster98, @lapean111

[mattster98]

Isn't that part of the setup script already? Pretty sure I watched it update..

On Sat, Apr 6, 2019, 8:31 PM marcone notifications@github.com wrote:

I noticed that I sometimes, but not always, get kernel stack dumps in dmesg when connecting the Pi to a host. This is apparently a kernel issue, and running rpi-update to update the kernel to 4.19 appears to have fixed that. Might be a worth a try for you, @mattster98 https://github.com/mattster98, @lapean111 https://github.com/lapean111

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/8#issuecomment-480548387, or mute the thread https://github.com/notifications/unsubscribe-auth/ABZr8qOkreRM3wvLgNm9Z8jVKIOpS2VMks5veTxygaJpZM4cgAG- .

[marcone]

The setup scripts run apt-get upgrade, but that only updates packages, not the kernel. You can check which kernel you're running with uname -r. For me, it was running 4.14.98+ before, and now it's running 4.19.32+

[mattster98]

You're absolutely right. It was 4.14, not 4.19 after rpi-update. I guess some part of the setup script looked similar.

I'll do some more testing with a single usb cable later.

On Sat, Apr 6, 2019 at 9:01 PM marcone notifications@github.com wrote:

The setup scripts run apt-get upgrade, but that only updates packages, not the kernel. You can check which kernel you're running with uname -r. For me, it was running 4.14.98+ before, and now it's running 4.19.32+

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/8#issuecomment-480549779, or mute the thread https://github.com/notifications/unsubscribe-auth/ABZr8vfDJXzrYI715iE4A8Xu0gZxB2dlks5veUNfgaJpZM4cgAG- .

[mattster98]

Car isn't seeing the usb drive after rpi-update. Will need to diagnose.. :(

On Sat, Apr 6, 2019, 9:11 PM Matt Smith matt@mattsmith.net wrote:

You're absolutely right. It was 4.14, not 4.19 after rpi-update. I guess some part of the setup script looked similar.

I'll do some more testing with a single usb cable later.

On Sat, Apr 6, 2019 at 9:01 PM marcone notifications@github.com wrote:

The setup scripts run apt-get upgrade, but that only updates packages, not the kernel. You can check which kernel you're running with uname -r. For me, it was running 4.14.98+ before, and now it's running 4.19.32+

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/8#issuecomment-480549779, or mute the thread https://github.com/notifications/unsubscribe-auth/ABZr8vfDJXzrYI715iE4A8Xu0gZxB2dlks5veUNfgaJpZM4cgAG- .

[injured10]

ssh pi@teslausb.local and running sudo rpi-update made the drive visible for me

[mattster98]

I got mine to show for a moment but then went away.. nothing I can see in logs to explain. Did want to ask if this is what you see.. specifically the first "LUN" line with "no medium". From dmesg.

[ 767.495316] Mass Storage Function, version: 2009/09/11 [ 767.495343] LUN: removable file: (no medium) [ 767.495571] LUN: removable file: /backingfiles/cam_disk.bin [ 767.495585] Number of LUNs=1 [ 767.503748] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 [ 767.503774] g_mass_storage gadget: g_mass_storage ready [ 767.503794] dwc2 20980000.usb: bound driver g_mass_storage [ 797.201145] dwc2 20980000.usb: new device is high-speed [ 797.274254] dwc2 20980000.usb: new device is high-speed [ 797.332336] dwc2 20980000.usb: new address 6 [ 797.344770] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage root@teslausb:~#

On Sun, Apr 7, 2019, 2:03 PM injured10 notifications@github.com wrote:

ssh pi@teslausb.local and running sudo rpi-update made the drive visible for me

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/8#issuecomment-480614944, or mute the thread https://github.com/notifications/unsubscribe-auth/ABZr8rDbOEJ6QrK35DG4b05bBoLI8Aa_ks5vejLdgaJpZM4cgAG- .

[marcone]

I see the same "no medium" line, both in the working and non-working case.

Non-working case (turns out I had a bad, perhaps charge-only, cable):

[   33.935768] Mass Storage Function, version: 2009/09/11
[   33.935788] LUN: removable file: (no medium)
[   33.935961] LUN: removable file: /backingfiles/music_disk.bin
[   33.936071] LUN: removable file: /backingfiles/cam_disk.bin
[   33.936079] Number of LUNs=2
[   33.939169] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11
[   33.939187] g_mass_storage gadget: g_mass_storage ready
[   33.939202] dwc2 20980000.usb: bound driver g_mass_storage

working:

[   32.452060] Mass Storage Function, version: 2009/09/11
[   32.452078] LUN: removable file: (no medium)
[   32.452236] LUN: removable file: /backingfiles/music_disk.bin
[   32.452342] LUN: removable file: /backingfiles/cam_disk.bin
[   32.452351] Number of LUNs=2
[   32.462678] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11
[   32.462698] g_mass_storage gadget: g_mass_storage ready
[   32.462713] dwc2 20980000.usb: bound driver g_mass_storage
[   32.568266] dwc2 20980000.usb: new device is high-speed
[   33.224901] dwc2 20980000.usb: new device is high-speed
[   33.326938] dwc2 20980000.usb: new device is high-speed
[   33.524499] dwc2 20980000.usb: new address 20
[   33.538451] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage

[lapean111]

No matter what I do, I can't get the drive to reliably show up for the Tesla. I have the pi permanently powered with a battery, so it's not hard rebooting ever. I can manually get the camera drive to show up by doing a modprob -r followed by a modprobe on the g_mass_storage.

I can't think of a way to schedule this without losing some recording time.

Anyone have any ideas??

[marcone]

If your Pi is already continuously-powered, then the only other things that come to mind are (1) check your cable is good and (2) run rpi-update to update to kernel 4.19. Does it work if you plug into a PC (using the same cable) ?

[lapean111]

I was doing some more tests yesterday, and have determined that keeping the pi always powered may be causing some issues. I have switched it now to be powered from the cig lighter, and have a data only cable going to the USB port on the Tesla. When I pull into the garage, and the pi connects to the WIFI, the drive disconnects from the Tesla. When I start my next drive, it takes a minute or two for the drive to show up while the pi is booting, but seems to always work.

Not sure what the perfect way to do this is...

[Rykemapo]

@marcone How are you able to run rpi-update with the read-only filesystem?

[marcone]

Run remountfs_rw first, then rpi-update

[Rykemapo]

I don't see that script anywhere

[marcone]

The headless setup script downloads it to /root/bin/ If you use manual setup, you can either download it yourself, or just do "mount -o remount,rw /; mount -o remount,rw /boot"

[marcone]

@lapean111 re: your comment above, I've been running mine continuously powered for 3 days now without issue.

[Rykemapo]

@marcone Found it. Thanks.

[rikbrown]

I'm also experiencing this problem.

Running modprobe -r g_mass_storage; modprobe g_mass_storage makes it reappear.

I checked /etc/modules and g_mass_storage wasn't there, so I added it.

Now on startup I see this in dmesg:

[    3.497541] Mass Storage Function, version: 2009/09/11
[    3.497570] LUN: removable file: (no medium)
[    3.523594] lun0: unable to open backing file: /backingfiles/cam_disk.bin
[    3.523779] g_mass_storage 20980000.usb: failed to start g_mass_storage: -2

Continuing to debug,

[mattster98]

Did you run the setup script? Sounds like you're missing a lot.

On Sat, Apr 13, 2019, 6:05 PM Rik Brown notifications@github.com wrote:

I'm also experiencing this problem.

Running modprobe -r g_mass_storage; modprobe g_mass_storage makes it reappear.

I checked /etc/modules and g_mass_storage wasn't there, so I added it.

Now on startup I see this in dmesg:

[ 3.497541] Mass Storage Function, version: 2009/09/11 [ 3.497570] LUN: removable file: (no medium) [ 3.523594] lun0: unable to open backing file: /backingfiles/cam_disk.bin [ 3.523779] g_mass_storage 20980000.usb: failed to start g_mass_storage: -2

Continuing to debug,

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/8#issuecomment-482893665, or mute the thread https://github.com/notifications/unsubscribe-auth/ABZr8qyqZw6kPxqBZvwVka5VgWNChRD4ks5vglSQgaJpZM4cgAG- .

[rikbrown]

I followed the one step guide. It went through everything, sequences of flashes etc, and was flashing the green light as described.

Oddly /root/bin/remountfs_rw was missing, which makes me wonder if something went wrong.

Here's the teslausb-headless-setup.log output. Let me know if I can provide anything else:

Sat  6 Apr 23:16:33 BST 2019 : Detecting whether to update wpa_supplicant.conf
Sat  6 Apr 23:16:33 BST 2019 : Wifi variables specified, and no /boot/WIFI_ENABLED. Building wpa_supplicant.conf.
Sat  6 Apr 23:16:33 BST 2019 : Rebooting...
Sat  6 Apr 23:16:58 BST 2019 : Detecting whether to update wpa_supplicant.conf
Sat  6 Apr 23:16:58 BST 2019 : Grabbing main setup file.
Sat  6 Apr 23:17:00 BST 2019 : Starting setup.
Sat  6 Apr 23:17:00 BST 2019 : Updating package index files...
Sat 13 Apr 22:39:25 BST 2019 : Verifying that the requested configuration is valid...
Sat 13 Apr 22:39:26 BST 2019 : Downloaded /tmp/verify-configuration.sh ...
Sat 13 Apr 22:39:26 BST 2019 : Verifying that there is sufficient space available on the MicroSD card...
Sat 13 Apr 22:39:26 BST 2019 : There is sufficient space available.
Sat 13 Apr 22:39:35 BST 2019 : Downloading additional setup scripts.
Sat 13 Apr 22:39:35 BST 2019 : Downloaded /tmp/create-backingfiles-partition.sh ...
Sat 13 Apr 22:39:36 BST 2019 : Downloaded /tmp/create-backingfiles.sh ...
Sat 13 Apr 22:39:36 BST 2019 : Downloaded /tmp/make-root-fs-readonly.sh ...
Sat 13 Apr 22:39:37 BST 2019 : Downloaded /root/configure.sh ...
Sat 13 Apr 22:39:37 BST 2019 : Fixing the modules-load parameter in /boot/cmdline.txt...
Sat 13 Apr 22:39:37 BST 2019 : Fixed cmdline.txt.
Sat 13 Apr 22:39:46 BST 2019 : Starting to create backing files partition...
Sat 13 Apr 22:39:46 BST 2019 : Checking existing partitions...
Sat 13 Apr 22:39:46 BST 2019 : Modifying partition table for backing files partition...
Sat 13 Apr 22:39:47 BST 2019 : Modifying partition table for mutable (writable) partition for script usage...
Sat 13 Apr 22:39:47 BST 2019 : Writing updated partitions to fstab and /boot/cmdline.txt
Sat 13 Apr 22:39:47 BST 2019 : Formatting new partitions...
Sat 13 Apr 22:40:24 BST 2019 : Mounting the partition for the backing files...
Sat 13 Apr 22:40:24 BST 2019 : Mounted the partition for the backing files.
Sat 13 Apr 22:40:24 BST 2019 : Creating backing disk files.
Sat 13 Apr 22:40:24 BST 2019 : create-backingfiles: starting
Sat 13 Apr 22:40:24 BST 2019 : create-backingfiles: Allocating 114471676K for /backingfiles/cam_disk.bin...
Sat 13 Apr 22:40:28 BST 2019 : create-backingfiles: Creating filesystem with label 'CAM'
Sat 13 Apr 22:40:30 BST 2019 : create-backingfiles: updated /etc/fstab for /mnt/cam
Sat 13 Apr 22:40:30 BST 2019 : create-backingfiles: created camera backing file
Sat 13 Apr 22:40:34 BST 2019 : create-backingfiles: done
Sat 13 Apr 22:40:43 BST 2019 : Main setup completed.
Sat 13 Apr 22:40:43 BST 2019 : calling configure.sh
Sat 13 Apr 22:40:43 BST 2019 : configure: /root/configure.sh starting with REPO=marcone, BRANCH=main-dev, ARCHIVE_SYSTEM=none, INSTALL_DIR=/root/bin
Sat 13 Apr 22:40:43 BST 2019 : configure: Skipping archive configuration.
Sat 13 Apr 22:40:44 BST 2019 : make-root-fs-readonly: start
Sat 13 Apr 22:40:44 BST 2019 : make-root-fs-readonly: Removing unwanted packages...
Sat 13 Apr 22:41:44 BST 2019 : make-root-fs-readonly: Installing ntp and busybox-syslogd...
Sat 13 Apr 22:42:39 BST 2019 : make-root-fs-readonly: Configuring system...
Sat 13 Apr 22:42:39 BST 2019 : make-root-fs-readonly: Mounting the mutable partition...
Sat 13 Apr 22:42:39 BST 2019 : make-root-fs-readonly: Mounted.
Sat 13 Apr 22:42:39 BST 2019 : make-root-fs-readonly: Moving fake-hwclock data
Sat 13 Apr 22:42:39 BST 2019 : make-root-fs-readonly: done
Sat 13 Apr 22:42:39 BST 2019 : Upgrading installed packages...
Sat 13 Apr 22:46:49 BST 2019 : All done.

[rikbrown]

I'm going to flash it and run the one-step setup again to see if I can reproduce this.

[rikbrown]

I just noticed configure: Skipping archive configuration. in the previous log. Thought I made a typo but think I worked it out.

In your example instructions you give some copy+pasta for setting up the /boot/teslausb_setup_variables.conf. That doesn't include the evidently required export ARCHIVE_SYSTEM=cifs. On my second attempt I copied the sample file and edited it, which did include this.

I think this is the problem? Happy to submit a PR to modify your docs, but maybe you meant to default it if not specified?

[marcone]

Yes, the headless setup scripts have required ARCHIVE_SYSTEM to be set for a while (since November 2018, in the upstream branch), but it looks like the documentation wasn't updated to reflect that. I just updated it.

[travelton]

I know this may sound retarded, but I was having the same issue until I realized there's two USB ports on the Pi. Need to use the data port, not the power only port. DOH!

[mattster98]

Worth pointing out, but yes I've confirmed I'm in the USB port. :)

On Thu, Apr 25, 2019, 6:41 PM Travis Swientek notifications@github.com wrote:

I know this may sound retarded, but I was having the same issue until I realized there's two USB ports on the Pi. Need to use the data port, not the power only port. DOH!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/8#issuecomment-486863349, or mute the thread https://github.com/notifications/unsubscribe-auth/AALGX4RSQGF4X75I4NRY2TLPSIXS3ANCNFSM4HEAAG7A .

[cleanev]

I have been trying to get the car to see this and am completely unsuccessful. I posted in another thread here - https://github.com/marcone/teslausb/issues/9#issuecomment-487080919

[cleanev]

@marcone - setting up multiple (4) RPi’s I came across yet another issue wherein I had to add cifs_archive=2.0 as by default it uses 3.0. I tried 2.1 and my CIFS share did not mount, 2.0 was the setting that helped me get past the drive mapping.

[marcone]

You're the 2nd or 3rd person that mentions having to tweak the CIFS version. Might be worthwhile to have it try all the possible versions automatically. I'm certainly open to accepting a PR for that.

[bbartizek]

I have been trying to get the car to see this and am completely unsuccessful. I posted in another thread here - #9 (comment)

I'm having this same problem. Plugged into my PC, RPi boots normally, CAM partition shows as a USB storage drive, etc. Plugged into a raw power-only USB, RPi boots normally and enters the archive loop (consistent LED flashes). Plugged into the front ports on my dash, and it powers on, lots of LED activity, but never settles into the archive loop, and never enables the dashcam on the car.

[marcone]

@bbartizek while it's in that state (the "never settles into the archive loop" state), ssh into the pi and grab /mutable/archiveloop.log and the output of dmesg.

[bbartizek]

I fully read through the other thread, and tried the dual power source suggestion. I have the same USB-A addon board, which used to work fine in the past, but I plugged a battery into the power micro-USB on the RPi, and got it to actually boot and show the dashcam. Once it was booted, removing the secondary power had no effect and it stayed working. I then tried it with the power port plugged into the splitter I have for my Nomad charger, and it successfully booted the RPi and entered the archive loop, but never started the dashcam in the car, so presumably something went wrong with the filesystem and it didn't correct itself.

So the root cause of the RPi never booting properly does seem to be that the power is, for some reason, insufficient/inconsistent/etc. when only connecting the data port to the car.

I'm not sure why the dashcam stopped working though.

current dmesg output is just this, over and over:

[ 481.278655] dwc2 20980000.usb: new device is high-speed [ 481.452780] dwc2 20980000.usb: new device is high-speed [ 481.928522] dwc2 20980000.usb: new device is high-speed [ 481.950513] dwc2 20980000.usb: new device is high-speed

Edit: Timestamps in archiveloop.log are way off, but last output is:

Thu  3 Nov 17:17:05 GMT 2016: Starting...
Thu  3 Nov 17:17:06 GMT 2016: Archiving...
Thu  3 Nov 17:17:06 GMT 2016: Disconnecting usb from host...
Thu  3 Nov 17:17:06 GMT 2016: Disconnected usb from host.
Thu  3 Nov 17:17:06 GMT 2016: Ensuring cam archive is mounted...
Thu  3 Nov 17:17:06 GMT 2016: /mnt/archive is already mounted.
Thu  3 Nov 17:17:06 GMT 2016: Ensured cam archive is mounted.
Thu  3 Nov 17:17:06 GMT 2016: Starting...
Thu  3 Nov 17:17:06 GMT 2016: Ensuring cam file is mounted...
Thu  3 Nov 17:17:07 GMT 2016: Mounting /mnt/cam...
Thu  3 Nov 17:17:07 GMT 2016: Mounted /mnt/cam.
Thu  3 Nov 17:17:07 GMT 2016: Ensured cam file is mounted.
Thu  3 Nov 17:17:07 GMT 2016: Running fsck on /mnt/cam...
fsck from util-linux 2.29.2
fsck.fat 4.1 (2017-01-24)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.
Performing changes.
/dev/loop0: 12 files, 29/1755167 clusters
Thu  3 Nov 17:17:09 GMT 2016: Finished fsck on /mnt/cam.
Thu  3 Nov 17:17:10 GMT 2016: Moving clips to archive...
Thu  3 Nov 17:17:10 GMT 2016: Creating output directory ''
Thu  3 Nov 17:17:10 GMT 2016: /mnt/cam/TeslaCam/SavedClips does not exist, skipping
Thu  3 Nov 17:17:10 GMT 2016: Moved 0 file(s), failed to copy 0, deleted 0.
Thu  3 Nov 17:17:10 GMT 2016: Finished moving clips to archive.
Thu  3 Nov 17:17:10 GMT 2016: Unmounting /mnt/cam...
Thu  3 Nov 17:17:10 GMT 2016: Unmounted /mnt/cam.
Thu  3 Nov 17:17:10 GMT 2016: Finished archiving.
Thu  3 Nov 17:17:10 GMT 2016: No music archive configured
Thu  3 Nov 17:17:10 GMT 2016: Connecting usb to host...
Thu  3 Nov 17:17:10 GMT 2016: Connected usb to host.
Thu  3 Nov 17:17:10 GMT 2016: Waiting for archive to be unreachable...

Edit 2: So it occurs to me from more closely reading the loop output, that the RPi might be unmounting the CAM partition when in range of the WiFi containing the archive system, which would explain why the dashcam isn't working if that's the case...

[marcone]

The rpi unpublishes the cam drive when it transitions from "not connected to wi-fi" to "connected to wi-fi". It then backs up whatever needs backing up, and published the cam drive again, while still connected to wi-fi. The snippet of archiveloop.log you included shows it publishing the cam drive and then waiting to become disconnected from wi-fi again, so that looks OK.

Your dmesg on the other hand doesn't look right at all. It should print a few messages when connected, not the same thing over and over like yours does.

On my car it works with a single USB cable (or at least it did last time I tried a few weeks ago, I normally have it on permanent power pulled from the OBD2 port), so it seems like this is car-specific, with some cars not providing enough power to the USB ports for the rpi to run reliably.

[bbartizek]

I was hoping that when I left the house, it would lose WiFi, remount cam, and things would work properly, but no such luck. It did revert back to the repeating single blink loop, but the dashcam in the car never activated. Not exactly sure how to troubleshoot from here since I can't connect to the RPi if it's out of WiFi range, lol.

[marcone]

If you leave the drives mounted, then both the Pi and the Tesla will be accessing the filesystem at the same time, which is likely going to confuse one or both, and/or lead to filesystem corruption.

[marcone]

What you probably want to do instead is, once the pi is plugged into the car, booted up, and you're ssh'd into the pi, run modprobe -r g_mass_storage (this is equivalent to unplugging the drive from the car), followed by modprobe g_mass_storage (equivalent to plugging it in to the car), then check the output of dmesg.

[wnichols85]

I'm getting the following in dmesg

[ 34.682879] CIFS VFS: Error -104 sending data on socket to server [ 34.682945] CIFS VFS: cifs_mount failed w/return code = -104 [ 35.613853] CIFS VFS: cifs_mount failed w/return code = -112 [ 35.844321] random: crng init done [ 35.844346] random: 7 urandom warning(s) missed due to ratelimiting [ 42.158478] Mass Storage Function, version: 2009/09/11 [ 42.158500] LUN: removable file: (no medium) [ 42.158662] LUN: removable file: /backingfiles/music_disk.bin [ 42.158774] LUN: removable file: /backingfiles/cam_disk.bin [ 42.158783] Number of LUNs=2 [ 42.167177] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 [ 42.167195] g_mass_storage gadget: g_mass_storage ready [ 42.167210] dwc2 20980000.usb: bound driver g_mass_storage [ 42.868862] CIFS VFS: error -9 on ioctl to get interface list [ 43.207047] CIFS VFS: error -9 on ioctl to get interface list [ 51.830123] Mass Storage Function, version: 2009/09/11 [ 51.830142] LUN: removable file: (no medium) [ 51.830302] LUN: removable file: /backingfiles/music_disk.bin [ 51.830399] LUN: removable file: /backingfiles/cam_disk.bin [ 51.830409] Number of LUNs=2 [ 51.830744] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11 [ 51.830757] g_mass_storage gadget: g_mass_storage ready [ 51.830772] dwc2 20980000.usb: bound driver g_mass_storage

If I have sentry mode on will I see a camera icon on the screen? Will having my phone key near by interfere with testing recordings by walking around the car?

[marcone]

Here's what I see after modprobe -r g_mass_storage followed by modprobe g_mass_storage:

[519360.546295] Mass Storage Function, version: 2009/09/11
[519360.546322] LUN: removable file: (no medium)
[519360.546547] LUN: removable file: /backingfiles/music_disk.bin
[519360.546686] LUN: removable file: /backingfiles/cam_disk.bin
[519360.546701] Number of LUNs=2
[519360.547163] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11
[519360.547181] g_mass_storage gadget: g_mass_storage ready
[519360.547201] dwc2 20980000.usb: bound driver g_mass_storage
[519360.556099] dwc2 20980000.usb: new device is full-speed

this is with the car having been sitting in the garage without me using it for a while. The car's USB ports are disabled/unpowered at this point, but the pi is on because it has permanent power. When I remotely turn on sentry mode, the car's usb ports become enabled, which results in these additional lines in dmesg:

[519587.481622] dwc2 20980000.usb: new device is high-speed
[519587.637275] dwc2 20980000.usb: new device is high-speed
[519587.734891] dwc2 20980000.usb: new address 9
[519587.750439] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage

If you don't see those lines in dmesgs, then the pi and the car are not seeing each other. Check that you're using the correct port in the pi, and that you don't have a power-only USB cable.

[wnichols85]

Turns out I had a charge only USB cable (used one that I found). Switch the cable to one that I know works and we are in business. Thanks!

[mattster98]

I just got updated to 2019.12.1.1 (MX) and everything is back to normal. Single cable on the USB port and boots and starts recording.

Will update later after it's seen power cycles and saved recordings.

On Sun, Apr 28, 2019, 7:50 PM wnichols85 notifications@github.com wrote:

Turns out I had a charge only USB cable (used one that I found). Switch the cable to one that I know works and we are in business. Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/8#issuecomment-487425811, or mute the thread https://github.com/notifications/unsubscribe-auth/AALGX4QCKL5U2J34VKOHMNLPSYZ3BANCNFSM4HEAAG7A .

[mattster98]

Quick drive this morning and it booted up fine and connected before I backed out. Saved a recording along the way and it was archiving when I got out of the car back at home. Looks like I'm back in business.

On Mon, Apr 29, 2019, 6:41 PM Matt Smith matt@mattsmith.net wrote:

I just got updated to 2019.12.1.1 (MX) and everything is back to normal. Single cable on the USB port and boots and starts recording.

Will update later after it's seen power cycles and saved recordings.

On Sun, Apr 28, 2019, 7:50 PM wnichols85 notifications@github.com wrote:

Turns out I had a charge only USB cable (used one that I found). Switch the cable to one that I know works and we are in business. Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/8#issuecomment-487425811, or mute the thread https://github.com/notifications/unsubscribe-auth/AALGX4QCKL5U2J34VKOHMNLPSYZ3BANCNFSM4HEAAG7A .

[bbartizek]

So I managed to fix the issue I was having previously where the RPi itself would seem to be working, but the car couldn't see it. In the other thread I read, the ports on the RPi board were described as:

the first one ("USB") goes to the USB port in the car, the second port on the board ("PWR IN")

This seemed pretty straightforward, so I didn't spend more than half a second thinking about it. Turns out, that was a mistake. I have a USB-A connector addon board for my RPi, so the "first" port is clearly the one next to the USB-A connector, right? Not the case. The inboard port, which I had assumed was the "second" port, is actually the data port, and the outboard port is power only. (I can't actually see the markings on the board with the addon board attached) So what was happening with my RPi, is that it was connected on the data port to both the front USB of the car, and the USB port on my splitter, which seems to confuse the hell out of everything, and make it not visible to the car. Once I switched my secondary power to the outboard port, the car saw the drive almost immediately and the dashcam is working again. User error ftw.

[cleanev]

Got 12.1.1 on Model 3. Didn’t change a thing from the original build using RPiZeroW. Simply plugged in and viola, got the camera icon on the screen. Seems it was something with the software release of the past that made us all go crazy with this cable swapping rebuilding. Finally it is working and hope that Tesla doesn’t break it again

[kewvention]

so i did manage to install it successfully, but whenever i plug the rpi zerow into the car, i see the quick 1 second blinks, but the dashcam icon never comes. i plugged the usb cable into the port labeled USB on the pi and the left port in the car. the cable itself, if i connect it to the pc, i see the boot partition as well. so im kind of lost.

[marcone]

When you said "the cable itself, if i connect it to the pc, i see the boot partition as well", did you mean "the card itself ..." ? Because you definitely should not be seeing the boot partition when the card is plugged in to the pi, and the pi is plugged in to the PC.

[kewvention]

When you said "the cable itself, if i connect it to the pc, i see the boot partition as well", did you mean "the card itself ..." ? Because you definitely should not be seeing the boot partition when the card is plugged in to the pi, and the pi is plugged in to the PC.

sorry yes. i meant that i see the boot partition when using a microsd card adapter .however, if i plug the pi into the pc and sdcard into the pi, i dont see any partition.this should be correct right.

[marcone]

If you plug the pi into the PC and let it boot up, the PC should see the cam and music drives, just like the car would. Should take under a minute for those to show up after plugging in the pi. If you're not seeing those drives appear on the PC, ssh into the pi and look at the various logs: /boot/teslausb-headless-setup.log, /mutable/archiveloop.log, the output of dmesg