**** BEGIN LOGGING AT Wed Dec 30 02:59:57 2020 Dec 30 15:36:13 hello how do I upgrade OS on a bbb ver 2? Dec 30 15:54:00 abnormal: uhh, what do you mean? Dec 30 15:54:22 where's no "bbb ver 2" Dec 30 15:54:25 *there Dec 30 15:54:50 bbb hardware revisions start with a letter Dec 30 15:56:02 ok B Dec 30 15:56:15 ver B Dec 30 15:56:27 how did you determine that? Dec 30 15:57:02 it's the second ver of BBB that I got in 2012 Dec 30 15:57:22 has Angstrom in it Dec 30 15:58:15 in all cases the recommended way to perform a major upgrade is by reflashing eMMC to the latest image. however, if you have a very early bbb (rev B or older), it has only 2G of eMMC (Microm eMMC marked with "JW896": https://photos.app.goo.gl/rMKMX782wCyMJ9Wd6 ) which restricts what images you can flash onto it Dec 30 15:58:31 oh wow, angstrom... that old Dec 30 15:59:05 yeah, sadly it's an antique... lol Dec 30 15:59:49 guess I am stuck with it Dec 30 16:00:10 so, your options are: 1. wipe eMMC and boot from SD card instead, recommended image is the latest (2020-04-06) Buster IoT image, Dec 30 16:00:11 glad I bought the Pi's Dec 30 16:00:28 ok ty Dec 30 16:00:34 2. flash a console image to eMMC, which is a minimal system that requires very little space Dec 30 16:00:44 (and then install anything you want yourself using apt) Dec 30 16:00:52 ok Dec 30 16:02:04 console image not my thing cuz I don't have the ability to program... Dec 30 16:02:43 3. try to squeeze the latest IoT image onto eMMC... I think it could fit, especially if you remove some unnecessary crap before flashing, but it would be very tight and I wouldn't recommend it Dec 30 16:03:07 (starting with a lean image and installing what you want is generally easier than starting with a bloated image and figuring out what's safe to remove) Dec 30 16:03:45 gotcha... ty Dec 30 16:03:50 I don't see what the ability to program has to do with it... using a console image requires slighly more skill in using a debian linux system, not any programming Dec 30 16:04:02 though I do wonder what you intend to use the bbb for Dec 30 16:04:41 trying to use it as a desktop puter with IRC chat Dec 30 16:05:00 I have 14 Pi's Dec 30 16:05:10 one Tinkerboard Dec 30 16:05:22 two Rock64's Dec 30 16:05:30 ok... so flash a console image, install whichever console irc client you prefer, and voila Dec 30 16:05:42 ok ty Dec 30 16:06:38 I would use a console image for this even if eMMC had space for the IoT image... none of the extra stuff the IoT image has is of any use to you, it would just waste space and make it boot slower Dec 30 16:06:48 took me two years to figure out how to get it online... lol... some guy in Alaska walked me thru the steps... Dec 30 16:07:00 how to get it online? plug ethernet in, done Dec 30 16:07:13 yup Dec 30 16:07:17 at least on current image that's the full list of steps Dec 30 16:07:43 (in theory you can also connect it via usb to a computer and then share that computer's internet connection to the bbb, but that's a lot more complicated) Dec 30 16:08:26 unfortunately for some reason the latest-images page doesn't include console images, however you can find them here: https://elinux.org/Beagleboard:Latest-images-testing Dec 30 16:08:49 bone-eMMC-flasher-debian-10.5-console-armhf-2020-08-25-1gb.img.xz would be the one to use Dec 30 16:09:04 yeah took me a while.. I'm not that literate of an indvidual.. I had to get help from very special ppl who were very patient with me... Dec 30 16:09:19 ok thank you Dec 30 16:09:55 flash it to sd card (using Etcher is recommended since it's user-friendly, supports .img.xz files directly, and verifies after flashing to ensure the sd card isn't broken) Dec 30 16:10:37 stick it into the bbb, then power on while holding down the S2 button (the one closest to the sd card slot)... you can let go of the button once any leds are on Dec 30 16:10:53 yeah I use Etcher all the time.. Dec 30 16:11:03 (using the button isn't always requires to boot from SD card, but it may be requires when the system on sd card is really ancient, like it is in your case) Dec 30 16:11:09 *required Dec 30 16:11:30 understood Dec 30 16:11:49 it will then automatically proceed to wipe and reflash the eMMC and when it's done it will power off. since the console image is quite small, this shouldn't take long Dec 30 16:12:19 ehh, "when the system on eMMC is really ancient" I maent earlier of course Dec 30 16:12:19 ok Dec 30 16:12:59 (specifically the bootloader (u-boot) on eMMC, which is used in preference over the one on SD card unless no bootloader is present on eMMC or the S2 button is held down at power-on) Dec 30 16:13:20 ok Dec 30 16:13:47 all my puters are Linux Dec 30 16:13:50 once it's done, don't forget to remove the sd card before turning it back on, otherwise it will immediately proceed to reflash again :P Dec 30 16:14:06 (maybe wipe the sd card afterwards to prevent such accidents) Dec 30 16:14:13 ok gotcha... lol Dec 30 16:15:45 once it's booted, ssh debian@beaglebone.local (password temppwd) or log in locally via monitor+keyboard and customize the system as desired Dec 30 16:17:06 if you have multiple beaglebones you'll want to change the hostname ("sudo hostnamectl set-hostname ...") to be unique Dec 30 16:17:37 so, why exactly do you have a farm of assorted small arm-based linux SBCs ? :D Dec 30 16:19:06 note that the default account ("debian") has been set up with a lot of privileges related to hardware access.. if it's just going to be used as an IRC terminal you may actually want to create a new account for that for increased security Dec 30 16:19:40 (but that depends on the situation whether or not you might care) Dec 30 16:24:15 i've been studying and discovered that the coprocessor i need for the application is not the PRU or the NEON FPU, but actually the IT PVR SGX530, because it supports OpenGLES 2.0 instructions. however i discovered access to this device is not enabled on any of the beagleboard.org images and I must load the SGX SDK into the filesystem. Dec 30 16:24:31 I've been trying to do this following directions here https://elinux.org/BeagleBoneBlack/SGX_%2B_Qt_EGLFS_%2B_Weston#All_patches and here https://processors.wiki.ti.com/index.php/Graphics_SDK_Quick_installation_and_user_guide, however I'm having trouble testing any of the demos. Dec 30 16:24:50 I don't see any compiler errors building the toolchain, but at runtime I see PVR:(Error): PVRSRVGetDeviceMemHeapInfo: Error 149 returned [0, ] and a set of other errors when running every one of IT demos and also with kmscube. Dec 30 16:25:12 pvrsrvkm is compiled and loaded, and tried performing the steps again and full power cycle with no change. /etc/init.d/rc.pvr start prints Loaded PowerVR consumer services. dmesg contains expected output from the module. I'm using 4.19.94-ti-r57 since it is most recent kernel for which there is package ti-sgx-ti335x-modules-4.19.94-ti-r57 in the rcn-ee.com repository. Dec 30 16:25:41 is access to the PVR SGX530 device possible on recent Debian images for BeagleBone Black, or no longer supported? Dec 30 16:26:08 misternumberone: the sgx is a hassle to get working yes.. always has been I think Dec 30 16:27:10 last time I fiddled with it I built debian packages for it: https://liktaanjeneus.nl/sgx/ but I haven't done anything with it since hence haven't updated them Dec 30 16:28:11 it may stlil work on current systems though... if you want to try it, be sure to not have any sgx stuff installed other than the kernel module Dec 30 16:28:45 (and also don't have any mesa libraries installed) Dec 30 16:29:12 (this also means don't have X11 installed) Dec 30 16:31:06 misternumberone: btw since you disappeared last time without saying anything, I'm not sure if you caught the last stuff I said then: https://pastebin.com/raw/znWTs76T Dec 30 16:33:05 the sgx is no speed monster either, but at least it's faster than software rendering for 3d stuff, and I know some people have managed (with some creativity) to use it for gpgpu computation Dec 30 16:33:13 misternumberone: hello? Dec 30 16:33:48 i was using an image i'm pretty sure had no graphical environment installed, but some mesa packages were installed for some reason, thanks for that tip Dec 30 16:34:08 which image? Dec 30 16:34:48 the current debian 10.3 image Dec 30 16:34:54 there's no mesa packages installed on the latest recommended (Buster IoT) image Dec 30 16:35:29 the debian release isn't hugely specific, you can find the image information in /etc/dogtag Dec 30 16:36:31 if you're using the 2020-04-06 IoT image then there shouldn't be any mesa libs installed unless you installed them yourself (e.g. as dependency) Dec 30 16:40:04 actually, now I'm not entirely sure I had a clean image installed, since you told me that. It is debian 10, but since I'm having issues I should start over with a clean one and try everything I did again Dec 30 16:41:23 so, maybe as a first test start with a clean image, make sure the sgx module package is installed, and try installing my old debian packges... if they work then at least you can see what I put where to get things working (including iirc an udev rule to automatically initialize the driver when the module loads) Dec 30 16:41:52 as a guideline if you want to try with the latest version of the userspace libs Dec 30 16:44:14 I should try to make uptodate packages some time... and then maybe see if rcn wants to adopt them Dec 30 16:44:28 so users can simply apt-get install them Dec 30 16:44:31 ok i see your other messages now, i'm sorry i left then the irc client i was using that day wasn't working right Dec 30 16:46:19 i'll try the packages you sent, though Rene from France's packages built in 2019 didn't work for me Dec 30 16:46:46 dunno who that is or how he built his packages :) Dec 30 16:47:49 do let me know how it turns out with mine! Dec 30 16:50:07 if they don't then my first guess would be a version incompatibility between the kernel driver and the userspace libs.. not sure how tightly in sync those are required to be Dec 30 16:53:01 misternumberone: also, if installing my packages fails with a conflict, that's almost certainly a real conflict and not to be ignored. (I just came across a wiki page that used "dpkg -i --force-all" which is very very very bad and should never ever be done) **** ENDING LOGGING AT Wed Dec 30 16:54:07 2020 **** BEGIN LOGGING AT Wed Dec 30 16:56:20 2020 Dec 30 16:57:08 well yeah that's what happened with the packages from this page https://elinux.org/BeagleBoneBlack/SGX_%2B_Qt_EGLFS_%2B_Weston Dec 30 16:58:02 i do have some files from other projects that I need so I'm using rsync to back up currently Dec 30 17:01:26 I try to keep important stuff in git repositories so that I have backups of old versions, can easily push to / pull from a central location, and can more easily merge changes if I modify files on more than one device where the project is used Dec 30 17:16:16 to keep potential conflicts to a minimum and benefit from using the clean image, i will try to minimize what I install before trying your packages. however, i do need to install this driver https://github.com/aircrack-ng/rtl8812au, its dependencies, and probably wicd-curses+mandatory patches since I'm using that currently, otherwise i will be greatly inconvenienced (i only have one board). this shoudn't interfere right? i'm Dec 30 17:16:16 certain none of this pulls in graphical dependencies, so it must have been something else that did that Dec 30 17:17:00 it doesn't seem likely that causes trouble Dec 30 17:17:40 but you don't need to guess, apt will tell you which dependencies it will install when you install a package Dec 30 17:23:24 yesterday I downloaded bone-debian-10.3-iot-armhf-2020-04-06-4gb.img.. or what LOOKS like it, but in fact it somehow no longer has the same sha256sum as what I see near the download link on beagleboard.org. I'd best refetch that as well. Dec 30 17:24:11 *img.xz* Dec 30 17:24:29 huh, how did you manage that Dec 30 17:26:52 btw, when installing my packages, the sgx-ti335x-userspace package should be installed *before* my libgbm1 and libgdm-dev packages, since those are in fact dummy packages that depend on the sgx-userspace package: https://liktaanjeneus.nl/sgx/pkg-summary.txt Dec 30 17:27:41 (Provides doesn't work for those since they're real package names rather than virtual ones) Dec 30 17:28:43 so, you still haven't explained what this program is for which you first wanted to use PRU and now SGX Dec 30 17:30:13 oh the application is Super Mario 64 the decompiled open source version. it seems also that, in theory, it should require much less porting work than I originally anticipated, because it has already been ported to 32-bit Raspberry Pi. Dec 30 17:30:55 its graphical components have also been ported to OpenGLES 2.0 already Dec 30 17:31:00 for that you'll definitely want sgx Dec 30 17:31:33 assuming it can run on a bbb at all Dec 30 17:33:22 I suppose it probably should be able to Dec 30 17:33:50 i worked on the N3DS port and unfortunately for older models it has pretty severe CPU performance issues with the currently available components of the software, though the device is less powerful than the AM335x i believe Dec 30 17:33:58 hopefully the code doesn't use too much 64-bit arithmetic (as side-effect of the N64 being a 64-bit processor), since gcc tends to generate terrible code for that on 32-bit arm Dec 30 17:34:21 (especially on the cortex-a8) Dec 30 17:34:39 so I anticipate potential performance issues here too, though I hope to improve that Dec 30 17:36:11 if the OpenGLES instructions aren't possible to offload from the CPU here though (using the SGX device), I think there is not much hope Dec 30 17:36:47 the bbb cpu should definitely be a lot faster than the 3DS Dec 30 17:36:59 in the past I have seen the performance of WebGL through llvmpipe on this CPU and it wasn't promising Dec 30 17:37:43 yeah sgx should definitely be a lot faster than cpu rendering obviously Dec 30 17:38:01 but requires gles1 or gles2, not classic gl Dec 30 17:38:41 (note that gles1 and gles2 are kinda totally different APIs, I didn't realize that at first) Dec 30 17:44:11 (it is conceivable that gles1 might be faster than gles2 if it's a decent match to whatever the SM64 port needs, but there's really no way to know without porting it to gles1 and testing it, which seems like an excessive amount of work) Dec 30 17:45:00 I'll have to say, this is a strange use of the BBB.. it places the highest demands on its weakest points while making no use of its strengths **** ENDING LOGGING AT Wed Dec 30 17:45:48 2020 **** BEGIN LOGGING AT Wed Dec 30 17:48:57 2020 Dec 30 20:21:37 strange, I see spi0 pins D0, D1, CS0 just stuck high, instead SCLK initially 1, then goes to 0 and stays there. After writing to MCSPI_TX0, I see MCSPI_CH0STAT changing from 0x28 to 0x22 RXFFE=1 and TXFFE->EOT that makes sense, however I don't see the pins changing Dec 30 20:38:09 mm302: so it's getting stuck at the start of the transfer? does your pinmux perhaps neglect to enable input on the SCLK pin? Dec 30 20:38:41 (although it's an output, it uses the input buffer to read back a clock that's more accurately synchronized to the data at the external pins) Dec 30 20:39:56 I set this pinmux settings with config-pin: P9_17=spi_cs, P9_18=spi, P9_21=spi, P9_22=spi_sclk Dec 30 20:40:04 oh, with config-pin Dec 30 20:40:15 as it's the only apparenlty reasonable option Dec 30 20:40:17 presumably its pinmux blocks are correct Dec 30 20:40:26 what is? Dec 30 20:41:11 there is no way to distinguish data in and data out, I set both pins to spi with config-pin Dec 30 20:43:45 do you think the pinmux setting above is incorrect? Dec 30 20:44:02 no Dec 30 20:44:46 I asked because it's a mistake people somewhat frequently make when writing pinmux declarations for mcspi, but that doesn't apply since you didn't write any Dec 30 20:45:07 I _presume_ cape-universal didn't fuck up (since people would have noticed), though I can check Dec 30 20:46:40 yeah it's fine Dec 30 20:46:52 I may actually try to force in MCSPI_SYSCONFIG the clock not to go idle, but in theory shouldn't be needed Dec 30 20:47:23 no don't worry about sysconfig, that's basically a prcm debugging register Dec 30 20:49:21 wait Dec 30 20:49:59 you say CHSTAT changes "from 0x28 to 0x22" .. but bit 1 should be set initially after enabling the channel (before writing the first data) Dec 30 20:52:48 also never mind what I said earlier anyway, I misread the status bits when I said that Dec 30 20:54:34 so did you, since EOT is bit 2 which didn't get set Dec 30 20:56:45 true, it's set to 0x28 immediately after enabling ch0 in CH0CTRL, I may try to add a pause just in case Dec 30 20:58:38 do you have fifos enabled btw? or more generally, what configuration are you using? Dec 30 21:04:03 yes, I've enabled fifo, using ch0 as master. In summary I set mcspi_write_modulctrl to 1 to set ch0 as single channel (optional), I set MCSPI_CH0CONF with all the settings CLKG,FFE*,..., then I write 1<<9|1 to MCSPI_CH0CTRL to enable channel 0 and use 1MHz, then write to MCSPI_TX0 hoping it should transfer data Dec 30 21:04:46 using SINGLE is recommended yes Dec 30 21:04:58 did you also set FORCE (bit 20) in CH0CONF ? Dec 30 21:05:20 SINGLE isn't specific to channel 0 btw, it works for any channel Dec 30 21:06:23 "write 1<<9|1 to MCSPI_CH0CTRL" .. uhh, so you just overwrote the settings you did earlier such as FFE* ? Dec 30 21:07:48 never mind, CTRL vs CONF Dec 30 21:08:00 jeez I'm not paying attention today Dec 30 21:09:55 no worries, I'm just going to try with sysconfig just in case Dec 30 21:11:31 maybe write a little test that saves all changes of IRQSTATUS and/or CH0STAT into a buffer until timeout (e.g. a fixed number of loop iterations) so you can dump that and see what status changes happened during the transfer Dec 30 21:12:34 sysconfig won't have any impact and should just be SIDLEMODE=2 AUTOIDLE=1 Dec 30 21:13:00 CLOCKACTIVITY=0 probably (that's the safest value anyway) Dec 30 21:13:28 you're right sysconfig doesn't seem to change the underlying issue Dec 30 21:13:30 doesn't matter unless the module is being disabled in prcm (for suspend or for runtime power management), which isn't the case Dec 30 21:14:26 22:04 <@zmatt> did you also set FORCE (bit 20) in CH0CONF ? Dec 30 21:15:01 no, I didn't set force Dec 30 21:15:22 I can try now Dec 30 21:15:32 generally speaking you want CS to remain asserted during the entire transfer sequence, even if it is temporarily idle (e.g. data not supplied fast enough) Dec 30 21:15:46 wow Dec 30 21:16:05 without FORCE, McSPI is allowed to deassert CS in between words Dec 30 21:16:27 which most spi slaves don't tolerate, at least none of the ones that I've ever used Dec 30 21:16:29 that had an effect! Dec 30 21:16:43 at the very least you should see CS being asserted the moment you enable the channel Dec 30 21:17:59 I can see 174 samples with 0,1,1,1 and then finally changing with about 6 pulses on the clock pin Dec 30 21:18:31 great progress, thank you Dec 30 21:18:34 I have no idea what that means. how are you monitoring this? using a scope? Dec 30 21:20:44 also, it might be informative to test without fifos until you better understand what's going on... you might not even need it for performance if you're using it from PRU, if TURBO is enabled... speaking of which, enable TURBO in CH0CONF Dec 30 21:20:47 I'm capturing samples at 2msps with my other pru Dec 30 21:22:44 without TURBO it can't start the next word until the previous word received has been removed from the RX buffer... even with RX fifo enabled (and not full) it still takes time for the word to be moved from RX buffer to RX fifo and slows down the transfer Dec 30 21:22:46 that's really great progress, no rush, I have something to look at closer now :-) Dec 30 21:23:51 actually I want to use it single shot (not continuous mode) so it may be fine, but I'll take note Dec 30 21:24:07 ah your entire transfer is a single word? Dec 30 21:24:27 right, but you actually _require_ a CS transition iirc? Dec 30 21:25:02 which also requires FORCE (and disabling/enabling the channel between transfers) if you want to guarantee this happens Dec 30 21:25:35 also, in that case FIFOs are pointless and TURBO is irrelevant Dec 30 21:25:39 true, I saw CS going briefly low then back up the settles down, looks like a short glitch in mcspi0 Dec 30 21:26:30 hmm, the data pins are high-impedance outside of transfers.. I don't think chip select should be Dec 30 21:26:45 yes, I send a single word and read a word, then I'd expect cs to go up Dec 30 21:29:10 you sure you're using sufficient time-resolution to examine these signals? (maybe accidently configured a higher bitrate than intended?) Dec 30 21:30:08 anyway, I remember mcspi had some idiosyncrasies, though it didn't too difficult to get working... I'm not sure if I saved my test code from back then, I can't seem to find it anyway Dec 30 21:30:25 it was many years ago on a different TI SoC Dec 30 21:32:49 I noticed very very few examples on the web, I cannot blame them, not very straighfoward to program it directly. but surely could be easier using some kind of wrapper Dec 30 21:33:33 like the python adafruit wrapper is very easy to use, but uses kernel driver Dec 30 21:33:49 (not sure if they work with the mcspi though) Dec 30 21:34:09 mcspi has a linux driver yes Dec 30 21:34:10 duh Dec 30 21:34:12 :P Dec 30 21:34:41 hence can be used via the generic linux mechanism for userspace spi access ("spidev") Dec 30 21:34:46 or any wrapper thereof Dec 30 21:35:28 however it would need to use DMA for any remote chance of being real time Dec 30 21:35:53 dma improved throughput, it increases latency Dec 30 21:36:06 the mcspi driver uses it for sufficiently large transfers Dec 30 21:36:33 (because otherwise the overhead of setting up the dma transfer negates its benefit... this is definitely partly due to stuff in the linux kernel being inefficient) Dec 30 21:38:16 unless you mean dma request using external pin (which iirc is an option), that obviously has very low latency, but definitely isn't supported by the kernel driver :P Dec 30 21:40:06 I see, thanks again Matt!!, I'm going to try out an old usb jack gadget now Dec 30 21:43:42 how many drivers do you think there are for lcd panels Dec 30 21:44:01 touchscreen drivers Dec 30 21:44:03 sorry Dec 30 21:44:11 there are a lot of LCD panel drivers Dec 30 21:44:17 my visuals are working now Dec 30 21:44:27 well most touchscreens are usb HID devices Dec 30 21:44:32 no touch functinoality though =( Dec 30 21:45:53 in the overlay I see compatible = "edt,edt-ft5x06"; Dec 30 21:46:06 I am wondering if I need to switch that out as well Dec 30 21:46:18 that's an i2c touchscreen controller Dec 30 21:47:40 "FocalTech FT5x06 family" Dec 30 21:48:02 i.e. it should be in your overlay if and only if you have such a touchscreen controller connected to that i2c bus Dec 30 21:49:18 hmmm let me check Dec 30 21:52:06 This communicates to the BBB using Dec 30 21:52:06 the I2C #1 channel. A Dec 30 21:52:39 also the driver is focaltech Dec 30 21:52:45 so i think it should work as is Dec 30 21:52:50 hmmmmm **** ENDING LOGGING AT Thu Dec 31 02:59:57 2020