**** BEGIN LOGGING AT Tue Dec 01 03:00:02 2020
Dec 01 03:07:52 <GenTooMan> hmm still working with your limits I mean limit switches?
Dec 01 03:18:44 <GenTooMan> set_ https://youtu.be/FJZa5K6Dk48
Dec 01 03:23:15 <set_> Yes.
Dec 01 03:23:25 <set_> I cannot find out how to implement them yet.
Dec 01 03:26:14 <set_> The person could have purchased a better blade. Sheesh.
Dec 01 03:31:46 <set_> poor carrot
Dec 01 03:35:23 <set_> GenTooMan: Did you ever see my last post to you about that one servo motor from Teknic?
Dec 01 03:35:44 <MattB000000ne> GenTooMan: how is he supposed to afford that
Dec 01 03:36:09 <MattB000000ne> opps that was tjust the commerical
Dec 01 03:36:42 <set_> Ha.
Dec 01 03:37:49 <set_> for instance, w/ Adafruit-BBIO, would I just use the debounce feature and Rising or Falling of a GPIO to record the hitting of my stopper?
Dec 01 03:38:59 <set_> So, I could have a "killswitch," the Rising/Falling aspect to the source, and the endstop?
Dec 01 04:49:23 <MattB000000ne> zmatt: I ran the thing
Dec 01 04:49:27 <MattB000000ne> not sure what it means though
Dec 01 04:49:44 <MattB000000ne> https://pastebin.com/Xz0PbgX8
Dec 01 04:51:19 <MattB000000ne> my show pins in case you were wondering https://pastebin.com/j5j0peg0
Dec 01 05:05:41 <zmatt> MattB000000ne: no evidence of your LCD, HDMI only
Dec 01 05:05:58 <zmatt> so that almost certainly means the DT declaration is wrong
Dec 01 05:06:26 <MattB000000ne> hmm
Dec 01 05:06:33 <MattB000000ne> ok
Dec 01 05:07:30 <MattB000000ne> would that be at the bootloader level before handoff to the kernal right
Dec 01 05:07:36 <MattB000000ne> something wrong at that stage
Dec 01 05:07:44 <zmatt> as in, something wrong in the overlay
Dec 01 05:07:48 <MattB000000ne> yup
Dec 01 05:07:59 <zmatt> u-boot merely applies the overlay, it doesn't care about it content
Dec 01 05:08:01 <zmatt> *its
Dec 01 05:08:33 <MattB000000ne> so no error checking and what not
Dec 01 05:08:46 <zmatt> so this isn't "at the bootloader level", this is between what your DT sources declares and how the kernel interprets it (or fails to)
Dec 01 05:08:57 <zmatt> overlay sources in this case
Dec 01 05:09:17 <MattB000000ne> so the fact that it accepted the pins is irrelevant
Dec 01 05:09:26 <zmatt> overlays have even less error-checking than the main DT, but in either case most of the checking is purely syntactic, not semantic
Dec 01 05:09:51 <zmatt> what does the source code of this overlay look like?
Dec 01 05:10:19 <zmatt> and what's the "sudo show-pins | sort" output ?
Dec 01 05:13:06 <MattB000000ne> https://pastebin.com/ZJbfR3nm
Dec 01 05:13:42 <zmatt> oh gross
Dec 01 05:14:04 <MattB000000ne> https://pastebin.com/VHUbFize
Dec 01 05:14:06 <MattB000000ne> lol
Dec 01 05:14:28 <zmatt> yeah, since the pinmux isn't attached to the device it belongs to, it will be set unconditionally and will not at all be indicative of the device being probed successfully
Dec 01 05:14:32 <MattB000000ne> zmatt you need to do a comic strip or something
Dec 01 05:14:36 <MattB000000ne> laughing my ass over here
Dec 01 05:14:44 <MattB000000ne> i have this mental picture of you saying that
Dec 01 05:14:47 <MattB000000ne> too funny
Dec 01 05:15:17 <MattB000000ne> like the dilbert but more embedded focused
Dec 01 05:16:00 <zmatt> uhh
Dec 01 05:16:20 <MattB000000ne> you ever read dilbert
Dec 01 05:16:21 <zmatt> either your overlay hasn't been applied, or something is completely broken
Dec 01 05:16:29 <zmatt> oh never mind
Dec 01 05:16:33 <zmatt> i'm blind, sorry
Dec 01 05:16:37 <MattB000000ne> let me check my uEnv.txt
Dec 01 05:17:13 <zmatt> no, the problem is that because P9 is on the left, I'm used to sorting P9 before P8 ... of course the "sort" utility does not give a fuck about my non-alphabetical preferences
Dec 01 05:18:06 <zmatt> so I just misread it
Dec 01 05:18:38 <MattB000000ne> your earlier statement about pinmux not tied to a device
Dec 01 05:18:40 <MattB000000ne> is that still true
Dec 01 05:18:57 <zmatt> yes
Dec 01 05:19:13 <zmatt> all you're doing is changing the default pinmux for cape-universal for those pins
Dec 01 05:19:35 <zmatt> disembodied from any device
Dec 01 05:19:59 <zmatt> (this may cause various problems, especially for i2c devices)
Dec 01 05:20:22 <MattB000000ne> so my uEnv.txt the eeprom tries to load the non BBAI overlay
Dec 01 05:20:33 <MattB000000ne> so I disable auto loading on all slots
Dec 01 05:20:46 <MattB000000ne> and then add the overlay I shared in the custom cape slot
Dec 01 05:20:50 <zmatt> the eeprom tries nothing, it just specifies the name of the cape
Dec 01 05:21:29 <MattB000000ne> some how it keys in on a different overlay file which I have to block
Dec 01 05:21:32 <zmatt> u-boot then loads the overlay based on name from /lib/firmware (unless that's been changed in the bbai u-boot)
Dec 01 05:23:01 <MattB000000ne> ok but my problem is the kernal doesn't think I have a cape
Dec 01 05:23:06 <zmatt> it would be nice if u-boot first tried to load a bbai-specific version of the overlay (e.g. in a different dir or with a name prefix)
Dec 01 05:23:17 <zmatt> (maybe it does, no idea)
Dec 01 05:23:39 <MattB000000ne> would there be any benefit to me just putting my BBAI code under the overlay it does try and load
Dec 01 05:23:48 <zmatt> no
Dec 01 05:24:15 <zmatt> I'm just musing about what's needed for plug&play operation (in addition to having a working overlay in the first place)
Dec 01 05:30:14 <zmatt> hmmm
Dec 01 05:30:32 <MattB000000ne> i got this line early in the kernel
Dec 01 05:30:33 <MattB000000ne> Hit pending asynchronous external abort (FSR=0x00001406) during first unmask, this is most likely caused by a firmware/bootloader bug.
Dec 01 05:30:53 <MattB000000ne> so maybe just a overlay bug
Dec 01 05:30:57 <MattB000000ne> or error
Dec 01 05:31:53 <zmatt> can you pastebin your kernel log?  (dmesg | pastebinit)
Dec 01 05:36:34 <MattB000000ne> https://pastebin.com/C4GwafFM
Dec 01 05:37:20 <zmatt> that's certainly not good, but it's not likely to be relevant here
Dec 01 05:38:56 <zmatt> it also means the error from omap_l3_noc at lines 96-147 is caused by the same thing (reported as soon as omap_l3_noc loads) and can be ignored
Dec 01 05:43:17 <zmatt> yeah, not sure what's going on... it's not giving any errors yet doesn't seem to recognize the device at all... and so far I'm not seeing anything obviously wrong with the dts
Dec 01 05:43:54 <zmatt> can you pastebin:  ls -l /sys/bus/platform/devices/
Dec 01 05:44:30 <zmatt> and assuming it exists,  ls -l /sys/bus/platform/devices/display/
Dec 01 05:44:54 <MattB000000ne> https://pastebin.com/1uPyQNTb
Dec 01 05:45:22 <MattB000000ne> display doesnt exist
Dec 01 05:52:03 <zmatt> I'm suspicious of this "qiaodian,qd43003c0-40" compatible-string
Dec 01 05:53:17 <zmatt> and of "panel-dpi" for that matter
Dec 01 05:53:48 <MattB000000ne> i could try cutting parts out to see if it works
Dec 01 05:53:55 <MattB000000ne> that is my go to debug technique
Dec 01 05:54:04 <zmatt> which is complete nonsense in this case
Dec 01 05:54:13 <zmatt> if wrong, it needs to be corrected
Dec 01 05:54:27 <zmatt> removing the compatible-string will 100% guarantee it will never work
Dec 01 05:54:41 <MattB000000ne> this would be all u-boot script?
Dec 01 05:54:58 <zmatt> u-boot is completely irrelevant here
Dec 01 05:55:12 <zmatt> at no point has u-boot been relevant during this entire discussion
Dec 01 05:55:23 <MattB000000ne> so the kernal is parsing this
Dec 01 05:56:12 <MattB000000ne> i guess what I am asking is how would one track down whether  "qiaodian,qd43003c0-40" is correct
Dec 01 05:56:15 <zmatt> the compatible-string of a device node declares what type of device it is, and consequently what driver should be used for it
Dec 01 05:56:38 <zmatt> it can optionally provide multiple options, with the first one that matches a driver being used
Dec 01 05:58:43 <zmatt> "qiaodian,qd43003c0-40" is a specific lcd panel and matches the "panel-simple" driver (drivers/gpu/drm/panel/panel-simple.c)
Dec 01 05:59:53 <zmatt> this driver looks like the wrong one to use, it hardcodes display geometry and timing instead of extracting it from DT (which seems like a terrible practice which is why I really hope this driver is deprecated)
Dec 01 06:00:45 <zmatt> and the information hardcoded for "qiaodian,qd43003c0-40" is also wrong for this display, assuming the information in the overlay is correct
Dec 01 06:03:10 <MattB000000ne> right from the github
Dec 01 06:03:20 <MattB000000ne> https://github.com/lorforlinux/BeagleBoard-DeviceTrees/blob/compatibility_Update3/src/arm/overlays/BBAI-4D4C-00A1.dts
Dec 01 06:04:50 <MattB000000ne> what do you mean the info for the display is incorrect
Dec 01 06:07:17 <MattB000000ne> ok maybe if I update the driver for the panel
Dec 01 06:07:29 <MattB000000ne> to right size
Dec 01 06:07:31 <zmatt> "driver for the panel" ? what are you talking about?
Dec 01 06:07:51 <zmatt> so far I'm not seeing any indication it loads any driver for this panel
Dec 01 06:07:59 <MattB000000ne> the reference to the specific panel
Dec 01 06:08:08 <MattB000000ne> so there is a mismatch
Dec 01 06:12:06 <MattB000000ne> maybe I  can swap in compatible = "ti,tilcdc,panel";
Dec 01 06:12:13 <zmatt> no
Dec 01 06:14:18 <zmatt> ok wtf
Dec 01 06:14:37 <MattB000000ne> what
Dec 01 06:15:03 <zmatt> drivers/gpu/drm/omapdrm/displays/panel-dpi.c exists in mainline kernel v4.19.94: https://elixir.bootlin.com/linux/v4.19.94/source/drivers/gpu/drm/omapdrm/displays
Dec 01 06:15:17 <zmatt> yet not in 4.19.94-ti-r57: https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.19.94-ti-r57/drivers/gpu/drm/omapdrm/displays
Dec 01 06:16:16 <MattB000000ne> so it wasnt filtered down
Dec 01 06:16:24 <MattB000000ne> for the ti fork
Dec 01 06:16:33 <zmatt> ah, I see... https://github.com/RobertCNelson/linux-stable-rcn-ee/commit/dfe07442c54d35fd6af0bcdbefd7b0d78ae89c03
Dec 01 06:19:53 <MattB000000ne> i googled drm_panel infrastructure but lost
Dec 01 06:21:19 <zmatt> like.. okay, cool, so what's the actual replacement of "panel-dpi" ?
Dec 01 06:23:00 <zmatt> what the actual fuck
Dec 01 06:23:14 <zmatt> are these people serious
Dec 01 06:25:02 <zmatt> there isn't a replacement, that's what seems to be the actual situation
Dec 01 06:26:57 <MattB000000ne> well that is great
Dec 01 06:27:02 <MattB000000ne> someone just forgot
Dec 01 06:27:24 <zmatt> the replacement is adding the panel to the simple-panel driver
Dec 01 06:27:31 <zmatt> and recompiling the kernel
Dec 01 06:28:31 <MattB000000ne> well that sure as hell not happening today
Dec 01 06:28:35 <MattB000000ne> recompile the kernel
Dec 01 06:28:42 <MattB000000ne> ..............
Dec 01 06:28:51 <zmatt> I wonder if the commit removing panel-dpi can be reverted
Dec 01 06:29:12 <MattB000000ne> could I go back to 4.14
Dec 01 06:29:15 <MattB000000ne> and get it
Dec 01 06:29:30 <MattB000000ne> maybe if I just downgrade
Dec 01 06:31:09 <zmatt> discussion thread about extending panel-simple to actually replace panel-dpi: https://patchwork.kernel.org/project/dri-devel/patch/20190307101030.3822-1-maxime.ripard@bootlin.com/
Dec 01 06:33:56 <zmatt> the removal commit seems to cleanly revert... lemme see if the resulting kernel still compiles
Dec 01 06:34:48 <MattB000000ne> ok
Dec 01 06:44:50 <zmatt> hmm, adding panel-dpi support to panel-simple may be a better strat, since that's what mainline seems to have done
Dec 01 06:48:18 <MattB000000ne> what does that entail
Dec 01 06:49:03 <zmatt> probably just cherry-picking the commit and recompiling.  but I'll wait for this build to finish first so you can try it
Dec 01 06:49:24 <zmatt> once we've determined which of these solutions works I'll mail rcn
Dec 01 06:50:42 <MattB000000ne> ok
Dec 01 06:51:38 <zmatt> jeez, building this kernel takes ages.. I'm not used to it taking this long, I guess it's because my own kernel config is pretty stripped-down while this one includes everything and the kitchen sink
Dec 01 06:52:21 <zmatt> fortunately the second one should be pretty quick
Dec 01 06:54:10 <MattB000000ne> do you get a performance bump by having a lean kernel
Dec 01 06:54:31 <zmatt> it saves disk space and reduces boot time
Dec 01 06:54:46 <zmatt> and it speeds up compiling the kernel obviously
Dec 01 06:55:29 <zmatt> in some rare cases the kernel itself might be faster if you specialize the kernel to your target
Dec 01 06:55:48 <zmatt> e.g. a generic kernel may include performance-impacting workarounds for issues that do not apply to your specific target
Dec 01 06:56:29 <zmatt> and some features may increase the size of data structures, increasing memory usage and reducing cache locality
Dec 01 06:57:02 <zmatt> there are also diffuse performance impacts from using an SMP kernel (i.e. one for multi-core processors) on a single-core system
Dec 01 07:10:16 <zmatt> finally
Dec 01 07:10:56 <MattB000000ne> works?
Dec 01 07:11:13 <MattB000000ne> or functional?
Dec 01 07:13:25 <zmatt> finally compile is done :P  I'll msg you the link
Dec 01 07:13:38 <MattB000000ne> ok
Dec 01 07:14:21 <zmatt> so this is with the old panel-dpi driver (i.e. with the removal reverted)
Dec 01 07:14:47 <MattB000000ne> ok
Dec 01 07:14:50 <MattB000000ne> got it
Dec 01 07:14:54 <zmatt> btw I suggest just using compatible = "panel-dpi";  unless/until you know the exact correct compatible-string for this specific lcd panel
Dec 01 07:16:04 <MattB000000ne> which i dont so I will just use that in the overlay
Dec 01 07:16:07 <MattB000000ne> and hope for the best
Dec 01 07:33:46 <MattB000000ne> was updating the overlay file
Dec 01 07:34:12 <MattB000000ne> I do get this warning https://pastebin.com/mJwwp10D
Dec 01 07:34:17 <MattB000000ne> i always got it
Dec 01 07:34:24 <MattB000000ne> just remembered since it flagged again
Dec 01 07:35:04 <zmatt> that's actually a good point
Dec 01 07:40:09 <zmatt> MattB000000ne: I _think_ it should be either of these: https://pastebin.com/p56rvA21
Dec 01 07:40:22 <zmatt> the top one seems safer
Dec 01 07:40:45 <zmatt> (it differs from what you have only by having port@0 { .. };  instead of port { ... }; )
Dec 01 07:41:32 <MattB000000ne> ok
Dec 01 07:48:37 <zmatt> argh I did something stupid so this compile is going to take just as long as the first
Dec 01 07:50:45 <MattB000000ne> if I were going to try and switch to this one I would have to undo the other one ?
Dec 01 07:50:59 <zmatt> ?
Dec 01 07:51:46 <zmatt> btw have you tested the kernel yet?
Dec 01 07:52:02 <zmatt> it should be a matter of install and reboot
Dec 01 07:52:23 <zmatt> sudo dpkg -i FILENAME.deb
Dec 01 07:54:23 <MattB000000ne> yeah I tried not booting trying to undo
Dec 01 07:54:32 <MattB000000ne> i installed the package
Dec 01 07:55:50 <zmatt> not booting?  that's not good
Dec 01 07:56:10 <zmatt> undo should be a matter of modifying uname_r= in /boot/uEnv.txt back to the previous kernel
Dec 01 07:56:25 <zmatt> did you capture any output on the serial console to help debug what's going on?
Dec 01 07:56:49 <MattB000000ne> Yeah I was going to do that but left my cables at the office
Dec 01 07:57:02 <MattB000000ne> will need run and get it
Dec 01 07:57:19 <MattB000000ne> I should have pastebins this afternoon my time
Dec 01 07:57:23 <MattB000000ne> what time zone are you anyway?
Dec 01 07:59:16 <MattB000000ne> I will take a quick nap and then head in to get that debug info. I am curious to know if that simple fix with that compile error does anything
Dec 01 08:00:15 <zmatt> second compile is virtually done
Dec 01 08:00:24 <zmatt> that gives you another kernel to test with
Dec 01 08:01:10 <MattB000000ne> ok yeah let me get that one
Dec 01 08:01:17 <MattB000000ne> and I will test these guys out
Dec 01 08:03:40 <zmatt> ok, sent you the url
Dec 01 08:03:55 <zmatt> after installation you can of course switch between them just by changing uname_r in /boot/uEnv.txt
Dec 01 08:04:27 <MattB000000ne> ok I will try them both once I have the serial and will post output
Dec 01 08:04:30 <MattB000000ne> thanks for doing all this
Dec 01 08:04:42 <MattB000000ne> i absorbed about 3% of what you are saying
Dec 01 08:04:44 <MattB000000ne> but it is something
Dec 01 08:04:45 <MattB000000ne> lol
Dec 01 19:06:59 <MattB0000ne> if I use lsusb and i find the my serial cable is connected to  device 002
Dec 01 19:07:02 <MattB0000ne> ie Bus 001 Device 002
Dec 01 19:07:16 <MattB0000ne> i would want to connect to /dev/ttyUSB1?
Dec 01 19:13:15 <zmatt> those are unrelated and unrelatable identifiers
Dec 01 19:13:46 <zmatt> well, not unrelatable I guess, you can relate them by digging through sysfs
Dec 01 19:14:40 <mru> or with some common udev rules, in /dev/serial/by-path/
Dec 01 19:15:13 <zmatt> certainly, although the path there may still be weird
Dec 01 19:15:47 <mru> yeah, right here right now, ttyUSB0 is pci-0000:43:00.0-usb-0:1.1:1.0-port0
Dec 01 19:16:00 <zmatt> e.g. the /dev/serial/by-path/pci-0000:00:14.0-usb-0:6:1.2 is not something I can guess from "Bus 001 Device 023"
Dec 01 19:16:46 <mru> the part after "usb" contains to the bus/device numbers
Dec 01 19:17:27 <mru> or not
Dec 01 19:17:52 <mru> lsusb -t prints the the numbers used there
Dec 01 19:18:05 <zmatt> nope, it indicates the physical path (i.e. which usb port on each hub on route)
Dec 01 19:18:52 <zmatt> I think bus:port:configuration:interface
Dec 01 19:19:13 <mru> I've never been able to decipher the usb device string
Dec 01 19:20:11 <mru> but yes, there are numbers relating to physical topology as well as a dynamically assigned "device number"
Dec 01 19:21:13 <zmatt> that is in fact what by-path is
Dec 01 19:21:22 <zmatt> i.e. it describes the physical path to the device
Dec 01 19:21:58 <mru> yes, as does lsusb -t
Dec 01 19:22:03 <mru> but without the pci part
Dec 01 19:22:11 <zmatt> correct
Dec 01 19:35:47 <MattB0000ne> https://pastebin.com/t9U3xwyA
Dec 01 19:35:53 <MattB0000ne> that is what the serial was saying
Dec 01 19:36:02 <MattB0000ne> i may not be booting from SD card
Dec 01 19:36:21 <MattB0000ne> and so there is a handoff to the emmc which has nothing
Dec 01 19:37:11 <MattB0000ne> also back to my earlier question is the only way to do it
Dec 01 19:37:24 <MattB0000ne> is to ls on /dev and see what is added when plugged in?
Dec 01 19:37:34 <MattB0000ne> or the noobish way about doing it
Dec 01 19:38:02 <zmatt> the kernel also announces it
Dec 01 19:38:06 <zmatt> Dec 01 20:22:25 chinchilla kernel: usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
Dec 01 19:40:05 <mru> I've made udev ruies matching the serial numbers of my converters, creating symlinks matching the labels I stuck on the cables
Dec 01 19:40:28 <zmatt> and assuming you plug it into the same usb port of your computer each time, the symlink it gets in /dev/serial/by-path/ will be consistent each time
Dec 01 19:40:58 <zmatt> what mru said is indeed the clever solution
Dec 01 19:41:05 <zmatt> but probably overkill in your case
Dec 01 19:41:26 <zmatt> anyway I'm not sure what I'm looking at
Dec 01 19:42:23 <zmatt> other than it's loaded the kernel, initrd, dtb, LCD7 overlay
Dec 01 19:42:30 <zmatt> and started the kernel
Dec 01 19:42:33 <zmatt> and then nothing
Dec 01 19:43:09 <MattB0000ne> right
Dec 01 19:43:13 <MattB0000ne> nothing after that
Dec 01 19:43:15 <MattB0000ne> no lights
Dec 01 19:43:31 <MattB0000ne> also it appears my laptop drops the connections right after announcing
Dec 01 19:43:32 <MattB0000ne> https://pastebin.com/T4JnSHZD
Dec 01 19:43:42 <MattB0000ne> the usb plug in event
Dec 01 19:43:57 <zmatt> uhh you mean the board powers off?
Dec 01 19:44:03 <MattB0000ne> no
Dec 01 19:44:06 <MattB0000ne> just sits there
Dec 01 19:44:36 <MattB0000ne> the power LED is on
Dec 01 19:44:37 <zmatt> I'm confused... the ftdi_sio is your usb serial converter
Dec 01 19:44:52 <zmatt> the beaglebone has no way to make it disconnect from your usb
Dec 01 19:45:06 <MattB0000ne> fan is spinning etc... but no other activity
Dec 01 19:45:11 <MattB0000ne> i guess that is what I am plugging in
Dec 01 19:45:34 <zmatt> oh it looks like something on your system is claiming the ftdi device for itself
Dec 01 19:45:57 <MattB0000ne> on the cable it says EZsync
Dec 01 19:46:00 <zmatt> by a braille display daemon o.O
Dec 01 19:46:09 <zmatt> brltty
Dec 01 19:46:13 <zmatt> [Dec 1 14:42] usb 1-5: usbfs: interface 0 claimed by ftdi_sio while 'brltty' sets config #1
Dec 01 19:46:32 <zmatt> this has nothing to do with the beaglebone
Dec 01 19:46:40 <zmatt> I think
Dec 01 19:46:44 <zmatt> not quite sure how to read this
Dec 01 19:46:54 <zmatt> could also be brltty *tried* to claim it but failed
Dec 01 19:47:45 <zmatt> regardless you're not making any sense, like I said there shouldn't be any way for the beaglebone to disconnect your usb-serial thingy from your computer's usb
Dec 01 19:48:01 <MattB0000ne> it seems to be a long standing problem
Dec 01 19:48:10 <zmatt> of that serial cable?
Dec 01 19:48:12 <MattB0000ne> seeing threads on it from 2008
Dec 01 19:48:41 <MattB0000ne> "The conclusion is that udev rules should be changed. "
Dec 01 19:48:46 <MattB0000ne> i will just go to my windows box
Dec 01 19:48:49 <MattB0000ne> for now
Dec 01 19:48:50 <zmatt> what are you referring to right now?
Dec 01 19:48:52 <MattB0000ne> worry about that later
Dec 01 19:48:54 <zmatt> I'm kinda lost
Dec 01 19:48:58 <MattB0000ne> that was with the serial cable
Dec 01 19:49:01 <MattB0000ne> forget that problem
Dec 01 19:49:28 <MattB0000ne> I liked the ability to do the serial debug on my linux laptop but not a big deal
Dec 01 19:49:47 <MattB0000ne> I am debating reflashing my SD
Dec 01 19:49:54 <MattB0000ne> or is there a way to unbork
Dec 01 19:50:00 <zmatt> just stop/remove brltty .. assuming you're not using any braille terminal
Dec 01 19:50:19 <MattB0000ne> my eyes work
Dec 01 19:50:20 <MattB0000ne> lol
Dec 01 19:50:28 <MattB0000ne> for now
Dec 01 19:50:44 <MattB0000ne> i do where glasses with a heavy prescription though
Dec 01 19:50:45 <zmatt> sudo apt-get purge brltty
Dec 01 19:52:07 <zmatt> anyway, it seems it's failing to boot from sd card and then proceeds to boot from eMMC (and failing in some capacity there as well)
Dec 01 19:52:29 <zmatt> not sure what's going on on the sd card... it clearly loaded /boot/uEnv.txt but that's it
Dec 01 19:52:51 <zmatt> possibly it's unable to load the kernel?
Dec 01 19:53:08 <MattB0000ne> uname-r has to be correct right?
Dec 01 19:53:10 <zmatt> e.g. uname_r set to a kernel that's not actually installed
Dec 01 19:54:03 <MattB0000ne> what folder has all my kernals
Dec 01 19:54:11 <zmatt> if you remove the cape you can probably boot from eMMC
Dec 01 19:54:18 <zmatt> then insert and inspect the sd card
Dec 01 19:54:26 <zmatt> or you can do so in another linux system
Dec 01 19:54:38 <MattB0000ne> yeah i just took the sd card out and looking at the filesystem now
Dec 01 19:55:18 <MattB0000ne> in boot my uboot folder is empty
Dec 01 19:56:10 <zmatt> that dir is unused
Dec 01 19:56:13 <zmatt> the kernels are all in /boot/
Dec 01 19:57:21 <MattB0000ne> ok maybe this is the reason
Dec 01 19:57:55 <MattB0000ne> 4.19.94-ti-r57 is what I have that boots but the one i get after your kernal has r45
Dec 01 19:58:16 <MattB0000ne> not sure how much that r45 vs r57 matters
Dec 01 19:59:17 <zmatt> what matters is that if you have kernels 4.19.94-ti-r57 and 4.19.94-ti-r45+dpi installed, then you cannot boot kernel 4.19.94-ti-r45 (which is what you set as uname_r) since it isn't on your system
Dec 01 19:59:50 <zmatt> the only reason mine is r45 is because I'd been too lazy to pull the latest version :P
Dec 01 19:59:59 <MattB0000ne> so I just need to install the r45 version of the kernal then I can switch to that uname-r
Dec 01 20:00:08 <zmatt> or just fix uname_r in /boot/uEnv.txt
Dec 01 20:00:17 <zmatt> which is a lot saner
Dec 01 20:00:51 <zmatt> set it to something that actually exists on your system, e.g. 4.19.94-ti-r57
Dec 01 20:01:39 <MattB0000ne> yeah i did that it boots
Dec 01 20:01:49 <MattB0000ne> but I want the  4.19.94-ti-r45+dpi
Dec 01 20:01:53 <MattB0000ne> for the panel update
Dec 01 20:01:55 <zmatt> so configure that
Dec 01 20:03:02 <zmatt> when you change uname_r manually just make sure that _exist_ kernel is actually installed (e.g. by inspecting /boot/)
Dec 01 20:03:10 <zmatt> that _exact_ kernel
Dec 01 20:03:32 <MattB0000ne> uname_r=4.19.94-ti-r45+dpi hangs me up
Dec 01 20:03:46 <MattB0000ne> stuck at starting kernel
Dec 01 20:03:57 <zmatt> with or without cape?
Dec 01 20:04:39 <MattB0000ne>  without
Dec 01 20:04:43 <MattB0000ne> just a bare bbai
Dec 01 20:04:50 <zmatt> hmm, fascinating
Dec 01 20:05:17 <zmatt> try removing "quiet" from the cmdline= option
Dec 01 20:06:05 <zmatt> I'll build a ti-r57 kernel with the patch just in case it matters
Dec 01 20:06:13 <MattB0000ne> ok
Dec 01 20:07:44 <zmatt> oh it probably matters
Dec 01 20:08:16 <zmatt> I don't think the r45 kernel supports overlays
Dec 01 20:12:27 <zmatt> I'll let you know when it's done building
Dec 01 22:56:48 <mattB000ne> got droppped
Dec 01 22:56:52 <mattB000ne> but i am back
Dec 01 23:52:23 <mattB000ne> zmatt: did that thing compile?
Dec 01 23:54:09 <zmatt> sorry, got distracted.. yes it compiled, hold on
Dec 02 00:00:13 <mattB000ne> thanks
Dec 02 00:31:04 <mattB000ne> ok could be some progress getting
Dec 02 00:31:08 <mattB000ne> some different errors
Dec 02 00:31:12 <mattB000ne> both kernels boot
Dec 02 00:32:07 <mattB000ne> though I cannot ssh in anymore
Dec 02 00:32:22 <mattB000ne> on the first one
Dec 02 00:32:45 <mattB000ne> 2nd boots and works normally
Dec 02 00:43:36 <mattB000ne> got some interesting error messages
Dec 02 00:43:45 <mattB000ne> not sure anyof it helps
**** ENDING LOGGING AT Wed Dec 02 02:59:57 2020