**** BEGIN LOGGING AT Mon Sep 21 08:50:38 2020 **** BEGIN LOGGING AT Mon Sep 21 09:30:01 2020 **** BEGIN LOGGING AT Mon Sep 21 09:32:16 2020 **** BEGIN LOGGING AT Mon Sep 21 10:03:24 2020 **** BEGIN LOGGING AT Mon Sep 21 10:18:10 2020 **** BEGIN LOGGING AT Mon Sep 21 10:30:37 2020 **** BEGIN LOGGING AT Mon Sep 21 11:13:41 2020 Sep 21 11:39:21 Hi, i want to add rpmb block in beagle bone black. How to create rpmb in beagle and how to access it Sep 21 11:43:35 hlo Sep 21 11:43:49 Hi, i want to add rpmb block in beagle bone black. How to create rpmb in beagle and how to access it **** BEGIN LOGGING AT Mon Sep 21 12:56:36 2020 Sep 21 12:57:35 my beaglebone blue bonescript is 0.5.2 now, how develop bonescript 0.6.1 Sep 21 13:37:38 when i compile beagleboneblue in cloud9, i have '/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabihf/8/../../../arm-linux-gnueabihf/Scrt1.o: in function `_start':(.text+0x44): undefined reference to `main' **** BEGIN LOGGING AT Mon Sep 21 13:41:48 2020 **** BEGIN LOGGING AT Mon Sep 21 14:22:31 2020 Sep 21 14:46:17 what is the unit of time for the system clocks of the pru Sep 21 14:46:27 actually not the PRU Sep 21 14:46:29 but the ehrPWM Sep 21 14:46:39 so if I say period of 1000 Sep 21 14:46:42 what are the units **** BEGIN LOGGING AT Mon Sep 21 16:04:39 2020 Sep 21 16:17:58 eHRPWM's clock is 100 MHz, so units of 10ns, assuming divider=1 Sep 21 16:18:40 ok Sep 21 16:18:46 the divider divides the clock, hence scales the units. this allows using larger periods, since the maximum period is 65535 Sep 21 16:19:00 you have ESP Sep 21 16:19:09 i was just going to ask the purpose of the divider Sep 21 16:19:09 ? Sep 21 16:19:15 ah **** BEGIN LOGGING AT Mon Sep 21 16:52:29 2020 **** BEGIN LOGGING AT Mon Sep 21 20:55:53 2020 Sep 21 21:35:59 So. I added thousands of debug messages to the encx24j600 driver and it tells me that it calls 'spi_write_then_read' but it does NOT read the data back, but is is clearly visible on the oscilloscope. I don't know what to do anymore. Source: https://pastebin.com/t7aEWYJG & https://pastebin.com/MTyFuDym - Bootlog: https://pastebin.com/8KSh6HVw **** BEGIN LOGGING AT Mon Sep 21 21:44:20 2020 Sep 21 21:44:54 mindbyte: remind me, it worked from userspace using spidev right? Sep 21 21:45:02 Right! Sep 21 21:46:24 what sort of transfer did you perform exactly to test it? Sep 21 21:48:10 @zmatt https://pastebin.com/pz3tpe9Z Sep 21 21:48:58 .. and the driver generates this traffic: https://wille.io/img/IMG_20200910_115625.jpg Sep 21 21:50:30 okay so a 3-byte tx+rx transfer. if you want to replicate what spi_write_then_read() does, try a SPI_IOC_MESSAGE(2) transfer with the first spi_ioc_transfer being 1-byte tx-only and the second being 2-bytes rx-only Sep 21 21:50:39 could easily be a driver bug Sep 21 21:50:57 (an omap2_mcspi driver bug I mean) Sep 21 21:52:12 wtf is happening on that chip select line? o.O Sep 21 21:52:57 if that's what it is Sep 21 21:53:16 oh or is that data but does it just look really weird? I'm not sure what I'm looking at Sep 21 21:53:49 and why is that channel AC-coupled? Sep 21 21:53:55 That's just the oscilloscope interpreting the SPI signal, it's just a representation Sep 21 21:54:03 I mean the yellow line Sep 21 21:54:46 the data decoder output looks like garbage too, but that might just be due to being zoomed out too much maybe? Sep 21 21:55:39 probably Sep 21 21:55:53 since the transcript looks right Sep 21 21:56:03 I don't know anymore. Sep 21 21:56:19 At least the beaglebone can read it (with spidev) Sep 21 21:58:10 like I said, try replicating the transfer structure used by spi_write_then_read() in this case using spidev Sep 21 21:59:41 Why with spidev? Sep 21 22:00:54 because you had it working with spidev (using a 3-byte txrx transfer), so if it doesn't work with spidev using the altered transfer structure then you immediately know *it* is to blame Sep 21 22:01:17 I'm pretty sure I use rx-only transfers myself too though Sep 21 22:02:29 yeah I definitely do Sep 21 22:02:50 it just sounds so weird Sep 21 22:03:54 Okay, that will take me some time as I never worked with spidev :) thanks for the tip Sep 21 22:05:10 ahh Sep 21 22:11:01 mindbyte: https://pastebin.com/jBb8f0mU Sep 21 22:12:06 Am I fckn retarded or is 'u16 eudast' uninitialized instead of being something like 0x56 ?! Sep 21 22:12:23 eudast = encx24j600_read_reg(priv, EUDAST); Sep 21 22:13:08 But 'encx24j600_write_reg' takes a non-ref parameter! Sep 21 22:13:16 And is called before that read Sep 21 22:13:45 btw.. so, right now you're printing a lot, but not actually the received data right after spi_write_then_read to confirm whether you got the data right or not? Sep 21 22:13:58 eh, where am I looking? Sep 21 22:15:00 I don't see what you mean Sep 21 22:15:13 the eudast variable isn't used in any encx24j600_write_reg() Sep 21 22:15:57 Line 459 defined but not initialized, line 469 used Sep 21 22:16:09 ehm, no it's not? Sep 21 22:16:13 encx24j600_write_reg(priv, EUDAST, EUDAST_TEST_VAL); Sep 21 22:16:19 where do you see eudast being used? Sep 21 22:16:48 Okay, then I'm retarded. Or just too tired and too tired of this mess ^^ Sep 21 22:16:59 i read 'EUDAST' as 'eudast' Sep 21 22:17:01 Sorry Sep 21 22:18:08 :D Sep 21 22:18:40 Okay, here's what I'm going to do next: I will study the datasheets of the chip again and look exactly what has to be sent and what has to be received. Then I'm doing more logging (actually read what spi_write_then_read has read). Then I'm going to test your new paste (thanks for that). Sep 21 22:19:39 the transfers seem to be fairly obvious Sep 21 22:21:12 it's writing EUDAST using 0x56 followed by u16le data out and reading it using 0x16 followed by u16le data in Sep 21 22:21:51 I'd guess 0x00-0x3F are register reads, 0x40-0x7F are the corresponding writes, and 0x80-0xFF is other stuff or reserved Sep 21 22:22:19 On the oscilloscope image the chip returns 00 00 00 on EUDAST (56 34 12). But he wants 34 12? Sep 21 22:22:33 no, that's the write Sep 21 22:22:43 Not full duplex? Sep 21 22:22:45 hence nothing on miso Sep 21 22:23:55 Yes, you are right. Sep 21 22:24:05 although spi inherently transfers data in and out simultaneously, actual protocols on top almost always use only one of the two directions for each transferred byte Sep 21 22:25:31 so the data on the bus looks fine, which means it makes no sense for that data to not end up in your receive buffer Sep 21 22:26:06 (unless there were a problem with physical connection or pinmux of the miso pin, but you've excluded that with your spidev test) Sep 21 22:26:40 so if the data is not there right after spi_write_then_read then there's something going wrong in the spi layer Sep 21 22:28:48 if the data is there yet encx24j600_read_reg() returns zero then you should follow the call chain to determine where along the way it gets lost Sep 21 22:29:33 if the data isn't there then it may be easier to first do some tests from userspace using spidev to determine the conditions that cause the problem Sep 21 22:30:26 The encx driver was statically linked, I just altered it to be built as another different module. I don't think I can do this with the spi module. Or is there a way to acutally debug the kernel without rebuilding everything? Sep 21 22:30:41 Yes, absolutely. Sep 21 22:33:27 there may be dynamic debug messages available (haven't checked), and while you can't compile the spi core as module you definitely can do so with the omap2-mcspi driver Sep 21 22:34:51 Okay, the omap2-mcspi driver is on my list. Sep 21 22:36:22 How great are my chances that a BBB will work with the encx driver out of the box? :) Sep 21 22:36:52 ? Sep 21 22:37:16 wait, are you not using a BBB? what are you using? Sep 21 22:37:26 BBGW, the trash from seeed Sep 21 22:38:39 that will make no difference here Sep 21 22:41:15 its main problem is that it (unnecessarily) sacrificed a bunch of expansion header pins for its wl18xx chip, but those are not the spi0 pins Sep 21 22:43:46 anyway, you have a place where the data appears (on the bus) and where it's gone (the return value from encx24j600_read_reg()) .. if you just systematically probe along the way I'm sure you'll find where it disappears into thin air Sep 21 22:44:03 I was thinking "it works for everyone, just not for me, using a bbgw". idk Sep 21 22:44:30 I read the output of the spi read and it is indead 00 00 => "spi_write_then_read got data: 0 0" Sep 21 22:44:31 you have confirmation it works for people? Sep 21 22:44:49 well that's interesting Sep 21 22:45:48 I do similar write-then-read transfers myself without any problem (using spidev, but that's a pretty thin wrapper around the kernel's api) Sep 21 22:46:30 e.g. https://github.com/bwilcutt/encx24j600/issues/2 Sep 21 22:47:12 and https://github.com/beagleboard/linux/issues/70#issuecomment-201349233 Sep 21 22:47:18 that is really funky Sep 21 22:48:41 Second guy is using DMA Sep 21 22:48:49 maybe double-check your pinmux using https://github.com/mvduin/bbb-pin-utils/tree/green-wireless ? Sep 21 22:49:08 spi automatically uses dma for transfers above a certain size Sep 21 22:49:17 3 bytes ain't that size :P Sep 21 22:49:39 (the omap2-mcspi driver will I maen) Sep 21 22:50:02 Also he declares "compatible = "ti,omap4-mcspi";", I don't. Sep 21 22:50:26 nor should you, that's part of am33xx.dtsi Sep 21 22:50:37 oh he's just quoting am33xx.dtsi Sep 21 22:50:42 oh wtf Sep 21 22:50:52 he edited his stuff into am33xx.dtsi Sep 21 22:51:02 Ew :D Sep 21 22:51:16 someone who doesn't get dts :P Sep 21 22:51:39 But he atleast got it working against all odds ^^ Sep 21 22:52:03 what does your DT overlay look like? Sep 21 22:52:08 I'm now looking at my pinmuxes **** BEGIN LOGGING AT Mon Sep 21 22:55:00 2020 Sep 21 22:55:01 sclk needs to be PIN_INPUT_PULLUP Sep 21 22:55:13 actually PIN_INPUT_PULLDOWN would make more sense since you're using mode 0 Sep 21 22:57:08 So, PIN_INPUT_PULLDOWN it is **** BEGIN LOGGING AT Mon Sep 21 22:59:08 2020 Sep 21 22:59:33 so PIN_INPUT will always work, PIN_OUTPUT will not always work and has limited benefit... presumably it saves a bit of power, and disabling the input buffer is probably a good thing if the pin might be exposed to intermediate voltages (in between logic-low and logic-high) for extended amounts of time Sep 21 23:00:35 OH Sep 21 23:00:36 MY Sep 21 23:00:37 FUCKING Sep 21 23:00:38 GOD Sep 21 23:00:40 spi_write_then_read got data: 34 12 Sep 21 23:01:00 [ 26.385807] encx24j600:519 - encx24j600_soft_reset: eudast reset validated! :) IT WORKS!! Sep 21 23:01:17 OH Sep 21 23:01:17 MY Sep 21 23:01:18 GOD Sep 21 23:01:19 [ 26.744869] encx24j600fey spi0.0 eth1: Silicon rev ID: 0x01 Sep 21 23:01:19 [ 26.744891] encx24j600fey spi0.0 eth1: MAC address 04:91:62:3f:57:ea Sep 21 23:01:30 I'm fing crying rn Sep 21 23:01:37 interesting, I did not know that that's how leaving the sclk pin's input buffer disabled would manifest itself Sep 21 23:02:06 though that makes sense in retrospect Sep 21 23:03:44 Or maybe more like because of the pulldown? Sep 21 23:05:12 so, the reason sclk, despite being an output-only pin, needs its input buffer enabled is because it uses the clock it inputs from the pin (rather than the one it drives to the pin) as clock for received data because it has better timing relative to the data Sep 21 23:05:21 no, the pulldown only matters outside of transfers Sep 21 23:05:55 it's just a cosmetic thing: it prevent the clock from floating back up after the transfer is complete Sep 21 23:06:19 anyway, so with the input buffer disabled, the receive shift register simply didn't get clocked Sep 21 23:07:38 hence it remained at its reset value of all-zeros, which is what gets transferred into the fifo after each byte transfer Sep 21 23:07:42 it all makes sense now Sep 21 23:08:28 But I could have sworn that we already tried it with INPUT and set it to OUTPUT or something similar Sep 21 23:08:43 No. Sep 21 23:08:47 That was for miso or mosi Sep 21 23:08:52 Then you're 100% right. Sep 21 23:09:07 so, it's safe to use INPUT for all of them, but it's unnecessary for mosi and cs Sep 21 23:09:21 OUTPUT is okay for those Sep 21 23:10:09 don't forget to add a comment to the pinmux block in your dts ;) Sep 21 23:10:22 Then how on earth was he using OUTPUT for clock (allegedly) successfully?? https://github.com/beagleboard/linux/issues/70#issue-138251579 Sep 21 23:10:29 Oh I will! :D Sep 21 23:10:50 he's not? Sep 21 23:11:08 it says input Sep 21 23:11:21 oh the comment below it Sep 21 23:13:39 Okay, I didn't read careful enough. But that's not important now. I can finally get some sleep and then my brain will work just fine as it used to :) Sep 21 23:14:02 @zmatt Do you have a Bitcoin wallet? Sep 21 23:14:09 those comments just seem to be mentioning whether the pins are input/output in the sense most people would understand it, it's definitely not describing the magic hex values, all of which are 0x33 (pull-up + input enabled + mux 3) Sep 21 23:14:31 hehe, no Sep 21 23:14:35 it's fine Sep 21 23:14:57 No. You restored my mental health with just one message :D Sep 21 23:15:44 I'm glad to have been able to end your misery :) Sep 21 23:18:09 I'm a software architect (with 386asm, C, C++, Qt, JS, ...), so if you need help or something done, please get back at me: mike@wille.io Sep 21 23:18:42 386asm ? poor you Sep 21 23:18:51 Thanks for helping and being helpful while maintaining being super friendly! Sep 21 23:18:58 Yes, it's actually fun :) Sep 21 23:19:13 whenever I occasionally learn more about the x86 architecture, I feel like I was a happier person when I knew less about it Sep 21 23:19:51 ;) Sep 21 23:20:09 Ohh 386 was sooo easy. But don't ask me anything about amd64, you've got to get a PhD on that to understand Sep 21 23:20:23 nah I'm fine with asm, but on modern 32-bit risc architectures please Sep 21 23:21:30 I mean, in 64-bit mode they actually simplified things Sep 21 23:22:00 removed a bunch of ancient cruft (even though it still needs to be supported in 32-bit mode due to backwards compat) Sep 21 23:23:08 like, if I were forced at gunpoint to start writing baremetal x86 code, getting the cpu into 64-bit mode ("long mode" iirc or something) would be my first priority Sep 21 23:23:31 ... not removed enough to make my x230 not boot Windows 98 :) https://twitter.com/AbusingTech/status/1114778742897950720 Sep 21 23:24:08 yeah it's all still there, I mean it still boots up in 16-bit real mode for fuck's sake Sep 21 23:24:35 Oh just use EFI, I love EFI :) It makes everything so much easier. But nobody likes EFI. Sep 21 23:24:55 (EFI does all the mode changes already) Sep 21 23:25:01 Yes, it's amazing! Sep 21 23:25:12 sweet Sep 21 23:25:36 yeah I don't hate EFI as such Sep 21 23:25:57 Amazing thought that when you turn on your computer it's just 1970s until some nanoseconds later when it's already in 200x with long mode Sep 21 23:25:57 like, I'm sure it's awful, but so is the traditional BIOS Sep 21 23:26:13 Absolutely. Sep 21 23:26:51 isn't gate A20 also still implemented by the chipset? controlled via a virtual keyboard controller connected to a virtual ISA bus Sep 21 23:27:02 YEP Sep 21 23:27:09 fucking PCs Sep 21 23:27:30 It was less expensive to just put it into the keyboard controller :) Sep 21 23:27:44 don't deprecate, don't remove, just add. add. add more. keeping adding Sep 21 23:28:59 Thanks to all the businesses who are scared to upgrade I guess? Sep 21 23:34:25 "Intel no longer supports the A20 gate, starting with Haswell." Sep 21 23:34:44 rip A20 gate (1982 - 2013) Sep 21 23:35:11 Ohh.. :( Sep 21 23:35:22 OHHH Sep 21 23:35:51 That explains why I couldn't boot Windows 95/98 on my newer machine. My x230 was pre-Haswell. Sep 21 23:36:34 zmatt you are enlighting me more and more xD Sep 21 23:38:07 someone made a test for it: https://github.com/margaretbloom/disable-a20 Sep 21 23:39:03 "When I run this on my Skylake laptop, the BIOS returned that only the fast A20 method was supported and signaled no error but yet the A20 line was still enabled. Even aver manually disabling it, the A20 line was still enabled." Sep 21 23:40:15 I love these types of projects like that hahah Sep 21 23:44:29 I'll go to bed now. Have a good night! :) Sep 21 23:44:34 and yet I just found a manual of some Skylake-based SBC which has a BIOS option to enable or disable support for gate A20 Sep 21 23:44:37 AAHHHHHHH Sep 21 23:45:08 so it's _still_ not actually gone, not on all systems Sep 21 23:45:24 if you want full and total compatiblity in realmode.... Sep 21 23:45:27 I'd say one should not rely on it anymore :) Sep 21 23:45:31 besides, himem.sys is useful :D Sep 21 23:45:45 yeah so right now it seems it depends on your motherboard and/or bios Sep 21 23:46:18 realmode software may need that extra 64K-16bytes on top of 1M addressing Sep 21 23:48:10 so get hardware of similar age as that software :P **** BEGIN LOGGING AT Tue Sep 22 00:01:28 2020 **** BEGIN LOGGING AT Tue Sep 22 00:20:48 2020 Sep 22 00:21:14 what is the difference between bin and dpg again? Sep 22 00:21:17 for pru firmware Sep 22 00:24:00 bin is just the program, dbg is program + debug information (for each instruction what the corresponding source file and line number is) Sep 22 00:24:48 debugging.py uses that to print instructions Sep 22 00:26:47 program.dbginfo (where program is returned by core.load) contains that debug info (as array indexed by program counter) if you load a .dbg file while it will be None is you load a .bin file Sep 22 00:27:31 if you code doesn't use dbginfo you should just load the .bin file Sep 22 00:29:27 loading a .dbg file also expects that the source code file(s) used to produce the .dbg file to be present (and not modified since compilation) Sep 22 00:31:45 ok **** BEGIN LOGGING AT Tue Sep 22 00:37:20 2020 **** BEGIN LOGGING AT Tue Sep 22 00:55:52 2020 **** BEGIN LOGGING AT Tue Sep 22 00:59:03 2020 **** BEGIN LOGGING AT Tue Sep 22 02:54:17 2020 **** ENDING LOGGING AT Tue Sep 22 02:59:57 2020