**** BEGIN LOGGING AT Wed Nov 02 03:00:00 2016 Nov 02 04:51:53 parallel computing is sure shady Nov 02 14:59:31 that default mass-storage device type msdos file system that you get hwen you usb a beaglebone black, is there an easy way to make the read-write Nov 02 15:00:01 i'm looking in parted to see if its a flag.. Nov 02 15:00:39 but its not Nov 02 15:36:13 hi there channel :-) Nov 02 15:36:27 zmatt: fyi, since we were talking about this y'day - 4.9.0-rc3-ti-r1 Nov 02 15:39:55 beside me BBB connected to desktop/laptop by usb, to a display by micro hdmi and logitech K400 keyboard Nov 02 15:40:48 uname -m says armv7l Nov 02 15:41:13 is it l or I? Nov 02 15:41:29 or 1 Nov 02 15:43:45 it's Rev. A5C Nov 02 15:47:24 lol i guess you could uname -m | grep l Nov 02 15:47:36 see if it turns up Nov 02 15:54:39 not X environment Nov 02 15:56:04 just console debian@arm:}]]]+**⁺[[+++çç poo Nov 02 15:56:21 sorry Nov 02 15:57:36 just console debian@arm:~$_ flashing underlined symbol Nov 02 15:58:26 not windows desktop manager :-( Nov 02 16:00:36 trying to launch openbox but it says: Openbox-Message: Failed to open the display from the DISPLAY environment variable Nov 02 16:01:03 that's after typing openbox Nov 02 16:04:23 which is the best distro for BBB Rev. A5C, just amstrong the one comes by default? Nov 02 16:06:37 rajesh_, which is the best distro for BBB Rev. A5C, just amstrong the one that comes by default? Nov 02 16:11:42 dury: see this - http://beagleboard.org/latest-images Nov 02 16:12:40 https://beagleboard.org/getting-started#update Nov 02 16:17:42 rajesh_, running debian jessie 8.4 installed on eMMC Nov 02 16:19:00 what a coincidence he/she is out :-( Nov 02 16:21:45 only 813M on /dev/mmcblk0p1 Nov 02 16:22:59 zmatt, can u assist, please? Nov 02 16:31:27 is it bad to flash several times eMMC? Nov 02 16:43:04 v 01 2016 11:13PM PDT Nov 02 16:47:16 So, $dayjob has a few low-volume products that are basically bbb + case + (custom cape), and we're thinking about moving to a compute-on-module approach with our cape becoming the baseboard Nov 02 16:48:50 So I'm on https://beagleboard.org/resources and looking at the "providers of omap35x in other development hardware", and it's all broken links and companies with broken websites and doesn't exactly instill confidence in the ecosystem Nov 02 16:49:38 and I'm realizing why so many commercial products (lookin' at you, FSL3D Pegasus) have an actual BBB inside, since it seems to be the thing most likely to still be available in a few years Nov 02 16:50:38 and I'm rambling these thoughts in here in case I'm missing something, or to see if y'all concur with that assessment. Nov 02 17:06:26 so? Nov 02 17:06:48 is it bad to flash several times eMMC? Nov 02 17:14:44 several is fine, several thousand might be bad Nov 02 17:17:49 myself, do u have your bbb running jessie 8.4 on eMMC, without sd-card. Mine is Rev. A5C Nov 02 18:46:13 hey shpew12 Nov 02 18:48:10 sooo gcc with ti-rtos... not a thing i guess? Nov 02 19:46:34 You mean to run on that rtos or to cross compile for it? Either way I'm sure it could be done. Nov 02 19:47:04 yeah i meant ot cross compile for it Nov 02 19:47:16 we found some examples, but ti's website conspicuously left out any mention of the gnu tool chain Nov 02 19:47:36 Surely they have *some* toolchain out there somewhere? Nov 02 19:47:38 gcc or no Nov 02 19:48:06 they talk about their "ti development something" and iar Nov 02 19:48:19 but i'd like to continue relying on gcc, since we're all developing some expertise in it Nov 02 19:48:34 Maybe it's vaporware and it's all a ruse until they can get something out ^_^ Nov 02 20:20:26 ayjay_t: the core of TI-RTOS at least supports it apparently http://processors.wiki.ti.com/index.php/SYS/BIOS_with_GCC_(CortexA) Nov 02 20:24:13 hey thanks for that link zmatt Nov 02 20:24:35 zmatt: TI-RTOS, isn't that what used to be SYS/BIOS and DSP/BIOS? Nov 02 20:24:58 ti-rtos = sys/bios + more libs Nov 02 20:25:24 I remember that from the DaVinci (the original DaVinci) Nov 02 20:25:40 dsp/bios is the old name of sys/bios, they renamed it since it no longer just targets their dsps Nov 02 20:26:00 It was DSP/BIOS back then, compiled only with the TI DSP toolchain and had a godawful build system Nov 02 20:26:40 though apparently the entrypoint is still called _c_int00 even under arm cortex systems.. lol Nov 02 20:28:21 and it's not a surprise to need the TI compiler when targeting TI DSPs :P Nov 02 20:28:57 though I think there might be c6x support for gcc but I have no idea what state that is in Nov 02 20:32:02 Hi Nov 02 20:32:27 gcc for c6x was never good Nov 02 20:32:44 that much I assumed Nov 02 20:32:57 I've got a Beagleboard b6 and i need some help getting the usb ethernet adaptor working Nov 02 20:33:46 maybe a new attempt using llvm would be more promising Nov 02 20:33:48 thinkfat: c64x+ / c67x doesn't strike me as a difficult target though, the instruction set is pretty clean Nov 02 20:34:38 zmatt: the output was never as performant as ti cc Nov 02 20:35:16 heh, and I've never been particularly impressed by the output of cl6x either Nov 02 20:35:34 ubern00b: just ask your question Nov 02 20:36:51 which kernel module do i need to download for a usb ethernet adaptor? Nov 02 20:37:00 thinkfat: one thing that annoyed me is that the C compiler imposes all kinds of restrictions that render various neat features unusable Nov 02 20:37:13 ubern00b: normally none Nov 02 20:37:40 I'm running angstrom linux from 2011 so i'm assuming the module isn't present Nov 02 20:38:23 ubern00b: that depends on the kernel configuration, but I think the relevant modules have been part of linux for quite a long time already and are normally enabled by default Nov 02 20:39:28 ok, perfomring an lsusb lists all usb devices, however the one for the usb ethernet only shows the hardware ID Nov 02 20:41:06 ubern00b: anything interesting in kernel log regarding the device? Nov 02 20:42:02 ubern00b, it would be best to just search: https://groups.google.com/forum/#!forum/beagleboard as your running a 'very' old Angstrom, not that many remember, and not all the network modules where enabled in the early versions.. Nov 02 20:42:26 maybe then upgrade the system? I noticed there's now a jessie release for the xm but dunno the original Nov 02 20:42:41 there is a more recent angstrom anyhow (from 2012) Nov 02 20:43:11 I've been looking online for a newer version but ifo is hard to come by now Nov 02 20:43:19 the problem, everything is thumb2 now-a-days.. the xm has a later core, but the older omap34xx just falls apart on everything. ;) Nov 02 20:43:54 yeah, i just want to turn this old thing into a very basic NAS lol Nov 02 20:44:38 rcn-ee: oh wow, since almost every TI SoC that has an a8 has r3p2 (with no really problematic errata) I almost forgot that older revisions exist with potentially real problems Nov 02 20:44:58 ubern00b, https://angstrom.s3.amazonaws.com/demo/beagleboard/Angstrom-TI-GNOME-image-eglibc-ipk-v2012.01-core-beagleboard-2012.01.11.img.gz Nov 02 20:45:21 ubern00b: I just saw it listed on http://beagleboard.org/latest-images Nov 02 20:46:07 zmatt, yeah those r1pX cores are fun. Biggest problem, u-boot had to enable thumb2 to fit on the bbxm's, however the old beagle can't even get out of SPL due to thumb2. ;) Nov 02 20:46:41 thanks a lot for that, i'll try it out tomorrow Nov 02 20:46:51 sorry for being so frustrating lol Nov 02 20:47:23 ubern00b, you should just pick up a bbb. ;) with a dedicated network interface and seperate usb for your storage.. You'll run into less issues then the old beagle.. Nov 02 20:47:45 usb stabilty was always an issue on the orginal beagle's.. Nov 02 20:48:15 yeah, i've got a Raspbery pi 2 which is great but i got this old beagleboard ages ago and i just wanted to get it doing something Nov 02 20:48:22 rcn-ee: which omap3 revision was used? I see that depending on that it might be r1p1, r1p2, r1p3, or r1p7 Nov 02 20:49:24 or there was 3 or 4 revisions used.. i think the ax used r1p2, bx used r1p3.. the xM used a r1p7 i belive.. Nov 02 20:49:52 ok, erratum 657417 (for r1p3 and older) sounds like it probably will have a gcc option as workaround Nov 02 20:52:29 since it affects a 32-bit thumb-2 direct branch instruction that crosses a page boundary and whose target is in the same page as the first half of the instruction Nov 02 20:52:42 that sounds avoidable Nov 02 20:54:01 it's the only erratum present in r1p3 fixed in r1p7 Nov 02 20:54:24 here's the one in u-boot: https://github.com/u-boot/u-boot/blob/f5fd45ff64e28a73499548358e3d1ceda0de7daf/arch/arm/cpu/armv7/start.S#L234-L271 Nov 02 20:55:20 those are all for r1pX though, hence would also apply to the xM Nov 02 20:55:59 unless you remember the xM's core revision incorrectly Nov 02 20:57:48 yeah, omap36xx uses r3p2 Nov 02 20:57:54 Yeah, i don't remember.. ;) Nov 02 20:58:06 so none of those errata apply to it Nov 02 20:58:19 ok jumping from r1pX to r3p2 makes life more interesting Nov 02 20:58:22 and it can handle thumb2, unlike it's older omap34xx.. Nov 02 20:58:23 ;) Nov 02 20:58:50 yeah it's the same core revision as on the dm81xx and am335x Nov 02 20:59:13 the latest/last a8 revision Nov 02 21:01:16 rcn-ee: did you see my comment on your gist btw? (I have no idea whether that results in a notification or something) Nov 02 21:02:15 they don't anymore.. I've sent a couple nasty emails to github about the "activity log" change, how it's udderly-useless... they agreed, but no changes.. ;) Nov 02 21:02:31 https://gist.github.com/RobertCNelson/f137dee9139f954bbf0a187127b2e5db that one Nov 02 21:03:41 the patch to fix spi device numbering is also impressive... it consists of removing two lines of code from the mcspi driver (the spi driver core actually supports of_alias based numbering but mcspi had overridden is with a static id counter, EW EW EW) Nov 02 21:03:50 Cool. ;) If we had alias's for the pwm's that would make people happy too. ;) Nov 02 21:04:34 https://github.com/beagleboard/bb.org-overlays/blob/master/examples/cape-unversal-pwm.txt#L1-L9 Nov 02 21:04:42 my patch for drivers/mmc/core/host.c can probably be used as template for other subsystems Nov 02 21:04:47 ^ that's what we are having people do. ;) Nov 02 21:04:50 it's based on the i2c driver Nov 02 21:04:55 *i2c core Nov 02 21:05:25 even without stable numbering, at the very least you could use an udev rule Nov 02 21:06:45 btw I also have some enhancements for gpio-of-helper and the sysfs interface for gpio: https://github.com/dutchanddutch/bb-kernel/tree/am33x-v4.8/patches/gpio Nov 02 21:07:35 combined with a small udev rule, it makes DT-declared gpios appear as /dev/gpio/$name/ Nov 02 21:07:37 thank's all merge those into the v4.9.x-ti tree. (it's running pretty good on my test farm right now) Nov 02 21:07:58 zmatt, there's a gpio option for that now in dt.. Nov 02 21:08:07 ? Nov 02 21:08:15 i saw the rasberry pi guys add it into mainline.. Nov 02 21:08:53 if you mean the 'new' gpio device interface in kernel 4.8... linus walleij is nuts if he thinks this is a reasonable replacement of the old sysfs interface Nov 02 21:08:55 https://www.spinics.net/lists/kernel/msg2371041.html Nov 02 21:09:11 "gpio-line-names".. Nov 02 21:10:06 yeah I think I added those names, but I don't think they show up in any useful place Nov 02 21:10:23 yeah, it's tied to "lsgpio"... Nov 02 21:10:47 which uses the new gpio interface, which I regard as dangerous and useless Nov 02 21:11:36 you need to be able to open /dev/gpiochip*, which means you have arbitrary control (direction and value) of all non-kernel-claimed gpios Nov 02 21:12:23 our users like control over that. ;) Nov 02 21:12:25 whereas gpio-of-helper lets you export individual gpios with the direction fixed in DT (unless direction change explicitly allowed) Nov 02 21:12:55 in other words gpio-of-helper is suitable to give non-root permissions via udev Nov 02 21:13:15 gpiochip most definitely isn't, since having right to /dev/gpiochip* amounts to having right to fry hardware Nov 02 21:14:42 plus you still have to search all gpiochips for the right pin and then remember that yourself if you want pin-independent software, e.g. if a different pin might be used for the functionality depending on harware Nov 02 21:15:21 gpio-of-helper sets the gpio line label, and my patches make it available in sysfs to allow udev to make symlinks Nov 02 21:16:21 btw did you say 4.9-ti ? I haven't used the -ti series in ages, in no small part due to the fact it seemed to be stuck on 4.4 Nov 02 21:16:41 I've been using -bone as basis for my kernels (currently 4.8-bone) Nov 02 21:17:00 Yeah, right now ti's 4.9 is just 4.9.. Nov 02 21:17:22 they go between lts's.. so the next jump would be 4.9 -> 4.15.. or so.. Nov 02 21:17:44 right, so I'll continue to use -bone kernels since I don't want to be stuck on lts versions :) Nov 02 21:18:06 i had cleaned-up/unified the patchset at 4.8.x to v4.9.x so they are almost 100% the same.. Nov 02 21:18:42 if you feel like it you might want to browse the commits in my tree to see if there's anything else useful for you to merge Nov 02 21:18:43 v4.9.x brings us hdmi audio.. Nov 02 21:18:56 I try to keep it rebased on the latest bone kernel Nov 02 21:19:22 grabbed the last 12, merging in right now into v4.9.x and it'll be back-ported to v4.8.x-bone. ;) Nov 02 21:19:36 What are the differences between -bone and -ti kernels? Nov 02 21:20:16 puzz-mobile, bone = am335x-no-smp-thumb2, ti = am335x/am57xx/smp (no-thumb2 due to cmem's stupidity)... Nov 02 21:21:01 rcn-ee: Refresh my memory. thumb2 is the executable format? Nov 02 21:21:11 rcn-ee: I also have an experimental patch (not yet pushed to github) to make userspace device mappings (via /dev/mem or uio) use "device" memory type just like kernel ioremap does, instead of "strongly ordered" Nov 02 21:21:14 ti also has a "1-year" support from ti... which basicly means they backport random stuff every month and therefor keeps me busy fixing regressions.. Nov 02 21:21:30 nosmp is a win on non-smp cpus Nov 02 21:21:44 thumb2 means smaller code hence less instruction cache pressure hence faster code Nov 02 21:21:54 so for a beaglebone, -bone is generally the way to go Nov 02 21:21:54 rcn-ee++ Nov 02 21:22:04 puzz-mobile, thumb2 is a compact format.. mixed 16bit/32bit without the penatiy of thumb1.. Nov 02 21:22:18 rcn-ee: how does cmem manage to break that though? Nov 02 21:22:31 Heh. I just upgraded us out of the dark ages to a 4.4.23-ti kernel at work. I should try harder at getting the -bone kernels to run in the future. Nov 02 21:22:47 I don't understand why non-thumb would be used *at all* anymore on armv7 (except for buggy early a8 cores) Nov 02 21:22:58 zmatt, [cmemk: unknown relocation: 51] Nov 02 21:23:30 puzz-mobile: beware that the latest -bone kernels don't have all drivers ported to it yet that older -bone kernels have, e.g. the tieqep Nov 02 21:23:32 i bisected it down to CONFIG_THUMB2_KERNEL, ti's kernel leaves that disabled... i tried patching cmemk to be built with thumb2/interwining.. No win.. Nov 02 21:23:48 I don't care, but if you happen to need one Nov 02 21:23:55 in theory, tieqep should be working on rc4 this weeknd. ;) Nov 02 21:24:07 rcn-ee: someone really needs to kick ti's butt for not compiling with thumb2 Nov 02 21:24:37 want me to look at cmem to see if I can identify the cause of problems? Nov 02 21:25:05 it really only affects the x15; arm <-> dsp interface... Nov 02 21:25:30 i really wish they just used a mainline memory allocater.. there's a bunch of options being posted to solve the memory sharing issue.. Nov 02 21:25:32 I know, but that also affects the -ti kernels which are the default kernels on beaglebone images for some reason Nov 02 21:25:42 zmatt: Thanks. I did a quick and dirty, "will it boot?" test starting with the latest and greatest kernel available in Jessie and stepped back by minor versions each time I was unable to boot. I landed on a 4.4-ti kernel. Nov 02 21:25:58 puzz-mobile: uhh, it should *boot* on any of those Nov 02 21:26:19 puzz-mobile, most of the boot issues, was u-boot (dtb overrideing kernel image in memory) Nov 02 21:26:59 and 4.8 had/has the rtc idle panic thing Nov 02 21:26:59 Oh, ouch. Nov 02 21:27:33 I don't recall having seen a resolution being posted on it? I still have my workaround (which I posted to the list) in place anyhow Nov 02 21:28:06 there was another 10 rtc patches (am335x) posted last week, so i final solution hasn't been merged yet.. Nov 02 21:28:41 zmatt, this is the upstream cmem tree: http://git.ti.com/gitweb/?p=ipc/ludev.git;a=summary Nov 02 21:28:46 kernel module is here: http://git.ti.com/gitweb/?p=ipc/ludev.git;a=tree;f=src/cmem/module;hb=HEAD Nov 02 21:29:10 and my build options on the arm-builder: https://github.com/rcn-ee/ti-cmem/blob/master/build.sh Nov 02 21:29:16 rcn-ee: I was a bit surprised to find it 4.8-bone (unmodified debian package with default dtb) didn't boot at all... I assumed you'd at least smoke-test those Nov 02 21:31:46 Sadly, not as much as i would have liked, my gf lives in my house now, so my hacking hours have been massively cut back. ;) I caught the 4.8.x only after the buidl failed.. Nov 02 21:32:30 ah, gf, that explains ;) Nov 02 21:34:03 I'll see if I can take a peek at cmem when I get to work Nov 02 21:38:08 yeah I somehow thought you might run all builds through some automated test on actual hw Nov 02 21:40:36 i do have 11 setup right now: http://rcn-ee.homeip.net:81/farm/uptime/ but they rely on the *.deb being built. ;) Nov 02 21:41:34 i need to find some barrel plug -> m-usb connectors then i have another 6 bbg's i can hook up to my power relay.. Nov 02 21:43:13 wouldn't it be easier to use the P9 pins instead of the barrel plug? Nov 02 21:45:15 btw, I've seen more than one person here trying but failing to get uio_pruss working on current jessie images, is there info on how you're supposed to do this? (I saw the comments in the .dts but that's not helpful to Average Users) Nov 02 21:46:28 yeah, i think we just need to split up: am335x-boneblack-uio.dtb/am335x-boneblack-remoteproc.dtb.. (originally i didn't want to do that...) Nov 02 21:46:53 can't an overlay be used? Nov 02 21:47:27 i tried that first, one of the drivers (uio_pruss/rmoteproc_pruss) worked as an overlay, but the other didn't.. Nov 02 21:47:30 I assumed there'd be an official way already, given that jessie is the release image and pruss is probably the most major unique feature of the bbb Nov 02 21:47:55 the bigger issue, they both share the "pruss" node address, so they can't be both loaded.. ;) Nov 02 21:47:59 it suffices if uio works, remoteproc is just a subset of its functionality Nov 02 21:48:25 node address conflicts don't matter in DT, maybe the ti,hwmods might Nov 02 21:48:39 the beaglebone blue guys are using remoteproc-pruss... Nov 02 21:48:50 that's their problem :P Nov 02 21:49:44 oh, and uio_pruss at some point gained an inane error about "no pins" being defined or such, which is also something users trip over Nov 02 21:49:53 it should be diked out Nov 02 21:50:11 that's cape-universal... it loads the pruss with no pin's... Nov 02 21:50:28 no it's the driver, these people don't use cape-universal since it conflicts with everything Nov 02 21:51:15 if you'd hang out here more you'd see how big an issue it is that jessie made large changes that invalidated most documentation out there on the internet, without providing the slightest clue on how to proceed instead Nov 02 21:52:02 I pushed jkridner to start http://elinux.org/Beagleboard:BeagleBone_Debian_Image_Migration although I ended up writing most info there right now, even though I largely have no idea how users are supposed to solve stuff in official images Nov 02 21:52:30 getting e.g. spi to work is another one seen frequently Nov 02 21:52:57 brb, breakfast Nov 02 21:52:57 anything with spi, they need to upgrade the 4.4.x kernel... Nov 02 21:53:20 ti backported an edma change that fixed the real issue, and my old-fix broke it.. Nov 02 22:11:15 zmatt, pushed the first couple: https://github.com/RobertCNelson/linux-dev/commits/master will do the other half tonight.. **** ENDING LOGGING AT Thu Nov 03 02:59:59 2016