**** BEGIN LOGGING AT Sat Mar 03 03:00:01 2018 Mar 03 05:55:48 hi Mar 03 05:59:52 hi Mar 03 09:41:59 * keesj just backed https://www.crowdsupply.com/qwerty-embedded-design/beaglewire Mar 03 09:51:45 gpmc used to interface with it... i.e. incompatible with eMMC, that sucks Mar 03 09:53:30 or maybe it's just an option to use it, I should first read more I guess Mar 03 09:58:24 yeah I guess it is, the only thing that's required is spi (to program it) Mar 03 10:05:17 I wonder what was the motivation for connecting an sdram to the fpga is... sacrificing a *ton* of i/o to attach a large amount of fairly slow memory to an fpga seems like an odd thing to do unless you have a very specific purpose for it Mar 03 10:27:39 and they're using their own 3.3v LDO powered from sys_5v instead of using the 3.3v from the beaglebone /o\ Mar 03 10:28:29 zmatt: They might need more current than the BB can supply on 3.3V? Mar 03 10:31:36 blathijs: an fpga doesn't have high-current i/o, and you can't draw that much more from sys_5v either. Mar 03 10:32:09 also, this makes using the fpga's self-configuration feature using the spi flash unsafe, since it may start driving beaglebone i/o before its i/o supply is up, damaging the beaglebone Mar 03 10:33:18 at the very least they should have grouped the beaglebone-facing i/o on one of the fpga's i/o banks and power that one from the beaglebone Mar 03 10:33:33 zmatt: I have not looked very deeply into the design. I hope to be able to combine BB and the FPGA board in a similar way it was done with the fruity pi device Mar 03 10:34:38 https://www.youtube.com/watch?v=UMDcnwZA2YE (long video but nice pointers/explanation on generating socs and the communication between the FPGA and a more general purpose device Mar 03 10:35:08 my BB's have mostly been collecting dust (and they are not the $LATESET release with lager mmc) Mar 03 10:36:00 the shear idea of the well documented beaglebone soc and the reverse engineerd FPGA and open source tools to run code on them is really appealing Mar 03 10:37:48 I think it would have been nicer if they removed the sdram, and had two i/o banks connected to the beaglebone (powered by its 3.3v) and two i/o banks for external i/o with an option to provide the voltage for those two banks externally Mar 03 10:38:40 and probably have the beaglebone-facing i/o on pins that can be used by pru rather than gpmc pins Mar 03 10:39:28 but *shrug* Mar 03 10:41:06 (right now the i/o allocation is: 40 external, 24 beaglebone, 30 sdram, 8 user interface, 4 spi, 1 osc) Mar 03 10:52:28 Well... I can not do better at this stage :P Mar 03 10:52:37 open source consumer Mar 03 11:14:19 isn't ddr usefull for running a soft core? Mar 03 11:30:59 ... why would you want to run a soft core on an fpga that's already connected to a SoC ? Mar 03 11:31:31 and it's not ddr, it's sdram Mar 03 11:32:13 oh it is ddr, nm Mar 03 11:32:30 is it? wait Mar 03 11:32:35 no it's not Mar 03 11:33:22 micron's page was confusing me for a bit Mar 03 15:36:34 Presumably for learning FPGA concepts rather than implementing a serious device, having a soft core in the FPGA might be sensible. Also, custom instructions. Mar 03 15:39:07 also, would that even fit in a small fpga like this? (4K LUTs) Mar 03 15:39:40 sorry, way fewer than that Mar 03 15:40:00 somewhat fewer I mean Mar 03 15:40:14 3520 "logic cells" Mar 03 15:40:47 plus you'd need to spend logic on the memory controller as well Mar 03 15:52:21 I have no idea; fpga's aren't really my thing. Maybe the ram is just there as a buffer? Mar 03 15:52:51 yes but what for? Mar 03 15:55:11 I didn't say there aren't applications for it, and I can think of applications myself, but I was just wondering why they'd put it on a general-purpose fpga cape... being able to almost double the amount of external i/o seems way better to me Mar 03 15:55:41 the fpga has some amount of on-chip SRAM for fast buffering anyway Mar 03 16:00:32 lol what... the fpga has 8 "low-skew global lines, designed primarily for clock distribution" Mar 03 16:00:45 the oscillator on the beagle-wire is connected to none of them Mar 03 16:00:51 it just uses a random i/o Mar 03 19:56:30 Greetings, greetings, greetings.... can anyone point me to X15 expansion boards? I need to expand the number of 1GigE port from the 2 the X15 comes with to at least 4, better 5. Mar 03 20:14:48 uhh Mar 03 20:15:10 connect a switch to it? Mar 03 20:15:25 the SoC only has two ethernet ports Mar 03 20:15:45 Need individual controllers, physically separate ports. Mar 03 20:16:04 I know it only has two, I mentioned that in my initial post Mar 03 20:16:32 why not use a VLAN switch with a trunk port to the x15 to keep the ports logically separated? Mar 03 20:17:19 yes but what I was saying is that you can't have an expansion board bring out interfaces that don't exist on the expansion headers Mar 03 20:17:23 or, well, Mar 03 20:17:29 I repeat, I need physcially distinct GigE controllers. Why asking me to modify my requirements. If you don't know it's okay. Mar 03 20:17:31 I guess since there's PCIe there you might Mar 03 20:17:44 I'm trying to help you find alternatives that actually exist Mar 03 20:18:25 If X15 expansion boards don't exists, just say so, not interested in alternatives. If I go that route I'll make my own Mar 03 20:19:41 have fun Mar 03 20:26:16 Aw. Mar 03 20:26:18 http://www.jetwaycomputer.com/JBC130F53306.html Mar 03 20:26:22 I just went and found him this. Mar 03 21:27:31 nono, he wanted an expansion board *for the x15* that provides additional gigabit ethernet ports, not any alternative solution :P Mar 03 21:33:41 :D Mar 03 21:36:45 He can tape an x15 to the chassis. Mar 03 21:37:01 That probably counts as "make my own" Mar 03 21:45:17 he'll just have to make an expansion board with a 2/3 port pcie gigabit ethernet controller, or 2/3 gigabit ethernet controllers on a pcie switch Mar 03 21:45:24 probably a piece of cake ;) Mar 03 21:54:15 yeah, I mean I made a board like that before breakfast this morning. Why isn't the market flooded with those? Mar 03 21:54:51 Maybe if I stomp my feet a little.. Mar 03 22:22:09 Hello... Mar 03 22:28:54 Pray for rain...I am setting up the Motor Bridge Cape. Pears and the BBB! Mar 03 22:43:40 no-go Mar 03 22:55:28 damn... Mar 03 22:55:51 zmatt: I tried that software change. I left a message. Mar 03 23:06:35 please note I prefer irc. it's also a bit annoying that you've turned my bugfix report issue into your own support thread Mar 03 23:07:01 that error just means you don't have Adafruit_GPIO installed, again Mar 03 23:09:53 I have it installed. Mar 03 23:09:54 Oh. Mar 03 23:09:59 I gave you credit. Mar 03 23:10:27 Your credit is #6 on Seeed-Studio's issue report. Mar 03 23:10:51 I think I put that on the software change. Mar 03 23:11:06 I did not want to tell on you by giving out your personal info. w/out your permission. Mar 03 23:11:26 e.g. name on irc or github.com. Mar 03 23:12:27 <<<< on a smoke break but first, my Adafruit_GPIO must be installed elsewhere or out of the PATH I need. I will test it before the smoke break. Mar 03 23:15:29 ... Mar 03 23:16:17 I installed Adafruit_Python_GPIO w/ their instruction on that page/GitHub.com/adafruit/adafruit-python-gpio. Mar 03 23:17:08 I ran the software w/ your changes on the Github.com, Seeed-Studio page. import as instead of from import and etc... Mar 03 23:17:09 ... Mar 03 23:17:09 you had it working earlier though Mar 03 23:17:16 so you must have mucked something up again Mar 03 23:17:17 Nope. Not on this board. Mar 03 23:17:40 also, weren't you going to test a working setup you already had to check on the pin configuration? Mar 03 23:17:44 Well...yea. I set up a new image today. I used bbb.io/latest-images to set up a new one. Mar 03 23:17:49 ... Mar 03 23:17:55 Yea. I need to do that still. Sorry. Mar 03 23:18:26 well anyway, you clearly managed to successfully install it before, I'm sure you can manage to do it again Mar 03 23:18:35 ... Mar 03 23:18:45 Okay. I am just harassing you at this point. I will back off. Mar 03 23:19:06 <<<< off to smoke and check other boards w/ the other images and setups. Mar 03 23:19:23 kinda yes. next time just read the error message, it literally said it couldn't find the module Mar 03 23:19:54 also, it's an error you've had before and I then also pointed out it just means you didn't have it installed Mar 03 23:20:16 Yea. I have new errors. IOError: [Errno 121] Remote I/O Error Mar 03 23:20:28 *that* is the only real error so far Mar 03 23:20:33 Okay. Mar 03 23:20:42 but that's not what you spent two github comments on just now Mar 03 23:21:10 for figuring out the i2c error I suggested dumping the pin configuration in a working setup for comparison Mar 03 23:21:10 zmatt: Look man, you are right as usual. I messed up. Please forgive me. I will resuit the gitHub.com posts. Mar 03 23:21:17 I remember. Mar 03 23:21:35 I will do that today. Mar 03 23:22:01 ...just a heads up. I might use pastebin later. Mar 03 23:23:36 Does anyone here use gsl1680 controller for touch support? I have some problem ... Mar 03 23:25:08 http://linux-sunxi.org/GSL1680 Mar 03 23:28:07 i think i have i2c problem! Mar 03 23:29:29 i2cdetect commands output : https://paste.ubuntu.com/p/JVDWF4gFvT/ Mar 03 23:30:24 in the linux-sunxi article "The GSL1680 always answers at the address 0x40" Mar 03 23:30:40 but there is nothing in 0x40 Mar 03 23:32:20 check hardware connection and pull-ups ? Mar 03 23:32:49 btw it is in general not recommended to use i2cdetect (see the big warning it prints) Mar 03 23:33:43 also make sure this "iocntl" pin mentioned on that wiki page is high Mar 03 23:35:43 hardware connection is OK.because i test with another ubuntu image and works correct Mar 03 23:35:55 i use debian Mar 03 23:36:35 zmatt, PINs set in am335x-boneblack.dts file? or in other files Mar 03 23:37:31 I'm assuming you're using i2c-2 on P9.19-P9.20, which is setup by default Mar 03 23:38:14 you can double-check the current pin configuration e.g. by using Mar 03 23:38:34 ... by using my show-pins script: https://github.com/mvduin/bbb-pin-utils/blob/master/show-pins Mar 03 23:39:38 i2cdetect did detect something connected to i2c-2 though, at address 0x50 ? Mar 03 23:40:41 yes 50 Mar 03 23:42:42 bien_salad: jesus seth, what on earth do you keep rambling about on github? Mar 03 23:44:26 zmatt, https://paste.ubuntu.com/p/NJzJs46GF2/ Mar 03 23:44:36 your script output for the PINs Mar 03 23:45:40 there is no IOCNTL and INT Mar 03 23:47:19 complete output : https://paste.ubuntu.com/p/ygWMjFHF5n/ Mar 03 23:48:19 which cape is this? Mar 03 23:49:31 also, which debian image are you using? Mar 03 23:50:05 I just noticed that bogus configuration of P9.42, which might be indicative of a really old bootloader being used? Mar 03 23:51:26 i am using a custom cape Mar 03 23:51:37 and my debian is stretch Mar 03 23:52:30 which image date? and are you booting from emmc or sd card? Mar 03 23:53:55 (even when booting from sd card it will still prefer to load u-boot from emmc instead of sd, which means that an old u-boot there can cause weird issues) Mar 03 23:54:25 i don't know exactly the image date! but i use the "Linux beaglebone 4.4.113-ti-r145" kernel Mar 03 23:54:31 and booting from SD Card Mar 03 23:54:55 kernel version doesn't say much (although it isn't a particularly recent one). you can find the image date in /etc/dogtag Mar 03 23:55:20 if you don't care about the contents of eMMC, consider wiping it using sudo blkdiscard /dev/mmcblk1 Mar 03 23:55:26 "BeagleBoard.org Debian Image 2017-10-10" Mar 03 23:55:45 okay, not very recent but also not very old Mar 03 23:56:13 Hey sorry guys, don't want to interrupt. I'm trying to use the PRUs on a BBB that I bought a while back. I loaded the most recent Debian image onto the board. I'm finding a ton of tutorials but they all seem to be out of date. Does the most recent build use device trees anymore? Can someone point me to a good tutorial on how to use and develop code for the PRUs? Mar 03 23:56:20 your custom cape have an identification eeprom to allow automatic loading of the appropriate overlay? Mar 03 23:56:31 and you're currently trying to make that overlay, or ? Mar 03 23:57:00 JGriff: uptodate documentation is indeed an issue Mar 03 23:58:10 JGriff: device trees are most definitely still used, it's how information about the hardware is communicated to the kernel. in the current debian releases you usually don't have to meddle directly with it anymore though (i.e. via overlays), although you still can Mar 03 23:58:44 there are two ways of working with the PRUs, either uio-pruss or remoteproc-pru Mar 03 23:59:03 you can select which one you want to enable by uncommenting the appropriate line in /boot/uEnv.txt Mar 03 23:59:37 uio-pruss is probably the better choice and will match better with most documentation you'll find Mar 04 00:01:07 to use pru's direct i/o you should configure the pins you want to use using the 'config-pin' utility Mar 04 00:02:14 e.g. config-pin P9.30 pruout Mar 04 00:02:58 zmatt, I have three part : 1 - beaglebone 2 - An evaluation board 3 - touch screen controller Mar 04 00:03:07 image of board : https://pasteboard.co/Hag5eCZ.jpg Mar 04 00:03:26 and now i want to get touch working. Mar 04 00:04:00 i use BB-BONE-LCD5-01-00A1.dtbo to get working LCD Mar 04 00:04:04 wow, thank you Mar 04 00:04:46 and now i want to use touch Mar 04 00:06:08 mehdi: you should then probably make an overlay (e.g. based on BB-BONE-LCD5-01-00A1.dts) that actually matches your hardware, including iocntl and int pins of the touchscreen controller Mar 04 00:06:18 and the touchscreen itself, if it has a kernel driver Mar 04 00:06:56 it has some driver : http://linux-sunxi.org/GSL1680#Linux_driver Mar 04 00:08:12 there is a userspace driver Mar 04 00:08:52 yeah, sounds like maybe this wasn't the best choice of touchscreen controller :) there are lots which do have mainline linux support Mar 04 00:09:43 so how can i add the iocntl and int to BB-BONE-LCD5-01-00A1.dts? i must read datasheet? Mar 04 00:10:41 I suppose you could actually even get it to work without changing the overlay, by just manually exporting the appropriate gpios Mar 04 00:10:46 zmatt, my working company bought this one!! Mar 04 00:11:13 it seems that userspace driver requires only the iocntl pin (i.e. it probably polls instead of using the interrupt... not great for performance) Mar 04 00:11:34 the main thing you need to know is which pins on the beaglebone are used for these signals Mar 04 00:13:52 how can i know that? Mar 04 00:14:00 any command? Mar 04 00:14:19 or script Mar 04 00:14:42 uh, no? you need to know how the touchscreen was connected to the beaglebone Mar 04 00:14:52 check schematic or ask whoever is responsible for the hardware Mar 04 00:24:43 ok Mar 04 00:24:53 zmatt, Thank you so much Mar 04 00:25:02 i will ask Mar 04 02:43:23 Hey! zmatt: Are you less annoyed by my form of repulsive denial? I have not replied to that "annoyed" display yet. Forgive me. Mar 04 02:45:24 ... Mar 04 02:45:27 no offense. Mar 04 02:50:42 Sorry mate...I was not trying to aggravate you. Serious. Please forgive me. **** ENDING LOGGING AT Sun Mar 04 03:00:01 2018