**** BEGIN LOGGING AT Sun Jul 03 02:59:58 2016 Jul 03 06:49:29 Hey ! I have questions about clpru Jul 03 06:49:42 so here : https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/docs/clpru_and_C_usage.notes#L255 Jul 03 06:49:57 the __xin() can have any base register Jul 03 06:50:25 but then, C uses some of the register for its functioning https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/docs/clpru_and_C_usage.notes#L146 Jul 03 06:51:32 So, can I assume that using any base register with __xin() will work as the Compiler will internally manage all the stuff ? Jul 03 19:23:14 This is beyond me. I just programmed the PRU in C like any other embedded system and didn't do things at this level. Jul 03 19:29:16 Speaking of things that are beyond people Jul 03 19:29:58 I've done normal standalone ARM stuff, but I can't figure out how to get my code to be loadable through u-boot without it all exploding horribly Jul 03 19:30:11 No one online is helpful or useful Jul 03 19:32:15 I put in a linux image and it boots. My code run on that. Sounds like you're doing more bare metally something. Jul 03 19:33:36 Yeah, that's what I'm trying to do Jul 03 19:34:27 I think zmatt had some examples for building bare metal code Jul 03 19:34:38 There are examples Jul 03 19:36:36 But they all... Jul 03 19:36:45 oh my god i'm so dumb how do I manage to dress myseld Jul 03 19:38:22 PROTIP: turns out that loading a binary into a place in RAM that's also where the code you're trying to run is putting it's variables Jul 03 19:38:27 doesn't do too well Jul 03 19:40:54 Nah, it's still prefetch aborting at +4 even Jul 03 19:40:54 lol! At least you figured it out. Jul 03 19:41:00 Poo. Jul 03 20:04:42 screw it Jul 03 20:04:49 I'll write my own bootloader Jul 03 20:04:55 With blackjack and hookers Jul 03 21:15:10 Sinestro: for the absolute minimum requires, see https://github.com/mvduin/bbb-asm-demo Jul 03 21:15:28 (there's no reason to do all that in asm though, but I happen to have that example lying around) Jul 03 21:15:48 realistically you also want to setup the mmu and enable caches Jul 03 21:16:33 I'm not sure what needs to be changed to be chainloaded via uboot, although I have in the past successfully invoked baremetal code from uboot Jul 03 21:17:09 Unless you want to use one of the few examples that heavily link into the GPLed u-boot code they provide, no one seems to know Jul 03 21:17:22 I suspect the demo.bin file created by this project can actually be directly invoked by uboot Jul 03 21:17:36 There's just a bunch of people asking and then either getting no response or posting back that they fixed it and not saying how Jul 03 21:17:41 although I don't remember using which of the boot* commands Jul 03 21:18:12 or maybe it was just "go $address" or something after loading it into memory Jul 03 21:18:54 Yeah that seems to be the thing Jul 03 21:19:24 It just keeps blowing up like there's something wrong with the binary/corruption Jul 03 21:19:45 but really, the only reason to still use uboot is if you need the memory controller or pmic initialized (say to run at 1 GHz instead of 500 MHz) but can't be bothered to do the init for that yourself Jul 03 21:20:18 Well, the idea of it was to make it marginally easier to move to another platform later Jul 03 21:20:21 well if you want a known-good binary, use the project I just linked Jul 03 21:20:50 not really, if you're writing baremetal code you'll end up using highly SoC-specific stuff anyway Jul 03 21:21:32 I meant more in the sense of it being able to be made modular down the road more easily if it's already in u-boot world Jul 03 21:21:47 Hell, there's a ton of delicious device tree data about everything I could use... Jul 03 21:23:39 my demo project isn't relocatable btw (afaik), it does need to be loaded specifically at 0x402f0400 Jul 03 21:24:01 which is where the ROM bootloader would load it Jul 03 21:37:44 ok, time to catch a train Jul 03 22:06:56 Sinestro: btw, do you actually have experience with Device Tree? sicne I wonder if you're not overestimating its value :P Jul 03 22:07:32 Not much practical experience, but enough to know it's pretty much useless Jul 03 22:07:54 But it does at least associate hardware with family names that mostly map to a choice of driver Jul 03 22:08:02 it's not exactly convenient to work with, and it falls quite short of describing the SoC since many devices just reference SoC-specific (variants of) drivers, and moreover linux still has quite a significant amount of hardcoded knowledge of the SoC Jul 03 22:09:02 Yeah honestly it'd probably be easier to just write my own thing like that, since I don't need either the consistency with platforms from 30 years ago or the generality that Linux wants (or it existing at all, but where's the fun?) Jul 03 22:09:03 it isn't even theoretically capable of describing the interconnect structure since as the name "Device Tree" suggests it assumes a tree structure, which simply isn't true Jul 03 22:09:50 I tried to read about it and it seemed... interesting Jul 03 22:10:21 several peripheral devices have multiple target ports on different interconnects Jul 03 22:11:21 moreover it means deferring choices to runtime that for efficiency you'd much rather do at compile-time Jul 03 22:12:04 Well, that's unavoidable considering the impractical pie-in-the-sky goals I have. :v Jul 03 22:13:11 well my pie-in-the-sky goals would include using a SoC description to generate the relevant code, to get both genericity and efficiency :P Jul 03 22:13:26 but more realistically, try getting anything to work at all first ;) Jul 03 22:13:50 No, that's an afterthought Jul 03 22:13:55 Implementation details! Jul 03 22:14:03 I'll be the next Hurd before I know it. Jul 03 22:14:10 Wait Jul 03 22:14:12 on the bright side, I may soon be able to tell you how to properly chainload from u-boot, since I want to run a baremetal test on an omap5, where u-boot does more magical init stuff than I'd care to reimplement myself right now Jul 03 22:14:15 that's not a good thing Jul 03 22:14:46 that'd be pretty rad, because honestly bootloaders do exist for a reason Jul 03 22:15:05 to load boots :P Jul 03 22:15:13 (also, the omap5 *needs* correct init since it powers up in a configuration that's damaging in long term... a little erratum) Jul 03 22:15:19 oh wow Jul 03 22:15:24 * Sinestro golf claps Jul 03 22:15:57 vayu (dra7xx/am57xx) inherits the same issue Jul 03 22:16:11 oh like Jul 03 22:16:15 it's a consistent thing Jul 03 22:16:27 and not 'well, we can't justify a new stepping, eat shit chipbuyers' Jul 03 22:16:45 * Sinestro stares off into the distance, not comfortable with what she's learning Jul 03 22:17:14 well maybe they'll fix it in a later revision, then again it's very easy to work around with no negative side-effects so it's probably not really a priority Jul 03 22:17:44 not like the "fails to reset" category of bugs that plagues 1.x revisions of vayu :P Jul 03 22:18:00 they're not bugs Jul 03 22:18:04 they're engineer puzzles Jul 03 22:18:07 it's added value tbh Jul 03 22:18:14 "It's working as designed." Jul 03 22:18:47 but really, u-boot is not going all that much important on an am335x ... most of what it initializes is overridden by linux anyway, except for the memory controller init Jul 03 22:19:19 but you only need to init that if you need >127 KB of ram anyhow, which actually takes some effort when writing baremetal code ;) Jul 03 22:19:30 unless of course you' Jul 03 22:19:33 You haven't seen my coding styles. Jul 03 22:19:35 unless of course you're u-boot Jul 03 22:19:50 emif init isn't actually hard though Jul 03 22:19:59 it's mostly writing a bunch of fixed values into registers Jul 03 22:21:23 btw, although my asm demo doesn't include mmu init code, I did make a partial example for this for the am335x -> https://community.arm.com/docs/DOC-10098 Jul 03 22:21:39 I don't want too many spoilers. :P Jul 03 22:21:53 lol Jul 03 22:21:59 I'm trying to just look at the comments Jul 03 22:22:02 this stuff is non-trivial to figure out Jul 03 22:22:15 Well I want to at least try and fail first Jul 03 22:22:17 do you have prior experience with baremetal coding on Cortex-A SoCs ? Jul 03 22:22:23 hehe Jul 03 22:22:24 fair enough Jul 03 22:22:25 Not on Cortex-A Jul 03 22:22:35 but on Cortex-M and on x86 Jul 03 22:22:46 http://gerbil.xs4all.nl/start.S.html Jul 03 22:22:48 last hint ;) Jul 03 22:23:00 that's the only asm code in my current baremetal codebase Jul 03 22:23:07 the rest is C++ Jul 03 22:23:17 it looks like a lot of fun Jul 03 22:23:19 get it Jul 03 22:23:27 because there's a bunch of functions Jul 03 22:23:33 i'm very witty Jul 03 22:23:40 :P Jul 03 22:23:46 anyhow, bbl Jul 03 22:23:50 ok! Jul 03 22:56:59 oh, one thing Jul 03 22:57:14 you wouldn't happen to be able to spare that defs.h file, would you? Jul 03 22:58:39 or is having to come up with those part of the 'fun'? Jul 03 23:21:02 back Jul 03 23:24:00 well I thought you didn't want too much spoilers? ;) Jul 03 23:24:15 actually I think it's pretty similar to the asm-defs.h in bbb-asm-demo, but lemme see Jul 03 23:32:32 there, made it a clickable link :) Jul 03 23:39:12 Sinestro: btw there's also TI's "StarterWare" ... which I'm mostly just mentioning as a warning, it's horrible Jul 04 00:26:36 lol It was an excellent example of how I didn't do anything. Jul 04 00:44:22 hmm? Jul 04 01:06:16 Sinestro: I remembered right about "go", go $address $args simply invokes a subroutine located at $addr (set bit 1 for thumb as usual) with prototype ulong entrypoint( int argc, char *const argv[] ) Jul 04 01:06:57 unlike when linux is invoked this does not disable caches **** ENDING LOGGING AT Mon Jul 04 02:59:58 2016