**** BEGIN LOGGING AT Mon Jun 01 02:59:57 2020 Jun 01 03:05:51 Long time no see... zmatt: in your bbb-asm-demo.. how/why can a syscall happen, and how the system knows where to find the handler? Jun 01 05:11:49 CoffeeBreakfast: ehm, there are no syscalls in that example and its syscall handler therefore contains nothing but a comment containing a suggestion on how they might be done Jun 01 05:12:55 if you'd put a syscall ("svc" instruction) somewhere then it would invoke the exc_syscall handler, which just returns therefore turning the "svc" into an expensive nop ;P Jun 01 05:29:54 CoffeeBreakfast: and to have multiple syscalls, my suggestion was to put a selector in r12 and have exc_syscall dispatch to the appropriate handler, which is what TI uses for secure monitor calls ("smc"). it looks like linux uses r7 instead, not sure why Jun 01 05:35:56 a svc instruction looks for a function named exc_syscall? the pc jumps to a predefined address? (like the Cortex M Vector Table) Jun 01 05:37:26 (well, not the svc instruction per se) Jun 01 05:40:19 there's a vector table like the cortex-M (except containing branches rather than addresses).. called "vectors", in the file "vectors.S" :P Jun 01 05:41:45 (start.S configures the address of this table into the Vector Base Address Register) Jun 01 05:43:35 classic ARM exception handling is weirder and more annoying than cortex-M however, but my code uses the (relatively modern) srs/rfe instructions to help emulate the cortex-M exception model on cortex-A Jun 01 05:44:37 not sure why I didn't keep _start, init, and vectors all in one source file, it would have been easier to follow I think Jun 01 05:45:18 like I do in my the start.S I've used for my baremetal C++ tests (which is the only assembly file of those): https://liktaanjeneus.nl/start.S.html Jun 01 06:22:51 hi Jun 01 06:23:04 Hello can you help me Jun 01 06:23:57 i not able to install Bone driver in my pc Jun 01 06:24:04 its showing failed Jun 01 06:24:30 Hi abhishek Jun 01 08:31:50 Hi sir my beaglebone OS was crashed(Debian 9.1). suddenly i am not able to pinging. this was happens earlier also. please help me Jun 01 13:04:48 GenTooMan Jun 01 17:14:44 Hi, i'm using 3.8.13-xenomai-r83 kernel and i've custom builded board which is using eMMC5.1. So i can't flash from sd card and gives error /dev/mmcblk1 does not exist. Jun 01 17:15:02 I've updated kernel using "apt-get install" but still i get same error Jun 01 17:15:12 is there someone to help me Jun 01 17:28:55 Yes and they will respond as soon as they can Jun 01 17:51:04 that's a _very_ old kernel Jun 01 18:36:31 how can i add emmc5.1 support to this kernel? Jun 01 18:52:16 why not run a kernel from this side of the great flood? Jun 01 19:20:12 carl62: I'm pretty sure the latest 3.8-bone kernel (3.8.13-bone86) fixes this problem Jun 01 19:25:14 aaand he's gone Jun 01 19:25:38 weird though, eMMC 5.1 support was already added in 3.8.13-xenomai-r79 Jun 01 19:27:14 (in fact it just removes the EXT_CSD_REV check) Jun 01 19:30:01 isn't emmc mostly backwards compatible? Jun 01 19:30:50 yep, eMMC spec actually says you shouldn't reject a device just because EXT_CSD_REV is higher than the version you support, which is why the patch removed the check Jun 01 19:31:04 The guy before me who did the device trees didn't do overlays, and I have to try to rework it now. I've not found much in the way of pointers or changes or whatever for DTs from 4.1.19 to 4.19.106. Is there a better way to approach this than wade through all the DTs? Jun 01 19:33:49 Ragnorok: I don't really think anything significant happened between those versions that would prevent you from recompiling your .dts with the new .dtsi files Jun 01 19:34:49 Okey doke. I sort of tried that but failed. I'll try again. I'm the rankest of n00bs at it, so I could have made a mistake. Jun 01 19:35:07 (or just "git pull" assuming he was smart enough to create your custom .dts in a git clone of dtb-rebuilder or its replacement BeagleBoard-DeviceTrees Jun 01 19:35:11 ) Jun 01 19:35:22 Ragnorok: failed to compile or failed to work? Jun 01 19:36:07 Failed to work. Jun 01 19:36:25 It's no biggie. Let me flounder around a little. (wink) Jun 01 19:37:09 what #includes does your .dts have? does it include a beaglebone .dts or .dtsi file? Jun 01 19:39:00 Let me refresh myself on what's what. Been doing the FAT thing and some USB device comm checks. 4.19.106 is working well enough I need to get DTs working. Jun 01 20:59:48 @%@#$@!#@!#@!$!#$#@$@#$#@$@#@#$@##@$@# QT Jun 01 21:00:01 that doesn't quite cover it Jun 01 21:00:23 what kind of idiot changes ABI between minor versions Jun 01 21:03:50 the c++ kind Jun 01 21:04:30 I mean, that doesn't sound like a major problem as long as the shared libraries are versioned Jun 01 21:04:36 are the linker reusing actual code opcodes as constants? like: this line loads 0xA4 to r0, but wait, the last byte of some opcode of some object file has that value, I'm gonna use it.. ??? Jun 01 21:04:40 zmatt: they're not Jun 01 21:06:17 CoffeeBreakfast: I've never seen anything like that Jun 01 21:06:29 mru: that seemed unlikely, it would make package-management neigh impossible Jun 01 21:06:52 it is Jun 01 21:07:33 if you update the qt libs without also updating all apps using them, things break Jun 01 21:10:17 can either of you give a reference to some page describing this issue? it's the first I've heard of it and I'm curious about the details Jun 01 21:11:10 I've seen it happen often enough Jun 01 21:11:32 you try running an app that hasn't been recompiled Jun 01 21:11:35 it loads just fine Jun 01 21:11:46 then it prints a message saying the qt version is wrong and dumps core Jun 01 21:12:33 if the libs were properly versioned, it would either work (if the old lib is still around) or not load at all Jun 01 21:13:09 qt says minor releases are backwards binary compatible, so any instance of that failing to be the case should be a bug report Jun 01 21:13:38 maybe they have a different idea of what minor means Jun 01 21:13:48 as in, major.minor.patch Jun 01 21:15:01 minor in that sense definitely breaks Jun 01 21:15:13 I saw it not one week ago Jun 01 21:15:25 have you reported the bug? Jun 01 21:15:31 I didn't think it was a bug Jun 01 21:15:39 it's always been like that Jun 01 21:15:58 it is a bug, they're trying hard to preserve backwards ABI compatibility: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C++ Jun 01 21:16:03 ah, here's the message still in an xterm Jun 01 21:16:12 "Cannot mix incompatible Qt library (version 0x50e01) with this library (version 0x50e02)" Jun 01 21:16:39 that sounds like mixed library versions though? Jun 01 21:17:21 yep, that message means you're mixing different versions of the qt libraries themselves Jun 01 21:17:46 try with QT_DEBUG_PLUGINS=1 Jun 01 21:18:00 I've rebuilt everything now Jun 01 21:18:21 and I'm not going near qt any more than I strictly have to Jun 01 21:19:24 well I've never seen that message in my life, and some google suggests it only happens to people making a mess of their custom qt installation Jun 01 21:19:32 *some googling Jun 01 21:19:52 it is when a package calls out needs qt5 Jun 01 21:20:10 then it blows up cuz it can't find qt_511 or a similar symbol Jun 01 21:20:19 that is an utter major f'ing up Jun 01 21:21:16 ds2: as far as I can tell it's only about mixing versions of the qt5 libraries themselves, which is also what the message literally says Jun 01 21:22:26 I assumed one of the numbers was pulled from the headers while building and compiled into the app Jun 01 21:22:31 zmatt: that's exactly my point... if it isn't ABI compatible, call it something else...say QT6, QT7, etc Jun 01 21:22:35 so far every thread I've read ended up resolved when people noticed qt5 libraries from an old version still being installed Jun 01 21:22:37 not god damn qt5 Jun 01 21:22:48 that is just plain idiotic Jun 01 21:22:54 ds2: don't be silly, you're talking about the internal ABI between different libraries of qt5 itself Jun 01 21:23:05 zmatt: if they are not compatible, they should not have the same soname Jun 01 21:23:10 that's not even public API Jun 01 21:23:14 or public ABI Jun 01 21:23:24 zmatt: how is it silly to expect something called the samething to just work. Jun 01 21:23:33 qt5 should be just qt5. Jun 01 21:23:44 if it isn't call it qt6 or qt-broken-garbage Jun 01 21:23:54 I don't care what they call it Jun 01 21:23:55 ds2: I think it's silly to mix & match files from two different versions of a framework and expect sane results Jun 01 21:24:07 these are same imbicles insisting people login to install LGPL3 binaries Jun 01 21:24:22 not changing the soname when making incompatible changes is the real sin here Jun 01 21:24:48 mru: I do agree that dependencies among qt5 libraries themselves should use the full .so version... I wonder if there's some reason that's not really possible Jun 01 21:24:50 if the sonames were different, you couldn't accidentally end up with a mix Jun 01 21:25:13 mru: changing the soname would break backwards compatibility wouldn' it? Jun 01 21:25:34 so that would go against the rule of not breaking backward compat for minor releases Jun 01 21:25:48 the soname is something like libQt5Core.so.5 Jun 01 21:26:06 zmatt: except they are breaking it already Jun 01 21:26:06 yep, sounds correct to me for their versioning policy Jun 01 21:26:18 but they're not following that policy Jun 01 21:26:48 the policy is about the API and ABI for applications that use qt5 Jun 01 21:26:56 not about internal dependencies between components of the framework Jun 01 21:27:03 you just shouldn't mix those Jun 01 21:27:12 then they should have made it harder Jun 01 21:27:33 agreed, it does seem to be handled rather... inelegantly Jun 01 21:27:57 like, at the very least print the libraries involved in that message Jun 01 21:29:47 oh I see now why they can't Jun 01 21:31:00 wait how does that even happen Jun 01 21:31:56 hmm, right Jun 01 21:32:42 anyway yeah it's a versioning of the private qt5-internal ABI Jun 01 21:32:58 which imo shouldn't exist Jun 01 21:33:06 that's nonsense Jun 01 21:33:21 then they shouldn't be separate libs either Jun 01 21:33:41 or if needs to be split for some reason, they pieces shouldn't be directly visible Jun 01 21:33:48 that's a silly suggestion for such a large library Jun 01 21:34:01 such a large library is silly Jun 01 21:34:17 maybe, but that seems highly subjective Jun 01 21:34:33 their goal seems to be to create a "qt" wrapper class around everything imaginable Jun 01 21:34:44 even if using that thing directly is simpler Jun 01 21:34:46 anyway, I don't think having a private API/ABI between jointly-maintained components of a library is a strange thing Jun 01 21:35:10 I don't disagree with that, but it's kinda besides the original point Jun 01 21:35:40 I can tolerate a set of interfaces that are not intended for others to use Jun 01 21:35:40 I do think their way of reporting this version mismatch sucks Jun 01 21:35:52 but the versioning requirements should be the same for all Jun 01 21:36:20 if you can't do that, you've probably split your functionality badly in the first place Jun 01 21:36:24 I think it should be detected when loading the library, not at runtime Jun 01 21:36:51 that would have prevented every forum thread I've encountered on google Jun 01 21:36:57 pretty sure Jun 01 21:38:45 having said that, I'm not immediately sure how you'd do that Jun 01 21:39:20 it makes it virtually impossible for one to have binaries Jun 01 21:39:21 oh I do, use versioned symbols for the internal ones Jun 01 21:39:45 (so the correct symbols are unavailable if you're mixing library versions) Jun 01 21:39:58 ds2: what do you mean? Jun 01 21:40:35 ds2: just don't mix libraries from one qt5 version and libraries from another qt5 version on the same system Jun 01 21:40:52 zmatt: I have an app Foo. It requires "QT5". A distro provides a version of QT5. Jun 01 21:41:04 App Foo immediately fails with that error Jun 01 21:41:29 zmatt: I am not mixing qt5 components. I am trying to run an app that was compiled to use qt5 Jun 01 21:41:39 conclusion - qt5 is not qt5 Jun 01 21:41:52 that is utterly and completely broken Jun 01 21:41:52 ds2: then something is very seriously wrong... is the app using qt5-private internal stuff or something? Jun 01 21:42:02 zmatt: nope. none of that Jun 01 21:42:04 hence my complaint Jun 01 21:42:23 ds2: like I said, something is horribly wrong then. as far as I can tell that shouldn't be possible Jun 01 21:42:33 end result I have trees of qt511, qt512, etc all over the place and LD_LIBRARY_PATH is need to make things work Jun 01 21:42:57 that sounds more like a great way to *cause* such problems than to solve them :P Jun 01 21:43:03 zmatt: that is possible when they intentionally put symbols to break it. that's why I am saying if they don't want mixing, call qt5, qt6, qt7, etc Jun 01 21:43:42 qt is the biggest peice of garbage out there. nothing else does games like this. My guess is that's a market shannigan Jun 01 21:43:54 boost... Jun 01 21:44:12 make the opensource LGPL version as worthless as possible while still claiming they support opensource Jun 01 21:44:20 ds2: sorry but no, that sounds like nonsense. that message is about qt5-internal ABI between qt5 components, they explicitly aim to preserve API and ABI backwards compatibility (for applications) between minor versions Jun 01 21:44:26 mru: boost is a good way to drive yourself into a mine Jun 01 21:44:30 if you have a case where that fails, file a bug report Jun 01 21:44:48 there are more then 1 app that is broken like that... all opensource Jun 01 21:45:04 filing bug reports almost guaranteed to be ignored or dismissed feels like a waste of time Jun 01 21:45:18 why would they be ignored or dismissed? Jun 01 21:45:20 filing a bug with qt is asking to be spammed to buy the support Jun 01 21:45:38 ENOTABUG Jun 01 21:45:46 zmatt: QT is in the business of fleecing people anyway they can Jun 01 21:46:03 mru: if he has an example of an ABI break between minor versions then that's absolutely a bug Jun 01 21:46:13 however, he doesn't since that's not what this message indicates Jun 01 21:46:54 ds2: btw what are you talking about "when they intentionally put symbols to break it" ... I've searched the qtbase5 source tree and that error shows up in two files and has absolutely nothing to do with symbols Jun 01 21:47:55 assuming we're still talking about "Cannot mix incompatible Qt library (...) with this library (...)" Jun 01 21:50:25 it's triggered by the constructor of QObjectPrivate or QWidgetPrivate by code from a different qt5 version Jun 01 21:54:13 zmatt: I think there is a confusion, I am not mixing qt installs. Jun 01 21:54:38 as I said, I have a qt app binary and a fixed qt install Jun 01 21:55:32 ds2: then I presume you're tlaking about a different error than mru is Jun 01 21:55:37 *talking Jun 01 21:57:42 and if a minor-version upgrade of qt5 breaks an application, then that would be a violation of their versioning policy hence should be reported as a bug Jun 01 21:58:13 I think you have too much faith in the bug reporting facility Jun 01 21:59:35 I mostly think that complaining about ABI breaks here instead of to them is kinda silly... I'm sure accidental ABI breaks happen now and then, but if you don't report them then you shouldn't complain about them, you've never given the Qt project even the chance of fixing it Jun 01 22:00:16 if you've reported it and nothing happens, _then_ you can complain :P Jun 01 22:00:17 zmatt: nobody is expecting you to fix it Jun 01 22:00:31 including me Jun 01 22:00:44 but a man's gotta grouse somewhere Jun 01 22:00:50 and the pub's shut Jun 01 22:00:52 but you also can't expect the Qt project to fix problems they don't know about Jun 01 22:01:22 you got it backwards Jun 01 22:01:33 I expect them to already know about it and not care Jun 01 22:01:49 except they clearly do seem to care Jun 01 22:02:06 from what I've found Jun 01 22:02:47 do you give them money? Jun 01 22:03:11 mru: note however that the "Cannot mix incompatible Qt library" error you mentioned it excluded from this, that's just people making a mess of their installation. I'm assuming ds2 is talking about something different Jun 01 22:03:27 no? Jun 01 22:03:44 I don't particularly like qt anyway Jun 01 22:03:47 I'm not sure what he's talking about since I haven't seen his error messages Jun 01 22:04:07 in my case, I might have been partway through a qt update Jun 01 22:04:15 lol Jun 01 22:04:22 which generally triggers a rebuild of everything qt related Jun 01 22:04:37 what's so funny? Jun 01 22:04:48 if they versioned their damn libs, it wouldn't be a problem Jun 01 22:05:13 then you'd be able to install the new version of all the libs, then delete all the old ones Jun 01 22:05:53 and then all applications that were built against the old ones are broken Jun 01 22:06:04 violating their versioning policy Jun 01 22:06:09 then keep the old ones until the apps are rebuilt Jun 01 22:06:21 except it's the explicit policy that apps don't need to be Jun 01 22:06:23 or don't break compat in the first place so the soname can be kept Jun 01 22:06:52 they've set themselves incompatible goals Jun 01 22:09:33 *shrug* ... I do think it's quite reasonable to want what they're doing, although it does seem like it might be tricky to do so without creating at least *some* headache Jun 01 22:10:18 I get why they want it Jun 01 22:10:20 I am pretty sure though that it can be done in a better way than is done currently, at least making sure that the failure is detected when the library is loaded Jun 01 22:11:22 if there's private stuff that needs to be shared between libs, one way is to put that in a separate shared object with a more specific soname Jun 01 22:11:24 that won't make upgrades atomic, though honestly I suspect system upgrades often have narrow windows where things might be fucked if you start an application at the wrong time :P unless you're versioning everything like NixOS does Jun 01 22:13:18 mru: then you'd get two versions of the private shared library loaded into your application if you start it when one qt5 library has been upgraded and another hasn't yet Jun 01 22:13:25 which won't give an error but probably a crash Jun 01 22:13:47 yeah, it's not good either Jun 01 22:14:40 the real problem is trying to have libraries be compatible and not compatible at the same time Jun 01 22:14:52 I think using something like versioned symbols might at least help to ensure it fails right away (when loading the libraries) and be easily identifiable instead of happening at runtime and having no idea who's responsible Jun 01 22:14:56 not at all Jun 01 22:15:48 or, at least I think it's perfectly reasonable to want to avoid backwards ABI-compatibility for your private internal interfaces Jun 01 22:15:50 if you're making incompatible changes without changing the soname, versioned symbols are a must Jun 01 22:16:08 the desire is understantable Jun 01 22:16:21 but the practical implications are nasty Jun 01 22:17:20 perhaps... I generally just don't start applications in the middle of a system upgrade :P Jun 01 22:17:56 next you'll be saying each app should be running in its own docker container Jun 01 22:18:11 it's a complete mystery to me how you'd jump to that notion Jun 01 22:18:29 oh, did docker go out of fashion? Jun 01 22:18:35 dunno, I've never used it Jun 01 22:18:58 containers seem to be the current universal solution Jun 01 22:19:10 like xml was a decade or two ago Jun 01 22:21:12 we do containerize some services on our beaglebones both for security and ease of upgrading them, but that's just done with directives in their service files Jun 01 22:44:26 https://pastebin.com/RsY4tTSc is some source from imageio devices, an error, and my thoughts. If you understand that I am trying to run this source from my BBGW and know of this error, do I need to set up ffmpeg w/ vaapi_devices, e.g. on the command line or w/ installing? Jun 01 22:56:58 How do you set up CAN bus on beaglebone AI? Jun 01 23:02:38 canbus: I found a fellow that set it up on the BBBlue but not on the AI yet. Jun 01 23:02:45 Let me check online. Jun 01 23:04:48 Thanks! Yah i searched online but couldn't find any overlays or really any information Jun 01 23:04:55 https://www.element14.com/community/community/project14/visionthing/blog/2019/11/16/beagleboard-ai-brick-recovery-procedure is a site online. Jun 01 23:05:10 I know that is not CAN stuff but it is a start to understand it all. Jun 01 23:05:32 That fellow might be available if necessary to help. Jun 01 23:05:53 I am not sure, though. I am not into CAN or him. But, like I say, it is a start. Jun 01 23:06:17 true Jun 01 23:06:39 From looking at the pinout it looks like CAN2 is only available as RX/TX Jun 01 23:06:50 er sorry CAN2 is available but not default pin Jun 01 23:06:57 I will attempt to look again. Please bear w/ me. Jun 01 23:07:22 Hmm. I know someone in here has a pin out diagram for the AI. Let me look it up. Jun 01 23:08:25 https://docs.google.com/spreadsheets/d/1mSqEpV_BAUHfeNApytxHcGhgTZwypy564GyOr66Nphs/edit?usp=sharing is from @zmatt. He made this worksheet available. Jun 01 23:11:02 I know the pin muxing on the AI is difficult from what people have been saying but, here is an example: https://www.elinux.org/EBC_Exercise_41_Pin_Muxing_for_the_AI. Jun 01 23:11:23 You Rock!! This worksheet is great! :) Jun 01 23:11:55 Thank @zmatt, he made it. Jun 01 23:12:33 Thank you zmatt :) hah Jun 01 23:13:02 Ha. Jun 01 23:13:18 I am sure he got it. He never replies to thank you's for some reason. Jun 01 23:13:45 Must be a stern personality mixed w/ "not a problem" rhetoric? Jun 01 23:13:53 No clue over here. Jun 01 23:16:09 canbus: If you want the BBBlue thing, here it is (it may help too): https://www.hackster.io/sacchet/chupacarbrah-car-hacking-with-beaglebone-and-python-18f137. Jun 01 23:30:00 @#@$#@$#@$#$!@#@!#@!#@!# modern cars Jun 01 23:30:40 Is the image produced for the AI currently supposed to have kernel 4.14.x? Jun 01 23:31:24 zmatt: it is very simple - I have an app that was compiled against version Qt5.11. It run not run if your system has 5.12, 5.09, 5.x where x !=11. There are no mismatches in the system install. The only work around is to install 5.11 and LD_LIBRARY_PATH it there. Jun 01 23:32:13 and that failure is done via explicit symbols. All those versions are QT5 and are incompatible. Jun 01 23:35:09 Hey sorry i had an errand to run. Thanks so much for the help set_ Jun 01 23:35:16 it looks like the link is broken https://www.hackster.io/sacchet/chupacarbrah-car-hacking-with-beaglebone-and-python-18f137. Jun 01 23:35:18 No issue. Jun 01 23:35:24 Forget the . Jun 01 23:35:29 It works. Jun 01 23:35:41 Just double click it. It is a hackster.io site. Jun 01 23:35:58 ohh whoops ok now it works thanks Jun 01 23:36:20 Yea boy! Jun 01 23:36:52 shoot yah so it looks like the blue must work out of the box because i'm not getting anything listed in ifconfig Jun 01 23:37:12 ifconfig? Are you trying to use WiFi? Jun 01 23:37:34 use connmanctl to set it up. I think there was an issue w/ ifconfig, connmanctl, and the entire set up. Jun 01 23:38:01 connmanctl tries to take over at boot for the set up. I saw a google groups thing a while back. Jun 01 23:38:19 yah i do that to setup wifi but ifconfig also lists can buses Jun 01 23:38:27 Oh. Jun 01 23:38:29 Okay. Jun 01 23:38:33 ip addr? Jun 01 23:38:39 Oh. Jun 01 23:38:41 I got you. Jun 01 23:38:44 the problem looks to be that the pins aren't CAN TX/RX by default Jun 01 23:39:01 Did you see that page from Element14? Jun 01 23:39:07 I listed it earlier. Jun 01 23:39:26 That fellow talks/describes how to set up pin muxing for the AI> Jun 01 23:40:04 .dts and so on. I do not think that config-pin works w/ the AI. Jun 01 23:41:09 I can try right now. I just plugged in. Let me see if I can work some magic. Hopefully, someone more knowledgeable will step in if I get odd. Jun 01 23:41:11 Ha. Jun 01 23:41:21 erm not seeing an element14 but the elinux link that you sent looks to be on the right track Jun 01 23:41:24 i'm going to try that Jun 01 23:41:37 canbus: Let me show you again. Jun 01 23:42:03 This is it: https://www.element14.com/community/community/project14/visionthing/blog/2019/11/16/beagleboard-ai-brick-recovery-procedure#jive_content_id_Pinmux_Procedure Jun 01 23:42:25 That fellow seems to have figured out how to configure the .dts files to suit the AI for use. Jun 01 23:44:58 canbus: Are you good w/ .dts files? Jun 01 23:44:59 oh wow show-pins is awesome! Jun 01 23:45:15 yah should be able to figure out the dts stufff Jun 01 23:45:44 Okay. Jun 01 23:47:30 That seems to be all gpio, i2c, and pwm. So, for CAN, I think you might have to jump into the TRM. Jun 01 23:50:03 "Note: the pin IDs shown in the second column are not yet correct as of 10/31/2019. For example, P9.15 is actually 76, not 69." ... uhh what Jun 01 23:51:44 lol Jun 01 23:51:46 he's wrong about that Jun 01 23:51:48 it's 69 Jun 01 23:52:34 at least, bbai schematic says it connects to ball AG4, my spreadsheet says that's pin 69 but I guess I'll double-check the am572x datasheet Jun 01 23:53:19 trm I mean Jun 01 23:54:33 Too much back and forth for my eyes. I get what GenTooMan and KenUnix go blind for these days. Jun 01 23:55:39 definitely 69 Jun 01 23:58:28 On the element14 page I listed, that fellow talks about copying the .dts file and using make to write the file to where? Jun 01 23:58:37 I am not sure I understand make in this category. Jun 01 23:59:18 make is used to build the .dtb from the .dts Jun 01 23:59:47 Oh. I figured it was like this: dtc -I dts -O dtb -f devicetree_file_name.dts -o devicetree_file_name.dtb? Jun 01 23:59:48 yah it basically turns code into object file Jun 01 23:59:57 the object file is what you point to to load Jun 02 00:00:07 I tried the make command and got an error. Jun 02 00:00:20 no you use dts etc. as you listed Jun 02 00:00:21 to compile Jun 02 00:00:22 set_: the invocation is more complex than that, which is why a Makefile is used so you don't have to type it out Jun 02 00:00:29 canbus: no, you use make Jun 02 00:00:40 I mean, make will invoke dtc indirectly of course Jun 02 00:00:51 set_: you probably did it in the wrong directory? Jun 02 00:00:58 Oh. Hmm. Jun 02 00:01:04 Let me try again. Jun 02 00:01:09 right yah, cuz you have to cross compile or something. i dunno, i wasn't able to use the regular dtc compiel command either Jun 02 00:01:29 indirectly it does that command tho Jun 02 00:01:30 The AI has a script on it for dts compilation. Jun 02 00:01:34 canbus: it's not code, a dtb is just a data structure, there's no "cross-compiling" Jun 02 00:01:50 but the source does need to be preprocessed before being passed to dtc Jun 02 00:02:00 depends on where we are talking. if you make from regular computer linux, then you have to cross compile Jun 02 00:02:09 if you do on an arm processor, then no need Jun 02 00:02:26 no, that's what I just said: there's no compiled code in a dtb, it's just a datastructure Jun 02 00:02:35 I am in BeagleBoard-DeviceTrees/src/arm/. Jun 02 00:02:36 its structure is not dependent on what kind of machine you're on Jun 02 00:02:48 set_: the Makefile is in BeagleBoard-DeviceTrees Jun 02 00:02:51 yah but we are going from dts to dtb or dtbo, right? Jun 02 00:02:52 Dang it. Jun 02 00:02:53 Okay. Jun 02 00:03:03 hence you need to execute "make src/arm/name-of-your.dtb Jun 02 00:03:04 " Jun 02 00:03:10 Got it. Jun 02 00:03:12 Okay. Jun 02 00:03:13 ohh i see Jun 02 00:03:24 I see it now. Jun 02 00:03:26 canbus: yes, which is from a textual format to a binary format, but still just a binary datastructure, not code Jun 02 00:04:34 Well damn. You guys just made the entire process easier than one could have thought. Jun 02 00:04:59 I guess people got tired of repetition. Jun 02 00:07:43 Okay. Jun 02 00:07:47 I am testing it. Jun 02 00:08:00 I am about to write the .dtb file to the AI. Jun 02 00:08:19 I see the new image is 8GB. Boo ya! Jun 02 00:11:42 what did you change the pin to? i'm seeing Jun 02 00:11:44 DRA7XX_CORE_IOPAD(0x368C, MUX_MODE14) Jun 02 00:11:59 weird 14. thought that would be 0. i guess it should be 2 right? Jun 02 00:12:20 holy zmatt your excel sheet is awesome, seriously Jun 02 00:12:32 make sure to read the README tab Jun 02 00:12:32 Thank you! Jun 02 00:14:14 (I sometimes regret deviating from the TRM's numbering scheme, but then again I'm not the only one: u-boot and the linux kernel also use 0-based numbering for uarts for example) Jun 02 00:14:29 oh dcan affected Jun 02 00:14:49 it's just really annoying that TI used 1-based numbering for some stuff Jun 02 00:15:25 why is there a p9.26a and p9.26b? Jun 02 00:15:40 two processor signals connecting to the same external pin, for more flexibility in pinmux options Jun 02 00:15:47 oh nice Jun 02 00:16:07 crazy, i've never seen that before Jun 02 00:16:21 Heh! Did show-pins need installing or is it onboard w/ the new image? Jun 02 00:16:36 so you could have 1 processor use the pinmux in 1 way, and another processor in y our code use it as a different mux? Jun 02 00:16:43 if there is one on it it's probably jkridner's and not mine Jun 02 00:17:05 Oh. I tried to make it work. I guess I will need to install it. Jun 02 00:17:39 Does pin-utils work for the AI? Jun 02 00:17:49 I see it is actually bbb-pin-utils. Jun 02 00:18:18 use the correct branch Jun 02 00:18:24 ti? Jun 02 00:18:43 master is for the bbb, there are separate branches for various other hardware Jun 02 00:18:53 e.g. bbai-experimental Jun 02 00:19:29 w/ apt? Jun 02 00:19:33 no Jun 02 00:19:35 Oh. Jun 02 00:19:47 Oh. Jun 02 00:19:50 I got you. Jun 02 00:20:28 Nope. Jun 02 00:20:32 I have no clue. Jun 02 00:20:45 https://github.com/mvduin/bbb-pin-utils/tree/bbai-experimental#show-pins Jun 02 00:21:26 note that README is mostly not updated for the BBAI, though the "Installation" section is Jun 02 00:21:42 Oh. Okay. I got it now. Jun 02 00:22:40 did you have any luck with setting the pins set_? I changed 14 to 2 and now i'm hung at "Starting kernel ..." Starting kernel ... Jun 02 00:23:22 gonna replace with my backup real quick and try the original compiled dtb from github to make sure it works without my change Jun 02 00:23:23 Oh. Jun 02 00:23:31 Do not use config-pin. Jun 02 00:23:38 Once the pins are set in the .dtb. Jun 02 00:23:42 It is good to go. Jun 02 00:24:17 Let me plug something in and make a ciruit to try it out. Jun 02 00:24:59 oh so i just downloaded the BeagleBoard-DeviceTrees.git code, edited the pins i wanted, compiled via make, backed up original dtb and replaced Jun 02 00:25:11 Oh. Jun 02 00:25:35 Did you find the CAN files on your machine once the .dtb was loaded and rebooted? Jun 02 00:26:02 it doesn't boot for me. i get stuck at loading kernel Jun 02 00:26:27 What image are you using? Jun 02 00:26:51 Or...what image were you using? Jun 02 00:27:43 AM5729 Debian 10.3 2020-04-06 8GB SD IoT TIDL Jun 02 00:27:56 I was on 4.14.x and just updated my kernel before trying out the ideas from element14. Jun 02 00:27:59 canbus: it's easy enough to end up with a non-booting system if you messed up yeah Jun 02 00:28:02 when modifying the dtb Jun 02 00:28:06 yah Jun 02 00:28:09 dangit! lol Jun 02 00:28:14 can fix though Jun 02 00:30:13 note that I strongly recommend you don't modify the original dts, make a copy with a different name and modify that (and configure the dtb to use into the "dtb" variable in /boot/uEnv.txt) ... normally an even better way would be to #include an existing .dts and just add your custom definitions below that, but last time I checked the bbai dts had a hideous giant pinmux thing that got in the way of any ... Jun 02 00:30:19 ...custom definitions, and I haven't checked if that's been fixed yet Jun 02 00:32:49 yah true i agree. Rather than modifying the original code it would be better to add an overlay where you just disable the original specifc pin and modify to what you need Jun 02 00:33:14 at this point, i'm just trying to get it up and going, but i will do that in the future. you are right Jun 02 00:33:49 regardless I'd strongly recommend giving it a different name and not overwriting any of the standard .dtb files Jun 02 00:35:14 ok yah you are right. ill do that thanks Jun 02 00:35:49 and installing your custom .dtb into /boot/dtbs/ and not a kernel-version-specific subdirectory. that means you can upgrade your kernel (at least within the same major series) and it'll still use your custom dtb (instead of reverting to the default or failing to boot) Jun 02 00:40:53 I am going to try to fade a bi-color led into three colors! Jun 02 00:40:55 W/ the AI! Jun 02 00:41:33 WIsh a brother some luck. Jun 02 00:44:00 jkridner: is cape_pins_default in the dts still needed? has u-boot not yet been fixed to set sane defaults on the bbai ? Jun 02 00:45:16 Heh? Where is GND on the AI? P9.01/02? Jun 02 00:45:26 same as on the BBB Jun 02 00:45:29 Yea boy! Jun 02 00:46:05 P9.01-02, P9.43-46, P8.01-02 Jun 02 00:46:11 Okay. Jun 02 00:50:15 Ut oh. I see the issue now. I know nothing. Jun 02 00:51:21 Starting w/ gpio instead of fading w/ pwm. Jun 02 01:00:23 canbus: hmm, iirc the dcan driver also needs to switch pins at runtime, lemme see if I can make an example dts declaration Jun 02 01:02:12 oh shoot thank you so much for the help! Jun 02 01:06:18 On my system, gpiochip0 in /sys/class/gpio/ means exactly what? Jun 02 01:06:56 the gpio0 controller Jun 02 01:07:01 Okay. Jun 02 01:07:10 yah i dont remember exactly but they are in groups. gpio0 gpio1 etc. are those groups Jun 02 01:07:15 canbus: okay, so I _think_ it's probably something like: https://pastebin.com/raw/qbEZXd3p Jun 02 01:07:22 or yah controller Jun 02 01:07:27 canbus: gpio are the individual gpios, gpiochip is a gpio controller Jun 02 01:08:09 I have a gpiochip0 w/ an export file in it. Jun 02 01:08:35 I am trying to export, write, value, and direction that same file. Jun 02 01:08:38 In .c. Jun 02 01:08:45 set_: ???? Jun 02 01:08:53 normally you should never need to manually export a gpio Jun 02 01:09:00 Oh. Jun 02 01:09:01 Okay. Jun 02 01:09:05 they're exported by default during boot Jun 02 01:09:27 Okay. Jun 02 01:09:38 So, the source from an older book might be a bit dated? Jun 02 01:09:54 "Bad to the Bone," is the book w/ the source in .c format I found. Jun 02 01:10:33 canbus: normally you'd be able to just #include "am5729-beagleboneai.dts" followed by these custom additions, except you'll run into pin conflicts because am5729-beagleboneai.dts has a giant pinmux node that claims all pins Jun 02 01:12:46 brb...this is getting good. Jun 02 01:12:59 so do i just modify the make file to include this pastebin file as compile and then use overlay? Jun 02 01:13:23 you don't need to modify the makefile Jun 02 01:13:29 does the bbai support overlays already? Jun 02 01:13:59 oh i thought it did. does it not? i thought maybe do: Jun 02 01:14:01 uboot_overlay_addr0=/lib/firmware/.dtbo Jun 02 01:14:07 enable_uboot_overlays=1 Jun 02 01:14:12 okay Jun 02 01:14:18 is that not? Jun 02 01:14:29 yep that implies it does Jun 02 01:14:42 I hadn't tried the latest image on the bbai yet Jun 02 01:14:45 i dont see that in the uEnv.txt but i've used it in the past Jun 02 01:14:49 ohhh Jun 02 01:14:50 oh Jun 02 01:14:59 I thought you meant you have that in your /boot/uEnv.txt Jun 02 01:15:17 naw it is pretty baren in that file for ai Jun 02 01:15:18 if those settings are not there already by default Jun 02 01:15:25 then I'd assume it doesn't Jun 02 01:15:38 i can try for grins though Jun 02 01:18:33 uhhh wtf, cape_pins_default looks like nonsense Jun 02 01:18:56 it configures most pins to gpio mode, but with input disabled Jun 02 01:20:08 jkridner: why do cape_pins and unused_pins still exist in am5729-beagleboneai.dts instead of configuring the defaults in u-boot? and why does it configure most pins to gpio mode with input _disabled_ :P Jun 02 01:22:57 hrm shoot getting an error with dtc -O dtb -f Can.dts -o Can.dtb Jun 02 01:23:13 Error: Can.dts:1.1-2 syntax error Jun 02 01:24:09 canbus: I've updated https://pastebin.com/raw/qbEZXd3p Jun 02 01:24:11 oh nice looking through the dts file now. yah i saw that you have to put the pins to sleep in case the lines have any toggling Jun 02 01:24:23 you even put a fix in for that issue! nice! Jun 02 01:24:45 save as src/arm/bbai-custom.dts or whatever (in a git checkout of the BeagleBoard-DeviceTrees repository Jun 02 01:24:52 then "make src/arm/bbai-custom.dtb" Jun 02 01:25:43 I'm disabling cape_pins and hoping u-boot sets sane defaults... Jun 02 01:26:31 if it boots with this dtb, please dump the pin configuration using my show-pins utility and share it via pastebin (or other paste service of your choice) so I can verify that it all looks sane Jun 02 01:26:42 Error: Can.dts:1.1-2 syntax error Jun 02 01:26:44 with that one Jun 02 01:26:53 it compiles fine here Jun 02 01:26:56 oh i see ok 1 sec Jun 02 01:27:11 use the makefile to compile it, not a manual dtc invocation Jun 02 01:27:49 nice that created a dtb! Jun 02 01:28:11 no promises it's a _working_ dtb though :D Jun 02 01:28:18 ok ill post pastebin Jun 02 01:28:37 dood seriously i wish there was a tip feature in this app! Jun 02 01:28:42 you are awesome! Jun 02 01:32:05 ok testing overlay in uEnv.txt Jun 02 01:32:05 enable_uboot_overlays=1 Jun 02 01:32:13 don't bother Jun 02 01:32:19 this isn't an overlay anyway Jun 02 01:32:32 but also, if it were supported it would be in /boot/uEnv.txt Jun 02 01:32:34 er oh fuk yah Jun 02 01:32:55 you are rihgt. the command stuff isn't overlay my bad Jun 02 01:33:01 craop Jun 02 01:38:28 dtb=/boot/dtbs/Can.dtb Jun 02 01:38:32 changed to ^^ Jun 02 01:38:35 just the name Jun 02 01:38:43 oh? Jun 02 01:38:52 dtb=Can.dtb? Jun 02 01:39:07 if that's what you named it (which is a pretty terrible name imho but hey :P) Jun 02 01:39:14 haha Jun 02 01:39:28 my creative skills for you Jun 02 01:40:56 well I suggested bbai-custom.dtb both to at least include the hardware it's for and because I assumed you may end up adding more customizations than just enabling can Jun 02 01:41:13 if it's for a specific project/application then use that of course Jun 02 01:43:04 oh no, don't tell me it's stlil the same u-boot Jun 02 01:44:11 at this point just trying to get can up. i can change to that instead Jun 02 01:44:22 erm says "debug: [dtb=Can.dtb] ..." Jun 02 01:44:26 which seems to be good Jun 02 01:44:36 hung at "Starting kernel ..." though Jun 02 01:44:53 "loading /boot/dtbs/Can.dtb ..." Jun 02 01:45:25 that almost seems like even the base dtb is somehow wrong, I can't imagine the additions for can could cause such an early boot failure Jun 02 01:45:39 that makes no sense though Jun 02 01:45:41 yah i mean they are just replacing gpio Jun 02 01:46:27 https://pastebin.com/XTE8HDzq Jun 02 01:47:03 oh it does support overlays? hm Jun 02 01:47:19 that is the same issue i got when i changed the original ai dtb file though Jun 02 01:47:45 the only thing i changed as p9.24 & p9.26a from 14 to 2 Jun 02 01:47:59 that would not have given you a can interface anyhow Jun 02 01:48:12 but yeah there's more going on here Jun 02 01:48:36 because it needed to be initailzed at run time? Jun 02 01:48:55 but I can't really test anything here and I kinda have to do other stuff... I can take a look at this when I'm at home again and have access to my bbai Jun 02 01:48:59 I made it back. Jun 02 01:49:06 because you didn't enable the can interface Jun 02 01:49:28 My led is on! Jun 02 01:49:38 But I cannot control it. No! Jun 02 01:50:13 anyway, I'm also pretty sure that u-boot 2019.07 predates setting sane defaults for pins, so that's an additional problem... that means &cape_pins can't be safely disabled Jun 02 01:50:24 isn't enabling the can interface just the normal "sudo ip link set can1 up type can bitrate 1000000 dbitrate 8000000 restart-ms 1000 berr-reporting on fd on" type whatnot Jun 02 01:50:40 that requires _having_ a can1 interface Jun 02 01:50:46 right now I assume you don't Jun 02 01:51:25 can2 only, but just saying that i'm thinking once we get pins set, ifconfig should show available can interfaces, then you set it up with ip link etc. Jun 02 01:51:49 or do you think there are additional steps to setup the can interface? Jun 02 01:52:21 canbus: wait, there is a can interface present already? wtf? Jun 02 01:52:27 i have read that you may also need to setup modprobe on socketcan Jun 02 01:52:36 no there is no interface present. that is the problem Jun 02 01:52:43 ifconfig doesn't show anything can related Jun 02 01:52:44 exactly Jun 02 01:52:53 and pinmux doesn't change that Jun 02 01:53:06 https://pastebin.com/5yMLag4a <<< Does this make sense still? Jun 02 01:53:10 it means the kernel doesn't even know about any can device Jun 02 01:53:23 erm crap i thought maybe once the pinmux was fixed, the socketcan would maybe work Jun 02 01:53:30 set_: ugh that looks awful Jun 02 01:53:42 Oh. Jun 02 01:53:59 set_: but I don't have the energy to explain how to do it properly Jun 02 01:54:04 Okay. Jun 02 01:54:05 No issue. Jun 02 01:54:15 canbus: besides, the pinmux actually needs to be controlled at runtime by the driver Jun 02 01:54:45 that's why my snippet enables the can device and gives it pinmux blocks for multiple states Jun 02 01:55:06 oh i see Jun 02 01:55:21 shouldn't the mode be 2? Jun 02 01:55:39 oh silly me I copy-pasted that from the am572x evm but it uses the other can interface Jun 02 01:55:47 anyway, but that's not causing your boot failure Jun 02 01:56:22 erm so all of them should be 2 right? Jun 02 01:56:32 the ones for active state Jun 02 01:56:36 I'm updating the paste Jun 02 01:56:55 oh and sleep should be 14 since that is default right? Jun 02 01:57:04 gpio Jun 02 01:57:06 no, 15 Jun 02 01:57:09 oh Jun 02 01:57:13 which is "safe mode" (pin disabled) Jun 02 01:57:35 paste has been updated Jun 02 01:57:55 ok thanks Jun 02 01:58:04 will try 2 sec Jun 02 01:58:07 oh! I just thought of something Jun 02 01:58:31 are you using the right branch of BeagleBoard-DeviceTrees ? Jun 02 01:59:51 oh? i didn't know there was a right branch. i'm just following that web site path Jun 02 02:00:14 lemme look at git Jun 02 02:00:23 there's a branch per major kernel series Jun 02 02:01:33 ahhhhh crap i just went to the git to check brnach. 1 sec i'm getting a thermal shutdown error on ai. i need to get a case with fan it seems Jun 02 02:01:50 the kernel installed by default depends on which image you have: for debian 10.3 2020-04-06, the "IoT TIDL" image for BBAI uses kernel 4.14-ti, all other image variants use 4.19-ti Jun 02 02:01:55 im on 4.14.108-ti-r131 Jun 02 02:02:11 shoot! and default branch is 4.19 Jun 02 02:02:15 yeah then switch to the v4.14.x-ti branch Jun 02 02:02:22 !!! you are a god! Jun 02 02:02:27 haha Jun 02 02:02:52 2 sec gonna let it cool and ill switch branches and retry Jun 02 02:03:13 weird though, i wouldn't think using the make file on a custom dts would make any difference between branches though Jun 02 02:03:34 the dts's for sure but maybe they are doing something different in the make file? Jun 02 02:03:45 of course it does, it indirectly #include a whole bunch of files that are different between the branches Jun 02 02:03:52 oh right! Jun 02 02:03:56 yah you are totally right Jun 02 02:09:30 Hi sir my beaglebone OS was crashed(Debian 9.1). suddenly i am not able to pinging. this was happens earlier also. please help me Jun 02 02:11:55 once i get all this up and running, i'm going to do a full write up on stack overflow so other people don't have to go through all this pain Jun 02 02:12:21 ok i think it is cool enough to try again. 2 sec Jun 02 02:13:26 Nagarjuna: Usually I just update my image on beagleboard.org. Jun 02 02:14:03 canbus: I'm still baffled how hot the bbai gets while my bbx15 (which has the same SoC, no heatsink) just gets lukewarm Jun 02 02:14:26 lol yah this thing gets reallllly hot! Jun 02 02:14:40 Nagarjuna: I seriously doubt anyone could give useful advice based on such a vague problem description Jun 02 02:15:35 canbus: though, if you're not actually using TIDL you may want to try a non-TIDL image since I did notice that it seems to keep all four EVEs running constantly Jun 02 02:17:17 (either IoT non-TIDL or Console .. I personally generally start with a console image since I'm perfectly fine with just installing stuff I want myself) Jun 02 02:19:43 shoot Jun 02 02:19:43 make src/arm/bbai-custom.dtb Jun 02 02:19:50 src/arm/bbai-custom.dts:1:10: fatal error: am5729-beagleboneai.dts: No such file or directory Jun 02 02:20:46 canbus: anyway, like I said earlier: if it does boot, immediately verify the pin configuration with show-pins since I don't know whether this u-boot configures sane defaults. if it doesn't then disabling &cape_pins is not okay and I'll need to give an alternative to that Jun 02 02:21:12 ok will do Jun 02 02:21:24 ehm, what did you do? the v4.14.x-ti branch most definitely does have src/arm/am5729-beagleboneai.dts Jun 02 02:21:44 my bbai-custom.dts compiles fine in that branch for me Jun 02 02:21:56 hrm Jun 02 02:22:11 Your branch is up to date with 'origin/v4.14.x'. Jun 02 02:22:21 missing -ti Jun 02 02:22:32 v4.14.x-ti Jun 02 02:22:52 ahhh crap didn't notice that Jun 02 02:22:54 2 sec Jun 02 02:25:32 canbus: I've also added a small thing to the top of my dts: https://pastebin.com/raw/qbEZXd3p Jun 02 02:26:15 setting the /chosen/base_dtb property to indicate the name of the dts file (to make it easy to determine at runtime which dts you've loaded) Jun 02 02:26:35 rebooting now Jun 02 02:26:37 fingers crossed Jun 02 02:27:04 I'm also curious if it'll show up as can0, can1, or can2 Jun 02 02:27:14 all three options seem possible to me Jun 02 02:27:49 debian@beaglebone:~$ dmesg | grep -ie can Jun 02 02:27:55 yah i'm not sure about that either Jun 02 02:28:00 oh sweet nice edit Jun 02 02:28:04 it booted! Jun 02 02:29:01 nothing in ifconfig by default Jun 02 02:29:04 show-pins output? Jun 02 02:29:09 oh that's not good Jun 02 02:29:32 then also kernel log please... if you have internet access on the bbai you can just do: journalctl -k | pastebinit Jun 02 02:30:36 https://pastebin.com/iymmihx6 Jun 02 02:31:02 not good! u-boot still doesn't set sane defaults! Jun 02 02:32:19 https://pastebin.com/sAWiXLtM Jun 02 02:32:39 cool! i didn't know you could just hook it into pastebin like that Jun 02 02:32:51 got an error Failed to contact the server: HTTP Error 503: Service Unavailable but manually pasted above Jun 02 02:33:46 I've updated https://pastebin.com/raw/qbEZXd3p with an alternative to at least fix the pins Jun 02 02:34:30 hmm, the kernel does say the pins are in use by the can controller, so the driver probed successfully Jun 02 02:34:53 ehm, what you pasted has truncated every line Jun 02 02:35:08 use journalctl -k --no-pager Jun 02 02:35:19 oh crap it is because of putty Jun 02 02:35:36 or try piping it into pastebinit -b pastebin.com Jun 02 02:35:51 (the default is paste.debian.net) Jun 02 02:35:55 (which is down) Jun 02 02:36:09 https://pastebin.com/mvXnRQKD Jun 02 02:36:18 wow that is supppper cool!! Jun 02 02:37:26 I'm not really seeing any error and it says can loaded... the "ip link" command shows no can interface? Jun 02 02:37:43 crap thermal shutdown again!!! arg. ok 2 sec i'm going to get a desktop fan to put on it Jun 02 02:37:55 try a non-TIDL image Jun 02 02:38:04 er actually let me try ip link. i only tried ifconfig Jun 02 02:38:14 ip link will show more Jun 02 02:38:44 or at least try moving/renaming the tidl-related files in /lib/firmware/ out of the way so they won't load Jun 02 02:39:29 ifconfig is a deprecated utility, "ip" is its replacement... I don't know anything about whether ifconfig works with can Jun 02 02:40:42 yah actually i created a virtual can device earlier and it didn't show up in ifconfig but did show up in ip link Jun 02 02:40:49 2 sec lemme cool it down Jun 02 02:40:57 ill switch over to a non-tidl Jun 02 02:41:02 meanwhile Jun 02 02:41:16 lemme check the name of the firmware files to move out of the way.. that's perhaps less effort than getting a new image Jun 02 02:41:54 oh wait they dont' have any available on beagleboard? Jun 02 02:42:03 i see flasher Jun 02 02:42:13 and older image Jun 02 02:42:39 yeah for some reason the main website only has a subset of images, the complete set can be found here: https://elinux.org/Beagleboard:Latest-images-testing Jun 02 02:43:26 weird Jun 02 02:43:27 ok so Jun 02 02:43:28 am57xx-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz Jun 02 02:43:53 that would be the non-tidl iot image yes Jun 02 02:46:01 note that it uses 4.19-ti kernel series instead of 4.14-ti Jun 02 02:46:38 sweet dont need to switch branch then Jun 02 02:46:53 ill copy it in anyway though just ot be sure lol Jun 02 02:47:11 "copy it in" ? Jun 02 02:47:24 type in Jun 02 02:47:28 "it" ? Jun 02 02:47:40 oh, selecting the branch Jun 02 02:47:41 git branch 4.19-ti Jun 02 02:47:54 that's not the branch name Jun 02 02:47:59 or whatever the branch specic name is Jun 02 02:48:13 booting Jun 02 02:48:21 when cloning the repo you can just do git clone -b v4.19.x-ti URL Jun 02 02:48:35 to select which branch to check out by default Jun 02 02:52:28 updating apt-get Jun 02 02:52:42 if you're feeling adventurous then another thing you can try to hopefully maybe reduce the heat produced by the bbai when idle is grab this utility I wrote: https://liktaanjeneus.nl/bbx15/omap5-cpu-prcm.tar.gz and run it as "sudo ./omap5-cpu-prcm --retention" ... it directly fiddles some hardware registers that _ought_ to be (but don't seem to be) configured correctly by the kernel. I disclaim any ... Jun 02 02:52:48 ...responsibility for side-effects (including data loss, spontaneous combustion, and tornados) caused by using this utility Jun 02 02:53:30 haha gotta love the disclaimer! Jun 02 02:53:40 have you tested it on your unit to see the thermal difference? Jun 02 02:53:53 ill definitly give it a try~! after the can stuff.. haha Jun 02 02:54:09 I don't remember... I did test it on the bbx15 and it had quite a noticable impact Jun 02 02:54:35 installing git Jun 02 02:54:59 cloning Jun 02 02:55:09 it allows the cpu to enter a lower power state when idle, so it won't help if you're trying to use 100% cpu load but generally a system is idle most of the time ;) Jun 02 02:55:17 git isn't installed by default? o.O Jun 02 02:55:27 that seems rather unlikely Jun 02 02:55:39 actually I'm quite sure it should be installed by default Jun 02 02:58:21 dang not finding dtc 2 sec need to find apt-get Jun 02 02:58:36 oi, the base_dtb property somehow got lost from https://pastebin.com/raw/qbEZXd3p when I fixed the pins.. re-added that Jun 02 02:58:44 huh, dtc not installed by default? wtf Jun 02 02:58:50 k got it Jun 02 02:58:59 oh good timing, just about to compile :) **** ENDING LOGGING AT Tue Jun 02 02:59:57 2020