**** BEGIN LOGGING AT Tue Mar 21 03:00:02 2017 Mar 21 03:25:08 zmatt: Yeah, that's what I was assuming I'd have to use. TI seems to say that reads to main memory are ~50-100 cycles, which is fine. Mar 21 03:25:45 but actually setting up such a memory region is what I don't know how to do Mar 21 03:30:05 (also does the PRU have some sort of cycle counter? I suspect I'm gonna end up with _large_ tracts of nop loops between reads, but if it drifts too far in aggregate, that might be a problem Mar 21 03:30:29 not sure if it actually will be, I haven't exactly characterized how sloppy my timings can get before it stops working) Mar 21 03:30:30 it has a cycle counter yes, and also a stall coutner Mar 21 03:30:35 ok sweet Mar 21 03:30:42 also local timers Mar 21 03:31:57 and I know for uio-pruss you can reserve some DDR3 memory in DT Mar 21 03:32:22 in general there are probably ways to rudely reserve some fixed memory in DT Mar 21 03:32:54 DT? Mar 21 03:32:56 I personally often reserve some of the on-chip SRAM for DMA purposes Mar 21 03:32:57 devicetree? Mar 21 03:32:57 device tree Mar 21 03:33:25 seems like with remoteproc a lot of the stuff that was done with the devicetree in UIO has moved into the firmware resource table Mar 21 03:34:07 remoteproc is one of those rare topics I know absolutely nothing about :) Mar 21 03:35:11 to me remoteproc seems like it adds overhead and restrictions without bringing any benefit Mar 21 03:35:46 but I may be wrong, since I don't really know anything about it Mar 21 03:37:08 the main benefit to me is that apparently UIO is depricated and is going to disappear at some point, and if you use remoteproc you get the PRU C compiler Mar 21 03:37:31 also remoteproc is apparently generalizable to other SoC Mar 21 03:37:32 s Mar 21 03:38:08 uio isn't going to disappear, and even the generic uio_pdrv_genirq (which has been around since the dawn of time) suffices for most purposes Mar 21 03:38:25 It's what I'm using cause I know jack about either way, and I don't want to put effort into learning a way that has "DON'T DO IT THIS WAY IT'S OLD SEE THIS OTHER WAY" on top of all of TI's docs Mar 21 03:39:06 yeah, TI saying that is having about this much impact: https://xkcd.com/1726/ Mar 21 03:39:07 and I'm somewhat of an intellectual masochist Mar 21 03:39:15 hahahaha Mar 21 03:39:31 just like kernel people saying you shouldn't use gpio from userspace Mar 21 03:40:24 the PRU C compiler is a mixed bag.. on one hand I understand some people like it, and their needs from PRUSS are simple enough that it works for the purpose Mar 21 03:41:12 I mean, the docs on it are terrible. The actual process of building/installing/etc firmware for it has so far been not that hard once I figured out that 99% of the things they reference aren't in the right place Mar 21 03:41:23 on the other hand the PRU instruction set is designed for hand-coding, and is quite poorly matched to the needs of C Mar 21 03:41:34 and pasm is quite a fancy assembler Mar 21 03:42:03 and PRU is often used for purposes where getting cycle-accurate timing is important, which you lose instantly when using the C compiler of course Mar 21 03:42:18 eh, really it's more the masochism and the desire to make the process suck less for anyone following in my footsteps Mar 21 03:42:20 either way, how you generate your program is separate from how you load it onto the PRU Mar 21 03:42:34 ya'd think Mar 21 03:42:38 except that it's not Mar 21 03:43:19 clpru has a bunch of wacky linker magic Mar 21 03:43:34 so the binaries it generates aren't AFAICT compatable with the UIO loading method Mar 21 03:44:02 (at least I couldn't do it, and I had a wizard who actually knows how linker scripts and objcopy work over my shoulder) Mar 21 03:44:40 if you xxd them there's some differences in the generated code too, even if my main() is just a big asm block Mar 21 03:45:07 I haven't looked at it much since I don't care about clpru, but it looked to me like it's basically the same as their other compilers (e.g. for DSPs), and simply outputs ELF Mar 21 03:45:11 I couldn't find a table of the instruction encoding to compare them semantically tho Mar 21 03:45:25 dispru Mar 21 03:45:34 didn't work on the clpru generated ones Mar 21 03:45:39 IIRC Mar 21 03:45:51 eh, dispru *only* works on clpru generated ones Mar 21 03:45:54 (this was like 3 weeks ago and I've basically flushed that all from cache so might be wrong on that one) Mar 21 03:46:02 okay maybe got it backwards Mar 21 03:46:02 well, unless you give the magic options to work on a raw binary probably Mar 21 03:46:26 you can get their toolchains to produce raw binaries as well Mar 21 03:46:38 alternatively doing ELF loading from userspace via uio shouldn't be too hard either Mar 21 03:46:39 huh. I guess I didn't see that option Mar 21 03:47:06 I definitey tried the latter, and the program didn't run Mar 21 03:47:15 then you did it wrong ;) Mar 21 03:47:19 vOv Mar 21 03:48:02 Either way, I know the differences betwee uio and remoteproc and I'm not particularly interested in doing it with uio Mar 21 03:48:04 with only 2048 instructions worth of iram per core, I personally wouldn't be in that much of a hurry to throw parts of it away as overhead Mar 21 03:48:09 in spite of the fact that that's a rather insane decision Mar 21 03:48:43 the clpru generated .text segments aren't bigger, they're different. Mar 21 03:49:20 well they're different because it generates ELF by default instead of a raw binary Mar 21 03:49:48 yeah, and in theory objdumping the .text segment of the ELF should be the raw binary. Mar 21 03:49:58 it can often be bigger because the compiler produces awful code output for many benign-looking code sequences Mar 21 03:50:41 in that case I wasn't actually using _any_ C expressions, just main () { asm: } Mar 21 03:52:25 AFAICT the only reason that remoteproc is such a b**** is becasue the docs are an anachronistic mess Mar 21 03:52:49 It's like if you did a git checkout of a compete docset and randomized the revision that each file comes from Mar 21 03:52:58 that said, I kind of enjoy blazing a trail through such things Mar 21 03:52:59 and int main() { return 0; } apparently uses 258 bytes of iram Mar 21 03:53:02 o.O Mar 21 03:53:14 what does return 0 from main even mean on a PRU? Mar 21 03:53:23 ask TI Mar 21 03:53:41 or check the surrounding framework code Mar 21 03:53:46 I think TI includes sources Mar 21 03:54:35 cause my ASM program used IIRC 12 bytes more with clpru than pasm even when I made it longer Mar 21 03:55:08 and that was (IIRC, again, this was awhile ago) 8 bytes at the beginning and 4 at the end, and otherwise it was _mostly_ the same Mar 21 03:55:25 I didn't try anything particularly sophisticated, it waited in a busy loop for a host interrupt and then sent one back Mar 21 03:55:26 ah wait maybe this prog isn't quite minimal, even though it includes no other code from me in the final link Mar 21 03:56:44 heh Mar 21 04:03:01 https://gist.github.com/mvduin/656a1f85f20a0f0be59814595f4044e0 Mar 21 04:04:25 in principle loading an ELF is really simple since you can ignore everything but the program headers Mar 21 04:05:43 to answer your question, the return value from main is evidently ignored Mar 21 04:06:23 though you can fish it out of the core after the program has exited of course Mar 21 04:06:27 oh bizarre, there's a bunch of extra crap in the .out file Mar 21 04:06:43 a better question is, why the fuck do they end in a deadloop instead of invoking HALT ? Mar 21 04:06:50 I was dumping directly from the .obj, whcih has an 8 byte text segment, which is closer to what I expected Mar 21 04:07:04 yes the .obj just contains the return 0 Mar 21 04:07:20 which is 2 instructions Mar 21 04:07:48 but as the word "return" indicates, main needs to be called from something Mar 21 04:08:33 another excellent question: why the hell is it loaded to offset 0x4 ? Mar 21 04:09:48 O_o Mar 21 04:10:50 yeah I kind of assumed that return from main wouldn't do anything Mar 21 04:11:28 or would be equivalent to __halt() Mar 21 04:18:24 https://gist.github.com/mvduin/db10c09436f21f3e72e25e3f26a91e32 some of these are hilariously bad Mar 21 04:18:53 hahahahaha wow Mar 21 04:18:56 (scroll down for C source) Mar 21 04:19:53 _Z3lt3s == lt3(unsigned short) is funny Mar 21 04:20:07 this is at maximum optimization level Mar 21 04:20:23 -O3 or -Os? Mar 21 04:20:32 (does clpru even have s?) Mar 21 04:20:32 this isn't gcc Mar 21 04:20:40 yes but it works differently Mar 21 04:20:41 guess that means no Mar 21 04:20:49 it has similarly shaped arguments though Mar 21 04:21:18 ehm, almost no argument is remotely similar to gcc Mar 21 04:21:33 -O looks like it, but isn't Mar 21 04:21:35 -O is? IDFK I've been using the Makefiles that come with it Mar 21 04:21:39 -O0 does not mean "do not optimize" Mar 21 04:22:30 it also has -i ala gcc Mar 21 04:22:45 -I you mean Mar 21 04:22:53 -i is library include path, which is -L for gcc Mar 21 04:23:24 some options I use are: -v3 --hardware_mac=on -O4 -mf -op3 Mar 21 04:23:31 --symdebug:none -on2 Mar 21 04:24:16 oof, I guess I don't remember GCC as well as I thought I did Mar 21 04:24:32 anyway, lt3(uint16_t) is the perfect example of mismatch between C and the pru instruction set, combined with utter stupidity of the compiler Mar 21 04:25:57 C has no arithmetic or comparison operators that accept anything smaller than an int, so the uint16_t gets implicitly converted to an int Mar 21 04:26:08 a *signed* int that is, not an unsigned one Mar 21 04:26:37 isn't that kind of the point of using 'int' rather than 'intxx_t'? Mar 21 04:27:10 int means "pick the size of number that my architecture is good at" Mar 21 04:27:29 except PRU is great at uint8_t, uint16_t, uint32_t Mar 21 04:27:34 and sucks as int32_t Mar 21 04:27:35 *at Mar 21 04:27:42 also known as int Mar 21 04:28:16 how is it good at uint32_t and not int32_t? Mar 21 04:28:28 does it not have signed int instructions? Mar 21 04:28:33 it has no signed comparisons, nor arithmetic shift right, nor a signed multiplier Mar 21 04:28:34 (I'm not familiar with its ISA at all) Mar 21 04:29:13 so then writing those functions in ASM would be just as ugly? Mar 21 04:29:23 if you actually want the semantics you're describing? Mar 21 04:29:45 IMO it's reasonable for a C compiler to generate crap code if you ask it to do something that the architecture is bad at Mar 21 04:29:46 if I wanted to test x < 3 for an uint16_t x, that would be 1 instruction Mar 21 04:29:59 and that's what I wrote in C Mar 21 04:30:05 aaaaaah Mar 21 04:30:33 I understand how it got there, which is by following the requirements of the standards, combined with utter stupidity of the compiler Mar 21 04:30:50 C tends to be very eager to convert stuff to int Mar 21 04:31:09 and specifically int, not uint Mar 21 04:32:16 so in this case it implicitly converted the uint16_t to an int Mar 21 04:32:31 that's... pretty dumb... Mar 21 04:32:45 immediately forgot the knowledge that the range is limited to non-negative numbers Mar 21 04:32:56 loaded 3 into register Mar 21 04:33:20 and performed a generic signed int comparison, which involves xoring both operands with 0x80000000 and then doing an unsigned comparison Mar 21 04:33:47 and for some reason it inserted another instruction which is completely inexplicable to me Mar 21 04:33:54 I wonder if it's less dumb if you make it (uint16_t)3? Mar 21 04:34:07 no Mar 21 04:34:14 C has no operator < (uint16_t, uint16_t) Mar 21 04:34:50 it has operator < (int, int) and operator < (unsigned, unsigned) and likewise for *larger* integer sizes Mar 21 04:35:03 and will upgrade smaller types to int in preference to unsigned int Mar 21 04:35:43 all this wouldn't matter if the compiler were smart enough to track the actual range of the operands Mar 21 04:37:35 uhh... waait what? Mar 21 04:37:42 is this code output even correct... Mar 21 04:38:25 ah wait this is for int16_t, not uint16_t, never mind Mar 21 04:38:36 I'm not that good at demangling C++ symbols in my head :P Mar 21 04:39:24 that means I'd need 2 or 3 instructions in assembly I guess Mar 21 04:40:15 oh C++ Mar 21 04:40:17 okay, the uint16_t version is not quite as bad, so I take back my statement about the compiler doing no range analysis, it does seem to be doing some Mar 21 04:40:19 that explains the overloading Mar 21 04:40:45 was a bit confused by how that compiled at all for a bit Mar 21 04:41:10 the mangled symbols weren't a giveaway? or the file suffix for that matter :P Mar 21 04:41:34 didn't pay attention to the suffix, and figured it might be some wacky thing clpru does, given that it's definitely not your usual C compiler Mar 21 04:41:51 and no, IDK crap about symbol mangling, figured that was just a thing it did Mar 21 04:42:01 I don't usually get this far down into toolchains Mar 21 04:42:17 no, a thing it does is write symbols with || around them for some reason, otherwise the assembler won't accept them Mar 21 04:42:26 the fact that I was sterting to get there is part of why I gave up on getting clpru to generate uio binaries Mar 21 04:43:36 like, I like to think I'm p aight at C, but I've only ever done it for x86_64, and in that domain, the compiler is generally trustworthy Mar 21 04:43:52 and when it turns out not to be, there's another guy in the office who knows this stuff :) Mar 21 04:44:09 another difference is that x86 and C are decently matched, and x86 assembly is hideous and not something you want to write if you can help it Mar 21 04:44:52 pru has some awesome instructions that I don't imagine a C compiler will be able to take advantage of Mar 21 04:46:16 I was expecting to be using asm for the timing-sensitive bits and chunks of C for the communicating-with-the-host bits and then nop loops that wait for "however many more microseconds it takes to get to " Mar 21 04:46:37 for microseconds it probably makes more sense to use a timer Mar 21 04:47:03 especially since any ddr3 access makes the cycle counter useless Mar 21 04:47:13 wait, it counts as one cycle? Mar 21 04:47:18 it ? Mar 21 04:47:22 ddr3 read Mar 21 04:47:25 like Mar 21 04:47:25 no Mar 21 04:47:37 oh right, eh Mar 21 04:47:37 I know Mar 21 04:47:38 hmm Mar 21 04:47:39 so I was thinking Mar 21 04:48:01 right you can use the cycle counter, you can't use a simply loop Mar 21 04:48:06 sorry, got those confused Mar 21 04:48:06 read cycle counter, do DDR read, read cycle counter again, subtract first from second, spin for the remainder Mar 21 04:48:11 i.e. you can't use instruction-counting Mar 21 04:48:16 no Mar 21 04:48:18 def not Mar 21 04:48:27 cause DDR reads are very loudly nondeterministic in time Mar 21 04:49:28 the cycle counter however stops when it hits 2^32-1 Mar 21 04:49:30 :) Mar 21 04:49:36 _stops_? Mar 21 04:49:39 or resets? Mar 21 04:49:40 stops Mar 21 04:49:46 it's meant to profile stalls Mar 21 04:49:51 can you reset it? Mar 21 04:50:01 hence both the cycle-counter and stall-counter halt once the cycle-counter would overflow Mar 21 04:50:04 yes you can Mar 21 04:50:08 okay that's even easier then Mar 21 04:50:13 reset, ddr read, read cycle counter Mar 21 04:50:40 if a ddr read takes 2^31 cycles, there's definitely something wrong lol Mar 21 04:50:56 I don't know if you need drift-free timing or not Mar 21 04:51:33 lol no overflow is not an issue with that approach :P Mar 21 04:51:40 I don't either, but knowing the people who make WS2812's that cost $3.50/meter ... whether or not I do is an entropy source. Mar 21 04:51:55 steppers definitely don't care Mar 21 04:52:04 the ws2812 does not care about drift-free timing Mar 21 04:52:36 not all "ws2812" chips are created equal. Apparently there's like 12 manufacturers that make things that are commonly sold as them Mar 21 04:52:43 yay china Mar 21 04:53:03 and I've definitely seen different brands that behave differently Mar 21 04:53:47 fortunately, I have a case of ones that match Mar 21 04:54:22 I mean, really, I could just go use somebody else's program to control them cause there's like 4 projects on github that I _know_ will do this, buuuut that wouldn't be very fun. Mar 21 04:55:01 I used eHRPWM Mar 21 04:55:17 setup DMA to change the duty cycle every period Mar 21 04:55:30 (yes I'm crazy) Mar 21 04:55:51 ha nice. Mar 21 04:55:57 oh in case you're wondering I did so from userspace Mar 21 04:57:32 the most ballin' way I've seen to control them is with an 800kHz SPI channel and a circuit made of a transistor, a resistor, and a capacitor. Mar 21 04:57:52 too much external circuit Mar 21 04:59:11 yeah, wasn't my project, and I can't find it now, but some people would rather solder than code vOv Mar 21 04:59:35 uhuh, or read the TRM to know what the am335x can do on its own Mar 21 04:59:50 the worst case of which would be the guy hooking up a 555 timer to GPIO on the beaglebone Mar 21 04:59:55 oh, thi wasn't beaglebone based Mar 21 05:00:01 I understood that Mar 21 05:00:09 or rather, I guessed that Mar 21 05:00:26 it may be a valid way to deal with the limitations of that microcontroller :) Mar 21 05:03:21 Alas, "valid" "best" and "easiest to find" are frequently very far apart Mar 21 05:04:01 before I learned about the BB I was doing this with a f*ing wiznet arduino shield. Those things _suck_ Mar 21 05:04:32 hello i want to know the root password for beaglebone black board Mar 21 05:04:50 which is compounded by the fact that the 'dweeno standard library is terribad an implements multi-byte read as a 4 byte SPI transaction for each byte Mar 21 05:04:54 i just bought it and when i execute sudo it is asking Mar 21 05:05:01 newbie_: there isn't one? Mar 21 05:05:23 try just 'su'? Mar 21 05:06:10 guess that worked? Mar 21 05:06:30 after su it asks for password Mar 21 05:06:45 if i just hit enter it says Authentication failure Mar 21 05:07:14 on the debian image the default user pw is 'temppwd', IDK what the shipping image is though. Mar 21 05:08:17 default account is debian/temppwd, root password is blank Mar 21 05:08:39 is that on the ancient angstrom that ships with it too? Mar 21 05:08:52 no idea, I don't do archeology Mar 21 05:09:22 yeeeaaaaaaaah, same. Mar 21 05:09:57 newbie_: cat /etc/dogtag Mar 21 05:25:41 I guess not... Mar 21 06:17:16 the level of suck of the tps65217 still amazes me.... like the status bit indicating "battery charging complete (battery full) or battery removed" Mar 21 06:17:27 it can't tell the difference... -.- Mar 21 06:25:43 I have Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l GNU/Linux Mar 21 06:25:59 Manual for Pimux operations? Mar 21 06:26:17 Trying to use BBBCSIO c# mono Mar 21 06:30:34 Apteryx_: config-pin -h Mar 21 06:32:43 zmatt: thanks Mar 21 06:42:07 hello how to change ip address of my beaglebone black board Mar 21 06:42:53 man ip Mar 21 06:43:24 specifically 'ip addr add ' Mar 21 06:44:15 i am connecting via usb interface to my pc (usb0 specifically) Mar 21 06:44:36 wanted to change the default ip of beagleboard as deafult is same in aal boards Mar 21 06:47:22 newbie_: edit /etc/network/interfaces - Backup image first! - man ip for more nfo Mar 21 07:00:15 gm Mar 21 07:00:38 ge Mar 21 07:09:41 gtz Mar 21 07:17:32 zmatt: do you know if the rcn ti-linux-kernel-dev/build_kernel.sh can be used to recreate a specific kernel from a debian image? Mar 21 07:26:43 I have no experience with building older tags... I don't see a good reason why it wouldn't work, but the readme refers to "yakbuild" if you want to do that (no experience with it) Mar 21 07:28:13 zmatt: easier, one just needs to modify version.sh and set it to the desired version Mar 21 07:28:50 hm, or not... Mar 21 07:39:54 lol no Mar 21 07:40:33 at the very least you need to check out the right tagged commit Mar 21 07:41:25 you may need to toss the KERNEL subdir to let it recreate it properly Mar 21 07:41:40 although iirc it usually figures that stuff out itself Mar 21 08:16:11 zmatt: yup, not so easy. Mar 21 08:16:25 probably easier to update the kernel on the board to the latest version Mar 21 10:22:43 zmatt: well, yakbuild it is Mar 21 10:30:23 zmatt: less sophisticated, but "just works" Mar 21 10:35:39 though there really should be a method to prevent shutdown of a hwmod without recompiling the kernel Mar 21 10:50:20 there is Mar 21 10:50:25 you can set a property on it in DT Mar 21 10:51:36 Hi, I tried to buy a beaglebone black but there was only beaglebone green available locally Mar 21 10:52:34 (I preffered the beaglebone black because it had a display port) Mar 21 10:53:00 Unfortunately I ended up with a beaglebone green from Seed Studios Mar 21 10:53:35 Now if I understand seedstudio's documentation correctly, there is not much differences between the two Mar 21 10:54:42 I also looked at upstream linux and in arch/arm/boot/dts/ the only differences between am335x-bonegreen.dts and am335x-boneblack.dts is the name Mar 21 10:55:01 uh, no Mar 21 10:55:08 that's definitely not the only difference Mar 21 10:55:09 In u-boot and barebox I don't find any beaglebone green Mar 21 10:55:25 u-boot definitely does have detection for it Mar 21 10:55:26 so does the software autodetects it automatically (there is an eeprom) Mar 21 10:55:29 ok Mar 21 10:55:39 based on eeprom yes Mar 21 10:55:49 thanks, so if I or my distro builds for beaglebone black it is supposed to work? Mar 21 10:56:17 if you have a correct dts file Mar 21 10:56:46 oh ok, I'm not up to date with the bootloader side, what do you mean exactly: Mar 21 10:57:10 1) the bootloader loads the linux bonegreen dts and passes it to linux? Mar 21 10:57:15 it's recommended to use one of the kernels from rcn, these contain patches/fixes/improvements for the beaglebone that haven't necessarily been integrated upstream yet Mar 21 10:57:17 2) the boneblack dts works Mar 21 10:57:35 the boneblack dts should not be used since it tries to enable hdmi Mar 21 10:57:37 3) you are refering to both kenrel and the dts used by u-boot somehow Mar 21 10:57:55 zmatt: you mean kenrel dts? Mar 21 10:57:58 the dts (or rather dtb) isn't used by u-boot, it's used by the kernel Mar 21 10:58:03 ok Mar 21 10:58:11 so they didn't make use of it yet Mar 21 10:58:13 u-boot loads it and passes it to the kernel Mar 21 10:58:13 in barebox they do Mar 21 10:58:15 ok Mar 21 10:58:23 thanks a lot Mar 21 10:58:41 I'll make u-boot load the right dtb Mar 21 10:59:06 you shouldn't have to "make" it do anything, it should already do this Mar 21 10:59:30 ok, I'll check that it does it right Mar 21 10:59:43 ahh, those patches aren't upstream yet it seems Mar 21 10:59:45 https://rcn-ee.com/repos/git/u-boot-patches/v2017.03/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch Mar 21 11:00:13 (The developers are not ARM experts in the distro I use, and it indeed loads boneblack dtb Mar 21 11:00:16 ) Mar 21 11:01:09 The real issue I have is related to the ethernet PHY, but I want to make sure I have it setup correctly before trying to deal with that Mar 21 11:01:23 so use the u-boot from rcn, you can find them prebuilt at https://rcn-ee.com/repos/bootloader/am335x_boneblack/ Mar 21 11:01:39 I can compile u-boot Mar 21 11:01:56 is there a branch to use for the beagle? Mar 21 11:01:57 I was just pointing it out since it's easier Mar 21 11:02:03 yes, np Mar 21 11:02:58 just apply the patch above to the base version v2017.03 Mar 21 11:03:21 ok Mar 21 11:03:23 thanks Mar 21 11:04:01 for kernels pick a branch of https://github.com/RobertCNelson/bb-kernel or https://github.com/RobertCNelson/ti-linux-kernel-dev Mar 21 11:04:37 ./build_kernel.sh , weak config if you want when the menuconfig appear, then grab a coffee while the scripts do the rest ;) Mar 21 11:04:46 or even ./build_deb.sh to build a debian package Mar 21 11:05:16 s/weak/tweak/ Mar 21 11:05:47 zmatt: the Ethernet PHY seem to have some issues on 4.10.3 Mar 21 11:05:57 haven't noticed any yet Mar 21 11:06:06 oh wait I'm still using 4.9 actually, nm Mar 21 11:06:08 ok, so it's probably my bad setup (wrong dtb) Mar 21 11:06:26 unlikely in this case I think Mar 21 11:06:31 ok Mar 21 11:06:48 I don't know whether the phy bug workaround is in mainline or a local patch Mar 21 11:06:55 I hate debugging Ethernet PHY issues, I do not understand ethernet and MII standards enough... Mar 21 11:07:14 It starts fine Mar 21 11:07:21 then at some point I think it autonegs again Mar 21 11:07:36 that would already be odd Mar 21 11:07:38 and ends up not working at the lowest speed (some 10M configuration) Mar 21 11:08:04 I've seen that exactly once, though I think it was caused by an esd incident Mar 21 11:08:10 mii-tool also has few registers Mar 21 11:10:01 I would suggest trying an official image for a while, or at least rcn's u-boot and latest 4.9-bone kernel, to help identify whether it's due to hardware issues or due to your choice of bootloader and kernel Mar 21 11:10:12 (userspace probably doesn't matter) Mar 21 11:10:15 The capabilities are also odd: 1000baseT-HD supported... Mar 21 11:10:24 that's definitely nonsense Mar 21 11:10:24 I didn't check the PHY datasheet yet Mar 21 11:10:34 does it supports that kind of speeds? Mar 21 11:10:36 no Mar 21 11:10:44 100baseTX Mar 21 11:10:46 ok Mar 21 11:10:55 okay... Mar 21 11:11:58 looks like a problem in mii-tool, ethtool gives correct info Mar 21 11:12:07 zmatt: should I check if there is a PHY driver or if a specific PHY driver probes? Mar 21 11:12:23 because it could be that there is no proper driver and that the generic PHY driver is used instead Mar 21 11:12:37 which would also explain why there is so few registers in mii-tool Mar 21 11:13:18 there is only 1k of register space shown Mar 21 11:13:33 # readlink -e /sys/bus/mdio_bus/devices/4a101000.mdio\:00/driver Mar 21 11:13:33 /sys/bus/mdio_bus/drivers/SMSC LAN8710!LAN8720 Mar 21 11:14:13 Generic PHY... Mar 21 11:14:20 that is it Mar 21 11:14:35 probably means broken device tree data Mar 21 11:14:37 let me look in /proc/config.gz if they did it right Mar 21 11:15:59 CONFIG_SMSC_PHY=y Mar 21 11:16:02 ok Mar 21 11:21:32 If I take origin/master on linux I have: .name = "SMSC LAN8710/LAN8720", .phy_id_mask = 0xfffffff0, .phy_id = 0x0007c0f0, /* OUI=0x00800f, Model#=0x0f */ Mar 21 11:22:07 and cat phy_id in /sys/bus/mdio_bus/devices/4a101000.mdio:00 says 0x0007ffff Mar 21 11:22:21 I'll build u-boot and install MLO first Mar 21 11:36:29 let's try now Mar 21 11:42:32 zmatt: ? there is no debugss representation in the dts for the am335xx Mar 21 12:00:47 thinkfat: that's an oversight then Mar 21 12:04:27 this is interesting, it seems that if I power the bbb via both a wallcharger and usb, and then power off, then 1. it will power on again 2. the ethernet phy fails to come up properly Mar 21 12:07:01 zmatt: did you check if the hardware actually supports that? Mar 21 12:07:23 zmatt: at work somebody fried a Sabre-AI board doing exactly that Mar 21 12:07:42 thinkfat: lol, yes the tps65217 is supposed to support that Mar 21 12:08:00 although now that you mention it, iirc it's buggy when you do so with no battery installed Mar 21 12:08:13 (yet another tps65217 bug) Mar 21 12:08:19 TM Mar 21 12:16:08 zmatt: oh, wow Mar 21 12:16:21 zmatt: debugger connected breaks resume also on linux Mar 21 12:20:19 ahh :) Mar 21 12:21:21 zmatt: i suspect some ICE effect ;) Mar 21 12:21:22 so then the question becomes, which aspect of "debugger connected" exactly Mar 21 12:21:26 indeed Mar 21 12:22:06 what's the debug core control register value you're using right now during suspend? Mar 21 12:23:02 zmatt: 0x2000 Mar 21 12:23:25 zmatt: tap control is 0x2108 Mar 21 12:24:22 and value read back? Mar 21 12:25:19 ummm Mar 21 12:25:24 gute frage Mar 21 12:25:24 you could try clearing bit 13 in the core control register too btw Mar 21 12:25:55 zmatt: current scripts don't read back the value Mar 21 12:26:01 zmatt: but I can try to implement that Mar 21 12:26:21 see also my script which I linked a while ago Mar 21 12:26:50 yes, I have stored that somewhere Mar 21 12:26:51 not reading back is not really polite anyway, in theory you're supposed to poll some changes for acknowledge :P Mar 21 12:26:54 zmatt: oh, wow Mar 21 12:27:12 zmatt: I reconnected to the target with bit13 cleared and it immediately woke up Mar 21 12:27:23 wtf? Mar 21 12:27:57 does openocd maybe set a vector catch or whatever? Mar 21 12:28:19 no, not imeplemented yet on cortex_a target Mar 21 12:28:31 hmm Mar 21 12:28:33 implicitly for semihosting, but that is not enabled Mar 21 12:28:55 I'm now even more curious what the core register reads back when it's "stuck" Mar 21 12:29:35 ok, but before I satisfy your curiosity, I'll have to have to check where my bored little son went Mar 21 12:29:43 the little mischief is up to something! Mar 21 12:29:45 heh, ok Mar 21 12:33:06 actually he wasn't, he went to bed Mar 21 12:33:16 for 5 full minutes Mar 21 12:33:21 ! Mar 21 12:34:05