**** BEGIN LOGGING AT Fri Feb 21 02:59:57 2020 Feb 21 05:34:57 How to get started with beagleboard GSoC ?? Feb 21 05:42:53 jkridner[m]: ^ Feb 21 05:42:57 oh he left. Feb 21 05:43:00 f** that then Feb 21 10:19:04 jkridner[m]: there's two things desperately missing in the BBB SRM... Feb 21 10:20:01 jkridner[m]: one, a table of contents in the PDF. There is one at the beginning of the document, with hyperlinks even, but it's really tedious to navigate it. a PDF TOC would make life much easier Feb 21 10:20:40 jkridner[m]: two, a single table that lists all the pin conflicts between internal functions an extension headers. There is one such table in each of the peripheral sections but buy, is it hard to collect all the data Feb 21 10:37:27 zmatt: ^ :P~ Feb 21 10:37:50 yeah too few PDFs these days contain TOC :( Feb 21 10:38:40 you can indeed find the data in the P8 and P9 tabs of https://goo.gl/Jkcg0w but my color coding could use a legend Feb 21 10:58:28 indeed Feb 21 10:58:51 without a legend, it's just another way to visualize the pin header description in the SRM... Feb 21 11:00:01 the color at least serves to identify pins that belong together Feb 21 11:02:59 zmatt: I see what you're doing there ;) Feb 21 11:03:02 zmatt: thanks a lot Feb 21 11:03:12 :) Feb 21 11:08:24 zmatt is pinmux pro :P lol Feb 21 11:18:34 ah, good to know, all the analog inputs are not 3.3V tolerant. That will save some headache, definitely Feb 21 11:32:32 zmatt: I2C1 has pullups somewhere on the BBB, against 3V3B? Feb 21 11:34:32 no Feb 21 11:35:10 well, internal pull-ups, but those just keep the pins from floating, they're not strong enough for i2c Feb 21 11:44:38 that's fine, I just don't want to damage the I2C when I pull them to a 3.3V rails that is generated on the cape. Feb 21 11:45:11 you should never pull them above the 3.3V supply from the beaglebone Feb 21 11:46:16 using your own 3.3V supply for logic that interfaces with the beaglebone requires very careful analysis to avoid damaging the AM335x. If at all possible, use the 3.3V supply from the beaglebone Feb 21 11:48:39 but that's also a separate regulator (3V3B) Feb 21 11:49:25 which is enabled by the AM335x 3.3V rail (and despite this it is in fact already the cause of known problems) Feb 21 12:24:00 thinkfat_: okay, I think the P9/P8 tabs are significantly improved Feb 21 12:39:19 okay I should stop tweaking it. it's Good Enough™ for now Feb 21 12:47:14 (he says as he continues tweaking) Feb 21 12:48:50 well, I'll put at least a footprint for a 0R between the 3V3B rail and the cape's VDD Feb 21 12:49:13 then I can see if that rail can support the cape and if not, I can still populate the regulator Feb 21 12:50:02 you're using sys_5v (P9.07/08) to supply the regulator? Feb 21 12:56:04 if you want to keep the option to use your own regulator open, at least try to ensure you're not driving any beaglebone pins strongly high unless you know it is properly powered. for example, make sure any cape outputs to the bbb are low or high-Z unless some enable-signal from the BBB is high (gated using a gpio with pull-down, or perhaps the reset pin. do not use the 3.3V supply as enable-signal) Feb 21 12:57:12 or at the very very minimum insert a substantial series resistor, but that might not adequately protect the BBB in the long run, and it can adversely affect the integrity of high-speed signals Feb 21 12:58:16 zmatt: I'm gating the cap supply through SYS_RESETN Feb 21 12:58:25 s/cap/cape/ Feb 21 12:59:04 zmatt: I believe we discussed this some time ago, SYS_RESETN seemed to be the best option Feb 21 12:59:39 gpio is the best option, sys_resetn is probably okayish Feb 21 13:00:50 zmatt: and I think I remember that the cape regulator was the only option, because I have consumers on VDD_5V that must be powered in sync with the logic Feb 21 13:02:01 so, SYS_RESETN gates VDD_5V which then creates the cape VDD through an LDO Feb 21 13:03:26 so, the difference between gpio (active-high with external pull-down) and reset is that a gpio will go immediately high-impedance if the processor resets (including the start of power-down sequencing), while the big obnoxious capacitor on reset causes it to rise and fall rather slowly Feb 21 13:04:31 gating the supply is definitely not as good as gating outputs, since supplies need to be backed with capacitance, which would have the opportunity to discharge via I/O Feb 21 13:05:02 but the best solution is rather situation-dependent, and pretty much needs to be analyzed for each signal that crosses power domains Feb 21 13:05:18 designing with multiple power domains is just kind of a headache :) Feb 21 13:06:43 yep Feb 21 13:07:15 the bane of the BBB Feb 21 13:07:46 no, the bane of connecting two independently-powered pieces of logic Feb 21 13:07:56 using independent power was your choice, not the BBB's Feb 21 13:08:33 and most digital logic is intolerant of voltages above their own supply Feb 21 13:08:45 (unless specifically designed to tolerate this) Feb 21 13:09:14 yep, STM32 MCUs usually have some pins that are at least 5V tolerant Feb 21 13:09:29 iirc those are only 5V tolerant while the MCU is powered Feb 21 13:11:29 yeah so their normal pins have an absolute maximum rating of 4V, while the 5V tolerant pins have an absolute maximum rating of VDD+4V Feb 21 13:16:38 and presumably the stm32 isn't manufactured on a 40nm process ;) Feb 21 13:39:43 looks like the only critical component I have is a DAC with its separate 5V and 3.3V supply. It's connected to I2C. Everything else can live from 3.3V Feb 21 13:41:02 there's a 74AC04 that will be fed with a 5V signal, though... Feb 21 13:43:17 ahm, there's also the GPS module that needs its own LDO and for that I need 5V... and it's of course connected to I/Os of the BBB... Feb 21 13:43:27 so, nope. Feb 21 14:17:29 that's really annoying Feb 21 14:59:09 put a schottky diode pair between the 3.3V supplies Feb 21 14:59:22 that way, they will follow eachother, while being decoupled Feb 21 14:59:50 a difference of ~0.3V between supplies is usually fine Feb 21 15:09:15 that solves absolutely nothing here Feb 21 15:09:46 it at least solves the power sequencing issue for the 3.3V rails Feb 21 15:09:54 no it doesn't Feb 21 15:09:54 unless i misunderstood the question Feb 21 15:09:57 you probably did Feb 21 15:10:32 ok, then just ignore what i said :-P Feb 21 15:10:53 the direction would have to be from cape to bbb, and backfeeding power into the 3.3v of the BBB is both forbidden and futile Feb 21 15:12:42 (futile because you're be backfeeding vdd_3v3b rather than vdd_3v3a, but even if that were a single supply then forcing 3.3v onto the 3.3v rail of the BBB outside its normal power sequencing is among the top five fun and easy ways to destroy an AM335x) Feb 21 15:15:37 right... i forgot that the AM335x is a bitch ^^' Feb 21 15:15:46 havent worked with it in a looooong time Feb 21 15:16:12 thinkfat_: best is to just clearly identify which parts of your design use which power supply (or supplies for chips that straddle multiple power domains) and for each line that crosses between them justify why it's not a problem Feb 21 15:16:19 KotH: that's really not AM335x specific Feb 21 15:16:48 zmatt: true... but it's one of the most difficult processors i ever worked with Feb 21 15:16:57 zmatt: the others had much lower requirements Feb 21 15:17:02 which other SoCs have you worked with? Feb 21 15:17:31 mostly uCs, but these do not really count, and the i.mx family Feb 21 15:20:09 I just browsed the i.MX53xD datasheet and its requirements look not the slighest bit more relaxed than those of the AM335x Feb 21 15:20:45 zmatt: but while you are here... you might be able to help me: i once found a diagram that showed vibration/acceleration spectra for buildings, but i can't find anything anymore. you wouldnt know a good place to look at, do you? Feb 21 15:21:02 ehhh Feb 21 15:21:05 no, sorry Feb 21 15:21:08 damn! Feb 21 15:21:20 zmatt: btw: i have not worked with any SoC in a looong time Feb 21 15:21:29 zmatt: i've left industry for greener and more interesting pastures Feb 21 15:28:33 fpgas? your own asics? ;) Feb 21 15:28:59 asic production got ditched due to my own stupidity :) Feb 21 15:29:04 oof Feb 21 15:29:06 but i'm doing mostly math, these days Feb 21 15:29:16 yay, math \o/ Feb 21 15:29:46 and the last months have been filled with learning what the professors didn't tell us about fourier transform Feb 21 15:29:47 I'm also the math guy here, whenever one is needed Feb 21 15:29:50 ah Feb 21 15:30:28 a good understanding of the fourier transform can be very useful Feb 21 15:30:40 i thought i had a good understanding Feb 21 15:30:56 then i tried to do a fractional integration of white noise.... Feb 21 15:31:13 now i know, we engineers only get the ELI5 version of fourier transform Feb 21 15:31:14 then you probably didn't know enough about it. once you know enough, you'll at most think you have an adequate understanding of it Feb 21 15:31:25 haha Feb 21 15:32:31 if you are curious what you dont know about FT, get this book: https://www.springer.com/de/book/9781441918550 Feb 21 15:33:10 the first 100 pages are only preliminaries needed to define the FT... and that's a book intended for graduate students in math Feb 21 15:39:55 well, I also like non-classical fourier analysis ;) Feb 21 15:40:09 *g* Feb 21 15:40:39 there is a second book: https://link.springer.com/book/10.1007/978-1-4939-1230-8 Feb 21 15:41:49 fourier transform is ultimately just a special case of Pontryagin duality of locally compact abelian groups, and I also found it quite enlightening to understand cyclic codes (such as CRC error detection and BCH error-correction codes) in frequency domain (using DFT for finite fields) Feb 21 15:42:49 i understand some of the words you used ^^' Feb 21 15:42:59 :D Feb 21 15:45:16 but thinking of it... the vandermonde matrix popped up a couple of times when i had a look at BCH Feb 21 15:46:19 basically appending a CRC ensures that one specific spectral line is zero. since a signal that's localized in time (e.g. a single bit error or short burst of bit errors) will almost certainly be nonzero everywhere in frequency domain, adding such a thing to crc-protected data will inevitably invalidate the CRC Feb 21 15:47:18 interesting Feb 21 15:47:24 i've never thought of CRC this way Feb 21 15:47:31 neither did I, until I did Feb 21 15:49:19 the LFSR used to compute a CRC is basically just an IIR filter y[t+1] = c * y[t] + x[t] which computes a single coefficient of a DFT Feb 21 15:50:44 (where c is some specific root of unity in GF(2^n) where n is the size of the CRC in bits) Feb 21 15:52:56 jupp, it all makes sense Feb 21 15:54:23 funnily, earlier today, i just had a look at doing DFT using resonators... whcih of course were implemented as IIR :) Feb 21 15:55:36 note that doing a DFT naively like this is kinda bad for numerical stability... of course that's a non-existent issue when using finite fields, but it's definitely a concern when using floating-point Feb 21 15:55:49 yeah, i know Feb 21 15:56:00 ok :) Feb 21 15:56:45 the problem i'm "working" on is detecting the exact frequency and phase of a damped sine wave with an approximately known frequency Feb 21 15:57:15 thought i could maybe sidestep the problem by using a DFT kind of thing Feb 21 15:57:25 or chirp-z transform Feb 21 15:59:20 I've previously had a need to detect the frequency of a tone (sine + some harmonics) in the presence of noise... I use an FFT to find the approximate peak, and then iirc use some sort of gradient descent to find the frequency that has the best fit in L2 norm Feb 21 16:00:24 yeah, we currently use gradient descent, but i'm not happy with it Feb 21 16:01:25 i wanted something that i can implement easily in an fpga and doesn't need looping over some variable Feb 21 16:01:34 btw I also liked http://cr.yp.to/arith/tangentfft-20070919.pdf ... not specifically for its explanation of the Tangent FFT (which is only of marginal interest to me), but rather how it presents the regular and split-radix FFTs Feb 21 16:01:58 is the tone continuously present, i.e. are you trying to stay "locked on" ? Feb 21 16:02:15 nope, if it were, i'd use a pll like approach Feb 21 16:04:12 hmm, sounds like it might be tough to avoid iterative algorithms yet maintain good performance Feb 21 16:05:00 though, iirc my code typically required only a handful of iterations, and each iteration should be reasonably FPGA-friendly? not sure, haven't really thought about the problem in such a way Feb 21 16:06:05 a prof from ETH told me to use a state-space approach, not unlike a kalman filter ... which should work without iteration, but his explanation didnt make sense, and the paper he gave me for reference, made even less sense Feb 21 16:06:19 lol Feb 21 16:06:57 i'll probably return to that paper once i understand things a bit better :) Feb 21 16:50:17 hi everyone i have problem with BBB i need to move a Project from debian 6 to debian 9.5 we use node js and we need upgrade this to node js > 8.6 but after upgrade debian 9.5 all go fine but when i install nodejs 10 i lost the cloud9 ide Feb 21 16:51:07 can somebody help me? Feb 21 16:55:19 rguaman: that doesn't sound surprising Feb 21 16:55:38 updating nodejs across major versions typically breaks things Feb 21 16:56:07 also, if you're upgrading anyway (hence breaking stuff) I'd suggest upgrading straight to 12 (the current LTS release) Feb 21 16:57:48 as for cloud9... perhaps if you're very lucky a simple "npm rebuild" in the appropriate directory will fix things, but there's a decent chance that some packages would need to be upgraded, which itself may break other stuff Feb 21 17:00:39 cloud9 itself is an unmaintained dead project I think Feb 21 17:01:50 so it may not work at all with node versions after 8 Feb 21 17:14:18 ok can you suggest to me a replace cloud9 Feb 21 17:14:49 ehm, use an IDE or text editor of your choice? dunno, I've never used cloud9 Feb 21 17:20:08 I personally just ssh to the beaglebone use vim and a makefile, one of my coworkers uses vscode (which can edit stuff via ssh or something I think), another coworker uses Atom and just manually transfers files Feb 21 19:51:41 bah, screw it. PCBs launched. Feb 21 20:29:11 Help friends! I have Debian installed on an SD (the not-for-flashing version). I'm trying to figure out how to configure my BBB (Rev. 2) to always boot from the SD. It boots fine when I hold down the user button but when I don't, I get only two LEDs and no display. Feb 21 20:34:50 I have tried the following: 1. Booting into SD then renaming `/bbb-uEnv.txt` to `/uEnv.txt`, 2. Disabling the "bootable" flag on the eMMC partition. My next idea is to change the disk uuid referenced in `/boot/uEnv.txt` on the eMMC. Feb 21 20:35:56 Although I can't confirm, I suspect my problem came from manually expanding the file system on the SD card rather than running the script. Feb 21 20:39:37 I believe their is a way to power on force it to boot from the SD card. You may wish to look at the documentation regarding booting for the AM335X for details. I believe IO can be held during reset to strap configure the AM335x too boot how you wish. I think that's all holding that button does (set a boot strap input) Feb 21 20:54:48 > believe their is a way to power on force it to boot from the SD card Feb 21 20:55:56 I'm able to get it to boot from SD by holding the user button. I need it to always do this, without me holding down the user button. This is necessary because I won't have physical access to the board after it's deployed. Feb 21 20:56:44 Or is that what you meant by "power on force it to boot from the SD card" ? Feb 21 20:56:50 I repeat all that does is force the IO line used during power on boot strap, you can set it up to do that automatically without pressing the button. Feb 21 20:57:40 It does take reading the documentation I think it's in the data sheet and not the TRM guide. A difference between 300 vs 5600 pages Feb 21 20:59:13 I also suggest looking at the schematics which are available on beagleboard.org (last I checked I can't guarantee that) you can reference the data sheet from beagleboard.org but it's best to go to TI's website as in case you need the TRM. Feb 21 21:03:30 that might get you going at the very least. Remember to consider if you need the USER button after boot (IE strapping it down temporarily might be a good idea) Feb 21 21:06:43 Thanks GenTooMan. I'm looking at the data sheet ( https://cdn.sparkfun.com/datasheets/Dev/Beagle/AM3359.pdf ) . This does give some insight as the hardware's role in the boot process but I assumed there would be a much simpler solution using software/boot configuration . I definitely don't want to modify the hardware just to change the boot Feb 21 21:06:43 sequence. Feb 21 21:10:40 I think their is another way. zmatt if he were around would likely remember it faster than I could hunt it down. Feb 21 21:12:33 however you likely just need to add hardware not modify it to do what you want. Feb 21 21:16:09 hmm? Feb 21 21:18:38 Rando52481: bootrom defaults to loading the bootloader (u-boot) from eMMC over loading it from SD, and it sounds like maybe your eMMC contains some ancient bootloader that is unable to properly boot the system on your SD card Feb 21 21:19:16 Rando52481: the simple solutions are wiping eMMC or making sure bootrom can't find a bootloader on it Feb 21 21:22:21 Rando52481: how to do the latter depends on whether eMMC uses a boot partition or not... on really ancient systems eMMC had two partitions, the first being a FAT boot partition. in that case, clearing its "bootable" flag (in the partition table) or deleting/moving/renaming the "MLO" file on it should do the trick Feb 21 21:23:03 if eMMC has only a single partition, then wipe sector 256 of it: sudo dd if=/dev/zero of=/dev/mmcblk0 seek=256 count=1 Feb 21 21:23:36 of course if the eMMC contents is ancient, then unless you have a particular reason to preserve its contents I suggest simply wiping it entirely with sudo blkdiscard /dev/mmcblk1 Feb 21 21:26:12 Thanks zmatt! There are 2 partitions associated with the eMMC. `/dev/mmcblk1p1` and `/dev/mmcblk1boot1` . Feb 21 21:26:28 Rando52481: note that reflashing eMMC and booting from that is generally recommended over booting from sd card. eMMC is typically faster than sd card (especially for reading) and more reliable than consumer sd cards Feb 21 21:26:32 Rando52481: no Feb 21 21:27:09 Rando52481: eMMC always has /dev/mmcblk1boot0, /dev/mmcblk1boot1, and /dev/mmcblk1rpmb ... but these are not normal partitions should be ignored Feb 21 21:27:51 if eMMC uses a FAT boot partition you'll see /dev/mmcblk1p1 and /dev/mmcblk1p2 Feb 21 21:29:13 Ah yes. You're right about boot0 and boo1 . I do not however have ` /dev/mmcblk1rpmb` Feb 21 21:29:35 Ah yes. You're right about boot0 and boo1 . I do not however have `/dev/mmcblk1rpmb` Feb 21 21:29:44 Whoops, sorry for the double post. I'm on a web client. Feb 21 21:30:39 what image version did you install to sd card? Feb 21 21:32:01 (cat /etc/dogtag or the name of the file you flashed to sd card) Feb 21 21:34:37 I have the board disconnected so I can't check with certainty but I'm 98% sure that it's bone-debian-9.9-iot-armhf-2019-08-4gb.img Feb 21 21:36:31 hmm, maybe it's an eMMC version thing Feb 21 21:36:53 anyway, like I said you can ignore those, including their nonexistence ;) Feb 21 21:37:13 I'm plugging it back in now to verify Feb 21 21:38:17 regardless, like I said: unless you have a good reason to preserve the eMMC contents, I suggest either flashing to eMMC (to boot from that) or erasing eMMC if you're intent on booting from sd card Feb 21 21:43:43 Yep, it's 2019-08-03. Feb 21 21:45:48 Okay then. I don't need the eMMC contents so I'll resolve this with `sudo blkdiscard /dev/mmcblk1` . Thanks again zmatt GenTooMan ! Feb 21 21:47:00 note that to verify it helped you'll need to power-cycle, rebooting does not suffice (since the S2 button is only sampled at power-up and not rechecked at reboot) Feb 21 21:48:57 ...the moment of truth Feb 21 21:49:19 It worked!!! Feb 21 21:50:57 yay :) Feb 21 22:03:23 and their was much rejoicing. Feb 22 02:33:51 I found a way to get back into Google Groups! Feb 22 02:33:55 sign up! Feb 22 02:33:59 It kicked me or something. Feb 22 02:34:36 Fri. fun day? **** ENDING LOGGING AT Sat Feb 22 02:59:57 2020