**** BEGIN LOGGING AT Wed Oct 21 02:59:59 2015 Oct 21 04:34:37 if i haven't said it before, I'll say it again - DTBs are asuch a waste of time Oct 21 06:24:00 anyone used bbblfs? Oct 21 06:27:06 or is vvu h/self about? Oct 21 06:34:44 AHA I have life. Oct 21 07:03:07 the underlying usb_flasher tool (turns BBB into MSC gadget) works, although it's a bit brittle Oct 21 07:03:19 the actual flashing scripts were broken last time I checked Oct 21 07:07:30 yes I've had to upload the image manually Oct 21 07:07:51 but otherwise, pretty nifty Oct 21 07:08:21 glad I hooked it to a power supply though... Oct 21 07:08:48 gets a bit power hungry at times Oct 21 07:09:07 although should mostly be within usb limits Oct 21 07:10:29 max current from emmc was something like 100 mA iirc from the datasheet Oct 21 07:12:28 (had to do a quick power budget estimation before replacing the 3v3b regulator with a wire connecting it to 3v3a) Oct 21 07:12:41 heh Oct 21 07:14:21 gotcha of the day - once again usb gadget/rndis .. still not quite tracked down which module is missing on my desktop kernel build :/ but it works here Oct 21 07:15:03 usb_flasher doesn't use the kernel driver, it uses libusb Oct 21 07:15:25 *but* I suspect it implicitly relies on the kernel rndis driver already having done initialization before it takes over Oct 21 07:15:26 yes .. but to 'see' the... erm. Oct 21 07:15:50 yea I think it still needs it for the enumeration Oct 21 07:15:59 no, not for enumeration Oct 21 07:16:12 I mean the actual RNDIS protocol stuff Oct 21 07:17:00 on another machine without Network Manager it doesn't work at all, probably because the lack of attempt of bringing the interface up Oct 21 07:17:11 which NM will do by default Oct 21 07:20:04 ah I see your point .. as long as the device enumerates on usb (which its 99.9% likely to do) then libusb will 'get' it .. I confess I didn't try that Oct 21 07:23:46 it will enumerate on usb, no prob, ... well, unless you're having musb trouble Oct 21 07:24:08 usb_flasher however does no RNDIS initialization, and iirc it does require some Oct 21 07:24:27 and like I said, it's rather... brittle Oct 21 07:24:37 look at the source code for fun :P Oct 21 07:25:33 it doesn't even inspect the packets it receives Oct 21 07:26:01 just: receive and discard packet, send bootp reply; receive and discard packet, send ARP reply; etc Oct 21 07:30:51 zmatt .. if you want comedy .. look at the TI eflash tool for the Luminary mcu's .. Oct 21 07:31:04 that's a REAL mess. Oct 21 07:32:00 much the same crude methodology with winsockets ;) Oct 21 07:32:13 I had to recode chunks to run AT ALL under linux Oct 21 07:32:45 heh Oct 21 07:32:49 memcpy#ing structures .. the lot .. :) Oct 21 07:34:01 I was still working on a little prog that can be run as MLO and serves the eMMC over ethernet in some fashion Oct 21 07:34:36 to serve as "rescue mode" (put it in SPI flash, use button to change boot order) Oct 21 07:35:00 in bare-metal I guess ... Oct 21 07:35:09 lwip ? Oct 21 07:35:40 I've already written an IPv6/UDP stack from scratch once, it's really easy Oct 21 07:36:05 especially if you never have to send unicasts other than replies Oct 21 07:39:13 you also avoid having to parse and discard most of the chatter on the network since IPv6 uses eth multicasts rather than broadcasts, so you can have the switch filter those out and you practically only get traffic that's actually intended for you Oct 21 07:41:50 no need for dhcp or link-local address detection... you *have* a link-local address (derived from MAC) and if you also have a global prefix you'll recognize that from the neighbour discovery packets ("ARP") from someone who's looking for you Oct 21 07:42:51 (but to avoid any spoofing vulnerabilities, don't remember that address but just use it for the reply packet(s)) Oct 21 07:43:14 hmm Oct 21 07:47:04 overall: just listen for and reply to neighbour discovery packets, and optionally send one announcement at link up, and you're ready to receive and reply to udp packets, as well as send link-local udp multicasts Oct 21 07:48:47 anything more than that and you'd have to start doing router solicitation, maintain neighbour and prefix tables, yada yada, too much effort ;) Oct 21 07:52:26 use udp multicast to locate it and connect to it Oct 21 07:52:44 for security I'll probably use public-key authentication and AES-GCM (yay for hardware crypto accelerators) Oct 21 07:55:57 lol Oct 21 07:56:06 right time to head to werk .. ugh.. bbl :p Oct 21 08:33:08 yeah, ditto :/ Oct 21 10:58:30 question on beaglebone black? It no longer sees SD card Oct 21 12:56:08 (try painting it fluorescent orange, for better visibility) Oct 21 13:30:35 jkridner: btw, do you think there's any way of convincing TI to open up on MReqDomain instead of reserving it for HS devices? with this many cores, debugging problems due to one core scribbling on the state of another core is going to be a nightmare to debug. using the firewalls for memory protection will help a lot, but to do so in case of DMA transfers requires assigning each core a different MReqDomain Oct 21 13:31:04 (since that's the "connid" used for EDMA memory protection and proxied by the transfer controllers) Oct 21 13:34:31 zmatt: just got to figure out the right way to ask.... not sure what concerns might be had by sharing the info. Oct 21 13:35:27 well the info isn't the only problem Oct 21 13:35:53 I know the control module address where supposedly the MReqDomain for initiators is configured Oct 21 13:36:06 but it ignores writes... or more likely, ignores non-secure writes Oct 21 13:36:21 *on the am335x Oct 21 13:36:23 sorry Oct 21 13:37:01 likewise on the dm814x I noticed that the SecSS cortex-m3 has a different MReqDomain by default (1 instead of 0) but again no way to reconfigure anything Oct 21 13:38:00 so loosening this up to GP devices would unfortunately involve more than an info-release, it means either making those registers writeable on GP devices or adding a ROM-call to modify them Oct 21 13:38:11 (the latter may be easier in practice) Oct 21 13:38:33 ah. well, that's tougher because it involves $$$ Oct 21 13:39:00 but it's annoying as hell that there's a perfectly good mechanism for setting up proper memory protection between different initiators Oct 21 13:39:05 and we can't use it Oct 21 13:39:20 and it's been like this since omap4 and netra Oct 21 13:40:01 but the number of initiators is getting really worryingly large now on vayu Oct 21 13:41:03 Well, if you get it posted on the beagleboard-x15 list and possibly e2e.ti.com, I can take it to the team to discuss if it can be exposed. Oct 21 13:41:57 I understand the basic need. Oct 21 13:45:36 it took me a while to figure out what this stuff was and why it was needed... but while the EDMA chapter describes it as proxying the initiator identity, it can't actually do that: while the initiator identity is mere metadata on TI's own interconnect tech (CBA/VBUS/TeraNet), the Arteris FlexNOC based L3 interconns are stateless packet-switched networks and need the sender's ID as destination for reply packe Oct 21 13:45:42 ts Oct 21 13:46:17 ok, I'll see about doing a write-up of what MReqDomain is and why we need it Oct 21 13:50:37 for the E2E copy, have a suggested forum? Oct 21 13:58:32 and I get that it may be too late to see this fixed in the am57xx, if we don't speak up it may remain buried in the "secure stuff" heap forever Oct 21 13:58:46 zmatt: not sure what forums are there, but it should be Sitara-related. Oct 21 13:59:33 zmatt: exactly.... gotta make the request and get people to understand the issue. I appreciate you spending a little time to try to make the situation better for everyone. Oct 21 14:00:23 yeah I've been meaning to speak up on this sooner, but didn't know how... just posting it in E2E seemed pointless since they're very high-volume with support questions and normally won't be read by anyone with significant influence within TI Oct 21 14:00:47 yeah, but it gives me something to point to... Oct 21 14:01:05 sometimes it helps, sometimes escalating isn't very straight-forward. Oct 21 14:02:41 yeah, it's frustrating to not be able to make genuine (and in this case probably low-effort) suggestions for improvement Oct 21 14:02:54 but, without the request coming from outside, it is more difficult. Oct 21 14:03:12 I don't suppose I get free clue-points for the number of times I've corrected TI support people on E2E when they were wrong? ;-) Oct 21 14:03:12 well, you are doing so. Oct 21 14:03:23 :-D Oct 21 14:03:39 some of them must hate me Oct 21 14:03:48 How do I do ? Oct 21 14:03:56 I'm afraid that's not possible Oct 21 14:04:15 sure it is, you configure that in undocumented register at
, and here's its bit allocation Oct 21 14:04:35 undocumented? call the FBI! Oct 21 14:06:12 they actually documented the register in the am572x Oct 21 14:06:23 but on e.g. the am335x or dm81xx Oct 21 14:06:32 *but not Oct 21 14:06:37 zmatt, u-boot/i2c1, do you have the e2e bug link by chance? u-boot window is open... Oct 21 14:07:16 rcn-ee: ehh, you mean the post about the guy with problems ultimately traced to that bogus pinmux? Oct 21 14:07:23 zmatt, yeah! Oct 21 14:07:27 would need to think a bit on how to locate that thread again... Oct 21 14:07:47 zmatt, ah.. nevermind then.. just about to hit git-send.. Oct 21 14:07:51 hmm, I haven't been *that* active on E2E lately Oct 21 14:07:59 maybe it's easy enough to locate in my history Oct 21 14:09:00 jkridner: maybe in my last x15 post I should have added "but I'm quite good at peeking and poking" ;-) Oct 21 14:10:17 zmatt, reminds me, we didn't have the xds100v2 in stock, it's ti's stock.. so no x15 jtag for you just yet. ;) Oct 21 14:12:30 https://e2e.ti.com/support/arm/sitara_arm/f/791/p/313894/1387696 Oct 21 14:17:06 Awesome, thanks zmatt ! Oct 21 14:17:14 jkridner: it's funny, I also strongly suspect the AM572x is actually capable of having 8 GB of memory (on a single rank)... I don't know where the notion came from that EMIF could only handle 2 GB per rank Oct 21 14:17:44 probably because of DMM's 2 GB restriction Oct 21 14:18:23 (although it can actually map anywhere within the 4 GB ram space of an EMIF) Oct 21 14:19:59 not relevant for the x15 though, not even for nutcases who'd want to try to perform a post-production RAM upgrade ;-) since you'd need eight x8 devices instead of four x16 Oct 21 14:30:06 rcn-ee: btw, re: uio. I don't even think the adc example works as overlay, since it changes the "compatible" of an existing node that's already enabled Oct 21 14:30:47 I don't think changing the compatible-property via an overlay would convince the kernel to unload the adc/tsc driver and hook it up to uio instead, would it? Oct 21 14:30:50 okay.. .the udev rules are still safe to enable by default.. Oct 21 14:30:52 yes Oct 21 14:31:32 ditto the modprobe rule, which is needed for the uio_pdrv_genirq to be usable at all Oct 21 14:31:59 (without it it can only be used by old-style board config, not DT) Oct 21 14:33:27 the only catch with the uio rule is that it needs a sufficiently recent kernel... unfortunately I have no idea what "sufficiently recent" means here Oct 21 14:33:55 but it still won't get triggered anyway with any default DT Oct 21 14:34:21 *with the udev rule Oct 21 14:37:21 I had an old version which worked on older kernels, but it was really horribly kludgy, and involved executing a helper script Oct 21 14:43:33 ARGH, jeez Gerard did you not read my posts *at all* before replying or something Oct 21 14:58:21 zmatt: reading is for sissies Oct 21 14:58:47 zmatt: real men infer the meaning of a mail from chicken bones Oct 21 14:59:45 Does the beaglebone black run with a mainline kernel or does it need out-of-tree patches? Oct 21 15:00:50 afaik I will run, but not optimally so (i.e. there may be some loss of functionality and power management) Oct 21 15:00:55 *it will Oct 21 15:02:08 it will run off mainline. small number of regressions as of now. Oct 21 15:08:08 zmatt, jkridner, cool thanks Oct 21 15:42:36 Nishanth Menon really has an epic awesome email address... 2-letter username @ 2-letter .com Oct 22 02:18:37 veremit: just noticed your question about eMMC in my history: yes, the Kingston is faster than the Micron **** ENDING LOGGING AT Thu Oct 22 02:59:58 2015