05:59 <Guest20> hi

05:59 <Guest20> Hi, any solution of my problem

05:59 <Guest20> my board,after some projects the board boot select switch is damaged and the track path of the switch

08:17 <Parduz> Long time i don't check BBB images, seems things are changed a bit... Where are the latest images for the BBB stored? I has this address saved (https://debian.beagle.cc/images/) but things are old... https://beagleboard.org/latest-images shows 2020 images, i see this forum (https://forum.beagleboard.org/t/debian-11-x-bullseye-monthly-snapshots/31280) ... so what should i look for the latest BBB images?

09:58 <Guest4511> HI All, I'm facing an issue in Pocket beagle bone board

09:58 <Guest4511> where in i cannot able to detect any device which is conneted over USB-peripheral

09:59 <Guest4511> lsusb,dmesg doesnot show any ports related USB

11:03 <russell--> please forgive my newbie question, why aren't the https://git.beagleboard.org/beagleboard/u-boot.git changes in upstream u-boot?

11:48 <zmatt> Parduz: depending on the user/usage I'd recommend either the 2020 IoT image from https://beagleboard.org/latest-images (which is still the latest officially released image) or one of the bullseye testing images from the second link

11:48 <zmatt> I still don't know what exactly is preventing bullseye from being the new official image, especially since it already is for the arm64 boards

11:50 <zmatt> if you're comfortable enough with debian administration and linux development I'd recommend starting with a bullseye minimal image and just installing whatever packages you need for whatever you want to do with ti

11:50 <zmatt> *with it

11:51 <zmatt> for new users I'd probably still recommend the latest official IoT image since it comes with a lot of stuff they may need preinstalled and it's more likely to match whatever online resources they read

11:52 <zmatt> russell--: I think a lot of changes do eventually get into upstream u-boot, but some patches are just not deemed suitable for mainline u-boot, or some patches may be recent and just haven't been integrated upstream yet

12:00 <russell--> i think i found the commit relevant to my openwrt problem: d0771d536bf4750a741b6213c9a9f31fe2cf4236 "am335x-osd335x-common.dtsi: set tick-timer = &timer2;, to fix Could not initialize timer (err -19)"

12:13 <Parduz> ok, thanks @zmatt

14:25 <ayjay_t> i have a question from someone else:

14:26 <ayjay_t> I'm trying to learn some PRU programming in C. Am I right if I assume that the scratch pads are not random access, but have to be accessed through the intrinsics __xin() and __xout() (assembly instruction XFR)? That is, if I want to flip bits in a scratch pad register, I have to xin it to its corresponding register, assuming I don't use remapping, do the bit manipulation in the register, and then xout it

14:26 <ayjay_t> back to the scratch pad?

14:26 <ayjay_t> When using C, am I free to use expression registers R15 to R29 as I please, as long as I don't call any functions?

17:20 <zmatt> ayjay_t: you mean using inline assembly? no, you cannot safely access any registers in inline assembly other than R30 and R31

17:23 <zmatt> "not random access, but have to be accessed through the intrinsics __xin() and __xout()" ehh that "but" doesn't make sense. they are definitely random access, and they're indeed accessed through the XIN/XOUT instructions (when using assembly) or the __xin()/__xout() intrinsics (when using C)

17:23 <zmatt> (note btw that XCHG doesn't work on the am335x)

17:26 <zmatt> also, my assumption is that the use_remapping parameter of the intrinsics must match the config register flag that enables this feature (since it seems highly unlikely the intrinsic updates that config register)

19:10 <zmatt> (my assumption was correct)

19:20 <zmatt> if use_remapping is true then the compiler has freedom to choose which register(-range) to use for the transfer, but the cost is that it has to load the appropriate offset into r0.b0 for pretty much every xin/xout (it will sometimes manage to keep r0.b0 preserved for multiple xin/xout instructions but it doesn't seem to be very good at doing so)

19:36 <zmatt> the main problem with the __xin/__xout intrinsics is that it requires the start offset to be at a full (4-byte) register boundary, i.e. you can't read just r18.w2 from a scratchpad even though the XIN/XOUT instructions can transfer any contiguous byte-range of r0..r29

22:48 <zmatt> kinda interesting that TI still actively supports the omap591x (which confusingly is not omap5 but omap1)

22:48 <zmatt> I wonder what keeps some SoCs alive while others die a quiet death

22:50 <zmatt> (or at least get delisted from the parametric search, like the dm816x)

22:58 <zmatt> never mind actually, I think the ones that went away are actually the exceptions and TI just continues to support pretty much everything...