**** BEGIN LOGGING AT Mon Jun 03 02:59:57 2019 Jun 03 11:00:57 would some beagle experts like to help update this: http://socialcompare.com/en/comparison/rpi-and-beagle-models-comparison-4wypyz79 Jun 03 11:03:18 all beaglebone variants use an AM3358B-100 (either in ZCZ package or embedded in one of the OSD3358 SiPs) Jun 03 11:04:21 the eMMC storage should probably be listed Jun 03 11:04:22 except the upcoming BeagleBone AI Jun 03 11:04:36 yeah Jun 03 11:04:44 I meant currently available beaglebones Jun 03 11:05:10 weird that ram is listed under "SOC" .. it isn't part of the SOC Jun 03 11:06:10 @jkridner[m], ok cat's out..... where to find more about BeagleBoneAI? Jun 03 11:06:22 also weird that CPU clock is below the auxiliary cores instead of grouped together with the information about the main CPU Jun 03 11:06:50 the ram is DDR3L-800 Jun 03 11:10:19 @zmatt this chart began as a comparison of RaspberryPi hardware so it was layed out as you see it. I added a couple things like the row for number of realtime units and a few others as sometimes that is important and it's a major distinction between the Pi and beagle hardware. Jun 03 11:13:05 some of the interfaces should probably indicate the number of such interfaces, e.g. 2x CAN, 2x I²C, 2x SPI, 4x UART (+ console port + another one that's tx-only + another one in PRUSS) .. although there's of course the detail of not being able to use all of it simultaneously Jun 03 11:16:12 btw if "HDMI audio" counts as audio out for the RPi Zero, it should also count for the BBB(W) and the row should probably be renamed to just "Audio Out" Jun 03 11:16:50 also the BBB(W) does not have an OTG port, it's a device port Jun 03 11:17:00 ditto for the pocketbeagle Jun 03 11:22:31 @zmatt working to correct some of that, best as I know it... but as anyone can edit I figured I'd point those here at it to take a look and if anyone chooses to - contribute to getting the info right. I didn't enter the info on the pocket beagle or black wireless, I'm just working to correct and update what someone else filled in Jun 03 11:25:50 an OTG port is a dual-role (host/device) port (using a micro-AB receptacle, not micro-B or mini-B) that supports detecting the role to assume (using the ID-port) and optionally change that role on the fly (using HNP) Jun 03 11:28:48 the rpi zero does not support OTG btw Jun 03 11:29:01 I think Jun 03 11:29:06 unless I'm misreading this Jun 03 11:35:49 yeah it's definitely not a compliant OTG port since it lacks the necessary power switching logic (which also means that if the rpi zero is used as usb device but is powered separately then it's a very non-compliant usb device that backfeeds 5v power, is unable to detect attachment and switch its data-line pull-up, and may damage the upstream port Jun 03 11:35:54 ) Jun 03 11:59:38 JGalt: bbb.io/ai Jun 03 12:02:50 JGalt: lots of more updates/errors. where all will this be picked up... as in, why should I create an account and edit here rather than elsewhere? Jun 03 12:03:16 zmatt: I think pi zero does support OTG. Jun 03 12:03:28 though none of the pi 1-3 do. Jun 03 12:03:49 maybe just dual-role? Jun 03 12:05:32 I don't think there are 40 GPIO on any pi.... just saying it has a 40-pin header doesn't say much about the GPIO. Jun 03 12:05:54 BeagleBone's have 65 digital and 92 total pins on headers. Jun 03 12:06:18 the table doesn't have analog outside of audio. Jun 03 12:07:08 peculiar how the width/height are swapped vs. Pi, which makes for an odd comparison. Jun 03 12:07:34 I like to remind people they pretty much copied our width/height, but forgot to round the corners and therefore they don't fit in the mint tins. Jun 03 12:08:17 th Jun 03 12:08:18 for the Black wiki, please don't use circuitco.com. Use elinux.org or github.com/beagleboard/beaglebone-black/wiki Jun 03 12:08:35 one of the annoying things about the pi is the way connectors come out every side Jun 03 12:08:51 makes it very untidy if mounted Jun 03 12:09:40 BeagleBone's also have Cortex-M3. Jun 03 12:09:51 artag: +! Jun 03 12:11:21 it works OK for intended purpose as an educational computer but bb is better for an industrial or built device imho Jun 03 12:11:38 lots of other useful peripherals like PWMs/Timers, eQEP, eCAP, etc. aren't included in the list. Jun 03 12:12:51 you can also simulate lots of things with prus Jun 03 12:23:33 @jkridner thanks for the link, look forward to release of the board. I'll try to get the suggestions noted here worked in to the comparison. Said site just seems like a good one as it came with a high google rank and a comparison of boards not found elsewhere. then add to that the ability to customize the tables. It has allowed me to build on the work of others in a true open source fashion Jun 03 12:33:09 jkridner: I'd omit the m3 from mention since it's not really relevant to anyone but the most sophisticated programmers who want to do crazy custom things in low-power modes and can cope with the severe limitations of the cortex-m3 subsystem Jun 03 12:33:29 in practice it's just part of the power management logic Jun 03 12:36:16 jkridner: and the pi zero is definitely not OTG since the port can only be safely used as device-port if it is being bus-powered via that port, which precludes using it in host-role Jun 03 12:42:41 when self-powered (via the power connector or header) it is a non-compliant port that can somewhat safely be used in host role (although I think it lacks overcurrent protection?) while it's dangerously non-compliant to use in device role Jun 03 12:43:27 these usb compliancy problems would also be great to include in a comparison :P Jun 03 12:44:23 ++ Jun 03 13:24:24 jkridner: also, the rpi zero has a micro-B receptacle, not a micro-AB receptacle, so no standard-compliant otg adapter would fit in it Jun 03 13:25:58 yuck. Jun 03 13:26:03 (AB doesn't have the beveled corners: https://www.te.com/content/dam/te-com/images/consumer-devices/global/infographics/micro-usb-mating-types-1024.jpg ) Jun 03 13:42:01 zmatt I don't think I've seen many A-B type connectors on things. Jun 03 13:46:09 I know, my phone actually has a micro-B receptacle which is pretty bullshit since it means that OTG adapter that physically fit in it are not standard-compliant and vice versa Jun 03 13:46:49 I've seen a good hypothesis about why this is: "testing a device for OTG compliance costs almost twice as much as testing a simple high-speed device. There is also much more work in the design phase, and much more risk of failing the compliance, having to make design iterations, and going through testing again. Since the OTG capability isn't used by many consumers, manufacturers don't feel the need to ... Jun 03 13:46:55 ...advertise full OTG compliance. Jun 03 13:47:38 so they basically just certify as a device only, which just "happens" to be able to take on a host role using certain non-compliant cables/adapters :P Jun 03 13:50:00 @zmatt I'm using the pi zero as a host. I have a hub attached to the otg port and I'm using a keyboard and mouse. I've also used it as a gadget but due to the way the default config is done one needs a keyboard and mouse with the pi unless you hack the image to setup gadget mode. Jun 03 13:50:45 JGalt: okay, and? Jun 03 13:52:19 @zmatt just saying from experience that it works both ways, but learning from this chat how better standards compliance would be nice Jun 03 13:52:41 JGalt: I never claimed it can't be used that way, in fact I mentioned it can Jun 03 13:52:47 but it's not an OTG port Jun 03 13:52:57 just a non-compliant dual-role port Jun 03 13:54:22 ah, ok technical difference. to most of us usuns OTG and dual role are synonymous Jun 03 13:54:38 whose non-compliance requires the use of a non-compliant cable in host mode, and whose non-compliance may be hazardous to other devices in certain circumstances (mainly when used in device role while self-powered rather than bus-powered) Jun 03 13:55:06 ....at least from a practical view Jun 03 13:55:21 @zmatt agreed! Jun 03 13:56:15 I'm all for following proper standards! Jun 03 13:58:37 especially when that standard was designed to prevent hardware from getting damaged Jun 03 13:59:33 as it is now, connecting an rpi zero in device-role to an unpowered host may damage that host Jun 03 13:59:56 (if the rpi is powered via some alternate route) Jun 03 14:01:13 actually harm may come to the host whether it is powered or not Jun 03 14:01:15 zmatt the weird thing is I use OTG on occasion, however it is understandable because the majority just use a device as a peripheral Jun 03 14:02:01 @zmatt, interesting observation, Wonder if the RPi foundation would accept liability there? Jun 03 14:02:04 GenTooMan: I don't feel it's understandable... I don't feel like testing for OTG compliance would really be that much of a burden for large phone manufacturers Jun 03 14:06:51 this is one of the things I have really liked about the beagle hardware is the lack of need for a keyboard and mouse dedicated to the device to get started. The default ethernet gadget setup in the default images makes beagle really easy, just plug and go Jun 03 14:31:49 that's purely the default image though Jun 03 14:42:48 zmatt point taken. However it's become the norm. People making these decisions are also in a hurry however, a delay of 1 to 2 weeks is often very unacceptable to businesses. I swear they make schedules based on ambition not what the proper thing to do is. Jun 03 15:15:49 m Jun 03 15:46:31 GenTooMan: I also partially blame the USB consortium for being so lax with their trademark Jun 03 15:52:34 Are there any instructions for compiling on the BBB for modules? Jun 03 15:53:02 i.e. small modules. Jun 03 15:54:48 I mean...I did some research and found different ideas online and went to the source of the Linux kernel online. Jun 03 15:54:49 ... Jun 03 15:55:33 I just have not found exactly how I would do this w/ small modules outside of "hello world" and "bye world." Jun 03 16:03:21 So, I install headers and then go for modules and compiling? Jun 03 16:23:54 yeap, matching headers are in the matching "linux-headers-`uname -r`" pkg... Jun 03 16:24:01 Figaro, Figaro, Figaro! Jun 03 16:24:05 I got it. Jun 03 16:24:30 I loaded a module but not on boot, yet. Jun 03 16:29:09 Now, onto loading at boot! Jun 03 18:42:07 zmatt, nice speed up with rng_core.default_quality=100... [ 1.006510] random: crng init done vs [ 19.785768] random: crng init done which means xorg/etc load much earlier.. Jun 03 18:53:26 dabbler: please test: https://rcn-ee.net/rootfs/bb.org/testing/2019-06-02/stretch-console/ Jun 03 21:02:25 rcn-ee[m]: :D Jun 03 22:50:37 rcn-ee[m]: sure. did you see zmatt's and my discussion of "resize2fs -M" a few days ago? Jun 04 00:30:11 dabbler, no sorry, been outside gardening, mostly digging holes.. what about it? Jun 04 01:30:13 Holes! Jun 04 01:30:25 Holes for the dead BBBs? Jun 04 01:30:50 gas line for the pool's heater.. Jun 04 01:31:00 Even more complicated. Jun 04 01:31:13 What happened to the old one? Jun 04 01:31:27 that was easy, compared to the hole i had to dig for the pool.. Jun 04 01:31:32 Ha! Jun 04 01:31:37 Seriously? Jun 04 01:33:24 Did you have a ditch witch? Jun 04 01:33:46 no, i'm cheap.. Jun 04 01:33:50 Tiller? Jun 04 01:34:01 Shovel only? Jun 04 01:34:10 Sheesh. That is some work, there. Jun 04 01:34:15 for the main pool, yeah for the rest just post hole digger.. Jun 04 01:34:21 Aw. Jun 04 01:34:51 rcn-ee[m]: we were wondering what you'd think of adding to your build process a "resize2fs -M" and truncation step to shrink the images before compressing and uploading them, accompanied by a resize2fs upon first boot (to expand to fill the SD card). this would be primarily in the interest of minimizing image-writing time and flash wear on the user end. the automatic expansion would also eliminate that extra step for those running off SD Jun 04 01:34:51 . Jun 04 01:34:53 Cheap works for people who know things or are willing to know things. Jun 04 01:36:05 rcn-ee[m]: I'm currently going through the process manually, and could document the shrinkage step command-by-command Jun 04 01:39:34 i've kinda relied on etcher/bmap-tools to help minimze the image-writing time. ;) Jun 04 01:40:27 i do like the way the pi does it on first bootup.. Jun 04 01:43:36 i might be an unusual case, but i have to write to SD from my android phone with dd haha Jun 04 01:44:05 rcn-ee[m]: should be relatively straightforward to have early boot (e.g. initramfs) check for some file (e.g. /expand-fs-on-boot or whatever) and expand the partition and filesystem to max size if it's there (and then remove it) Jun 04 01:44:17 no python on the phone? Jun 04 01:47:34 zmatt, so the flag we currently use is: /resizerootfs (and we actually passs the rootfs partition name thru that..) all the other details are in /boot/SOC.sh on teh 1st partition.. (size of fat (if used), ext or btrfs).. Jun 04 01:48:54 rcn-ee[m]: haha no, no python in android Jun 04 01:49:44 rcn-ee[m]: surely it can determine the root partition name? Jun 04 01:50:15 i mean, i'm sure it can be installed, but i don't think anyone's gonna go to the trouble when they could just dd Jun 04 01:50:15 you don't want to stick that in the image since it might be flashed to sd card or directly to eMMC via bbblfs/beagleboot Jun 04 01:51:01 and you know the current images are just a single ext4 partition so no other cases that need consideration Jun 04 01:51:19 also, unless people look in the directory of your server, they won't know about the bmap. it's not linked from the wiki, at least that i've seen Jun 04 01:51:51 if you shrunk the images, you wouldn't even need to make and post the bmaps :) Jun 04 01:51:56 just sfdisk + partprobe (if doing online resizing) + resize2fs Jun 04 01:52:38 zmatt, dual drive's get interesting.. there's a push to switch to efi, that forces us back on a fat partition.. Jun 04 01:53:03 dabbler, it's a recent change.. i kinda got pissed off at the etcher dev's when they nuked the cli tool... Jun 04 01:53:04 ew, efi? Jun 04 01:53:23 because u-boot isn't quite bloated enough yet? Jun 04 01:54:21 also, there's an efi implementation for the am335x ? Jun 04 01:54:45 rcn-ee[m]: and what do you mean by "dual drive" ? Jun 04 01:54:56 all you need to know is the device and partition number of the rootfs Jun 04 01:55:03 and that's surely information available in initramfs Jun 04 01:55:54 or alternatively during early boot (since you can do online resizing it doesn't have to be in initramfs) Jun 04 01:57:50 oh, it's actually enabled and mostly works today... --efi flag in setup_image.sh script.. Jun 04 01:58:20 it just doesn't load the dtb file... there's a goal to the all the overlay stuff in efi, then you can change things thru serial/video on bootup.. Jun 04 01:58:54 while playing around with it, also discovered u-boot doesn't scrube memory.. you can load a *.dtb and reboot, and it'll still be there for the next bootup.. Jun 04 01:59:06 dual drive... eMMC and microSD.. Jun 04 01:59:31 why would you want that? Jun 04 01:59:56 I actually recommend anyone who wants to boot from sd card to wipe eMMC entirely Jun 04 02:00:14 to avoid a mismatch between u-boot and the image Jun 04 02:04:43 btw zmatt, on sd or eMMC boot... do you know if there's any other control registers we could read.. https://github.com/RobertCNelson/boot-scripts/issues/93 we can "read" the boot pin but wish there was another register we could read to which "worked"... on teh am335x.. Jun 04 02:05:59 sysboot can be read from the control module via /dev/mem Jun 04 02:06:11 like you already seem to know there Jun 04 02:06:22 of course that doesn't tell you which option was picked Jun 04 02:06:40 that *might* still be in internal SRAM, if it hasn't been clobbered by u-boot or the kernel Jun 04 02:07:07 more sensible would be to have u-boot write that info into the DT Jun 04 02:07:13 that's what would be cool.. Jun 04 02:07:16 in /chosen or so Jun 04 02:07:48 yeah for new versions we can do that, trying to detected ancient crap. ;) Jun 04 02:15:14 just check where bootrom pus the booting structure (address passed to SPL via r0) and whether that's still intact by the time linux has loaded Jun 04 02:15:18 *puts Jun 04 02:16:20 the byte at offset 8 indicates boot device (8 = mmc0, 9 = mmc1) Jun 04 02:25:22 or just use Yocto images, that is standard with them Jun 04 02:26:05 ds2, so you have a script, that reads the version of u-boot on both media's and which "booted" for debugging? ;) Jun 04 02:27:01 i was referring to resizing Jun 04 02:27:38 why do you care so much about version of U-boot? 1 version should be good enough for the life of the board! Jun 04 02:29:37 well when we are shoving features in u-boot to enable customers wants/needs.. Jun 04 02:30:32 this is mostly about overlays and detecting mis-configurations, instead of blindly telling everyone to nuke the eMMC, it's easier to say, your verison of u-boot doesn't support features x, so nuke it... Jun 04 02:31:45 features should not go into a bootloader Jun 04 02:32:13 ds2, linux developers don't care about overlays.. Jun 04 02:32:17 just because these board happens to be hard to brick doesn't mean all boards are Jun 04 02:32:31 rcn-ee[m]: heh... _I_ don't care about overlays ;) Jun 04 02:33:24 rcn-ee[m]: on an unrelated thing - do all BBAI images run on X15? (run as in boot) Jun 04 02:33:25 ah! see i care about the customers.. they like features and options.. overlays give them that.. Jun 04 02:33:48 different approaches to features Jun 04 02:34:17 my approach is a minimal bootloader and do things elsewhere) Jun 04 02:34:22 there's no offical bbai image, it's still hacked up.. the brcmhd driver can't be natively built, so it's a dd of Jason's sd card.. Jun 04 02:34:38 x15 should boot, i had made sure the version of u-boot worked on both.. Jun 04 02:34:58 does jason's SD card have TIDL preinstalled? Jun 04 02:35:39 tidl requires v4.14.x in our repo.. ti-argo's stupid cmem driver is version locked.. Jun 04 02:36:02 but yes tidl is preinstalled, jason's demo'd a tild demo at embedded world on the ai.. Jun 04 02:36:35 oh nice Jun 04 02:36:48 but you lose wifi when you switch.. Jun 04 02:37:06 going to use it on an x15 Jun 04 02:37:08 i see in the git repo, jason got an updated wifi firmware today, so i'll give that a shot tomorrow.. Jun 04 02:37:22 want to see how different preformance wise is the x15 vs the jetson Jun 04 02:37:30 for CNN's Jun 04 02:37:43 Grab the latest x15/lxqt image, tild is pre-isntalled.. Jun 04 02:38:14 https://rcn-ee.net/rootfs/bb.org/testing/2019-06-02/stretch-lxqt/ Jun 04 02:38:17 lxqt? does that require a monitor/kb for EULA appeasement purposes? Jun 04 02:38:33 ( i don't remember if the iot image has tild installed on teh x15 ).. Jun 04 02:38:44 EULA? i don't worry about that.. Jun 04 02:39:27 this one right - https://rcn-ee.net/rootfs/bb.org/testing/2019-06-02/stretch-lxqt/am57xx-debian-9.9-lxqt-armhf-2019-06-02-4gb.img.xz Jun 04 02:39:36 yeap.. Jun 04 02:39:49 cool.. one step ahead of the jetson image...that wants a KB/Monitor for EULA crap Jun 04 02:40:25 I just want to run a CNN on it to see if it is faster then a desktop w/o GPU accel Jun 04 02:40:28 crap, here's what else you have to do on top of that.. (i need to package teh tidl-api).. Jun 04 02:40:32 https://github.com/rcn-ee/tidl-api/tree/v01.02.02-bb.org Jun 04 02:40:54 Follow the "Debian Build", the rest was my documentation.. Jun 04 02:42:02 on top of the image I pasted? Jun 04 02:42:08 or on top of the iot image? Jun 04 02:42:23 ds2: also ping jkridner , as he wrote a step by step guide for all the other bits, for the tild demo they did.. Jun 04 02:42:51 ds2, on top of the lxqt-stretch based image, the tild examples use xorg.. Jun 04 02:43:25 (back on the original topic - while I may not agree on the phillosophy, I greatly appreciate you hiding it all being brain dead simple shell scripts. Very much appreciated and a BIG BIG thank you) Jun 04 02:43:50 rcn-ee[m]: ah... is the headers installed? I can probally figure out how to make it headless from the TI docs Jun 04 02:44:24 my 'reference' image is a networked camera and reference output via a webserver (jpeg in, jpeg w/boxes marking it out) Jun 04 02:45:24 sadly, the headers lost out to space, just do "sudo apt update ; sudo apt install linux-headers-uname-r" (this riot irc bridge doesn't let me do special escape characters..) Jun 04 02:49:46 laughs... vendor... the driver works for us on i.mx8... yeah, we know that.. we are dealing with am57xx sdio.... Jun 04 02:50:27 that works Jun 04 02:50:42 apt is easy to deal with Jun 04 02:51:14 what is the problem? (I don't have a BBAI yet) Jun 04 02:51:46 that broadcom chip should be somewhat mature... I think it is used in many android phones, right? Jun 04 02:52:06 so on the bbai, we used the same wifi module that is on the PI... It's cheap, and supports all the new stuff.. Jun 04 02:52:19 and it uses the sdio bus... which means compatiable... Jun 04 02:52:42 tuns out ti's sdio bus is different... or the brcm sdio assumes something else.. Jun 04 02:53:00 it looks like no one has previously tried this module on am57xx.. Jun 04 02:53:55 as expected the ti guys don't want to touch it, because it's not a ti radio.. Jun 04 02:54:13 and cypress/broadcom is as supported as one would expect.. Jun 04 02:54:23 and cypress/broadcom "guys" are as supported as one would expect.. Jun 04 02:55:35 kinda weird, you'd think sdio is sdio :P Jun 04 02:56:29 i thought that too, turns sdio is a random spec, implement any you want of these paramters, and pray the other side can handle it.. Jun 04 02:56:57 I mean, I'm pretty sure it isn't, so that means one of the two sides is non-compliant Jun 04 02:57:09 assuming whatever problem you have is actually in the protocol and not some driver/driver interaction Jun 04 02:57:18 eh, both sides are non-compliant, and neither side cares... Jun 04 02:57:46 what makes you think that TI's implementation is non-compliant? Jun 04 02:57:51 they claim compliance Jun 04 02:58:25 (iirc) Jun 04 02:58:34 yep Jun 04 02:59:10 I've got nothing for either, they might be both fully compliant.. ;) Jun 04 02:59:11 "full compliance" with SD physical layer v2.00 **** ENDING LOGGING AT Tue Jun 04 03:00:18 2019