**** BEGIN LOGGING AT Sun Aug 07 02:59:57 2016 Aug 07 03:00:13 I might, if I ever find the time, make some toolage for saner generation for DTs. actual UIs aren't really my area of expertise Aug 07 03:42:15 is beagleboard working on an armv8 board? Aug 07 03:42:48 i know there's a new beagleboard x-15 but it is still 32bit Aug 07 06:56:17 I'm not aware of any armv8 TI SoC being announced Aug 07 06:57:29 i really dearly hope they are working on one Aug 07 06:57:52 why do you think you or they need it urgently? Aug 07 06:58:32 because *i* would like a board with which to start writing our AArch64 port Aug 07 06:58:54 and *they* have already been beat to market and need to catch up Aug 07 06:59:01 if all you need is a random board with an ARM core there are lots of alternatives Aug 07 06:59:08 armv8 Aug 07 06:59:15 any arm core Aug 07 06:59:22 any armv8 core Aug 07 06:59:40 i can't write a 64 bit operating system on a 32 bit computer Aug 07 06:59:43 also Aug 07 07:00:08 i have grown fond of TI's documentation and general M.O. when it comes to ARM SoCs Aug 07 07:00:22 freescale's SoCs are a nightmare to work with Aug 07 07:00:27 imagec's SoCs are a nightmare to work with Aug 07 07:00:33 samsungs's SoCs are a nightmare to work with Aug 07 07:00:34 for a TI SoC the arm core is just a small part of the whole Aug 07 07:00:35 etc. Aug 07 07:00:48 oh, wait, now i see what you mean Aug 07 07:01:02 yeah, a purely arm breakout board would be..troublesome.. to work with Aug 07 07:01:12 my workflow nessecitates ethernet/serial term/etc Aug 07 07:01:18 and the cores they've used so far (A8, A9, A15) are three of the four oldest ARM cortex-A cores Aug 07 07:01:55 yeah but they all conform to armv7 instruction set which is all i care about Aug 07 07:02:21 then you can't possibly be doing systems level programming Aug 07 07:02:37 kernel level Aug 07 07:02:40 since the cortex-a8 and the cortex-a15 are worlds of difference Aug 07 07:03:36 oh, yeah, the A8 does a lot of stuff w/r/t page table coherency differently Aug 07 07:03:53 these are all problems i'll deal with, i haven't actually worked on porting a new arch (only writing device drivers) Aug 07 07:04:01 regardless Aug 07 07:04:23 the A8 indeed has a tlb which is not automatically coherent with L1 data cache Aug 07 07:04:30 for us a new arch usually arrives with support for a popular SoC board implementing it Aug 07 07:05:03 in general the point of unification of all internal initiators (L1 data, L1 instr, dTLB, iTLB) is the L2 cache (or system memory if not L2 cacheable) Aug 07 07:05:16 other than that however the A8 behaves extremely sane and straightforward Aug 07 07:05:34 no speculative access other than instruction prefetch, everything nicely in-order Aug 07 07:05:51 pretty much every data abort is a synchronous abort Aug 07 07:06:11 it's actually very difficult to produce an asynchronous abort on an am335x Aug 07 07:06:51 the cortex-a15 otoh never seems to produce synchronous aborts, not even for reads from strongly-ordered memory Aug 07 07:07:41 i see Aug 07 07:07:59 in fact I've seen async aborts as a result of bus errors get sufficiently delayed that a task switch had already occurred and an innocent unrelated process got shot down with a SIGBUS as consequence Aug 07 07:08:04 i have to say, you are reaching the very limits of my understanding here Aug 07 07:08:33 (a boundry i am trying to push by writing armv8 port) Aug 07 07:08:52 also, that is insanity Aug 07 07:08:54 in general the behaviour of the cortex-a15 is bizarre, incredibly complex, not documented in any useful detail, and essentially impossible to predict Aug 07 07:09:10 you should also read the errata for fun Aug 07 07:09:34 i know the a8 is an outlier in how it handles things Aug 07 07:09:50 the a8 is basically borderline ARMv6 Aug 07 07:10:01 i imagine the a9, a12, a15 etc all do the same Aug 07 07:10:10 your chronology is off Aug 07 07:10:17 https://en.wikipedia.org/wiki/ARM_Cortex-A#Overview Aug 07 07:10:17 [WIKIPEDIA] ARM Cortex-A#Overview | "The ARM Cortex-A is a group of 32-bit and 64-bit RISC ARM processor cores licensed by ARM Holdings. The cores are intended for application use. The group consists of 32-bit cores: ARM Cortex-A5, ARM Cortex-A7, ARM Cortex-A8, ARM Cortex-A9, ARM Cortex-A12, ARM Cortex-A15, ARM Cortex-A17 MPCore, and ARM..." Aug 07 07:10:22 gcl-bot: STFU Aug 07 07:10:28 that is the page im looking at :) Aug 07 07:10:33 i just assumed it was numerical Aug 07 07:10:44 ARM seems to make a lot of strange design decisions Aug 07 07:10:52 kremlin: no, it's based on ARM's idea of "power" or so Aug 07 07:11:04 TI does the same Aug 07 07:11:22 amXXX? Aug 07 07:11:32 where XXX is a number describing SoC "powerfulness" Aug 07 07:11:38 am35xx is omap3-derivative Aug 07 07:11:52 am37xx is an omap36xx with different efuse settings Aug 07 07:12:26 then came omap4 and netra, which afaik are same generation but they have a different overall design Aug 07 07:12:45 netra is dm816x / am389x Aug 07 07:12:49 aye, i am unclear on the whole omap/sitara story Aug 07 07:13:02 we stick all our omap3/omap4/am335x code in one subdir in the kernel tree Aug 07 07:13:17 from netra descended centaurus, whose many partcodes include dm814x and am387x Aug 07 07:13:24 and i always felt that the sitara stuff would be better off totally seperate Aug 07 07:13:30 centaurus is also automotive dra65x Aug 07 07:13:35 ah, ok Aug 07 07:14:08 (there's also a little-known centaurus derivative c6a811x / dra62x) Aug 07 07:14:39 from here descended subarctic (am335x / dra61x / dra60x) and aegis (am437x) Aug 07 07:16:49 pruss got merged in around here also from freon/primus (omap-L1xx / am1xxx / c674x, da8xx), from which also came lcdc Aug 07 07:17:15 (a little earlier actually since afaik dra62x also has pruss) Aug 07 07:17:43 meanwhile omap4 begat omap5, a slightly awkward family member since TI exited the smartphone industry Aug 07 07:19:15 vayu (am57xx / dra7xx) is finally the point of reunification: it is a very clear omap5 descendent (and some photo actually showed an experimental chip labeled XOMAP5777) but with all the goodies from its industrial relatives merged in Aug 07 07:19:22 yes, i am *totally* lost as to the purpose or raison d'etre of OMAP5 Aug 07 07:19:46 from a kernel point of view however omap5 and vayu are treated largely the same Aug 07 07:19:50 weird coincidence you mention PRU & lcdc, i just finished a pru driver a few weeks ago and am right now in this momement writing a lcdc display driver Aug 07 07:20:34 anyhow, "sitara" is not a useful category from a software point of view Aug 07 07:20:42 it's just a marketing term Aug 07 07:21:59 that's also why I used the codenames above whereever I know them, since from a kernel point of view you couldn't care less what partcode got stamped on the package or which brand has been assigned to it for marketing purposes Aug 07 07:22:10 aye, i am seeing its ambiguity now Aug 07 07:22:42 i.e. whether it's an "OMAP36xx" or a "DaVinci DM37xx" or a "Sitara AM37xx" ... it's all exactly the same die, just different feature bins Aug 07 07:22:55 mhm Aug 07 07:23:10 i.e. the kernel doesn't give a shit, it's just some stuff enabled or not in DT Aug 07 07:23:43 meanwhile the AM335x is architecturally totally different from the AM35xx Aug 07 07:23:46 like not all PRU egpio pins being broken out on bbb Aug 07 07:23:58 god, that distinction is killer for me Aug 07 07:24:07 and i am not even dyslexic Aug 07 07:24:24 which is why I prefer to call the am335x by its codename subarctic Aug 07 07:24:32 :) Aug 07 07:24:34 people are better at names than at 4-digit numbers Aug 07 07:25:26 unfortunately I don't know the code names for all dies, if they even have any Aug 07 07:25:40 what, uh Aug 07 07:25:46 what makes the automotive chips special Aug 07 07:25:52 is it just regulatory conformance or something else Aug 07 07:26:32 mostly the part code :P and there are some automotive-specific peripherals like MLB Aug 07 07:26:46 ah Aug 07 07:27:01 probably tech support will be handled differently too Aug 07 07:27:51 note that in an unusual move of openness TI recently published TRMs of the DRA75x and TDA2x Aug 07 07:28:24 still "public TRMs" so not everything covered Aug 07 07:28:51 but the fact they published anything at all besides glossy whitepapers and 2-page technical briefs is completely novel Aug 07 07:29:43 i know they aren't going to fork over everything -- but the public TRMs from TI ive worked with in the past have eschewed the deadly mistake of not keeping private stuff and public stuff totally seperate Aug 07 07:29:46 like, for example Aug 07 07:29:54 nxp/freescale imx.6 TRM Aug 07 07:30:04 tells you a whole lot about how the image processor (IPU) works Aug 07 07:30:14 but there are a few private bits they leave out Aug 07 07:30:32 you mean like TI did with PRUSS :P Aug 07 07:30:35 all the other IPU documentation would lead you to believe they are giving you enough to build a functioning thing out of Aug 07 07:30:38 but no, they just lead you on Aug 07 07:30:42 how so? Aug 07 07:30:47 i have worked extremely intimately with the PRU Aug 07 07:30:52 ah okay no I haven't seen that with TI Aug 07 07:30:54 and haven't hit troubles Aug 07 07:31:18 well they didn't use to document anything about how MII-RT (EtherCAT) worked Aug 07 07:31:28 and were pretty vague about EDIO Aug 07 07:31:51 they fixed that recently in the same burst of openness though Aug 07 07:32:13 but usually TI indeed doesn't do what you just described Aug 07 07:32:49 although, u-boot for the omap5 does some pretty opaque initialization, including writing control module registers marked "reserved" in the TRM Aug 07 07:33:56 how bizzare Aug 07 07:34:19 anyhoo, it is late for me, nice talking to you Aug 07 07:34:21 yes, apparently something to do with slew rate compensation Aug 07 07:35:10 i remember a register bit that would toggle gpio pin's slew rate between "fast" and "slow" (?) Aug 07 07:35:10 both omap5 and vayu though have plenty of control module registers you wouldn't dare to touch unless explicitly instructed to by TI :P Aug 07 07:35:15 <-- actually gone Aug 07 08:54:00 Hi there, I need some help. I want to know how bone_capemgr load the dtbo file specified in uEnv.txt, especially the machnisam Aug 07 08:54:08 anybody can help me Aug 07 09:49:50 My BBB wont show any lights near the usb port or boot to a operating system Aug 07 09:49:50 what could be causing this? Aug 07 16:45:24 Hello Aug 08 02:37:33 just to be absolutely clear -- there is NO WAY to guarantee the PRUSS can only access memory within its own space Aug 08 02:37:54 that is to say, there is NO WAY to guarantee it never accesses external memory over the ocp port, right? Aug 08 02:38:33 i know there is OCP enable bit in some registers, but from my understanding the pru could just flip that bit if it wanted (no was host can "lock it down" to its own memory space) **** ENDING LOGGING AT Mon Aug 08 02:59:58 2016