03:28 <Guest95> Hello I was looking at page 61 of the BB-X15 and I have soldered in the boot headers, can anyone please tell me which are exactly the resisters that need to be removed

04:27 <mranostaj> rcn-ee: so adding adafruit_bbio to the pip3 install packages results in this https://gist.github.com/mranostay/e3b36b351c9f32551c5d45815db7e134

04:39 <rcn-ee> @mranostaj, add build-essentials... ps, @drewfustini is done with that library, go for "blinka" https://github.com/RobertCNelson/omap-image-builder/blob/master/configs/bb.org-debian-bullseye-iot-generic-armhf.conf#L126

04:39 <rcn-ee> Adafruit-Blinka

04:41 <rcn-ee> @mranostaj, i think there is also a bug in the pip install, i install that library thru git/python3 installl.. https://github.com/RobertCNelson/omap-image-builder/blob/master/target/chroot/beagleboard.org-buster.sh#L164-L177

04:56 <mranostaj> ah okay

04:56 <mranostaj> rcn-ee: do notice cannot access i2c0 with that library.. i know it is for the headers on board but anyway to work around that without hacking the package?

07:25 <Romi> I've been having issues using can0 on a beaglebone black. I've tried with multiple transievers, however whenever I try to recieve all I get are errors and candump does not show anything. Is there any steps I can take to troubleshoot this issue?

07:26 <Romi> *Are there

07:27 <zmatt> mranostaj: there's nothing on i2c0 to access: all devices on that bus have kernel drivers hence are not directly accessible from userspace without using force

07:30 <zmatt> Romi: did you configure the pins (P9.19+20) to can function? beware that those pins are configured as i2c by default and are used to probe for CAPEs at boot, so if you use those pins you'll at least end up with some garbage on your bus every time you boot

07:30 <zmatt> use can1 on P9.24+26 to avoid that problem

07:33 <zmatt> actually, more problematically P9.19 is i2c scl and can rx, so you'd end up with a drive conflict between the am335x and the can transceiver while the i2c interface is being accessed during boot, so if you do want to use can0 be sure to put a resistor between P9.19 and the CAN transceiver to protect both sides from damage (or, if the CAN transceiver has a sleep mode that makes the can rx pin ...

07:33 <zmatt> ...high-impedance, make sure that mode is engaged by default)

07:36 <Romi> Right now I added the BB-CAN0-00A0.dtbo overlay in uEnv.txt, even without the resistor, it should still be able to recieve / transmit, right?

07:37 <zmatt> assuming neither side has been damaged yet

07:37 <Romi> true, i've tried with other trancievers, but not with other bb

07:37 <Romi> i'll try using can1 then

