**** BEGIN LOGGING AT Mon Aug 19 02:59:57 2019
Aug 19 07:51:14 <nexgen> hello
Aug 19 07:51:21 <nexgen> please let me know
Aug 19 07:51:37 <nexgen> is there any method to boot from SD without pressing key combination?
Aug 19 07:51:48 <nexgen> may be creating some file on SD?
Aug 19 07:52:06 <nexgen> or only changing uboot config on eMMC?
Aug 19 08:00:03 <thinkfat_> nexgen: you kill the bootloader on the eMMC
Aug 19 08:00:25 <nexgen> please explain
Aug 19 08:00:45 <nexgen> can I boot from eMMC uboot->SD ?
Aug 19 08:01:05 <thinkfat_> yes, you can do that, too. if you're fine with the uboot version on the eMMC
Aug 19 08:01:15 <nexgen> or directly from SD if BROM looks for some file on it?
Aug 19 08:01:18 <zmatt> nexgen: if the contents of eMMC is not important, just wipe eMMC with blkdiscard
Aug 19 08:02:07 <nexgen> what is I cannot boot from a new image written to eMMC? Do you have some etolone image to restore ?
Aug 19 08:02:27 <zmatt> you asked about booting from SD card
Aug 19 08:02:29 <nexgen> is eMMC available as a block device if BBB is attached to PC?
Aug 19 08:02:34 <zmatt> no
Aug 19 08:03:08 <nexgen> how can I boot from SD except pressing key combination you suggested earlier?
Aug 19 08:03:16 <zmatt> I already answered that
Aug 19 08:03:58 <nexgen> if eMMC in blank then BBB tries to boot from SD?
Aug 19 08:03:59 <zmatt> note that normally the S2 button isn't required to boot from SD card, it is only needed if a bootloader is present on eMMC that is not compatible with the system on SD card
Aug 19 08:04:03 <zmatt> yes
Aug 19 08:04:23 <nexgen> how BBB treats eMMC being blank?
Aug 19 08:04:40 <nexgen> does it expects first fat partition?
Aug 19 08:05:07 <nexgen> can I still have some other partition or specific layout for BBB to treat it still blank?
Aug 19 08:05:09 <zmatt> if eMMC is blank it will simply skip it and try the SD card
Aug 19 08:05:30 <nexgen> how does it determines if eMMC is actually blank?
Aug 19 08:05:40 <nexgen> it checks MBR partition table?
Aug 19 08:06:26 <nexgen> can I trick partition layout to make eMMC it is blank while actually it is not
Aug 19 08:06:40 <zmatt> it looks for a specific header at sector 256*i for i=0..3 and if none is found then it checks for a DOS partition table with a FAT partition containing an "MLO" file... I think it needs to be the first partition too but I'm not sure, I don't remember
Aug 19 08:06:48 <zmatt> the official images use sector 256
Aug 19 08:07:38 <zmatt> so if you just create an ext4 partition or whatever on a blank eMMC, it will never be considered bootable
Aug 19 08:08:30 <zmatt> (it is recommended that the first partition starts at offset 4MB)
Aug 19 08:08:49 <zmatt> what kind of bizarre setup are you trying to accomplish?
Aug 19 08:10:52 <nexgen> thank you very much for the information
Aug 19 08:10:58 <nexgen> I just want to boot from SD
Aug 19 08:11:06 <nexgen> and use eMMC for some data
Aug 19 08:11:18 <zmatt> that's really unusual, why not boot from eMMC ?
Aug 19 08:11:24 <nexgen> rarely used data to avoid eMMC waste
Aug 19 08:13:26 <nexgen> 1) I am afraid there may be some substitution/injection of undesirable code during booting
Aug 19 08:13:27 <nexgen> 2) I would like to reduce its waste
Aug 19 08:14:27 <zmatt> (consumer) SD cards are considerably less reliable than eMMC, and on the BBB the SD card slot only has half the max transfer speed as the eMMC interface
Aug 19 08:14:39 <zmatt> 1 makes no sense
Aug 19 08:14:57 <zmatt> SD card and eMMC are basically the same
Aug 19 08:15:50 <zmatt> apart from some minor differences in initialization, booting from SD card and booting from eMMC works exactly the same
Aug 19 08:18:16 <zmatt> and I can understand the concern about eMMC wear-out, although that should take a long time unless you're doing really crazy things.  if it does wear out, you can still switch to booting from SD card then
Aug 19 08:19:25 <zmatt> a typical SD card will wear out about 10x faster
Aug 19 08:20:38 <zmatt> (if it uses a good wear leveling algorithm, it'll depend on the amount of free space on the card)
Aug 19 08:20:47 <tbr> and if you want more reliability, switch to SLC :)
Aug 19 08:25:09 <zmatt> yup, you can (irreversibly) reconfigure the eMMC into pSLC mode at the cost of sacrificing 50% storage capacity, and you can also buy SLC/pSLC microSD cards
Aug 19 08:27:07 <zmatt> we do actually reconfigure the eMMC in that way to maximize lifetime (along with putting in some effort to avoid unnecessary writes and monitoring of eMMC write stats)
Aug 19 08:33:07 <nexgen> sorry, connection lost
Aug 19 08:33:14 <nexgen> Reason of my preference to bood from SD:
Aug 19 08:33:16 <nexgen> 1) I am afraid there may be some substitution/injection of undesirable code during booting
Aug 19 08:33:18 <nexgen> 2) I would like to reduce its waste
Aug 19 08:33:42 <nexgen> Does BROM expects on SD the same layout as on eMMC?
Aug 19 08:34:00 <zmatt> don't repaste stuff you already said 20 minutes ago.  just because you have connection problems doesn't mean we do
Aug 19 08:34:08 <nexgen> so it can boot from MLO on SD?
Aug 19 08:34:24 <zmatt> https://pastebin.com/PUjVVN3b
Aug 19 08:34:54 <nexgen> just to be sure my messages have been delivered
Aug 19 08:35:02 <nexgen> I cannot verify this
Aug 19 08:38:42 <nexgen> thanks for the transcript
Aug 19 08:39:15 <nexgen> there are some clones of BBB
Aug 19 08:39:25 <nexgen> with 1GB of RAM
Aug 19 08:39:32 <nexgen> what is the best one?
Aug 19 08:39:45 <nexgen> most RAM and may be something else?
Aug 19 10:15:52 <tbr> "best"
Aug 19 11:07:23 <zmatt> I'm not aware of more than one existing
Aug 19 11:07:28 <zmatt> (with 1GB ram)
Aug 19 11:11:32 <zmatt> well and apparently Special Computing offers a customized BBB with 1GB ram and 8GB eMMC (bulk orders only, price unspecified)
Aug 19 12:25:02 <dcmertens> g'morning
Aug 19 12:25:05 <dcmertens> zmatt, I figured it out
Aug 19 12:25:17 <dcmertens> the undulations are caused by CPU activity
Aug 19 12:25:31 <dcmertens> I rewrote the kernel to have the PRU store the data directly with DMA
Aug 19 12:25:37 <dcmertens> everything went away
Aug 19 12:25:56 <dcmertens> It turns out that using DMA also simplifies the kernel
Aug 19 12:26:03 <dcmertens> (where by "kernel" I mean the assembly code)
Aug 19 12:26:27 <zmatt> ah I was puzzled how the kernel was involved
Aug 19 12:26:37 <zmatt> but it still doesn't make any sense
Aug 19 12:27:09 <zmatt> I don't see any plausible way PRU's "activity" is relevant, especially since it typically has constant 100% cpu load (unless you use the SLP instruction)
Aug 19 12:28:55 <dcmertens> it's not the PRU that's causing trouble, it's the ARM core
Aug 19 12:29:18 <dcmertens> every 768 steps, I would signal to the core to copy data out of the PRU shared memory
Aug 19 12:29:19 <zmatt> that also seems odd, but also I then don't understand what you changed
Aug 19 12:29:33 <zmatt> to?
Aug 19 12:29:46 <dcmertens> to normal CPU-side arrays
Aug 19 12:30:06 <dcmertens> but, now I have the PRU store the data into a CPU-accessible array
Aug 19 12:30:31 <zmatt> I mean, you already were, but one that was too small :P
Aug 19 12:30:33 <dcmertens> what this all means is that my analog circuitry is really terrible
Aug 19 12:30:36 <dcmertens> :-P
Aug 19 12:30:45 <zmatt> that still seems very odd to me
Aug 19 12:30:51 <zmatt> the cpu runs on a completely independent power supply
Aug 19 12:31:12 <dcmertens> well, sure, but if you look at the wires I actually use to power the system...
Aug 19 12:31:38 <zmatt> the ADC uses the 1.1V core supply for digital logic and a separate filtered 1.8V supply for analog stuff
Aug 19 12:32:06 <zmatt> the CPU runs on its own switching power supply that's part of the pmic (typically at 1.35V but it depends on cpufreq)
Aug 19 12:32:39 <zmatt> (at least I think it was 1.35V for 1GHz, don't hold me to it:P )
Aug 19 12:33:12 <dcmertens> I don't doubt you on that
Aug 19 12:33:29 <zmatt> the patterns you were seeing were huge, so if those are really caused by cpu load then something really funky is going on
Aug 19 12:34:11 <dcmertens> 40/4000? that's 0.1%
Aug 19 12:34:11 <zmatt> actually how big were they?  I thought I rememebered they were pretty big but now I'm not sure anymore
Aug 19 12:34:14 <zmatt> ah
Aug 19 12:34:22 <zmatt> I guess the vertical scale was rather zoomed in
Aug 19 12:34:28 <dcmertens> indeed. :-)
Aug 19 12:34:37 <dcmertens> but, still noticeable in my data analysis
Aug 19 12:34:44 <dcmertens> because I was computing differences
Aug 19 12:35:21 <zmatt> can I see your adc config again?
Aug 19 12:35:36 <zmatt> (i.e. the code that configures the adc)
Aug 19 12:35:38 <dcmertens> yeah, though I've simplified it now to use a single fifo. :-)
Aug 19 12:36:03 <zmatt> good
Aug 19 12:36:26 <dcmertens> Here's the latest: https://nopaste.xyz/?2c396e780fd722ef#vd1q0rS5oPYfXRE5/7DEQrmAaOQFqz//IlYx+lMGD+M=
Aug 19 12:36:49 <zmatt> did you see the last bit I said last time just after you said you were out?
Aug 19 12:37:30 <zmatt> ugh, what's with the enormous url
Aug 19 12:37:47 <dcmertens> hmm...
Aug 19 12:37:55 <dcmertens> sorry about the URL, I just used the website
Aug 19 12:38:15 <zmatt> maybe some other paste service? *any* other :P  e.g. pastebin.com
Aug 19 12:38:26 <dcmertens> heh heh
Aug 19 12:38:27 <dcmertens> sure
Aug 19 12:38:46 <zmatt> it's not a huge deal but these are wider than my terminal and that makes them a bit annoying to copy-paste
Aug 19 12:38:58 <dcmertens> sure, gimme a sec...
Aug 19 12:39:08 <zmatt> it's fine for now
Aug 19 12:39:20 <zmatt> just... preferably something that produces shorter urls in the future :P
Aug 19 12:39:37 <dcmertens> well, I did ask if there was a preferred pastebin when I came on...
Aug 19 12:39:44 <dcmertens> anyway, were you referring to the overlays?
Aug 19 12:39:55 <dcmertens> I tried that, but had no luck
Aug 19 12:40:03 <zmatt> hmm what?
Aug 19 12:40:09 <dcmertens> when I enabled your one-liner, the ADC simply didn't work
Aug 19 12:40:14 <dcmertens> I didn't dig into it much
Aug 19 12:40:16 <dcmertens> no wait
Aug 19 12:40:19 <dcmertens> that's not true
Aug 19 12:40:27 <zmatt> my one-liner just keeps the ADC enabled
Aug 19 12:40:29 <dcmertens> scratch that: it cause the SPI interface to fail
Aug 19 12:40:36 <zmatt> ??!??
Aug 19 12:40:38 <dcmertens> yeah
Aug 19 12:40:51 <dcmertens> so...
Aug 19 12:40:58 <dcmertens> I just went back to the previous setup
Aug 19 12:40:58 <zmatt> "fail" ?
Aug 19 12:41:23 <dcmertens> let me see if I can scroll back and find the error message...
Aug 19 12:41:24 <zmatt> I mean you really shouldn't have the kernel driver enabled while doing this
Aug 19 12:41:45 <dcmertens> You like your "should"s :-P
Aug 19 12:41:50 <zmatt> I do
Aug 19 12:42:17 <zmatt> I use the adc too, I sure as hell don't have the kernel driver enabled :P
Aug 19 12:42:50 <zmatt> dnuno if I use ti,no-idle though.... maybe I just fiddle the PRCM manually... it's old code so I might not have known about ti,no-idle yet
Aug 19 12:43:08 <zmatt> ah, indeed
Aug 19 12:44:19 <dcmertens> the error was that when I tried to open a file descriptor to "/dev/spidev1.0", I got a negative file handle
Aug 19 12:44:57 <dcmertens> when I got that, I just rolled it back
Aug 19 12:45:59 <dcmertens> now, this could be because I have old software on these BBs, from last summer
Aug 19 12:46:07 <dcmertens> and your stuff assumes newer software
Aug 19 12:47:26 <zmatt> that's not a useful error, what does the kernel log say?
Aug 19 12:47:46 <zmatt> ehh, what does your /boot/uEnv.txt look like?
Aug 19 12:48:58 <dcmertens> https://pastebin.com/qwxZEuJk
Aug 19 12:49:05 <dcmertens> ^^^ /boot/uEnv.txt
Aug 19 12:49:12 <dcmertens> where would I find the kernel log?
Aug 19 12:49:25 <zmatt> ok so not actually old
Aug 19 12:49:47 <dcmertens> no? I thought it was from last summer
Aug 19 12:49:50 <zmatt> journalctl -k --no-pager -b     for example
Aug 19 12:50:17 <zmatt> well I mean, it uses u-boot overlays and a 4.14 kernel
Aug 19 12:51:02 <dcmertens> it wouldn't just be in /var/log/kern.log ?
Aug 19 12:51:26 <zmatt> no idea what, if anything, your syslogd, if one is installed, writes there
Aug 19 12:51:38 <zmatt> I haven't used a syslogd in many years
Aug 19 12:51:44 <dcmertens> it looks like a bootup log
Aug 19 12:53:00 <zmatt> removing rsyslog and removing most of the contents of /var/log is among the first things I do if I start with a clean BBB image, to avoid unnecessary eMMC writes.  runtime journal is usually perfectly sufficient
Aug 19 12:54:00 <dcmertens> turns out the journalctl command gives basically the same thing as /var/log/kern.log, which is the boot log
Aug 19 12:54:34 <zmatt> I mean, sure?
Aug 19 12:54:43 <zmatt> there are more ways to dump it too
Aug 19 12:54:52 <zmatt> I just offered *one* way since you asked for one
Aug 19 12:56:05 <zmatt> also, it looks like you're using the absolute minimum sample time (2 cycles), you maaay want to bump that a bit :P
Aug 19 12:56:30 <dcmertens> zmatt, maybe, if that reduces noise. I'll have to play with it and see if it improves things
Aug 19 12:56:33 <zmatt> setting clkdiv to zero is also a bad idea... and might even be a datasheet violation, but I'd need to double-check that
Aug 19 12:56:44 <dcmertens> I don't think so
Aug 19 12:56:50 <zmatt> yeah I'm not 100% sure
Aug 19 12:56:52 <dcmertens> I think it sets the actual clockdiv to whatever you pass + 1
Aug 19 12:56:58 <zmatt> it does yes
Aug 19 12:56:59 <dcmertens> (but maybe I'm thinking about something else)
Aug 19 12:59:10 <zmatt> it seems I set the clkdiv register to 1 (i.e. use a /2 divider)
Aug 19 13:01:11 <zmatt> and I set sample_time to 28  (i.e. 20 cycles of sampling + 13 cycles conversion = 33 cycles per step) ... I don't remember whether that value was picked for some good reason or mostly arbitrary :P
Aug 19 13:01:17 <zmatt> 18 sorry
Aug 19 13:02:17 <dcmertens> good to know. I have not played with these settings at all, but I may look into them
Aug 19 13:03:49 <dcmertens> I am now reaching the point where I'm really driving down the noise and other sources of uncertainty
Aug 19 13:03:56 <dcmertens> so now is the time for me to play with these thngs
Aug 19 13:04:05 <zmatt> and configured it to alternate between sampling an actual channel and sampling vref- ... presumably to ensure that should the sample time be too low it would just result measurements which are a bit low rather than channel cross-talk
Aug 19 13:05:31 <zmatt> your code still looks like it's causing fifo underflows... and it's not checking results, hence not noticing those fifo underflows
Aug 19 13:06:31 <zmatt> *checking for errors I mean
Aug 19 13:07:35 <dcmertens> fifo underflows?
Aug 19 13:07:55 <zmatt> oh never mind
Aug 19 13:07:56 <zmatt> I see now
Aug 19 13:08:00 <zmatt> no I don't
Aug 19 13:08:14 <dcmertens> You mean asking the fifo for data when it's not there?
Aug 19 13:08:18 <zmatt> yes
Aug 19 13:08:35 <dcmertens> It always asks for data after cueing the *next* read
Aug 19 13:09:00 <dcmertens> so there should always be four entries available
Aug 19 13:09:24 <dcmertens> the only situation where I would get a fifo underflow is if I cue four more samples before the first four have finished
Aug 19 13:09:36 <dcmertens> and I think I'll figure out that sampling rate "the hard way"
Aug 19 13:09:49 <dcmertens> and then put something in my documentation to "never use sampling rates faster than XX"
Aug 19 13:09:52 <dcmertens> :-)
Aug 19 13:10:04 <zmatt> yes but the first time there's nothing ensuring the first measurement has completed... also, if for whatever reason you get a trigger before the adc is done, a mess ensues
Aug 19 13:10:22 <dcmertens> zmatt, the first time, it waits for the *next* trigger from the external system
Aug 19 13:10:27 <dcmertens> which'll be 50us later
Aug 19 13:10:30 <zmatt> I'd suggest the simpler structure   loop { wait for trigger; start sampling; wait until done; copy data; }
Aug 19 13:10:32 <dcmertens> (or whatever)
Aug 19 13:12:15 * dcmertens shrugs
Aug 19 13:12:20 <zmatt> dcmertens: what's ensuring that a vclock- pulse doesn't occur immediately after you've done the adc setup and entered the acquisition loop the first time?
Aug 19 13:13:05 <zmatt> ohhhh
Aug 19 13:13:12 <zmatt> sorry I'm blind
Aug 19 13:13:42 <dcmertens> perhaps I should have highlighteed the QBEQ a bit better
Aug 19 13:13:45 <zmatt> it's still unnecessarily complicated and fragile
Aug 19 13:13:56 <dcmertens> but, it ensures I have the most time possible to do other things
Aug 19 13:14:01 <dcmertens> and the next step is to add other things
Aug 19 13:14:38 <zmatt> ah I see... I was about the say copying the data takes negligible time, but I should have realized that saving it to ram is merely a placeholder
Aug 19 13:15:02 <dcmertens> yep
Aug 19 13:15:26 <dcmertens> I may still be over-engineering, but that's a tradeoff I'm willing to make
Aug 19 13:15:43 * dcmertens makes a bigger comment around the first-sample QBEQ
Aug 19 13:16:12 <zmatt> hey, if you really want to overengineer to have maximum time you could have one pru core deal with triggering the adc and the other wait for adc irq and process the data :)
Aug 19 13:16:42 <dcmertens> I thought about that...
Aug 19 13:17:55 <dcmertens> speaking of which, I've realized I'll want to send outputs to non-enhanced GPIO, and to SPI
Aug 19 13:17:59 <zmatt> so eh.. didn't you have a pretty short trigger interval?
Aug 19 13:18:10 <dcmertens> five clocks, or something? yeah
Aug 19 13:18:25 <zmatt> "five clocks" ?
Aug 19 13:18:55 <dcmertens> I have a BB that holds the voltage signal HI for seven clock cycles
Aug 19 13:19:02 <zmatt> "clock cycles" ?
Aug 19 13:19:02 <dcmertens> seven PRU clock cycles
Aug 19 13:19:14 <zmatt> that's pulse length though, not trigger interval :P
Aug 19 13:19:34 <dcmertens> oh, that's configurable
Aug 19 13:19:59 <zmatt> anyway, isn't sampled_cued (queued :P ) going to overflow in a few days time?
Aug 19 13:20:09 <zmatt> and trigger the QBEQ again
Aug 19 13:20:19 <zmatt> ohhh
Aug 19 13:20:20 <zmatt> I see now
Aug 19 13:20:20 <dcmertens> oh sure
Aug 19 13:20:22 <zmatt> finite number of samples
Aug 19 13:20:25 <dcmertens> right
Aug 19 13:20:34 <dcmertens> my experiments don't last much longer than a second
Aug 19 13:21:00 <dcmertens> my biggest limitation on duration is going to be the size of the external memory, which is 8MB
Aug 19 13:21:11 <dcmertens> which comes out to 2^20 samples
Aug 19 13:21:27 <zmatt> the pru shared memory in ddr you mean?  its size is configurable
Aug 19 13:21:32 <dcmertens> which I think will be enough for my longest measurements. we'll see
Aug 19 13:21:32 <dcmertens> yeah
Aug 19 13:21:43 <dcmertens> right, I can change it with a system command
Aug 19 13:21:48 <zmatt> kernel parameter
Aug 19 13:21:50 <zmatt> iirc
Aug 19 13:21:52 * dcmertens forgot the system command at the moment
Aug 19 13:22:15 <dcmertens> you say "kernel parameter", I say "thing changed with a system command"
Aug 19 13:22:28 <zmatt> thing changed by editing /boot/uEnv.txt :p
Aug 19 13:22:36 <dcmertens> no no
Aug 19 13:22:44 <dcmertens> I think it can be changed after boot
Aug 19 13:24:02 <zmatt> hmm nope?
Aug 19 13:25:01 <zmatt> anyway, I do suggest you try fiddling with the adc's parameters to reduce noise/crud
Aug 19 13:26:11 <zmatt> since I also remember that configuring everything to minimum yielded... sub-optimal... results
Aug 19 13:26:37 <dcmertens> zmatt, thanks, I'll look into it
Aug 19 13:26:45 <dcmertens> that really is next on my list
Aug 19 13:27:07 <zmatt> if you suspect power supply fluctuations are a factor it might be interesting to measure a voltage created from adc 1.8v by a voltage divider instead of using an independent voltage
Aug 19 13:27:28 <dcmertens> and as for the size of the ddr, if it is set in /boot/uEnv.txtt, I'll have to update all the BBs on my system, which is a high enough barrier that I'll only do it if I really, really need to
Aug 19 13:28:11 <zmatt> also, try changing your ref+ and ref- selection from vdda/vssa (0) to vref+/vref- (3)
Aug 19 13:28:13 <dcmertens> zmatt, no, that part of the design is unchangeable
Aug 19 13:28:23 <zmatt> even for a quick test?
Aug 19 13:28:29 <dcmertens> it doesn't matter
Aug 19 13:28:34 <dcmertens> the PCBs have been printed and soldered
Aug 19 13:28:53 <dcmertens> so, that inputs to the BB are not going to change
Aug 19 13:29:27 <zmatt> and you're sure your voltage outputs are actually stable and not getting involved by the rest of the system in some way?
Aug 19 13:29:48 <zmatt> *getting affected
Aug 19 13:29:50 <dcmertens> but I'll play around with it and see if anything gives better results. I didn't touch those settings earlier because there was nothing documenting why or how they would be useful or better
Aug 19 13:30:20 <dcmertens> on no, that is *exactly* the problem
Aug 19 13:30:20 <zmatt> yeah, some empirical science may be needed
Aug 19 13:30:26 <dcmertens> the voltage outputs *are* effected
Aug 19 13:30:31 <dcmertens> I observed them with a scope
Aug 19 13:30:42 <zmatt> ehm, well then the adc is working fine
Aug 19 13:30:46 <dcmertens> right!
Aug 19 13:31:11 <dcmertens> so we come back to my observation: if I tell the CPU to be quiet, the signal is much cleaner
Aug 19 13:31:19 <dcmertens> and that's really all I need to know
Aug 19 13:31:41 <dcmertens> so, next on my list is to fiddle with the ADC parameters and see if I can reduce the noise on the signal
Aug 19 13:31:45 <zmatt> I mean, that would be a hardware issue in your pcb then right?
Aug 19 13:31:51 <dcmertens> exactly
Aug 19 13:31:55 <dcmertens> and that's not going to change now
Aug 19 13:32:12 <dcmertens> but I can minimize it. :-)
Aug 19 13:32:29 <dcmertens> actually, the biggest source of noise was the trigger signal
Aug 19 13:32:32 <zmatt> probably not using adc parameters though, but you can try.
Aug 19 13:33:02 <dcmertens> so my next step is to use the PRU's clock rather than an external trigger
Aug 19 13:33:16 <dcmertens> use the external trigger for the first point, then everything after that is tracked internally
Aug 19 13:34:36 <zmatt> the adc *can* affect the voltage levels since it needs to charge internal capacitance from the adc input... that's why sufficient sampling time is needed, and the higher the impedance of the voltage source connected to the analog input, the higher the sampling time needs to be
Aug 19 13:34:52 <zmatt> but this would be the same every time
Aug 19 13:35:54 <zmatt> I'd definitely try setting bits 12, 13, 23, and 24
Aug 19 13:36:28 <dcmertens> the ADC is being fed outputs from an op-amp, so the output impedance should be pretty low
Aug 19 13:36:37 <dcmertens> but, I still mean to fiddle with those
Aug 19 13:37:04 <zmatt> no series resistor on the output?  oof, I hope you won't run into trouble with the ADC erratum
Aug 19 13:37:26 <dcmertens> hmm?
Aug 19 13:37:45 <dcmertens> what is "ADC erratum"?
Aug 19 13:38:48 <zmatt> see AM335x Errata, Advisory 1.0.32
Aug 19 13:39:00 <dcmertens> oh how delightful...
Aug 19 13:39:18 <zmatt> anyway, doesn't matter since the hardware can't be changed :)
Aug 19 13:39:39 <zmatt> so no point in worrying about it
Aug 19 13:42:48 <dcmertens> sheesh, now I'm worrying about itt
Aug 19 13:42:56 <dcmertens> well, what's the worst that can happen?
Aug 19 13:42:59 <dcmertens> I fry my BBs?
Aug 19 13:43:08 <dcmertens> not worried about it
Aug 19 13:43:13 <dcmertens> they've been running for months now
Aug 19 13:43:15 <dcmertens> and now smoke yet
Aug 19 13:43:19 <dcmertens> *no smoke
Aug 19 13:54:29 <zmatt> it's only a concern during powerup, not while running
Aug 19 13:56:49 <zmatt> anyway, overall it doesn't sound like you're facing an adc issue, you have some sort of hardware issue... maybe switching to vref+/vref- and/or increasing sampling time and/or clkdiv helps, but it'll be hard to guess what might or might not help as long as the root cause is unknown, which means hardware debugging :)
Aug 19 13:59:51 <dcmertens> zmatt, thinking about maximum duration, the 8MB DDR memory limitation is not likely to be the biggest hangup
Aug 19 14:00:00 <dcmertens> I think I'll want to use the cycle counter
Aug 19 14:00:14 <dcmertens> which stop counting after 2^32 cycles, which is 21.5s
Aug 19 14:00:30 <zmatt> yeah the cycle counter is intended for profiling, not really as timer
Aug 19 14:00:39 <dcmertens> (whereas 2^20 samples * 50us/sample = 52.4s)
Aug 19 14:00:56 <dcmertens> I've red that I can get it working again by disabling and re-enabling
Aug 19 14:01:07 <dcmertens> but it seems that would take some variable amount of time?
Aug 19 14:01:21 <dcmertens> or no...
Aug 19 14:01:40 <dcmertens> you only have to worry about time uncertainties when working with peripherals, right?
Aug 19 14:02:50 <zmatt> keeping continuous time with the cycle counter would be a big mess, at that point it would be better to use a real timer (iep or ecap)
Aug 19 14:03:29 <dcmertens> oh!!
Aug 19 14:03:31 <dcmertens> neat!
Aug 19 14:11:36 <dcmertens> wait, so could I just tell the ecap to give me an interrupt every "period" and then listen for interrupts on it?
Aug 19 14:39:56 <samael> i'm new to relatevely recent bbb debian images and kernel. i'm using a 2018-10-14 image running on 4.14.71-ti-r80. why there are two usb network interfaces?
Aug 19 15:12:50 <rcn-ee[m]> samael: one is for Windows built-in driver, the other for Mac OSX's built-in driver..
Aug 19 15:41:10 <samael> rcn-ee[m]: good to know. i use linux, so i guess i can just ignore the new interface and keep using the one with 192.168.7.1
Aug 19 15:41:41 <rcn-ee[m]> use either.
Aug 19 15:43:05 <samael> what about the two can interfaces? are they linked someway to the can hardware on board? i have a couple of comms capes, are their can interfaces compatible with later images?
Aug 19 15:43:55 <rcn-ee[m]> correct
Aug 19 15:45:05 <samael> good, thanks
Aug 19 16:06:31 <thinkfat> zmatt: an LTS EOL being bumped usually means a vendor pays for it being supported longer than the standard two years
Aug 19 16:07:07 <thinkfat> zmatt: but I doubt 4.19 is going to experience a lifetime extension
Aug 19 16:08:10 <rcn-ee[m]> unless your using 'vendor' would it matter? ;)
Aug 19 16:09:16 <thinkfat> rcn-ee[m]: ?
Aug 19 16:11:02 <thinkfat> rcn-ee[m]: let's say, if I'm a tier-3 rather than a tier-1 or -2, I'm alwas glad if I have a maintained kernel I can use as a baseline for my own product, without going through the hassle of patching security flaws myself ;)
Aug 19 16:11:53 <thinkfat> rcn-ee[m]: if I'm not on a "launch-and-forget" product strategy, that is
Aug 19 16:13:49 <rcn-ee[m]> Let's look at 4.9 and debian's page on spectre: https://wiki.debian.org/DebianSecurity/SpectreMeltdown
Aug 19 16:14:25 <rcn-ee[m]> 4.9 is still an lts but noticed, not all security fixes have been fixed..
Aug 19 16:14:40 <rcn-ee[m]> so in your case, wait two years and v4.19.x could look like 4.9.x on that chart..
Aug 19 16:16:44 <rcn-ee[m]> the other point on that chart, while v4.9.x-lts isn't as safe as 4.14.x-lts, it's still way better then 4.10.x.. ;)
Aug 19 16:17:09 <thinkfat> yep
Aug 19 16:17:43 <rcn-ee[m]> 4.19.x-lts should be good for another year, 5.4.x-lts will be this fall..
Aug 19 16:18:24 <thinkfat> to me 4.14 looks rather attractive, but it's really an old kernel in linux terms
Aug 19 16:18:59 <rcn-ee[m]> unless your running RT, then 4.19.x is better. ;)
Aug 19 17:15:19 <zmatt> thinkfat: "I doubt 4.19 is going to experience a lifetime extension"  how come?
Aug 19 17:17:14 <vagrantc> given debian stable is using linux 4.19, pretty sure ben hutchings (or someone else) will continue to maintain it for 3-5 years
Aug 19 17:17:37 <vagrantc> if that's the 4.19 y'all were talking about
Aug 19 18:00:19 <rcn-ee[m]> vagrantc: are you making the journey down to San Diego this week for ELC?  I know Portland was your home base so it was easier last year..
Aug 19 18:00:53 <vagrantc> rcn-ee[m]: too many other commitments
Aug 19 18:01:12 <rcn-ee[m]> ah!
Aug 19 18:47:44 <veremitz> wow had I Blagged it, I coulda done openPOWER and ELC in two weeks?! dayum :/
Aug 19 18:48:06 <veremitz> if I coulda slept on my mate's couch .. I'da been sorted :D
Aug 19 18:48:37 <veremitz> #NextTime™
Aug 19 18:56:56 <zmatt> rcn-ee[m]: why's 4.19 desirable for RT ?
Aug 19 18:58:19 <rcn-ee[m]> mmc on bootup is dog slow with 4.14.x+RT..
Aug 19 18:58:27 <zmatt> o.O
Aug 19 18:59:16 <zmatt> that sounds like there's more going on than just the usual inefficiency of RT kernels due to more expensive locking
Aug 19 19:00:20 <zmatt> thinkfat: it seems EOL extensions are more rule than exception among LTS kernels... https://liktaanjeneus.nl/lts-kernel-eol-history.html
Aug 19 19:02:43 <rcn-ee[m]> i don't remember the full details (i moved on to v4.19.x+RT in my testing..) our users found v4.9.x-RT was fast, 4.14.x-RT was slow, and v4.19.x-RT was back to v4.9.x-RT numbers..
Aug 19 19:06:44 <zmatt> sounds like it wasn't actually mmc related at all
Aug 19 19:07:10 <zmatt> OP just assumed so because the "mounted filesystem" message was the first message after long delay
Aug 19 19:07:38 <zmatt> I guess noone tried using loglevel debug? :P
Aug 19 19:08:06 <veremitz> I have reports (partially substantiated) that 4.18/.19 have been really bad for hardware compatibility (possibly arm32 exempt) .. so I'm holding back
Aug 19 19:08:22 <veremitz> I've not directly had any major failures though myself
Aug 19 19:08:34 <zmatt> that sounds rather vague
Aug 19 19:08:55 <veremitz> it is in bare terms ;)
Aug 19 19:09:22 <veremitz> the problems, I believe, are focussed more on powerpc and aarch64 I believe
Aug 19 19:09:26 <veremitz> iirc
Aug 19 19:10:05 <veremitz> they may, too, have been fixed in the long patch-stream that LTS kernels seem to have
Aug 19 19:16:57 <rcn-ee[m]> i think some of it for 4.19, was the 'rush' to get in LTS...
Aug 19 19:17:31 <rcn-ee[m]> other then a few things, most of my builders are on 4.19.x-lts now..
Aug 19 19:17:55 <veremitz> good stuff
Aug 19 19:18:46 <zmatt> ah 4.19 had the blk-mq corruption thing
Aug 19 19:34:03 <thinkfat> zmatt: interesting page ;)
Aug 19 19:34:17 <zmatt> I just quickly made it because I was curious
Aug 19 19:45:21 <thinkfat> zmatt: I'm assuming that people would be jumping onto 5.4 rather than 4.19. Also, looking at various roadmaps e.g. from NXP, I see not much of 4.19 but rather 4.14.x until 2020, which would be the projected EOL for 4.19
Aug 19 19:45:39 <thinkfat> zmatt: haven't seen a roadmap from TI, though
Aug 19 19:46:28 <thinkfat> vagrantc: I'm right now betting on debian regarding the lifetime of the 4.19 kernel, yes
Aug 19 19:50:08 <rcn-ee[m]> thinkfat: nxp only seems to update once, then the next lts is only new silicon..
Aug 19 19:50:43 <zmatt> thinkfat: well, 4.4, 4.9, 4.14, 4.19 were all released in roughly 1-year intervals, they all had an initial EOL set to 2 years after release (and 5.4's planned EOL is again a year later, keeping with the pattern), and so far 4.4, 4.9, and 4.14 all got their EOL bumped by 4 years, around 6 months before their original EOL
Aug 19 19:52:23 <zmatt> it would be nice if the policy on EOL date was a bit clearer, but I guess it probably just depends on whether it matters enough and Greg or someone else wants to take on the job
Aug 19 19:54:34 <rcn-ee[m]> don't forget about the crazy 3.18.x, it went eol 2017-02-03, but Greg brought it back till about 3months ago.. (android phones..)
Aug 19 19:54:52 <thinkfat> the official "default" policy is quite clear, though: two years it is, and I think EOL extensions are "sponsored" by whoever needs the respective LTS version to be maintained longer
Aug 19 19:55:55 <thinkfat> Id bet Google sponsored the 3.18 resurrection ;)
Aug 19 19:56:05 <rcn-ee[m]> https://lwn.net/Articles/788689/
Aug 19 19:57:56 <zmatt> i.e. it's not "quite clear" :P  it doesn't help that the commit message just says something like "Bump 4.14 LTS lifetime up a bit" without indication of why...
Aug 19 20:00:22 <zmatt> there doesn't even seem to be a mailing list post about the fact that the EOL got bumped
Aug 19 20:01:56 <thinkfat> zmatt: yeah, hadn't there been talk about this here on the channel this morning, I'd not have bothered to look
Aug 19 20:03:29 <thinkfat> zmatt: and "a bit" is a serious understatement
Aug 19 20:03:39 <zmatt> lol yes
Aug 19 20:04:20 <thinkfat> I wonder how the ltsi initiative is doing. there's not much publicity from that camp
Aug 19 20:08:08 <zmatt> yeah I have no idea... the kernel release that's prominently on their front page is 10 months old, but then again their previous non-rc tag was 22 months ago, so I guess that's just their pacing
Aug 19 20:12:53 * thinkfat briefly contemplates soldering 90-odd LEDs and a tiny QFN to a freshly arrived PCB and decides to go for a beer instead
Aug 19 20:13:14 <zmatt> it's important to prioritize
Aug 19 20:13:24 <thinkfat> indeed. beer makes hands steady
**** ENDING LOGGING AT Tue Aug 20 03:01:37 2019