**** BEGIN LOGGING AT Tue Nov 08 02:59:56 2022 Nov 08 03:38:33 I found pep-0008, @zmatt. Phew. Nov 08 03:38:40 Dang it. Sorry. Nov 08 03:38:49 I forget. No python3 jargon in here. Nov 08 04:23:13 I'm trying to use pru setup from a cloud9 example blinkExternalLed.pru0.c and am getting an error: 'writing "gpio" to "/sys/devices/platform/ocp/ocp:P9_14_pinmux/state" Nov 08 04:24:50 How can I configure my board to make the P9_14_pinmux directory? Nov 08 11:09:55 BBBlue will fly! Trust it. Nov 08 11:10:27 It is driving me sensorless. Nov 08 11:45:14 Hello Nov 08 11:45:38 olay! Nov 08 11:46:12 Is there a way I can access my beaglebone as a folder from windows? Nov 08 11:49:08 Yes. Nov 08 11:49:42 online. Nov 08 11:50:00 Do you have an Ethernet cable or USB shared network? Nov 08 11:50:18 I use a usb to share internet from my pc to a pocket beagle Nov 08 11:50:29 Okay! Nov 08 11:50:34 We are in business. Nov 08 11:51:00 Can you install files and post files via git or however? Nov 08 11:51:12 I did try to use samba to do this since I have done with a pi before, but I ended up not being able to do ssh. Since I don't much, I just reflashed the sd Nov 08 11:51:33 Since I don't know much* Nov 08 11:51:44 Yeah, I can download git Nov 08 11:51:52 You do not need it. Nov 08 11:52:19 I was just making sure you could in case I did not understand that you have Internet access on your Pocket beagle. Nov 08 11:52:41 I have, I already download some repositories from git Nov 08 11:52:49 downloaded* Nov 08 11:52:54 Okay. Good. Nov 08 11:53:07 That means, you can access files online. That is a start. Nov 08 11:53:26 I am turning on my beagle now. Nov 08 11:53:50 I will do it and brb. This way, I can make sense out of what I am saying. Nov 08 11:56:15 Go to 192.168.7.2 Nov 08 11:56:39 That should do it! Nov 08 11:57:16 hello Nov 08 11:57:23 but doesn't that just opens the cloud9? Nov 08 11:57:40 That is odd. Mine does not even open Cloud9. What image do you use and what kernel? Nov 08 11:58:07 uart0_person: I have a book somewhere. I will have to research this idea more. Nov 08 11:59:00 I used this one from the beaglebone website Nov 08 11:59:01 AM3358 Debian 10.3 2020-04-06 4GB SD IoT Nov 08 11:59:25 Do you know about their forums? Nov 08 11:59:36 Yeah, I used them sometimes Nov 08 11:59:49 They have updated images but I cannot say for sure that it will work. Nov 08 11:59:54 I need to research more. Nov 08 12:01:16 How do I know if the BBB is booting from the microSD card or the eMMC ? Nov 08 12:01:26 are there more recent images than the ones advised on the website? Nov 08 12:01:33 Yes! Nov 08 12:07:31 so to you set, going into that ip address allows you to access the pocket as a folder in windows instead of showing cloud9 Nov 08 12:07:34 ? Nov 08 12:08:36 yes. Nov 08 12:08:44 weird Nov 08 12:10:05 I have three files. Nov 08 12:10:16 All of which are not working b/c I removed them! Nov 08 12:10:48 Well, I stopped the services that lead to their working behavior. Nov 08 12:11:27 yeah, I tried going to the ip address through file explorer, it sent me to cloud9 again Nov 08 12:11:57 uart0_person: Try to start yourself a .service file in /etc/systemd/system/. Then, boot it. That may work. Nov 08 12:12:31 If you know a code snippet to use, you can access your beagleboard.org am335x board from anywhere. Nov 08 12:13:20 what if I disable cloud9? Nov 08 12:13:47 It is more complicated than that...I think. Then cloud9 will cease! Nov 08 12:14:50 Ok, I i will try those things you advised Nov 08 12:15:18 also. Nov 08 12:15:21 ! Nov 08 12:15:54 Make sure you are using a ssh client w/ security and plus that file, it will need to be full of security features. Nov 08 12:18:55 Hello? Nov 08 12:19:05 Oh. it is me. Nov 08 12:25:35 up, up, and otay! Nov 08 14:06:55 Hello Nov 08 14:07:25 set_ Is this the place with the latest images? Nov 08 14:07:27 https://rcn-ee.com/rootfs/bb.org/testing/ Nov 08 14:09:56 uart0_person: if you're looking for the latest testing images, rcn posts them on the forum together with notes: https://forum.beagleboard.org/tag/latest-images ... the ARM64 one is for the bbai64 obviously, the other two threads have the latest bullseye and buster images for am335x and am572x Nov 08 14:10:17 oh thx Nov 08 14:10:18 uart0_person: btw to answer your earlier question, you can just transfer files via ssh/sftp... there are plenty of clients for that Nov 08 14:11:21 it's also not uncommon for IDEs to have support for remote editing files, e.g. vscode: https://code.visualstudio.com/docs/remote/ssh Nov 08 14:11:58 maybe the vs code option could my problems Nov 08 14:12:54 for some reason they claim to need 1G of ram on the remote host though.... I don't know if they're serious about that Nov 08 14:14:20 it's also possible to mount a remote filesystem on your local pc via ssh: https://phoenixnap.com/kb/sshfs Nov 08 14:21:19 another question, which one of the images should I use for pocketbeagle? Nov 08 14:21:41 i don't know the difference between buster and bullseye Nov 08 14:21:50 same as for beaglebone black Nov 08 14:22:42 buster is an older version of debian, this is still used for the official released images (https://beagleboard.org/latest-images) except for the BBAI64 Nov 08 14:23:52 the bullseye images are more modern and uptodate but will have a variety of backwards-incompatible changes which also means external documentation you may find on how to do things may not always apply anymore without changes Nov 08 14:25:17 of course any testing image will not (yet) be as well-tested and widely used as the officially released images Nov 08 14:25:52 so the last well tested image for pocket was from two years ago? Nov 08 14:26:26 yeah the latest images are getting a bit dated... I don't know what exactly is keeping the current testing images from becoming the official next release Nov 08 14:27:33 though the fact that the bbai64 uses bullseye images suggests to me the bullseye images might be nearing readiness Nov 08 14:27:48 (for other devices as well) Nov 08 15:40:26 Is there any image for the BB AI-64 which includes the AI tools but no desktop environment (no graphical interface)? Nov 08 16:00:54 Guest62: hmm, curiously it doesn't look like it... you could maybe take a minimal image and install the edgeai packages? Nov 08 16:02:06 rcn-ee: any reason there's no iot/iot-edgeai images for the ai64 ? Nov 08 16:12:59 Thank you very much zmatt. Do you know if the edgeai package are `ti-edgeai-8.2-base`, `ti-vision-apps-8.2`, and `ti-vision-apps-eaik-firmware-8.2`? I was trying to find documentation about how to install them in the https://docs.beagle.cc/latest/boards/beaglebone/ai-64/edge_ai_apps/index.html, but the only place such packages are mentioned is in Nov 08 16:12:59 the "Update software on BeagleBone AI-64" page... Nov 08 16:13:48 unfortunately I don't really know anything about the edgeai software, I've never done anything with ai and I don't own a bbai64 Nov 08 16:14:53 Thank you anyway zmatt. It is good advice. I will try and see how it goes Nov 08 16:15:11 if I personally wanted to know what exactly the differences are between the edgeai and non-edgeai images, I'd probably just download both, extract a list of installed packages for both images, and compare those Nov 08 16:15:40 or check the image build tool Nov 08 16:19:47 actually, try comparing https://github.com/beagleboard/image-builder/blob/master/configs/bb.org-debian-bullseye-xfce-v5.10-ti-arm64.conf and https://github.com/beagleboard/image-builder/blob/master/configs/bb.org-debian-bullseye-xfce-edgeai-v5.10-ti-arm64.conf Nov 08 16:26:54 Thanks zmatt I was looking for that :) Nov 08 16:27:47 and probably grep the image-builder repository for "rfs_enable_edgeai" to see where that flag gets tested in the scripts Nov 08 16:29:53 Apparently, not. I did a quick grep and it is only mentioned in the config file: Nov 08 16:29:54 ``` Nov 08 16:29:54 rg rfs_enable_edgeai Nov 08 16:29:55 bb.org-debian-bullseye-xfce-edgeai-v5.10-ti-arm64.conf Nov 08 16:29:55 157:rfs_enable_edgeai="enable" Nov 08 16:29:56 ``` Nov 08 16:30:53 https://github.com/beagleboard/image-builder/blob/master/scripts/chroot.sh#L1266 Nov 08 16:31:49 Oh well, my grep-foo is not very good then '=D Nov 08 16:32:13 Ok, so just installing the packages and enabling a systemctl package Nov 08 16:32:29 sounds good Nov 08 16:33:58 Thank you for the help zmatt Nov 08 17:21:49 Hello, Nov 08 17:22:14 So I installed a newer image, but the steps I did before to pass internet from my pc to the board via usb don't work anymore Nov 08 17:26:41 uart0_person: networking is one of the things that changed significantly between buster and bullseye... is there a particular reason you're using a bullseye image anyway? Nov 08 17:27:12 Just assumed it would be better to use the latest image Nov 08 17:27:40 "better" is a rather vague term.... better for what? better for who? Nov 08 17:28:19 *I* would rather use a bullseye system than a buster system, but then I'm quite familiar and comfortable with setting up a debian system in whatever way I want Nov 08 17:30:20 what was the procedure you followed for buster images? Nov 08 17:34:33 uart0_person: it may suffice to add Gateway=192.168.7.1 to the [Network] section of /etc/systemd/network/usb0.network Nov 08 17:35:09 (or Gateway=192.168.6.1 to /etc/systemd/network/usb1.network if you're using the CDC-NCM interface rather than the RNDIS interface) Nov 08 17:35:27 and then sudo systemctl restart systemd-networkd Nov 08 17:38:20 In my windows machine, I would find my connection to wifi and set it to share with the name of the usb connection to the board. Then, I would configure the usb connection ip address since windows give a random one and not the right one. After this I create two files, one at root folder, another at /etc/init.d, give the permission and give a Nov 08 17:38:21 symbolic link Nov 08 17:39:38 wait you mean configure the ip address on the beaglebone side? why not configure a fixed ip range on the windows side? Nov 08 17:39:42 or is that what you meant? Nov 08 17:40:12 I don't understand why you'd need a service on the beaglebone for this, networking is handled by a network manager - connman on buster images, systemd-networkd on bullseye images Nov 08 17:42:01 you could also just configure the beaglebone to act as dhcp client, which is arguably the better solution that doesn't require any ip configuration anywhere Nov 08 17:44:02 I do these steps Nov 08 17:44:07 I do these steps Nov 08 17:44:08 https://ofitselfso.com/BeagleNotes/HowToConnectPocketBeagleToTheInternetViaUSB.php Nov 08 17:44:17 for that, just change /etc/systemd/network/usb0.network to this: https://pastebin.com/emLmGPvw Nov 08 17:44:44 ok Nov 08 17:45:14 the downside of that config is that you won't know the ip of the beaglebone since it'll be assigned by Windows Nov 08 17:45:38 but you can hopefully find it by hostname... at least that would work on mac or linux Nov 08 17:46:20 So I add gateway to network Nov 08 17:46:28 or erase everyhting to the thing you sent me Nov 08 17:47:20 the "add gateway to network" solution is for when you want to use fixed IPs, 192.168.7.2 for the beaglebone and 192.168.7.1 for windows Nov 08 17:47:47 you'd need to configure that ip manually on the windows side if you use internet sharing Nov 08 17:48:32 I'm eating food right now but I'll look at your link after that Nov 08 17:51:20 the benefit of the "add gateway" solution is also that it at least doesn't break the normal networking setup, i.e. you can still just disable internet sharing and configure the interface automatically on the windows side and be able to reach the beaglebone Nov 08 17:53:22 with the solution of configuring the beaglebone to use dhcp, it _needs_ a dhcp server on the windows side (as provided by internet sharing) to have ipv4 connectivity to the beaglebone (though ipv6 should work regardless) ... of course you should be able to reach it via IPv6 regardless) Nov 08 17:53:36 ehh, that sentence failed near the end Nov 08 17:54:10 you can of course also use the usb serial interface exposed by the beaglebone to figure out what's going on with networking on its side Nov 08 17:54:27 and whenver I said "beaglebone" I meant "pocketbeagle" in your case of course, sorry Nov 08 18:08:51 Hello Nov 08 18:09:33 if you missed some of the last stuff I said, check the logs... https://libera.irclog.whitequark.org/beagle/2022-11-08 Nov 08 18:11:20 Ok just read it Nov 08 18:11:37 did you see the link I sent? Nov 08 18:14:36 uart0_person: adding the Gateway=192.168.7.1 line will make the network manager add a route similar to what "route add default gw 192.168.7.1" does Nov 08 18:15:00 ok, let me add it and then reboot the board Nov 08 18:15:34 (note btw that the "route" command is old and deprecated, its modern replacement would be "ip route add default via 192.168.7.1", but either way you *generally* shouldn't mess with routes like that since they're the responsibility of your network manager) Nov 08 18:15:54 you don't really need to reboot, it suffices to "sudo systemctl restart systemd-networkd" Nov 08 18:17:33 Yeah, didn't work Nov 08 18:18:10 did you do the configuration on the windows side? what your guide suggests probably still works Nov 08 18:19:03 yeah, I did all the steps Nov 08 18:19:22 "didn't work" in what sense? are you no longer able to reach the pocketbeagle? Nov 08 18:21:22 I can reach the pocket, but it can't connect to internet Nov 08 18:21:34 pinging 8.8.8.8 yields no results Nov 08 18:21:42 can you pastebin the output of "ip route" ? Nov 08 18:22:58 https://pastebin.com/eay8CF1B Nov 08 18:23:42 well it has a default gateway via usb networking, so any problems must be on the Windows side Nov 08 18:23:52 this routing table looks correct to me Nov 08 18:25:09 btw, just in case you've previously messed with /etc/resolv.conf ... that file shouldn't be touched, it should be a symlink to /run/systemd/resolve/resolv.conf (https://pastebin.com/2UY9g2Q4) Nov 08 18:26:49 yeah, I did alter that file Nov 08 18:27:24 uart0_person: I'm honestly not sure why the guide you linked chose to change the interface back to "Obtain an IP address automatically" after enabling internet sharing, it probably makes more sense to just statically configure it to 192.168.7.1 Nov 08 18:27:42 ok, I will do that Nov 08 18:28:18 and just in case you can fix /etc/resolv.conf with: sudo ln -sfT /run/systemd/resolve/resolv.conf /etc/resolv.conf Nov 08 18:28:30 though that doesn't affect your ability to ping an IP Nov 08 18:29:30 changed back the file, and set the static ip, but no internet yet Nov 08 18:30:04 think will just reflash back to the old version Nov 08 18:30:15 since the internet is not working Nov 08 18:30:36 I honestly don't see how the image version could be causing this, the routing table you have now should be the same as you would have had before Nov 08 18:31:06 if anything, it should work more reliably on bullseye since you don't have to worry about connman (which was used on buster) messing with your routes (which connman really likes to do) Nov 08 18:31:24 strange Nov 08 18:31:38 the only thing that is slightly different Nov 08 18:31:43 when I had the other image version Nov 08 18:31:57 the name of the ethernet connection was just like the guide Nov 08 18:31:59 ethernet 2 Nov 08 18:32:05 but with new version is ethernet 3 Nov 08 18:32:12 but that shouldn't be causing this Nov 08 18:32:43 probably the mac address of the usb network interface changed, so windows doesn't know that it's the same device as before Nov 08 18:33:03 but yeah that is of no relevance, as long as you now share your internet with ethernet 3 instead of with ethernet 2 Nov 08 18:34:14 which I did Nov 08 18:34:22 so it should be working Nov 08 18:34:25 it does feel more likely the problem is still on the Windows side rather than the pocketbeagle side, since the config on the pocketbeagle side looks correct to me Nov 08 18:37:09 oh another thing is different Nov 08 18:37:12 before I did anything Nov 08 18:37:21 http://192.168.7.2/ doesn't work Nov 08 18:37:30 in the other version went to cloud9 Nov 08 18:37:42 now it says it can't connect Nov 08 18:38:33 cloud9 has been dropped since the project is dead and unmaintained Nov 08 18:39:17 I will return the version and hope it works Nov 08 18:39:18 it is possible to run vscode on the beaglebone as a substitute, which (as the forum page of the testing images explains) is instaleld by default but not enabled by default Nov 08 18:40:40 when I was coding with raspberry pi, I used samba and could open the rpi as a folder in windows, then I used my ide to code. I wanted to do something like this. Set said their version could do that so I updated Nov 08 18:40:57 but now that internet is not working i think it's better to return the version and find another way Nov 08 18:41:23 you could use samba for file sharing yeah, or like I mentioned earlier you could use ssh to mount the filesystem Nov 08 18:41:53 both of these should work equally well regardless of whether you're using buster or bullseye Nov 08 18:42:13 samba is more hassle to setup, ssh requires no setup on the beaglebone side Nov 08 18:50:37 I tried with samba Nov 08 18:50:52 but I couldn't reach the pocket via usb anymore after I tried Nov 08 18:51:24 lol, how'd you manage that... samba shouldn't have any way of affecting your ability to ssh to the beaglebone Nov 08 18:51:55 I don't know haha Nov 08 18:51:59 I was surprised too Nov 08 18:52:25 I was trying to repeat the steps I did for rpi but for beagle, and it ended up like that Nov 08 18:56:05 I still don't understand why internet sharing isn't working for you right now, but with Windows as a host I also have no clue how to diagnose it Nov 08 19:29:01 yeah, now the internet is not working even in the old image Nov 08 19:29:14 lol Nov 08 19:29:49 like I said, the config looked fine on the pocketbeagle side Nov 08 19:30:47 I also did everything on windows side, like the other times, didn't change a step Nov 08 19:31:16 maybe the lunar phase has changed Nov 08 19:32:14 try holding a pineapple and see if that helps ( https://xkcd.com/1457/ ) Nov 08 19:33:16 too bad, I only have oranges Nov 08 19:38:06 whyyyy this pocketbeagle's internet doesn't work Nov 08 19:41:59 now it works Nov 08 20:42:52 I just disabled internet sharing then redid the process Nov 08 20:42:54 and then it worked Nov 08 23:18:20 Hi, how can I set up pins to function as bidirectional input/output? I want them to take in inputs on certain cycles, and then reconfigure it to output digital values on other cycles Nov 08 23:19:28 nick12310: uhh, that doesn't require any "set up", you can change the direction of a gpio as easily as you can read (as input) or change (as output) its value Nov 08 23:20:01 unless you're talking about PRU (in which case you should definitely have clarified that in your question) Nov 08 23:29:07 Yes, talking about the PRU. Right now i'm working with blinkExternalLED.pru0.c , one of the examples in the cloud 9. I see how it inits pins as output direction, but is there a way for input and output? Nov 08 23:30:08 unfortunately not for the pru's dedicated (low-latency) gpios Nov 08 23:31:20 can I use ocp for other gpios? Nov 08 23:31:32 if you need bidirectional GPIO from PRU, your options are to use regular GPIO (via the GPIO controllers) instead of PRU's direct GPIO, or use external logic (like a tristate buffer) to work around the limitation Nov 08 23:31:37 PRU can access everything Nov 08 23:32:36 there's a catch with changing GPIO direction from PRU though: you need to be sure that linux won't try to change the direction of any gpio on the same gpio controller, otherwise you'll end up with a race condition Nov 08 23:34:10 since there's no way to atomically change the direction of a single gpio, gpio direction is controlled by reading/writing a register that controls the direction of all 32 gpios of that gpio controller (one bit per gpio) Nov 08 23:36:49 but on the bright side, I don't think linux has any reason to change the direction of a gpio on the beaglebone unless requested to by userspace, so you're in control of that Nov 08 23:37:47 That makes sense. I want the PRUs to be the only thing doing changes with the pin outputs Nov 08 23:39:14 But wait, you said PRU can't change the direction? Nov 08 23:39:36 PRU's dedicated low-latency gpio (wired into PRU registers) can't Nov 08 23:40:10 Oh ok, but if I use ocp I can change the direction Nov 08 23:40:12 normal GPIO, controlled via the four gpio controllers, can Nov 08 23:41:01 Will that stop me from being able to use the physical pins that the pru is connected to, or can I use those pins in gpio mode the same? Nov 08 23:41:37 "use ocp" is a weird phrasing... ocp is just an abbreviation linux uses for the on-chip peripherals (collectively), either that or it refers to the Open Core Protocol used to interface peripherals to the interconnects, not sure Nov 08 23:41:57 nick12310: all of the digital I/O pins on the beaglebone support normal GPIO mode Nov 08 23:43:49 it's their default mode Nov 08 23:46:18 Yea sorry for the ambiguity Open Core Protocol is what I mean. The example for PRU uses the Open Core Protocol (OCP) master port to toggle the GPIO pins Nov 08 23:46:53 it uses the OCP master port to interface to the L3 interconnect via which it can (directly or indirectly) reach all of the subsystems and peripherals on the AM335x Nov 08 23:50:22 So it uses that to move from pru subsystem to the GPIO pins? what exactly is the l3 interconnect Nov 08 23:50:31 my py-uio project actually includes a header ( https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/gpio.h ) and example ( https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/toggle-led.pasm ) for using the gpio controllers in pru assembly Nov 08 23:50:53 (this doesn't include direction-changing since I didn't want to encourage people doing that without being aware of the dangers) Nov 08 23:52:16 nick1231026: the L3 interconnect is basically just a network that forwards read/write requests from initiators like PRU or the Cortex-A8 to various peripherals and other targets on the SoC, and their replies (write acknowledge / read data) back to the initiators Nov 08 23:55:53 (most peripherals are actually on one of several subsidiary interconnects known as the L4 interconnects) Nov 09 00:10:42 nick1231026: you can find more information about the interconnects in chapter 10 of the AM335x Technical Reference Manual, though for the most part you don't really need to know much about it since the interconnects are mostly invisible to the casual programmer Nov 09 00:11:52 and I've updated https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/gpio.h to include the definition of the direction register Nov 09 00:17:01 Ok, nice. I see I just need to change a bit in the register Nov 09 00:17:25 I am a little confused, is this example for beaglebone black? the pru example I am using has different register numbers Nov 09 00:18:53 yeah, if you know PRU is the only one messing with the GPIO directions of one particular GPIO controller, you can read the controller's direction register once and just keep that around and then if you want to toggle a direction bit you update that cached value and write it to the GPIO controller (keep in mind that reads of things outside PRUSS are relatively slow) Nov 09 00:19:17 that header is for the AM335x yes, and the example for the beaglebone black specifically Nov 09 00:19:36 (or beaglebone variants that are sufficiently similar to the BBB) Nov 09 00:19:42 what example are you looking at? Nov 09 00:22:11 https://github.com/jadonk/cloud9-examples/blob/master/BeagleBone/Black/pru/blinkExternalLED.pru0.c and https://github.com/jadonk/cloud9-examples/blob/master/common/prugpio.h Nov 09 00:26:12 nick1231026: https://github.com/jadonk/cloud9-examples/blob/master/common/prugpio.h#L54-L58 ... his GPIO0 address is plain wrong (as is the comment above it which writes "am35xx" while it meant "am335x") Nov 09 00:27:25 other than that they match mine except I add 0x100 to them because all relevant registers are in range 0x100 - 0x194 Nov 09 00:28:03 this allows me to use single-byte register offsets, which allows them to be used as immediate offsets in load/store instructions Nov 09 00:29:42 since you were talking about doing things "on some cycles" I was kinda assuming you were programming PRU in assembly rather than C Nov 09 00:34:26 nick1231026: for C you may be interested in this header I wrote: https://pastebin.com/anqLbyav Nov 09 00:37:26 (the compiler will no doubt generate terrible code for it, but that's business as usual for the PRU C compiler) Nov 09 00:43:25 Ah, thanks I will check the header out. Nov 09 00:43:50 Good day / evening everyone. Nov 09 00:44:19 I'm getting lost in the online sea of outdated documentation and tutorials. Nov 09 00:44:30 yeah that is a problem indeed Nov 09 00:44:48 I got an IoT OS of beaglebone Black and I'm trying to set the resolution of the display Nov 09 00:45:21 I'm using a pretty small hdmi monitor for an IoT project Nov 09 00:45:51 Hey! You guys? Nov 09 00:46:00 last clue was to edit the uEnv.txt file in boot but that did not pan out Nov 09 00:46:08 Figured I'd try here. Nov 09 00:46:13 Super busy...need a break? One break coming up! Nov 09 00:46:26 Guest76: I mean, normally it will figure out an appropriate resolution for your monitor (based on what the monitor reports is supported), but you can force the selection by appending e.g. video=800x600 or whatever in the cmdline= variable assignment in /boot/uEnv.txt Nov 09 00:47:38 Guest76: what change did you make in /boot/uEnv.txt exactly? Nov 09 00:49:43 That's actually what I was trying to do as well. let me quickly peek Nov 09 00:50:01 That's what the last instruction doc I was reading told me to do as well Nov 09 00:50:28 well then that doc was right Nov 09 00:51:02 you sure the monitor supports the resolution you configured? Nov 09 00:51:50 if it did not support it, it would not display it right? Nov 09 00:52:03 display it where? Nov 09 00:53:32 I mean the image would not even show up on the monitor right? Nov 09 00:53:37 The usual. Nov 09 00:53:58 When a monitor received unuspported video resolution it would say something like "unsupported resolution" etc Nov 09 00:54:13 In my case even if I set the argument, it just defaults to 1920x1080 Nov 09 00:54:36 no, if the resolution isn't supported then the kernel will know that (since the hdmi monitor reports which resolutions are supported) and therefore won't allow that resolution to be picked Nov 09 00:54:50 I see Nov 09 00:54:59 is it possible to force it Nov 09 00:55:21 ... probably? dunno Nov 09 00:55:37 because I have one of those 5" project hdmi monitors that technically supports 1920x1080 but the text is so small you can't read it Nov 09 00:55:51 so just because the driver supports it, doesn't mean it's gonna be a good experience sort of deal Nov 09 00:55:55 it's quite possible the monitor only supports native resolution Nov 09 00:56:08 I had it run at 640x480 on raspbery pi Nov 09 00:56:13 so it definetely works Nov 09 00:56:14 huh ok Nov 09 00:56:27 The chip shortage has me looking at beaglebone Nov 09 00:56:48 that makes even less sense... it's not like the linux kernel's resolution-selection logic is any different on the beaglebone than on the rpi Nov 09 00:56:50 I used to run this project on raspberry pi zero and also rpi4 headless Nov 09 00:57:00 I know, right Nov 09 00:57:23 that's why I'm stumped as to why it's behaving differently Nov 09 00:57:25 just to confirm, can you cat /proc/cmdline ? Nov 09 00:57:35 just to double-check the kernel parameters Nov 09 00:58:36 yeah I gotta ssh to copy the output Nov 09 00:58:49 it did print something out Nov 09 00:58:59 what's the command to get ip address? Nov 09 00:59:12 uhh of what? Nov 09 00:59:28 "ip addr" shows all network interfaces on linux Nov 09 00:59:35 if that's what you mean Nov 09 01:00:46 yeah, I want to post here the output of cat, but to do that I gotta ssh into beaglebone Nov 09 01:00:57 unless you want dusty phone pic of the screen cli Nov 09 01:01:42 if the beaglebone is connected via usb then you can reach it as 192.168.7.2 (on windows or linux) or 192.168.6.2 (on mac or linux) or as beaglebone.local (on mac, linux, and maybe windows) Nov 09 01:01:56 console=ttyS0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet Nov 09 01:02:07 I'm not seeing your video config Nov 09 01:02:20 what _exactly_ did you change in /boot/uEnv.txt ? Nov 09 01:02:23 let me check the uEnv.txt Nov 09 01:03:07 you need to find the existing line that configures the "cmdline" variable and append "video=640x480" to it (separated by a space from any existing parameters) Nov 09 01:03:21 e.g.: Nov 09 01:03:30 cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet video=640x480 Nov 09 01:04:06 here's the contents of the uEnv.txt file Nov 09 01:04:07 https://pastebin.com/UfegRYLq Nov 09 01:04:11 One note Nov 09 01:04:18 I had to add the cmdline= to it Nov 09 01:04:21 it was not there Nov 09 01:04:31 PS I am looged in as debian Nov 09 01:04:34 not as root Nov 09 01:04:41 it is there, line 59 of your paste Nov 09 01:04:41 PS I am logged in as debian Nov 09 01:04:57 OH Nov 09 01:05:00 I'm blind Nov 09 01:05:04 one moment Nov 09 01:06:20 IT WORKED! Nov 09 01:06:25 there ya go Nov 09 01:06:38 once again thanks due to me missing something simple Nov 09 01:06:53 I was losing my mind tbh, thought everything I read was out of date Nov 09 01:07:04 nope, this wasn't! Nov 09 01:07:06 thank you very much Nov 09 01:07:16 actually I think this never changed at any point Nov 09 01:07:43 Yay! My turn! Nov 09 01:07:57 at least not for as long as I've been around here :D Nov 09 01:08:19 bbl...dang it. Nov 09 01:08:22 gotcha Nov 09 01:13:37 oh btw, how would one retrive the name of the currently used video driver? Nov 09 01:13:55 the video driver on the am335x is tilcdc Nov 09 01:14:15 I'm working on something with pygame which runs in SDL2 and it need to have a correct environment variable set to display. Nov 09 01:14:55 tilcdc it is then Nov 09 01:15:02 beware that the video capabilities of the AM335x are quite limited, it's an industrial SoC, not a media SoC like the rpi Nov 09 01:15:44 Indeed. I wanted to see how much worse or better the beaglebone ran my application Nov 09 01:16:27 (and its rarely-used potato GPU requires a kernel driver and userspace package that's not installed by default, and which is incompatible with using X11) Nov 09 01:16:30 first problem after getting the resolution of the cli fixed was to get the pygame running. I actually did get it to launch, and it played the sounds of the application, but did not display the actuall app. Nov 09 01:17:06 I see. Nov 09 01:17:06 so I hope you don't need OpenGL ;) Nov 09 01:17:10 Oh no Nov 09 01:17:14 it's just 2D stuff Nov 09 01:17:18 ok Nov 09 01:17:23 https://wiki.libsdl.org/FAQUsingSDL Nov 09 01:17:34 SDL2 supports a few solutions Nov 09 01:17:40 not as much as SDL1 Nov 09 01:17:41 ohh driver in that sense Nov 09 01:17:53 yes, what did I reffer to ? Nov 09 01:17:56 my mistake Nov 09 01:18:04 I assumed which kernel driver is being used Nov 09 01:18:16 righto. Nov 09 01:18:38 for this, if you're not using X11 then I'd say try kmsdrm, otherwise I guess directfb ? Nov 09 01:18:39 I should probably let nick12310 go ahead with his question Nov 09 01:18:50 he's been attempting to write one a few times when I butt in Nov 09 01:19:33 anyone can type at any time they want Nov 09 01:19:34 and with those being the only two supported drivers, I'd say I can look into those. Nov 09 01:19:46 that and x11 Nov 09 01:20:02 to be honest. my choices right now are - anything that gets this thing to actually launch Nov 09 01:20:17 Guest76: kmsdrm sounds like the Right Thing to me, assuming it supports any kernel driver with kms and dumb buffer support (e.g. tilcdc) Nov 09 01:20:39 and not egl or whatever Nov 09 01:24:26 I should probably get some sleep Nov 09 01:26:13 Appreciate the help Nov 09 01:41:35 Does the video=HDMI-1-A support flpping? Nov 09 01:41:44 say if the display is mounted upside down? Nov 09 01:42:28 tilcdc does not support any kind of rotation or vertical/horizontal flip Nov 09 01:42:33 the hardware doesn't support it Nov 09 01:43:13 like I said, _very_ basic graphics support Nov 09 01:43:40 gotcha Nov 09 01:44:45 the AM335x basically has the dumbest video hardware you can get away with for driving a touchscreen ;) not even hardware mouse cursor support. the only reason it has a (crappy) 3d gpu is because it was originally intended to support android (though this has been dropped since) which requires a gpu Nov 09 01:45:04 I see Nov 09 01:46:18 I am pretty sure my project isn't demanding in terms of the graphical load Nov 09 01:46:24 This was the last rendition Nov 09 01:46:25 https://www.youtube.com/shorts/S9bk1NTKImQ Nov 09 01:46:32 Basically a text based adventure game Nov 09 01:48:32 I would tend to agree Nov 09 01:50:20 This chip shortage is forcing me to start looking into custom SoCs and running linux on them Nov 09 01:50:48 I was told, and I now agree, that I can't rely on raspberry pi stock even for a small run Nov 09 01:51:15 relying on the rpi is a mistake since the SoC is custom for the rpi foundation and not available on the general market Nov 09 01:51:36 indeed. It was a starting time Nov 09 01:52:49 oops Nov 09 01:52:53 prematurely pressed enter Nov 09 01:53:05 oh dang, you can edit these messages Nov 09 01:53:06 nice Nov 09 01:53:23 I actually started this project on an MCU Nov 09 01:53:30 with Adafruit GFX Nov 09 01:53:31 uhh no you can't edit messages here Nov 09 01:53:36 really? Nov 09 01:53:40 I figured you can Nov 09 01:53:43 a Nov 09 01:53:46 nevermind Nov 09 01:53:52 up arrow does something else Nov 09 01:54:13 this is IRC, it's state-of-the-1980's technology Nov 09 01:54:32 hehe Nov 09 01:54:57 So yeah, I started this project on an MCU, Arduino Due Nov 09 01:55:11 Atmel SAM3X8E ARM Cortex-M3 Nov 09 01:55:18 just bare metal Nov 09 01:55:55 It was a pretty good start, but once I started defining game data, like jsons for level data Nov 09 01:56:05 I had quickly learned about the malloc headaches Nov 09 01:56:26 I mean, do you really need json or malloc for a game like this? Nov 09 01:56:28 json was bloated but vert convenient as I used it extensivelt for my game dev projects. Nov 09 01:56:54 Tehcnically the way the game is made is very modular Nov 09 01:56:56 then keep the master data in json and write a tool to convert the json to something sensible for the microcontroller :P Nov 09 01:57:39 I wanted to add expandability to the game Nov 09 01:58:24 And having been spoilt by scripting languages, it was apparent that a linux solution would be the way Nov 09 01:58:30 you don't need JSON for that... people make plenty of Super Mario Romhacks and let me assure you it doesn't use JSON ;-) Nov 09 01:58:33 (nor malloc) Nov 09 01:58:42 *Super Mario World romhacks Nov 09 01:58:44 well those games are static in size Nov 09 01:59:26 some romhacks are pretty big, I know they've managed to patch their way around some limitations of the original game in terms of number of levels Nov 09 02:00:26 It's less to do with JSON itself and more that dicitonaries make for an extremely easy way to move around data and establish the game world. Nov 09 02:00:26 anyway, yeah linux-based development does have its comforts and luxuries Nov 09 02:00:48 There would be a lot of key value pair movement Nov 09 02:01:02 and for that I'd have to do a lot of memory management Nov 09 02:01:19 not to mention audio sfx and music playback Nov 09 02:01:47 individually these elements are alright enough to handle, but once put together on an MCU, it becomes a bit much. Nov 09 02:01:50 to be fair that's not really any different on microcontrollers than on linux, it's just that you generally have more ram to waste on being sloppy Nov 09 02:02:05 And linux already handles memory for me Nov 09 02:02:16 so I just have to keep within the limitations Nov 09 02:02:23 which is less of a hassle Nov 09 02:02:38 I mean, that's not really any different on a microcontroller.... like, not from a practical point of view Nov 09 02:02:48 maybe it's just me Nov 09 02:02:54 in both cases you just malloc() and don't worry about the details behind the scene Nov 09 02:03:13 I found I focused more on the game design on the raspberry pi than I did with memory management Nov 09 02:03:25 adding audio was super easy, with the spi audio solutions Nov 09 02:03:32 same with ethernet Nov 09 02:03:47 it's already a part of linux so I didn't have to program my own telnet Nov 09 02:03:50 yeah, a lot of things are definitely easier to get working Nov 09 02:04:04 on linux compared to a baremetal environment Nov 09 02:05:31 mostly just for fun I've done small bits of baremetal programming on the AM335x and before that an even larger SoC.... it's neat to have direct access to so much resources, but it takes ages to actually get anything *done* Nov 09 02:07:03 indeed. Nov 09 02:07:10 I do remember on that other SoC when I got the ddr3 memory controller operational and suddenly had access to external RAM instead of just the on-chip SRAM.... I had absolutely no idea what I was gonna do with all that ram, the internal SRAM was already plenty really ;) Nov 09 02:07:49 in contrast, now the bootloader used to linux doesn't even manage to fit its fat ass in internal SRAM and as a result has to do two-stage loading Nov 09 02:07:55 *used to load linux Nov 09 02:09:08 lol, I see Nov 09 02:10:10 I was reffered to this nugget Nov 09 02:10:12 https://jaycarlson.net/embedded-linux/ Nov 09 02:10:32 In response to my problem of getting bit in the butt for relying on rpi Nov 09 02:10:53 I suppose the rpi is super demanding due to it's accessibility Nov 09 02:12:24 there's also a company that makes a module containing the AM335x + PMIC + DDR3 ram + decoupling caps ... so basically the most critical parts that normally surround the AM335x (and require the most from the pcb design), stuffed together in one package Nov 09 02:12:33 it's not cheap though Nov 09 02:13:49 The write of this blog mentioned that one can find pre-made board + schematic designs which I can just send to fab facotories to get produced and installed with bga components? Nov 09 02:14:12 I don't suppose you have experience with these? Nov 09 02:14:22 or if you've come across an example of these? Nov 09 02:14:39 the beaglebone's schematic and pcb design is open Nov 09 02:15:06 Well that's a big plus over the rpi Nov 09 02:15:21 here's to hoping I can get this pygame running Nov 09 02:16:21 the company that makes the module I just mentioned, Octavo, also released a variant that embeds an eMMC, which means you need _very_ little around it to boot: https://twitter.com/pdp7/status/1100349116515827712 Nov 09 02:16:55 seems a bit unnecessary to me compared to just adding an external eMMC to your pcb design, but it's kinda funny Nov 09 02:17:12 oh my lord Nov 09 02:17:18 lmao that bga solder work Nov 09 02:19:28 if you think this is crazy, do a google image search on "bga dead bug" ;) Nov 09 02:24:16 oh god Nov 09 02:24:19 I was thinking this yeah Nov 09 02:24:21 lol Nov 09 02:25:41 oh right I was going to get some sleep Nov 09 02:25:59 * zmatt zZ Nov 09 02:26:10 alrighty Nov 09 02:26:14 thanks for the conversation **** ENDING LOGGING AT Wed Nov 09 02:59:57 2022