07:38 <zmatt> and the can interface has been configured correctly (for which I don't really know the details)

07:56 <Romi> so uh, i'm still not recieving anything

07:56 <Romi> I'm using a tcan332 chip as a transciever if that helps

07:57 <Romi> (i'm trying with can1 now)

07:57 <zmatt> unfortunately I don't know much about CAN, I've used it only once and that was a looooong time ago

07:57 <zmatt> I do remember it being.... fiddly

07:57 <Romi> yeah, i've been going at it for two days by now

07:57 <Romi> it's uh

07:57 <zmatt> but I did get it to work

07:58 <Romi> I keep getting "can state ERROR-PASSIVE"

07:58 <Romi> on the ip -details -statistics command

07:58 <Romi> no clue how to check what caused the error though

07:58 <zmatt> so it's ending up in an error state

07:58 <Romi> it looks like it

07:59 <Romi> i've been testing with a logic analyzer too, the device that i'm using to test does produce good frames

07:59 <zmatt> you sure you configured the interface correctly? (speed and such)

07:59 <zmatt> before bringing it up

08:00 <Romi> i'm not 100% sure, is there anything other than the bitrate that I have to adjust?

08:00 <zmatt> eh, I don't think so? dunno, it's been too long ago, I don't actually remember any details

08:01 <zmatt> but it's all I can think of

08:01 <zmatt> maybe use my show-pins utility to double-check pin configuration: https://github.com/mvduin/bbb-pin-utils/#show-pins

08:03 <Romi> P9.26 96 D16 fast up 2 can 1 tx can@481d0000 (pinmux_dcan1_pins) and P9.24 97 D15 fast rx up 2 can 1 rx can@481d0000 (pinmux_dcan1_pins)

08:03 <Romi> looks good to me I guess

08:04 <zmatt> yup. (also, in the future don't paste multi-line output into chat, it just becomes an unreadable mess. use a paste service like pastebin.com)

08:04 <Romi> true

08:04 <Romi> i'm slowly going crazy trying to figure out if this is a hardware or a software issue lol

08:05 <zmatt> yep, it sounds like it's either a hardware or a software issue ;)

08:05 <zmatt> sorry, I think I've run out of useful advice

08:05 <Romi> no worries, thanks for the help though

08:06 <zmatt> rest assured, there are people who have CAN working

08:06 <Romi> maybe something broke with a kernel update? though I doubt it

08:07 <zmatt> my suggestion would be to just idle in the channel, with a bit of luck someone will see your plight and have useful input

08:07 <Romi> the weird part, is that whenever I enable berr-reporting I start seeing frames, but they're all errors

08:07 <Romi> yeah, that's a good idea, i might come back at another time and check if someone else knows more about can

08:08 <zmatt> make sure you have a good ground connection to the transceiver? or check the signal integrity on the BBB side using an analog scope?

08:09 <Romi> yeah, I've checked with a scope, but it looks... fine I guess

08:09 <Romi> 3.3V voltage levels, nice and square too

08:09 <zmatt> then I've run out of ideas

08:11 <zmatt> be mindful that most people here are idle most of the time, so staying connected yields a higher probability of getting an answer than "coming back at another time", since the person who has an idea of what to check may have seen your question in between your visits

08:12 <zmatt> (but I suppose leaving an irc client open isn't convenient for everyone)

08:16 <Romi> yeah, i'll just come back later and check the chat logs, don't wanna leave my pc on

15:03 <tiger_xy> Hi GoodMorning, I have a package built using ./configure, make. There is make install script to be installed in the local unit. Is there any way to generate a .deb to be deployed into other units?

15:08 <tiger_xy> Or how to deploy the generated package into another BBBw?

18:15 <mranosta1> rcn-ee_: another silly questions in what package is the beagleboard.org wallpaper for lxqt in?

18:34 <rcn-ee_> @mranosta1, i should really package that into one of our default *.deb files... it's only in git: https://github.com/RobertCNelson/boot-scripts/blob/master/images/beaglebg.jpg

18:35 <rcn-ee_> i'll add it to our "customization" package: https://github.com/beagleboard/customizations

19:15 <Guest34> Hi everyone I am looking for some guidance I have and two x15 and two bbb they are genrating the same backtrace upon but up, what would the best forumn to get help

19:15 <Guest34> thats boot up

19:42 <vagrantc> Guest34: ask a more specific question and wait patiently

19:55 <zmatt> Guest34: share the actual backtrace using a paste service like pastebin.com, and be more specific about what you're doing that's causing the backtrace (since a backtrace at boot is obviously not a normal thing and doesn't happen when running a stock image)

20:02 <Guest34> I believe I am running the stock image as I only upgraded via the built in script that beagel bone page specifies I will head over to pastbin

20:03 <zmatt> if you've never flashed these devices, I suggest reflashing them to the latest image... you never know how old the image is they ship with

20:06 <zmatt> easiest way is by downloading the Debian 10.3 2020-04-06 4GB eMMC IoT Flasher image from the "Flasher Debian images" section of https://beagleboard.org/latest-images (the AM3358 version for the BBB or the AM5729 version for the BBX15), write that to microsd card using Etcher (https://etcher.io/) and then boot the device from that... it should automatically proceed to wipe and reflash the eMMC and ...

20:06 <zmatt> ...then power off when it's done

20:08 <crash_> I recently bought a BBB and i see that i can upgrade the kernel but there are so many too choose from is all stable enough?and what will i gain if i jump from 4.19-ti?

20:08 <zmatt> (in case of the BBB, if the bootloader on eMMC is really ancient then to get it to boot the SD card it may be necessary to bypass the eMMC bootloader by holding down the "S2" button (the one closest to the sd card slot) while applying power (you can let go once the power led turns on))

20:09 <zmatt> 4.19-ti is the latest recommended kernel series

20:10 <zmatt> what image are you currently running? what does "cat /etc/dogtag" say?

20:11 <crash_> I`m not home right now, but it has the april release installed debian 10.3

20:13 <zmatt> crash_: I actually meant that questoin for Guest34, sorry for confusion

20:13 <zmatt> *question

20:14 <zmatt> crash_: in general I'd suggest sticking to the latest release within whatever kernel series an image uses unless you desperately need a specific feature from a later kernel and don't mind being a guinea pig

20:16 <crash_> Hehe no worrys, ok thanks for the info, then i will continue to use the 4.19 that i came with :)

22:35 <Romi2> I've been trying to use a really old beaglebone black, but I haven't been able to get it to boot from an SD card, here's the Uboot logs https://pastebin.com/prNmLRx3

22:36 <Romi2> I guess it's an outdated bootloader, how can I update it?

22:36 <zmatt> you can bypass the bootloader on eMMC by powering on while holding down the S2 button (the one closest to the sd card slot)

22:37 <zmatt> you can let go of the button once the power led turns on

22:37 <Romi2> doing that just prints 'C's to the console

22:38 <Romi2> Do I hold the S2 button, and then plug it in?

22:38 <zmatt> that implies the sd card isn't bootable

22:38 <Romi2> I'll try reflashing

22:38 <zmatt> how did you flash it?

22:38 <zmatt> (and what image did you put onto it?)

22:42 <Romi2> I got an image of an SD card that I was using on another bb, but it might be corrupted I'll try with a new one

22:45 <Romi2> yup, that worked

22:46 <Romi2> Do I need to update uboot on the emmc? Or can I just dd if=/dev/zero it

22:46 <zmatt> don't use dd to erase an sd card or eMMC, use blkdiscard

22:47 <zmatt> to erase the entire eMMC: sudo blkdiscard /dev/mmcblk1

22:50 <Romi2> got it, thanks

23:00 <mranostaj> rcn-ee_: so does dtbs build with dtb-rebuilder get put in the images, or it from the bb.org kernel build?

23:02 <zmatt> the dtbs are part of the kernel build, and https://github.com/beagleboard/BeagleBoard-DeviceTrees (which is the replacement for dtb-rebuilder) is kept in sync with the kernels

23:05 <mranostaj> zmatt: ah but for a board not in the mainline it would be added in BeagleBoard-DeviceTrees repo, correct?

23:06 <zmatt> I mean, for a custom board that's up to you where you want to maintain it

23:08 <mranostaj> but that repo generates the dtbs that are put in the bb.org images, correct?

23:09 <zmatt> no, I just said 01:02 <@zmatt> the dtbs are part of the kernel build

23:09 <zmatt> each kernel package includes its own dtb files in /boot/dtbs/KERNEL_VERSION/