**** BEGIN LOGGING AT Sat Jul 04 03:12:19 2020 Jul 04 03:12:32 So the BBBW is better then the BBGW? Jul 04 03:13:02 KenUnix: yes the BBBW does not have the same problem, its expansion headers are 100% compatible with the BBB Jul 04 03:13:41 balsam_pear: here's a small perl script that checks how much data has been written to eMMC since boot: https://pastebin.com/k9VEmv4p Jul 04 03:13:43 OK Jul 04 03:18:40 Ran the script and got: 0.00 KiB in 6.1d Jul 04 03:19:01 KenUnix: are you running from sd card maybe? Jul 04 03:19:26 SC card Jul 04 03:19:47 then of course it hasn't written to eMMC Jul 04 03:19:57 why would it? :P Jul 04 03:20:47 if you want to know about the sd card you'd need to change the "mmcblk1" in the script to "mmcblk0" Jul 04 03:25:45 Yep. Got 544 MiB in 6.1d Jul 04 03:29:07 Gotta run. See you later. Jul 04 03:33:12 zmatt: I execute the script, but it say "-bash: ./eMMC_detect.sh: /usr/bin/perl^M: bad interpreter: No such file or directory" Jul 04 03:33:45 balsam_pear: looks like it ended up having embedded CRLFs Jul 04 03:33:54 instead of normal line endings Jul 04 03:34:19 one way to strip them is: perl -pi -e 's/\r//g' eMMC_detect.sh Jul 04 03:34:36 also it should be .pl, not .sh ... it's not bash script Jul 04 03:46:02 anyone use pyqt? Jul 04 03:46:18 or a more basic python oop question Jul 04 03:48:26 things created in __init()__ Jul 04 03:48:40 they go out of scope once init finishes Jul 04 03:48:43 ? Jul 04 03:48:48 like a gui window Jul 04 03:49:32 any variable goes out of scope at the end of a function in python (or at the end of the lexical block where the variable was declared in most other languages) Jul 04 03:49:58 so if I wanted it to hang around I need to make it a property Jul 04 03:50:04 things you want to stick around should go some place more permanent, like an attribute of your object Jul 04 03:50:09 it is wierd because the gui doesnt go away Jul 04 03:50:40 or I am not understanding the window system Jul 04 03:51:10 it is possible that the objects will stick around even if _you_ don't keep a reference to them, that depends on how pyqt works, which I do not know Jul 04 03:52:29 it is confusing Jul 04 03:52:39 grrr Jul 04 03:53:05 need to google Jul 04 03:57:28 i hate how python makes you list self everywhere Jul 04 03:59:45 hmm I'm not a fan of it but I can't think of a better way they could do it. Jul 04 04:00:00 not making that explicit would be a semantic mess in a language as dynamic as python Jul 04 04:00:41 it's the same in perl and mostly the same in javascript Jul 04 04:01:43 languages where the object can be used implicitly as receiver are those where everything has to be declared, like C++ and C# Jul 04 04:25:57 what would happen if I had multiple threads reading the FIFO Jul 04 04:26:36 i am sort of stuck. I am not sure how to go about updating values in two places Jul 04 04:26:52 or better worded update two gui elements Jul 04 04:27:19 I am going to instuct the device to continuously output Jul 04 04:27:33 in the full implementation the PRU would be reading it as fast as it comes in Jul 04 04:28:18 I guess I could have the PRU write to shared memory Jul 04 04:28:46 and then have python pull from shared Jul 04 04:30:31 I guess I need to make a simple PRU code that just moves values from UART to shared memory Jul 04 04:31:06 how would I reference the FIFO from PRU1 assembly Jul 04 04:31:35 the python is great for setup. now I would want to launch the PRU and let her go Jul 04 04:31:54 I will leave that for tomorrow Jul 04 04:32:00 got some good progress today Jul 04 04:32:03 woo hoo Jul 04 04:32:26 zmatt I was looking and I will need you to get a DOI number so I can cite your github Jul 04 04:32:34 we are ways a way but it is coming Jul 04 06:04:06 Man...you guys were busy for July 4th. Yea boy! **** ENDING LOGGING AT Sat Jul 04 07:17:23 2020 **** BEGIN LOGGING AT Sat Jul 04 11:18:23 2020 **** BEGIN LOGGING AT Sat Jul 04 12:31:11 2020 Jul 04 17:14:22 Hi, the encx24j600 driver doesn't support the "compatible" field for dtb. How do I tell the driver now, on which pin the interrupt pin is attached to? I don't even know how to tell Linux to bind the encx42j600 driver to the spidev1.0 device without dtb. Can someone please help me? Jul 04 17:16:23 Overlays for both spis are loaded using uEnv.txt with "uboot_overlay_addr0=/lib/firmware/BB-SPIDEV1-00A0.dtbo" and "uboot_overlay_addr1=/lib/firmware/BB-SPIDEV0-00A0.dtbo" Jul 04 17:25:29 hi Jul 04 18:18:36 I got upm compiled! Jul 04 18:18:53 Many libraries for the BBB and capemgr. No! Jul 04 18:19:49 I will figure out how to port it to the BBB w/ u-boot overlays or I will cease to cease. Jul 04 18:21:30 Oh and Seeed outdid themselves on the BBGG "wiki." **** BEGIN LOGGING AT Sat Jul 04 18:56:31 2020 Jul 04 20:03:04 zmatt:how does the PRU read the UART Jul 04 20:03:22 is there a specific registry I would move the value out from Jul 04 20:12:33 pr1_uart0_rxd Jul 04 20:12:39 is what I would need Jul 04 20:14:45 I also see this starting address 0x0002_8000 Jul 04 20:15:04 so basically if I read from this spot somehow I would get UART data. Jul 04 23:15:04 mindbyte2: the SPIDEV overlays are for controlling spi devices directly from userspace, it's mutually exclusive with using a specific kernel driver for the device Jul 04 23:17:28 mindbyte2: it might be that this driver just needs to be updated to support DT-based configuration, I'm not sure Jul 05 00:23:20 zmatt: Would it work if I create a dtbo with "linux,spidev" but set an interrupt with it? Could the driver auto-detect the enc424j600 by probing? Thanks! Jul 05 00:24:00 no, and the spidev driver doesn't use any interrupt so your declaration of one would achieve nothing Jul 05 00:24:52 like I said, the spidev driver is purely to give userspace the ability to interact directly with spi devices, it is mutually exclusive with using any other kernel driver for the spi device, e.g. the enc424j600 driver Jul 05 00:28:48 zmatt: But how the f were other people using this driver? I mean.. How did they bind the driver to exactly the pins they want? I really don't get it. Jul 05 00:30:40 I have no idea how spi devices are used other than by DT, I guess they used board files? Jul 05 00:30:49 I dunno Jul 05 00:31:15 I also don't know how much work it is to update the driver to support DT, I suspect it's fairly minor Jul 05 00:31:43 It's should literally just be a one liner (+ one include), but I'm not sure Jul 05 00:31:45 acpi? Jul 05 00:32:53 mindbyte2: nah it's not a one-line... at minimum it would need the declaration of an of_id for the driver, and probably the probe function needs to be modified to be able to obtain its irq from the DT declaration Jul 05 00:33:41 Right. The of_net include and the compatible string, like from the smaller chip: static const struct of_device_id enc28j60_dt_ids[] = { { .compatible = "microchip,enc28j60" }, Jul 05 00:33:52 mru: What do you mean? Jul 05 00:34:13 acpi is another mechanism for declaring hardware used on x86 systems Jul 05 00:34:31 Does the bb even have acpi? Jul 05 00:34:37 the bb isn't an x86 system Jul 05 00:34:39 and due to microsoft's insistence, a few arm systems Jul 05 00:34:55 it was just a reply to how other systems might be using this driver Jul 05 00:35:06 mru: but doesn't acpi require some sort of id declaration in the driver too? Jul 05 00:35:08 Ahh okay now that makes sense. Jul 05 00:35:18 zmatt: I guess Jul 05 00:35:23 I avoid it as much as possible Jul 05 00:35:36 the mere sight of it makes me cringe Jul 05 00:35:43 grrr Jul 05 00:37:17 mindbyte2: and yeah, the modifications done for the enc28j60 driver are a good guideline: https://github.com/beagleboard/linux/commit/2dd355a007e4 Jul 05 00:37:28 zmatt: I found a link quite a while ago, where someone already did it: https://github.com/beagleboard/linux/issues/70#issuecomment-201349233 Jul 05 00:37:30 looks like nothing specific needs to be done for the irq Jul 05 00:37:44 But he's using the "compatible" string, which is non-existent in the driver Jul 05 00:38:07 mindbyte2: yes, that needs to be added to the driver at minimum Jul 05 00:38:22 Your link is for the enc28j60 (which has excellent documentation btw), but I have the bigger chip, enc424j600 Jul 05 00:38:43 I know, I'm saying that this is showing how the enc28j60 driver was modified to support DT Jul 05 00:39:10 which can serve as a guide on how the enc424j600 driver needs to be modified to support DT Jul 05 00:39:20 Ahhh! :) Jul 05 00:39:46 Okay, thanks zmatt for your help!! Seems like I will modify that horrible driver, huh? Jul 05 00:39:52 the encx24j600 driver looks like it's written for old-style board files Jul 05 00:40:18 Seems so! Jul 05 00:40:29 and the only resource it needs it an irq, unless I'm mistaken Jul 05 00:40:49 should be a 5-line patch to get that from dt Jul 05 00:40:58 mru: looks like it doesn't need anything for the irq Jul 05 00:41:12 the enc28j60 driver obtains its irq in the same way as enc424j600 Jul 05 00:41:24 and that apparently didn't require any change to be DT-compatible Jul 05 00:41:25 oh, does the spi framework fill it in? Jul 05 00:41:28 I guess so Jul 05 00:41:40 that has to be the case Jul 05 00:42:26 so declaring the compatible-string is probably the only change strictly needed Jul 05 00:42:38 for driver matching, the part of "compatible" after a comma, if any, is matched against the spi_device_id table if the driver doesn't have a dt table Jul 05 00:42:39 Yes :) Jul 05 00:43:12 mru: But where does the table come from? Jul 05 00:43:29 which table? Jul 05 00:43:38 "the spi_device_id table" Jul 05 00:43:44 mru: so you're saying compatible="microchip,encx24j600"; should just work? Jul 05 00:43:44 static const struct spi_device_id encx24j600_spi_id_table Jul 05 00:43:57 I think it might, yes Jul 05 00:44:01 mru: but will the the module get automatically loaded? Jul 05 00:44:12 I think the MODALIAS will be wrong for that right? Jul 05 00:44:17 screw modules Jul 05 00:44:48 I mean yeah, compiling-in the driver or just adding the module to /etc/modules would work around that Jul 05 00:45:09 I wish I had a 100k resistor so I could test right now :( Jul 05 00:45:47 mindbyte2: so possibly it might work even without any changes, but it means you'd need to get the module explicitly loaded (by adding it to /etc/modules) if the driver is compiled as module Jul 05 00:46:07 bb's debian has the driver in-kernel Jul 05 00:46:15 ok Jul 05 00:46:25 mindbyte2: I have a few hundred of those, drop by and get one Jul 05 00:46:36 then compatible="microchip,encx24j600" might just work Jul 05 00:46:58 One more question: about spi on linux: If I check all spidev devices with spidev_test and there is no data returning, there are no spi devices connected, right? Jul 05 00:47:12 mru: Where do you live ? :) Jul 05 00:47:23 I guess at least 1000km from me, as usual ^^ Jul 05 00:47:24 I have no idea what spidev_test does, but there's no generic way to probe spi devices Jul 05 00:47:37 southampton Jul 05 00:47:46 and those resistors are 0603 smd type Jul 05 00:47:50 typically speaking I wouldn't expect any response from an spi device unless you send an appropriate command Jul 05 00:48:02 mru: *way* too far and smd is *way Jul 05 00:48:04 (but it'll depend on the type of spi device) Jul 05 00:48:08 * too small haha :) Jul 05 00:48:20 0603 is rather large Jul 05 00:48:46 0201 is a bit small though Jul 05 00:49:57 zmatt: okay, I will try that in a minute. But the enc sadly requires a pullup on the interrupt pin to go into spi mode. Jul 05 00:59:42 and enabling the internal pull-up of the AM335x does not suffice? Jul 05 00:59:53 (which is 100KΩ ±50%) Jul 05 01:06:01 Hmm.... *probably*. BUT... the pullup must be there from exactly the second, where power is applied. So I could do a hard reset by pulling the power cable from the chip :) Jul 05 01:06:26 zmatt: But I don't know how to pullup with the internal pullups Jul 05 01:07:15 your DT fragment should declare a pinmux node for the irq pin Jul 05 01:08:02 and it needs pull-up at power-up? that sounds iffy, does it not have a reset input? Jul 05 01:08:51 still, just use a pin that has default pull-up Jul 05 01:09:25 also, if you're going to use a pin that has default pull-down you'd need a significantly stronger external pull-up to override that, like 1K-10K, definitely not as weak as 100K Jul 05 01:09:42 so either way a 100K external pull-up is silly Jul 05 01:10:04 The board which contains the chip does not break-out a reset pin >_> Jul 05 01:17:27 Funnily enough, some dude did a pull-down...: https://github.com/bwilcutt/encx24j600/blob/eff93233317dcfaed25c88800f6efc2801547642/am335x-boneblack.dts#L63 Jul 05 01:23:26 btw if you're unsure which pins have default pull-up, you can find this in the P9 and P8 tabs of my pins spreadsheet: https://goo.gl/Jkcg0w Jul 05 01:24:32 mindbyte2: that is pretty odd, though based on what you're saying it might be too late for pull-up/down to matter anyhow? Jul 05 01:24:45 also boo on this guy for modifying the base dts Jul 05 01:25:51 and the pin declaration is technically in the wrong place too (it shouldn't be in the same pinmux block as the spi pins, since the spi pinmux should be attached to the spi controller while the irq pin should be attached to the encx24j600 device) Jul 05 01:28:25 that comment on lines 44-46 (unrelated to the encx24j600) is pretty wtf too Jul 05 01:28:37 Wow that's a very big spreadsheet. Thank you :) Jul 05 01:28:38 like, this sounds like he was just trying shit at random Jul 05 01:29:04 overall, I would not use this as example :P Jul 05 01:33:20 So just almost like me hahah Jul 05 01:46:47 mindbyte2: https://pastebin.com/raw/ERDuqARR something like this might work Jul 05 01:49:02 I'm curious though, why are you connecting some ethernet controller to the BBB via spi ? Jul 05 01:49:03 zmatt: That's clean af! Thank you :) Jul 05 01:50:12 Because we "have" to use a BBGW without onboard eth + we actually need 2 interfaces Jul 05 01:50:33 oh the green-wireless Jul 05 01:51:03 then you can't use P9.12 Jul 05 01:51:35 since that's one of many pins the green-wireless uses for its wifi/bt chipset Jul 05 01:51:39 (the green-wireless sucks) Jul 05 01:54:20 Ew... and we need the wifi, that's the main reason we took the bbgw ^^ Jul 05 01:55:02 yeah but the bbgw did wifi stupid by sacrificing many expansion header pins... as opposed to the bbbw which instead just reused the pins normally used for ethernet Jul 05 01:55:15 (most of those pins are left unused by the bbgw) Jul 05 01:56:13 the green-wireless is just poorly designed Jul 05 01:56:40 Damnit >_> Jul 05 02:04:11 Are there more differences between the gw and the bw? Jul 05 02:04:43 the bw has (optional) hdmi output, the gw doesn't Jul 05 02:05:14 the bbbw is really just the bbb with ethernet replaced by wifi/bt and it uses a micro-usb connector instead of mini-usb Jul 05 02:05:47 w.r.t. the expansion headers the bbbw is fully compatible with the bbb Jul 05 02:06:03 oh and the bbgw has those grove connectors which the bbb/bbbw do not Jul 05 02:10:16 I guess I gonna throw the bbgw away then :) Jul 05 02:10:28 lol, that's up to you Jul 05 02:10:43 for your immediate concern you can just pick a different pin for the irq Jul 05 02:10:58 Sure! Jul 05 02:11:37 as long as it's not any of P8.{11,12,14-18,26}, P9.{12,41} Jul 05 02:12:18 P9.11 (gpio 0.30) would be an option Jul 05 02:29:36 I must go to bed now, it's 4:28am here in Germany. zmatt, again, thank you so much for your support!! Good night Jul 05 02:53:03 Hi guys ,can please someone give lcd display code having i2c interface **** ENDING LOGGING AT Sun Jul 05 03:01:09 2020