**** BEGIN LOGGING AT Thu Feb 13 02:59:57 2020 Feb 13 03:45:36 ericxdu: I think every ARMv7 core other than the A8, A9, and A5 have virtualization support (provided bootrom on the SoC doesn't deny access to it) Feb 13 03:47:52 ARMv7-A I mean Feb 13 03:48:22 and all ARMv8-A cores Feb 13 03:58:56 weather the board has enough resources to do much useful with it... Feb 13 03:59:02 another matter entirely Feb 13 03:59:10 sure Feb 13 04:08:25 virtualization has specific uses but often what people are using such SoC's for aren't it. One has to be careful and only do something a good reason. That is what reason does one need virtualization on something you would use that SoC with? It's much like wanting to run an AM335x core as an X display (doesn't make sense). Feb 13 04:09:03 something a good reason. hmmm time to sleep to much fiddling with my new scope. Feb 13 04:12:57 Hey! Feb 13 04:14:06 Work'eth make me learn! Outside of that idea, I think I am getting closer. Thank you all and to all a nice evening. Feb 13 04:16:00 lol, "Blockchains are like grappling hooks, in that it's extremely cool when you encounter a problem for which they're the right solution, but it happens way too rarely in real life." Feb 13 04:18:37 the problem is people here "cool ideas" and run off the implement them instead of thinking what the minimum and simplest way to do it is. This leads to lots of project failures. Feb 13 04:19:00 here = hear time to sleep Feb 13 04:19:26 this feels like it should be an article in The Onion... https://www.cnbc.com/2017/12/21/long-island-iced-tea-micro-cap-adds-blockchain-to-name-and-stock-soars.html Feb 13 04:24:56 I like candy! <<< That is the idea. Feb 13 04:32:41 Everything I research is related to programming in a known library, i.e. BBIO or WiringPi and etc. Feb 13 04:33:18 If I wanted to use the registers, what type of access does Python have to registers on the BBBW? Feb 13 04:34:02 I mean. Feb 13 04:35:02 I make my calls = something. This something is in the datasheet. Then, I use Python source to script my "somethings" for further use? Feb 13 04:35:05 Does that make sense? Feb 13 04:37:00 So, I need to include "preprocessor" directives in Python somehow. I will learn what allows me to do this in Python instead of C/C++. Feb 13 04:38:18 Then, I need to define my or their naming for definitions which have to equal the assigned register values in hex. or dec. Feb 13 04:39:00 Finally, it is time to program fun stuff w/ my defined namings. Feb 13 04:39:01 Right/ Feb 13 04:40:28 I know why this will get complicated. The smbus2 library only accepts so many definitions. Then, I will need to find a python PWM library too. Mostly, b/c i cannot type one up yet. Feb 13 04:42:06 one comment a person gained several billion EU scamming people with block chain visions. It's like the idiots who threw money at internet companies in the late 90's. Feb 13 04:42:23 set_: a "pwm library" will be of no use for using the servo cape Feb 13 04:43:01 Oh. Feb 13 04:43:14 Hmm. That means, all my functions need to be from my defintions? Feb 13 04:43:36 Say defintions out loud. It is fun. Sorry. Feb 13 04:43:46 definitions. There. Feb 13 04:44:47 I don't know what you mean by that, though it does sound like you're back to ignoring all advice given earlier Feb 13 04:45:03 Okay. No issue. Feb 13 04:46:09 @zmatt: I am trying to find which built-ins give access to me handling registers. I am still learning. Feb 13 04:47:49 __dict__? Feb 13 04:48:00 set_: pineapple Feb 13 04:48:08 (that answer makes as much sense as your question) Feb 13 04:49:37 Okay. Feb 13 04:49:38 Fine. Feb 13 04:49:50 I will keep researching this idea. Feb 13 04:52:11 Oh. Feb 13 04:52:15 iirc the pca9685 uses the usual interface for reading/writing registers via i2c, so the read_byte_data and write_byte_data methods of python-smbus2 probably work Feb 13 04:52:47 Okay but I am trying to call everything beforehand to use in the source I am going to produce. Feb 13 04:54:14 in c/c++, one makes reference via preproccesor directives and also afterwards w/ defining what is what from the datasheet in dec. or hex. Right? So... Feb 13 04:54:21 ??? Feb 13 04:54:52 you're stringing together random concepts into a confusing milkshake Feb 13 04:55:13 For instance, if I wanted to use taco.py in myfood.py, I would have to use from taco import *. Feb 13 04:55:15 Right. Feb 13 04:55:36 go do a python tutorial Feb 13 04:55:40 Fine. Feb 13 07:26:47 zmatt: the white I'm try to enable uboot overlays is a jessie one with 4.4.23 kernel and old bootloader not capable of, I have update kernel and bootloader and bb-cape-overlays , then used a new uEnv.txt but it seems overlays are ignored, later when I'll be back on lab I'll do further check.... Feb 13 07:51:59 fred__tv: maybe the bootloader update script installed a bootloader it deemed appropriate for your ancient system (i.e. still an ancient bootloader with no support for overlays) Feb 13 15:50:26 zmatt: U-Boot 2019.04-00002-g3d8c979660 but don't know if it means something... Feb 13 15:50:45 sounds like it should support u-boot overlays Feb 13 16:10:45 but overlays aren't loaded..... any bootloader log ? Feb 13 16:11:18 just via the serial console... which on the white you can reach via usb Feb 13 16:13:09 yes Feb 13 16:23:59 https://pastebin.com/bx0Abuyb Feb 13 16:25:39 what does your /boot/uEnv.txt look like? Feb 13 16:26:44 although... it doesn't seem to be loading that? but /uEnv.txt instead? that shouldn't even exist. what's in that file? Feb 13 16:28:49 https://pastebin.com/CD8K3wLY Feb 13 16:29:56 arghhhh there's one /uEnv.txt and one /boot/uEnv.txt !!!!! Feb 13 16:30:08 get rid of /uEnv.txt ? Feb 13 16:30:48 kernel or bootloader update should have created the /uEnv.txt and point to that Feb 13 16:31:28 btw for custom capes you should use uboot_overlay_addr4-7 or dtb_overlay, not uboot_overlay_addr0-3 (which are for overriding autodetected overlays for real capes) Feb 13 16:31:45 I don't really know the story behind /uEnv.txt .. I know it existed on ancient images but no longer does Feb 13 16:32:09 I never used /uEnv.txt Feb 13 16:32:13 me neither Feb 13 16:32:29 so why it is recalled at boot now ? Feb 13 16:32:32 but u-boot seems to be loading it on your system, which is probably undesirable, so I'd say get rid of it Feb 13 16:32:47 I think it's a backwards-compat thing Feb 13 16:32:56 but not sure Feb 13 16:33:03 like I said, I don't really know the story behind it Feb 13 16:33:05 so, how to get rid of ? Feb 13 16:33:10 ehm, rm? Feb 13 16:33:35 or rename it if you want to keep a backup of it for some reason Feb 13 16:33:45 e.g. sudo mv /uEnv.txt /uEnv.txt.bak Feb 13 16:34:17 aha ! Feb 13 16:35:56 uboot_overlays: loading /lib/firmware/P8_1wire.dtbo ... Feb 13 16:36:05 woot Feb 13 16:36:48 how helpful serial console is..... Feb 13 16:37:03 you rarely need it, but when you do need it, you really need it Feb 13 16:37:13 not as helpful as zmatt..... Feb 13 16:37:19 :) Feb 13 16:39:36 probably /opt/scripts/tools/developers/update_bootloader.sh causes bootloader to call /uEnv.txt instead of /boot/uEnv.txt Feb 13 16:39:53 no, /uEnv.txt predates /boot/uEnv.txt Feb 13 16:41:13 I think really ancient bootloaders required /uEnv.txt, newer ones still pay attention to it for backwards compatibility reasons (and evidently something in it, or perhaps merely its presence, prevents u-boot overlays from working) Feb 13 16:42:35 trying to see if stretch still has /uEnv.txt... Feb 13 16:43:14 it doesn't Feb 13 16:43:24 (if I find sdcard..) Feb 13 16:44:06 lost sdcard...... Feb 13 16:44:41 ah actually it's there as "bbb-uEnv.txt" with a comment indicating it should be renamed to uEnv.txt if you have certain ancient bootloaders (angstrom or 2013 debian) Feb 13 16:45:12 2013 angstrom or 2014 debian sorry Feb 13 16:46:18 this happens when you still use old things.... Feb 13 16:46:23 yep Feb 13 16:47:49 kids waiting.....thank you again Feb 13 17:25:08 I don't think anstrom even exists anymore it got eaten by the yocto beast. Feb 13 17:25:19 yeah angstrom died a while back Feb 13 17:44:09 indeed https://github.com/Angstrom-distribution <-- last touched in 2015 I guess they moved on http://www.angstrom-distribution.org/ is still around oddly. Feb 13 17:44:38 yeah but the site is completely broken Feb 13 17:44:45 none of the articles have content Feb 13 17:44:55 it's been like this for quite a while already Feb 13 17:48:10 RIP ... I use to use it on my beagle board hence I remember it LOL 2008 I think? Feb 13 19:12:13 heh, on the bone-debian-9.9-iot-armhf-2019-08-03 image, removing some packages that are irrelevant for am335x-based beaglebones frees up 417M Feb 13 20:33:23 hmmm which are those? Feb 13 20:33:44 I could really use some freed up space Feb 13 20:35:58 sudo apt-get purge firmware-am57xx-opencl-monitor ti-opencl libtiopencl1 ipumm-dra7xx-installer ti-ipc-dra7xx vpdma-dra7xx-installer ocl-icd-libopencl1 ti-c6000-cgt-v8.2.x-installer bb-bbai-firmare firmware-iwlwifi && sudo apt-get --purge autoremove Feb 13 20:37:40 there's a ton more that's irrelevant for many users, but at some point it's easier to start with a console image and install what do you want than start with the iot image and remove what you don't want ;) Feb 13 20:54:01 a legitimate point Feb 13 21:50:40 everything but bb-bbai-firmare because it's bb-bbai-firmware I think but I digress was removed :D Feb 13 22:01:58 oh whoops :D Feb 13 22:02:25 I added that one to the end and it seems I typed it instead of copy-pasting, for some reason Feb 13 22:11:28 zmatt: okay thanks re virtualization on Arm **** ENDING LOGGING AT Fri Feb 14 02:59:59 2020