**** BEGIN LOGGING AT Mon May 01 03:00:01 2017 May 01 04:01:59 kremlin: btw, the loops in edma_comp_intr() are wrong unless EDMA_NUM_DMA_CHANS is 64, which defeats the purpose of having a #define for it in the first place. the first loop should go up to min(32,EDMA_NUM_DMA_CHANS), not EDMA_NUM_DMA_CHANS/2 May 01 04:02:53 kremlin: or, much simpler and more efficient, use a single 64-bit read and a single loop May 01 04:05:17 EDMA_NUM_DMA_CHANS is 64 May 01 04:05:40 I am aware of that May 01 04:07:02 oh i see what you're saying May 01 04:07:18 but the whole idea behind using a #define instead of a hardcoded number is that the code would still work if the number is different (and edma instances with less than 64 channels do in fact exist in other SoCs) May 01 04:08:36 it looks like using 64-bit reads/writes would simplify quite a bit of the code May 01 04:08:47 instead of having all those ch < 32 tests May 01 04:09:44 hrm. yeah May 01 04:13:39 the api also looks a bit awkward to use.. there's no way to safely keep a steady data stream going since reenabling the channel with edma_trig_xfer_by_dev() after programming the next descriptor also discards any dma event the peripheral may have submitted in the meantime May 01 04:13:56 its not a very well fleshed out driver May 01 04:14:26 im trying to get my callback function passed via the edma_intr_dma_en() to trigger on DMA transfer condition May 01 04:16:36 I think the correct way would be edma_intr_dma_en(); for each transfer { make sure memory region is prepped for dma; edma_param_write(); edma_trig_xfer_by_dev(); start transfer via mmc controller; wait for completion callback; } May 01 04:17:13 ill try that May 01 04:17:20 what do i want to chagne with edma_param_write ? May 01 04:18:38 so, note that struct edma_param in your edmavar.h corresponds to edma::Job in my edma.h May 01 04:18:42 mine is better documented May 01 04:20:13 i have both those files pulled up next to each other, checking May 01 04:20:33 you want { src_fifo = true, fifo_width = 2, c_channel = dma_channel, c_irq = true, May 01 04:20:51 wait, read or write? May 01 04:21:12 both, conditionally May 01 04:21:20 I'll assume read for now, that's what I started with above May 01 04:21:24 ok May 01 04:21:27 write mostly means swap src/dst May 01 04:21:46 lemme actually check if the mmc controller supports fifo mode May 01 04:22:23 it does May 01 04:24:58 src = /*fifo port*/ (mmc_base + 0x220), dst = mem_phys_addr, len = blocksize, count = num_blocks, src_stride = 0, dst_stride = blocksize, count2 = 1 } May 01 04:25:21 that's assuming the mmc controller sends a dma request per block May 01 04:25:28 I haven't checked whether that's true May 01 04:26:00 but I vaguely remember that it does May 01 04:27:14 next should be NULL, which is encoded as 0xffff (as shown in my Job::Link helper class) May 01 04:28:22 hold on May 01 04:28:40 I remembered right, mmc controller sends one dma request per block May 01 04:30:27 * zmatt holds on May 01 04:31:46 why does struct edma_param specify __attribute__((__packed__)) ? all fields are aligned May 01 04:32:39 this is really ugly May 01 04:32:41 but May 01 04:32:43 parm->opt |= (1 | (0x2 << 8) | (sc->dma_ch_rx << 12) | (1 << 20)) May 01 04:33:29 on the bright side, you only need to set the opt field once :) May 01 04:33:31 that sets: source is fifo port, fifo width of 2, rx channel number into what is c_channel in your code, and c_irq also in your code May 01 04:34:05 sounds good May 01 04:34:27 why |= instead of = ? May 01 04:34:35 k trying it May 01 04:34:45 because i'm modifying the extant param struct May 01 04:34:58 what extent param struct? May 01 04:35:02 *extant May 01 04:35:06 the one returned by edma_param_read May 01 04:35:23 you mean the uninitialized random data that's there after reset? May 01 04:35:55 oh, shit, yeah, i guess our edma driver doesn't initialize it May 01 04:36:36 in general if you're setting up the dma for the first time, don't modify edma_param, just initialize it entirely May 01 04:37:03 ok May 01 04:37:07 but hey!! May 01 04:37:12 i think it sort of worked: May 01 04:37:17 Data modified on freelist: word 44730952 of object 0xc49ef560 size 0x10 previous type ??? (invalid addr 0x3381c181) May 01 04:37:19 panic: Data modified on freelist: word 3 of object 0xc49ef560 size 0x10 previous type ??? (0x51f94feb != 0xdeaf4152) May 01 04:37:31 that looks like a kernel panic due to memory suddenly changing May 01 04:37:35 lol May 01 04:37:40 maybe perhaps due to external dma actions May 01 04:37:46 wrong pointer used in dst field? May 01 04:37:54 data modified on freelist May 01 04:38:17 note that if you want to practice with edma you can do memory-to-memory transfers May 01 04:39:10 just pick any unused channel, fill in the job, don't use fifo mode, and then trigger it with edma_trig_xfer_man() May 01 04:42:37 iirc the on-chip sram (ocmc) does support fifo mode, so you can use that as source if you want to use dma to memset() May 01 04:45:28 hrm, now nothing May 01 04:45:36 callback isn't getting fired May 01 04:46:09 might want to make some debug dump helpers, especially since the driver currently doesn't enable any of the error-irqs May 01 04:52:27 wait May 01 04:53:04 * zmatt waits May 01 04:53:04 you're saying i should set the edma PaRAM src (offset 0x4) value to the SD_DATA register? May 01 04:53:12 and not SD_ARG? May 01 04:54:02 what's SD_ARG ? May 01 04:54:36 the register you fill with the target address when performing sd/mmc read/write May 01 04:54:55 SD_DATA is filled with the requested data in the case of a write May 01 04:55:00 err May 01 04:55:01 read ** May 01 04:55:25 SD_DATA isn't really a register, it's a fifo port May 01 04:56:10 oh ok May 01 04:56:22 the argument is the offset on the mmc you want to read from or write to (in bytes for <2GB devices, in sectors for >=2GB devices) May 01 04:57:21 dma doesn't care about that part of course, it just reads from the SD_DATA port and writes to memory, or vice versa May 01 05:02:48 https://ce.gl/ommmc.txt May 01 05:02:51 let's see how this works May 01 05:04:58 note that {src_fifo=true, dst_fifo=false, fifo_width=2} means the inner "copy loop" is something like void memcpy_srcfifo32(u32 *dst, u32 const volatile *src, size_t len) { assert(len > 0 && len % 4 == 0 && (src & 31) == 0); do *dst++ = *src; while( len -= 4 ); } May 01 05:06:01 wetware fails to parse May 01 05:06:05 (this would replace the plain "memset" in the conceptual code at the top of my edma3-tc.h header) May 01 05:06:30 copy it into an editor with syntax highlighting and reformat it... that should help ;) May 01 05:09:59 ok May 01 05:10:01 i sorta see May 01 05:10:41 that's why fifo mode is also known as "constant addressing mode" May 01 05:12:12 the fifo port width configured in edma should always match the width of the data port of the peripheral, which is 32-bit for all L4 peripherals and 32-, 64-, or 128-bit for L3 peripherals (varies) May 01 05:12:56 the requirement that the fifo port is located at a 32-byte aligned address is a weird constraint of which I don't know the reason May 01 05:13:59 most fifo ports happen to satisfy that constraint fortunately. the SPI controller originally violated it, but they added a config bit that moves the fifo port to a 32-byte aligned address :) May 01 05:21:27 geez May 01 05:21:53 i'm losing steam, i think im going to call it a night May 01 05:22:06 hey THANKS a ton for your help, honestly, i am miles ahead of where i would've been w/o it May 01 05:22:12 it's really appreciated May 01 05:26:32 you're welcome! I'm off too May 01 14:48:06 zmatt: hello, I'm back again May 01 15:48:39 sudden6: I only looked at it briefly, but while last time I tried suspend I had no trouble with it, this time I couldn't get it into suspend at all for some reason :/ May 01 15:48:57 probably something wonky about my system May 01 15:58:56 zmatt: I just figured out the problem, the external 5V power supply has to be connected May 01 15:59:40 at least thats what makes the rtcwake work May 01 16:58:42 that sounds strange May 01 16:59:05 also means it's a blue-specific problem May 01 17:00:14 blue? May 01 17:00:23 oh wait nm I confused you with someone else May 01 17:00:31 ok, np May 01 17:01:09 so you mean it doesn't work when powered via usb? that also doesn't really make sense May 01 17:01:30 yes May 01 17:02:07 I don't see how or why the system could possibly care May 01 17:02:46 normally linux doesn't even really know which of the two is being used May 01 17:02:49 it's on a different pin on the pmic, maybe the ic decided wakeup from usb isn't possible^^ May 01 17:02:57 pmic isn't involved in any of this May 01 17:03:30 or, well, the voltage rails are lowered to retention levels by the firmware running on the cortex-m3 May 01 17:03:36 but that's it May 01 17:03:37 isn't the pmic responsible for turning on and of the voltages May 01 17:03:45 none of the voltages from the pmic are turned off May 01 17:03:55 all power gating is done inside the am335x May 01 17:05:44 supplies from the pmic are only turned off when you shut down May 01 17:06:03 (in which case the rtc loses power as well) May 01 17:07:13 hello, we are designing a beagleboard-X15-based system and it is now failing to boot u-boot version 2017.01. If I install version 2016.05 on the same uSD card, the board boots fine. Here is the boot log: https://pastebin.com/vMRE9J1W May 01 17:07:27 Here is the log of a successful boot: https://pastebin.com/n44YmGMZ May 01 17:10:08 raffo: looks like they probably switched to 'driver model' for mmc May 01 17:10:45 maybe check where those DTs it tries to match come from, and how they are matched May 01 17:12:32 I'm not sure how it's supposed to work either, since the config menu claims that embedding a DT is just a dev option and not meant for general use, but I don't see how it could obtain a DT early enough if not embedded May 01 17:14:11 I see there's "am57xx_evm_defconfig" and "am57xx_evm_nodt_defconfig", which one did you use? May 01 17:14:39 we're looking into forcing a the boot loader to use one of the beagleboard models. We don't have eprom with a board ID stored in it. May 01 17:15:09 that sounds inconvenient May 01 17:15:30 I see in am57xx_evm_defconfig that the list of DTs is right there May 01 17:15:46 along with the default DT to use May 01 17:15:56 I'm using the u-boot that came with the uSD image. I presume it was built with am57xx_evm_defconfig, but I haven't checked. I could build both configurations and test. May 01 17:16:32 if your board doesn't have board id I don't see how any unmodified u-boot could work May 01 17:17:08 perhaps it would have been smarter to retain the eeprom in your design :) May 01 17:17:23 yeah, version 2016.05 was booting fine. May 01 17:18:00 ha ha, that's what I said in one of our meetings. May 01 17:18:18 looks like it both cases it fails to detect the board and defaults to the beagleboard-x15 config May 01 17:18:28 no sure why that config doesn't work anymore for you May 01 17:19:35 hmm, or maybe the fallback doesn't work in the new u-boot May 01 17:19:51 RCN just sent me a suggestion to try. I think the issue is the lack of eeprom. May 01 17:20:03 it's a bit odd, the fact it knows about "mmc@4809c000" means it has some DT knowledge May 01 17:20:11 yet it can't find the pinctrl state May 01 17:23:30 Looks like I need to customize this: http://git.ti.com/gitweb/?p=ti-u-boot/ti-u-boot.git;a=blob;f=board/ti/am57xx/board.c;h=af6b7f6303a00c958e48ef47439061e2776d4901;hb=refs/heads/ti-u-boot-2017.01#l1000 **** ENDING LOGGING AT Tue May 02 03:00:01 2017