**** BEGIN LOGGING AT Mon Jan 16 03:00:01 2017 Jan 16 08:28:06 zmatt: hello. FYI what I needed to do was to echo 'spi' in /sys/devices/platform/ocp/ocp\:P9_{28,29,30,31}_pinmux/state and leave universal cape, then "flashrom -p linux_spi:dev=/dev/spidev2.0 -r bla.img" worked (for log readers it's BBW, not BBB) Jan 16 08:28:57 I thought the dts took care of pinmuxing for me so there's still a lot to understand about that, but hey, it works now Jan 16 14:04:03 Using a BBW I'm dumping data from a 2MB 50MHz SPI flash memory still on its original circuit (I simply soldered wires from its pins) which staus offline during flash read. I dump it using flashrom. Problem is, I never read the same exact image twice. There are blocks (sometimes a few bytes, sometimes up to ~240) that change (sometimes all FF, sometimes seems random). I tried lower reading speeds such as 128 Jan 16 14:04:09 kHz to no avail. Jan 16 14:06:56 there's about 15-20cm of wires per port, but they're all the same length Jan 16 14:27:09 gquere: decrease the sepeed to <1MHz Jan 16 14:27:33 gquere: 20cm is waaaaaay too long for 50MHz Jan 16 14:28:00 KotH: I tried 128KHz (which takes about a minute to dump), same result Jan 16 14:28:16 then there is something else interfering with your interface Jan 16 14:28:27 check on a scope how the signals look like Jan 16 14:28:56 and ensure that _NOTHING_ on the board is accessing the signals going to the spi flash Jan 16 14:29:53 no scope available sadly (wouldn't know what to do with it anyways) Jan 16 14:30:49 yeah that's another of my concerns, even though the whole circuit is not powered, maybe the 3.3V to the SPI flash powers something on that interferes with my readings Jan 16 14:31:44 lol Jan 16 14:31:56 if you power the spi flash you power the rest of the circuit too Jan 16 14:32:05 if you dont power the spi flash, then you get random data anyways Jan 16 14:32:26 I power part of the circuit I suspectyes Jan 16 15:38:08 welp, I converted my BBW to a BBB ... Jan 16 15:47:14 um, lol? Jan 16 15:48:58 it kinda burned Jan 16 15:49:08 as well as the front USB of my computer Jan 16 15:49:22 congrats. Jan 16 15:49:23 and a fuse somewhere down the eletric line Jan 16 15:49:26 :D Jan 16 16:16:55 gquere: how did you manage to redirect so much energy into the wrong place to blow a mains fuse? Jan 16 16:43:21 thinkfat: not a fuse, a breaker, I forgot the word earlier Jan 16 16:43:45 guess I should buy a couple BBB then Jan 16 16:47:35 lol, wow Jan 16 16:49:13 I forgot to remove the BB's 3.3V output from the circuit when I powered it Jan 16 16:49:56 connecting it was a bad idea in the first place Jan 16 16:50:06 can't be used as an input? Jan 16 16:50:21 to power other circuitry i mean Jan 16 16:50:53 -facepalm Jan 16 16:52:35 you mean whether the bbb can power external stuff? sure if it's not too power hungry, though for some reason your description of it ("spi flash memory still on its original circuit") sounds ominous to me :P Jan 16 16:53:54 and obviously connecting another supply to the same circuit would have been a very bad idea, although I'm still curious how you managed to accomplish the destruction you described Jan 16 16:54:49 sounds kinda like you connected BBB ground to something capable of delivering a lot of current Jan 16 16:55:32 (instead of to ground) Jan 16 16:56:07 but the info you've given is insufficient for any firm statement Jan 16 16:57:05 mmhhh Jan 16 16:58:18 well, the flash memory had to have been correctly connected, since I read successfully from it Jan 16 16:58:47 though unreliably Jan 16 16:58:49 only thing that changed is that powerwise the BB's 3.3V output became an input Jan 16 16:59:17 that is never valid Jan 16 16:59:20 yeah, but like ~1000 bad bytes per 2MB Jan 16 17:00:02 yes, sounding a bit like there were interfering transactions of some sort, making me rather suspicious of what exactly the rest of that circuit consisted of Jan 16 17:01:10 rather typical microprocessor i'm trying to hack Jan 16 17:02:26 powering that up sounds like an excellent way to get a drive conflict on the spi bus Jan 16 17:02:33 (also, how much does it draw?) Jan 16 17:05:32 the vdd_3v3b on the bbb (which is what's on the expansion headers) is rated at 500 mA, and also powers ethernet and eMMC (each drawing around 100 mA worst case iirc according to datasheets) and sd card (if any) Jan 16 17:08:50 yeah possibly a drive conflict, not sure they (flash + µC) are powered from the same 3.3V line Jan 16 17:08:57 i'll have to check that tomorrow Jan 16 17:12:43 they almost certainly are, or if not then you were introducing 3.3v in a weird location on that board, which is generally also bad Jan 16 17:14:18 most ICs are not tolerant of any significant voltage on their I/Os when they're unpowered, so whenever possible it's preferred to power interconnected ICs from the same supply (there are exceptions to this rule of course) Jan 16 17:15:57 still doesn't explain how you fried the bbb so badly, let alone the upstream usb port Jan 16 17:16:25 I am trying to setup a bbb after some time of (I had the same problem last time) hence asking: I downloaded the bbb Debian 8.6 2016-11-06 4GB SD LXQT from http://beagleboard.org/latest-images , dd the thing and started bbb with the user button pressed Jan 16 17:16:58 afterbooting normally (I have only a serial) I became root and started the installer) Jan 16 17:18:12 das_: I assume you checked thoroughly that this supply on the microcontroller is indeed 3.3v and not, say, 5v ? Jan 16 17:18:47 http://pastebin.com/sJEmQKX0 (is the outout of the install) rsync: write failed on "/tmp/rootfs/usr/local/lib/node_modules/node-red-node-beaglebone/node_modules/octalbonescript/node_modules/verror/tests/tst.verror.js": No space left on device (28) Jan 16 17:19:18 any hint on having a working bbb setup? Jan 16 17:20:01 keesj: lines 43 and 45 of your log Jan 16 17:21:06 (quite stupid that the installer doesn't check this itself before installing... "Giving you time to check" is not a valid substitute imho) Jan 16 17:21:39 so.. I need to ... reformat (the installer doesn't?) Jan 16 17:22:14 you have an older beaglebone bone with 2GB of eMMC Jan 16 17:22:24 you downloaded a 4GB image Jan 16 17:22:34 might be :P also have a beaglebone white Jan 16 17:23:11 beaglebone black rev C has 4 GB, as do the flurry of derivatives Jan 16 17:23:23 black rev A/B has 2 GB, white has none Jan 16 17:25:25 so.. throw away or is there a smaller image (I want to play with the usb sniffer) Jan 16 17:25:55 boot from µSD or use a console image or such Jan 16 17:25:58 (thanks for helping BTW) Jan 16 17:26:19 right .. that is of course also an option.... Jan 16 17:26:48 there are IIRC "IoT" images Jan 16 17:27:04 which is regular image, but without all the x-server crapola Jan 16 17:27:10 iot should fit if you first use resize2fs on it Jan 16 17:27:23 since for reasons unclear to me it's still a 4GB image Jan 16 17:27:33 last time I checked Jan 16 17:28:03 booting from sd is fine (if I get it to automatically boot from there) Jan 16 17:28:03 there also used to be 2GB reduced-crap gui images, but they seem to have vanished Jan 16 17:28:49 just clear sector 256 of the eMMC Jan 16 17:29:10 or Jan 16 17:29:16 I will Jan 16 17:29:23 reformat the filesystem on the eMMC partition Jan 16 17:29:43 actually even that's not needed Jan 16 17:29:58 the installer did correctly install the bootloader Jan 16 17:30:08 which will prefer booting from sd over booting from eMMC Jan 16 17:30:11 so all is fine Jan 16 17:37:29 thanks I will try to cleanup the image later (e.g. stop lightdm and such) Jan 16 17:53:31 zmatt: didn't, but the flash is 3.3V for sure Jan 16 18:03:16 that's what I meant, the supply you connected to Jan 16 18:04:54 sorry i'm not getting it. flash is 3.3V, so the circuit had to be powering it 3.3V (didn't check physically, just read the datasheet), I don't see where the 5V comes from Jan 16 18:05:17 I was trying to figure out how you could have fried the bbb by this Jan 16 18:06:02 you think it would have tolerated 3.3V input ? Jan 16 18:07:04 on pins p9.3/4 Jan 16 18:07:13 I don't think connecting another 3.3v supply to the bbb's 3.3v supply (with common ground of course) while the bbb is powered on would fry it (though it still wouldn't be a good idea) Jan 16 18:07:29 ah Jan 16 18:07:38 it would be a bit indetermine which side would be powering which side, depends on the regulators Jan 16 18:07:39 then i don't know what happened Jan 16 18:07:45 *indeterminate Jan 16 23:23:12 heyo Jan 16 23:23:22 anyone here played around with the beaglebone green wireless? Jan 16 23:44:41 Hi, does anyone here understand the relationship between the GMAC_RFT_CLK (gmac clock domain) and other clock domains ? Jan 16 23:44:55 On AM572x sitara devices Jan 16 23:45:06 e.g. beaglebone x15 Jan 16 23:45:58 What im looking for is to understand if I can make a direct relationship between the PRUSS_IEP clock and the 1588 clock (GMAC_RFT_CLK) Jan 16 23:55:13 does the hardware (schematics) or system reference manual not describe how those clocks are derived or pre-scaled? Jan 16 23:55:34 the PRUSS clocks are pre-scaled from the master clock i think Jan 17 00:01:58 @kyranf: it does, but its a lot of information to process. I see that they both come from DPLL_GMAC Jan 17 00:02:19 and there are switches I can configure Jan 17 00:02:28 it's a complex beast Jan 17 00:02:39 yeah Jan 17 00:02:43 I send pity in your direction Jan 17 00:02:54 thank you, I guess Jan 17 00:02:58 i don't know how to help you myself Jan 17 00:03:08 thats ok, thank you though Jan 17 00:03:38 do you know which clock is being modified by ptp ? Jan 17 00:03:52 (its on the CPTS block) Jan 17 00:03:53 no Jan 17 00:03:57 i don't know Jan 17 00:03:59 ok Jan 17 01:07:16 davidcm: the hardware just does timestamping, it's up to the driver to do something useful with that Jan 17 01:10:31 kyranf: PRUSS itself is normally clocked at core pll m4 (same as L3 clock, normally 200 MHz), although it can be switched to use display pll m2 Jan 17 01:14:10 two more clocks go to pruss: the iep clock which is again the 200 MHz core m4 clock, and the uart clock which is peripheral pll m2 (192 MHz) Jan 17 01:16:07 iep can also be configured to run synchronous to the rest of pruss, which probably reduces latency hence is a good idea unless you specifically need pruss on disp-m2 and iep on core-m4 Jan 17 01:18:18 the cpts ref clock is core-m5 by default (250 MHz clock for ethernet) but can also be configured to use core-m4 instead Jan 17 01:19:10 ah wait sorry Jan 17 01:19:31 I overlooked that the question was about the am572x, my bad Jan 17 01:20:04 above stuff is all for the am335x Jan 17 01:22:17 you can try to see if http://www.ti.com/tool/CLOCKTREETOOL is useful... maybe it has improved since my last experience with it Jan 17 01:49:15 am572x doesn't seem that different actually, except that pruss, iep, and cpts all get their own divider on dpll_gmac **** ENDING LOGGING AT Tue Jan 17 03:00:02 2017