**** BEGIN LOGGING AT Wed Apr 15 02:59:57 2020
Apr 15 08:39:47 <bbblob> Has anyone built and used arago on beagleboard X15?
Apr 15 09:12:58 <zmatt> bbblob: TI's Processor SDK for Linux is arago-based so yes, there will be lots of people (note that the bbx15 is simply the base board of the am572x EVM)
Apr 15 11:27:48 <johanhenselmans> Gi17na20
Apr 15 11:34:19 <johanhenselmans> Oops, wrong screen, sorry.
Apr 15 11:52:47 <humpelstilzchen[> I would not be able to remember that password
Apr 15 11:57:47 <veremitz> everybody courtesy /clear ;P lol
Apr 15 12:28:21 <zmatt> more like time to change that password :P
Apr 15 12:28:49 <zmatt> humpelstilzchen[: for most things I use random passwords and store them, it's more secure than having one password you remember and using it everywhere
Apr 15 12:33:49 <veremitz> zmatt: the only problem is single-point-of-failure where you store them .. unless you store them in multiple places, but then you just shift the problem
Apr 15 12:34:09 <veremitz> I'm not sure there is a human-compatible answer to the security dilemma
Apr 15 12:35:00 <zmatt> I keep a backup of that file in a reasonably secure location
Apr 15 12:38:55 <zmatt> well there are ways (that have been known for decades but aren't used) to make the problem far less problematic.  for example, if we universally used password-authenticated key agreement (which we could have, if it were an integral part of TLS, implemented in all browsers and servers and everything had been done to encourage its use)
Apr 15 12:39:22 <zmatt> then at least phishing wouldn't be a thing
Apr 15 12:40:27 <zmatt> (and a password db stolen from a server would stlil require cracking before you could use the passwords to authenticate to services)
Apr 15 12:43:27 <veremitz> the 'obvious' answers seem to elusive to achieve :/
Apr 15 12:43:32 <veremitz> to be*
Apr 15 12:45:02 <zmatt> it's just annoying when certain specific security issues do have known good solutions, and have been known for a long time, but almost nobody has picked up on them or implemented them
Apr 15 12:46:30 <zmatt> one paka protocol made it as far as getting an RFC and being implemented in openssl, but that implementation wasn't enabled or used by anyone and I think it's now been dropped from the library
Apr 15 12:46:53 <zmatt> *sigh*
Apr 15 12:47:40 <veremitz> or people implement shit basic security (8-10 char pwds, only lower-case alpha+num., etc) :/
Apr 15 12:48:31 <zmatt> yeah things that impose restrictions on password length or what type of chars you're allowed to use are reaaaly dumb
Apr 15 12:49:04 <zmatt> and you should definitely use a unique random password for those, given that they're probably not storing the password in hashed form
Apr 15 12:49:15 <veremitz> ugh really :/
Apr 15 12:49:31 * veremitz makes a note
Apr 15 12:50:02 <zmatt> if all you do with a password is stick it into a password hasing function, there's no reason to restrict the length or character set
Apr 15 12:50:47 <veremitz> *nod*
Apr 15 12:50:53 <zmatt> most likely those restrictions are due to the password going straight into a database column
Apr 15 12:51:00 <veremitz> vile
Apr 15 12:51:07 <MattB0ne> zmatt are there stock overlay files that have the uarts opened?
Apr 15 12:51:17 <veremitz> should be
Apr 15 12:51:31 <zmatt> MattB0ne: ls /lib/firmware/*UART*
Apr 15 12:53:27 <zmatt> MattB0ne: as for your earlier remark.  if you want to modify an overlay, make a copy of the orignal source file (don't modify the original), modify it, compile it, and optionally place it in /lib/firmware (taking care not to replace any existing files there, use a non-conflicting name)
Apr 15 12:54:07 <zmatt> note however that if you want to make overlays, you may find my overlay-utils and its examples friendlier than bb.org-overlays
Apr 15 12:55:52 <MattB0ne> the dtbo files are compiled already
Apr 15 12:56:12 <MattB0ne> so i just need to tell the boot sequence to use the file?
Apr 15 12:56:16 <zmatt> for example, here's an overlay for uart4 in overlay-utils:  (the four lines that are commented out are for hardware flow control):
Apr 15 12:56:19 <zmatt> https://github.com/mvduin/overlay-utils/blob/master/uart4.dtsi
Apr 15 12:56:32 <zmatt> versus one in bb.org-overlays:
Apr 15 12:56:34 <zmatt> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART4-00A0.dts
Apr 15 12:56:58 <zmatt> dtbo files are compiled overlays yes
Apr 15 12:57:14 <MattB0ne> yeah that is more than what I need
Apr 15 12:57:32 <MattB0ne> I just need pins switched to Rx and Tx without me manually doing it every time
Apr 15 12:59:24 <zmatt> I mean, if you're using cape-universal then software can obviously also just configure the pins are boot.  but using an overlay is also an option
Apr 15 13:01:16 <zmatt> so just configure the path to the overlay (either a stock one or a custom one) into /boot/uEnv.txt .. it has five variables available for configuring general overlays:  uboot_overlay_addr4..7 and dtb_overlay
Apr 15 13:04:17 <veremitz> does it matter what kernel dtbo's are built with? or are the headers generic enough?
Apr 15 13:04:51 <zmatt> overlays compiled for kernel 3.8 won't work, it used an older dtc which produced overlays with a different structure
Apr 15 13:05:15 <zmatt> also, it used different labels for some peripherals (1-based numbering instead of 0-based numbering), including uarts I think
Apr 15 13:05:25 <zmatt> so it's not even source-compatible
Apr 15 13:07:19 <zmatt> and generally DT structure remains fairly stable, and the differences between kernels are usually not significant for overlays (with rare exceptions, such as the overlay for remoteproc-pru, which has changed for every major kernel version)
Apr 15 13:08:03 <MattB0ne> should I put my entry on the bottom
Apr 15 13:08:57 <MattB0ne> also I saw my LCD has a dto file possibly BB-BONE-NH7C-01-A0.dtbo
Apr 15 13:09:12 <MattB0ne> I checked I do not have it loaded but it appears to work
Apr 15 13:09:39 <MattB0ne> https://pastebin.com/Wy6LgBE7
Apr 15 13:09:46 <zmatt> if you're using a standard lcd cape then the correct overlay should be auto-loaded
Apr 15 13:11:19 <MattB0ne> yeah it seems it did
Apr 15 13:11:25 <MattB0ne> that last entry
Apr 15 13:11:42 <zmatt> so why did you say "I checked I do not have it loaded"
Apr 15 13:11:54 <zmatt> when it says right there it's loaded
Apr 15 13:12:34 <MattB0ne> it looked different from BB-BONE-NH7C-01-A0.dtbo
Apr 15 13:12:41 <zmatt> ??
Apr 15 13:12:45 <MattB0ne> i saw in the overlay docs on elinux
Apr 15 13:13:03 <zmatt> what docs?
Apr 15 13:13:13 <MattB0ne> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
Apr 15 13:14:08 <zmatt> .. what are you referencing in that section?  I don't understand what you're trying to say
Apr 15 13:14:40 <MattB0ne> moot point but they had a section U-Boot Capes added
Apr 15 13:15:17 <zmatt> ?  what about it?
Apr 15 13:15:33 <MattB0ne> I didnt think it would autoload
Apr 15 13:15:43 <MattB0ne> did not look carefully enough
Apr 15 13:15:44 <zmatt> that's how cape overlays are supposed to work
Apr 15 13:16:07 <MattB0ne> I havent done anything with overlays yet and got worried
Apr 15 13:16:27 <zmatt> it uses i2c to detect the cape and read its identifier, and then loads the appropriate overlay from /lib/firmware
Apr 15 13:16:42 <zmatt> ("it" being u-boot nowadays)
Apr 15 13:17:05 <MattB0ne> so if I hadd /lib/firmware/BB-UART3-00A0.dtbo
Apr 15 13:17:21 <MattB0ne> sucks that it consumes the i2c port
Apr 15 13:17:30 <MattB0ne> there is only one on the board
Apr 15 13:18:27 <MattB0ne> add*
Apr 15 13:19:20 <zmatt> it doesn't "consume" the i2c bus since you can attach multiple devices to i2c
Apr 15 13:19:30 <zmatt> also, there are multiple i2c busses
Apr 15 13:20:07 <zmatt> note btw that uart3 rxd is not available on the bbb expansion header
Apr 15 13:20:17 <zmatt> it's the only uart which is therefore tx-only
Apr 15 13:20:58 <MattB0ne> would the LCD cape consume i2c per the documentation that came with my cape they do not have those pins available
Apr 15 13:21:24 <MattB0ne> I was planning on using UART4 and UART1
Apr 15 13:21:32 <MattB0ne> so just adding those dtbo files
Apr 15 13:21:52 <MattB0ne> BB-UART1-00A0.dtbo
Apr 15 13:21:55 <MattB0ne> BB-UART4-00A0.dtbo
Apr 15 13:22:13 <zmatt> which cape is this? is its schematic available?
Apr 15 13:22:53 <MattB0ne> NHD-7.0CTP-CAPE-V
Apr 15 13:22:59 <MattB0ne> from newhaven display
Apr 15 13:23:06 <MattB0ne> https://www.newhavendisplay.com/userguides/NHD-7.0CTP-CAPE_User_Guide.pdf
Apr 15 13:23:32 <MattB0ne> they have an expansion header map
Apr 15 13:23:34 <MattB0ne> in the guide
Apr 15 13:25:49 <zmatt> it doesn't seem to match the schematic
Apr 15 13:26:17 <zmatt> oh they just labeled too many thing in the image
Apr 15 13:26:33 <zmatt> (but omitted them from the list next to it)
Apr 15 13:28:10 <zmatt> it seems to pass through everything except: P9.14, P9.27, P8.11-19, P8.27-46
Apr 15 13:29:10 <zmatt> (it even passes through the eMMC pins, which seems like a bad idea since attaching long stub traces to those pins could degrade signal integrity)
Apr 15 13:29:15 <MattB0ne> so UART4 which i was using previously is on P9.11 and p9.13
Apr 15 13:29:21 <MattB0ne> so it is safe to use
Apr 15 13:29:25 <zmatt> yep those are fine
Apr 15 13:29:57 <veremitz> zmatt: if I had a dollar/euro/etc .. :P~ "it even passes through the eMMC pins, which seems like a bad idea.."
Apr 15 13:29:59 <MattB0ne> so i can just add /lib/firmware/BB-UART4-00A0.dtbo
Apr 15 13:30:14 <MattB0ne> to the uEnv.txt
Apr 15 13:30:25 <MattB0ne> at the bottom?
Apr 15 13:30:29 <zmatt> MattB0ne: you can configure that into one of the five variables I mentioned if you want to use that overlay
Apr 15 13:30:46 <zmatt> none of which are at the bottom, they're closer to the top I think (commented out)
Apr 15 13:31:33 <zmatt> so... remind me again why exactly you're using overlays instead of config-pin?  I get the feeling using config-pin would be easier for you
Apr 15 13:32:36 <MattB0ne> I am running a c++ application
Apr 15 13:32:58 <MattB0ne> and this was to change the pins to UART so I can communicate to external controllers
Apr 15 13:33:05 <MattB0ne> you said either way
Apr 15 13:33:05 <zmatt> .. okay, and?
Apr 15 13:33:18 <zmatt> I mean overlays work too
Apr 15 13:33:24 <MattB0ne> overlays were more permanent
Apr 15 13:33:45 <MattB0ne> um that was really it. I am using serial communication to talk to the other boards
Apr 15 13:34:08 <zmatt> using an overlay will get the uart configured a bit earlier than using config-pin at boot.  does that matter?
Apr 15 13:34:31 <zmatt> either is fine, it just sounds like you're finding overlays a hassle, hence I was wondering
Apr 15 13:34:38 <MattB0ne> I do not think so though eventually I would want to have this directly boot into my application
Apr 15 13:35:00 <veremitz> overlays aren't complicated
Apr 15 13:35:12 <veremitz> (unless you make them so... :P)
Apr 15 13:35:17 <MattB0ne> veremitz: i am very very new to this
Apr 15 13:35:20 <MattB0ne> I think I got it
Apr 15 13:35:22 <MattB0ne> though
Apr 15 13:35:35 <veremitz> beats having to hard config in source/board configs
Apr 15 13:35:40 <zmatt> veremitz: even making them isn't very complicated
Apr 15 13:35:40 <veremitz> ugh happy days
Apr 15 13:35:44 <zmatt> lol
Apr 15 13:35:44 <veremitz> zmatt: right?!
Apr 15 13:35:53 <MattB0ne> geez guys
Apr 15 13:35:59 <MattB0ne> doing wonders for my self esteem here
Apr 15 13:36:01 <MattB0ne> lol
Apr 15 13:36:09 <veremitz> and -finding- the damn config amongst the mess of a normal board config file .. lol.
Apr 15 13:36:14 <MattB0ne> I am taking slots 4 and 5 for this
Apr 15 13:36:14 <zmatt> MattB0ne: lol, no don't worry.. DT intimidates most people
Apr 15 13:36:14 <veremitz> MattB0ne: yeah I do kinda appreciate that
Apr 15 13:36:30 <veremitz> its not the most elegant system, but its an improvement on What Went Before.
Apr 15 13:37:04 <veremitz> invariably when yo have your fingers burnt a few times, you do become a little jaded :D
Apr 15 13:37:35 <zmatt> and the structure of overlays is just ugly... I don't understand why you're forced to write that structure out manually instead of dtc generating it for you... my overlay-utils uses a tiny perl script to preprocess the source code into the structure requires for an overlay, dtc could have done that for you instead... but it doesn't
Apr 15 13:38:06 <veremitz> zmatt: you wouldn't have created that beautiful perl script otherwise ;P
Apr 15 13:38:18 <veremitz> nor many of the other excellent tools :p
Apr 15 13:38:30 <zmatt> it's not.  like most perl scripts (at least the ones I've written), it's hideous
Apr 15 13:38:36 <zmatt> but it gets the job done
Apr 15 13:38:37 <veremitz> its perl :p
Apr 15 13:39:15 * GenTooMan makes no comment about perl and leaves it at that.
Apr 15 13:39:43 <zmatt> hey, perl scripts *can* be nice... I think
Apr 15 13:40:06 <zmatt> at least nicer than stubbornly continueing to try to do the same thing with bash scripting
Apr 15 13:40:42 <zmatt> *continuing
Apr 15 13:41:16 <GenTooMan> Sorry the spelling police are eating bakery goods with proper social distancing.
Apr 15 13:42:20 <zmatt> perl shines at processing text though, I'm pretty sure this script would have required a lot more code in any other language
Apr 15 13:42:40 <veremitz> its Perl ;p
Apr 15 13:42:48 * veremitz hopes not a third time :D
Apr 15 13:43:39 <GenTooMan> that's what perl was originally intended for so... yes text processing it can do. Before perl there was sed. :D
Apr 15 13:43:51 <veremitz> ^ this
Apr 15 13:44:16 <zmatt> it's pretty decent at binary data too (way more so than python)
Apr 15 13:44:20 <veremitz> "Practical Extraction and Reporting Language"
Apr 15 13:44:40 <MattB0ne> I just need to reboot after the edit right?
Apr 15 13:45:11 <zmatt> veremitz: that's a backronym.  perl isn't an abbreviation
Apr 15 13:45:30 <zmatt> MattB0ne: yes
Apr 15 13:45:59 <GenTooMan> zmatt but you can't forget it even if it's wrong
Apr 15 13:46:04 <veremitz> zmatt: yeah I know
Apr 15 13:46:09 <veremitz> ^ that
Apr 15 13:47:08 <zmatt> lol... "It has been nicknamed "the Swiss Army chainsaw of scripting languages" because of its flexibility and power, and also its ugliness.  In 1998, it was also referred to as the "duct tape that holds the Internet together," in reference to both its ubiquitous use as a glue language and its perceived inelegance."
Apr 15 13:47:21 <zmatt> -- wikipedia
Apr 15 13:48:00 <zmatt> I find its inelegance helpful.  it helps me to avoid getting stuck on trying to do something elegantly
Apr 15 13:48:08 <veremitz> lol
Apr 15 13:48:14 <veremitz> its about right though
Apr 15 13:48:14 <zmatt> like, if you use perl for the job, you're given up on that in advance
Apr 15 13:48:21 <veremitz> true ^
Apr 15 13:48:24 <zmatt> so the goal is just to get the job done
Apr 15 13:49:23 <zmatt> otherwise I often have trouble writing code that merely gets the job done... I worry too much about doing things Right, or worse yet, doing it elegantly
Apr 15 13:49:42 <zmatt> or efficiently, another productivity-killer
Apr 15 13:53:07 <MattB0ne> so I should be able to go into /dev/ttys4
Apr 15 13:53:09 <MattB0ne> and see UART
Apr 15 13:53:11 <MattB0ne> but it is blank
Apr 15 13:53:22 <zmatt> "go into" ?
Apr 15 13:53:34 <MattB0ne> view /dev/ttys4 with vim
Apr 15 13:53:40 <zmatt> ehm, no
Apr 15 13:53:44 <zmatt> that's not how serial ports work
Apr 15 13:53:52 <zmatt> also it's /dev/ttyS4
Apr 15 13:53:52 <MattB0ne> well check the pin status
Apr 15 13:54:05 <zmatt> you can't open a device in a text editor
Apr 15 13:54:11 <zmatt> that just makes no sense
Apr 15 13:54:26 <MattB0ne> wasnt the pin configurator just changing the value of a file
Apr 15 13:54:36 <MattB0ne> so you could see the switch
Apr 15 13:54:59 <zmatt> yes but that file will no longer exist now since runtime configuration is disabled for pins that are used by overlays
Apr 15 13:55:00 <GenTooMan> you just want to view the pin setting then?
Apr 15 13:55:21 <zmatt> one way to inspect your pinmux, regardless of how it was set, is using my show-pins utility: https://github.com/mvduin/bbb-pin-utils/#show-pins
Apr 15 13:59:28 <MattB0ne> ok how can test my serial real quick just connect the Tx and Rx and echo throguh it?
Apr 15 14:01:33 <zmatt> I think there's *some* possibility that might work if you do "cat /dev/ttyS4" in one window and "echo foo >/dev/ttyS4" in another, but I'm not sure, if echo is enabled it'll end up sending data in a loop continuously
Apr 15 14:03:56 <zmatt> I'd probably test it with "screen /dev/ttyS4 115200 -crtscts" (use control-A control-K to exit.  don't merely close your ssh connection, screen will remain running in the background if you do that)
Apr 15 14:07:08 <MattB0ne> ok
Apr 15 14:10:27 <GenTooMan> wow screen deja vous
Apr 15 14:11:34 <MattB0ne> so I should open another terminal and echo into it
Apr 15 14:11:44 <MattB0ne> after entering that command I have a blank screen
Apr 15 14:11:46 <MattB0ne> cannoot type
Apr 15 14:11:53 <zmatt> "cannot type" means the serial port isn't working
Apr 15 14:11:56 <MattB0ne> blinking cursor though
Apr 15 14:12:13 <zmatt> or your loopback connection isn't working
Apr 15 14:12:28 <zmatt> it should transmit when you type, and display anything it receives
Apr 15 14:13:39 <MattB0ne> hmm
Apr 15 14:14:16 <zmatt> so on an unconnected serial port you'd indeed see anything happening (even if you type), but if you have a loopback connection from txd to rxd then you should see what you type
Apr 15 14:15:59 <zmatt> did you confirm (using show-pins as I mentioned above, or using rcn's version.sh) that the uart overlay has indeed been applied?
Apr 15 14:21:47 <MattB0ne> used your pin think
Apr 15 14:21:58 <MattB0ne> here is what I have for P9.11 and P9.13
Apr 15 14:21:58 <MattB0ne> https://pastebin.com/sJuJpxBZ
Apr 15 14:22:15 <zmatt> in other words it didn't apply
Apr 15 14:22:26 <zmatt> so you probably did something wrong in /boot/uEnv.txt
Apr 15 14:22:35 <MattB0ne> LOL
Apr 15 14:22:43 <MattB0ne> i will paste my file
Apr 15 14:22:49 <MattB0ne> cant get right
Apr 15 14:24:45 <MattB0ne> https://pastebin.com/s4A52CY5
Apr 15 14:24:51 <MattB0ne> is my uEnv.txt
Apr 15 14:25:00 <zmatt> you left the lines commented out
Apr 15 14:25:08 <zmatt> any line that starts with # is ignored
Apr 15 14:26:10 <MattB0ne> doh!
Apr 15 14:26:15 <zmatt> some syntax highlighting is quite illustrative: https://pastebin.com/wUZjUAPL  (bash syntax highlighting isn't quite right for this, but it's close enough)
Apr 15 14:30:29 <MattB0ne> still not taking it seems
Apr 15 14:30:29 <MattB0ne> https://pastebin.com/L676uDWM
Apr 15 14:30:39 <MattB0ne> with the lines uncommneted
Apr 15 14:31:30 <zmatt> you did reboot?
Apr 15 14:31:37 <MattB0ne> yup twice
Apr 15 14:31:46 <MattB0ne> just to make sure
Apr 15 14:31:52 <zmatt> what does version.sh say about which overlays have been applied?
Apr 15 14:33:42 <MattB0ne> where is version.sh
Apr 15 14:33:50 <zmatt> you used it earlier
Apr 15 14:33:59 <MattB0ne> i used your pin script
Apr 15 14:34:59 <zmatt> 15:09 < MattB0ne> https://pastebin.com/Wy6LgBE7
Apr 15 14:35:45 <MattB0ne> your right
Apr 15 14:35:47 <MattB0ne> not applied
Apr 15 14:36:00 <MattB0ne> still the same four entries as earlier
Apr 15 14:36:25 <MattB0ne> https://pastebin.com/e86mWxDY
Apr 15 14:36:42 <zmatt> oh I also just noticed you wrote ".dtbo.dtbo" as file suffix
Apr 15 14:36:50 <zmatt> which is one .dtbo too many
Apr 15 14:36:56 <zmatt> :P
Apr 15 14:37:41 <MattB0ne> rebooting
Apr 15 14:37:45 <MattB0ne> hopefully that is it
Apr 15 14:37:51 <MattB0ne> you figure they would put an error
Apr 15 14:37:55 <MattB0ne> rather than ignore
Apr 15 14:38:07 <MattB0ne> i guess they are assuming the user is better than I
Apr 15 14:38:08 <MattB0ne> lol
Apr 15 14:38:30 <zmatt> be glad it didn't, since u-boot's way of "giving an error" would typically be to fail to boot your system entirely
Apr 15 14:39:28 <MattB0ne> SUCCESS!!!
Apr 15 14:39:33 <MattB0ne> thank you kind sir
Apr 15 14:39:46 <MattB0ne> I will now stop pestering you and find some other way to screw up
Apr 15 14:40:33 <veremitz> haha
Apr 15 14:40:34 <zmatt> I have faith you'll manage to
Apr 15 14:40:37 <veremitz> keep learning ;)
Apr 15 15:04:48 <bbblob> Does arago bring the KVM kernel modules for beagleboard, or how can one use system emulation on beagleboard? I need to run nios flash programmer on it?
Apr 15 15:14:15 <veremitz> you don't want to run emulation on a single-core ARM computer. Period.
Apr 15 15:32:42 <bbblob> Have you got an other idea how to flash an altera fpga from beaglebone?
Apr 15 15:33:12 <bbblob> flashrom I crossed while surfing - any experience?
Apr 15 15:39:09 <veremitz> if the tool runs under linux .. there shouldn't be a problem .. although I have precious little experience with low-end FPGAs .. I Was working with Xilinx ones about 20 years ago ..
Apr 15 15:53:48 <bbblob> Time passe by to fast.... the same to me...! yes, it runs under linux but it is prcompiled for x86_64 that is the problem
Apr 15 16:13:09 <zmatt> then kvm would also be useless
Apr 15 16:13:14 <zmatt> you'd need to run it under qemu
Apr 15 16:14:34 <veremitz> can you access it's source? and cross-compile to ARM?
Apr 15 16:14:51 <veremitz> zmatt: ugh :p don't go there
Apr 15 16:16:17 <zmatt> veremitz: why not? if it's a simple utility that operates via an uart, using qemu-user might be fine
Apr 15 16:45:44 <veremitz> mkay .. are the binaroes for qemu-iser around?
Apr 15 16:45:48 <veremitz> oops typo hell
Apr 15 16:45:57 <zmatt> sudo apt-get install qemu-user
Apr 15 16:46:01 <veremitz> cool
Apr 15 16:46:22 <zmatt> if you also have binfmt-support installed then you can just run x86 programs with ./program
Apr 15 16:46:43 <zmatt> ah sorry, you need qemu-user-binfmt for that
Apr 15 16:47:04 <zmatt> (which depends on qemu-user and binfmt-support)
Apr 15 16:50:20 <rproc_user> I downloaded the latest image for the BeagleBone Black WiFi (10.3 Buster IoT (without graphical desktop)). I'm having issues with the PRU. When I try and stop the PRU by doing echo 'stop' > /sys/class/remoteproc/remoteproc2/state  I get an operation not permitted error. Did something change in 10 with interacting with the PRU?
Apr 15 16:50:41 <zmatt> what's its current state?
Apr 15 16:50:48 <rproc_user> Says running
Apr 15 16:51:26 <zmatt> readlink -e /sys/class/remoteproc/remoteproc2
Apr 15 16:52:26 <zmatt> (just to double-check that remoteproc2 is still the correct device to use)
Apr 15 16:53:57 <rproc_user> "/sys/devices/platform/ocp/ocp:l4_wkup@44c00000/44d00000.wkup_m3/remoteproc/remoteproc2/state"
Apr 15 16:54:07 <zmatt> that's not pru
Apr 15 16:54:20 <zmatt> that's the wakeup m3
Apr 15 16:55:11 <zmatt> hardcoding something like /sys/class/remoteproc/remoteproc2 is just a bad idea... the kernel will assign those numbers just in whatever order it happens to encounter the devices
Apr 15 16:55:21 <rproc_user> Yup, looks like they changed it to 0 and 1 now instead of 1 and 2
Apr 15 16:55:43 <zmatt> they're not deliberately assigned any particular numbering by anyone, it's just arbitrarily decided at runtime
Apr 15 16:56:21 <rproc_user> So to find the pru I should be using readlink in my scripts?
Apr 15 16:56:32 <rproc_user> Or is there a better way to always find PRU1
Apr 15 16:57:19 <zmatt> I don't use remoteproc-pru myself, I use uio-pruss, and for that I created a udev rule that creates symlinks to the uio devices to allow them to be located easily
Apr 15 16:57:35 <zmatt> (and I do a similar thing for gpios)
Apr 15 16:57:43 <zmatt> a similar principle should be possible for remoteproc-pru
Apr 15 16:58:50 <zmatt> or, without a udev rule, you could scan for it using libudev (or some wrapper thereof), or locate all instances of a particular driver (in /sys/bus/platform/drivers/$driver/ )
Apr 15 16:59:21 <zmatt> I don't know the driver name in this case but it shouldn't be hard to find, (just check what the 'driver' links to for the other two remoteproc devices)
Apr 15 17:00:01 <zmatt> using a udev rule is definitely the cleanest solution.  I'm surprised none exists for this by default (assuming that's indeed the case)
Apr 15 17:00:02 <rproc_user> Alright, thank you for the help. That was very informative!
Apr 15 17:00:29 <rproc_user> I will look into the udev rules. Thanks again.
Apr 15 17:01:00 <zmatt> you can find some examples of existing custom udev rules in /etc/udev/rules.d/
Apr 15 17:06:01 <MattB0ne> zmatt: does this mean my pins are setup correctly https://pastebin.com/pLKD4UJg
Apr 15 17:06:14 <MattB0ne> I tried to do the screen thing still cannot type
Apr 15 17:06:18 <zmatt> yep, looks good
Apr 15 17:06:26 <MattB0ne> but I do see the overlay getting pulled in and stuff
Apr 15 17:06:36 <MattB0ne> i also tried the two terminal think
Apr 15 17:06:41 <zmatt> you've externally connected the txd line to rxd with a wire?
Apr 15 17:06:51 <MattB0ne> thing where I echo in one screen and cat in the other
Apr 15 17:06:54 <MattB0ne> yes
Apr 15 17:07:11 <MattB0ne> triple checked the mapping
Apr 15 17:07:14 <zmatt> you've also been properly closing your screens like I said and not left them running?  (check with screen -ls )
Apr 15 17:07:22 <MattB0ne> so 11 and 13
Apr 15 17:08:02 <MattB0ne> No Sockets found in /run/screen/S-debian.
Apr 15 17:08:34 <zmatt> yep, so the 6th and 7th pin from the top in the leftmost column of the leftmost header if the bbb is oriented such that the ether connector is facing away from you
Apr 15 17:08:49 <zmatt> *ethernet
Apr 15 17:13:17 <MattB0ne> ok maybe it was working but was just going crazy
Apr 15 17:13:21 <MattB0ne> redid it
Apr 15 17:13:38 <MattB0ne> i sent echos to it
Apr 15 17:13:47 <MattB0ne> before screen would that be in the back log or something
Apr 15 17:14:10 <zmatt> ?
Apr 15 17:14:12 <MattB0ne> and when screen is run it takes all that input?
Apr 15 17:14:47 <MattB0ne> well I echoed "hello" to /dev/ttyS4
Apr 15 17:14:50 <zmatt> I actually have no idea if input is buffered if no application has the device open
Apr 15 17:14:51 <MattB0ne> before running screen
Apr 15 17:15:21 <MattB0ne> [screen is terminating]
Apr 15 17:15:35 <MattB0ne> but no sockets found when you run screen -ls
Apr 15 17:15:45 <MattB0ne> how long does it take to stop a screen session
Apr 15 17:15:45 <zmatt> yeah that's the desired thing
Apr 15 17:16:00 <zmatt> what?
Apr 15 17:16:02 <zmatt> none
Apr 15 17:16:27 <MattB0ne> if I try and launch another session with screen /dev/ttyS4 115200 -crtscts
Apr 15 17:16:39 <MattB0ne> i get [screen is terminating]
Apr 15 17:16:47 <MattB0ne> but if I run screen -ls
Apr 15 17:16:56 <MattB0ne> No Sockets found in /run/screen/S-debian.
Apr 15 17:16:57 <zmatt> then it's failing to open the device I guess?
Apr 15 17:17:06 <zmatt> yeah since it terminated
Apr 15 17:17:09 <MattB0ne> reboot
Apr 15 17:17:11 <MattB0ne> ?
Apr 15 17:17:24 <zmatt> I don't know, I don't know what you did or what's happening so I can't guess solutions either
Apr 15 17:17:34 <MattB0ne> sort of worked
Apr 15 17:17:39 <MattB0ne> let me reboot
Apr 15 17:20:17 <MattB0ne> ok it is working reboot did it
Apr 15 17:22:31 <MattB0ne> are there more permanent ways of hooking up to female headers
Apr 15 17:22:46 <zmatt> male headers
Apr 15 17:23:02 <MattB0ne> i am using jumper cables but once I get everything nailed down I would want some more secure
Apr 15 17:23:21 <zmatt> the bigger the header, the more secure it is
Apr 15 17:23:51 <MattB0ne> and you just solder to the header?
Apr 15 17:24:39 <zmatt> if you just have a small thingy that you want to connect to some pins, then yeah we've done that
Apr 15 17:25:36 <zmatt> though in most cases we have a custom pcb for a product with two full 2x23 pin headers that the BBB plugs into
Apr 15 17:26:04 <zmatt> (which is very secure, in fact it can be quite a PITA to remove the BBB from that)
Apr 15 17:32:35 <MattB0ne> yeah I think I will stick with the mail headers
Apr 15 17:32:40 <MattB0ne> not to many connections to make
Apr 15 17:32:53 <zmatt> *male
Apr 15 17:33:00 <zmatt> mail headers are what you find at the top of an email :P
Apr 15 17:33:26 <MattB0ne> lol
Apr 15 17:33:38 <MattB0ne> do you need permission to be added to /dev folder?
Apr 15 17:33:44 <MattB0ne> like I needed to add debian to input
Apr 15 17:33:52 <MattB0ne> is there an output group
Apr 15 17:34:13 <zmatt> why? it didn't sound like you had any permission errors
Apr 15 17:34:34 <zmatt> the debian user is already in pretty much every group
Apr 15 17:34:49 <MattB0ne> added some more code that is now interfacing the UARTs I just set up
Apr 15 17:35:43 <MattB0ne> i get a permission error failing to open tty
Apr 15 17:35:54 <MattB0ne> which my only guess is the UART since that is all that I added
Apr 15 17:36:32 <zmatt> why would you have to guess?  if you're opening the uart then you're presumably logging the error yourself
Apr 15 17:37:07 <zmatt> and if you could previously open the serial port using screen or cat, then you don't have any permission issues with the serial port
Apr 15 17:37:18 <MattB0ne> yeah this is with qt
Apr 15 17:37:25 <zmatt> that doesn't matter
Apr 15 17:37:26 <MattB0ne> may be something with that
Apr 15 17:37:40 <MattB0ne> it appears to work since if I launch myself it is fine
Apr 15 17:37:45 <MattB0ne> no errors
Apr 15 17:37:51 <MattB0ne> i will leave that can of worms alone
Apr 15 17:37:52 <zmatt> as opposed to?
Apr 15 17:38:01 <MattB0ne> well in both instances it runs
Apr 15 17:38:20 <zmatt> you've completely lost me again
Apr 15 17:38:29 <MattB0ne> just I see Qtcreator spitting out failed to open tty error
Apr 15 17:38:35 <MattB0ne> I am gonna ignore for now
Apr 15 17:38:57 <MattB0ne> forget I said anything
Apr 15 21:13:31 <bbblob> @zmatt KVM is a qemu switch to activate or not and increases the emualtion performance drastically
Apr 15 21:13:51 <zmatt> bbblob: KVM is for virtualization, not emulation
Apr 15 21:14:17 <zmatt> to run a program for another architecture you need emulation but have absolutely no need for virtualization
Apr 15 21:15:27 <zmatt> there is some overlap between full-system emulation and virtualization (in terms of emulating hardware peripherals) but that's about it
Apr 15 21:15:55 <zmatt> there's zero overlap in functionality between cross-architecture emulation of userspace executables (which is what qemu-user does) and same-architecture virtualization (which is what kvm does)
**** ENDING LOGGING AT Thu Apr 16 02:59:57 2020