**** BEGIN LOGGING AT Fri May 26 03:00:04 2017 May 26 06:46:08 Hello, I want to add a driver that doesn't exits in BBB linux. here is the link foru source : https://github.com/Microchip-Ethernet/UNG8071/tree/master/KSZ/linux-drivers/ksz9897/latest . how do i do that? May 26 06:50:11 wouldn't it make more sense to ask Microchip for support, considering they made that out-of-tree driver? May 26 06:50:16 (as well as the hardware) May 26 07:12:30 hi May 26 07:13:04 I need to build the beaglebone green wireless image May 26 07:13:16 can anyone help me in this? May 26 07:14:21 I also tried the write a driver module which can read the data from i2c-2 bus, but getting stuck May 26 07:14:24 rcnee has detailed instructions on his wiki May 26 07:15:42 https://eewiki.net/display/linuxonarm/BeagleBone+Black http://elinux.org/Beagleboard:BeagleBoneBlack_Debian May 26 07:27:20 karry: you're aware that you can also perform arbitrary i2c access from userspace? May 26 07:27:48 i.e. writing a dedicated kernel driver is usually not necessary May 26 07:30:12 i know that i can access the i2c from userspace but i need the data in my module May 26 07:30:21 ah ok May 26 07:31:06 as I want to write a keyboard driver, which takes the keyboard's controller data from the the i2c-2 bus and pass to the user application May 26 07:31:32 that could still be done in userspace using uinput, but a kernel driver may indeed be nicer May 26 07:32:13 I written a module and registered it as I2c driver May 26 07:32:17 but May 26 07:32:37 for my module, probe is not getting call May 26 07:32:49 did you create a suitable entry for it in device tree? May 26 07:33:34 I also modified the .dts file for this, but not sure what i done for dts file, is right or not. May 26 07:33:45 becuase I am new to .dts file May 26 07:34:33 i tried to modify BB-BONE-I2C2-0A002.dts file May 26 07:35:39 its BB-I2C2-00A0.dts file May 26 07:36:04 yeah that can work, or you can load a separate overlay for your i2c device (after enabling the i2c2 bus, if you want to connect it there instead of on i2c1) May 26 07:36:30 oh actually May 26 07:36:35 i2c2 is the one that's enabled by default May 26 07:37:02 why are you trying to load an overlay for it? (why does an overlay for it even exist? weird...) May 26 07:38:37 so how my driver can take data from i2c-2 bus? May 26 07:39:39 https://github.com/mvduin/overlay-utils/blob/master/i2c1-mcp7940x.dtsi this is an example of how to declare an i2c device in DT May 26 07:40:20 in your case the compatible-property would be set to the of_device_id declared by your driver May 26 07:40:53 conventionally this is "vendor,product", e.g. "ti,tca8418" for the tca8418 i2c keyboard driver May 26 07:41:09 (which you can use as example) May 26 07:41:37 any other config your driver needs can be set as additional properties on the device tree node representing the i2c device May 26 07:41:46 e.g. http://elixir.free-electrons.com/linux/v3.19/source/Documentation/devicetree/bindings/input/tca8418_keypad.txt May 26 07:43:22 my overlay-utils github project also contains a makefile to convert a device tree fragment (a .dtsi file) into the source code for an overlay, which uses rather obnoxious syntax May 26 07:43:49 for my driver referance I have used adp5588 driver code as this is a i2c keyboard driver May 26 07:44:16 (alternatively you can #include the .dtsi into the main device tree source file and recompile that) May 26 07:45:41 the tca8418 is also an i2c keyboard, and looks simpler and more modern to me May 26 07:46:11 @zmatt - i am not getting about the .dts file modification, can you pease help me May 26 07:46:46 looks like the adp5588 is rather ancient and lacks device tree support May 26 07:46:53 its driver I mean May 26 07:47:47 ok i am check tca8418 driver May 26 07:48:15 http://elixir.free-electrons.com/linux/latest/source/drivers/input/keyboard/tca8418_keypad.c#L362 this declaration is an essential bit May 26 07:48:31 in general, kernel functions with the of_ prefix are related to device tree May 26 07:50:27 but in device tree there will be an enrty for tca8418 May 26 07:50:29 right? May 26 07:50:44 then only its probe will get call May 26 07:51:05 there needs to be a device for which the driver's probe call it invoked May 26 07:51:30 you use DT to tell the kernel that the device exists, only then the kernel will start searching for a driver for it May 26 07:51:47 ok May 26 07:52:15 otherwise it also wouldn't have any reason to load your kernel module (assuming you compiled it as module) May 26 07:52:43 for this I need to connect the tca8418 device on the i2c-2 bus May 26 07:53:05 ? May 26 07:53:14 or whatever device you are using of course May 26 07:53:17 to call the probe May 26 07:53:35 probe gets called simply by declaring that the device exists May 26 07:53:49 if it's not actually connected to the bus, the probe will probably fail May 26 07:53:53 tca8418 is pree defind the kernel tree May 26 07:54:10 ? May 26 07:54:17 I want my own devide to defind in same way on run time May 26 07:54:36 I also used I2C_BOARD_INFO to add my device info May 26 07:54:37 the tca8418 *driver* is included in the linux kernel tree May 26 07:55:06 static struct i2c_board_info i2c_board_info_adv[] = { { I2C_BOARD_INFO("arbd", 0x70) }}; May 26 07:55:35 that sounds like it's related to board files, which are obsolete May 26 07:55:37 arbd is the driver i want to add May 26 07:57:10 assuming 0x70 is the i2c address, the equivalent DT declaration would be: &i2c2 { keyboard@70 { reg = <0x70>; compatible = "arbd"; }; }; May 26 07:58:09 that might need your driver to declare "arbd" as of_device_id, or maybe the kernel will also search i2c_device_id as legacy fallback May 26 07:58:44 static struct i2c_driver arbd_driver = { .driver = { .name = "arbd", .owner = THIS_MODULE, #ifdef CONFIG_PM .pm = &arbd_dev_pm_ops, #endif }, .probe = arbd_probe, .remove = arbd_remove, .id_table = arbd_id, .address_list = normal_i2c, }; May 26 07:59:17 I used this i2c_driver struct in my driver init May 26 07:59:19 why are you pasting this? May 26 07:59:42 ok, and? May 26 08:00:26 so just want to ask that with the same name, I need to add in dts file? May 26 08:00:50 and also please tell me which dts file I need to use May 26 08:02:29 like I just said, I don't know if linux will search i2c_device_ids when trying to probe a DT i2c device, it may require an of_device_id May 26 08:03:23 please see drivers/input/keyboard/tca8148_keypad.c as example May 26 08:05:08 ok thanks, let me check the same for my board May 26 08:07:22 device_property_*() functions btw seem to be generic wrappers for querying various forms of platform data. if you only care about ARM-based systems (and not ACPI on PCs for example) you could also use of_property_*() functions directly for obtaining configuration data from the device tree node May 26 11:12:15 hi zmatt May 26 11:13:13 I tried with tca8418 example May 26 11:13:26 but still probe is not getting call May 26 11:14:32 I just need to write a driver, which read data from i2c-2 bus May 26 12:15:40 what did you put in your device tree declaration? May 26 14:37:20 Does anyone know how to implement soft UARTs via the PRU or other means? May 26 14:51:43 I'm pretty sure I've seen a PRU softuart example somewhere May 26 14:51:52 have you asked google? May 26 14:53:03 Lots of stuff on goole, but mostly gets bogged down by piles of articles on enabling ttyO1-5 May 26 14:53:48 I've found some PRU SUART example code from TI, but nothing specific to the BB or appropriate device tree info May 26 14:54:15 oh, ew they use McASP .. why May 26 14:54:39 that makes no sense, PRU is an excellent bit-banger May 26 14:55:18 Yeah, that's part of the confusion May 26 14:56:10 Should be able to implement UART in assembly, but I would prefer not to do it if someone else already has somewhere May 26 14:56:35 it's quite possible not many people care, since there are quite a few uarts already May 26 14:56:35 Though, it woul dbe on company time and take me forever, so not the woooorst thing May 26 14:57:02 pru assembly is pretty nice, certainly when using pasm May 26 14:57:37 Yeah, we're using the BBB for a fairly niche application that I'm NDA'd from elaborating on. Basically we need an obscene number of UARTs out of the platform May 26 14:58:01 tx, rx, or both? May 26 14:58:38 Ideally both, but could possibly pare it down or do some tricky multiplexing May 26 14:58:41 and what sort of bitrate? May 26 15:00:10 Default baud is 115200, but should be able to go lower. Will be operating on some NMEA and some UBX. SOme MAVLink as well May 26 15:00:17 and a protocol I haven't specced yet May 26 15:01:15 so that's *at least* 1736 pru cycles per serial bit May 26 15:01:17 :) May 26 15:02:00 i.e. PRU probably wouldn't have trouble turning each of its dedicated I/Os into a serial tx or rx and read a newspaper at the same time May 26 15:02:25 Right now looking at about six UARTs for NMEA/UBX work alone. Then more for other com links, probably three or four. May 26 15:02:38 So total of ~10 UARTS May 26 15:03:16 So minus the four duplexed ones allready accessible, would need six out of the PRU May 26 15:03:34 Also, haven't looked into it; does the BBB have one or two PRU cores? May 26 15:03:38 two May 26 15:03:49 Well, that's nice May 26 15:04:40 a trick for really high-bandwidth applications (like beaglelogic) is to use one for data acquisition, pass that via broadside bus to the other core, and have it write data out to memory May 26 15:04:49 this isn't a really high-bandwidth application though May 26 15:05:16 might make sense to have one core do tx and the other rx, since those are completely async to each other May 26 15:05:41 Yeah, that's what the TI documentation suggested; each core is simplex then bused to form duplex UARTs May 26 15:06:57 hmm, no they actually say 2 full-duplex uarts per PRU... but they're using mcasp to serialize and deserialize anyway so that's really not similar May 26 15:07:46 Strange. Elsewhere in docs, "In Both PRU mode, one PRU is dedicated to handle the transmit operation while the other is dedicated to handle the receive operations" May 26 15:09:48 I see the term "both pru mode" only in the context of the OMAP-L1xx PRU softuart May 26 15:10:49 (there using the mcasp makes more sense since iirc they have lots of those but no dedicated pru I/O) May 26 15:11:27 Yeah. Not sure how applicable the different setups are. Would like to avoid McASP if i can, less to deal with May 26 15:11:53 using mcasp only complicates things, and the am335x doesn't have a useful amount of those to spare May 26 15:12:30 Not sure why the both PRU is only mentioned of omapl when other platforms also have multiple PRUs May 26 15:13:10 in fact all instances of PRUSS are dual-core May 26 15:13:26 might be able to implement the same sort of RX/TX core segregation myself (or get our guy that speaks assembly better than English to do it) May 26 15:14:04 note that "assembly" doesn't mean anything May 26 15:14:19 in this case you mean "PRU assembly" specifically May 26 15:16:43 Found some random guy that dumped a PRUSS SUART driver May 26 15:17:01 Haven't foudn the actuall PRUSS bit though May 26 15:18:12 ? you mean https://gitorious.org/pru/am335x-pru-uart-fw?a=tree ? May 26 15:18:59 Well, that's certainly helpful May 26 15:19:13 it was in the TI wiki page, and also one of the first google hits I got May 26 15:19:53 (note btw that "am335x pru uart" is a bit ambiguous phrase since PRUSSv2 also includes an actual uart) May 26 15:21:31 Hadn't found that wiki page, but have it now. That should help. May 26 15:21:45 still, it's an example of the wrong way to do it :) May 26 15:22:11 they probably just did it like that to be able to reuse the code previously written for omap-L1xx May 26 15:23:52 Sounds right. Strange how the omapL1xx showed support for up to 8 SUART while the AM335x page shows only four. Might have to do some digging May 26 15:24:25 either laziness or interconnect latency May 26 15:25:19 interconnect latency is pretty significant on the am335x, so if you're not careful about that you'll pay a heavy price for it May 26 15:26:36 the solution is to make sure that cortex-a8 or dma delivers data directly into PRUSS, to avoid the PRU cores from having to perform reads on external memory or peripherals May 26 15:26:51 (writes are less of a problem since they're "fire and forget") May 26 15:27:20 Yeah. The page supplies code for getting four more UARTs. Even one more would be workable I think. Worst case I grab the coolgear cape for the last two May 26 15:28:04 Know of any guides to doing that? I got thrown on this project and haven't done CS or embedded dev since my undergrad May 26 15:29:07 note that the bbb only has at most 6 mcasp data pins accessible in total, so that rules out getting more than 3 full-duplex uarts using McASPs on the BBB May 26 15:30:05 Ouch. Broadside bus is still an option though, right? May 26 15:31:15 the broadside bus is what connects the two cores and a few other internal resources (three "scratchpad" pages, the "zero" and "fill" resources, the multipliers (one per core), and ethercat (not relevant)) May 26 15:34:40 i just updated http://jadonk.github.io/bone101/Support/BoneScript/updates/. Let me know if there are any vague areas. May 26 15:34:50 mz_: it can read and/or write any contiguous byte-range of the 29 general-purpose registers, e.g. exchange all 29 registers with the contents of one of the scratchpad pages, in a single clock cycle May 26 15:34:53 * jkridner continues to try to solve FAQs. May 26 15:35:25 mz_: i.e. it has to consist of at least 1856 signals... hence the "broad" in "broadside" May 26 15:40:26 zmat: Alright, guess I still just have a lot to wrap my head around May 26 15:41:25 http://elinux.org/Ti_AM33XX_PRUSSv2 the cute little thin arrows they draw between the pru cores, scratch pad, and MAC is what's supposed to represent the broadside bus :) May 26 15:41:37 I think they could have used a slightly thicker arrow for that May 26 15:42:31 It's supposed to be ~1850 bits wide, right? May 26 15:43:40 29 register * 32-bit * 2 directions May 26 15:43:47 + some status signals obviously May 26 15:44:59 oh sorry, 30 registers * 32-bit May 26 15:46:47 So, assuming a segregated RX/TX would the two cores even need to talk amongst themselves? I don't need flow control or anything, just the data lines May 26 15:47:06 nope May 26 15:47:47 scratchpad might be useful if you need more temporary storage than fits in registers, but that seems doubtful May 26 15:48:09 Alright, didn't think so. On the TX side, it would be a direct access GPIO coming in, then a fire and forget to memory on the output, so shouldn't be too bad May 26 15:48:20 like I said, beaglelogic makes good use of it, but that's because it's a 14-channel 100 MHz logic analyzer May 26 15:48:33 on the RX side you mean May 26 15:49:07 Yeah, somebody put those next to each other on my keyboard :) May 26 15:49:29 for TX it would be most efficient if the cortex-a8 drops the data directly into ring-buffers in PRUSS local memory May 26 15:50:19 although in this application you have so much time available you could presumably also get away with the expense of fetching it from external RAM May 26 15:50:28 I'll pretend like I know how to do that already :P May 26 15:50:54 you can literally mmap() pru's memory in a userspace application on the cortex-a8 May 26 15:51:20 Oh, well, that's sure nice May 26 15:51:43 so then you can just access it like normal memory, it's just really slow for the cortex-a8 (though again much more so for read than for write, depending slightly on how it's being mapped) May 26 15:53:00 Are there any faster ways? or is this the best we have with te hardware? May 26 15:53:29 does it matter if there are faster ways when your application isn't remotely going to push the limits of pruss *at all* anyway? May 26 15:54:28 Less pushing the limits and more minimizing latency, but I supposed the timescales for memory operations being "slow" aren't really an issue May 26 15:54:41 slow = ~150 ns May 26 15:55:27 Yeah, already looking at an addition of a few 10s of ms for logging and processing, so not really an issue May 26 15:56:15 Would it make sense on the RX side to have data go into the PRU's memory space as well to be read out by the cortex? May 26 15:58:50 doesn't matter hugely at these low speeds May 26 15:59:30 sending it out to external RAM would probably be slightly more efficient, but trickier w.r.t. synchronization May 26 16:00:12 a bigger concern is probably that PRUSS doesn't have much memory May 26 16:00:56 8KB + 8KB + 12KB of data memory total May 26 16:01:01 The 12K shared or a different block? May 26 16:01:50 all three blocks can be accessed by both PRU cores and external initiators like the cortex-a8 or EDMA May 26 16:02:31 So Data RAMx and Shared, correct? May 26 16:02:35 yes May 26 16:03:07 Just making sure I got it all. I'm a signals guy they have doing embedded development :P May 26 16:03:53 still safer than a software guy wielding a soldering iron May 26 16:04:33 Yeah. They fixed that by only letting techs touch anything even remotely dangerous May 26 16:04:57 Bricking a BBB is a lot cheaper than workman's comp May 26 16:06:37 you can't really brick a BBB except by damaging the hardware anyway May 26 16:07:39 Good to hear. So, do you think this is a reasonable endeavour or not worth the trouble? May 26 16:08:42 I think this sounds like a perfectly doable project, and I'm pretty sure also the easiest way to obtain that many extra UARTs May 26 16:09:27 Maybe I'll even get clearance to open source it. Company really likes IP and all May 26 16:10:08 its needs are modest enough that you might even be able to get away with using the PRU C compiler, although it's pretty crappy May 26 16:10:26 (PRU was really never designed to be targeted by a C compiler) May 26 16:11:13 have to run to a meeting. Any way to get in touch with you? If I haven't bugged you enough May 26 16:11:22 I'm often enough here May 26 16:13:12 Cool thanks May 26 16:19:09 ah, and I stand corrected, apparently you can do exchange (XCHG) with a scratchpad, only read (XIN) or write (XOUT) May 26 16:19:13 *you can't do May 26 17:57:58 Hello May 26 19:10:23 still curious, people who seem to come here just to say hello and leave again May 26 19:15:14 * vagrantc only comes here to watch people say hello and leave again May 26 19:34:14 wtf... when the hell did this start happening... May 26 19:34:15 Stage this hunk [y,n,q,a,d,/,e,?]? Use of uninitialized value $key in string eq at /usr/lib/git-core/git-add--interactive line 1120. May 26 19:35:12 haha. May 26 19:37:18 $key there is the result of ReadKey 0... that should never be undef May 26 19:38:59 uhh, huh May 26 19:41:07 it happens only in *that terminal window* wtf **** ENDING LOGGING AT Sat May 27 03:00:01 2017