**** BEGIN LOGGING AT Thu Dec 14 03:00:01 2017 Dec 14 03:01:17 Elpida B4432BBPA-1D-F Dec 14 03:01:34 oh that's the ram Dec 14 03:01:42 right, PoP Dec 14 03:01:55 so... check the DT ? Dec 14 03:04:17 stormbytes: it's a BCM2835, same as the regular zero Dec 14 03:04:43 same as the original pi Dec 14 03:09:55 so all pi variants use the bcm2835, bcm2836, or bcm2837 ... which are basically just the bcm2708 videocore SoC with different choices of ARM subsystem glued onto it (arm1176jzf-s, quad cortex-a7, or quad cortex-a53 respectively) Dec 14 03:16:04 thanks, will google that Dec 14 03:16:49 good luck, none of them have a public datasheet or even a product page Dec 14 03:19:43 if you want a SoC with actual documentation published... use a TI SoC :D Dec 14 03:22:57 is there something comparable from TI? Dec 14 03:23:05 comparable = linux soc in that price range Dec 14 03:23:44 I don't even know what the "price range" is for any of those broadcom processors, they're not available for sale as far as I know (or if they are, their price is definitely not public) Dec 14 03:23:57 afaik they're custom made for the rpi foundation Dec 14 03:24:13 not available for sale?? Dec 14 03:24:19 how's that? Dec 14 03:25:16 like I said, they don't even have a product page at broadcom Dec 14 03:26:13 perhaps if you want a million of them broadcom may be willing to sell them to you, but dunno Dec 14 03:27:50 "The chip is not officially propietary to the raspberry pi foundation but broadcom are notoriously hostile to working with "little guys". Dec 14 03:28:00 "Also the license of the raspberry pi firmware is restricted to use on raspberry pi products, so to remain within the license you would have to make your own firmware builds from the materials broadcom provide (under NDA). Dec 14 03:28:09 "Odroid managed to secure a small batch of BCM2835 and developed a pi-compatible product called the odriod W around it but broadcom refused to sell them further chips." Dec 14 03:28:23 so... good luck with that Dec 14 03:35:04 apparently element14 does offer a service for customized rpi builds Dec 14 03:35:58 (min qty 5000) Dec 14 03:36:33 anyway, this is rather seriously off-topic for this channel Dec 14 03:37:53 Okay, so I don't actually know if I'm trolling right now, but concievably that means I could have 'em make a BeaglePi... Dec 14 03:38:19 I have no idea what you could even mean by that Dec 14 03:38:57 note that it is likely that such custom builds will be way more expensive than a regular rpi Dec 14 03:39:46 And I assume it's intended to be something like "customize the silkscreen for our promotional giveaway" or some such Dec 14 03:40:55 no it's "we were stupid enough to prototype based on the rpi and now we want to turn our mess into a real product.... halp?" Dec 14 03:41:51 Ooooo. Dec 14 03:42:52 Somewhere around here I have a copy of a nastygram sent to a certain maker of only-partly-shitty 3d printers, who built their flagship printer around a beaglebone... Dec 14 03:43:22 ...and then didn't even change the default hostname on the OS image, so one of the guys was trying to ssh into the beaglebone on his desk... Dec 14 03:43:29 loool Dec 14 03:43:30 ...and found himself in the printer instead Dec 14 03:43:50 as root, natch. Dec 14 03:44:33 don't get me wrong, it can be a fine strategy to embed an existing board like the bbb or rpi into your product... but with the bbb you always have the option to later transition to a custom board since all the parts are available off-the-shelf, the same is not true for the rpi Dec 14 03:44:53 yeah, I completely understand it. It's just.... hard to imagine doing so with less finesse. Dec 14 03:45:35 and what you're describing is just stupidity that's not really related to using a prefab product... if they had a custom board they would still have been stupid enough to run a linux system with root login left enabled :P Dec 14 03:45:46 oh lol, about that rpi customization... Dec 14 03:45:49 "So, I've sent you a quote,which resulted in no reply. I talked to your online chat support who have -never heard- of this customization program. I tracked down the number to your sales people, and they never heard of it either." Dec 14 03:46:31 that sounds promising Dec 14 03:46:39 And I now work for a company who ships products with beaglebones inside, so I really can't throw stones here. But our hardware guy is working as fast as he can on the new version which will have the cape stuff and octavo chip all smushed together. Just as soon as he gets a minute to breathe.. Dec 14 03:48:53 we also ship products with beaglebones inside, but ssh access requires public-key authentication Dec 14 03:49:02 :P Dec 14 03:49:21 Yeah. The new kid got tasked with locking down the OS build. I haven't checked on how that's going.. Dec 14 03:49:54 (and hostname is model + serial number) Dec 14 03:50:55 nice. I'm working on a CNC setup to programmatically engrave the product name, part number, and possibly serial number, right into the case of each unit. Fewer stickers = win, IMHO. Dec 14 03:52:28 so it sounds like you're heading down a fine trajectory... embedded beaglebone today, osd335x-based pcb tomorrow, maybe some day a design that uses an am335x directly (if quantity makes it worthwhile to do so) Dec 14 03:54:17 not sure why you're inquiring into messing about with broadcom socs :) Dec 14 03:55:28 I was thinking of it as a gag, honestly. Lemme stick an am335x and a bcm2835 and an esp8266 and an atmega328 onto the same PCB, just to watch the flamewars on hackaday.. Dec 14 03:56:06 and a BASIC STAMP, because get off my lawn! Dec 14 03:56:26 don't forget to shoehorn a CHIP clone in too Dec 14 03:56:36 need some allwinner in that mix yo Dec 14 03:56:39 Oh right, something allwinner.. Dec 14 03:56:58 because the bcm isn't undocumented enough :P Dec 14 03:57:02 sounds like a wonderful platform, I'm sure it'll be a great success Dec 14 03:57:10 oh allwinner has way better docs than broadcom Dec 14 03:57:50 I love how the linux-sunxi people flat-out say allwinner is violating the GPL right on their front page Dec 14 03:57:53 at least for some of their SoCs, dunno the CHIP Dec 14 03:58:42 sure, they're bottom-feeding scum Dec 14 03:59:16 but they do have better docs than broadcom Dec 14 03:59:29 I'll drink to that Dec 14 03:59:36 that's not a particularly high standard to meet, since broadcom has not published any docs on the bcm2835/6/7 whatsoever Dec 14 04:00:08 makes me wonder how the rpi thing got started, tbh. But I left my tinfoil hat in the other room Dec 14 04:00:18 (turns out it makes a good groundplane..) Dec 14 04:00:22 there's some thin pdf documenting some of the peripherals, but it's actually written by an rpi foundation member, not by broadcom afaik Dec 14 04:01:20 the supplement on the quad-a7 subsystem of the bcm2836 actually contained stuff like "I wasn't able to find at what clock speed this timer is supposed to run" or something like that Dec 14 04:02:30 so, yeah, I don't really have much enthausiasm for the rpi family Dec 14 07:43:10 anyone using FreeBSD on their beaglebone black? I'm trying to work out my best method for keeping up to date, making world or working out how to use crochet Dec 14 09:15:04 going back to the discussion about embedding bbb or pis in products Dec 14 09:15:52 one thing I've found much harder with the bbb is documentation and examples to get started on things Dec 14 09:17:04 there seems to be a lot of rapid change with the bbb, makes it harder for the documentation to stay current Dec 14 09:17:55 personally I've found the dto very confusing and it's never worked as documented for me, for example I still can't unload a slot without crashing the bbb Dec 14 09:18:22 I've also experienced issues like failing to boot occasionally (serial noise at bootup apparently, fixed with a uboot config/patch) Dec 14 09:18:41 and most recently, sometimes access to /dev/spi* needs root, and othertimes not Dec 14 09:18:55 I find it hard to imagine building a product around it Dec 14 09:19:24 what do people do to mitigate these issues? use a system like buildroot/yocto? and keep absolutely everything at a known version Dec 14 09:49:05 mattvenn: most of what you're describing are about differences in the default software configuration. obviously when embedding beaglebones in a product you will flash them with particular firmware that includes your own software, rather than continuously using the latest default firmware image Dec 14 09:50:42 the poor documentation is a real issue, but mostly for newcomers... when you work with the bbb on a daily basis, you just get to know it :) Dec 14 09:54:18 as for issues with capemgr/overlays... we don't use them whatsoever, nor do we use cape-universal. we just make a custom DT per product Dec 14 10:00:40 then probably my problem is that I do a projet with it, then it's 9 months till I use it again and it feels like I have to start again Dec 14 10:00:56 it gives me the impression that it's unreliable Dec 14 10:01:38 but you and myself both use it in commercial products right? Dec 14 10:01:54 so, a lot of vendors of embedded products will fix particular software versions at some point in development Dec 14 10:02:09 trust me, there are plenty of devices shipping with a 2.6 kernel today Dec 14 10:02:54 this is not something particular to the beaglebone Dec 14 10:04:17 though to be honest, I rarely see anything break due to updating software Dec 14 10:05:35 like I said, for the most part you're describing changes in the default config. that's something I don't run into since I'm not using the default config, I'm using *our* config Dec 14 10:05:50 what build system do you use out of interest? Dec 14 10:06:19 we're using debian, not a buildroot style environment Dec 14 10:08:22 how do you manage building the image? Dec 14 10:11:14 initially by preparing a template device, and making some tools that make it easy to snapshot a device into a master image and flash that image onto other beaglebones. for ease of updating, most of the software runs in containerized services which can be easily updated by replacing a single (squashfs) file Dec 14 10:11:45 (this was also done to enhance security) Dec 14 10:12:31 interesting, thanks Dec 14 10:13:23 zmatt, do you do that for all /usr/bin/* or just for your main apps ? Dec 14 10:13:40 I really like the idea of having a configuration for buildroot in a repo and then rebuilding images from that Dec 14 10:14:11 but it's nice to have a device to work on immediately and then just use that as the image Dec 14 10:14:17 mattvenn: I agree conceptually, but this was more comfortable and familiar for development, and we just needed to ship a product you know :) Dec 14 10:14:48 yea, I've been looking into buildroot/yocto for a while but still haven't actually used either Dec 14 10:15:20 yocto is awesome mattvenn , i was all worth it for me to dive into it ( aka openembedded) Dec 14 10:15:28 rob_w: it's for the main software Dec 14 10:15:40 zmatt, right ok Dec 14 10:15:59 rob_w: though not much runs outside those containers... mostly things like systemd{,-networkd,-resolved}, dbus Dec 14 10:16:05 i was asking , as i am in the process to get my update procuders some buffs Dec 14 10:17:29 each container basically contains one executable and its dependencies (shared libs etc), so not much is installed on the system itself Dec 14 10:18:04 the shared libs come in by a mountpoint ? or how is squashfs way to do that ? Dec 14 10:18:32 they're bundled together with the executable in the squashfs image Dec 14 10:18:52 hmm ok Dec 14 10:19:03 so if we update libraries on our development system, and build a new image for an application, it automatically includes those updated libraries Dec 14 10:20:31 ok , for me i am thinking of a update procedure with the A<->B model and making use of squashfs somehow Dec 14 10:25:40 that's a fairly different story Dec 14 10:26:00 since you mean the whole rootfs I assume Dec 14 10:30:31 robw: did you try buildroot? Dec 14 10:30:39 looks a bit easier to get started with Dec 14 10:49:34 i used buildroot way back but dropped it for oe long time ago. though i had one product in the field with its manufacturer buildroot system Dec 14 10:50:03 i kept taht and not ported it to oe, its was a small enough system to keep the buildroot for Dec 14 10:50:20 zmatt, yes thats for full rootfs upgrades Dec 14 10:50:44 but i wanted to do have both , full A-B updates and incremental ipk rolling updates Dec 14 10:51:13 but dunno how i end up Dec 14 10:51:37 i would only make sense if i go the full way and therefore then be able to drop some older toolchains Dec 14 11:47:59 HI Dec 14 12:05:50 Stretch IoT (non-GUI) for BeagleBone and PocketBeagle via microSD card Debian 9.2 2017-10-10 4GB SD IoT ,try to update my bag Dec 14 12:07:01 But since it was a STRETCH, something different and I got failure Dec 14 12:09:26 okay, thanks for sharing **** BEGIN LOGGING AT Thu Dec 14 12:51:01 2017 Dec 14 17:52:28 playing with GPIO Dec 14 17:52:45 is there a list with the numbers I have to export ? Dec 14 19:03:15 found this one: https://github.com/adafruit/adafruit-beaglebone-io-python/blob/master/source/common.c Dec 14 19:03:38 how reliable is the information in pins_t table[] ? **** ENDING LOGGING AT Fri Dec 15 03:00:02 2017